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

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



Smith, Donald wrote:
> Then isn't the "it is hoped ... ddos-urpf" recommendation out of scope also?

I think there's a distinction between describing a gap that is not yet
adressed and asking for feature parity between two or N implmentations.

I don't think that it's necessarily a detraction that a BCP doesn't
cover all the details of a vendor specific implementation. Though to
contrast I do think the implmentation examples are useful to get the
point across.

we (the royal we) just need to address this in another document.

 that
> Feasible path is nice and there are a couple of other urpf recommendations I could make to make it easier for other ISPs to start using strict mode urpf.

There beyond feasbile path there's the question of whether bcp 38 needs
an update to reflect our experience with it.

> Let me gather together recommendations and try to write them into a rfc.
> 
> 
> (coffee != sleep) & (!coffee == sleep)
> Donald.Smith at qwest.com gcia   
> 
>> -----Original Message-----
>> From: Joel Jaeggli [mailto:joelja at bogus.com] 
>> Sent: Tuesday, June 09, 2009 12:17 PM
>> To: Smith, Donald
>> Cc: 'opsec at ietf.org'
>> Subject: Re: [OPSEC] FYI draft-ietf-opsec-blackhole-urpf-04
>>
>> I agree that feasible path is nice...
>>
>> ;)
>>
>> RFE's should be out of scope for this document.
>>
>> draft-smith-feasible-path-considered-benificial-00 will probably get a
>> sympathetic ear in opsec, probably also idr.
>>
>> joelja
>>
>> 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!
>>>>     - 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
>>>>