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

Re: NAT and IPsec



At 14:31 19.10.2000 +0300, Jari Arkko wrote:
>
>Hi. I've been studying the IPsec through a NAT issue, and
>in particular the drafts 
>
>  http://search.ietf.org/internet-drafts/draft-aboba-nat-ipsec-02.txt
>
http://search.ietf.org/internet-drafts/draft-huttunen-ipsec-esp-in-udp-00.txt
>http://search.ietf.org/internet-drafts/draft-stenberg-ipsec-nat-traversal
-00.txt
>
>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.

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.

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.

>* Would it be simpler to just use a client-initiated
>  ping as needed rather than a special-case heartbeat
>  packets as in two of the drafts?

There are two UDP ports here... IKE and ESPoverUDP.
With the ping you only keep ESPoverUDP alive.

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

J–rn


Follow-Ups: References: