Subject: [BEHAVE] Re: [Ietf-behave] Comments on draft-ietf-behave-nat-icmp-01

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 9 Nov 2006 07:23:45 -0800 (PST)

Philip,

Sorry, I missed your e-mail when it was posted. For some reason, I did not see
this in my inbox until a kind soul refered me to it. Anyways, sorry for the
delay. Please see my responses below inline.

regards,
suresh

> >X-ClientAddr: 72.232.205.74
> >From: Philip Matthews <[email-masked]>
> >Date: Tue, 31 Oct 2006 16:25:03 -0500
> >To: Bryan Ford <[email-masked]>, Senthil Sivakumar <[email-masked]>,
> >         Saikat Guha <[email-masked]>,
> >         Pyda Srisuresh <[email-masked]>
> >X-Mailer: Apple Mail (2.752.2)
> >X-magma-MailScanner-Information: Magma Mailscanner Service
> >X-magma-MailScanner: Clean
> >X-Spam-Status:
> >Cc: Dan Wing <[email-masked]>, Behave WG <[email-masked]>
> >Subject: [Ietf-behave] Comments on draft-ietf-behave-nat-icmp-01
> >X-BeenThere: [email-masked]
> >X-Mailman-Version: 2.1.9
> >List-Id: IETF Behave WG <ietf-behave.list.sipfoundry.org>
> >List-Unsubscribe:
> <https://list.sipfoundry.org/mailman/listinfo/ietf-behave>,
> >        
> <mailto:[email-masked]?subject=unsubscribe>
> >List-Archive: <http://list.sipfoundry.org/archive/ietf-behave>
> >List-Post: <mailto:[email-masked]>
> >List-Help: <mailto:[email-masked]?subject=help>
> >List-Subscribe: <https://list.sipfoundry.org/mailman/listinfo/ietf-behave>,
> >         <mailto:[email-masked]?subject=subscribe>
> >Sender: [email-masked]
> >X-Greylist: IP, sender and recipient auto-whitelisted, not delayed 
> >by milter-greylist-2.0.2 (venus.xmundo.net [201.216.232.56]); Tue, 
> >31 Oct 2006 18:28:48 -0300 (ART)
> >
> >Dan Wing asked me to review draft-ietf-behave-nat-icmp-01.
> >Below are my comments.
> >
> >- Philip
> >

[suresh] Thank you for reviewing.

> >Major comments
> >==============
> >
> >* (Section 3.2)
> >    Is the query session freed up when the query response is received
> >by the NAT,
> >    or does it stay active for the duration of the timer? If the former,
> >    then the case for having having the mapping of the query identifier
> >    be endpoint-independent seems weakened.
> >

[suresh] ICMP query request/response sequence is similar to the UDP datagram
request/response sequence. As such, the ICMP query session idle timeout is
similar to the UDP session idle timeout.

> >* In section 4.2.2, the document contains the following paragraph
> >           "In the outer header, the destination IP address will remain
> >            unchanged, as the IP addresses for Host-x is already in 
> > the external
> >            domain. If the ICMP error message is generated by Host-y, the
> NAT
> >            a NAPT device must simply use the NAT Session to translate the
> >            source IP address Host-y to Host-y'. However, if the ICMP error
> >            message is originated by the intermediate node Router-y, and the
> >            NAT device is a Basic NAT ([NAT-TRAD]), and it has active
> mapping
> >            for the IP address that sent the ICMP error, the NAT device MUST
> >            translate the source IP address of the ICMP error packet with
> the
> >            public IP address in the mapping. Otherwise, the NAT device MUST
> >            simply use its own IP address in the external domain to
> translate
> >            the source IP address."
> >    It took me a few re-reads to understand what this paragraph was
> >getting at.
> >    If I understand correctly, it is talking about the address that
> >should be
> >    used as the public IP address in the ICMP Error packet in the case
> >where the
> >    NAT has more than one public address.
> >    If the ICMP packet comes from the host, then the paragraph says that
> >    the choice is easy: use the public IP address in the mapping for the
> >    TCP or UDP session that caused the error.
> >    The problem is when the ICMP error packet comes from an intermediate
> >    router behind the NAT. In this case, the above paragraph talks
> >    about an "active mapping for the IP address that sent the ICMP
> >error".
> >    The question is: What sort of mapping? 

[suresh] Unlike NAPT, a Basic NAT has a pool of public IP addresses and maps a
public IP address from the pool when a private host initiates a new session via
the NAT. Unlike NAPT, which perfroms endpoint mapping, a Basic NAT performs
address mapping. Subsequent to an address mapping, while the mapping is active
on the Basic NAT, the NAT reuses the mapping for all new sessions from the
private host.

I will reword the text to make this clearer. Thanks.

> >                                           Does a mapping for a UDP
> >    or TCP session count? And what if the NAT does not support the
> >    Address Pooling behavior of Paired (which is just a SHOULD in the
> >    BEHAVE-UDP document) -- in this case,  which address is used?

[suresh] Please see my comment above. With a Basic NAT, both TCP and UDP
sessions use the same address mapping. Ports are unchanged from private
endpoint to public endpoint.

> >
> >* Section 6 talks about outbound flows that are rejected by the NAT
> >    and says that the NAT SHOULD send an ICMP message back to the
> >internal
> >    host when this happens.
> >    However, some NAT designers may say "We never reject an outbound
> >flow;
> >    if we get close, we just steal the entry from an existing flow".
> >    By doing this, they may claim to conform to REQ-8, while violating
> >    the spirit of the requirement.
> >    I would like to see the document discuss this issue, and perhaps make
> >    a recommendation discouraging this potential practice.

