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

From: Warren Kumari <[email-masked]>
Date: Mon, 6 Oct 2008 13:04:05 -0400

On Sep 29, 2008, at 5:04 PM, Smith, Donald wrote:

>
>
> (coffee != sleep) & (!coffee == sleep)
> [email-masked] gcia
>
>> -----Original Message-----
>> From: Warren Kumari [mailto:[email-masked]]
>> 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.

Thanks, fixed!

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

Doh! I meant customers --- providers should already be filtering their  
customers so that they can only announce space that "belongs" to them.  
As I often (incorrectly) use the word "peer" to refer to any sort of  
BGP session where routes are exchanged, I will go check If I have made  
this mistake anywhere else (I must admit that I also use the phrase  
"class C" to refer to any network with a mask of /24, call the screen  
on an digital watch an "LCD display" and ask for "Coke" when I want a  
soda...)

>
>
>
>>>
>>>
>>> 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?
>>
>>
>> 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....
> I reread it. It is much better now.

Cool, thanks!

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

Great, thank you for your text, it does a MUCH better job of  
explaining what I intended... I think that leaving in some mention of  
active / feasible / loose, etc is a good idea so that people are aware  
that it can be deployed even if the provider is currently running mode  
X... Thoughts?

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

Hmmm... Fair enough... (the "next_hop_for_source" lookup includes the  
"route exists" check :-))

I will get around to posting -02 sometime soon (with your  
suggestions), or maybe just wait till this is officially accepted as a  
WG doc....

W

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

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