Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6 mobility

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 01 Jul 2004 15:21:58 -0700

Greg Daley wrote:
> In the MIPv6 case, it may be possible to exchange delegation
> chain messages over the home tunnel to ensure that the MN knows
> that the HA is authorized to be a router for the prefix.
> Also, the MN could sign the key of the router and send back
> a proxy certificate by a similar message.
> 
> There may have to be a control plane request in the message
> sent back to the router which could request use of the address,
> and proxying.  With MIPv6 this is already done if the
> proxy certificate is sent within a BU/BAck.

sounds like an idea that would work. maybe you should
write up a draft on this.

Vijay
--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

---

From: Greg Daley <[email-masked]>
Date: Fri, 02 Jul 2004 13:26:08 +1000

Hi Vijay,

I'll see if I can get some time
before the drafts deadline.

I think we'd have to talk about functional
requirements rather than implementation
specifics.

We will still have to look carefully at the
existing SEND to see if the security model
matches though...

:)

Greg

---

From: "James Kempf" <[email-masked]>
Date: Tue, 6 Jul 2004 11:33:51 -0700

Jean-Michel,

> 1) I agree that the issue that you mention is a
> limitation. I'm not sure the security considerations
> section is the right place to explain the limitation,
> however; it seems that the limitation is functional
> rather than security related.

IMO, this is a security issue because SEND works if the "proxy" has the
Mobile's key and so the issue is in fact linked to the CGA key distribution
(Mobile -> "proxy" or "proxy" -> Mobile)

jak>> If the paragraph in Section 1 I posted won't do, please propose some
text and placement in the security considerations section that will address
your concerns.

>
> In any case, Section 7.14 (Limitations) already
> states: "Proxy Neighbor Discovery is not supported
> by this specification." Do you think more text
> is needed?

Yes, IMO, I think we need more text ... I am afraid to see in some drafts
"Just use SEND" as we saw for RFC 2401 with "Just use IPsec".

jak>> I'm afraid to say "not our problem". If people are not willing to take
the time to read the drafts and understand what the technology does and
doesn't do, then there is not much we can do about it. SEND is not a
panacea. Of course, when someone does use the "pixy dust" approach and we
notice it, we should try to call them out on it.

>
> 2) I believe there's a solution that can support
> proxy ND with SEND; for now the WG has determined
> that it will not include the solution in the current
> RFC. However, there's a plan to develop an extension
> later. I guess the interest level for SEND and its
> combined use with things like MIPv6 determines how
> soon is "later". Chairs?
>
> 3) In the meanwhile, MIPv6 home addresses and SEND would
> work with so called virtual home networks where the
> mobile nodes never go to.

Agree. This is the right solution for MIPv6, HMIPv6 and NEMO ...

> Care-of addresses will of
> course work with SEND in any case.

... but with FMIPv6 we have still a problem: the "proxy" function is
concerning the Co@ (for the tunneling between the PAR and the NAR).

jak>> Depending on whether the wireless link technology supports predictive
or reactive handover, there may be an issue with proxying. For a predictive
technology, the NAR may be required to proxy since the PAR informs it of the
new CoA prior to the actual link handover. However, this is entirely
theoretical at the moment, because there is no widely available wireless
link technology that supports predictive handover and, simultaneously, would
be in a position to use FMIPv6. The cellular technologies all do local link
handover optimization their own way ("stretchy PPP" for 3GPP2, GPRS for PP).
802.16 may support predictive handover, but the WG doing mobility is about 2
years from completing the basic link design (I think it's .16e) if I
understand correctly. With a reactive wireless link technology, there's no
need for proxying because the mobile doesn't actually claim the CoA until it
is on the link. 802.11 is a reactive technology, as is 802.15.2 (Bluetooth),
and so they don't need proxying. Given the focus in SEND on meeting
immediate technology needs quickly rather than doing the full solution too
late, the WG decided to forgo working on secure proxying for now, though the
design team did discuss some approaches. If SEND turns out to be popular, we
can have a BOF and restart the WG to work on the remaining issues.

                     jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 6 Jul 2004 14:09:17 -0700

Greg,

If the minimum path MTU on the tunnel is too small, the DCA could
potentially get fragmented, and the cert exchange could suffer from the same
problem that IPsec cert exchange does, namely some router on the path drops
the packet. I'd think that this would not be as severe a problem in IPv6 as
IPv4, because theoretically the end hosts are responsible for handling path
MTU discovery and fragmentation rather than the routers, but I'm not sure
whether the implemented and deployed equipment actually lives up to this.
Might be worth testing.

In addition, by RFC 3775, the HA and MN need to have an IPsec SA in place to
secure the MIPv6 signaling traffic. Now, this SA doesn't actually require
the HA to identify what prefixes it is authorized to route, like the SEND SA
does, but it does require the HA to be authenticatable. So I'd think adding
the address extension to the certificates used to identify the HA would be a
better option, provided, of course the SA is constructed using certificates,
as it would avoid having the HA send the same set of certs twice.

It might be useful to have some kind of flag or something in the HA
Discovery message to request that the HA identify what prefixes it is
authorized to route, not sure. There's feeling among some that the address
extension for authorized prefixes is too fine-grained a mechanism, and that
just having the router identify itself in an authenticatable way is
sufficient. Time and deployment popularity will tell.

            jak

----- Original Message ----- 
From: "Vijay Devarapalli" <[email-masked]>
To: <[email-masked]>
Cc: "Jean-Michel COMBES" <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Thursday, July 01, 2004 3:21 PM
Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6
mobility

---

From: Greg Daley <[email-masked]>
Date: Wed, 07 Jul 2004 09:56:14 +1000

Hi James,

> whether the implemented and deployed equipment actually lives up to this.

Certainly.

> as it would avoid having the HA send the same set of certs twice.

This sounds like a good idea too.

> sufficient. Time and deployment popularity will tell.

Indeed.

I can understand that a simple certificate saying
I'm a router for ISP XYZ is considered sufficient
in this case.

What's important is a mechanism which allows the HA
pass a the correct public key for the MN to sign (whether
in IPSec key exchanges or not).
The they used for SEND may not be the same public key
IPSec key negotiation, though.

The responding indication from the MN needs to provide
both an authorization and a timestamp though (which
sounds like a certificate, too). So we need to
determine if this response can be sent in (just) DCA,
or needs to be put into the end of a BU message, which
would cause MTU issues too.
Perhaps an option indicating the HA's public key (actually
a hash over the key as used in SEND) and the authorization
timestamp could be included in both messages (BU and DCA).

A more radical alternative would rely only
upon the routing authorization of a router for a
particular prefix, and allowing routers to create
neighbour cache state for any address they are
authorized to route (except for other routers'
addresses).

This wouldn't require the MN to sign a key at all,
and would be based on the timing of the NCE of the
proxying router (the original timer from the
address owner being kept in limbo, to use in
verifying an MN's return).

This entrenches authorized prefixes though.

Greg

---

From: "James Kempf" <[email-masked]>
Date: Wed, 7 Jul 2004 08:44:01 -0700

Greg,

Greg,

> timestamp could be included in both messages (BU and DCA).

I guess I'm not following you here. Why do you want the HA to send a public
key to the MN to sign? In SEND, the host isn't acting as a certificate
authority.  The router is providing the host with a certificate chain
including the router's certificate with the router's public key, allowing
the host to verify the authenticity of the router's public key and providing
that key to host so the host can verify Router Advertisements. Is there some
different requirement for Mobile IP that we've missed?

> This entrenches authorized prefixes though.

What threat is this intended to mitigate?

            jak

---

From: Greg Daley <[email-masked]>
Date: Thu, 08 Jul 2004 11:25:56 +1000

Hi James,

Perhaps I'm getting a little ahead of myself.

I'll try to describe myself below. I hope my
interchangable use of the words MN as the proxied
node and HA/Router as the proxier don't cause confusion.

What's needed is a mechanism to allow the
HA to undertake proxy neighbour discovery for
the MN on the home link (or a node or router
to be a proxy for host). MIPv6 has a mechanism
for PND, but it is unsecured, as is all PND.

What's needed for other hosts on the home subnet
to trust a (secured) PND is either a
blanket authorization for an authorized router to
proxy on a particular subnet, or a delegated
authority from a host that another may act on its behalf
in ND.

Below I describe each of the possible schemes and
outline some advantages and disadvantages.

In the first case, the router and MN don't need to
exchange any information about keys.
The router/HA just starts advertising for a particular
MN address, and people believe them because they're
the router (with router certificates).

The second case allows devices which are known to the MN
to start undertaking advertisement on the MN's behalf,
but require some proof to show to neighbours on the link
that the proxy behaviour is authorized by the end host.

The proof could easily be some sort of simple certificate
generated by the MN (fairly minimal) which the proxy
can show to others in a DCA message, if they question
the proxy's authority.

The signature in the certificate would be tied to
the CGA which is being proxied. It would sign the
public key of the host who is allowed to proxy.
That public key being that key used for signing its
SEND messages.

Obviously this key generation and communication of
authorization exceeds any requirement for a SEND host
yet mandated.

Of the two schemes, one requires no exchange of
keying information, but cannot be directly tied to the
MN's wishes.

The other requires the proxy to send its public key to
the proxied in order for it to generate a certificate,
for the proxy to advertise to others when doing (secured)
PND.

Of course, if the MN already knows the public key of the MN
because it has been there (or has received it in IKE),
then the MN doesn't need to re-learn it when proxying starts.
The MN will still need some explicit way of providing
its authorization (the certificate) to the router when the
proxying starts.

If explicit authorization for particular subnets isn't
available in the advertised SEND router certificate
delegation, then the first method may not be a good idea
(not sure yet, but uneasy about any router with any
delegation chain being able to proxy without a proxied
host knowing).

The proxied host's certificate generation may be useful
in a home networking environment since a host could
try to delegate authority to an ND proxy, which may not
be trusted as a router on the closer-to-internet network
(and so may be more generally applicable).

Greg

> different requirement for Mobile IP that we've missed?

Please tell me if the description I've made above
doesn't clear this up.

> What threat is this intended to mitigate?

This is only related to the mechanism which
trusts routers to do proxying without certificate
generation by the proxied SEND host.
Knowing which prefixes a router may be authorized
for helps to avoid unpleasant situations where
a router starts usurping another's role.

This may particularly be useful if there are more
than one 'authorized router' on a link, potentially
authorized for (advertising?) different prefixes.

It may be possible for the router which didn't
advertise a particular prefix to start sending
Proxy NA's for a host.
If the authorization isn't explicit about
which prefixes a router may proxy or route for,
it may not be a good idea to allow routers to
proxy for addresses without explicit authority
provided by the proxied address owner.

Does this clarify some of my concern in this case?

Greg

---

From: "James Kempf" <[email-masked]>
Date: Thu, 8 Jul 2004 09:24:06 -0700

Greg,

Thanx for the explanation, I think I understand better.

> for PND, but it is unsecured, as is all PND.

PND needs security, but I think we ought to understand why (i.e. the problem
statement).

In the mobile context, I can think of only two cases where PND would need
security:

1) NAR proxying during FMIP predictive handover. However as I mentioned in
my previous post, there are currently no wireless link types able to do
predictive handover that would use FMIP.

2) DAD defense of an autoconfigured home address by the HA, so the MN
doesn't have to. However, as discussed in
draft-kempf-mip6-bootstrap-problem-statement-00.txt and in the soon to be
released boostrapping design team WG draft, it is today not possible to use
a dynamically allocated IPv6 home address with MIP6 because the HA can't
verify if the MN is authorized to use the address. The bootstrapping design
solution will address this issue.

Are there any others?

Since neither of these is a problem at the moment, there doesn't seem to be
a particularly compelling need to come up with a secure PND solution right
now, IMHO.

> the router (with router certificates).

If the router has a cert and the MN has validated it, then this would only
require the NA response to be signed by the router. However, this kind of
"trust the network" approach is not likely to appeal to "only the host can
be trusted" purists.

