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

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 1 Apr 2007 15:10:18 -0700 (PDT)

Sorry to be late on this thread. I have been swarmed with my day job work past
few days. My comments inline below.

regards,
suresh

--- Philip Matthews <[email-masked]> wrote:

> 
> On 21-Mar-07, at 19:38 , David Barrett wrote:
> 
> >
> > 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.
> >
> 
> I think David raises a very good point that we need to clear up.
> Personally, I also fall in the first camp.
> 
[suresh] Right, David puts it well and raises a good point. I agree, the BEHAVE
WG is defining requirements for various of the IP protocols

But, the point that Fernando raises is that ICMP is a core signaling protocol
for IP and is required for the proper operation of all IP transport protocols,
not just TCP or UDP. For this reason, it seems, it would not be acceptable to
build a NAT that does not support ICMP, whereas it might be OK to build a NAT
that does not support a certain transport protocol.

My 2c.

regards,
suresh

> Does anyone believe that the WG has already made a decision on this  
> point?
> 
> - Philip
> 
> 
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/behave
> 

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

---

From: EKR <[email-masked]>
Date: Sun, 01 Apr 2007 15:13:07 -0700

Pyda Srisuresh <[email-masked]> writes:

> not just TCP or UDP.

Since lots of Internet firewalls block all ICMP, I think this assertion
is arguable at best.

-Ekr

---

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 1 Apr 2007 17:55:24 -0700 (PDT)

> Since lots of Internet firewalls block all ICMP, I think this assertion

[suresh] Are you saying that some firewalls are configured to block all ICMP -
ICMP queries and ICMP errors, inbound and outbound? That seems flawed. 

Is there an IETF document that recommends this setting to administrators? I can
understand if some firewalls block inbound ICMP queries. But, why are the ICMP
errors blocked? 

We cannot make recommendations based on what some firewall admins do. There are
many admins that block UDP traffci entirely. That does not mean we recommend
NATs to not support UDP packets. 

regards,
suresh

---

From: EKR <[email-masked]>
Date: Sun, 01 Apr 2007 18:25:29 -0700

Pyda Srisuresh <[email-masked]> writes:

> [suresh] Are you saying that some firewalls are configured to block
> all ICMP - ICMP queries and ICMP errors, inbound and outbound? That
> seems flawed.

It's quite common, actually. 

> Is there an IETF document that recommends this setting to
> administrators? I can understand if some firewalls block inbound
> ICMP queries. But, why are the ICMP errors blocked?

Because correlating them to the flows they refer to is a pain
and it's easier to block them directly.

> We cannot make recommendations based on what some firewall admins do.

We certainly can avoid making recommendations that would have the
effect of declaring a large number of firewalls nomcompliant.

> There are

Recommending that someone block X is not the same as not requiring
that someone not block X.

-Ekr

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 2 Apr 2007 09:23:01 +0300

> It's quite common, actually.

It's quite common. Sure. But first, in most case, it blocks pretty much 
everything else too for security reasons (your typical corporate Intranet 
with proxies of all types and only outbound NTP and/or DNS or so allowed).

And if not, it's completely flawed, whether it exists or not. Saying that this 
is bad by forbidding this in BEHAVE specs actually looks good to me. It's not 
like the BEHAVE working group will change or remove these firewalls magically 
by telling they are non compliant. As far as I am concerned, you can still 
continue sell thse boxes - so what are you complaining about?

> and it's easieFrom [email-masked] Mon Apr 02 02:23:12 2007
From: =?iso-8859-1?q?Rémi_Denis-Courmont?= <[email-masked]>
Organization: Nokia TP-SP-SWD
To: EKR <[email-masked]>, Behave WG <[email-masked]>
Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt
Date: Mon, 2 Apr 2007 09:23:01 +0300
Cc: 

> It's quite common, actually.

It's quite common. Sure. But first, in most case, it blocks pretty much 
everything else too for security reasons (your typical corporate Intranet 
with proxies of all types and only outbound NTP and/or DNS or so allowed).

And if not, it's completely flawed, whether it exists or not. Saying that this 
is bad by forbidding this in BEHAVE specs actually looks good to me. It's not 
like the BEHAVE working group will change or remove these firewalls magically 
by telling they are non compliant. As far as I am concerned, you can still 
continue sell thse boxes - so what are you complaining about?

> and it's easier to block them directly.

That's laughable. The original pristine packet headers are inside ICMP errors 
messsages. It's actually easier to match an ICMP error to a flow than a real 
reply packet of some transport protocol.

> effect of declaring a large number of firewalls nomcompliant.

We can. We can also not specify anything. Or we can tell the truthm which is 
that this behavior is bad for interactive network usage and application 
developers.

In any case (independant of ICMP BEHAVE), I am very confident that 
some "security" researchers will soon claim that NATs and firewalls MUST NOT 
be BEHAVE-compliant because it allows various kind of traversal scenario to 
work. Just look at some NAT implementors happily boasting about their NAT 
being symmetric to "increase security" (read: prevent everything but HTTP 
from going through).

> > There are
> > many admins that block UDP traffci entirely. That does not mean we
> > recommend NATs to not support UDP packets.
>

Recommending that someone does not block X is not the same as passing a law 
that someone must not block X.

-- 
Rémi Denis-Courmont

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 2 Apr 2007 09:22:58 +0300

List-Por to block them directly.

-- 
Rémi Denis-Courmont

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 2 Apr 2007 09:22:58 +0300

On Monday 02 April 2007 01:13:07 ext EKR wrote:
> > But, the point that Fernando raises is that ICMP is a core signaling
> > protocol for IP and is required for the proper operation of all IP
> > transport protocols, not just TCP or UDP.
>

But then again, if you are serious about isolating your Intranet, you should 
use a firewall, but you should NOT user/rely on a NAT.

Besides, a firewall can do pretty much anything, so it looks ridicule to me 
that we would try to make the spec firewall-compliant (normally, it works the 
other way around). The only way a spec will be compliant with firewalls is 
not to specify anything related to computer networking!

NATs are meant to allow connectivity in case there are not enough IP 
addresses; firewall are security devices. It is a purely incidental practical 
thing that both features are often implemented on the same box.

At the very minimum, an BEHAVE-compliant box MUST NOT break Path MTU discovery 
(in particular not require TCP MSS clamping, which can only fix TCP anyway), 
and it MUST let ICMP errors back to not degrade/break interactive 
connectivity diagnostics -> user experience.

-- 
Rémi Denis-Courmont

st: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/behave>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

On Monday 02 April 2007 01:13:07 ext EKR wrote:
> > But, the point that Fernando raises is that ICMP is a core signaling
> > protocol for IP and is required for the proper operation of all IP
> > transport protocols, not just TCP or UDP.
>

But then again, if you are serious about isolating your Intranet, you should 
use a firewall, but you should NOT user/rely on a NAT.

Besides, a firewall can do pretty much anything, so it looks ridicule to me 
that we would try to make the spec firewall-compliant (normally, it works the 
other way around). The only way a spec will be compliant with firewalls is 
not to specify anything related to computer networking!

NATs are meant to allow connectivity in case there are not enough IP 
addresses; firewall are security devices. It is a purely incidental practical 
thing that both features are often implemented on the same box.

At the very minimum, an BEHAVE-compliant box MUST NOT break Path MTU discovery 
(in particular not require TCP MSS clamping, which can only fix TCP anyway), 
and it MUST let ICMP errors back to not degrade/break interactive 
connectivity diagnostics -> user experience.

-- 
Rémi Denis-Courmont

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 2 Apr 2007 05:49:24 -0700 (PDT)

Right. I fully agree with Remi's comments.

regards,
suresh

---

From: EKR <[email-masked]>
Date: Mon, 02 Apr 2007 07:47:35 -0700

> with proxies of all types and only outbound NTP and/or DNS or so allowed).

Not so. It's reasonably common for packet filters to (for instance)
pass established TCP but not ICMP. Not all firewalls are proxies.

> continue sell thse boxes - so what are you complaining about?

1. You're making the assumption that I sell such boxes. I don't.
2. What I'm complaining about is that the WG isn't chartered to 
   declare a large swath of the network noncompliant.

> reply packet of some transport protocol.

Doing more work is always more work than doing no work, even if the
work is inherently easy. 

> that someone must not block X.

Yes, but I didn't suggest either of those. Rather, I suggested that
the WG *not* require that it pass X. 

-Ekr

---

From: EKR <[email-masked]>
Date: Mon, 02 Apr 2007 07:51:51 -0700

> use a firewall, but you should NOT user/rely on a NAT.

The problem is that as Greg Lebovitz pointed out in Prague, many
(most?) NATs now provide some sort of access control functionality.
I.e., they are firewalls.

> addresses; 

That's far from the only reason people deploy NATs.

> firewall are security devices. It is a purely incidental practical 

No, it's not.

> At the very minimum, an BEHAVE-compliant box MUST NOT break Path MTU
> discovery (in particular not require TCP MSS clamping, which can
> only fix TCP anyway), and it MUST let ICMP errors back to not
> degrade/break interactive connectivity diagnostics -> user
> experience.

1. The current draft requires that boxes permit ICMP query apps
   (see S 3.1.)
2. You're just asserting this, but I don't find the argument behind
   it very convincing.

-Ekr

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 03 Apr 2007 09:50:15 +0200

> the WG *not* require that it pass X. 

EKR and Rémi,

I guess the problem here is how one writes this up. BEHAVE WG can 
clearly specify a requirement on forwarding and how to do it for ICMP if 
one actually get it past the firewall/filtering behavior. But the 
reality unfortunately is that most ICMP will be filtered away. And I 
guess we need that disclaimer here. But we can't put requirements on the 
filtering because that is not BEHAVE's task. What can be done is explain 
why it is recommend that you forward ICMP messages that clearly can be 
associated with existing flows being passed through the NAT.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 3 Apr 2007 11:32:51 +0300

> pass established TCP but not ICMP. Not all firewalls are proxies.

However common, not passing Packet too big errors breaks about any currently 
deployed TCP stack. And not passing other ICMP errors degrade interactive 
connection diagnostics.

A firewall that blocks *ALL* ICMP *IN ANY CASE* is broken. Full point. Yes, 
that happens, and frequently. The fact that it is a common mistake does in no 
way means that it should be allowed by standards.

Besides, it's not like people are going to rush upgrading their firewalls for 
BEHAVE compliance. I would actually expect that (regardless of ICMP) some 
security "experts" will claim that BEHAVE is insecure. It allows some kind of 
firewall evasion, they'll claim. So IT manager should buy this nice 
symmetric-NAT/firewall combo instead of that BEHAVE-conformant box. And of 
course, the first one will also ship various ALGs for all the hype-of-year 
protocols, and turn out to be plain broken next year.

-- 
Rémi Denis-Courmont