Note: RFC 2267 has been superseded by RFC 2827
You are correct, RFC2827 is not a standard but it is a Best Current Practice (BCP0038)
which could be used as a precedent in a lawsuit if it came to that. RFC2827 is about
ingress filtering for backbones rather than egress filtering for ISP's but the rules
are similar. It is just which side of the peering point you are looking at.
Egress filtering would require a lot less horsepower then ingress filtering because
the border router already has routing tables for what IP blocks it accepts traffic.
Using this on source address of outgoing traffic adds not much more memory overhead
(although it does add more CPU cost). This is just applying routing rules to outgoing
traffic as well as incoming traffic rather than doing any censoring.
The golden rule of egress filtering: Only allow packets out of your network with
source IP address that you would allow in.
>From heading of RDC 2827
Network Ingress Filtering:
Defeating Denial of Service Attacks which employ
IP Source Address Spoofing
Status of this Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
-----Original Message-----
From: Paul D. Robertson [mailto:[EMAIL PROTECTED]]
Sent: Saturday, June 09, 2001 17:48
To: Bill Royds
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: This is a must read document. It will freak you out
On Sat, 9 Jun 2001, Bill Royds wrote:
> If they sell routing services, they must only route for source
> addresses they control. They are not looking at the content of the
> packets but at the envelope (headers). This is where they, like other
> common carriers, are responsible. When a telephone company sets up a
> long distance call, it is responsible that the Caller ID is either
> correct or blank. But they can't let it be for an exchange that they
> don't run.
But in that case the CNID signal is supposedly generated out of band, and
generated by the carrier's equipment. In this case, the customer is
generating the signaling.
> If the ISP allows non-standard practices (and now with RFC, egress
> filtering is recommended standard), then it is responsible for illegal
> use of its practices. To be covered by common-carrier laws, one has to
> follow standard common carrier protocols.
Lots of RFCs are violated every day- some of them for very good reasons.
If we're to codify RFCs as carrier law, there's probably not an ISP on
the planet who wouldn't be the target of multiple lawsuits.
Anyway, your terminology is wrong- it is not a _standard_, standards
documents are preferaced with STD, and that's important when discussing
carrier responsibilities and legal enforcement.
Indeed from the text of RFC 2267:
"This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited."
and
"All providers of Internet connectivity are urged to implement filtering
described in this document to prohibit attackers from using forged source
addresses which do not reside within a range of legitimately advertised
prefixes."
Note that the term "urged" isn't the typical community "must" language of
most other RFCs that have pieces which should not be violated in
implementation.
Also under Liabilities:
"Filtering of this nature has the potential to break some types of "special"
services"
Seems to indicate that an ISP may draw liability from implementing the
recommendations to the detriment of its pre-existing contracts or level of
service agreements.
I doubt that there's not a defense attourney in the country who couldn't
defend against such a suit.
In any case, the RFC really is about backbone providers doing ingress
filtering on their backbones, and I'm saying that the best solution is
egress filtering at the leaf nodes. Best because (a) it distributes the
performance out to where it's managable, and (b) because it distributes
the proteciton out closer to the source of the illegitmate packet
generation. That makes it signifcantly easier and more possible to
implement for infrastructures with significant mulihomed points of
presence and for places that are aggragating signifcant ammounts of layer
2 data prior to moving it to a layer 3 device (see a.)
Unless I've missed another filtering RFC in there somewhere?
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
