[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [OPSEC] FYI draft-ietf-opsec-blackhole-urpf-04

On Jun 9, 2009, at 11:02 AM, Smith, Donald wrote:




(coffee != sleep) & (!coffee == sleep)
Donald.Smith at qwest.com gcia


-----Original Message-----
From: opsec-bounces at ietf.org [mailto:opsec-bounces at ietf.org]
On Behalf Of Joel Jaeggli
Sent: Monday, June 08, 2009 10:34 PM
To: 'opsec at ietf.org'
Subject: [OPSEC] FYI draft-ietf-opsec-blackhole-urpf-04

Another iteration of this draft after last call has been posted.

you many peruse it at your leisure. The diff located here:

http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-iet
f-opsec-blackhole-urpf-04.txt


shows the changes which are minor for the most part, except
for the very
strong disclaimer now in 4.0...

Before enabling uRPF (in any mode), it is vital that you
  fully understand the implications of doing so:

    - Strict mode will cause the router to drop all ingress traffic
      if the best path back to the source address of the traffic is
      not the interface from which the traffic was received.
      Asymetric routing will cause strict mode uRPF to drop
      legitimate traffic.
This completely ignores Junipers feasible-paths which allows for a urpf check to "pass" the packet if 
a feasible path exists via the interface the packet arrived on.
We should request all vendors implement feasible-path and active- paths too since that would remove most of the danger in strict mode!
Yes, you are completely correct, it *does* ignore the Juniper features and only outlines the lowest common denominator (I also didn't mention the optional ACL that you can use as well, etc). The text is meant as a warning to implementers and not a comprehensive guide to uRPF with all of its knobs and whistles.
If y'all feel that the operation of feasible / active path should be included, I'd really appreciate some text, as I found writing the current text tricky -- for some reason I find explaining uRPF in a clean and concise manner difficult without a whieboard... 







   - Loose mode causes the router to check if a route for the source
     address of the traffic exists. This may also cause legitimate
     traffic to be discarded.

  It is hoped that in the future, vendors will implement a "DoS-
  mitigation" mode in addition to the Loose and Strict modes
-- in this
  mode, the uRPF check will only fail if the next-hop for
the source of
  the packet is a discard interface.
If this gets implemented (gentle reminder / poke), this will decrease the risk of enabling uRPF even further... 



_______________________________________________
OPSEC mailing list
OPSEC at ietf.org
https://www.ietf.org/mailman/listinfo/opsec


_______________________________________________
OPSEC mailing list
OPSEC at ietf.org
https://www.ietf.org/mailman/listinfo/opsec


--
"Being the Fun-Police in the global Internet is a thankless - and probably futile - task." 
 --  R. Whittle ("draft-whittle-sram-ip-forwarding-01.txt")