Subject: Re: [OPSEC] ICMP filtering (was Re: charter skeleton rev5)

From: Joel Jaeggli <[email-masked]>
Date: Fri, 01 Feb 2008 08:07:44 -0800

Fernando Gont wrote:
> At 02:01 a.m. 31/01/2008, you wrote:
> 
>> I would say that a router that strictly codes to RFC 1812 is a router
>> which can be attacked and used to attack others. As Don mentioned,
>> routers today need a lot more capabilities and reset of expectations.
>>
>> Consideration - a total relook at RFC 1812 - updating it so that all
>> routers behave the same way - in a way that it is safe from attack
>> and cannot be used to attack others.
> 
> The same thing applies to most RFCs, including RFC 1122 (host 
> requirements), the core TCP and IP specifications, and so on. What's 
> really bad is is that people seem to feel happy about it.
> 
> I doubt whether we would ever be able to get consensus to rewrite RFC 
> 1122 or RFC 1812. The older the RFC, the more controversial it turns out to be.

Which is why I think bcp is the proper place to address this for now:

A. operational experience suggests deviation from original requirements
   is wise.

B. making alterations to the base documents supporting ipv4 at this late
   date seems like a non-starter. The time to be hacking alterations
   into ipv4 has long since passed.

> Think about any of the most well known network attacks we have faced 
> in the past (Smurf, SYN-flood, netkill, or whatever), and try to find 
> a reference to them in any IETF RFC. Only since a couple of years ago 
> we have had IDs or RFCs on a few of these issues (ICMP attacks, 
> TCP-based attacks, SYN-floods)... but most of these efforts ended up 
> in Informational RFCs (rather than Standards track)...
> 
> Kind regards,
> 
> --
> Fernando Gont
> e-mail: [email-masked] || [email-masked]
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
> 
> 
> 
> _______________________________________________
> OPSEC mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/opsec
> 

_______________________________________________
OPSEC mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/opsec

---

From: Danny McPherson <[email-masked]>
Date: Fri, 1 Feb 2008 11:13:53 -0700

>    into ipv4 has long since passed.

On the other hand, one might posit that because we've
gained more experience in certain areas, network and
infrastructure security in particular, that it is definitely the
time to make such recommendations and provide the
appropriate guidelines to implementers.

Given that any open communications system is only
going to be as secure as it has to be in order to operate,
and the amount of dust on the referenced documents,
this would seem to be a natural step in the evolutionary
process.

-danny

---

From: "Smith, Donald" <[email-masked]>
Date: Fri, 1 Feb 2008 12:27:27 -0700

One issue with leaving those RFC's unmodified is most customers require their vendors to implement those rfc's AS IS. Most customers don't know enough to tell their vendor which RFC to violate.
 
So how do you address some of the tcp reset vulnerabilities that have been discovered in the last few years? 
 
By requiring your vendors to accept a reset within the window, or permitting icmp packets to terminate sessions?
Those are part of the RFCs. Some of us got lucky because some vendors failed to implement some elements of those RFCs.
 
Next issue how do you know what your vendor did to fix those issues?
There was more then one way to "fix" those issues.
 
[email-masked] giac

________________________________

From: [email-masked] on behalf of Danny McPherson
Sent: Fri 2/1/2008 11:13 AM
To: opsec wg mailing list
Subject: Re: [OPSEC] ICMP filtering (was Re: charter skeleton rev5)

-danny

This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.
_______________________________________________
OPSEC mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/opsec

---

From: Fernando Gont <[email-masked]>
Date: Fri, 01 Feb 2008 18:39:43 -0200

>A. operational experience suggests deviation from original requirements

I think the argument we could make for a BCP (rather than Standards 
track) is that the internet-draft/RFC would be aimed at firewalls, 
rather than routers. Thus, neither RFC 1122 nor RFC 1812 would need 
to be updated (wrt firewalls).

>    into ipv4 has long since passed.

The IETF is supposed to do engineering. And that includes the 
maintenance of the protocols that currently run the Internet. I don't 
think that the possibility that at some point in time IPv6 may 
replace IPv4 should make us comfortable with the fact that many of 
the specs of the protocols that currently run the Internet are more 
than 20 years outdated.

