[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [OPSEC] FYI draft-ietf-opsec-blackhole-urpf-04
(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!
>
> - 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.
> _______________________________________________
> OPSEC mailing list
> OPSEC at ietf.org
> https://www.ietf.org/mailman/listinfo/opsec
>