Subject: [OPSEC] http://www.ietf.org/internet-drafts/draft-kumari-blackhole-urpf-00.txt

From: Joel Jaeggli <[email-masked]>
Date: Thu, 11 Sep 2008 10:57:46 -0700

Was one of the upcoming documents mentioned in the dublin meeting.

this document expands on the method in RFC3882 and I think much more
accurately represents current operational practice.

some review on it's current form and consensus as to whether we should
accept it as a working group document would be appreciated.

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

---

From: "Smith, Donald" <[email-masked]>
Date: Thu, 11 Sep 2008 13:00:16 -0600

First let me say this is valuable work and it is well done.
It should be accepted as a WG document.

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.

Triggered black-hole routing, Remote triggered black hole routing and
RTBH filtering.

If "As a matter of policy, operators SHOULD NOT accept source-based RTBH
announcements from their peers or customers" then why bother asking for
a registered community from IANA?

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.

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.

Security through obscurity WORKS against some worms and ssh attacks:)
[email-masked] giac 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Joel Jaeggli
> Sent: Thursday, September 11, 2008 11:58 AM
> To: opsec wg mailing list
> Subject: 
> [OPSEC]http://www.ietf.org/internet-drafts/draft-kumari-blackh
> ole-urpf-00.txt
> 

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]
https://www.ietf.org/mailman/listinfo/opsec

---

From: "Christopher Morrow" <[email-masked]>
Date: Mon, 15 Sep 2008 00:57:05 -0400

> It should be accepted as a WG document.

I agree.

-chris

---

From: Warren Kumari <[email-masked]>
Date: Wed, 17 Sep 2008 18:46:39 -0400

Hi all,

I am feeling a little bad that I received this a while ago and haven't  
responded yet -- I have visitors at the moment and things have been  
hectic keeping them amused, etc...

Anyway, thank you very much for your comments -- I haven't had time to  
fully digest them, so these are incomplete thoughts...

> It should be accepted as a WG document.

Yay! Thank you :-)

> but which ever term is used should be used consistently.

Thank you, will search and replace...

> a registered community from IANA?

Bah... I was hoping no-one would notice this :-P. I started off  
writing this because there was a (perceived) need for standard  
community so that customers can signal their provider that they would  
like DESTINATION based RTBH applied (I have often run into the "OMG,  
I'm being attacked, what was $PROVIDERs community for this again? 666?  
37? something? Help!" issues. Usually people start calling their  
provider at this point, then realize that the first tier support has  
no idea, etc..). This document then morphed into a source based RTBH  
document...

I do still believe that it would be beneficial if there was a  
standardized community to signal your provider that you want  
DESTINATION based RTBH applied, but probably not SOURCE RTBH. How does  
this sound? I DID try figuring out how to word this in the doc, but,  
well...

> intention of the authors but it wasn't what I expected.

Yeah, I was going to put in multiple examples, one for destination,  
then one for source, but apparently got sidetracked  -- I'll try fix  
this...

> Does this imply that strict mode urpf can't be used for source based

Nope, not at all... I was a little wary of suggesting strict mode  
because, all to often I have seen the "Oooh, a config snippet, let me  
paste it onto all of our routers without understanding it..." syndrome  
-- I didn't want to get grumpy emails asking why I suggested that :-)

> some serious security implications.

Nope, if you have strict mode, thats fine, but if you have no URPF,  
you need to be a little more careful turning on strict than loose...

> [email-masked] giac

Once again, thank you for you comments, I will try and update the  
draft ti include them soon...

W

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 18 Sep 2008 10:35:41 -0700

> fully digest them, so these are incomplete thoughts...

i think there's significant interest in this work. And I think someone
should discuss it at the ietf security bof at the upcoming nanog and
solicit feedback there as well.
> Bah... I was hoping no-one would notice this :-P. I started off writing
> this because there was a (perceived) need for standard community so that
> customers can signal their provider that they would like DESTINATION
> based RTBH applied (I have often run into the "OMG, I'm being attacked,
> what was $PROVIDERs community for this again? 666? 37? something? Help!"
> issues. Usually people start calling their provider at this point, then
> realize that the first tier support has no idea, etc..). This document
> then morphed into a source based RTBH document...
> 
> standardized community to signal your provider that you want DESTINATION
> based RTBH applied, but probably not SOURCE RTBH. How does this sound? I
> DID try figuring out how to word this in the doc, but, well...
> 
> 
>>
>>
> Yeah, I was going to put in multiple examples, one for destination, then
> one for source, but apparently got sidetracked  -- I'll try fix this...
> 
>>
>>
> Nope, if you have strict mode, thats fine, but if you have no URPF, you
> need to be a little more careful turning on strict than loose...
> 
> Once again, thank you for you comments, I will try and update the draft
> ti include them soon...
> 
> W
> 
>>
>>

---

From: "Smith, Donald" <[email-masked]>
Date: Thu, 18 Sep 2008 13:46:36 -0600

> From: Warren Kumari [mailto:[email-masked]] 
> Sent: Wednesday, September 17, 2008 4:47 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
> 
> Hi all,
> 
> > It suffers from inconsistent use of the following teams 
> which appear  
> > to
> > If "As a matter of policy, operators SHOULD NOT accept 
> source-based  
> > RTBH
> > announcements from their peers or customers" then why 
> bother asking  
> > for
> this sound? 
That sounds good. 666 is a fairly commonly used community for that.

>I DID try figuring out how to word this in the doc, but,  
> well...
> 
> 
> >
> >

If you just add the loose mode (and feasible vs active paths for junos
maybe?) that should be enough. 

> > some serious security implications.

How about:
"In strict or loose mode some vendors also verify that the destination
route does
not point to a discard interface."

That way you can leave strict mode out of the config sample but others
won't wonder if strict mode would work with uppf for src based RTBHF.

---

From: "J. Gill" <[email-masked]>
Date: Thu, 18 Sep 2008 16:00:38 -0400

> > no idea, etc..). This document then morphed into a source based

...

> That sounds good. 666 is a fairly commonly used community for that.

For what it is worth (a chuckle at least) ...  AS701 initially used 666
for RTBH.  But when "this new, great idea" was being explained to People
In Pinstripes, they blanched at the possible media relations problems
that could arise if the public found out about it.  Yeah.

So for you 701 neighbors, use 9990.  Thanks.

--gill

---

From: Warren Kumari <[email-masked]>
Date: Fri, 26 Sep 2008 23:29:24 -0400

> that could arise if the public found out about it.  Yeah.

I suspect that the dye that is used to color the pinstripes releases  
some chemical that suppresses both the humor and adrenal glands....

> So for you 701 neighbors, use 9990.  Thanks.

Thank you -- as I am not very organized, I will scribble this number  
down on a (slightly soiled) napkin which will get buried in one the  
piles on my desk, then eventually used to mop up yet another coffee  
spill and thrown out -- this means that I will be completely unable to  
signal you when the need arises[0]. My lack of organization / desk  
cleaning ability is the reason I am asking for a registered community.

Warren

[0]: OK, not really -- I will remember 9990, especially because I now  
know where it comes from  -- a registered community will mean that I  
don't need to spend multiple hours on the phone with all of my peers  
trying to pry the same information out of them...

---

From: Warren Kumari <[email-masked]>
Date: Sat, 27 Sep 2008 00:38:55 -0400

> It should be accepted as a WG document.

Cool, thanks...

> 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.)
> a registered community from IANA?

I realized that I was not very clear here -- I have tried to reword  
bits so that it is more clear that the IANA community should only be  
used for destination RTBH filtering and that communities with the AS  
number as the first 2 octets (RFC1997-style?!) should be used and  
carefully filtered....

> 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... )

> 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...

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...)
   }

Thank you for all of your comments -- hopefully I have managed to  
integrate them into the doc (I have just posted -01) -- please have a  
look and let me know.

Also, apologies again to everyone for taking so long to respond to  
emails, the random disjointedness of my replies, etc... My parents are  
visiting from South Africa and are staying with my wife and I for a  
month or so -- I have taken time off work to show them around, etc --  
this has completely destroyed my routine and productivity....

W

---

From: "Smith, Donald" <[email-masked]>
Date: Mon, 29 Sep 2008 15:04:17 -0600

(coffee != sleep) & (!coffee == sleep)
[email-masked] gcia   

> Sent: Friday, September 26, 2008 10:39 PM
> To: Smith, Donald
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.

> if I missed any (other than where I define it in the Abstract and  
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."

> number as the first 2 octets (RFC1997-style?!) should be used and  
I reread it. It is much better 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.

>     (increment uRPF accept counter, accept packet, normal processing  

Interesting.
How about:
> If ((next_hop_for_source == DISCARD)) {
That would eliminate the route check which I don't think you really want
in this case.