Subject: [mobile-ip] mobile IPv6 BindingUpdate security

From: Ramin <[email-masked]>
Date: Sat, 17 May 2003 11:02:37 -0700

All,

The MobileIPv6 draft seem to requires a separate security association 
(SA) per home address (see the excerpt from the draft below).
My question/comment:
If the link between a group of MNs and HA is protected by a secure 
tunnel and if access to the tunnel is also protected (say, by physical 
means), then a separate SA per MN does not seem to be necessary.

Shouldn't this requirement be relaxed?

Thank you,

-Ramin

============================================
5.1 Binding Updates to Home Agents
[...] 
"Such a check is provided in the IPsec processing, by having the 
security policy database entries unequivocally identify **a single 
security association for any given home address and home agent**."

---

From: Jari Arkko <[email-masked]>
Date: Sat, 17 May 2003 21:16:00 +0300

> Shouldn't this requirement be relaxed?

No, because it is still necessary to ensure that MN A (home address addrA)
does not send a Binding Update on the behalf of MN B (home address addrB).

--Jari

---

From: Ramin <[email-masked]>
Date: Sat, 17 May 2003 11:38:21 -0700

Jari Arkko wrote:

>> tunnel and if access to the tunnel is also protected (say, by 
>> physical means), then a separate SA per MN does not seem to be 
>> necessary.
>>

True, but assuming that the group of MNs that have access to the tunnel 
gateway are trusted nodes (as stated in my assumption above) the case 
that you stated would not happen.  I am assuming that untrusted MNs do 
not have access to the VPN gateway and the HA security policy is such 
that it drops packets that are received outside the secured tunnels. 

-Ramin

---

From: Jari Arkko <[email-masked]>
Date: Sat, 17 May 2003 23:30:38 +0300

> that it drops packets that are received outside the secured tunnels.

Ah, I see... then its a question of whether we think such
trust makes sense. I certainly don't think it makes sense
all of the time. Thats why we require per-MN SAs. OTOH,
perhaps it could be interesting study to figure out in
which circumstances what you propose (a) is possible and (b) saves
something. I'm not sure I understand how the mobile nodes
can roam around all over the place and still access the
same VPN gateway?

--Jari

---

From: "James Kempf" <[email-masked]>
Date: Sat, 17 May 2003 18:39:46 -0700

What about if the HA is the VPN gateway? Does the spec insist that the
security associations be host mode?

            jak

---

From: Jari Arkko <[email-masked]>
Date: Sun, 18 May 2003 16:06:36 +0300

> security associations be host mode?

You have to support host mode, but it does not outlaw other modes.
SAs have to be unique for a given home address, however. If someone
wants to develop a scheme where one tunnel mode SA is used for a number
of mobile nodes, I suppose that is possible in the future. I understand
that the HA end of the tunnel can be easily arranged, but I'm not sure
whether it is possible on the other end.

--Jari

---

From: Michael Thomas <[email-masked]>
Date: Mon, 19 May 2003 10:25:50 -0700 (PDT)

> that it drops packets that are received outside the secured tunnels. 

Frankly, we're sort of into BCP area here. Jari
correctly states that in order to secure binding
updates for the general case, you need a have a
separate SA for each MN. However, the reason that
it's in the spec is mainly so that we can prove
that there exists at least one way to solve for
the general case. We are not the deployment police
though: if your situation is such that the general
case doesn't apply and you can thus economize,
then it's probably acceptible assuming that you
understand what you're giving up. Also: as Basaraj
points out, we have contemplated other mechanisms
which also allow (re)use of a single SA (the
so-called authz-in-MIP method I proposed). The
decision to move it to a later standard/BCP if
there is sufficient interest seems quite
reasonable to me however: let's get something to
work for now and optimize later based on
experience.

		Mike

---

From: Ramin <[email-masked]>
Date: Mon, 19 May 2003 15:51:23 -0700

Jari Arkko wrote:

> Ramin wrote:
>
>> True, but assuming that the group of MNs that have access to the 
>> tunnel gateway are trusted nodes (as stated in my assumption above) 
>> the case that you stated would not happen.  I am assuming that 
>> untrusted MNs do not have access to the VPN gateway and the HA 
>> security policy is such that it drops packets that are received 
>> outside the secured tunnels.
>
>

Yes, it does not make sense for all possible scenarios.  We are 
suggesting to allow this configuration (HA being a VPN gateway) by 
relaxing the current requirement in the spec that requires an individual 
security association per home address.

Regarding (a) in your comments above:
Consider the case that the MN moves from "satellite office A" to 
"satellite office B" and each of these offices have a pre-established 
VPN tunnel with a single Home Agent.
The MN's access to the VPN gateway in the satellite offices is secured 
by virtue of being plugged in to the ethernet jack in the wall in those 
offices.

Regarding (b) in your comments above:
This would reduce the number of security associations that the Home 
Agent needs to maintain to the number of satellite offices.  It also 
reduces the BU/BA time because MNs do not need to establish individual 
security associations with the HA.

Does this make sense?

thanks,

-Ramin

---

From: Jari Arkko <[email-masked]>
Date: Tue, 20 May 2003 08:02:02 +0300

> by virtue of being plugged in to the ethernet jack in the wall in those 

It appears that what you want to do might perhaps be also
achieved by simply turning home agent binding update security off.
The security properties of the resulting system appear largely the
same; everyone is trusted.

We currently do require security to be always on, but of course
implementations might (and many do) allow configurations without
security.

Whether this makes sense is another question. My suspicion is that
if you have a network that has multiple sites and VPNs, you would
want to worry about trusting everyone in the network ;-)

--Jari

---

From: Ramin <[email-masked]>
Date: Tue, 20 May 2003 15:34:57 -0700

> want to worry about trusting everyone in the network ;-)

==>  Yes, relaxing the requirement (i.e., MUST to SHOULD) in section 5.1 
where it states "The mobile node and the home agent MUST use an IPsec 
security association to protect the integrity and authenticity of the 
Binding Updates and Acknowledgements." is exactly what I am trying to 
argue for.  We are not requesting that all the alternative ways of 
securing BU (including the one that I outlined in my previous message) 
to be included in the specification.

Accrording to the definition of the term "SHOULD" in RFC 2119, this 
seems to be an appropriate use of the term "SHOULD".

Thank you,

-Ramin

 From RFC 2119:
SHOULD This word, or the adjective "RECOMMENDED", mean that there may 
exist valid reasons in particular circumstances to ignore a particular 
item, but the full implications must be understood and carefully weighed 
before choosing a different course.

-Ramin

---

From: Jari Arkko <[email-masked]>
Date: Wed, 21 May 2003 14:08:58 +0300

Ramin wrote:
> es, relaxing the requirement (i.e., MUST to SHOULD) in section 5.1

Perhaps, but according to RFC 2119 "limit behaviour which has
potential for causing harm" is also a reason for a MUST.
So I think you could argue for MUST as well. Anyway, MUST
was what was developed earlier in the specification work and
now it starts to be a bit late to start changing things
unless they are clearly broken ;-)

--Jari