[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NAT and IPsec
Jari Arkko <Jari.Arkko@lmf.ericsson.se> writes:
> * In terms of requirements, I think we'd be on the wrong path
> if we put much effort in getting all IPsec and IKE modes
> to work. I'd rather have a simple scheme that allows only
> ESP and only TUNNEL mode and only ... than a complex scheme.
> Also - and this may be just my own experience - I consider
> most NAT devices as _hostile_ and therefore approaches like
> RSIP aren't very fruitful (hostile as in made too early
> before RSIP was available or as in owned by an operator who
> wants $ for true IP access). Also, I'm not sure about
> the scalability of RSIP to an operator or large corporation
> NAT.
Depends on definition of complexity, I guess. Nobody has proven to me that
supporting all modes is much more difficult than just esp-tunnel, and I
believe that esp+ipcomp (for example) is definitely a valid combination
worth supporting on slow links.
> * Bernard's draft says in section 7.1 the following: "By adding a
> NAT compatibility mode to IKE/IPSEC, the total time to negotiate
> an IPSEC SA may be increased significantly. For example, when
> an IKE initiator fails to receive a response, it will typically
> need to try again using UDP encapsulation, since the lack of
> response may have been due to the presence of intervening NATs."
> But is this really the case? I could see an implementation
> that tries BOTH standard IKE and NAT-IKE at the same time,
> and uses the one that succeeds. And if both happen to
> succeed as they would in a no-NAT case, a DELETE could
> be performed on the more expensive one afterwards. (A
> scheme that might also be useful for other purposes, such
> as IKE vs. KINK selection.)
Also you could just detect the need during IKE (note that IKE, being normal
UDP traffic, should work between hosts even if there is a NAT in the middle
- at least until P2) and adjust accordingly.
> * Related to the above, would IKE be run directly in the
> UDP encapsulation method, or would it too be encapsulated
> in UDP? If latter, that would offer a very simple way
> for the responder to detect the capability (= existence
> of encapsulation) and need (= outer ip not equal to inner
> ip).
See above.
> * I worry about the denial of service issues for plain
> UDP encapsulation. For instance, if I'd implement
> an UDP tunnel scheme independently from IPsec, and
> used the last incoming packet's src and src-port to
> determine where the next outgoing packet to the
> inner src address should go, then anybody could
> send a fake packet that is later dropped by IPsec,
> but already modified the return address mapping.
> Therefore, it seems that a procedure similar to
> IPsec sequence number updates must be applied here, or
> alternatively the return addresses must be fixed
> at the time of IKE negotiations.
Fixed addresses are the way to go, for various reasons.
> * I saw in the minutes of the last NAT WG meeting that
> somebody proposed the use of L2TP to tunnel IPsec.
> While confidentiality and other properties would be
> satisfied in this approach, I think a DoS would be
> possible here as well: snoop the tunnel IDs and sequence
> numbers, then close the tunnel using a fake IP address.
Yes. As far as I (also) understand it, that's not secure approach at all
(in DoS sense), as L2TP itself has no security features whatsoever.
> * To what extent do we believe that the use of IPsec
> through NAT must be negotiated, and to what extent
> it could just be _configured_? Normally, users would
> know that they are behind a NAT. Can we simplify based
> on such an assumption? Or perhaps we want to apply
> e.g. centrally made corporate policies and not even
> let users configure things like this?
Typical end users are ignorant/<insert politically correct term here if you
live in US>. Expecting them to be able to do more than just select 'yes,
there is an machine I want to talk with securely' is not realistic, I
think.
Thus, this leads to question of whether or not we want to spend twice as
much time detecting both options, or just detect it on the fly. I prefer
later. YMMV.
> * Would it be simpler to just use a client-initiated
> ping as needed rather than a special-case heartbeat
> packets as in two of the drafts?
That's one of the options. However, IPsec SA-level-heartbeat has some
adverse issues that I recall from the recent generic IKE/IPsec-heartbeat
debates and thus won't get to it here.
_Some_ form of mandatory heartbeat is necessary if you really intend to
support 'general NAT case' (as opposed to the rare static {basic NAT,NAPT}
cases).
> * I'm not sure I understand the need for the ESPUDP
> attribute value in Ari's draft. If the connection
> has been determined to be through a NAT, and the
> VIDs have been exchanged - what's left? Or, why
> not use just the ESPUDP value and not VIDs?
There's more than one thing I don't understand in the draft - of course, I
can see that it's a work in progress and I'm keenly waiting for the next
version to see if actual implementation (vrt. guessing how to implement it)
is possible based on it.
Out of curiosity - has anyone actually tried to implement either of the
UDP-encapsulation drafts? (Besides the draft writers themselves, of course)
> * The Stenberg draft has an overhead of 25 bytes (section
> 4.2). This is close to the 28 bytes of an UDP encapsulation.
> Can you comment on whether a a new header format is
> desireable, given the small difference in the outcome?
> Or perhaps the use of this specific header format gives
> some added benefits that can not be realized with just
> using UDP + IP headers?
Basically, that was simply "smallest encapsulation possible when using IKE
version field to detect packets". Most of the fields included (due to extra
space mainly) are not really necessary to support even the most nasty (IMO)
AH-transport case.
Next version will have somewhat less overhead (25->20), and actual content
is just 4 bytes.
> * Why does the Stenberg draft include an unused field
> in the packet encapsulation? And isn't the version
> fields in IKE negotiation sufficient, do we need a version
> field in the traversal tunnel header as well? Isn't
> TOS field thrown away in any case after IPsec has been
> processed?
Because it uses IKE port, there has to be a way for IKE to detect that it
is not a valid packet (reason for version being included). And because IKE
version's 17th byte, there was simply extra space there. However, header
format will change by -01 which should be out in two weeks or perhaps bit less.
> * As a part of the IKE negotiations, the peer
> exchange perceived and local identities (section
> 3.1.2 of the Stenberg draft). Actual IPsec
> packets then contain an envelope that contains,
> among other things, the local address. But why?
> If I receive a packet from the perceived address,
> can't I just replace the local addresses without
> having to restate them in every packet?
Yes, exactly; that's one of the things that changes in -01 draft (see
above for comments).
> Jari
> ----
> Jari Arkko, Oy L M Ericsson Ab, 02420 Jorvas, Finland. Tel +358 9 2992480
> Fax +358 9 2993052. GSM +358 40 5079256. E-Mail: Jari.Arkko@ericsson.com
> Private WWW: http://www.iki.fi/jar. Standard disclaimers apply.
-Markus Stenberg
Follow-Ups:
References: