Subject: RE: Problem of blocking ICMP packets

From: "Christian Huitema" <[email-masked]>
Date: Fri, 7 May 2004 12:51:56 -0700

> But in between the network, some routers have some firewall 
> configuration so that they will simply drop any incomming ICMP 
> packet without sending any response to the sender. 

Not just routers. Many "host firewalls" will by default drop all
unsolicited ICMP packets. The rational is a variant of security by
obscurity: a host is more secure if its presence cannot be trivially
detected.

The old assumption used to be that if a host has an IP address, it can
receive pretty much any packet sent to that address. The practical
situation we have today is that if two hosts communicate over a given
protocol and port, they can receive packets from the same "five tuple"
but are not guaranteed to receive other packets. This has an important
consequence for many IETF designed protocols, including indeed path MTU
discovery.

-- Christian Huitema

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 7 May 2004 23:03:02 +0200

> consequence for many IETF designed protocols, including indeed path MTU

So you are saying that when a host sends out an IP packet with the DF 
bit set, it's ok for that host (or any system on the path to that host) 
to filter out ICMP "fragmentation needed but DF bit set" messages?

Filtering on protocol/port numbers is a broken concept. When are we 
going to take the time to come up with a *real* security architecture? 
One that allows hosts to receive wanted packets and reject unwanted 
ones, rather than the current one where any correlation to whether a 
packet is wanted and whether it's rejected seems coincidental at best? 
One that at least entertains the possibility of doing something about 
denial of service attacks? And, last but not least, one that allows 
reasonable protocols, carrying desired communication, to function 
without undue breakage?

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 7 May 2004 23:03:02 +0200

---

From: Mark Smith <[email-masked]>
Date: Sat, 8 May 2004 10:42:30 +0930

On Fri, 7 May 2004 23:03:02 +0200
Iljitsch van Beijnum <[email-masked]> wrote:

> > The old assumption used to be that if a host has an IP
> > address, it can receive pretty much any packet sent to that
> > address. The practical situation we have today is that if two
> > hosts communicate over a given protocol and port, they can
> > receive packets from the same "five tuple" but are not
> > guaranteed to receive other packets. This has an important
> > consequence for many IETF designed protocols, including
> > indeed path MTU discovery.
> 
> So you are saying that when a host sends out an IP packet with
> the DF bit set, it's ok for that host (or any system on the
> path to that host) to filter out ICMP "fragmentation needed but
> DF bit set" messages?
> 
> Filtering on protocol/port numbers is a broken concept. When
> are we going to take the time to come up with a *real* security
> architecture? One that allows hosts to receive wanted packets
> and reject unwanted ones,

