Subject: [Idr] Adoption of draft-djsmith-bgp-flowspec-oid-01 as IDR WG document

From: "John G. Scudder" <[email-masked]>
Date: Wed, 16 May 2012 15:40:12 -0400

Folks,

We have received a request from the authors to adopt draft-djsmith-bgp-flowspec-oid-01 as an IDR WG document.  Please send your comments to the list.  The deadline for comments is June 1, 2012 at noon EDT.

Thanks,

--John

---

From: Keyur Patel <[email-masked]>
Date: Wed, 16 May 2012 12:53:38 -0700

Support.

-Keyur

On 5/16/12 12:40 PM, "John G. Scudder" <[email-masked]> wrote:

> Folks,
> 
> We have received a request from the authors to adopt
> draft-djsmith-bgp-flowspec-oid-01 as an IDR WG document.  Please send your
> comments to the list.  The deadline for comments is June 1, 2012 at noon EDT.
> 
> Thanks,
> 
> --John
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 16 May 2012 22:19:13 +0200

Hi,

I support the adoption of this draft as WG document.

However the new text authors added between -00 and -01 seems too 
restrictive to the original theme/direction.

It says:

".. or the AS_PATH attribute of the flow specification is empty."

That precludes injecting and honoring the flow routes even within the 
same administrative domain in the presence of confederations.

I recommend that this limitation should be removed in next version.

Regards,
R.

> draft-djsmith-bgp-flowspec-oid-01 as an IDR WG document.  Please send
> your comments to the list.  The deadline for comments is June 1, 2012
> at noon EDT.
>
> Thanks,
>
> --John _______________________________________________ Idr mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/idr
>
>

---

From: Randy Bush <[email-masked]>
Date: Wed, 16 May 2012 10:21:22 -1000

> draft-djsmith-bgp-flowspec-oid-01 as an IDR WG document.

have read lightly.  agree it is a reasonable wg work item.

of course, i like centralization about as much as i like large telco
switches, nat444, ....  but that does not detract from this being a
perfectly reasonable work item.

randy

---

From: Keyur Patel <[email-masked]>
Date: Wed, 16 May 2012 14:20:12 -0700

One comment and one question on the draft.

1) I believe the rule should cover checks for AS4_PATH as well.

2) Section 6 from RFC5575

<snip>
BGP implementations MUST also enforce that the AS_PATH attribute of a
   route received via the External Border Gateway Protocol (eBGP)
   contains the neighboring AS in the left-most position of the AS_PATH
   attribute.  While this rule is optional in the BGP specification, it
   becomes necessary to enforce it for security reasons.
<snip>

Do we need to do a complete aspath check instead? Otherwise, a neighboring
AS can inject a bogus flowspec route?

Regards,
Keyur

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 16 May 2012 23:24:22 +0200

Hi Keyur,

Actually you bring a good point. Going by section 6 would preclude 
reception of flow-spec routes across IX route servers as in those cases 
enforcing-first-as must be disabled on the IX client.

Perhaps as you suggest we should replace section 6 of current 5575 with 
the full AS_PATH check regardless if enforce-first-as is in effect there 
or not.

Comments ?

Thx,
R.

> On 5/16/12 1:19 PM, "Robert Raszuk"<[email-masked]>  wrote:
>
>> Hi,
>>

---

From: Keyur Patel <[email-masked]>
Date: Wed, 16 May 2012 14:46:20 -0700

Yep. In that case, the enforce-first-as text [RFC5575] could be relaxed and
modified as well (We would need a uniform enforce-first-as policy between
the flowspec and unicast afi/safis and that would work when comparing
aspaths).

Regards,
Keyur

---

From: Randy Bush <[email-masked]>
Date: Wed, 16 May 2012 12:25:23 -1000

first, we are now discussing the draft, not whether it should be a wg
item.  so i have changed $subject

> Do we need to do a complete aspath check instead? Otherwise, a
> neighboring AS can inject a bogus flowspec route?

