Subject: Re: [Mobike] does mobike support end-to-end use of tunnel mode?

From: <[email-masked]>
Date: Wed, 1 Feb 2006 10:31:44 +0200

Mohan Parthasarathy wrote:
 
> This still does not describe the limitation. If i can
> assume that the PAD can be configured appropriately,
> then you can ensure what address a peer gets. So,
> there seems to be a use case where this is limiting. 
> Can someone describe that ?

In host-to-host IPsec use, either your addresses are static 
(so you don't have that big need for MOBIKE), or your PAD is not 
configured appropriately -- or you're doing something like BTNS.

To take a concrete example: suppose my laptop wants to establish 
an IPsec SA with my local mail server.  Assuming some kind of 
corporate PKI, the laptop could create an IKE_SA, authenticate the 
mail server, and authenticate itself as "pasi-dot-eronen-at-
nokia-dot-com" (or "laptop-123456-at-nokia-dot-com").

But there's practically no way the mail server's PAD would contain
child SA authorization data saying that "pasi-dot-..  is allowed to
create IPsec SAs with traffic selectors matching address
192.0.2.123", since the address came from DHCP...

So either creating the IPsec SA fails, or the PAD contains data
saying "pasi-dot-... (and all other employees) are allowed to create
SAs for practically any address" (or at least addresses they can
spoof).  The latter is not exactly very secure... but that's what 
some people are using anyway (sort of like BTNS).

The "Experiences with Host-to-Host IPsec" paper by Tuomas Aura,
Michael Roe, and Anish Mohammed (try Google for PDF) describes
this and many other issues with host-to-host IPsec in detail.

With typical "VPN gateway" use, the problem doesn't really exist.
When the gateway allocates the client a new IP address using
configuration payloads, it can at the same time update the PAD.

None of this is really specific to MOBIKE as such, so I think
we should not add text about this to the MOBIKE draft...

Best regards,
Pasi
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Jari Arkko <[email-masked]>
Date: Wed, 01 Feb 2006 16:59:15 +0200

>this and many other issues with host-to-host IPsec in detail.
Right. Thanks for the reference, I hadn't seen that before.

--Jari

---

From: Mohan Parthasarathy <[email-masked]>
Date: Wed, 1 Feb 2006 10:15:36 -0800 (PST)

> 192.0.2.123", since the address came from DHCP...
Hmm..won't you be using a transport mode SA for this 
and MOBIKE is clearly out of scope here ?

> we should not add text about this to the MOBIKE
Agreed. Now, we can even put the reference and say
that
host-to-host case is out of scope.

-mohan

---

From: <[email-masked]>
Date: Thu, 2 Feb 2006 15:01:37 +0200

Mohan Parthasarathy wrote:
> > child SA authorization data saying that "pasi-dot-..  is allowed
> > to create IPsec SAs with traffic selectors matching address
> Hmm..won't you be using a transport mode SA for this and MOBIKE 
> is clearly out of scope here ?

You can use tunnel mode between two hosts if you want. 

> Agreed. Now, we can even put the reference and say that

Well... if you have host-to-host tunnel mode IPsec working in a 
secure manner, MOBIKE could work as well. But this situation 
is pretty rare.

Best regards,
Pasi

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 02 Feb 2006 11:37:43 -0800

> secure manner, MOBIKE could work as well. But this situation 

Clarifying question: for this case are you assuming that the inner and 
outer IP addresses for the tunnel must be different?

I think tunnel mode can be used (per the RFCs even if implementations 
might not handle it) where the inner and outer IP addresses are the same.

If you apply MOBIKE to such a case, then you end up with an unsolved 
address ownership issues, because the existence of the IPsec SAs, which 
now use a different outer remote address, will prevent a different host 
which has "inherited" that outer address from establishing a SA with the 
same peer.

This end-to-end tunnel case was in fact the one that made me concerned.

A host is using some public-access network infrastructure. It gets 
allocated IP address B by a DHCP server.

B contacts server A (www.example.com), and uses Mobike.
As a result of this, A ends up with a (IKE and IPsec) SAs that make 
packets destined to IP address B be subject to the IPsec SA that was 
setup. Thus packets destined from A to B are placed on an ESP tunnel, 
with a destination of B.

The host (B) later moves to a different network, where it is assigned IP 
address C. It uses Mobike to move the IKE and IPsec SAs from using B to 
using C. This (and here is were the document is silent) means that 
packets sent from A to B and placed in an ESP tunnel with a destination 
of C. (In any case, there isn't any text I could find that says that 
there is no residual IKE or IPsec SA or policy that refer to B.)

What happens when another host appears on the initial public-access 
infrastructure and is assigned IP address B by the DHCP server? (This 
could be hours or days after the first host left.)
When that host tries to contact www.example.com, things would fail due 
to the SADB and SPD entries that were created by the original host.

---

