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

From: "Greg O'Shea" <[email-masked]>
Date: Thu, 9 Jan 2003 09:43:56 -0000

The authentication/authorization of the HoA appearing in the BU gets
looked up in IPSec which is fine - I was thinking of the implicit
(derived) HoA' that don't get looked up in IPSec when creating a home
binding because IPSec never gets sight of the HoA'.

Re Jari's ideas:
A) explicitly tests that a given MN owns and is explicitly authorized to
use a specific HoA, and simultaneously that IPSec is configured for that
HoA (else HoT for that HoA may be compromised on a foreign net). In my
experience it is extremely easy to misconfigure IPSec for MIPv6 so
personally I would draw confidence from explicitly testing these things
when creating each home binding. Others may feel differently. I agree
that this would be awful to implement for s=0.
B) Presumably an empty SPD/SADB would be conflict free...

Please make support for s=0 an optional feature on HA and MN, then I can
stop worrying about its consequences.
Greg
>-----Original Message-----
>From: Ed Remmell [mailto:[email-masked]] 
>Sent: 08 January 2003 17:56
>To: Jari Arkko; Greg O'Shea
>Cc: [email-masked]
>Subject: RE: [mobile-ip] MIPv6 IPSEc and s=0
>
>
>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:
>> > "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.
>>
>> 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: Jari Arkko <[email-masked]>
Date: Thu, 09 Jan 2003 17:54:44 +0200

> binding because IPSec never gets sight of the HoA'.

Right. I agree with Greg that we do have an issue here.

> that this would be awful to implement for s=0.

Sigh, but I guess you are right... we also have an additional
problem with security associations: it is impossible
to deduce from reception of a message on SA1 that another message
on SA2 could be correctly received. That is, if you configured
the SAs manually, I really don't know if the MN has a key that
would allow sending a packet that passes the SPD/SADB for HoA'.
Remember that the SAs are HoA-specific! In IKE, there's no
problem as we can check whether the same phase 1 identity
would have been allowed when creating a phase 2 SA for HoA'.
This ties S=0 to IKE, which I'd very much like to avoid.
If anyone has a suggestion, let me know.

Conclusion? If the above is right, we got more problems with
S=0. But I'm trying to fix this anyway.  Here's the suggested
text:

When the Single Address Only (S) bit is zero, the home agent
MUST check that the IPsec and IKE security policies would
allow the creation of a security assocation for the implied
home addresses by the same identity that was used when
creating the security association that carried the Binding
Update.

> stop worrying about its consequences.

Well, we are debating this in the other issue... I guess the main
objection to that was that if its optional then the MN implementors
will have to prepare for S=1 case anyway, and will not implement
S=0 at all => more BUs will be needed. However, perhaps this is
an unnecessary fear. It is the MNs that care about speedy access
and small number of packets. If they care about that, they will
implement S=0 even if the code has to have a fallback for S=1.

Could this be a compromise?

Jari

---

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

IMHO MN support for S=0 BUs should be optional, I hadn't realized it was
mandatory. HA support for S=0 BUs should continue to be mandatory.

I agree that only MNs that care about optimizing to reduce the number of BUs
sent (and thus minimize handover latency) should use the S=0 BU. Otherwise,
multiple S=1 BUs works perfectly fine.

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

> Sent: Thursday, January 09, 2003 8:55 AM
> To: Greg O'Shea
> Cc: Ed Remmell; [email-masked]

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 09 Jan 2003 10:45:01 -0800

Hello folks,

> Right. I agree with Greg that we do have an issue here.

This is really not an issue.  The point is that the mobile node
needs to be able to continue the defense of several or many
related addresses that it would naturally be able to defend if
it were still present on the home network.   The home agent is
there to serve the needs of the mobile node.  The mobile node
does not gain any ability to threaten other nodes that it would
not have if it were on the home network.  If anything, this is
an IPsec problem, not a Mobile IPv6 problem.  It should not be
posed as a problem for Mobile IPv6.

> creating the security association that carried the Binding

This is O.K. with me, and it also serves to point out that
the problems lie solely with IPsec.

> implement S=0 even if the code has to have a fallback for S=1.

I think it's fine for the S=0 case to be purely optional at
the mobile node.  But, it has to be mandatory for the home
agent to implement S=0.

Regards,
Charlie P.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 10 Jan 2003 16:43:28 +0200

> posed as a problem for Mobile IPv6.

Fair enough. I agree that IPsec is a major cause for
this problem. [And no, I'm not too happy about the
complicated beast IPsec protection for the home
registration signaling is turning out to be.]

Nevertheless, it *is* a problem and needs to be
addressed in our specifications.

> the mobile node.  But, it has to be mandatory for the home

The current spec is unclear about the required support level
for MNs. It also doesn't explicitly say anything about the
support for HAs, though the implication is of course that
its mandatory because there is no error code to report a
failure etc.

Greg, would you be happy with optional for MNs, mandatory
for HAs? If yes, here's the text change in 11.7.1:

   The mobile node MAY clear the Single Address Only (S) bit ...
   Otherwise, the mobile node desires that only a single home
   address should ... and sets ...

and in 10.3.1:

    ... depend on the settings of the Single Address Only
    (S) and Link-Local Address Compatibility (L) bits. The
    home agent MUST observe these bits as follows:

Jari

---

From: Brian Haley <[email-masked]>
Date: Mon, 13 Jan 2003 17:01:25 -0500

> multiple S=1 BUs works perfectly fine.

Right, the S-bit isn't required in the protocol, it's an optimization,
which is why I asked a year ago to remove it :)  With all the IPsec
discussions going on recently, isn't it possible we still missed some
other problem?  Putting it in a separate draft gives people time to
investigate things further.

-Brian