Subject: [Idr] flowspec enhancements

From: Wesley Eddy <[email-masked]>
Date: Tue, 15 Sep 2015 13:39:29 -0400

Hello, we've been working on a few enhancements to the BGP flowspec
capabilities that may be of interest:

https://tools.ietf.org/html/draft-eddy-idr-flowspec-exp-00

There are several ideas described in the document that could be
factored out from one another, but the basic idea is to increase
the power of flowspec, mainly for its DDoS mitigation purposes.

Specifically, the suggested enhancements include:
- add packet rate limitations as an action (not just bitrate)
- add support for filtering of tunneled traffic (unencrypted)
- identifying flow specifications for tracking and communication
  between providers
- cryptographically signing flowspecs
- supporting a more surgical re-route to scrubbing centers
- providing feedback about flowspecs to the source

If any of these are interesting to folks, we'll appreciate your
feedback, comments, questions, etc.  Some are more difficult than
others.

I'm assuming IDR is a reasonable list for this, though it also
touches SIDR and OPSEC topics, but will appreciate the chairs'
thoughts on this.  It has been mentioned in the DOTS list, but
is obviously out of scope for DOTS.

-- 
Wes Eddy
MTI Systems

---

From: Haoweiguo <[email-masked]>
Date: Wed, 23 Sep 2015 01:05:25 +0000

Hi Wes,
I have read through your draft, it's very useful and interesting. One comment about "add support for filtering of tunneled traffic" is as follows:

I also think flow-spec should support nesting representation for overlay encapsulations. In my draft of "draft-hao-idr-flowspec-nvo3-01", the nesting problem and solution are raised, a new component type of "Delimiter type" is proposed. In your draft, the name is called "tunnel separator". I think both of us think it's an important problem that should be resolved.  

Thanks,
weiguo
________________________________________
From: Idr [[email-masked]] on behalf of Wesley Eddy [[email-masked]]
Sent: Wednesday, September 16, 2015 1:39
To: [email-masked]
Cc: Justin Dailey
Subject: [Idr] flowspec enhancements

--
Wes Eddy
MTI Systems

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

---

From: Wesley Eddy <[email-masked]>
Date: Fri, 25 Sep 2015 16:09:34 -0400

I agree that expressing ways to match tunneled flows is very useful.

I took a look at the draft-hao-idr-flowspec-nvo3 document and I
don't agree with the approach taken there, which identifies
specific encapsulations (e.g. VXLAN, NVGRE, and eventually others
such as GUE, as I understand the plans).

I don't think that's a reasonable approach in general for BGP/flowspec
to express tunneling, because we can't rely on the multitude of
encapsulations to be parse-able by routers in general.

That's why we proposed the "Offset-Value-Mask" approach for defining
components to be matched within a tunnel.  At the cost of being only
slightly more complex to express fields, it can be much more generally
implemented for the many current (and future) encapsulation types.

On 9/22/2015 9:05 PM, Haoweiguo wrote:
> Hi Wes, I have read through your draft, it's very useful and
> interesting. One comment about "add support for filtering of tunneled
> traffic" is as follows:
> 
> I also think flow-spec should support nesting representation for
> overlay encapsulations. In my draft of
> "draft-hao-idr-flowspec-nvo3-01", the nesting problem and solution
> are raised, a new component type of "Delimiter type" is proposed. In
> your draft, the name is called "tunnel separator". I think both of us
> think it's an important problem that should be resolved.
> 
> Thanks, weiguo

-- 
Wes Eddy
MTI Systems

---

From: Haoweiguo <[email-masked]>
Date: Mon, 28 Sep 2015 11:14:54 +0000

Hi Wesley,
Glad to see both of us think that matching tunneled flow is necessary for BGP flowspec application.
In the draft of 'draft-hao-idr-flowspec-nvo3', classic BGP Flowspec matching method is used for overlay encap, the method is semantic dependant. The routers need to understand every field's meaning in BGP Flowspec message. 
However, in your draft, a new "Offset-Value-Mask" approach was proposed, the method is semantic agnostic. The routers don't need to understand the specific meaning for each field, so theoretically it has great scalability.  However, your solution will incur additional security issue, the security problem space will be totally different with current BGP flowspec mechanism. Also, your method can be used to replace all current BGP flowspec documents, because all current BGP flowspec documents assume the routers need to know the exact meaning of each field in BGP flowspec message.

I think you should ask IDR WG firstly if it suitable to use 'semantic agnostic' method for all BGP flowspec application.  If your solution has not been adopted by WG, we had better use current mechansim('semantic dependant') to design the solution for overlay tunneled flow matching.

Thanks,
weiguo

________________________________________
From: Wesley Eddy [[email-masked]]
Sent: Saturday, September 26, 2015 4:09
To: Haoweiguo; [email-masked]
Cc: Justin Dailey
Subject: Re: [Idr] flowspec enhancements

--
Wes Eddy
MTI Systems