Subject: RE: [Ietf-behave] WG last call: draft-ietf-behave-nat-udp-01.txt

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Mon, 9 May 2005 11:13:39 -0700 (PDT)

A lot of text in this 
document is generic to both TCP and UDP but the applicability 
states
<FONT face=Arial 
color=#0000ff size=2> 
"This document only 
covers the UDP Unicast aspects of NAT traversal and does not cover TCP, 
IPSEC, or other protocols.  Since the document is for UDP only, packet 
inspection below the UDP layer (including RTP) is also out-of-scope."
 
We felt this while writing the TCP behavior 
draft where we had to refer to the UDP draft for generic issues.  The 
common requirements should be addressed in a seperate document, that will make 
both the TCP and UDP requirements concise and should not be interleaved in this 
UDP requirements draft.
 
Senthil

From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
[mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Francois 
AudetSent: Monday, May 09, 2005 11:02 AMTo: 'Paul 
Hoffman'; 'Jiri Kuthan'; 'Ietf-behave@xxxxxxxxxxxxxxxxxxx'Subject: 
RE: [Ietf-behave] WG last call: 
draft-ietf-behave-nat-udp-01.txt

Hi Paul, 
Thank you for your careful reading of the document. 
I agree with all your comments and will make the changes 
accordingly unless there is opposition on the 
list. 
Cheers. 
> -----Original Message----- > 
From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [<A 
href="mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx">mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] 
On Behalf Of > Paul Hoffman <FONT 
size=2>> Sent: Monday, May 09, 2005 10:11 > To: 
Jiri Kuthan; Ietf-behave@xxxxxxxxxxxxxxxxxxx > 
Subject: Re: [Ietf-behave] WG last call: > 
draft-ietf-behave-nat-udp-01.txt > <FONT 
size=2>> > At 2:10 AM +0200 4/26/05, Jiri Kuthan 
wrote: > >This is a BEHAVE Working Group Last Call 
for comments > >on draft-ietf-behave-nat-udp-01. 
This last call closes > >Tuesday May 12, 2005. 
Please post any final comments you > >have on this 
draft to this list by that date. > <FONT 
size=2>> **Unnecessary specification of UDP** > 
> In a few sentences in the document, UDP is 
mentioned as if it is the > specific protocol being 
discussed, but TCP could be equivalently > 
substituted in its place. These sentences should be made <FONT 
size=2>> protocol-agnostic if they really are protocol-agnostic, which I 
think > the following are. (Of course, there are 
still many UDP-specific > sections in the 
document!) > > 4.1, first 
sentence, delete "UDP" because the same would be true for <FONT 
size=2>> "TCP" and possibly other protocols. > 
> 4.3, first sentence, remove "UDP" because the 
timers are very > unlikely to be different than TCP 
timers. > > 5.1, first 
sentence, remove "UDP" because the same would be true for <FONT 
size=2>> "TCP" and possibly other protocols. > 
> 7, first sentence, remove "UDP" because the same 
would be true for > "TCP" and possibly other 
protocols. > > 9, first 
sentence, remove "UDP" because the same would be true for <FONT 
size=2>> "TCP" and possibly other protocols. > 
> 11, first two sentences, remove "UDP" because the 
same would be true > for "TCP" and possibly other 
protocols. > > 
> **Editorial** > 
> 1, fourth paragraph, remove "the" and change "off" 
to "of": > "...control off middle boxes..." 
> > 1, last paragraph, RTP and 
other UDP-based protocols are said to run > on top of 
UDP, so change "below" to "above". > <FONT 
size=2>> 4.2.3, first paragraph, "glare" should be "glaring". 
> > 5.1, second bullet, replace 
"...packets to Y..." with "packets to > Y:any ..." to 
make it parallel with the other usage in the section. <FONT 
size=2>> > 7, last paragraph, after "methods" add 
"or protocols that try to be > NAT-aware" to make it 
more general. > > 9, 
section title should be "ICMP Destination Unreachable Behavior" <FONT 
size=2>> because that is the only type of ICMP behavior being discussed in 
the > section. > 
> 10, section title should be "Fragmentation of 
Outgoing Packets" to > emphasize that the entire 
section is about packets flowing in one > 
direction. > > 10.1, end 
of first paragraph, add ", or other reasons" because there <FONT 
size=2>> are many reasons why the MTU is set higher on the NAT. 
> > 10.1, third and fourth 
paragraph, "should" needs to be capitalized. > 
> 10.2, end of first paragraph, add "as specified in" 
before "RFC 1812". > > 11, 
first sentence, change "first or last" to "in any fragment" <FONT 
size=2>> because there may be more than two fragments for the packet. 
> > 13, last paragraph, add "if 
done incorrectly" after "...a DoS > opportunity" 
because many stacks correctly buffer fragments in a > 
manner that doesn't make them susceptible. > 
> > --Paul Hoffman, 
Director > --Cybersecurity Association 
_______________________________________________ > 
Ietf-behave mailing list > 
Ietf-behave@xxxxxxxxxxxxxxxxxxx > <A 
href="https://list.sipfoundry.org/mailman/listinfo/ietf-behave" 
target=_blank>https://list.sipfoundry.org/mailman/listinfo/ietf-behave

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 9 May 2005 11:32:00 -0700 (PDT)

At 11:13 AM -0700 5/9/05, Senthil Sivakumar \(ssenthil\) wrote:
A lot of text in this document is generic to both TCP and UDP but 
the applicability states

"This document only covers the UDP Unicast aspects of NAT 
traversal and does not cover TCP, IPSEC, or other protocols.
There is no mismatch there. In the areas I pointed out, where it says 
"UDP" it actually covers any IP-based protocol. Thus, it is better to 
keep those parts generic.

  Since the document is for UDP only, packet inspection below the 
UDP layer (including RTP) is also out-of-scope."
There is no mismatch there either. I don't think that the current UDP 
requirements draft talks about UDP packet inspection except to say 
"don't do that".

We felt this while writing the TCP behavior draft where we had to 
refer to the UDP draft for generic issues.
Right.

  The common requirements should be addressed in a seperate 
document, that will make both the TCP and UDP requirements concise 
and should not be interleaved in this UDP requirements draft.
That's one option. Another is to make the two drafts parallel, 
pointing out where they differ due to specific differences between 
UDP and TCP.

--Paul Hoffman, Director
--Cybersecurity Association