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

From: Joel Jaeggli <[email-masked]>
Date: Mon, 08 Jun 2009 21:34:03 -0700

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

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

---

From: "Smith, Donald" <[email-masked]>
Date: Tue, 9 Jun 2009 09:02:51 -0600

(coffee != sleep) & (!coffee == sleep)
[email-masked] gcia   

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Joel Jaeggli
> Sent: Monday, June 08, 2009 10:34 PM
> To: [email-masked]'
> Subject: [OPSEC] FYI draft-ietf-opsec-blackhole-urpf-04
> 
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!

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

---

From: Warren Kumari <[email-masked]>
Date: Tue, 9 Jun 2009 11:44:37 -0400

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

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

>>   the packet is a discard interface.

If this gets implemented (gentle reminder / poke), this will decrease  
the risk of enabling uRPF even further...

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

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 09 Jun 2009 11:16:43 -0700

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

---

From: "Smith, Donald" <[email-masked]>
Date: Tue, 9 Jun 2009 12:38:03 -0600

Then isn't the "it is hoped ... ddos-urpf" recommendation out of scope also?

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.

Let me gather together recommendations and try to write them into a rfc.

> From: Joel Jaeggli [mailto:[email-masked]] 
> Sent: Tuesday, June 09, 2009 12:17 PM
> To: Smith, Donald
> Cc: [email-masked]'
> Subject: Re: [OPSEC] FYI draft-ietf-opsec-blackhole-urpf-04
> 
> > This completely ignores Junipers feasible-paths which 
> allows for a urpf check to "pass" the packet if
> > We should request all vendors implement feasible-path and 
> active-paths too since that would remove most of the danger 
> in strict mode!
> >

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 09 Jun 2009 12:15:03 -0700

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

---

From: Pekka Savola <[email-masked]>
Date: Wed, 10 Jun 2009 08:55:14 +0300 (EEST)

On Tue, 9 Jun 2009, Smith, Donald wrote:
> 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.
>

Seconded.

You may already know this but RFC3704 talks a bit about feasible paths 
on a generic level, and draft-savola-bcp84-urpf-experiences-03 
describes experiences with multihomed uRPF using feasible paths. We're 
using it everywhere but some manual fiddling is required in our case 
(described in the draft above).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "Smith, Donald" <[email-masked]>
Date: Thu, 11 Jun 2009 15:07:29 -0600

Based on this conversation I withdraw my objection.
Several members expressed interest in doing a urpf feature recommendations type rfc aimed at making it easier for ISPs to implement urpf including things like feasible paths.

(coffee != sleep) & (!coffee == sleep)
 [email-masked] gcia
________________________________
From: Pekka Savola [[email-masked]]
Sent: Tuesday, June 09, 2009 11:55 PM
To: Smith, Donald
Cc: 'Joel Jaeggli'; [email-masked]'
Subject: Re: [OPSEC] FYI draft-ietf-opsec-blackhole-urpf-04

Seconded.