Re: [Isis-wg] 答复: Call for WG Adoption for draft-you-isis-flowspec-extensions-04

[Marc Binderberger <[e-mail]>]

Hello Jianjie,

sorry for my delayed reply.

> I'm not sure RFC6823 could be appropriate for supporting dissemination of 
> FlowSpec rules. 

I guess your reply is based on another comment you made ...

> "[...] we think FlowSpec is more like a n-tuple route."

... and I would disagree with the n-tuple _route_. What flowspec distributes 
is a policy/filter, aiming to interrupt by dropping, rate-limiting, 
quarantining etc..


> Can it be regarded as an example of application of RFC6823?

well, everything can be treated as application :-) if it is not needed by 
IS-IS to do it's main task and IS-IS internal data is not needed for the new 
task. In this case I would say yes, we can. What you want from IS-IS is 
transporting flowspec data through the domain.


> If it could, then we need to define FlowSpec under the framework of RFC6823?

yes, you would need to request an application ID and would move the 
(sub-)TLVs you define in your draft into the TLV 251 framework.

Separating the IS-IS main functionality from transporting flow-spec 
information will have an impact on section 4.1.2. "Validation Procedure" in 
your draft. This procedure seems a 1:1 copy from the original BGP work. For 
IS-IS I don't see the point. And draft-ietf-idr-bgp-flowspec-oid actually 
modifies the rules for BGP to accept any originator in your administrative 
domain, which translated into IS-IS means "no check".

I would propose to drop this validation check in your draft.



Saying all this: I still think this is best done by a controller programming 
flow-spec into network elements; YANG models help here. This is outside of 
what routing protocols should be involved in.


Regards, Marc





On Thu, 3 Mar 2016 02:48:11 +0000, Youjianjie wrote:
> Hi Marc,
> 
>> -----邮件原件-----
>> 发件人: Isis-wg [mailto:[e-mail]] 代表 Marc Binderberger
>> 发送时间: 2016年2月29日 13:04
>> 收件人: Christian Hopps
>> 抄送: [e-mail]
>> 主题: Re: [Isis-wg] Call for WG Adoption for
>> draft-you-isis-flowspec-extensions-04
>> 
>> Hello Christian & IS-IS experts,
>> 
>> I agree with your comment. From my memory (the old ISP days ...):
>> 
>> (1) a big issue when DDoS attacks became the new "normal" was the
>> coordinated fight. A private, operator-only mail list was used but response
>> time was always an issue.
>> 
>> (2) thus signalling to your upstream or your peers was important. Obviously
>> this is eBGP and RFC5575 is exactly solving this problem.
>> 
>> (3) inside your network you needed to distribute the information to the
>> peering and uplink routers, potentially to your access routers too. You 
>> need
>> routers that see the traffic without any label, i.e. the edge. Again 
>> RFC5575
>> + iBGP came handy.
>> 
>> (4) Tools like Arbor and Riverhead spoke (and speak) BGP.
>> 
>> (5) problem (3) can be - and initially was - solved with ACLs, either 
>> manually
>> configured or with a configuration tool.
>> 
>> 
>> So (3) could be also addressed with an IGP like IS-IS. My personal opinion 
>> is
>> that only (1) was the main driver for RFC5575 and to fiddle with a 
>> protocol.
>> For problems like (3) the ISPs had been always inventive enough to use 
>> their
>> OSS systems if nothing else was available. To be fair, in these days CLI 
>> was
>> king, so enabling the network operators to send the attack to Null0 with a
>> few BGP commands on one central router was a good thing (tm).
>> 
>> 
>> If we really want to use IS-IS as a transport for configuration then what
>> about RFC6823 "Advertising Generic Information in IS-IS" ?  That exists
>> already.
> 
> I'm not sure RFC6823 could be appropriate for supporting dissemination of 
> FlowSpec rules. If it could, then we need to define FlowSpec under the 
> framework of RFC6823? Can it be regarded as an example of application of 
> RFC6823?
> 
> Thanks,
> Jianjie
> 
>> Regards, Marc
>> 
>> 
>> 
>> 
>> On Fri, 26 Feb 2016 14:16:21 -0500, Christian Hopps wrote:
>>> 
>>>> On Feb 26, 2016, at 1:43 PM, <[e-mail]> <[e-mail]>
>> wrote:
>>>> 
>>>> 
>>>> Hi Folks,
>>>> 
>>>> The authors have requested the IS-IS WG adopt:
>>>> 
>>>>    https://datatracker.ietf.org/doc/draft-you-isis-flowspec-extensions/
>>>> 
>>>> as a working group document.
>>>> 
>>>> Please indicate your support or no-support for taking on this work.
>>> 
>>> Speaking as a WG contributor and not as chair.
>>> 
>>> I am having some trouble accepting this solution is needed. The one use
>>> that has been given is a single operator who does not run BGP. The reason
>>> this is important is that BGP already provides a similar solution. But I
>>> believe the BGP solution exists not simply as a new way to configure
>>> routers, but b/c BGP enables inter-domain communication, and allows one
>> AS
>>> to inform another AS about an attack. BGP is also better suited to 
>>> carrying
>>> large amounts of data. Neither of these is true for IS-IS.
>>> 
>>> For the intra-domain only case the operator already has mechanisms in 
>>> place
>>> for configuring it's own routers. I've asked this before but not really
>>> gotten any answer as to how this proposal doesn't simply represent using
>>> IS-IS as a router configuration protocol.
>>> 
>>> If this is the case why wouldn't the DDOS detecting device simply use an
>>> established configuration mechanism, perhaps netconf/yang, to add the
>>> required policy on the required routers?
>>> 
>>> Thanks,
>>> Chris.
>>> 
>>> _______________________________________________
>>> Isis-wg mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/isis-wg
>> 
>> _______________________________________________
>> Isis-wg mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/isis-wg