Re: does mobike support end-to-end use of tunnel mode?

[email protected] wrote:

> 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).

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

> 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.

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?

> None of this is really specific to MOBIKE as such, so I think
> 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