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

Re: NAT and IPsec


Joern Sierwald wrote:
> 
> At 14:31 19.10.2000 +0300, Jari Arkko wrote:
> >I have some questions and some issues I'd like to discuss.
> >Here they are:
> >
> >* In terms of requirements, I think we'd be on the wrong path
> >  if we put much effort in getting all IPsec and IKE modes
> >  to work. I'd rather have a simple scheme that allows only
> >  ESP and only TUNNEL mode and only ... than a complex scheme.
> 
> It should be noted that our (huttunen) scheme is a simple as
> it possibly can be.

Almost.. It could have been made somewhat simpler but I was constrained
by a couple of factors. The first factor was the IPR statement that
appears in the Stenberg draft. I made the assumption that SSH had filed
for a patent recently, and I tried not to use methods in my draft that
would not be self-evident for everyone. Another factor is the way
private numbers and payloads are allowed to be used in IKE. Having
now read through that patent application (assuming there is only one),
I'm in a position to create an even simpler draft that according to
my understanding does not infringe on the patent, if there is to be
one of course. This is my best understanding at this time, but I may
of course be wrong. You must not use this paragraph in any legal decision
to use or not use the draft that we've written.

I'll have more to say about this later as I suggest how my draft can
be improved, but for now I'll just go through these messages and answer
some points in them.

> 
> There are a lot of thoughts in the draft, but you have to
> make it work for yourself. It mentions transport mode, yes.
> But we don't even have that ourselves.

Right. The reason there is an attempt to incorporate transport
mode is that some vendors do not implement IPsec tunnel mode
in hosts, as it's not required by RFCs. As we have tunnel mode
in our implementation, we're not actively pursuing in defining
the transport mode. I welcome others to study using the transport
mode. It is possible, but not so easy as tunnel mode.

> 
> You want to configure it, not negotiate it?
> Well, you have to configure it in order to negotiate it, right.
> The only change in negotiation is the 61440 number.
> You don't _have_ to use the VID... It says "SHOULD" in the draft.
> You can use a configuation switch instead.

To my understanding IKE RFCs require that we send a vendor ID 
if we use numbers from private ranges. That is the only real reason
for it. If the number is from a standard range, we could just
throw the VID away.

> >* I worry about the denial of service issues for plain
> >  UDP encapsulation. For instance, if I'd implement
> >  an UDP tunnel scheme independently from IPsec, and
> >  used the last incoming packet's src and src-port to
> >  determine where the next outgoing packet to the
> >  inner src address should go, then anybody could
> >  send a fake packet that is later dropped by IPsec,
> >  but already modified the return address mapping.
> >  Therefore, it seems that a procedure similar to
> >  IPsec sequence number updates must be applied here, or
> >  alternatively the return addresses must be fixed
> >  at the time of IKE negotiations.
> >
> 
> I understand the problem, but you found the solution.
> Change your mapping only after the packet has passed ESP...

I wrote in the draft something to the effect that the source IP address
and port MUST NOT change. As Joern said, it's possible to make it work.
The question is, should the draft allow or disallow such changes?

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: