Re: [Idr] flowspec enhancements

[Haoweiguo <[e-mail]>]

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 [[e-mail]]
Sent: Saturday, September 26, 2015 4:09
To: Haoweiguo; [e-mail]
Cc: Justin Dailey
Subject: Re: [Idr] flowspec enhancements

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