Re: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt
"jshukla" <jshukla@earthlink.net> Tue, 10 July 2001 22:50 UTC
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6AMoNm08028; Tue, 10 Jul 2001 15:50:23 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA24599 Tue, 10 Jul 2001 16:30:36 -0400 (EDT)
Message-ID: <001001c10973$2c8a1360$5fb12304@ffb5b>
From: jshukla <jshukla@earthlink.net>
To: "Mason, David" <David_Mason@nai.com>, ipsec@lists.tislabs.com
References: <8894CA1F87A5D411BD24009027EE78381281B7@ROC-76-204.nai.com>
Subject: Re: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt
Date: Tue, 10 Jul 2001 12:04:40 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
----- 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
- I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Internet-Drafts
- RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Mason, David
- RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Mason, David
- RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Mason, David
- RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Brian Swander
- RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Mason, David
- Re: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Bill Sommerfeld
- Re: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Markus Stenberg
- Re: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt jshukla
- Re: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Ramin Ali Dousti
- RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Mason, David
- RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Mason, David
- Re: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Bill Sommerfeld
- RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Mason, David
- RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Brian Swander
- RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Mason, David
- RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Mason, David
- RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Mason, David
- Re: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Markus Stenberg
- RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Brian Swander
- RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Mason, David
- RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Mason, David
- Re: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Bill Sommerfeld
- RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Mason, David
- Re: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Bill Sommerfeld
- Re: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Derek Atkins
- Re: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Derek Atkins
- RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Mason, David
- Re: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Derek Atkins
- RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Mason, David
- RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Mason, David
- Re: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Bill Sommerfeld
- Re: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt jshukla
- Re: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Michael Thomas