this draft has wonderful text in the security section

   No new security issues are introduced by relaxing the validation
   procedure for IBGP learned flow specifications. With this proposal,
   the security characteristics of BGP flow specifications remain
   equivalent to the existing security properties of BGP unicast
   routing.  Traffic flow specifications learned from IBGP peers are
   trusted, hence, its not required to validate that the originator of
   an intra-domain traffic flow specification matches the originator of
   the best-match unicast route for the flow destination prefix.
   Conversely, this proposal continues to enforce the validation
   procedure for EBGP learned traffic flow specifications. In this way,
   the security properties of RFC 5575 are maintained such that an EBGP
   peer cannot cause a denial-of-service attack by advertising an
   inter-domain flow specification for a destination prefix that it does
   not provide reachability information for.

you gotta love the ref to 5575 which essentially says you have no
protection, abandon all hope ye who enter

randy

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 17 May 2012 00:36:34 +0200

> protection, abandon all hope ye who enter

For the record .. this is not what below quote says.

Explanation:

The RFC says that for IBGP even with relaxed validation you get what you 
have today .. provided that you know how to protect your AS in the first 
place.

For EBGP the validation is in place and matching last AS as unicast 
route injector with flow spec is sufficient. The DDoS attack to a 
particular destination may have been detected just by your peer and it 
is WRONG to mandate full AS_PATH match.

That would mean that flow-spec filter would need to be injected by the 
target and would consume bandwith of all transit ASes in the AS_PATH. 
This is wrong.

I admit we did not consider RS @ IX when writing section 6.

R.

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 29 May 2012 14:34:20 -0400

So far I have seen replies to this from three people. This is not really strong evidence of interest on the part of the WG.

The comment period will end on Friday.

--John

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Tue, 29 May 2012 20:38:12 +0200

I am ok adopting this as a WG draft.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John G. Scudder
Sent: dinsdag 29 mei 2012 20:34
To: [email-masked] List
Subject: Re: [Idr] Adoption of draft-djsmith-bgp-flowspec-oid-01 as IDR WG document

--John

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 29 May 2012 15:09:07 -0400

> The comment period will end on Friday.

I thought I had publicly responded in the affirmative.  I support adoption
of this as a WG item.  Additionally, similar work is a pre-requisite for the
geo-distribution draft I presented at the last IETF.

-- Jeff

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 29 May 2012 15:41:28 -0400

Hi,

I support adoption of draft-djsmith-bgp-flowspec-oid as IDR WG document

Regards,
Jeff
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John G. Scudder
Sent: Wednesday, May 16, 2012 12:40 PM
To: [email-masked] List
Subject: [Idr] Adoption of draft-djsmith-bgp-flowspec-oid-01 as IDR WG document

Folks,

Thanks,

--John

---

From: Warren Kumari <[email-masked]>
Date: Tue, 29 May 2012 16:20:28 -0400

> I support adoption of draft-djsmith-bgp-flowspec-oid as IDR WG document

Me too.

This is a fun new game -- John issues a CFA and we all ignore it. After the call closes and doesn't carry, we all popup and support it. This all adds to the suspense, making for a more entertaining WG :-P

W

---

From: "Shyam Sethuram (shsethur)" <[email-masked]>
Date: Thu, 31 May 2012 11:17:14 -0700

+Support

thanks--shyam

>Sent: Tuesday, May 29, 2012 11:34 AM
>To: [email-masked] List
>Subject: Re: [Idr] Adoption of draft-djsmith-bgp-flowspec-oid-01 as IDR
WGdocument
>
>So far I have seen replies to this from three people. This is not
really strong evidence of
>interest on the part of the WG.
>
draft-djsmith-bgp-flowspec-oid-01 as
>an IDR WG document.  Please send your comments to the list.  The
deadline for comments
>is June 1, 2012 at noon EDT.
>>
>> Thanks,
>>
>> --John
>