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

Re: NAT and IPsec

Jari Arkko wrote:
> 
> * 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.)

This is basically just what our draft does. An initiator that supports
both ESP and ESP-UDP sends proposals that cover both alternatives.
The main disadvantage is that the proposal lists grow quit large,
and some vendors do not even support large proposal lists (more than 10 
proposals or something).

BTW, if I could get something ADDED to IKE it would be this: allow
the specification of 
- Lifetime MIN, MAX values allowed by X
- In proposal lists, allow defining in one place a thing like
  "either X, Y or Z" is allowed here, rather than having to explode
  the whole thing
- Allow specification of "I don't care about X" for many things X
Of course, there's not much chance of this happening. ;)

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

You might do wisely to read through a patent application made by SSH
and Tatu Ylonen that concerns this issue. You can find it here:

  http://l2.espacenet.com/dips/bnsviewer?CY=fi&LG=fi&DB=EPD&PN=EP1036460&ID=WO+++9935799A2+I+
  http://l2.espacenet.com/dips/viewer?PN=AU1879599&CY=fi&LG=fi&DB=EPD

One point to note is that what is specified in the Stenberg draft
MOST CLEARLY falls under this patent application. Here's a paragraph
from that patent application (copied by hand):

 To compensate for transformations at the receiving node, the receiving node applies
 reverse transformations to the received data before computing the MAC. Thus, the
 sending node will send a packet that has a correct MAC, and the receiving node will
 convert the packet to the form sent by the sending node before verifying the MAC.

Here's a sentence from the Stenberg draft:

   Decapsulation occurs
   before IPsec processing, and it copies values from the envelope to
   the real packet and discards the envelope.

As our draft specifies a method that does not make correcting packet transformations
BEFORE verifying the MAC, it is currently my belief that we do not 'infringe'
on this patent application. Instead, we make a packet transformation after MAC
checking as ordinary NAT boxes do. Yes, I know that claims are what counts, so I read
through them and still believe in this.

One thing that follows, is that AH cannot be made to pass NAT without 'infringing'
on this patent application.

Note that I have no lawyer training, so I'm not qualified in reading lawyer talk.
You MUST NOT use anything that I said to guide your legal decisions about using
or not using our draft. Or for anything else. In fact, I never wrote anything,
so you never read anything ;).

I think I'll probably specify something to the effect in a future draft version 
that the initiator sends the original IP address and port it used. Having these
makes the most complex part of our draft simpler, i.e. the determination of whether
NAT exists along the route. The current version only makes an educated guess, as
specified in our draft. 

Question:
  What would be the best way to transport original IP address / port information
  in the first IKE packet (of any phase I)? I think private payloads are out,
  since one can't send them before a VID from the other end is received. Right?

Ari

-- 
Ari Huttunen                   phone: +358 9 859 900
Senior Software Engineer       fax  : +358 9 8599 0452

F-Secure Corporation       http://www.F-Secure.com 

F-Secure products: Integrated Solutions for Enterprise Security
References: