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

Re: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt


----- Original Message -----
From: "Mason, David" <David_Mason@nai.com>
To: <ipsec@lists.tislabs.com>
Sent: Tuesday, July 10, 2001 7:53 AM
Subject: RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt

>
> Reiterating my point that support for AH adds (unnecessary) complexity:
The
> steps outlined for AH Decapsulation in sections 3.7 and 3.9 will fail the
> ICV verification check for every single packet.  There needs to be a step
> inserted that changes the source and/or destination address in the outer
IP
> header to match the source/destination addresses that were used during the
> encapsulation process. And then for the transport case, after step 5)
change
> the address(es) back.

It is nice to see that someone else also noticed that
a very obvious step was missing!

Did you guys also notice that the basic ESPUDP proposal
itself has changed?! I am surprised that nobody has yet
commented on this fact?!

Allow me to explain......

In the section 4 of draft-ietf-ipsec-nat-t-ike-00.txt, there is mention
of sending original source IP address. The reason it is done is
so that IP header can be corrected in the transport mode. They
explain this in Section 3.1.2 of draft-ietf-ipsec-udp-encaps-00.txt.

    This is in a very _big_ departure from the earlier proposals.
Earlier proposals used built-in NATs and _completely_ discarded
the ESPUDP transport mode.

I quote from draft-huttunen-ipsec-esp-in-udp-00.txt, Section 7.2

   "For this reason, ESPUDP in transport mode is not recommended when
   NAT traversal is required.

  The recommended choice is to use tunnel mode ESP over UDP
  in this situation. Similarly to the Client<->GW case, the contained
  protocols like FTP continue to work."

    Sections 7.3 (similar to 7.2) and 7.4 (IP address assigned by the
remote gateway to the host) also present approaches that are nothing
like what we see in the current draft.

    Similarly the other draft "draft-stenberg-ipsec-nat-traversal-01.txt"
talks about built-in NATs and nothing about reverting to the original
IP address once the packet arrives at the destination.

    Guess what? Built-in NATs are completely gone from the current
proposal.

    Now the question is how come they have suddenly switched to a
very different approach and now ESPUDP in transport mode works
across NATs?

    I'd like to hear an explanation from the authors about what seems
to be outright conflicting statements in their drafts and a big departure
from their original proposal.

    Although I must agree that reversing the effect of NATs is a
brilliant idea. I think it was presented at the San Diego meeting
by someone! :-)

regards,
Jayant
References: