Good day,
What NSPs do filter packets, and can really deal with DoS and DDoS attacks?
-Abdullah Bin Hamad A.K.A Arabian
The shorter shorter list would be the NSPs that do NOT filter
packets. I can't think of an NSP that does not filter.
--bill
IMO, Commercial ISPs should never filter customer packets unless
specifically requested to do so by the customer, or in response to a
security/abuse incident.
Consumer ISPs are much more likely to have clauses in the AUPs that are
enforced premptively via packet filtering - antispoof filters (honestly,
antispoof filtering is, IMHO, the one expection to my "commercial ISPs
should not filter" rule), port blocks to prevent customers running
servers, outbound SMTP blocks to off-provider systems to stop direct-to-MX
spamming, ICMP rate limiting, et al. All of which are fine by me as long
as they clearly assert their right to do so in their AUP - that is, as
long as there's a comparable provider I can use instead.
-C
IMO, Commercial ISPs should never filter customer packets unless
specifically requested to do so by the customer, or in response to a
security/abuse incident.
We already have BCP 38, which strongly recommends packet filtering on the
customer-ISP edge. There are now two major vendors who have strict mode
uRPF. This which covers 80% of the BCP 38 packet filtering on the
customer-ISP edge. With a few BGP config tweaks, strict mode uRPF can cover
a lot of the last 20% (all those multihomed customers).
Q. What is wrong with BCP 38 filtering?
We also have Loose Mode uRPF that can work on all the ISP edges. While this
was originally done to allow source based remote-triggered black hole
filtering, Loose Mode uRPF does do some sanity checking of the packets. It
drops any packet whose source is not in the global route table. So it is an
effective bogon, RFC 1918, and martin filter on the ISP-ISP edge.
Q. What is wrong with filtering packets with source address that should not
be out there floating on the Net?
The only thing that has been holding up uRPF deployment has been ISP
migrating to images that support uRPF (mostly done) and operational
confidence in the feature (so the operators know it is not going to hose
their network). Both of these are well on their way with more operators
turning on uRPF (Strict or Loose mode). So it is really a matter of time
before we have a lot of uRPF doing packet filtering on the ISP edges.
But, what if you could "strict mode" packet filter on the ISP-ISP side? Lets
say there was a dynamic uRPF filter that checked the source addresses
against the eBGP routes coming into a link. In other words, if the source
address from an ISP does not match the eBGP prefixes coming across from the
peer, the packet would drop. So if some /8 prefixes are filtered on the eBGP
side, they would get dropped on the ISP-ISP peering interface. For example,
if I only send routes from AS X, then any packet whose source address is
outside of AS X (say from AS Y) would not pass the uRPF check - resulting in
a drop. Since this is based on the dynamics of the eBGP prefixes coming
across the peering session, it would allow a "strict mode like" uRPF packet
filtering on the ISP-ISP edge (with all the asymmetry found on the ISP-ISP
edge).
The question is whether this is something people would want as an option. A
uRPF mode that would enforce a peering agreement with dynamic packet
filtering (dynamic is based on the eBGP advertisements that get through the
peering filter).
Barry
Except vendor J doesn't spend much time at the customer edge, and vendor F
seems to think that you should do per-interface RPF with acl's.
Also, vendor J's implementation of loose mode is significantly different
from everyone elses. It seems they mean "is it feasible for this src ip to
be routed to this interface regardless or route selection", not "it is
feasible for this src ip to be routes to any interface on the box". Or to
put it another way, say you peer with someone who sends you 5000 routes,
but you only accept 4000 as best-path. If you feasible filter it, you'll
be allowing src IPs from those 5000 prefixes, not from all 100k+ on the
box. While this is potentially a neat feature, it isn't the same as true
"loose".
Between that and only being able to set strict or feasible for the entire
box and not per-interface, I'd say vendor J's implementation is almost
completely useless at this point.
I'll clarify this...I already noted that antispoof filtering is an exception,
and I'll agree that RPF fits loosely under the antispoofing definition as well,
albiet in the other direction.
-C
But, what if you could "strict mode" packet filter on the ISP-ISP side? Lets
say there was a dynamic uRPF filter that checked the source addresses
against the eBGP routes coming into a link. In other words, if the source
address from an ISP does not match the eBGP prefixes coming across from the
peer, the packet would drop. So if some /8 prefixes are filtered on the eBGP
side, they would get dropped on the ISP-ISP peering interface. For example,
if I only send routes from AS X, then any packet whose source address is
outside of AS X (say from AS Y) would not pass the uRPF check - resulting in
a drop. Since this is based on the dynamics of the eBGP prefixes coming
across the peering session, it would allow a "strict mode like" uRPF packet
filtering on the ISP-ISP edge (with all the asymmetry found on the ISP-ISP
edge).
How would this work for BGP Conditional Advertisement as per page 118 of
"Cisco ISP Essentials?"
Hank
Might be of interest, BBC-2 has a story on the impact of Sept-11 on comms
networks (7:30 GMT).
Seems a little dramatic given the real (to comms) impact it had but it may
make interesting viewing.
Alan.
>
> We already have BCP 38, which strongly recommends packet filtering on the
> customer-ISP edge. There are now two major vendors who have strict mode
> uRPF. This which covers 80% of the BCP 38 packet filtering on the
> customer-ISP edge. With a few BGP config tweaks, strict mode uRPF can cover
> a lot of the last 20% (all those multihomed customers).Except vendor J doesn't spend much time at the customer edge, and vendor F
seems to think that you should do per-interface RPF with acl's.Also, vendor J's implementation of loose mode is significantly different
from everyone elses. It seems they mean "is it feasible for this src ip to
be routed to this interface regardless or route selection", not "it is
feasible for this src ip to be routes to any interface on the box". Or to
put it another way, say you peer with someone who sends you 5000 routes,
but you only accept 4000 as best-path. If you feasible filter it, you'll
be allowing src IPs from those 5000 prefixes, not from all 100k+ on the
box. While this is potentially a neat feature, it isn't the same as true
"loose".
Juniper I believe is working on a "super-loose" check which
will mimick the cisco behaviour. As always, check with your vendor
for more detailed information, etc..
Between that and only being able to set strict or feasible for the entire
box and not per-interface, I'd say vendor J's implementation is almost
completely useless at this point.
Their 'loose' is interesting only in the case of customer
interfaces and not so interesting in the network core. Also
I seem to recall that it's a global option currently.
- jared
I happened to switch the TV on part way through. It wasn't exactly overwhelming on actual detail. They concentrated solely on the AT&T network (not being familiar with the US network there I don't know if there are others involved). They explained some of the basic principles that the network management team used to cope with the demand but the most technical they got was showing the AT&T switch building that got severely damaged when one of the minor buildings collapsed.
They did stretch to cover wireless coverage and how the mobile phone network was affected along with emergency plans of bringing in mobile transmitting units to keep the network running.
I happened to flick over to this right at the start, and thought the content was actually quite factual for this kind of programme.
They obviously concentrated on Voice, lots of interviews with Verizon and AT&T types, lots of footage of the West Street CO which must have been 60-70% of the content.
The bits that did touch on data seemed to actually be quite accurate if very brief, correctly "getting it" that the Internet didn't suffer any major problems in the immediate aftermath, and that e-mail was a major communications mechanism, although individual news content providers were swamped. They also had a good description of how a SONET ring works, so they must have had a decent technical advisor.
There was a small segment on the New York Times website, and the steps they took drop graphical content to try and keep things running.
Not too bad overall, I normally switch this kind of thing off as the content is usually hopelessly inaccurate but watched this right up to the end.
richard; sorry for latency on this one
but might be worth reading andre's:
"Internet expansion, refinement and churn",
http://www.caida.org/outreach/papers/2002/EGR/
which shows that most prefixes in the table come from
large providers. among.andre.conclusions (there is
quite a bit in the paper):
"transit ASes originate prefixes than non-transit ASes
despite the fact that there are five times as many non-transit
as transit ASes.
[see table 16 of paper, p.11]
the number of non-transit multihomed ASes grew from 46% to 49%
from 2000 to 2001, but their share of global routes remained
stable at 30%."
etc etc
there's a lot of stuff in there
not at all a waste of time
k
----- Forwarded message from Richard A Steenbergen <ras@e-gerbil.net> -----
On Wed, Aug 07, 2002 at 05:32:34PM -0700, k claffy mooed:
richard; sorry for latency on this one
but might be worth reading andre's:
"Internet expansion, refinement and churn",
CAIDA Resource Catalog
which shows that most prefixes in the table come from
large providers. among.andre.conclusions (there is
quite a bit in the paper):
On a related note, from a paper we're about to submit to
the Internet Measurement Workshop, see:
http://nms.lcs.mit.edu/~dga/aspathfrac.eps
for a breakdown of prefix by origin AS.
It's fairly clear where most of the prefixes come from..
(hi, UUNET).
-Dave
> On a related note, from a paper we're about to submit to
>the Internet Measurement Workshop, see:
>
> http://nms.lcs.mit.edu/~dga/aspathfrac.epsAcrobat is unable to render eps files. Care to send it in .ps or .pdf?
Whoops. My apologies:
http://nms.lcs.mit.edu/~dga/aspathfrac.pdf
Btw, I should clarify my comment about UUNET: They're the largest
source of prefixes announced by a single origin AS, but this
isn't necessarily reflective of poor aggregation. (I'll leave
that analysis to others). I'd wager there's also a historical
component in there. Don't even know that it's a problem, per se,
just an observation.
-Dave