Subject: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt

From: Cullen Jennings <[email-masked]>
Date: Fri, 16 Mar 2007 22:08:17 +0100

My recollection of the last meeting was that we were not going to  
require that NATs MUST forward ICMP packets at all since many  
firewalls don't do that. However, if they do it, we were describe the  
requirements on they needed to do.

I disagree that a NAT must forward ICMP packets at all - we agree to  
try and not specify firewall behavior but also we agree not to  
specify things such that firewalls would automatically not be  
compliant with behave.

RFC 1812 has a lot of stuff in it - NATs are not routers - I doubt  
that a NAT has to meet all the requirements of a router. For  
example,from 1812  -  "A router MUST NOT reassemble any datagram  
before forwarding it."

NATs are not hosts in all senses of 1122 - for example when they  
forward a packet from the outside to the inside they violate
           "When a host sends any datagram, the IP source address MUST
             be one of its own IP addresses (but not a broadcast or

I don't understand how a NAT that does not implement some extension  
contemplated in ICMP-EXT will be able to correctly translate when  
forwarding these. I'm not sure there is a problem here - it may all  
be fine but I don't understand it.

Req-6 - I agree with this but it is confusing on how it is written.  
I'm not sure implementers will be able to understand this.

             multicast address)."

The way 3022 is reference in this draft, it would need to be a  
normative reference.

The terminology is confusing and uses several things we agree not to  
use because it was confusing. For example, "Basic NAT",etc - I see no  
need to this document to introduce any new nat terminology

There is still normative language in things that are not requirements. 

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

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 20 Mar 2007 08:49:21 -0700 (PDT)

Cullen,

Thank you for your comments. Please see my respinses inline.

regards,
suresh

> specify things such that firewalls would automatically not be  

[suresh] I reviewed minutes summary from Dan and feedback from Fernando from
the last meeting. I did not see this comment in ether of them. Anyways, help me
understand why you dont think NATs be required to forward ICMP packets,
perhaps, with an example. Thanks.

> example,from 1812  -  "A router MUST NOT reassemble any datagram  
[suresh] Cullen - NAT is fundamentally a routing device in that it forwards
packets from realm to another. RFC 2663 (section 3) refers this as transparent
routing.

> be fine but I don't understand it.
[suresh] From checking with the authors of draft-bonica-icmp, it seems there
are no known ICMP extensions that use addressing information. The draft-bonica
authors basicaly suggested that a NAT be cognizant of standard ICMP extensions.
This is so, in case there is a future ICMP-extension that might require NAT to
translate.

> I'm not sure implementers will be able to understand this.

[suresh] Has soemthing petered off here? Anyways, if you have better wording
for the requirement, do suggest. Thanks.

> need to this document to introduce any new nat terminology
[suresh] Basic NAT is not new terminology. This is merely adapted from 2663,
right. Is there some usage that is confusing?

> There is still normative language in things that are not requirements. 
[suresh] As for normative language and so forth - Magnus suggested moving 2663
and 3022 to informational, because of the new downref concerns. DO you suggest
not doign so?

Thanks.

regards,
suresh

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 20 Mar 2007 18:59:55 +0200

> requirements on they needed to do.

Hmm, firewalls are about filtering, NATs are about sharing/hiding IP 
addresses. Sure, you can (and often do) have both on the same box.

That noted, unless you decide to filter ICMP traffic purposedly, i.e. to avoid 
breaking UDP hole punching and TCP-S-O in some cases, NATs certainly should 
forward ICMP. And that might be worth discussing.

> specify things such that firewalls would automatically not be

I wouldn't take IETF-firewall-taboo as a reason for taking such a decision.

> example,from 1812  -  "A router MUST NOT reassemble any datagram

Yes, but that's not at all ICMP-specific.

(...)
> be fine but I don't understand it.

Hmm, ICMP extension will always preserve the port numbers within the 
encapsulated transport protocol header (which is to say the first 4 bytes 
past the IP header), unless there is a big amount of IP options (something 
you definitely do not use if you want to be NAT friendly).

