Re: does mobike support end-to-end use of tunnel mode?
<[email protected]> Wed, 1 Feb 2006 10:31:44 +0200
| Newsgroups | gmane.ietf.mobike |
|---|---|
| Message-ID | <[email protected]> |
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