(coffee != sleep) & (!coffee == sleep)
Donald.Smith at qwest.com gcia
-----Original Message-----
From: Warren Kumari [mailto:warren at kumari.net]
Sent: Friday, September 26, 2008 10:39 PM
To: Smith, Donald
Cc: Joel Jaeggli; opsec wg mailing list
Subject: Re: [OPSEC]
http://www.ietf.org/internet-drafts/draft-kumari-blackhole-
urpf-00.txt
On Sep 11, 2008, at 3:00 PM, Smith, Donald wrote:
First let me say this is valuable work and it is well done.
It should be accepted as a WG document.
Cool, thanks...
Minor grammer issue:
3: A BGP policy is configured on all routers that have the discard
route so that routes announced with with the community [IANA -
INSERT
REGISTERED COMMUNITY HERE] will have their next hop set to the
discard address.
Too many "with"s.
It suffers from inconsistent use of the following teams
which appear
to
mean the same thing I recommend Remote Triggered Black Hole
filtering
but which ever term is used should be used consistently.
I *think* that I have caught all occurrences of this -- the term
"Remote Triggered Black Hole filtering" made the document feel very
long, so I am using the acronym "RTBH filtering". Please
let me know
if I missed any (other than where I define it in the Abstract and
Introduction.)
This is nearly impossible and removes some of the resilency of the
internet.
Most Peers can not filter announcements from other peers to a specific
set of cidr blocks.
If we started filtering, lost a link, had a customer come up on their
backup link with another carrier we would allow them to advertise that
to us. Most dual homed customers would be affected in a situation like
this. So peers don't filter peers announcments (much).
"While administrators may choose to drop any prefixes they wish, it is
recommended when employing source-based RTBH inter-domain that
explicit policy be defined that enables peers to only announce
source-based RTBH routes for prefixes which they originate."
The cisco and juniper examples only covers destination based RTBH
filtering no urpf statements are included and therefore source based
RTBH is not provided by the example configs. That may have been the
intention of the authors but it wasn't what I expected.
I have included uRPF in the examples (actually I do not have
access to
any lab devices at the moment, so I have not pasted the configs to
make sure that they are correct... )
Does this imply that strict mode urpf can't be used for source based
RTBH?
"In loose mode some vendors also verify that the destination route
does not point to a discard interface."
If so going from strict mode to loose to support source
based RTBH has
some serious security implications.
After having a bit more time to digest your comment, I realized that
once again I was unclear -- if you already have strict (or feasible
path) uRPF deployed, you are fine -- unfortunately some ASes are
unable to deploy uRPF in this manner, but can at least deploy loose
mode uRPF. If these ASes use a vendor that "also verify that the
destination route does not point to a discard interface" they can
still get the source-based RTBH benefits... I *think* hat I have now
done a better job of wording this...
This is how you have it now.
"By combining traditional RTBH filtering with unicast Reverse Path
Forwarding (uRPF [RFC3704]) a network operator can filter based upon
source address. uRPF performs a route lookup of the source address
of
the packet and checks to see if the ingress interface of the packet
is a valid egress interface for the packet source address (strict
mode) or if any route or the source address of the packet exists
(loose mode). If the check fails, the packet is (generally)
dropped.
In loose mode some vendors also verify that the destination route
does not point to a discard interface - this allows source based
RTBH
filtering to be deployed in networks that cannot implement strict
(or
feasible path) mode uRPF."
I think this is more correct, you appear to be mixxing up feasible
path
and loose mode.
"By combining traditional RTBH filtering with unicast Reverse Path
Forwarding (uRPF [RFC3704]) a network operator can filter based upon
source address. uRPF performs a route lookup of the source address
of
the packet and checks to see if the ingress interface of the packet
is a valid egress interface for the packet source address (strict
mode, feasible path), or is THE valid egress interface (strict mode,
active path)
or if any route to the source address of the packet exists
(loose mode). If the check fails, the packet is (generally)
dropped.
In strick or loose mode some vendors also verify that the
destination
route
does not point to a discard interface. This allows source based RTBH
filtering to be deployed in networks that cannot implement strict
mode uRPF but can implement loose mode."
You might even want to drop the entire feasible-paths vs active-paths
and just stick to strict and loose modes. I am not sure the active-
paths
| feasible-paths comes into play.
Unfortunately some networks are unable to deploy even loose
mode uRPF
(due to interesting peering arrangements / scaling tricks (and / or
during convergence) it is possible for a router to receive a packet
and have no route for the source address of that packet) -- I have
spoken to one vendor requesting that they implement yet another uRPF
mode (let's call it "dos-mitigation" mode for now[0]) where the uRPF
check is relaxed even further. The logic basically becomes:
If ((route_exists_for_source) && (next_hop_for_source == DISCARD)) {
(increment uRPF drop counter, drop packet)
} else {
(increment uRPF accept counter, accept packet, normal processing
here...)
}
Interesting.
How about:
If ((next_hop_for_source == DISCARD)) {
(increment uRPF drop counter, drop packet)
} else {
(increment uRPF accept counter, accept packet, normal processing
here...)
}
That would eliminate the route check which I don't think you really
want
in this case.