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

From: Youjianjie <[email-masked]>
Date: Wed, 2 Mar 2016 09:11:57 +0000

Hi all,

I support as co-author. I'm not aware of any IPR.
This draft is useful for the networks using IS-IS or IS-IS variant, for example, the campus network or DC network, it is expected to extend IS-IS to distribute FlowSpec rules in order to mitigate (distributed) denial-of-service attacks.

Best Regards,
Jianjie

> -----邮件原件-----
> 发件人: Isis-wg [mailto:[email-masked]] 代表 [email-masked]
> 发送时间: 2016年2月27日 2:43
> 收件人: [email-masked]
> 抄送: [email-masked]
> 主题: [Isis-wg] Call for WG Adoption for draft-you-isis-flowspec-extensions-04
> 
> 
> 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.
> 
> Thanks,
> Chris & Hannes.

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 2 Mar 2016 17:43:25 +0800

I also support this doc to be a working group item as the co-author from operator. I am not aware of any IPR neither.

[email-masked]
 
发件人： Youjianjie
发送时间： 2016-03-02 17:11
收件人： [email-masked]; [email-masked]
抄送： [email-masked]
主题： [Isis-wg]答复: Call for WG Adoption for draft-you-isis-flowspec-extensions-04
Hi all,

Best Regards,
Jianjie
 
> Please indicate your support or no-support for taking on this work.
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isis-wg

---

From: Youjianjie <[email-masked]>
Date: Thu, 3 Mar 2016 02:01:11 +0000

Hi Chris,

> 发送时间: 2016年2月29日 23:15
> 收件人: Marc Binderberger
> 抄送: [email-masked]
> 主题: Re: [Isis-wg] Call for WG Adoption for
> draft-you-isis-flowspec-extensions-04
> 
> 
> Marc Binderberger <[email-masked]> writes:
> 
> > 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).
> 
> And so here's the thing, we have IS-IS protocol modifications being proposed
> here, OSPF has apparently accepted them, I just saw a new draft to add similar
> changes to PCEP, will we also see the same changes for RIP, Babel, EIGRP, ...?
> 
> I still don't understand why we don't define *1* yang model for flowspec, and
> use the protocols already there to configure routers for configuring routers.
> 
> > 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 agree if moving forward with this I think we need to look at GENAPP as well..
> 
> Firs though I'd like to hear more on why intra-domain flowspec (or the
> equivalent) can't simply be defined using a yang model.

Do you mean disseminating FlowSpec rules by using I2RS? I think it could be an alternative. But They each have their pros and cons. If using routing protocol to disseminate FlowSpec rules, when networks change, FlowSpec rules could be flexible as route entries, i.e. without involvement of management devices. 

Thanks,
Jianjie

> Thanks,
> Chris.
> 
> >
> >
> > Regards, Marc
> >
> >
> >
> >
> > On Fri, 26 Feb 2016 14:16:21 -0500, Christian Hopps wrote:
> >>
> >>> On Feb 26, 2016, at 1:43 PM, <[email-masked]>
> <[email-masked]> wrote:
> >>>
> >>>
> >>> Hi Folks,
> >>>
> >> 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.
> >>

---

From: Youjianjie <[email-masked]>
Date: Thu, 3 Mar 2016 02:48:11 +0000

Hi Marc,