I've only read the abstract, however Steve Bellovin's
"Distributed Firewalls"
(http://www.research.att.com/~smb/papers/distfw.html) seems to
suggest exactly that.

Interestingly, with all the recent attacks on Microsoft software,
they seem to be going down this distributed firewalls path, where
each host has a firewall. I'm not sure if they are aware of
Steve's paper, or whether it is a result of these worms almost
always seeming to be being able to bypass any network based
security in place anyway. I'd suspect the latter.

Linux and other OSs have already have firewalls built in, so
maybe we are seeing an unplanned and evolutionary transition to
this model.

 rather than the current one where any
> correlation to whether a packet is wanted and whether it's
> rejected seems coincidental at best? One that at least
> entertains the possibility of doing something about denial of
> service attacks? And, last but not least, one that allows
> reasonable protocols, carrying desired communication, to
> function without undue breakage?
>

I've understood that what you have described is the end-goal
of end-to-end, opportunistic encryption and authentication ie.
IPsec. Once the network can't tell what type of traffic it is,
ie. the port numbers (or protocol numbers if IPsec is run in
tunnel mode), these network based firewalls will be useless, and
hopefully will be turned off.

That wouldn't necessarily remedy denial of service attacks
though. I think denial of service attacks will always be possible
if entities can issue traffic to the network in an unregulated or
unidentified manner.

An "IPsec" only Internet would provide a disincentive to DoS, as
I'd presume that it implies that end-points are uniquely
identified, which allows responsibility for these attacks to be
attributed. That may not be a world we want to live in though as
anonimity in communications can also be a useful privacy feature.

In a few respects, DoS attacks and Spam are similar - they rely
on or assume near or absolute source anonimity, and very low
costs of transmission. If, or hopefully when, any solutions are
found to the spam problem, the fundamental methods or techniques
may be able to be applied to DoS attacks.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Sat, 8 May 2004 10:42:30 +0930

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Sat, 8 May 2004 11:34:15 +0930

On Sat, 8 May 2004 10:42:30 +0930
Mark Smith <[email-masked]>

> An "IPsec" only Internet would provide a disincentive to DoS,

Should be "IPsec only" Internet.

---

From: Mark Smith <[email-masked]>
Date: Sat, 8 May 2004 11:34:15 +0930

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 8 May 2004 17:31:48 +0200

> (http://www.research.att.com/~smb/papers/distfw.html) seems to

Yes, this is good stuff. But I don't think distributed firewalling on  
its own is the full answer.

> security in place anyway. I'd suspect the latter.

You are assuming the existence of network based security (ie, a  
traditional firewall or the by-effects of NAT) in the first place.  
Despite the way it seems some times, not everyone uses NAT. And many of  
those that do drop all incoming sessions on a fixed internal address  
because maintaining a list of specific port mappings is too much work.  
Last but not least, there is physical movement of infected systems.  
(Laptop infected at home brought to work.)

The part that I don't get is why a host is running insecure services in  
the first place and then blocks those services. The only reason for  
doing that I can think of is that those services are for host-local  
use. Now obviously it would make lots more sense to make these services  
available to the loopback address only. This is what MacOS does, for  
instance.

> maybe we are seeing an unplanned and evolutionary transition to

There are two issues that aren't dealt with in this model:

- link-local services
- undesired locally initiated communication

The reason why systems like Windows have so many open services is (in  
part) that it's desirable to share files and so on in small work groups  
without having to do much, if any, configuration. Now this is a  
legitimate need, and any security device that gets in the way will  
invariably be disabled in a good percentage of all cases. So what we  
need is a good way to keep local services local. That doesn't fix any  
holes those services may have, but it does mitigate the potential for  
wide-scale abuse. (Those fences on the observation deck at the top of  
the Empire State Building don't cure suicidal tendencies but they do  
make 34rd street safer to walk.) Various approaches come to mind. The  
obvious one is using unroutable address space for these services, but  
that doesn't work because of address translation and the address  
selection problem in the presence of multiple source and/or destination  
addresses. But this can also be done using a TTL hack such as RFC 3682  
uses for BGP, or by setting aside a range of portnumbers for site local  
services and then filter these ports at site edges.

Undesired locally initiated communication can be fixed by Zone Alarm  
like filters, where filtering (also) happens based on which application  
is trying to communicate rather than just the information inside the  
packets themselves. The problem with Zone Alarm is that the local user  
has to decide what applications can and can't do, which is often too  
much to ask from end users. A distributed policy mechanism not unlike  
the one proposed in the paper by Steve Bellovin you cited could help  
here. Especially if the application version is taken into account: as  
soon as a vulnerability is found in an application, it can be blocked  
by changing the policy in a central place. When users upgrade to a  
fixed version of the application they can immediately communicate  
again.

> hopefully will be turned off.

They are of limited use even today, as it's trivial to change port  
numbers if you control both ends of the communication. The only thing  
that's easy to block (or allow) in a current firewall is communication  
towards known services on known ports.

> if entities can issue traffic to the network in an unregulated or

I think it's possible to remedy denial of service by having service  
providers do proxy IPsec AH verification. I haven't found the time to  
write a draft about this so far, though. One of the open questions is  
whether this can be done if correspondents are running regular ISAKMP  
or changes on both ends are necessary. And obviously this requires  
"you-didn't-think-I-could-do-line-rate-crypto-at-10-Gbps-did-you-ha-ha- 
you-stupid-scriptkiddie" type line cards...

> anonimity in communications can also be a useful privacy feature.

I certainly don't want an IPsec-only internet as the extra overhead,  
both in CPU cycles and packet size, is significant. But there are large  
classes of applications that would benefit from IPsec. I'm not worried  
about the privacy aspect: with SSL only the server needs a certificate  
in order to protect the communication. I don't see why this model  
wouldn't work for many applications of IPsec.

> may be able to be applied to DoS attacks.

There is a very fundamental difference: spam can only come in as fast  
as the mail server is willing to accept it, as spammers must play nice  
at least as far as RFC 793 goes. DoS traffic on the other hand, is sent  
entirely unilaterally, the destination has no way to stop it or slow it  
down.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 8 May 2004 17:31:48 +0200

- link-local services

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 09 May 2004 06:43:46 +0900

Mark Smith;

> > Filtering on protocol/port numbers is a broken concept.

Yes, it is.

However, it is merely as broken as PMTUD that we don't need
security discussion to deny PMTUD.

> IPsec.

Back to the original problem, PMTUD depends on the capabilities
of intermediate systems on a path to generate certain ICMP,
generation of which is as complex as fragmentation itself,
that it is not very end to end.

That is, PMTUD is a broken concept.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 09 May 2004 06:43:46 +0900

Mark Smith;

Yes, it is.

						Masataka Ohta

---

From: Mark Smith <[email-masked]>
Date: Sun, 9 May 2004 13:16:15 +0930

On Sun, 09 May 2004 06:43:46 +0900
Masataka Ohta <[email-masked]> wrote:

> > of end-to-end, opportunistic encryption and authentication
> > ie. IPsec.
> 

Radia Perlman, in her book "Interconnections", 2nd edition,
suggests a few alternative methods of performing PMTUD, including
one which wouldn't require feedback from the network, starting at
pg 185.

> That is, PMTUD is a broken concept.

I'm not sure I understand you. Are you saying the idea of PMTUD
is broken, or the way it currently works ?

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Sun, 9 May 2004 13:16:15 +0930

Regards,
Mark.

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 09 May 2004 17:49:07 +0900

Mark Smith;

> one which wouldn't require feedback from the network, starting at

While I won't bother to read a paper material not available here,
I understand it is a very bad idea for a transport or above layer
to interpret a packet loss as a unreliable hint of congestion and
MTU mismatch, especially because initially and upon path changes,
both path congestion and path MTU properties will change.

It is fine that fragmentation of IPv4 is detected and reacted
against by an upper layer.

It is also fine to just send 1280B or smaller IPv6 packets.

> is broken, or the way it currently works ?

The idea is broken. Note that recent super computers are, as
expected long ago, massively parallel ones to be able to
process a lot of interrupts without much performance loss.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 09 May 2004 17:49:07 +0900

Mark Smith;

						Masataka Ohta

---

From: Melinda Shore <[email-masked]>
Date: Sun, 9 May 2004 12:36:35 -0400

> its own is the full answer.

I think it's pretty clear at this point that there is no full
answer, or that if there is it's multi-component and situation-
dependent.  I think that it's pretty clear that we need to make
sure that we're allowing network administrators better control
of their own networks, and distributed firewalling can anchor that
(how security policy is passed around).  Unfortunately I think there
will continue to be a need for firewalls at network borders, at
least towards the edge.  NAT doesn't properly belong in this discussion
but since it's here anyway it should be regarded as part of the
network border packet filtering whatever and probably ought to be
included in participation in enforcing security policy.

Melinda

---

From: Melinda Shore <[email-masked]>
Date: Sun, 9 May 2004 12:36:35 -0400

Melinda

---

From: Matt Mathis <[email-masked]>
Date: Sat, 8 May 2004 18:13:30 -0400 (EDT)

> That is, PMTUD is a broken concept.

This is the whole point of reopening the original pmtud working group.
http://www.ietf.org/html.charters/pmtud-charter.html

See draft-ietf-pmtud-method-01.txt   I quote:

   This document describes a robust new method for Path MTU Discovery
   that relies on TCP or other Packetization Layer to probe an Internet
   path with progressively larger packets.  This method is described as
   an extension to RFC 1191 and RFC 1981.
   ...
   The general strategy of the new algorithm is to start with a small
   MTU and probe upward, testing successively larger MTUs by probing
   with single packets.  If the probe is successfully delivered, then
   the MTU is raised.  If the probe is lost, it is treated as an MTU
   limitation and not as a congestion signal.

This does not require any messages from the network, and works just fine with 
arbitrary middleboxes that either toss over-sized frames or ICMP 
messages.

Comments, suggestions and additions to the text are welcome.  The document is 
not well baked, but there is running code.   There is some (slightly out of 
date) background info at http://www.psc.edu/~mathis/MTU/#pmtud

Thanks,
--MM--
-------------------------------------------
Matt Mathis      http://www.psc.edu/~mathis
Work:412.268.3319    Home/Cell:412.654.7529
-------------------------------------------

---

From: Matt Mathis <[email-masked]>
Date: Sat, 8 May 2004 18:13:30 -0400 (EDT)

Thanks,
--MM--