Subject: [Ietf-behave] Comments on draft-ietf-behave-nat-udp-00.txt

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 13 Mar 2005 23:31:18 -0800 (PST)

Francois & Cullen,

Had a chance to review your draft. My comments are largely centered around
terminology and TCP/UDP common concepts. Some are non-standard terms. Some
relate to terms that are not UDP specific and apply to both TCP & UDP. I
believe, terms that apply to both TCP & UDP behave drafts shoudl not be
replicated/redefined in both drafts, rather they should go into a single
behave-gen draft. Likewise, recommendations that relate to IP/ICMP processing
belong in behave-gen draft. Lastly, all behave drafts advising the NAT vendors
should use common terminology so it is not confusing when switching between the
behave documents. As such, I believe, all behave drafts shoudl refer a single
behave-gen draft that centralizes all the behave terminology.

My detailed comments below.

1. Terminology and Common concepts
 
Section 4 (NAPT behavior) - This whole section describes generic NAT issues.
Instead, this shoudl refer the behave-gen draft.

Section 4.1 describes the translation behavior in terms of "External NAT
mapping" or "Address and port Mapping" . Why not use the standard term
"Address/port Binding" for this? Port Binding support or the lack of is the
major distinction between Cone NATs and symmetric NAT as far as translation
behavior is concerned. 

As for the filering behavior, section 5 and 5.1 describe "endpoint address and
port dependent", "endpoint address dependent", and "endpoint address and port
independent" behavior in details. My own preference would be to charcaterize
the filterign behavior in terms of ?Port Restricted Cone NAT?, ?Address
Restricted Cone NAT? and ?Full Cone NAT?. But, if you prefer a different
terminology, I understand. We should probably poll the list on this. In either
case, I believe, the characterizations shoudl be centralied in a single
behave-gen draft.

Section 4.1 defines "Arbitrary" and "Paired" Address Pooling ? These are
apparently new terms to describe dynamic address bind and static address
binding. Why not reuse the existign terms?

Section 4.2 discusses "Port Asisgnment" behavior, "Port preservation" behavior
, "port overloading" etc. All these concepts are not UDP specific (and have
been discussed in TCP draft as well). As such, this is another set of terms
that should be centralized in behave-gen draft. Same goes with discussion of
Well-known ports, registered ports, dynamic ports etc.

Sections 4.3 & 4.4 discuss "Mapping Refresh Direction" and "Mapping Refresh
Scope". These are new terms and are confusing. The term "Mapping" here is used
to refer to "NAT Sesions" and "Binding" at different times. Why not use
existing terms "NAT Session Idle timeout" and "Bind Idle timeout". The concepts
are identical for both TCP and UDP. The TCP draft uses these existing terms.
Also, a lot of text of was spent describing whether idletime should be
refreshed on inbound packets or outbound packets or both. By definition, the
idletime for a NAT Session should be reset when there is traffic in either
direction of the sessions. Likewise, the idletime for a Bind is reset when
there is at least one NAT Session using the Bind. Vendors may choose to
implement the idletime processing any whichway they like.  I dont believe, the
behave draft needs to go into the implementation details of refresh processing.

Section 7 discusses  Multi Level Nat and Hairpinnign behavior. Once again,
these concepts are not UDP specific. Suggest refering behave-gen draft for
these.

Section 8 refers to ALGs. Section 10 refers to ICMP behavior. Section 11 &
Section refer to IP fragmentation and Path MTU message procssing. All these are
not UDP specific and shoudl be referred from a single behave-gen draft.

2. Recommendations: 

REQ-2 : This says - "It is RECOMMENDED that a NAT have an "IP address pooling"
          behavior of "Paired".  Note that this requirement is not
          applicable to NATs that do not support IP address pooling".

I suspect, this means it shoudl be possible to configure a NAt for static
address maps, so it genrates static address binds. Why? This depends on how the
NAT is configured. If you are saying, it shoudl be possible to configure a NAT
with static address/port maps, why not also say that it shoudl be possible to
configure a NAT with dynamic address maps?  To me, this seems like a
superfluous  requirement.

REQ-3 - This belongs in the behave-gen draft, I believe.

REQ-5: This is UDP NAT Session idletimeout. 

REQ-6: Assumign, you are referign to "NAT Session idel timeout" and ""Bind Idle
timeout", the implementations details of idletime refreshing is not relevant
here, IMHO.

REQ-7: I agree with your recommendation for "Address restricted Cone NAT"
filterign behavior. Here is one reason why I think this makes sense.

TFTP is a popular protocol during bringup time. In TFTP protocol (ref: RFC
1350), the initiating client sends a TFTP request with UDP SrcPort set to XX
and DestPort set to 69. The TFTP servr responds back with SrcPort set to YY and
DestPort set to XX. As you will notice,  the TFTP would not work with a Port
Restricted Cone NAT, but will work with an Address restricted Cone NAT.
Considerign that UDP doesnt enforce a strict session behavior (unlike TCP), I
would suggest that the NATs be recommended to support Address Restricted Cone
NAt behavior rather than Port Restricted Cone NAT behavior. 

REQ-8: This is hairpin translation behvaior. I believem, this shoudl be moved
to    behave-gen draft.

REQ-9 - Well, we discussed this in the WG meeting. I guess, the consensus was
to  enable certain default ALGs (FTP & DNS). 

REQ-10 - Agree with this. But, this needs a hint on what you mean.
Fundamentally, a binding in use by a NAT Session does not change in the middle
o f the NAT Session use, unless the NAT Session has idle timedout and this is
the only NAT Session usign the Bind. So, how exactly shoudl the user enforce
this - in what scenario, did you mean? 

REQ-11,12,13 - They elogn to behave-gen draft.

Thats all for now.

regards,
suresh