> -----邮件原件-----
> 发件人: Isis-wg [mailto:[email-masked]] 代表 Marc Binderberger
> 发送时间: 2016年2月29日 13:04
> 收件人: Christian Hopps
> 抄送: [email-masked]
> 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.
> 
> (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

> >> On Feb 26, 2016, at 1:43 PM, <[email-masked]> <[email-masked]>
> wrote:
> >>
> >>
> >> Hi Folks,
> >>
> > 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.
> >

---

From: Youjianjie <[email-masked]>
Date: Thu, 3 Mar 2016 03:25:12 +0000

Hi Alia, Chris,

A Yang model based FlowSpec: https://tools.ietf.org/html/draft-wu-idr-flowspec-yang-cfg-02
Is this the draft that you may refer to? I think we still need to adapt it to IS-IS protocol if using Yang model?
The Yang model based FlowSpec does have some application scenarios, such as inject FlowSpec rules into specified routers by management system. In this document, we think FlowSpec is more like a n-tuple route. So we extend IS-IS.

Thanks,
Jianjie

发件人: Isis-wg [mailto:[email-masked]] 代表 Alia Atlas
发送时间: 2016年2月29日 23:37
收件人: Christian Hopps; Sue Hares
抄送: Marc Binderberger; [email-masked]
主题: Re: [Isis-wg] Call for WG Adoption for draft-you-isis-flowspec-extensions-04

On Mon, Feb 29, 2016 at 10:15 AM, <[email-masked]<mailto:[email-masked]>> wrote:

Marc Binderberger <[email-masked]<mailto:[email-masked]>> writes:

> (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.
>

And so here's the thing, we have IS-IS protocol modifications being
proposed here, OSPF has apparently accepted them, I just saw a new draft
to add similar changes to PCEP, will we also see the same changes for
RIP, Babel, EIGRP, ...?

I still don't understand why we don't define *1* yang model for flowspec,
and use the protocols already there to configure routers for configuring
routers.

I would strongly prefer to see one yang model for flowspec that can then be used by multiple protocols.  A question is how to carry the results  in each protocol?
Is it protocol-specific translation?  Is it extending a generic mechanism to carry a self-describing binary?

On the yang model for flowspec, please do also talk to Sue Hares (cc'd).  This is
something that she has been looking at in reference to BGP and the filter-specific
RIB model in I2RS.   One question that she raised is whether it is desirable to have exactly the same functionality via a yang model as via BGP flowspec.

I would strongly encourage discussion.  Part of this ties to what does it mean to have a model-based protocol?  Can we enhance our existing protocols?  Should we consider what a model-based protocol might look like if done from scratch?

Thanks for raising the question about the elephant in the room!

Regards,
Alia

> about RFC6823 "Advertising Generic Information in IS-IS" ?  That exists

I agree if moving forward with this I think we need to look at GENAPP as
well..

Thanks,
Chris.

>>> On Feb 26, 2016, at 1:43 PM, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>>
>>> Hi Folks,
>>>
>> routers, but b/c BGP enables inter-domain communication, and allows one AS
>> [email-masked]<mailto:[email-masked]>

_______________________________________________
Isis-wg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/isis-wg

---

From: Liangqiandeng <[email-masked]>
Date: Thu, 3 Mar 2016 05:50:41 +0000

Hi all,
 
I support as co-author and I'm not aware of any IPR.

Best Regards,
Qiandeng

-----邮件原件-----
发件人: Isis-wg [mailto:[email-masked]] 代表 Youjianjie
发送时间: 2016年3月2日 17:12
收件人: [email-masked]; [email-masked]
抄送: [email-masked]
主题: [Isis-wg] 答复: Call for WG Adoption for draft-you-isis-flowspec-extensions-04

Hi all,

Best Regards,
Jianjie

---

From: <[email-masked]>
Date: Fri, 04 Mar 2016 17:54:06 -0500

> Do you mean disseminating FlowSpec rules by using I2RS? I think it could be an alternative. But They each have their pros and cons. If using routing protocol to disseminate FlowSpec rules, when net…

I mean one would use netconf (or restconf, ...) and flowspec yang model to
configure ones routers with the flowspec data.

Can you explain more what you mean when talking about network changes?
The flowspec entries aren't changing when network changes occur.
If the originator changes them it knows it needs to configure the new
entries on the routers.

Again, this proposal just looks like configuring ones routers using a
routing protocol. If that's what we are doing I'd like it to be more
clearly understood, and then we can decide if this is what we think
routing protocols should be doing. :)

Thanks,
Chris.

---

From: <[email-masked]>
Date: Fri, 04 Mar 2016 17:58:16 -0500

> The Yang model based FlowSpec does have some application scenarios, such as inject FlowSpec rules into specified routers by management system. In this document, we think FlowSpec is more like a n-t…

But why should we think of flowspec as an N-tuple route?

Thanks,
Chris.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 4 Mar 2016 23:22:35 +0000

> Again, this proposal just looks like configuring ones routers using a routing
> protocol. If that's what we are doing I'd like it to be more clearly understood,
> and then we can decide if this is what we think routing protocols should be
> doing. :)
>

I do NOT think this is what routing protocols should be doing. Our job is to send information needed for routing. 

If you want to use the IS-IS flooding mechanism as a general purpose transport then you should use GENAPP (RFC 6823) in combination with MI (RFC 6822). IT is then clear that you are defining application information and this falls under TLV 251 using an IANA assigned application identifier.

Alternatively you could use other mechanisms (such as Chris suggests below) - which is also fine and likely a better choice in this case. But this is NOT something that belongs in an IGP instance used for routing - and certainly not in router capabilities.

   Les

> -----Original Message-----
> From: Isis-wg [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Friday, March 04, 2016 2:54 PM
> To: Youjianjie
> Cc: Marc Binderberger; [email-masked]
> Subject: Re: [Isis-wg] 答复: Call for WG Adoption for draft-you-isis-flowspec-
> extensions-04
> 
> 
> > Do you mean disseminating FlowSpec rules by using I2RS? I think it could be
> an alternative. But They each have their pros and cons. If using routing
> protocol to disseminate FlowSpec rules, when networks change, FlowSpec
> rules could be flexible as route entries, i.e. without involvement of
> management devices.
> 
> 
> If the originator changes them it knows it needs to configure the new entries
> on the routers.
> 
> Again, this proposal just looks like configuring ones routers using a routing
> protocol. If that's what we are doing I'd like it to be more clearly understood,
> and then we can decide if this is what we think routing protocols should be
> doing. :)
> 
> Thanks,
> Chris.
> 
> >
> > Thanks,
> > Jianjie
> >
> >> Thanks,
> >> Chris.

---

From: Marc Binderberger <[email-masked]>
Date: Sun, 6 Mar 2016 15:56:48 -0800

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:
>> their
> 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
>> 
>> 
>> 
>> 
>>> place

---

From: Youjianjie <[email-masked]>
Date: Fri, 11 Mar 2016 02:53:19 +0000

Hi Marc, Chris, and Les,

Thank you all for your comments. 
We'll think about using FlowSpec YANG model in this case for a next step. 

Best Regards,
Jianjie

> -----邮件原件-----
> 发件人: Marc Binderberger [mailto:[email-masked]]
> 发送时间: 2016年3月7日 7:57
> 收件人: Youjianjie
> 抄送: Christian Hopps; [email-masked]
> 主题: Re: 答复: [Isis-wg] Call for WG Adoption for
> > I'm not sure RFC6823 could be appropriate for supporting dissemination
> > of FlowSpec rules.
> 
> ... 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..
> 
> 
> 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.
> 
> 
> 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".
> 
> >> too. You need routers that see the traffic without any label, i.e.
> >> the edge. Again
> >> RFC5575
> >> + iBGP came handy.
> >>
> >> 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).
> >>
> >>

---

From: <[email-masked]>
Date: Sat, 19 Mar 2016 14:20:38 -0400

Hi Folks,

So the authors have agreed to look into other methods (e.g., yang) for
distribution of flowspec intra-domain. Given that and the other opinions
expressed during the adoption call, the WG consensus is to not take this
work on at this time.

Thanks,
Chris & Hannes.