Subject: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015

From: "Susan Hares" <[email-masked]>
Date: Mon, 19 Jan 2015 11:30:47 -0500

This is to begin a 2 week adoption call for draft-hao-idr-flowspec-evpn.
Please comment on the usefulness of the draft in deployments and on the
technical pros/cons of the draft.  In your comments please include:
"support" or "no support" indicate.  Authors should indicate if any IPR
exists for this draft. 

The draft can be found at: 

http://datatracker.ietf.org/doc/draft-hao-idr-flowspec-evpn

Sue Hares

---

From: <[email-masked]>
Date: Mon, 19 Jan 2015 16:33:02 +0000

Support as co-author.

Moreover I'm not aware of any IPR regarding this document.

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Monday, January 19, 2015 17:31
To: idr wg
Cc: 'John G. Scudder'
Subject: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015

This is to begin a 2 week adoption call for draft-hao-idr-flowspec-evpn.  Please comment on the usefulness of the draft in deployments and on the technical pros/cons of the draft.  In your comments please include:  "support" or "no support" indicate.  Authors should indicate if any IPR exists for this draft.

Sue Hares

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Mon, 19 Jan 2015 19:14:20 +0000

+1

Jim Uttaro

From: Idr [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, January 19, 2015 11:33 AM
To: [email-masked]
Subject: [Idr] FW: WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015

Support as co-author.

Sue Hares

Thank you.

---

From: Lucy yong <[email-masked]>
Date: Mon, 19 Jan 2015 19:17:14 +0000

Support!

Cheers,
Lucy

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Monday, January 19, 2015 10:31 AM
To: idr wg
Cc: 'John G. Scudder'
Subject: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015

Sue Hares

---

From: Mach Chen <[email-masked]>
Date: Tue, 20 Jan 2015 00:38:43 +0000

Support.

Best regards,
Mach

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Tuesday, January 20, 2015 12:31 AM
To: idr wg
Cc: 'John G. Scudder'
Subject: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015

Sue Hares

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 20 Jan 2015 01:47:03 +0000

Support the adoption.

Best regards,
Jie

Sue Hares

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 20 Jan 2015 03:16:34 +0000

This draft is very useful and therefore I support the adoption.

Xiaohu

Sue Hares

---

From: Zhuangshunwan <[email-masked]>
Date: Tue, 20 Jan 2015 15:21:19 +0800

Support as co-author and not aware any IPR regarding this document.

Thanks,

Shunwan

发件人: Idr [mailto:[email-masked]] 代表 Susan Hares
发送时间: 2015年1月20日 0:31
收件人: idr wg
抄送: 'John G. Scudder'
主题: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to
2/2/2015

This is to begin a 2 week adoption call for draft-hao-idr-flowspec-evpn.
Please comment on the usefulness of the draft in deployments and on the
technical pros/cons of the draft.  In your comments please include:
“support” or “no support” indicate.  Authors should indicate if any IPR
exists for this draft. 

Sue Hares

---

From: "Smith, Donald" <[email-masked]>
Date: Tue, 20 Jan 2015 15:23:21 +0000

So far all the "support" responses re from Huawei ( single vendor support) engineers.

When will the intended status be decided?

Intended RFC status:Unknown

The draft itself at first review appears to be pretty good. I didn't see any large technical issues with it (yet:)

I am considering how an ISP would use this or if they would.

"Please comment on the usefulness of the draft in deployments and on the technical pros/cons of the draft." so I look forward to use cases or other descriptions of how/when people would use this.

I think the security considerations should probably match what other flow-spec drafts have said.
Currently it is very weak and probably inaccurate.

I will withhold support for now. But also don't object to adoption by this wg!

(coffee != sleep) & (!coffee == sleep)
 [email-masked]

From: Idr [[email-masked]] on behalf of Zhuangshunwan [[email-masked]]
Sent: Tuesday, January 20, 2015 12:21 AM
To: 'Susan Hares'; 'idr wg'
Cc: 'John G. Scudder'
Subject: Re: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015

Thanks,
Shunwan

发件人: Idr [mailto:[email-masked]] 代表 Susan Hares
发送时间: 2015年1月20日 0:31
收件人: idr wg
抄送: 'John G. Scudder'
主题: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015

This is to begin a 2 week adoption call for draft-hao-idr-flowspec-evpn.  Please comment on the usefulness of the draft in deployments and on the technical pros/cons of the draft.  In your comments please include:  “support” or “no support” indicate.  Authors should indicate if any IPR exists for this draft.

Sue Hares
This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 20 Jan 2015 11:17:48 -0500

Donald:

I hope that service providers will comment on the list on the usefulness of
this draft.   If you have suggestions on improving the security
considerations, please send these to the list during the WG adoption call. 

Sue 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Smith, Donald
Sent: Tuesday, January 20, 2015 10:23 AM
To: Zhuangshunwan; 'Susan Hares'; 'idr wg'
Cc: [email-masked]; 'John G. Scudder'
Subject: Re: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn
(1/19/2015 to 2/2/2015

So far all the "support" responses re from Huawei ( single vendor support)
engineers.

The draft itself at first review appears to be pretty good. I didn't see any
large technical issues with it (yet:)

"Please comment on the usefulness of the draft in deployments and on the
technical pros/cons of the draft." so I look forward to use cases or other
descriptions of how/when people would use this.

I think the security considerations should probably match what other
flow-spec drafts have said.
Currently it is very weak and probably inaccurate.

I will withhold support for now. But also don't object to adoption by this
wg!

From: Idr [[email-masked]] on behalf of Zhuangshunwan
[[email-masked]]
Sent: Tuesday, January 20, 2015 12:21 AM
To: 'Susan Hares'; 'idr wg'
Cc: 'John G. Scudder'
Subject: Re: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn
(1/19/2015 to 2/2/2015

Thanks,
Shunwan

Sue Hares
This communication is the property of CenturyLink and may contain
confidential or privileged information. Unauthorized use of this
communication is strictly prohibited and may be unlawful. If you have
received this communication in error, please immediately notify the sender
by reply e-mail and destroy all copies of the communication and any
attachments.
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Haoweiguo <[email-masked]>
Date: Wed, 21 Jan 2015 02:30:09 +0000

Hi Donald,

Thanks for your great comments. The layer 2 flowspec deployment in layer 2 VPN network is similar to layer 3 flowspec. The following is the typical deployment scenario.

Attacker--------Router A-----Router B-------Router C----Traffic analyzer
             AS 100       |                    AS200

The procedures:
1. Traffic are sampled on Router C and Router D using netstream like method, then the traffic is sent to the traffic analyzer.
2. When the traffic analyzer detects exceptional traffic relying on rules defined in beforehand, the analyzer constructs BGP flowspec routes automatically, then it sends the
flowspec routes to peer Router C.  
3. Then router C  transmits the flowspec routes to ingress PE of Router B.
4. Router B converts the flowspec routes to local ACL rules, downloads the ACL rules to chipset for traffic filtering.

Your further complementary usecases and deployment mode are welcomed.

As for security issue, would you like to give some detail suggestions?

Thanks,
weiguo
________________________________________
From: Idr [[email-masked]] on behalf of Susan Hares [[email-masked]]
Sent: Wednesday, January 21, 2015 0:17
To: 'Smith, Donald'; Zhuangshunwan; 'idr wg'
Cc: [email-masked]; 'John G. Scudder'
Subject: Re: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015

Donald:

Sue

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Smith, Donald
Sent: Tuesday, January 20, 2015 10:23 AM
To: Zhuangshunwan; 'Susan Hares'; 'idr wg'
Cc: [email-masked]; 'John G. Scudder'
Subject: Re: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn
(1/19/2015 to 2/2/2015

Thanks,
Shunwan

Sue Hares

---

From: "Smith, Donald" <[email-masked]>
Date: Mon, 26 Jan 2015 15:59:28 +0000

>       From: Haoweiguo [[email-masked]]
>       Sent: Tuesday, January 20, 2015 7:30 PM
>       To: Susan Hares; Smith, Donald; Zhuangshunwan; 'idr wg'
>       Subject: RE: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015
>
>
>       Hi Donald,
>
>       Thanks for your great comments. The layer 2 flowspec deployment in layer 2 VPN network is similar to layer 3 flowspec.
>The following is the typical deployment scenario.
>
>       1. Traffic are sampled on Router C using netstream like method, then the traffic is sent to the traffic analyzer.
Netstream, or netflowv5 (and ipfix, v9...) is there some way to say this that is nonvendor specific but still sight requirements for the trffic analysis input protocols without writing a new rfc :)
I think it doesn't make a difference. In fact sflow which is different from netflow in several ways should work right?

>       2. When the traffic analyzer detects exceptional traffic relying on rules defined in beforehand, the analyzer constructs BGP flowspec routes automatically,    >   then it sends the  flowspec routes to peer Router C.
Many of us prefer there be a human in this decision so traffic analyzer would send an alert including recommended rule(s) for review to some kind of review tool/alert system.

>       3. Then router C  transmits the flowspec routes to ingress PE of Router B.
Is router B a PE, ASBR, EDGE, peering router with MPLS vrfs enabled?

>       4. Router B converts the flowspec routes to local ACL rules, downloads the ACL rules to chipset for traffic filtering.

If it was an ASBR or peering router where AS100 and AS200 cooperate in filtering unwanted or
"bad" traffic filtering, you might even allow it to propagate to router A if the two ASes allowed it. It is better to drop closer to source, there could even be a router Z in AS 100 (or set of routers) that receive the flow-spec rule and drop "bad" traffic at the edge of AS100 so AS100 doesn't have to carry "bad" or unwanted traffic over its network/backbone.

With an ASBR as200 would actually be doing the announcement itself into a VPN tunnel (into the as100 physical space but within their own vrf/mpls tunnel in as100.

With a peering router and interAS filtering agreements in place AS200 would notify AS100 in some fashion (perhaps directly using flow-spec rules or a phone call or carrier pigeon:)

With large ISPs this could even come down to a customer of AS200 making a filtering request that after prefix filtering etc... affects traffic filtering in a vrf in AS100's network (but outside their bgp control?)

>       As for security issue, would you like to give some detail suggestions?
From rfc5575
"https://tools.ietf.org/html/rfc5575#section-10
Security Considerations

   Inter-provider routing is based on a web of trust.  Neighboring
   autonomous systems are trusted to advertise valid reachability
   information.  If this trust model is violated, a neighboring
   autonomous system may cause a denial-of-service attack by advertising
   reachability information for a given prefix for which it does not
   provide service.

   As long as traffic filtering rules are restricted to match the
   corresponding unicast routing paths for the relevant prefixes, the
   security characteristics of this proposal are equivalent to the
   existing security properties of BGP unicast routing.

   Where it is not the case, this would open the door to further denial-
   of-service attacks.

   Enabling firewall-like capabilities in routers without centralized
   management could make certain failures harder to diagnose.  For
   example, it is possible to allow TCP packets to pass between a pair
   of addresses but not ICMP packets.  It is also possible to permit
   packets smaller than 900 or greater than 1000 bytes to pass between a
"
While this isn't quite right for this rfc it is closer then "no new vulnerabilities".

---

From: Haoweiguo <[email-masked]>
Date: Tue, 27 Jan 2015 11:15:17 +0000

Hi Donald,
Thanks for your detail replies.

For layer 2 VPN flowspec deployment, the more typical network can be illustrated as follows:
 
                                                            Traffic analyzer (AS65513)
                                                            /
                                                           /l2VPN Flow
                       AS100              AS200 /
CE1-------PE1--------ASBR1-----------ASBR2-------PE2------CE2
AS65511                                                  AS65512
               L2VPN Flow    l2VPN Flow     l2VPN Flow 

In above figure, traffic analyzer belongs to service provider network, it establishes EVPN BGP session with ASBR2. The traffic analyzer can serve for multiple VPN customers simultaneously.

As for other replies, pls see inline with [weiguo].
Thanks,
weiguo

________________________________________
From: Smith, Donald [[email-masked]]
Sent: Monday, January 26, 2015 23:59
To: Haoweiguo; Susan Hares; Zhuangshunwan; 'idr wg'
Cc: [email-masked]; 'John G. Scudder'
Subject: RE: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015

[weiguo]: Essentially netstream,netflow and IPFix are same solutions for traffic statistics,IPFix is an IETF released standard based on Netflow v9. 
Yes, SFlow is very different from Netflow. Netflow like solutions are more often supported on routers, SFlow appears to be more popular on switches.
Netflow is flow based sampling solution. SFlow is packet based sampling solution, sFlow sampling technology is very simple and imposes little impact on forwarding performance. 
But for SFlow, traffic collector and analyzer need do more thing for abnormal flow detection.

Many of us prefer there be a human in this decision so traffic analyzer would send an alert including recommended rule(s) for review to some kind of review tool/alert system.
[weiguo]:Exactly, flowspec rules also can be manually injected by human, then the flowspec rules are advertised to BGP peer of the traffic analyzer.

Is router B a PE, ASBR, EDGE, peering router with MPLS vrfs enabled?
[weiguo]: ASBRs don't need configure VRFs, BGP flow spec rules can be only enforced on ingress PE, so ingress PE should configure VRF. 

If it was an ASBR or peering router where AS100 and AS200 cooperate in filtering unwanted or
"bad" traffic filtering, you might even allow it to propagate to router A if the two ASes allowed it. It is better to drop closer to source, there could even be a router Z in AS 100 (or set of routers) that receive the flow-spec rule and drop "bad" traffic at the edge of AS100 so AS100 doesn't have to carry "bad" or unwanted traffic over its network/backbone.
[weiguo]: Sure, i agree, flow-spec rule should be propagted to the ingress PE closer to attacker source.

With large ISPs this could even come down to a customer of AS200 making a filtering request that after prefix filtering etc... affects traffic filtering in a vrf in AS100's network (but outside their bgp control?)
[weiguo]: Yes, maybe this is the real scenario, layer 2 and layer 3 VPN flowspec have no difference in this respect.

From rfc5575

[weiguo]: Yes, the security description defined in RFC 5575 can also applied to layer 2 flowspec.

---

From: Haoweiguo <[email-masked]>
Date: Tue, 27 Jan 2015 12:01:05 +0000

Sorry for repost to correct the deployment network figure. The figure should be:

Traffic analyzer is connected to PE2, it can serve for multiple VPN customers.
Thanks,
weiguo
________________________________________
From: Haoweiguo [[email-masked]]
Sent: Tuesday, January 27, 2015 19:15
To: Smith, Donald; Susan Hares; Zhuangshunwan; 'idr wg'
Cc: [email-masked]; 'John G. Scudder'
Subject: RE: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015

Hi Donald,

From rfc5575