I agree however that some corner ICMP cases are just impossible to handle for 
NATs, such as:
- too much IP options prevent seeing the port numbers,
- no encapsulated error packets (NAT using inner port numbers for muxing), 
neither an Echo req/rep packet (NAT using ICMP ID for muxing).

Maybe it should be a "best effort" type-of requirements then??

-- 
Rémi Denis-Courmont

---

From: Fernando Gont <[email-masked]>
Date: Tue, 20 Mar 2007 15:32:49 -0300

>specify things such that firewalls would automatically not be

If you want to get rid of ICMP, you should raise it on the Int-Area 
list, I guess. Killing ICMP is not a decision that is within the 
scope of this WG.

Kindest regards,

-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Saikat Guha <[email-masked]>
Date: Wed, 21 Mar 2007 08:35:43 -0400

On Tue, 2007-03-20 at 15:32 -0300, Fernando Gont wrote:
> >I disagree that a NAT must forward ICMP packets at all
[...]
> list, I guess. Killing ICMP is not a decision that is within the 

Is it acceptable to build a NAT that does not support SCTP? or DCCP?
Just because a NAT is not required to support a particular protocol does
not mean that that protocol has no reason to exist on the Internet.

Apparently, there are NATs that do not support UDP (see Joe Touche's
comments from
http://www3.ietf.org/proceedings/06jul/minutes/behave.html)

I'd suggest clarifying the scope of the document to read:

   This document applies to NATs that translate or originate ICMP
   packets (i.e. almost every NAT).

-- 
Saikat

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 21 Mar 2007 14:57:14 +0200

Agree overall.

> Is it acceptable to build a NAT that does not support SCTP? or DCCP?

Or UDP-Lite.

(...)
> http://www3.ietf.org/proceedings/06jul/minutes/behave.html)

Hmm, I hope such NATs has its own DNS caching server, otherwise I would not 
want to be using such a thing.

-- 
Rémi Denis-Courmont

---

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 21 Mar 2007 06:17:47 -0700 (PDT)

Saikat,

Will a NAT be BEHAVE compliant, if the NAT complies with BEHAVE TCP, but does
not comply with the BEHAVE UDP? I would think not. 

Will a NAT be BEHAVE compliant, if the NAT complies with BEHAVE TCP, and BEHAVE
UDP, but does not comply with the BEHAVE ICMP? I would think not.

NAT vendors support TCP and UDP, as these are the most popular transport
protocols. While there are many transport protocols, there is just one
signaling protocol for IP - That is ICMP. All NAT vendors support ICMP, AFAIK. 

regards,
suresh

---

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 21 Mar 2007 06:36:25 -0700 (PDT)

> forward ICMP. And that might be worth discussing.

[suresh] I agree. 

> you definitely do not use if you want to be NAT friendly).

[suresh] Remi - [ICMP] stipulates that an ICMP error message should embed IP
header and a minimum of 64 bits of the IP payload. IP options are part of IP
header. So, the protocol header would be part of ICMP embedded payload. 

I believe, Cullen is commenting about implementing extensions contemplated in
[ICMP-EXT] (draft-bonica-internet-ICMP) on a BEHAVE compliant NAT device. 

> - too much IP options prevent seeing the port numbers,

[suresh] Please see my comment above. IP options should not be a problem.

> neither an Echo req/rep packet (NAT using ICMP ID for muxing).
[suresh] I dont understand your comment about "no encapsulated error packets".
Why will an ICMP error packet not have embedded IP packet. That is simply a
violation of RFC 792, right?

regards,
suresh

---

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 21 Mar 2007 06:45:28 -0700 (PDT)

> want to be using such a thing.

[suresh] Right. I also wouldnt call it BEHAVE compliant. 

regards,
suresh

---

From: Saikat Guha <[email-masked]>
Date: Wed, 21 Mar 2007 09:59:35 -0400

> not comply with the BEHAVE UDP? I would think not.