The above isn't an issue for a IPsec SG that has static 
allocation/authorization of the inner IP addresses (having a fixed 
binding between the clients CERT and the inner IP address is clearly 
secure). Don't know if there are issues with IPsec SGs that do dynamic 
allocation of the inner IP address.

    Erik

---

From: Joe Touch <[email-masked]>
Date: Thu, 02 Feb 2006 11:46:03 -0800

> might not handle it) where the inner and outer IP addresses are the same.

In that case, it doesn't seem like the inner packet shouldn't be accepted.

The outer packet would be accepted because it is matches an IPsec rule
and is properly signed.

The inner packet, after decapsulation, should match the same rule, at
which point it should look like an unsigned packet, which should be
discarded.

Joe

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 02 Feb 2006 13:54:19 -0800

> some people are using anyway (sort of like BTNS).

Yes, and that is clearly a problem for IKEv2 in general.

> configuration payloads, it can at the same time update the PAD.

The configuration payload allows the client to suggest an IP address as 
well as just getting one assigned by the SG. I don't know if that 
introduces any new issues. But in any case, that isn't a problem 
introduced by the MOBIKE WG.

But is there or is there not an issue introduced by the combination of 
dynamic SG assignment of inner addresses, and MOBIKE changing the outer 
addresses?

Here is an example:

Alice visits the IETF, get X as the IP address, connects to 
sg.example.net. The SG allocates A as the inner IP address for Alice.

Alice moves to another network. Gets Y as the IP address and uses MOBIKE 
to move the SAs from X to Y.

An hour later Bob, who also works at example.net, walks into the IETF 
and is allocated X as its IP address. Bob connects to sg.example.net and 
is allocated B as the inner address.
I assume there is no conflict between Alice's and Bob's SAs on 
sg.example.net, even though they started with the same outer IP address. 
Is that assumption correct?

---

What happens if it takes a while for Alice to walk to the other network 
so that things happen in this order:
1. Alice DHCP lease for the outer address (X) expires
2. Bob shows up at IETF and is allocated IP address X.
3. Bob contacts sg.example.net, and the SG still has the SAs for Alice 
at outer address X. Can Bob setup its SAs? What happens to Alice's SAs 
at the SG?
4. Alice finally arrives at the second network, is allocated IP address 
Y, and contacts the SG and uses MOBIKE to move its SAs from X to Y. Does 
this work as well as if Bob hadn't been around?

There are variants on the above when Alice is walking even slower so 
that one or more of these happen before Bob arrives:
  - The IPsec SAs for Alice on the SG expires
  - The IKE SAs for Alice on the SG expires
  - The "lease" for the dynamically allocated inner address A expires on 
the SG, thus Bob might accidentally end up reusing both the inner and 
the outer IP addresses that Alice had.

All these cases are introduced by MOBIKE, since it enables the reuse of 
the outer IP address by somebody else.

Has anybody done the complete case analysis to check if we need some 
additional recommendations for the protocol behavior of the SG in order 
to ensure interoperability for these cases?

> we should not add text about this to the MOBIKE draft...

I hope the above examples show that there are potential issues for how 
MOBIKE interacts with IKE on the SG.

    Erik

---

From: <[email-masked]>
Date: Fri, 3 Feb 2006 10:56:57 +0200

Erik Nordmark wrote:
> Clarifying question: for this case are you assuming that the 
> inner and outer IP addresses for the tunnel must be different?
> 
> I think tunnel mode can be used (per the RFCs even if
> implementations might not handle it) where the inner and outer 
> IP addresses are the same.

Yes, both addresses can be the same, but that does not really
change the situation much.

> address ownership issues, because the existence of the IPsec SAs,
> which now use a different outer remote address, will prevent a
> different host which has "inherited" that outer address from
> establishing a SA with the same peer.

The address ownership issue is not new to MOBIKE; exactly the same
thing exists in RFC 4301 and 4306.

> A host is using some public-access network infrastructure. It 
> gets allocated IP address B by a DHCP server.
> 

No; it's much more likely that creating the IPsec SA will fail.

As explained in Section 4.4.3 of RFC4301, server A will allow creating
this IPsec SA _only_if the Child SA Authorization Data in its PAD has
an entry "Authenticated-identity-X is allowed to create IPsec SAs with
traffic selectors matching address B".

In reality, this will not be the case, since server A has never heard
about address B before.

In other words, just sending IKEv2 packets using some particular
address does not imply a permission to create IPsec SAs with that
address in the traffic selectors!  Of course, you can configure
your PAD in a way that allows any authenticated peer to create 
IPsec SAs with any traffic selectors, but that would not be very
secure in most environments.

MOBIKE does not change this part of IPsec.  In particular, moving to
some particular address using UPDATE_SA_ADDRESSES, completing a return
routability check, or including an address in the list of additional
addresses do not imply any updates to the Child SA Authorization Data
in the PAD.

Let's not forget that the "UPDATE_SA_ADDRESSES" part of MOBIKE is
basically an optimization to avoid creating new IKE_SAs when addresses
change (and we want this optimization because creating an IKE_SA is 
likely to require user interaction, not because of extra roundtrips). 
If the PAD says "everything goes", an attacker can get the same effect 
by creating a new IKE_SA and new CHILD_SAs, without using MOBIKE at all.

Presumably, the attacker wouldn't be worried about the inconvenience 
of typing the password twice.

> The host (B) later moves to a different network, where it is
> assigned IP address C. It uses Mobike to move the IKE and IPsec SAs
> from using B to using C. This (and here is were the document is
> silent) means that packets sent from A to B and placed in an ESP
> tunnel with a destination of C. (In any case, there isn't any text 
> I could find that says that there is no residual IKE or IPsec SA or
> policy that refer to B.)

Yes, this is what happens (but only if the PAD allowed creating the 
SA in the first place). And this is correct, since according to
server A's PAD, the peer is authorized to "represent" address B
(there's no distinction between a host and extremely small security 
gateway in this case; although for SG, it's likely that instead
of a B1.B2.B3.B4/32 this would be at least /29 or /28).

> infrastructure and is assigned IP address B by the DHCP server?
> (This could be hours or days after the first host left.)  When that
> host tries to contact www.example.com, things would fail due to the
> SADB and SPD entries that were created by the original host.

Creating the IPsec SAs could be succesful only if the PAD also has an
entry "second-authenticated-identity is allowed to create IPsec SAs
with traffic selectors matching address B".  In other words, server A
is configured in a way that both the first and second authenticated
peers are allowed to represent address B.

> secure). Don't know if there are issues with IPsec SGs that do
> dynamic allocation of the inner IP address.

Dynamic allocation of the inner IP address (using configuration
payloads) basically implies that the SG adds a temporary PAD entry
binding the authenticated peer identity and the newly allocated 
inner address.

Best regards,
Pasi

---

From: Jari Arkko <[email-masked]>
Date: Fri, 03 Feb 2006 15:25:07 +0200

>introduced by the MOBIKE WG.
Right.

>Is that assumption correct?
I think so. SA identification needs to happen via SPIs, not
addresses. And for the internal addresses, the policies
for accepting inner address proposals have to be so that A != B,
even without MOBIKE.

>at outer address X. Can Bob setup its SAs? What happens to Alice's SAs 
All of this is fine. Remember that already today we have
to allow a situation where a number of VPN connections
come from the same IP addresses, due to NATs. The SPIs
will be different and the UDP port numbers will be different.
(And when they aren't -- see the appendix in mobike protocol
spec for a warning on how to do your implementation.)

>this work as well as if Bob hadn't been around?
Yes.

>  - The IPsec SAs for Alice on the SG expires
This is fine.

>  - The IKE SAs for Alice on the SG expires
There's nothing special about this. Alice just has to re-establish
her IKE SA, and then this is already from the new address. Nothing
in this entire process affects the inner addresses.

>the outer IP addresses that Alice had.
This might be possible, but again, this is an IKEv2 problem. The
lease might expire even if Alice didn't move, and didn't
implement MOBIKE.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Fri, 03 Feb 2006 16:21:57 +0200

> establishing a SA with the same peer.

Lets talk about this case first without the inner=outer case. Generally,
you can have multiple IKEv2 SAs from the same address, and the fact
that they are from the same address says nothing about their "sameness";
the SAs have their own authorization, keying material, etc. Even if they
come from the same address, they migh be have different inner
address authorizations, for instance.

Secondly, the inner and outer addresses are also unrelated. What's
in the outer address does not necessarily pay any role in the authorization
of specific inner addresses in the child SAs.

Thirdly, MOBIKE is not a fully fledged mobility protocol in the same
way as SHIM6 or MIPv6 are. Specifically, it does not provide its own
stable identifier, but relies instead on the inner addresses for being
stable. This implies that its incompatible with the model where
inner=outer or where transport mode is used. (That does not mean,
however, that it would be impossible to extend it to do these things.)

> might not handle it) where the inner and outer IP addresses are the same. 

It can, but I don't think there's any magic associated with it. Its still
the same old child SA authorization that applies. If your PAD is
correctly set up, you can start with inner=outer and then move
to another location while keeping your inner address the same.

--Jari

---

From: Francis Dupont <[email-masked]>
Date: Sun, 05 Feb 2006 22:40:13 +0100

=> they may be different only. To use the two-space system terms,
the inner address is an identifier and the outer is a locator.
MOBIKE can only change the outer address because the inner one is
a traffic selector. BTW MOBIKE can be extended to transport mode
when handoffs don't imply a traffic selector change (I know at least
two common cases of this).
To come back to authorization: IPsec assumes an authorization about
the content of traffic selectors, so about inner addresses. It is
used in the MIPv6/NEMO context.

Regards

[email-masked]

PS: I'll see further messages of this thread.
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike