[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

NAT and IPsec


Hi. I've been studying the IPsec through a NAT issue, and
in particular the drafts 

  http://search.ietf.org/internet-drafts/draft-aboba-nat-ipsec-02.txt
  http://search.ietf.org/internet-drafts/draft-huttunen-ipsec-esp-in-udp-00.txt
http://search.ietf.org/internet-drafts/draft-stenberg-ipsec-nat-traversal-00.txt

I have some questions and some issues I'd like to discuss.
Here they are:

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

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

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

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

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

* 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?

* 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?

* 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?

* 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?

* 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?

* 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?

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.
Follow-Ups: