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

["Smith, Donald" <[e-mail]>]

(coffee != sleep) & (!coffee == sleep)
[e-mail] gcia   

> -----Original Message-----
> From: Warren Kumari [mailto:[e-mail]] 
> 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."


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


> 
> >
> >
> > 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.
> 
> 
> 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:)
> > [e-mail] giac
> >
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]]
> >> 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
> >> [e-mail]
> >> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/opsec
> >
> 
> 
_______________________________________________
OPSEC mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/opsec