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

["Smith, Donald" <[e-mail]>]

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


>       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?)






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


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