Subject: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-04.txt

From: "Francois Audet" <[email-masked]>
Date: Thu, 15 Sep 2005 15:20:49 -0700 (PDT)

Hi all, I want to draw everybody's attention to
draft-ietf-behave-nat-udp-04.

It includes all the changes resulting from WGLC and the Paris meeting.

Many thanks to Bryan Ford, Cullen Jennings and Dan Wing who
helped in finalizing the wording.

The changes are:
- Removal of section 5.2   
- Addition of section 4.4 (including new  REQ-7)   
- Modification to now-REQ-14   
- Adjusted the wording on the ALG requirement 
- Correction of typos and spelling mistakes
- Updated list of references.

> -----Original Message-----
> From: i-d-announce-bounces@xxxxxxxx 
> [mailto:i-d-announce-bounces@xxxxxxxx] On Behalf Of 
> Internet-Drafts@xxxxxxxx
> Sent: Wednesday, September 14, 2005 12:50
> To: i-d-announce@xxxxxxxx
> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx
> Subject: I-D ACTION:draft-ietf-behave-nat-udp-04.txt 
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories. This draft is a work item of the 
> Behavior Engineering for Hindrance Avoidance Working Group of 
> the IETF.
> 
>       Title           : NAT Behavioral Requirements for Unicast UDP
>       Author(s)       : F. Audet, C. Jennings
>       Filename        : draft-ietf-behave-nat-udp-04.txt
>       Pages           : 28
>       Date            : 2005-9-14
>       
> This document defines basic terminology for describing different
>    types of NAT behavior when handling Unicast UDP and also defines a
>    set of requirements that would allow many applications, such as
>    multimedia communications or on-line gaming, to work consistently.
>    Developing NATs that meet this set of requirements will greatly
>    increase the likelihood that these applications will function
>    properly.
> 
> A URL for this Internet-Draft is: 
> http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-udp-04.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> i-d-announce-request@xxxxxxxx with the word unsubscribe in 
> the body of the message.  
> You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings.
> 
> 
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username "anonymous" and a password of your e-mail 
> address. After logging in, type "cd internet-drafts" and then
>       "get draft-ietf-behave-nat-udp-04.txt".
> 
> A list of Internet-Drafts directories can be found in 
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
>       mailserv@xxxxxxxxx
> In the body type:
>       "FILE /internet-drafts/draft-ietf-behave-nat-udp-04.txt".
>       
> NOTE: The mail server at ietf.org can return the document in
>       MIME-encoded form by using the "mpack" utility.  To use this
>       feature, insert the command "ENCODING mime" before the "FILE"
>       command.  To decode the response(s), you will need "munpack" or
>       a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
>       exhibit different behavior, especially when dealing with
>       "multipart" MIME messages (i.e. documents which have been split
>       up into multiple messages), so check your local documentation on
>       how to manipulate these messages.
>               
>               
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
> 
Attachment:
draft-ietf-behave-nat-udp-04.URL

---

From: Saikat Guha <[email-masked]>
Date: Thu, 29 Sep 2005 20:29:54 -0700 (PDT)

> draft-ietf-behave-nat-udp-04.

Regarding endpoint filtering behavior in section 5, the draft says that
a NAT can either filter a packet, or not filter a packet.

Clearly, not filtering a packet implies that is it translated and routed
to the internal host.

What does filtering a packet entail? Options would be to either DROP it
silently, or respond with some ICMP error. Currently, I think the
implicit assumption is that the NAT drops the packet. I am not sure if
the ICMP option has been discussed (and rejected) on the list, but I
would think that ICMP makes more sense.

Justification:
        Consider a VoIP phone that retries for 3 minutes before giving
        up. If the NAT simply drops the incoming request packet, the
        application has _no choice_ but to keep retrying for 3 minutes
        since it does not know if a NAT is actively blocking the packet,
        or if the host is intermittently down. If the NAT responds with
        an ICMP, the application knows that there is a problem and has
        the choice of either aborting early and reporting the error to
        the user within seconds, or continuing to retry for 3 minutes as
        before.
        
        Implicitly (or explicitly) recommending that the NAT silently
        drop the packet and not report an error severely/permanently
        restricts the application's responsiveness since it forces the
        application to guess what happened to the packet. The ICMP gives
        the application a choice.

Justification Against:
        One can make the argument that sending back an ICMP response
        allows an attacker to check whether a host is present at that
        address or not. The same can be said for Internet hosts
        responding to ping messages. RFC 1122 says that an ICMP ECHO
        server MUST be implemented, and MAY ignore _only_ multicast and
        broadcast echo requests. Therefore, RFC 1122 doesn't make a case
        for "stealth" hosts.
        
        Another argument can be that an attacker can send these probe
        packets and find an open mapping by tracking which ports do not
        return an ICMP error. This is NOT the case. If the NAT is
        security conscious (and therefore has "address and port
        dependent endpoint filtering"), then the NAT will filter such
        UDP probes to open mappings and respond with ICMP errors that
        are indistinguishable from the ICMP errors generated for
        non-existing mappings. An attacker cannot infer which mappings
        are open for such NATs. For NATs that are not security conscious
        and aim for application transparency instead (endpoint
        independent filtering NATs), sending back an ICMP makes even
        more sense.

Therefore, I suggest the following text:

REQ-8 b) If a NAT filters a packet, it is RECOMMENDED that it send
         an ICMP error in response. 

The next question ofcourse becomes what ICMP error to send. It would be
Type=3 (Destination Unreachable). As for the sub-code, this has been
discussed earlier on the list with no clear winner: either Code=1 (Host
Unreachable), or Code=10 (Host Prohibited), or come up with a new one
Code=16 (No Route To Destination).

The choice of the Code defines application behavior -- if it is a
"soft-error", then the VoIP application is allowed to retry (for
instance when it is trying to establish STUN). Code=1 is explicitly
designated a soft-error in RFC 1122. Code=10 is left unspecified so it
becomes host dependent as existing stacks treat it
non-deterministically; designating it soft-error now breaks legacy
stacks. If we create a new Code=16, we can explicitly designate it a
soft-error without breaking legacy implementations. 

Thoughts?

-- 
Saikat
-- 
Saikat
Attachment:
signature.asc