It is actually not possible to "comply" with BEHAVE TCP and not with
UDP. See Section 8, behave-tcp:
  "A NAT that supports all of the mandatory requirements of this
   specification (i.e., the "MUST") and is compliant with [BEHAVE-UDP],
   is "compliant with this specification"."

> UDP, but does not comply with the BEHAVE ICMP? I would think not.

That is the issue under debate. If a NAT/Firewall wanted to completely
block TCP/UDP-related ICMP errors in all directions, should that be
allowed. I don't see why not.

If your counter-argument is that such a NAT/firewall would break TCP/UDP
and prevent them from working correctly, then I'd say such a
NAT/firewall would not be commercially viable and therefore does not
matter.

If you think such a NAT/firewall would break a particular TCP/UDP
application, please say which.

ICMP is "nice" to have for TCP/UDP but NOT a MUST. Requiring ICMP
support for TCP/UDP IMHO is a non sequitur.

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 21 Mar 2007 17:04:08 +0200

On Wednesday 21 March 2007 15:36:25 ext Pyda Srisuresh wrote:
> [suresh] Remi - [ICMP] stipulates that an ICMP error message should embed
> IP header and a minimum of 64 bits of the IP payload. IP options are part
> of IP header. So, the protocol header would be part of ICMP embedded
> payload.
>
> I believe, Cullen is commenting about implementing extensions contemplated
> in [ICMP-EXT] (draft-bonica-internet-ICMP) on a BEHAVE compliant NAT
> device.

Yes, I understand that. ICMP-ext will provide at least 128 bytes of the 
original IP packets. So unless you have 104 bytes worth of IP options, the 
port numbers are going to be there. So it should indeed not be a problem.

> > - no encapsulated error packets (NAT using inner port numbers for
> > muxing), neither an Echo req/rep packet (NAT using ICMP ID for muxing).
>
> [suresh] I dont understand your comment about "no encapsulated error
> packets". Why will an ICMP error packet not have embedded IP packet. That
> is simply a violation of RFC 792, right?

I refer to non-error ICMP messages (ping).

-- 
Rémi Denis-Courmont

---

From: Fernando Gont <[email-masked]>
Date: Wed, 21 Mar 2007 15:25:47 -0300

>not mean that that protocol has no reason to exist on the Internet.

ICMP is a core Internet protocol, and it is still required for proper 
TCP operation. While mechanism for PMTUD that does not depend on ICMP 
has been devised, it has not yet been widely deployed.

And even then, ICMP can greatly help to shorten the convergence time 
of the new PMTUD mechanism.

Some implementations (e.g., Linux) implement UDP PMTUD. Thus, killing 
ICMP would kill UDP's PMTUD, too.

Look at the archives of the TCPM WG. For three years we have been 
discussing about ICMP. And you know simply want to kill it at a NAT.

Kindest regards,

---

From: Lars Eggert <[email-masked]>
Date: Wed, 21 Mar 2007 19:36:00 +0100

> allowed. I don't see why not.

I'm not quite sure what ICMP types you define to be included in "TCP/ 
UDP-related", but breaking PMTUD and causing blackholed connection  
attempts are issues.

> NAT/firewall would not be commercially viable and therefore does not

A technical recommendation to prevent breaking transport protocols is  
surely preferable?

Lars

---

From: "David Barrett" <[email-masked]>
Date: Wed, 21 Mar 2007 11:38:16 -0700

> -----Original Message-----
> From: Fernando Gont [mailto:[email-masked]]
> 

Nobody's arguing for the destruction of ICMP.  It's a question of whether
BEHAVE mandates that NATs support a minimal subset of protocols (ICMP, TCP,
UDP) or not.

Both positions are reasonable:
- BEHAVE defines the behavior for several optional protocols
- BEHAVE defines the behavior for several mandatory protocols

I think I fall in the first camp: if a NAT is going to support ICMP (or UDP,
or TCP) at all, it should support it as BEHAVE dictates.  If the NAT for
some reason doesn't support ICMP (or UDP, or TCP), then it need only comply
with BEHAVE for those protocols it chooses to support.

