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

Re: NAT and IPsec

Markus Stenberg wrote:
> 
> 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.

There's no reason why our draft couldn't support UDP+ESP+IPCOMP. It just wasn't
specified in it, because we had no implementation experience with that combination.

In fact, it should be better for wireless since the encapsulation overhead
is smaller.

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

Right, so? If some company fails to change their firewall when something
new is deployed that needs such changes, well.. it's their problem.

Someone at the interop. told me they actually made something similar
that works along TCP port 80, a couple of years back. Sorry, I fail to remember
who it was. And doesn't Microsoft have some protocol that tunnels everything
along that?

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

Yes. Sucks.. I somehow think IPsec WG should make an effort to do something
to help in this (like specifying draft-ietf-ipsec-notifymsg-03.txt but more).
The solution should NOT be to pass the bucket to IPSP WG, althought there
is surely a need for it too.

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

I've been thinking that someone should make a patch to Ethereal that
would enable it to look inside AH or ESP/NULL. That's somewhat hard, but
doable with some innovative guesswork. (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
Follow-Ups: References: