Subject: Re: [Idr] draft-marques-idr-flow-spec-04.txt as an IDR WG document

From: Robert Raszuk <[email-masked]>
Date: Tue, 07 Aug 2007 03:52:41 +0200

Yakov,

I support this to be an IDR WG document.

Thx,
R.

> Folks,
> 
> IDR WG chairs received a request to accept 
> draft-marques-idr-flow-spec-04.txt
> as an IDR WG document (see attached).
> 
> Comments are greatly appreciated. The deadline for comments is
> August 10, 2007.
> 
> Yakov.
> ------- Forwarded Message
> 
> Date:    Thu, 26 Jul 2007 12:33:27 -0600
> From:    Danny McPherson <[email-masked]>
> To:      Hares Susan <[email-masked]>, Yakov Rekhter <[email-masked]>
> cc:      Pedro Roque Marques <[email-masked]>, [email-masked]
> Subject: Fwd: I-D ACTION:draft-marques-idr-flow-spec-04.txt
> 
> Susan/Yakov,
> As discussed in the meeting today, could you please ask
> the WG about this becoming a WG item?
> 
> - -danny

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Danny McPherson <[email-masked]>
Date: Mon, 6 Aug 2007 20:48:06 -0600

> I support this to be an IDR WG document.

++me, obviously..

-danny

---

From: Scott A.McIntyre <[email-masked]>
Date: Tue, 7 Aug 2007 15:31:12 +0200

Hey all,

> From: Yakov Rekhter <[email-masked]>
> Date: July 27, 2007 9:01:14 AM MDT
> To: [email-masked]
> Subject: [Idr] draft-marques-idr-flow-spec-04.txt as an IDR WG  
> document
>
> Folks,
>
> IDR WG chairs received a request to accept draft-marques-idr-flow- 
> spec-04.txt

Great to see this moving forward, consider this note a positive  
comment in support of accepting it.  Can't wait to see flow-spec more  
widely deployed...

Regards,

Scott A. McIntyre
Security Officer
KPN-CERT

---

From: "Drake, John E" <[email-masked]>
Date: Tue, 7 Aug 2007 06:45:09 -0700

As do I 

> -----Original Message-----
> From: Robert Raszuk [mailto:[email-masked]] 
> Sent: Monday, August 06, 2007 6:53 PM
> To: Yakov Rekhter
> Cc: [email-masked]
> Subject: Re: [Idr] draft-marques-idr-flow-spec-04.txt as an 
> IDR WG document
> 
> Yakov,
> 
> > Comments are greatly appreciated. The deadline for comments 
> is August 
> > 10, 2007.
> > 
> > Yakov.
> > As discussed in the meeting today, could you please ask the 
> WG about 
> > this becoming a WG item?
> > 
> > - -danny
>

---

From: Shane Amante <[email-masked]>
Date: Tue, 07 Aug 2007 08:02:36 -0600

Yakov Rekhter wrote:
> Folks,
> 
> IDR WG chairs received a request to accept draft-marques-idr-flow-spec-04.txt 

Support.

-shane

> Begin forwarded message:
>> From: [email-masked]
>> Date: July 8, 2007 4:15:02 PM MDT
>> To: [email-masked]
>> Subject: I-D ACTION:draft-marques-idr-flow-spec-04.txt
>> Reply-To: [email-masked]
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>
>> 	Title		: Dissemination of flow specification rules
>> 	Author(s)	: P. Marques, et al.
>> 	Filename	: draft-marques-idr-flow-spec-04.txt
>> 	Pages		: 25
>> 	Date		: 2007-7-8
>> 	
>> This document defines a new BGP NLRI encoding format that can be used
>>    to distribute traffic flow specifications.  This allows the routing
>>    system to propagate information regarding more-specific  
>> components of
>>    the traffic aggregate defined by an IP destination prefix.
>>
>>    Additionally it defines two applications of that encoding format.
>>    One that can be used to automate inter-domain coordination of  
>> traffic
>>    filtering, such as what is required in order to mitigate
>>    (distributed) denial of service attacks.  And a second  
>> application to
>>    traffic filtering in the context of a BGP/MPLS VPN service.
>>
>>    The information is carried via the Border Gateway Protocol (BGP),
>>    thereby reusing protocol algorithms, operational experience and
>>    administrative processes such as inter-provider peering agreements.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-marques-idr-flow-spec-04.txt
>>
>> To remove yourself from the I-D Announcement list, send a message to
>> [email-masked] with the word unsubscribe in the body of
>> the message.
>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>> to change your subscription settings.
>>
>> Internet-Drafts are also available by anonymous FTP. Login with the
>> username "anonymous" and a password of your e-mail address. After
>> logging in, type "cd internet-drafts" and then
>> "get draft-marques-idr-flow-spec-04.txt".
>>
>> A list of Internet-Drafts directories can be found in
>> http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>> Internet-Drafts can also be obtained by e-mail.
>>
>> Send a message to:
>> 	[email-masked].
>> In the body type:
>> 	"FILE /internet-drafts/draft-marques-idr-flow-spec-04.txt".
>> 	
>> NOTE:	The mail server at ietf.org can return the document in
>> 	MIME-encoded form by using the "mpack" utility.  To use this
>> 	feature, insert the command "ENCODING mime" before the "FILE"
>> 	command.  To decode the response(s), you will need "munpack" or
>> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
>> 	exhibit different behavior, especially when dealing with
>> 	"multipart" MIME messages (i.e. documents which have been split
>> 	up into multiple messages), so check your local documentation on
>> 	how to manipulate these messages.
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>> Content-Type: text/plain
>> Content-ID: <[email-masked]>
>>
>> I-D-Announce mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/i-d-announce
> 
> ------- End of Forwarded Message
>

---

From: Joe Abley <[email-masked]>
Date: Tue, 7 Aug 2007 13:44:45 -0400

> Comments are greatly appreciated. The deadline for comments is

I support this draft being adopted as a working group document.

Joe

---

From: Michal Mroczek <[email-masked]>
Date: Thu, 09 Aug 2007 12:20:26 +0200

Support.

-- 
MPM

---

From: John Leslie <[email-masked]>
Date: Thu, 9 Aug 2007 10:51:26 -0400

> Comments are greatly appreciated. The deadline for comments is

   I support adding this as a WG item. It would be highly useful to have
an automated way to report, "I am dropping packets like this: please log
them instead of sending them to me."

==
John Leslie <[email-masked]>

---

From: "Martin Djernaes \(djernaes\)" <[email-masked]>
Date: Fri, 10 Aug 2007 11:18:41 -0700

Hi,

I think that the problem space presented in the FlowSpec draft is a very
interesting, and very important, problem, but I do not think that the
FlowSpec draft does enough to resolve the problem and leaves enough
issues behind that it at best could be seen a stop gap measure for a
more comprehensive solution. Instead of having FlowSpec becoming a
working group document I would suggest that the problem is taken up
separately, possibly in the security area, to ensure that a solution
resolve the majority of the needs in such networks. Therefore I can not
support this as a WG document.

Martin

> From: Yakov Rekhter [mailto:[email-masked]] 
> Sent: Friday, July 27, 2007 8:01 AM
> To: [email-masked]
> Subject: [Idr] draft-marques-idr-flow-spec-04.txt as an IDR 
> WG document
> 
> Folks,
> 
> > You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce

---

From: Chandrashekhar Appanna <[email-masked]>
Date: Fri, 10 Aug 2007 12:16:01 -0700

Hi,

The document says :

   "Additionally it defines two applications of that encoding format.
   One that can be used to automate inter-domain coordination of traffic
   filtering, such as what is required in order to mitigate
   (distributed) denial of service attacks.  And a second application to
   traffic filtering in the context of a BGP/MPLS VPN service."

I believe that for the most part the solution for threat detection,
propogation and then mitigation requires a framework of which BGP may
be a part. However, we should consider whether BGP is the transport
for the propagation once we have figured out the framework and the
requirements. Would IDR be the group for that? I do not think so. 

I think that there are quite a few interesting discussion points
raised by the draft and they all are related to the application
that is using BGP as a transport. Is BGP going to be extensible as
a framwork? Is BGP going to be the transport of choice? Does the
distribution network for information propagation for these applications
mirror a BGP routing information distribution network? 

In summary, at this point I do not feel that this should become an
IDR WG document.  We should perhaps find a suitable home for these
discussions and then if we still choose to use BGP we can bring the
BGP changes to IDR.

0.02,
Chandra.

---

From: "Barry Greene \(bgreene\)" <[email-masked]>
Date: Fri, 10 Aug 2007 12:45:16 -0700

The operators objectives is to get this draft to Information RFC
status. Be that through IDR or through the normal processes. 

Realities is that Flowspec does work - with an operational
understanding that it is not the perfect solution. Operators are not
looking for a perfect solution, they are looking for thing that will
solve a issue that is causing them pain. 

Keep in mind that today, the #1 SP Security tool used to hammer the
bad guys is BGP + Forwarding to Null 0 (Remote Triggered Black Hole).
This is an industry wide practice. So the comfort level of using BGP
to trigger security policy is the defacto standard today.

IMHO - doing flowspec work in IDR - making sure that all BGP bases
are covered (i.e. we need to add 4-byte ASN) is logical. The
objective is not standards. The objective is completeness of a
partial tool that operators would like to deploy and require of their
vendors.

Barry

> From: Martin Djernaes (djernaes) 
> Sent: Friday, August 10, 2007 11:19 AM
> To: Yakov Rekhter; [email-masked]
> Subject: RE: [Idr] draft-marques-idr-flow-spec-04.txt as an 
> IDR WG document
> 
> Hi,
> 
> I think that the problem space presented in the FlowSpec 
> draft is a very interesting, and very important, problem, but 
> I do not think that the FlowSpec draft does enough to resolve 
> the problem and leaves enough issues behind that it at best 
> could be seen a stop gap measure for a more comprehensive 
> solution. Instead of having FlowSpec becoming a working group 
> document I would suggest that the problem is taken up 
> separately, possibly in the security area, to ensure that a 
> solution resolve the majority of the needs in such networks. 
> Therefore I can not support this as a WG document.
> 
> Martin
> 
> 
> > cc:      Pedro Roque Marques <[email-masked]>,
> > [email-masked] Subject: Fwd: I-D
> > ACTION:draft-marques-idr-flow-spec-04.txt
> > 
> > Susan/Yakov,
> > > username "anonymous" and a password of your e-mail address.
> > > After  logging in, type "cd internet-drafts" and then "get 
> > > draft-marques-idr-flow-spec-04.txt".
> > >
> > > http://www.ietf.org/shadow.html or 
> > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > >
> > > 	command.  To decode the response(s), you will need "munpack"
> > > or 	a MIME-compliant mail reader.  Different MIME-compliant
> > mail readers
> > > 	"multipart" MIME messages (i.e. documents which have been
> > > split 	up into multiple messages), so check your local
> > > documentation on 	how to manipulate these messages.
> > >
> > > Below is the data which will enable a MIME compliant mail
> > > reader  implementation to automatically retrieve the ASCII
> > > version of the  Internet-Draft.
> > > Content-Type: text/plain

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 10 Aug 2007 15:51:47 -0400

I support this.

Regarding some of the other points raised, I'll just note that "the  
perfect is the enemy of the good".

--John

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 10 Aug 2007 12:54:44 -0700

Hi Martin,

Can you list those issues which are left by the draft behind ?

Thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 10 Aug 2007 13:03:15 -0700

Chandra,

I am afraid you have missed the main point about flowspec since you are 
asking such questions below.

We use BGP not just as a transport for it. It is highly integrated with 
the actual advertisement of customer routes which today travel via BGP. 
The main objective is to be able to automatically verify if filter for a 
given prefix comes from the router which advertised such prefix to us in 
the first place. Then we compare if such filter application would not 
negatively impact other peers with more specific blocks.

I see no practical way to achieve the above goals if the transport of 
filter for a given destination is not part of the same protocol which 
distributed the actual route in the first place.

So clearly please provide actual facts how such integration and 
verification is negative and if you consider it positive how could that 
be achieved by decoupling transport protocols for both.

Cheers,
R.

---

From: Brad Volz <[email-masked]>
Date: Fri, 10 Aug 2007 20:24:59 +0000 (UCT)

As an operator, I agree with Barry Greene's summary below.

The only point that I would add is that at least for this operator, 
support for the flow-spec draft is already a part of our RFPs to vendors; 
both in terms of network hardware and IP transit.

The difference that flow-spec support makes when dealing with a flood from 
multiple points of network ingress toward a critical service ( ie, one 
that cannot simply be blackholed ) is amazing.

Brad

On Fri, 10 Aug 2007, Barry Greene \(bgreene\) wrote:

>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>