Given that there are more protocols than just ICMP, TCP, and UDP, this seems
the only sustainable path.

-david

---

From: Lars Eggert <[email-masked]>
Date: Wed, 21 Mar 2007 19:40:42 +0100

On 2007-3-21, at 19:36, ext Lars Eggert wrote:
> A technical recommendation to prevent breaking transport protocols  
> is surely preferable?

Let me put that more strongly: BEHAVE is tasked to describe how NATs  
SHOULD behave. If that recommendation breaks IETF transport  
protocols, I'm becoming very concerned.

Lars

---

From: Saikat Guha <[email-masked]>
Date: Wed, 21 Mar 2007 15:04:38 -0400

On Wed, 2007-03-21 at 15:25 -0300, Fernando Gont wrote:
> TCP operation. 

[saikat@sioux tmp]$ grep -ci icmp rfc793.txt 
1

I count 1 instance of icmp in RFC 793 (which admittedly has been updated
many many times but nevertheless AFAIK has not been obsoleted yet). That
one mention is in a Figure that illustrates the protocol stack from
Telnet down to IP.

I do not claim ICMP is not a core protocol. Nor do I claim that present
day TCP does not heavily depend on it. I am merely stating that is is
POSSIBLE to have TCP without ICMP (with degraded performance as it may
be).

> Look at the archives of the TCPM WG

As such, your statement is absolutely correct but entirely depends on
your definition of "proper TCP operation". That definition may differ
for TCPM and BEHAVE.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 21 Mar 2007 16:22:49 -0300

At 04:04 p.m. 21/03/2007, Saikat Guha wrote:

>many many times but nevertheless AFAIK has not been obsoleted yet).

Oh, yeah... from that perspective you can also violate TCP congestion 
control, as it wasn't introduced in RFC793. C'mon... you know better than that.

>POSSIBLE to have TCP without ICMP (with degraded performance as it may

Please explain to me how RFC1191/1981 PMTUD is expected to work if 
you blackhole ICMP.

There are even at least one RFC describing the problem of ICMP 
blackholes... and the IETF had to devise a PMTUD mechanism that could 
survive those blackholes (which has not yet been widely deployed).

But you guys seem to want the IETF to standardize ICMP blackholes. 
I'm amazed....

Kindest regards,

---

From: Saikat Guha <[email-masked]>
Date: Wed, 21 Mar 2007 16:03:38 -0400

> protocols, I'm becoming very concerned.

Agreed. BEHAVE must not make a recommendation that breaks transport (no
one is recommending a NAT not support ICMP). 

Perhaps the chairs can correct me, be from the charter I read:
"generate requirements documents and best current practices to enable
NATs to function in as deterministic a fashion as possible." Which I
read as follows: 1) Identify cases where NATs are non-deterministic. 
2) Make them deterministic. 

Support for PMTUD (TCP or UDP) or the lack thereof, I assume, is a
non-deterministic feature that needs to be addressed. The most precise
statement that captures would be something along the lines of:
    "NATs that support TCP or UDP MUST support the translation of ICMP
     Can't Fragment Error (Type=3,Code=4)"
or even
    "NATs that translate transport protocols such as TCP,UDP,SCTP etc.
     MUST support the translation of ICMP Can't Fragment Error
     (Type=3,Code=4)"
followed by a justification for exactly why.

An overarching statement of the form a NAT MUST support translating all
ICMP messages in all situations IMHO is out-of-scope for BEHAVE, which I
think may be what Cullen was pointing out.

---

From: Lars Eggert <[email-masked]>
Date: Thu, 22 Mar 2007 11:11:23 +0100

> one is recommending a NAT not support ICMP).

OK, now I am confused. Your earlier email said:

> allowed. I don't see why not.

I took "that should be allowed" to mean "that NAT should still be  
labeled as behave-compliant." Which is problematic.

> think may be what Cullen was pointing out.

That ("need not translate all ICMP messages in all situations") is a  
very different statement, and much more aligned with other current  
practice on filtering, e.g., v6ops.

Lars

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 22 Mar 2007 14:57:54 +0100

In no way is the BEHAVE WG trying to kill ICMP - we encourage it's  
use. However, when we chartered this group, we agree to try and write  
our spec in such a way that Firewalls could be "behave compliant".  
Keep in mind that the goal of this work is to get people that build  
combination NATs/Firewalls to build things that are compliant with  
behave and allow developers to build applications that will  
reliability work with in that environment. We are not specifying  
firewall behavior, but we are trying to specify NAT behavior such  
that it is deployable and we find a balance between what would be  
good for applications and what would not break the goals of why the  
NAT was deployed.

So say there is something that firewalls commonly do, such as block  
an inbound ping request. We don't recommend this is a good or bad  
idea in behave - that is out of behave scope - it's about firewalls.  
What some other behave docts have done to get past this is say  "if  
the device forwards the inbound PING, then the address need to get  
properly translated." If it forwards or not, is a firewall topic but  
how the packet gets's translated is a behave topic.

Cullen <as an individual>

---

From: Fernando Gont <[email-masked]>
Date: Mon, 26 Mar 2007 00:07:34 -0300

>how the packet gets's translated is a behave topic.

The WG is issuing requirements for NATs, not for firewalls. (The fact 
that these two functions are usually implemented in the same fox is a 
separate issue).

IMO, as a NAT, is just supposed to do address tranlation, *not* 
filtering. As a result, the core Internet protocols should be 
supported, and the requirements should be stated considering the core 
protocols are supported.

IMHO, if some firewall-like functionality later decides to disable 
ICMP (or some other core protocolol, such as TCP), that is not 
something that this wg should be concerned about..... unless we 
include firewalls in the charter.

Kindest regards,

---

From: Saikat Guha <[email-masked]>
Date: Mon, 26 Mar 2007 03:35:16 -0400

On Mon, 2007-03-26 at 00:07 -0300, Fernando Gont wrote:
> The WG is issuing requirements for NATs, not for firewalls.

Given a mutually exclusive choice between either being BEHAVE complaint
or having firewall functionality, vendors will ignore BEHAVE
requirements. Search the BEHAVE archives for Linksys's reaction to the
endpoint filtering requirement posted by Cullen around summer'05.

For BEHAVE to have any impact, requirements *MUST NOT* be mutually
exclusive with reasonable firewall functionality.

Allowing or disallowing ICMP on a local network is a policy issue for
the site. This site policy is out-of-scope of BEHAVE. What IS in scope,
as Cullen said, is specifying how those packets are to be translated if
site policy permits.

---

From: Lars Eggert <[email-masked]>
Date: Mon, 26 Mar 2007 10:13:22 +0200

> as Cullen said, is specifying how those packets are to be  

If ICMPs were completely advisory, I'd agree, but they aren't (yet).  
Some ICMP messages are needed for the correct operation of transport  
protocols (must fragment), others are increasing efficiency  
(unreachables, etc.)

One way to capture this would be to say "a NAT that translates  
transport protocol X SHOULD also translate ICMP messages Y and Z,  
because otherwise <problem happens>".

Lars

---

From: Saikat Guha <[email-masked]>
Date: Mon, 26 Mar 2007 10:28:53 -0400

> because otherwise <problem happens>".

Agreed. I actually meant ICMP support for query-response pairs (ping,
timestamp request etc.) should be optional.

Old text:
   REQ-1: A NAT device MUST permit ICMP query based applications to be
   initiated from private hosts to the external hosts. 
   a) NAT mapping of ICMP Query identifiers SHOULD be external host 
   independent.

Suggested new text:
   REQ-1: If a NAT device permits ICMP query based applications to be
   initiated from private hosts to the external hosts, then the NAT 
   mapping of ICMP Query identifiers SHOULD be external host 
   independent.

As for Section 4 (handling ICMP errors earned from the network), suggest
adding:

REQ-X: A NAT device that translates TCP packets MUST translate ICMP
       Can't Fragment (Type=3,Code=4) errors.