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

Re: IKEv2 and NAT traversal



Michael Richardson wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> >>>>> "Sami" == Sami Vaarala <sami.vaarala@netseal.com> writes:
>     Sami> The UDP encapsulation draft assumes that IKE packets never begin with
>     Sami> eight zero bytes, whereas in IKEv2 the first eight bytes are the recipient
>     Sami> SPI (cookie) (which is potentially zero).
> 
>     Sami> Since IKEv2 also runs on port 500, this seems like a problem.
> 
>   Since that NAT people insisted on running on the same port using a terrible
> hack to get around a number of imaginary problems, frankly, I think that this
> is the NAT people's problem.

Err.. no. "NAT people" didn't specify this encapsulation draft, at least I deny
any connection to "NAT people" :). "NAT people" produced RSIP, we "IPsec people"
just try to get around the NAT problems the best we can.. (I dislike dividing
people into categories, but that discussion is not for this list.)

>   BTW: if we pick JFK, and the JFK people appear to feel strongly that they
> should run on a different port than 500, all of the "use the same port"
> arguments have become moot.

For almost a year there has been discussion of whether to move this common
IKE and ESPUDP used in the encapsulation draft to a different port than 500,
this is among the authors and hasn't appeared on the list. The reason is that
all the methods, given the constraints, were worse than the method used in 
the current draft.

So what are/were the constraints? The biggest one is that IKEv1 designed
to traverse NATs must start on port 500, because it has no clue whether the
other end can do ESPUDP. So if IKE is then to move to another port after 
finding out that the peer supports ESPUDP and/or that a NAT is actually found
to be present, complicates the protocol enormously. Like, consider what
happens when a port is changed in the middle of an exchange and packets get lost,
like in one alternative we briefly considered.

The second constraint was the attempt to save bandwidth by reducing the amount
of NAT keepalive packets by using one port, instead of a two port model, like
I presented in my first draft a year ago. Unfortunately the constraint of not
being able to change IKE causes ESPUDP traffic encapsulation to be inefficient
and IKE traffic to be efficient, which is the wrong way.

If we are free to consider a model for IKEv2 where the whole protocol is moved
to a port that is non-500, we can devise a much better encapsulation method,
which is described in the encapsulation draft under "5.2. Alternative Encapsulation 
Method 1 - Common Port". This also demands that all IKEv2 implementations support
this method, at least as far as encapsulating IKEv2 packets themselves is concerned.

There's another reason than IKEv2 swapping the cookies to use a port that is
not 500. It's that many of the NAT boxes seem to attempt to do intelligent
stuff for IKE, and this causes them to break when ESPUDP is flowing through them,
because they get confused with 'zero cookies'. My American co-authors have more
exact information about this.

> 
>   Further, I think that IKE has the right to change things with the cookie
> values at any time.

This is an interesting question. I also used to consider a protocol just
a contract between Ari and Bob, who wish to communicate. However, there's
Ned in the middle who wishes to 'do stuff' to the protocol while it is
in transit. If we consider that doing NAT is a valid thing to do, are
Ari and Bob free to change the protocol so that Ned's implementation fails?

Ari


> 
>   You made this kludge, now lie in it.
> 
> ]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
> ] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [
> 
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3ia
> Charset: latin1
> Comment: Finger me for keys
> 
> iQCVAwUBPBZn14qHRg3pndX9AQEsxwP/TXCbRsSK/79/8V52M4c5spYxiij6koky
> HGtnFFG4E/3ox3AeZxbomjRvhuTPfLzZXAxgkzRXUJCN8azlNGqbTxAryIgvbzET
> EdqpwLUIrVyenaTYPDEjfXzy0kXNa0nMg3W8KmlObW0aCVmIcXRwSTkvwIPGSuYA
> IZJNcHlPEGQ=
> =pwYd
> -----END PGP SIGNATURE-----

-- 
"They that can give up essential liberty to obtain a little 
temporary safety deserve neither liberty nor safety." - Benjamin Franklin

Ari Huttunen                   phone: +358 9 2520 0700
Software Architect             fax  : +358 9 2520 5001

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

F(ully)-Secure products: Securing the Mobile Enterprise


Follow-Ups: References: