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

Re: NAT and IPsec



Jari Arkko <Jari.Arkko@lmf.ericsson.se> writes:
> 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.

Yes.. I see that there are currently three different (important) factors
for solutions to this:

 - cases where it applies
 - complexity/overhead
 - ease of deployment (we do _NOT_ want to make anything that requires
 ipv6-level-changes in deployed hardware - thus RSIP is out)

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

It is simply easier to deploy - as IKE will be used on the port in any
case, the approach of 'if IKE works, IPsec works also' makes it a lot
easier to cope with.

(Hypothetical example):

 - corporation X allows only IPsec traffic, i.e. port 500 access to one
 host and ESP traffic to the host (which happens to be a SGW)

 - roaming road warrior of corporation X wants to access the internal
 network of corporation X, and happens to be in DoubleTree hotel somewhere
 in middle of nowhere, behind a NAT

Which of the drafts will work as-is in this case? (-: 

Admittedly, most firewall configrations are (remote=500,local=500) but I
think that anything that can simplify the end user experience without
excessive cost should be done in this type of technology. IPsec as-is
should be as transparent to end user as possible, and I believe the way of
traversaing NAT should be the same.

As rhetorical question - have you ever tried to debug why enduser cannot do
something?

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

I think that you need something beyond UDP header to be able to support all
modes (for example, original header length so that extra options which may
or may not get snipped off can be stored elsewhere).

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

Yes, that. (+4 bytes of header information => 12 byte UDP payload => 20
byte total.

> can't say I like that approach much. Will be interesting to
> see this traffic in Ethereal or to specify firewall rules...

Well, as a side note - it seems that Ethereal barfs equally nicely to IKE
version approach (which it _should_ handle but apparently doesn't). That
reminds me, I have to submit my Ethereal patches for this.. (-:

Firewall rules are not _my_ concern - if why are you letting IKE through if
you do not desire IPsec?

(Excluding some obscure use of AH to make "verifiable but snoopable" Big
Brother-friendly access somewhere.)

> Jari

-Markus

P.S.
 It seems that the IPsec list is dropping my comments - at least I never
 saw it show up.. I guess it's in some form of paranoid
 subscribed-people-only-mode, but I wish it had at least sent me a bounce
 regarding the previous message(s).. :P

--
Markus Stenberg <stenberg@ssh.com> of SSH Communications Security (www.ssh.com)
-- 

John C. Kelley
Computer Scientist
NAILabs at Network Associates, Inc.
Glenwood, MD


Follow-Ups: References: