[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IKEv2 and NAT traversal
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
[mailto:owner-ipsec@lists.tislabs.com]
> On Behalf Of Ari Huttunen
>
> 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.)
>
Didn't your original draft use RSIP? From the section 6 of your original
draft (expired Jan 2001), it seems to me that it is based on RSIP
principle and UDP encapsulation. So you cannot deny a connection to "NAT
people"! Of course your new drafts have gotten rid of RSIP.
>
> 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.
>
Why does IKE have to move to another port? This is your kludge which
forces you to do nasty stuff like this. Your solution is not a proper
NAT traversal solution and because you use IKE to help in NAT traversal,
you have all these weird problems. To me this solution is as bad as the
port 80 punch thru.
> 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.
>
That brings up another good point. Isn't that solution based on the NAT
boxes (ones with IPsec pass thru) examining the IKE messages and storing
the information about SPI, local host, and remote host? This information
can be used to re-direct the subsequent IPsec packets to the appropriate
local host.
Clearly your proposed solution will break a lot of these NAT boxes and
that is not good!
> >
> > 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.
> >
True!
~Jayant
Trlokom, Inc.
p.s.: BTW, I have notified IETF about your new drafts infringing on our
intellectual property.
Follow-Ups:
References: