Subject: [mobile-ip] MIPv6 IPSEc and s=0

From: "Greg O'Shea" <[email-masked]>
Date: Wed, 8 Jan 2003 09:21:38 -0000

"Such a check can be provided in
   IPsec processing, by having the security policy database entries
   unequivocally identify a single security association for any given
   home address and home agent." [5.1]

This appears to be undermined by s=0 where bindings can be created on an
HA in a way that bypasses IPSec. Maybe s=0 processing should be extended
to verify that the MN and HA share SA's for each HoA in the set of
addresses generated from the HoA specifically cited in an s=0 Binding
Update.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 08 Jan 2003 17:29:09 +0200

> addresses generated from the HoA specifically cited in an s=0 Binding 

Good point. (I'm starting to see the reasoning in your earlier complaints
about S=0...)

The "unequivocally identify" rule is basically for the system
administrator, or the software if there's some sort of automatic
MIPv6-specific policy support. If we start to require the S=0
case to be checked, should we do it (a) when the S=0 BU arrives
or (b) require the SPD/SADB setup is conflict free even when
S=0 is used? I'm leaning on the latter because it appears easier.

Jari

---

From: "Ed Remmell" <[email-masked]>
Date: Wed, 8 Jan 2003 10:55:55 -0700

Jari & Greg -

Per section 11.7.1 "Sending Binding Updates to the Home Agent":

"Each Binding Update MUST be authenticated as coming from the right
   mobile node, as defined in Section 5.1.  The mobile node MUST use its
   home address - either in the Home Address destination option or in
   the Source Address field of the IPv6 header - in Binding Updates sent
   to the home agent.  This is necessary in order to allow the IPsec
   policies to be matched with the right home address."

So, it is the MN home address in the BU which matters here for this specific
BU authentication, not any other implied home addresses associated with the
S=0 binding.

W/ regards to IPsec configuration for other MN home addresses being used,
this should be the same regardless of whether the MN is registering those
home addresses individually using multiple S=1 BUs or registering some or
all of those en masse using a S=0 BU.

The advantage of the S=0 BU is that it decreases the number of BUs that the
MN needs to send after movement to a new foreign link, which reduces latency
due to subnet movement. If you want to remove it from the draft because of
the extra complexity involved, I'm OK with that, I'd just like to know
sooner rather than later before I invest too much time into implementing it.
I'm not incredibly happy with the "feature" of the HA defending the MN's
auto-configured link-local scope address for the S=0 BU, because it
complicates MN return to home logic, so I'd be happy either way (i.e. keep
or remove).

Thanks.
- Ed Remmell
Elmic Systems, USA
http://www.elmic.com

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jari Arkko
> Sent: Wednesday, January 08, 2003 8:29 AM
> To: Greg O'Shea
> Cc: [email-masked]
> Subject: Re: [mobile-ip] MIPv6 IPSEc and s=0
>
>
> Greg O'Shea wrote:

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 08 Jan 2003 18:16:18 -0800

> This appears to be undermined by s=0 where bindings can be created on
> an HA in a way that bypasses IPSec. Maybe s=0 processing should be
> extended to verify that the MN and HA share SA's for each HoA in the
> set of addresses generated from the HoA specifically cited in an s=0
> Binding Update.

here is the entire paragraph.

A mobile node must be prevented from
   using its security association to send a Binding Update on behalf
   of another mobile node using the same home agent.  This MUST be
   achieved by checking that the given home address has been used with
   the right security association.  Such a check can be provided in
   IPsec processing, by having the security policy database entries
   unequivocally identify a single security association for any given
   home address and home agent. 

you ommitted the first two sentences. the reason for the check is 
given in the first two sentences. when the MN sets S=0, it includes 
only _one_ home address in the BU. the rest of the home addresses are 
derived by the HA. so nothing is undermining anything.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 08 Jan 2003 19:01:12 -0800

Ed Remmell wrote:

> auto-configured link-local scope address

Ed, 

take a look at issue #163 and #161. these issues require that the
HA proxy for the MN's link local address. the HA now has to tunnel
a packet meant for the MN's link local address if the packet 
carries MLD or stateful address configuration protocol messages.

so if the MN needs MLD and DHCP message tunneled by the home agent,
it has to ask the HA to defend and proxy its link local address.

lets move on.

Vijay

---

From: "Ed Remmell" <[email-masked]>
Date: Thu, 9 Jan 2003 08:33:24 -0700

Vijay -

Thanks, this is useful information.

Movin' on...

Thanks.
- Ed Remmell
Elmic Systems, USA
http://www.elmic.com

> [mailto:[email-masked]]On Behalf Of Vijay
> Devarapalli
> Sent: Wednesday, January 08, 2003 8:01 PM
> To: Ed Remmell
> Cc: Jari Arkko; Greg O'Shea; [email-masked]

---

From: "Ed Remmell" <[email-masked]>
Date: Thu, 9 Jan 2003 11:15:10 -0700

Vijay -

IMHO, L=1 isn't really necessary in the case of S=1 BUs (except perhaps for
supporting DHCPv6 run over the MN-to-HA tunnel, although I don't completely
understand how that scenario works - I assume the purpose for this would be
to renew a lease for a HoA obtained using DHCPv6 on the home network). The
way I'm implementing MN support for application-level multicast is by using
MLD on the foreign link, not over the MN-to-HA tunnel (this method is
mentioned in section 11.3.5 "Routing Multicast Packets"). All IPv6 routers
are expected to support IPv6 multicast, so there should never be any problem
with having the MN join a specific multicast group on a foreign link, also
I'd expect multicast routing to the foreign link to be more efficient than
multicast routing over the MN-to-HA tunnel. So, since I really have no need
to have any link-local scope traffic tunneled to the MN, I plan to always
specify L=0 when doing a S=1 registration (regardless of the HoA that is
being registered). This is not completely compliant with the current spec
(since the spec says that if the HoA is formed from the interface ID, I
SHOULD set L=1 in this case)... please let me know if you see any real issue
with this implementation.

Thanks.
- Ed Remmell
Elmic Systems, USA
http://www.elmic.com

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 09 Jan 2003 09:58:20 -0800

Ed Remmell wrote:
> being registered). 
> This is not completely compliant with the current spec

no issues... 

Vijay