<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7652.24">
<TITLE>FW: Filtering ULA?</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>--> going slightly OT here so please excuse...<BR>
<BR>
Well, this means extra annoyance for me because I use loose uRPF<BR>
at the edge (so I can drop RFC1918 sourced traffic), none<BR>
of my hardware supports any bypass acls (GSR Engine >2)<BR>
so I either have to turn it off and revert to plain old<BR>
ACLs (and lose my ability to do source based blackholing)<BR>
or leave it on and not worry about the edge case people<BR>
sending ICMP from unrouted address space.<BR>
<BR>
Its about time ICMP had an overhaul, this is silly,<BR>
what would happen If I sent TOOBIG messages from random sources<BR>
at the same time as a TCP handshake to people, could I<BR>
cause them to reduce their MSS to the point where the connection<BR>
performed badly? What happened if I did this in the reverse direction<BR>
i.e to a popular content site which used PMTUd to all its clients ?<BR>
Could I cause it to perform badly to everybody?<BR>
<BR>
And what about unreachable messages? no checking on those<BR>
, I understand some TCP stacks on seeing these will drop<BR>
the connection (to prevent hanging) and return EHOSTUNREACH/ENETUNREACH to the app,<BR>
what happens if I spray these about referencing sources such as popular sites,<BR>
will these stacks drop their connections (if only during handshake?)<BR>
<BR>
According to RFC1122:<BR>
<BR>
A Destination Unreachable message that is received MUST be<BR>
reported to the transport layer. The transport layer SHOULD<BR>
use the information appropriately; for example, see Sections<BR>
4.1.3.3, 4.2.3.9, and 4.2.4 below. A transport protocol<BR>
that has its own mechanism for notifying the sender that a<BR>
port is unreachable (e.g., TCP, which sends RST segments)<BR>
MUST nevertheless accept an ICMP Port Unreachable for the<BR>
same purpose.<BR>
<BR>
So its great securing TCP using sequence numbers, but the statelessness<BR>
of ICMP makes for an attack vector, no?<BR>
<BR>
<BR>
Dave.<BR>
<BR>
<BR>
Pointers anybody?<BR>
<BR>
------------------------------------------------<BR>
David Freedman<BR>
Group Network Engineering<BR>
Claranet Limited<BR>
<A HREF="http://www.clara.net">http://www.clara.net</A><BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Pekka Savola [<A HREF="mailto:pekkas@netcore.fi">mailto:pekkas@netcore.fi</A>]<BR>
Sent: Mon 9/22/2008 21:00<BR>
To: Iljitsch van Beijnum<BR>
Cc: David Freedman; ipv6-ops@lists.cluenet.de<BR>
Subject: Re: Filtering ULA?<BR>
<BR>
On Mon, 22 Sep 2008, Iljitsch van Beijnum wrote:<BR>
> As for the packets: what if someone generates an ICMP too big message with a<BR>
> ULA source address? That could happen. It would be really bad if people<BR>
> filtered out those packets because that creates PMTUD black holes.<BR>
<BR>
Sometimes folks (usually from a network X using RFC1918 space<BR>
internally) start complaining about network Y breaking PMTUD because<BR>
they filter RFC1918 or some other bogus addresses on the border. As<BR>
if network X had some $DEITY given right to break connectivity by<BR>
exposing RFC1918 addresses to the outside and expecting the others<BR>
to special-case around their brokenness.<BR>
<BR>
If it isn't routed, it's bogus and should be dropped. If you expose<BR>
unroutable address space to outside, don't make it others' fault if it<BR>
causes breakage.<BR>
<BR>
The same applies to ULA space IMHO. (And that's what the spec says as<BR>
well.)<BR>
<BR>
--<BR>
Pekka Savola "You each name yourselves king, yet the<BR>
Netcore Oy kingdom bleeds."<BR>
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings<BR>
<BR>
<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>