Talk with any implementer that has (or has had) to build a TCP/IP 
stack from scratch, or that at least wants to maintain an existing 
implementation so that it is not vulnerable to trivial (and in many 
cases even "known") attacks. The current situation is at least messy. 
They have to google for vulnerability advisories, look at other 
implementations' source code, google for relevant papers on the 
subject, etc. Much of the security of current TCP/IP stacks depends 
on "undocumented wisdom".

An example of this is NISCC's VU# 532967 (ICMP attacks against TCP). 
The ICMP reset attacks were used at the very least in the mid/late 
90's as IRC nukes. Nobody documented them. Nobody proposed 
counter-measures. Ten years later, we had BGP routers & VoIP systems 
vulnerable to these attacks. Then, when this issues was discussed in 
some mailing-lists, guess what many of the comments were: "Filter all 
ICMP!" (talk about breaking PMTUD, at least).

I don't think our response to these issues should be "We will not 
work on this issues because at some point in the future IPv4 may get 
replaced with IPv6".

That said, considering that updating some RFCs may *politically* be a 
non-starter, IMHO it is a good thing that at least we document these 
issues and possible work-arounds in some Informational or BCP RFCs.

Kind regards,

---

From: Roland Dobbins <[email-masked]>
Date: Sun, 3 Feb 2008 09:08:21 +0700

On Feb 2, 2008, at 3:39 AM, Fernando Gont wrote:

> is that the internet-draft/RFC would be aimed at firewalls, rather  
> than routers.

Why the artificial (and meaningless, IMHO) distinction?  The desired  
behavior ought to be exhibited by any device which filters packets,  
including routers, ought it not?

-----------------------------------------------------------------------
Roland Dobbins <[email-masked]> // 408.527.6376 voice

	Culture eats strategy for breakfast.

            -- Ford Motor Company

---

From: Fernando Gont <[email-masked]>
Date: Sun, 03 Feb 2008 04:14:44 -0200

At 12:08 a.m. 03/02/2008, Roland Dobbins wrote:

>Why the artificial (and meaningless, IMHO) distinction?

It's "conceptual", not "artificial". A router is a device that 
*forwards* packets. Here we are talking about *filtering* packets.
For that same reason, we have RFC 1122 for hosts *and* RFC 1812 for 
routers, even when in most cases a router (as a "device") will also 
behave as a host for some functions.

>The desired

No. We are not changing ICMP or IP. We are simply providing advice on 
ICMP filtering. The specs are left unchanged. But, if you have a 
packet filtering device, you may follow the advice we'd be providing.

P.S.: For some reason, big vendors seem to be opposed to changes in 
the specs of core protocols, particularly when they have to do with 
security issues. I don't really know if the issue is that they would 
have to provide these upgrades for free (as they are supposed to be 
security fixes) or what. So, in this respect, a positive side effect 
of this direction (BCP or Informational) is that this would be advice 
on what to filter if you decide to actually do it.

Kind regards,

---

From: Roland Dobbins <[email-masked]>
Date: Sun, 3 Feb 2008 18:32:23 +0700

> *forwards* packets. Here we are talking about *filtering* packets.

Lots and lots of routers *filter* packets.  In fact, there are  
probably more routers in the world *filtering* packets than there are  
firewalls doing the same.  There are also may types of filtering,  
including functions such as rate-limiting, which in effect ends up  
filtering packets in many cases.

;>

> behave as a host for some functions.

OK, are you saying that all filtering of packets should be considered  
a 'firewall' function?  In the common parlance, 'firewall' typically  
implies state, while most filtering which takes place on routers is  
stateless.  I don't believe that 'firewall' is suitable as a generic  
appellation for filtering packets.

>> No. We are not changing ICMP or IP. We are simply providing advice  
>> on ICMP filtering. The specs are left unchanged. But, if you have a  

I didn't mean to imply that ICMP or IP were being changed, but that  
indeed this was advice, i.e., BCP-type advice, about behavior that we  
would recommend that all devices exhibit when filtering packets.

            -- Ford Motor Company