Subject: [BEHAVE] Comments on draft-ietf-behave-nat-icmp-03

From: EKR <[email-masked]>
Date: Thu, 22 Mar 2007 04:16:32 -0700

S 2.
The use of "Query Identifier" is confusing. Please just use the
ICMP term "Identifier"

S 3.1.
   A NAT device MUST permit ICMP query based applications to be
   initiated from private hosts to the external hosts.

This makes practically all firewalls noncompliant. That's not
OK.

S 3.2.
   Below is justification for making the endpoint independent mapping
   for ICMP query IDs a SHOULD [RFC2119] requirement. ICMP Ping and
   ICMP traceroute ([RFC1470]) are two most commonly known legacy
   applications built on top of ICMP query messages. Neither of these
   applications require the ICMP Query Id to be retained across
   different sessions with external hosts. But, that may not be case
   with future applications. In the future, when an endhost 
   application reuses the same Query identifier in sessions with
   different target hosts, the endhost application might require that
   the endpoint identity (i.e., the tuple of IP address and Query
   Identifier) appears the same across all its target hosts.

It's not clear to me that it's a good idea placing additional
requirements on NATs for future hypothetical protocols, given
that there's not exactly a flood of new ICMP-based protocols. 
How many NATs are currently compliant with this?

S 4.1.
   Appendix C of [ICMP-ATK] points out that newer revision end host 
   TCP stacks do not accept ICMP error messages with a mismatched 
   IP or TCP checksum in the embedded packet. NAT devices should
   ensure that ICMP Error payload is not corrupted.

But this is very frequently not possible because of truncation.
You cover this below, but this guidance here seems confusing.

S 4.2.1.
This diagram would be simpler if you omit Router-X, which doesn't
seem to be needed until much later. Simple is good.

S 6.
   Some NAT designers opt to never reject an outbound flow. When a 
   NAT runs short of resources, they prefer to steal a resource 
   from an existing NAT Session rather than reject the outbound flow.
   Such a design choice may appear conformant to REQ-8 below. However,
   the design choice is in violation of the spirit of both REQ-8 and 
   REQ-2. Such a design choice is strongly discouraged. 

Sure, but why is this the best design choice?

S 7.1.2
   This is flip side of the argument for the above section. By virtue
   of the address translation NAT performs, NAT may end up being the
   recipient of "Packet too big" message. 

How is this "by virtue of the address translation"

S 9.
   This document does not introduce any new security concerns related
   to ICMP error message handling in the NAT devices. However, the

This isn't true because REQ1 reverses a security decision that
firewall vendors have made. This needs analysis.

-Ekr

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

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 22 Mar 2007 14:19:09 +0200

> This makes practically all firewalls noncompliant. That's not

We are not specifying firewalls. We are specifying **NATs**.

In fact, most firewalls drop UDP, at least to some extent, as well.

> How many NATs are currently compliant with this?

Probably most of the NATs that handle unknown ICMP types in a sane manner, 
which is to say, as if it were an unknown (or non "multiplex-able") protocol 
running on IP. I don't think this matters a lot though, since indeed, it's 
unlikely we will add new useful ICMP types at this point in time.

> You cover this below, but this guidance here seems confusing.

True. However, NATs should fix the "embedded" IP and layer-4 checksums, which 
is do-able because of IP checksum kindof-linearity (Linux/NetFilter does that 
by the way), i.e. compensate for the checksum difference caused by the 
NAT-caused modifications.

> firewall vendors have made. This needs analysis.

This "decision" was never backed by IETF as far as I can tell. And from the 
discussion on this list, and earlier ICMP blackhole documentation, I would 
even argue that their decision was wrong.

-- 
Rémi Denis-Courmont

---

From: Lars Eggert <[email-masked]>
Date: Thu, 22 Mar 2007 13:36:38 +0100

> unlikely we will add new useful ICMP types at this point in time.

As a datapoint, there are new proposals for ICMP error types, such as  
draft-zhang-btns-icmp-sec-extension, but it's not clear how much  
traction there is.

Lars