[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NAT and IPsec
Markus Stenberg wrote:
> 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.
Yeah. Didn't mean to imply that I don't want everything if it comes
at the same price :-) And esp+ipcomp is very valid combination,
also in transport mode. Think wireless.
> > * 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.
Now I finally understand the format. Smart!
However, I'm still wondering *why* it is necessary to use
the IKE port. Does somebody have specific knowledge of
situations where NATs have let IKE through but not other
UDP traffic? Come to think of it, have there been
incidents to specifically block IKE and IPsec but let
other UDP traffic through [implemented by a very hostile
NAT :-) ]? Or perhaps the IKE port is necessary for
firewalling NATs to understand what they're letting through?
What I'm getting at is UDP-only header insertion and non-IKE
port would make the added header sizes smaller as in Ari's
draft. Or do you have specific knowledge why the *encapsulation*
part of that draft doesn't work?
How are you planning to optimize the fake IKE header further?
Can we set I-Cookie to 0 or some predefined value as to mark,
IPsec packets or what? That would cut the overhead to 8...
can't say I like that approach much. Will be interesting to
see this traffic in Ethereal or to specify firewall rules...
Jari
Follow-Ups:
References: