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

[Haoweiguo <[e-mail]>]

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

                                                                                  Traffic analyzer (AS65513)
                                                                                  /
                                                                                 /l2VPN Flow
                      AS100                                    AS200 /
CE1-------PE1--------ASBR1-----------ASBR2-------PE2------CE2
AS65511                                                  AS65512
            L2VPN Flow    l2VPN Flow     l2VPN Flow 

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

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 [[e-mail]]
Sent: Monday, January 26, 2015 23:59
To: Haoweiguo; Susan Hares; Zhuangshunwan; 'idr wg'
Cc: [e-mail]; 'John G. Scudder'
Subject: RE: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015

(coffee != sleep) & (!coffee == sleep)
 [e-mail]

>       From: Haoweiguo [[e-mail]]
>       Sent: Tuesday, January 20, 2015 7:30 PM
>       To: Susan Hares; Smith, Donald; Zhuangshunwan; 'idr wg'
>       Cc: [e-mail]; 'John G. Scudder'
>       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.
>
>       Attacker--------Router A-----Router B-------Router C----Traffic analyzer
>                    AS 100       |                    AS200
>
>       The procedures:
>       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?

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

>       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.
[weiguo]:Exactly, flowspec rules also can be manually injected by human, then the flowspec rules are advertised to BGP peer of the traffic analyzer.

>       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?
[weiguo]: ASBRs don't need configure VRFs, BGP flow spec rules can be only enforced on ingress PE, so ingress PE should configure VRF.

>       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.
[weiguo]: Sure, i agree, flow-spec rule should be propagted to the ingress PE closer to attacker source.

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?)
[weiguo]: Yes, maybe this is the real scenario, layer 2 and layer 3 VPN flowspec have no difference in this respect.





>
>       Your further complementary usecases and deployment mode are welcomed.
>
>       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".

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

>
>       Thanks,
>       weiguo
>       ________________________________________
>       From: Idr [[e-mail]] on behalf of Susan Hares [[e-mail]]
>       Sent: Wednesday, January 21, 2015 0:17
>       To: 'Smith, Donald'; Zhuangshunwan; 'idr wg'
>       Cc: [e-mail]; 'John G. Scudder'
>       Subject: Re: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015
>
>       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:[e-mail]] On Behalf Of Smith, Donald
>       Sent: Tuesday, January 20, 2015 10:23 AM
>       To: Zhuangshunwan; 'Susan Hares'; 'idr wg'
>       Cc: [e-mail]; '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.
>
>       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)
>        [e-mail]
>
>
>
>       From: Idr [[e-mail]] on behalf of Zhuangshunwan
>       [[e-mail]]
>       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
>
>
>       Support as co-author and not aware any IPR regarding this document.
>
>       Thanks,
>       Shunwan
>
>
>       发件人: Idr [mailto:[e-mail]] 代表 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.
>
>       The draft can be found at:
>
>       http://datatracker.ietf.org/doc/draft-hao-idr-flowspec-evpn
>
>       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
>       [e-mail]
>       https://www.ietf.org/mailman/listinfo/idr
>
>       _______________________________________________
>       Idr mailing list
>       [e-mail]
>       https://www.ietf.org/mailman/listinfo/idr
>
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.