> authorization exceeds any requirement for a SEND host

The SEND design team talked about having the MN issue an authorization
certificate to the router. There would need to be some protocol involved for
this, of course.

> its authorization (the certificate) to the router when the

I think you mean "if the HA already knows the public key..." but, yes, I
understand what you're saying.

> (and so may be more generally applicable).

These are all considerations. At some point, solving the security problem
for PND will become more compelling, IMHO. Right now, there's more urgent
problems, like fixing bootstrapping for MIPv6.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Thu, 8 Jul 2004 14:52:31 -0700

> predictive handover that would use FMIP.

Vijay points out that PND is needed for reactive handover too. The PAR must
defend the MN's old CoA until the tunnel to the new CoA is torn down;
otherwise the old CoA may be claimed by a new host arriving on the old link.

            jak

---

From: Greg Daley <[email-masked]>
Date: Fri, 09 Jul 2004 13:53:05 +1000

Hi James,

> otherwise the old CoA may be claimed by a new host arriving on the old link.

Your response is faster than mine...

It may be that we need a Problem Statement to
show what needs to be done.

It would be good to have something to talk about
even if we're not having a session at IETF60,
so perhaps we can get some of this into a draft.

Vijay also mentioned this before...

Hi Vijay.

Greg

---

From: "James Kempf" <[email-masked]>
Date: Fri, 9 Jul 2004 11:19:44 -0700

Hi Greg,

The SEND WG actually will be shutting down shortly, so I'm not sure where to
send a PND problem statement. We could hold a BOF in Washington (cause it is
too late for San Diego) I suppose, but if we were to do that, I'd like to
see a bit more committment from people about actually doing the work and
from vendors about actually implementing it. So far, that's not there.

Given the lack of real product interest, we could also do it in the context
of MOBOPTS (cc'ed) since it does seem to be a security issue for FMIP. Shall
we organize a BAR BOF at IETF 60?

        jak

----- Original Message ----- 
From: "Greg Daley" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Vijay Devarapalli" <[email-masked]>; "Jean-Michel COMBES"
<[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Thursday, July 08, 2004 8:53 PM
Subject: Re: RE : Problem of interaction between SEND(CGA) and the IPv6
mobility

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Sat, 10 Jul 2004 15:32:22 -0700

James,

<snip>
> is on the link. 802.11 is a reactive technology, as is 802.15.2 (Bluetooth),

I don't understand this part. Why do you think in 802.11, that the NAR cannot defend
the new CoA when the MN is on the old link ? When the node is on the old link, why can't it 
do the standard FMIPv6 like on any other link ? 

thanks
mohan

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Sat, 10 Jul 2004 15:39:23 -0700

Greg,

> (and so may be more generally applicable).
Which deployment scenario requires secured Proxy ND ? If MIPv6
is deployed by the operators, there would not be a real home link
AFAIK. If MIPv6 is deployed in an enterprise, the trust is sufficient
enough to not require proxy ND i guess. So, i am missing something
on where proxy-ND would be required in practice.

thanks
mohan

---

From: "James Kempf" <[email-masked]>
Date: Mon, 12 Jul 2004 09:20:23 -0700

For reactive handover, the NAR doesn't know the new CoA until the MN
switches to the new link. I suppose the MN could configure prior to
switching if it had information on prefixes available on the new link, but
in .11, the interface firmware typically makes the switch decision and it is
difficult for the OS to intervene.

For predictive handover, of course, the HI/HAck sends the new CoA to the
NAR, so it can defend.

       jak

----- Original Message ----- 
From: "Mohan Parthasarathy" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Jean-Michel COMBES"
<[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, July 10, 2004 3:32 PM
Subject: Re: Problem of interaction between SEND(CGA) and the IPv6 mobility

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 12 Jul 2004 10:00:20 -0700

> difficult for the OS to intervene.
Look at http://hostap.epitest.fi and follow the README there. There are different modes
the driver can operate on. And one of the modes (mode 3), the firmware and driver does not involve
in any handoff decision. 

-mohan