[suresh] OK.

> >
> >* Should this document mandate support for draft-bonica-internet-icmp?
> >    Note that an early version of this work has been widely
> >implemented in routers
> >    (since about 2000).
> >

[suresh] I havent read the draft. DO any of the existing requirements change by
mandating the support for this? Are there new fields that a NAT has to modify?
Or, are the extensions completely transparent to a NAT device?

> >
> >
> >Minor and editorial comments
> >============================
> >* Section 1 states:
> >         "Even though ICMP is a transport protocol on top of IP, ICMP
> message
> >         processing is often considered an integral of IP and is independent
> >         of other transport protocols. As such, many of the ICMP behavioral
> >         requirements discussed in this document apply to all IP protocols."
> >    Three comments on this:
> >    a) ICMP is not a transport protocol, but a network control protocol.
> >    b) "an integral of IP" --> "an integral part of IP"
> >    c) I don't understand what you are trying to say with this paragraph.
> >       When I review the requirements for ICMP, they seem pretty ICMP-
> >specific,
> >       and not applicable to UDP or TCP or some other protocol running
> >on top
> >       of IP.
> >

[suresh] Fernando made a similar comment on this text. Would the followrded
text work for you? Thanks.

   ICMP is a signaling protocol for IP. ICMP message processing is
   often considered an integral of IP and is independent of other IP
   protocols. As such, many of the ICMP behavioral requirements
   discussed in this document apply to all IP protocols.

> >
> >* In section 3.2
> >         "an ICMP query transiting a NAT device"
> >    Not sure about "transiting". Suggest replacing with
> >         "an ICMP query that transits a NAT device"
> >

[suresh] OK.

> >
> >* In section 4.2
> >         "Section 4.3 of the RFC 3022 describes the various fields within
> >         an ICMP error message  a NAT device translates."
> >    Two comments:
> >    a) Missing a "that" after message.
> >    b) Everywhere else, the document say just "RFC XXXX", not "the RTC
> >XXXX".
> >

[suresh] OK. 
s/message a NAT/message that a NAT/   
s/the RFC 3022/RFC 3022/

> >
> >* Also in section 4.2:
> >         "domains. Whereas, the subnets in the private network ..."
> >    Suggest either changing the "." to a ",", or changing "Whereas" to
> >"By contrast".
> >

[suresh] OK. s/Whereas/By contrast/

> >* And more in section 4.2:
> >         "... to Host-x, let us say that the NAT device assigned a mapping
> of
> >         Host-y' to associate with Host-y in the external network."
> >    This implies that the mapping is just an IP address to IP address
> >mapping,
> >    but in some cases it also involved the Information field.
> >
[suresh] Would the following rewording work for you?

"... to Host-x, let us say that the NAT device mapped the endpoint on Host-y to
an endpoint on Host-y'. "

> >* In section 4.2.2:
> >         "If the ICMP error message is generated by Host-y, the NAT
> >         a NAPT device must simply use the NAT Session to translate the ..."
> >     Delete "a NAPT".
> >
[suresh] Yup. Thanks.

> >* In section 4.3
> >         "By not effecting the NAT Sessions, the NAT
> >         device is able to retain them, even as someone spoofs ICMP error
> >         messages pertaining to the NAT Sessions."
> >    Here "effecting" should be "affecting", but I really suggest
> >    rewording this entire sentence to:
> >         "This ensures that the NAT Session will not be modified
> >         if someone is able to spoof ICMP error messages
> >         for the session."
> >

[suresh] OK.

> >* In section 5
> >         "REQ-7: NAT devices enforcing Basic NAT ([NAT-TRAD]) MUST support
> the
> >         traversal of hairpinned ICMP query sessions. All NAT devices (i.e,
> >         Basic NAT as well as NAPT devices) MUST support the traversal of
> >         hairpinned ICMP error messages."
> >    I suggest replacing this with just
> >         "REQ-7: NAT devices MUST support the hairpin traversal of ICMP
> >messages."
> >    The proceeding discussion mentions why this is a bit more difficult
> >    for Basic NAT devices, but I suggest that the requirement itself
> >be stated
> >    as cleanly and simply as possible.

[suresh] The requirement as stated refers to supporting hairpinning for both
ICMP queries and ICMP messages explicitly. The requirement is also explicit
that hairpinnig support for ICMP queries is is required only for Basic NAT.
Your revised text is not explicit on either of these. 

> >
> >"If the DF bit is not set and the MTU on the forwarding interface
> >     of the NAT device mandates fragmentation, the NAT device must
> >     simply send this fragmented, just as any router does [RFC1812]."
> >         Suggest rewording this as
> >    "If the DF bit is not set and the MTU on the forwarding interface
> >     of the NAT device mandates fragmentation, the NAT device MUST
> >     fragment the packet and forward the fragments [RFC1812]."
> >

[suresh] OK.

Thanks.

regards,
suresh

> >* In section 7.1.1:
> >         "If the DF bit is not set and the MTU on the forwarding interface
> >         of the NAT device mandates fragmentation, the NAT device must
> >         simply send this fragmented, just as any router does [RFC1812]."
> >    Suggest rewording this as
> >         "If the DF bit is not set and the MTU on the forwarding interface
> >         of the NAT device mandates fragmentation, the NAT device MUST
> >         fragment the packet and forward the fragments [RFC1812]."
> >

_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave