Subject: [BEHAVE] NAT-ICMP summary

From: "Dan Wing" <[email-masked]>
Date: Wed, 4 Apr 2007 17:40:55 -0700

I just returned from a 10-day vacation and caught up on the nat-icmp thread.
To summarize the discussion it seems most of the concern is around some
MUSTs in the existing document.  What seems needed is "If the device's
policy permits doing ___, then do it this way".  So I have made proposed
changes to three of the requirements in nat-icmp.  Please read these and
comment back to the list.

---
1. Change to Req-1:

OLD:
   REQ-1: A NAT device MUST permit ICMP query based applications to 
   be initiated from private hosts to the external hosts.

NEW:
   REQ-1: A NAT device SHOULD permit ICMP query based applications to
                       ^^^^^^
   be initiated from private hosts to the external hosts.

---
2. Change to Req-4:

OLD:
   REQ-4: If a NAT device receives an ICMP error packet from external
   realm, and the NAT does not have an active mapping for the embedded
   payload, the NAT SHOULD silently drop the ICMP error packet.  If
   the the NAT has active mapping for the embedded payload, then the
   NAT MUST do the following prior to forwarding the packet.

NEW:
   REQ-4: If a NAT device receives an ICMP error packet from external
   realm, and the NAT does not have an active mapping for the embedded
   payload, the NAT SHOULD silently drop the ICMP error packet.  If
   the the NAT has active mapping for the embedded payload, 
   and local policy permits, then the
   ^^^^^^^^^^^^^^^^^^^^^^^^^
   NAT MUST do the following prior to forwarding the packet.

---
3. Change to Req-5:

OLD:
   REQ-5: If a NAT device receives an ICMP error packet from private
   realm, and the NAT does not have an active mapping for the embedded
   payload, the NAT SHOULD silently drop the ICMP error packet.  If
   the the NAT has active mapping for the embedded payload, then the
   NAT MUST do the following prior to forwarding the packet.

NEW:
   REQ-5: If a NAT device receives an ICMP error packet from private
   realm, and the NAT does not have an active mapping for the embedded
   payload, the NAT SHOULD silently drop the ICMP error packet.  If
   the the NAT has active mapping for the embedded payload, 
   and local policy permits, then the
   ^^^^^^^^^^^^^^^^^^^^^^^^^
   NAT MUST do the following prior to forwarding the packet.

---
4. The Security Considerations section should be amended to briefly 
discuss what was intended by 'local policy'.  I suggest:

NEW:
  Unfortunately, ICMP messages are sometimes blocked at network 
  boundaries due to local security policy.  Thus, some of the 
  requirements in this document allow local policy to override
  the recommendations of this document.  Blocking such ICMP 
  messages is known to break some protocol features (most notably 
  Path MTU Discovery) and some applications (e.g., ping, 
  traceroute), and such blocking is NOT RECOMMENDED.

-d

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

---

From: "David Barrett" <[email-masked]>
Date: Wed, 4 Apr 2007 19:54:03 -0500

This sounds really good.

> -----Original Message-----
> From: Dan Wing [mailto:[email-masked]]
> Sent: Wednesday, April 04, 2007 7:41 PM
> To: [email-masked]; [email-masked]; 'Senthil Sivakumar (ssenthil)';
> 'Saikat Guha'
> Cc: [email-masked]
> Subject: [BEHAVE] NAT-ICMP summary
>

---

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 8 Apr 2007 22:28:52 -0700 (PDT)

Dan,

Please see my comments below.

regards,
suresh

>    be initiated from private hosts to the external hosts.
[suresh] Dan - I disagree with this change. NATs are supposed to permit
outbound flows - TCP , UDP  and ICMP. That some firewalls block query messages
is not a reason to change the recommendation. Taking cue from your other
changes below, perhaps, this could be reworded as follows.

NEW':
   REQ-1: When local policy permits, a NAT device MUST permit ICMP query 
   based applications to be initiated from private hosts to the external
   hosts.

>    and local policy permits, then the

[suresh] Once again, this seems directly influenced by firewall policies.
However, given the caveat you state under security considerations section, I am
OK with this.

>    and local policy permits, then the

[suresh] Same as above. 

>   traceroute), and such blocking is NOT RECOMMENDED.
[suresh] This sounds good. Thanks.

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 14 Apr 2007 21:41:04 -0700

>   traceroute), and such blocking is NOT RECOMMENDED.

Just commenting on this one part of the proposed changes - this did  
not seem to  this did not seem to reflect the subtle of what I could  
pull out of the meeting recording and list traffic but I was not in  
the meeting so who knows ...

I think you are stepping into controversial areas here that can  
easily be avoided by just tighten this up a bit. Many people feel  
that blocking some ICMP messages is recommended - just not ones that  
break things. Now the what should be blocked is a firewall issue out  
of scope of this WG but we would like to not automatically make  
firewall non compliant with this. I think that what you should say  
here is that this draft recommends particular ICMP messages in  
particular situations that the NAT SHOULD NOT block. The  
recommendation of what ICMP message need to work for UDP and TCP our  
covered in theses documents - here you should just have the stuff for  
the ICMP applications.

Cullen <with my individual hat on>