Re: [Idr] WGLC for draft-ietf-idr-bgp-flowspec-oid-06

["Juan Alcaide (jalcaide)" <[e-mail]>]

If trafic goes ISPB->ISPA->Customer M, then ISPB will accept the FS rule 
from ISPA (this is just RFC5575)
If traffic goes ISPB->Customer M, then ISPB needs to trust the FS rule 
from ISPA. This is what ISPB needs to configure and this is the wording 
we are discussing

-J


On 5/11/2018 11:44 PM, John Schiel wrote:
> Don's example makes sense to me. Ideally CustM is getting traffic both 
> from ISPA and ISPB. If ISPA identifies and stops the traffic from 
> going to CustM, then sends a rule to B, ISPB may or may not accept the 
> rule and the attack would still go over the connection from ISPB to 
> CustM based on preferred path regardless of rule acceptance. If the 
> metrics are different and the preferred path is now from ISPB to ISPA 
> and then to CustM, then the importance of accepting the rule becomes 
> more important.
>
> I don't see any current issues with this WG.
>
> --John
>
>
> On Fri, May 11, 2018 at 2:42 PM, Jakob Heitz (jheitz) 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     This is the case that we all intend to work (I think), but only if
>     ISPB explicitly
>
>     allows that flowspec rule from ISPA. It would not happen by default.
>
>     Now to find the words...
>
>     Thanks,
>
>     Jakob
>
>     *From:*Smith, Donald <[e-mail]>
>     *Sent:* Friday, May 11, 2018 1:36 PM
>     *To:* Jakob Heitz (jheitz) <[e-mail]
>     <mailto:[e-mail]>>; Juan Alcaide (jalcaide)
>     <[e-mail] <mailto:[e-mail]>>; John Scudder
>     <[e-mail] <mailto:[e-mail]>>; idr@ietf. org
>     <[e-mail] <mailto:[e-mail]>>
>
>
>     *Cc:* [e-mail] <mailto:[e-mail]>; Schiel, John
>     <[e-mail]
>     <mailto:[e-mail]>>;
>     [e-mail]
>     <mailto:[e-mail]>
>     *Subject:* RE: [Idr] WGLC for draft-ietf-idr-bgp-flowspec-oid-06
>
>     Customer M
>
>     | |
>
>     |              |
>
>     | |
>
>     ISPA------ISPB
>
>     ISPA sees a large DDoS attack against customer M and triggers a
>     flowspec rule internally and to ISPB.
>
>     But ISPB has customer M connections too (one or more) and receives
>     BGP announcements from them (or has a static or ... but has routes
>     that would be preferred internally), thus the flowspec check would
>     fail right?
>
>     Metric System < +000 > -000
>
>     Extra People's Terribly Good Meals Kept mY uNCLE    Ned   Purring
>     For     Ages
>
>     Exa   Peta Tera     Giga   Mega  Kilo milli Micro(u) Nano Pico   
>     Femto Atto
>
>     [e-mail] <mailto:[e-mail]>
>
>     ------------------------------------------------------------------------
>
>     *From:*Jakob Heitz (jheitz) [[e-mail]
>     <mailto:[e-mail]>]
>     *Sent:* Friday, May 11, 2018 1:39 PM
>     *To:* Smith, Donald; Juan Alcaide (jalcaide); John Scudder;
>     idr@ietf. org
>     *Cc:* [e-mail] <mailto:[e-mail]>; Schiel, John;
>     [e-mail]
>     <mailto:[e-mail]>
>     *Subject:* RE: [Idr] WGLC for draft-ietf-idr-bgp-flowspec-oid-06
>
>     Sorry Donald, Can you draw a diagram or reword your scenario?
>
>     Thanks,
>
>     Jakob
>
>     *From:*Smith, Donald <[e-mail]
>     <mailto:[e-mail]>>
>     *Sent:* Friday, May 11, 2018 12:30 PM
>     *To:* Juan Alcaide (jalcaide) <[e-mail]
>     <mailto:[e-mail]>>; Jakob Heitz (jheitz)
>     <[e-mail] <mailto:[e-mail]>>; John Scudder
>     <[e-mail] <mailto:[e-mail]>>; idr@ietf. org
>     <[e-mail] <mailto:[e-mail]>>
>     *Cc:* [e-mail] <mailto:[e-mail]>; Schiel, John
>     <[e-mail]
>     <mailto:[e-mail]>>;
>     [e-mail]
>     <mailto:[e-mail]>
>     *Subject:* RE: [Idr] WGLC for draft-ietf-idr-bgp-flowspec-oid-06
>
>     I am not entirely sure if that works here or not.
>
>     But I think with that you could show some AS as the last AS in the
>     past (far left) and maybe not show the original customer AS?
>
>     As long as your advertising that space to me, and I don't have a
>     better path it should work.
>
>     Now what happens when a customer is a customer of ISP A and ISP B
>     both have routes to it, if A advertises flowspec to B for that
>     network wouldn't it be blocked as the best path to the customer
>     inside of B is B's path.
>
>     This is actually a different problem, or subset of the original issue.
>
>     What should happen in that case? I might want to take action, I
>     might not be seeing a huge flood, while the original announcer (A)
>     is and wants us to take action as they expect we will be seeing
>     that traffic soon?
>
>     Metric System < +000 > -000
>
>     Extra People's Terribly Good Meals Kept mY uNCLE Ned   Purring
>     For     Ages
>
>     Exa   Peta        Tera     Giga   Mega Kilo milli Micro(u) Nano
>     Pico    Femto Atto
>
>     [e-mail] <mailto:[e-mail]>
>
>     ------------------------------------------------------------------------
>
>     *From:*Juan Alcaide (jalcaide) [[e-mail]
>     <mailto:[e-mail]>]
>     *Sent:* Friday, May 11, 2018 12:57 PM
>     *To:* Smith, Donald; Jakob Heitz (jheitz); John Scudder; idr@ietf. org
>     *Cc:* [e-mail] <mailto:[e-mail]>; Schiel, John;
>     [e-mail]
>     <mailto:[e-mail]>
>     *Subject:* Re: [Idr] WGLC for draft-ietf-idr-bgp-flowspec-oid-06
>
>     Don,
>
>     (just to be clear, this has nothing to directly with the redirect
>     extended-community draft)
>
>     We already thought about it and added a 'clause' in the last revision.
>
>     "Optionally, an implementation
>        could be configured to allow only flow specification NLRIs
>     containing
>        only a subset of ASes.  This could be useful, for example, with
>        networks that consist of multiple ASes that operate under the same
>        administrative domain."
>
>     This is not what you want?
>
>     -J
>
>     On 5/11/2018 4:50 PM, Smith, Donald wrote:
>
>         That would work of course MAY would be caps :) But that should
>         cover the case I was describing.
>
>         All the other BGP security issues would still apply.
>
>         Cc'ing the two architects that have been working on this
>         concept with me, in case they have anything to add.
>
>         Metric System < +000 > -000
>
>         Extra People's Terribly Good Meals Kept mY uNCLE Ned   Purring
>         For     Ages
>
>         Exa   Peta Tera     Giga Mega  Kilo milli Micro(u) Nano
>         Pico    Femto Atto
>
>         [e-mail] <mailto:[e-mail]>
>
>         ------------------------------------------------------------------------
>
>         *From:*Jakob Heitz (jheitz) [[e-mail]
>         <mailto:jheitz@cisco..com>]
>         *Sent:* Thursday, May 10, 2018 11:39 PM
>         *To:* Smith, Donald; John Scudder; idr@ietf. org
>         *Cc:* [e-mail]
>         <mailto:[e-mail]>
>         *Subject:* RE: [Idr] WGLC for draft-ietf-idr-bgp-flowspec-oid-06
>
>         I support the draft.
>
>         Donald, are you saying that AS1 should accept a flowspec rule
>         from AS2 for traffic going to AS3?
>
>         If AS1 can trust the flowspec from AS2, then I don't see why not.
>
>         Maybe we can add text to the effect of:
>
>         The rules stated here are for default behavior.
>
>         Local policy may allow flow specifications from other EBGP
>         neighbors to be accepted.
>
>         Thanks,
>
>         Jakob
>
>         *From:*Idr <[e-mail]>
>         <mailto:[e-mail]> *On Behalf Of *Smith, Donald
>         *Sent:* Thursday, May 10, 2018 11:58 AM
>         *To:* John Scudder <[e-mail]> <mailto:[e-mail]>;
>         idr@ietf. org <idr@ietf..org> <mailto:idr@ietf..org>
>         *Cc:* [e-mail]
>         <mailto:[e-mail]>
>         *Subject:* Re: [Idr] WGLC for draft-ietf-idr-bgp-flowspec-oid-06
>
>         This supports some of the bi-lateral, ddos-peering work we
>         want to do, so support.
>
>         https://pc.nanog.org/static/published/meetings/NANOG71/1447/20171003_Levy_Operationalizing_Isp_v2.pdf
>         <https://pc.nanog.org/static/published/meetings/NANOG71/1447/20171003_Levy_Operationalizing_Isp_v2.pdf>
>
>         That is almost always going to be between some set of systems
>         not one hop away, not directly in the forwarding plane,
>         probably not really IBGP peers.
>
>         " It thus becomes necessary to modify step (a) of the RFC 5575
>         <https://tools.ietf.org/html/rfc5575>
>            validation procedure such that an IBGP peer that is not
>         within the
>            data forwarding plane may originate flow specification NLRIs."
>
>         While you could have the IBGP peer directly in the forwarding
>         plane, forward it like a route reflector, requiring it to
>         seems counter intuitive as it is more likely to come from some
>         BGP speaking tool in ISP requesting the filter.
>
>         Next lots of references to IBGP and a few to EBGP, when I
>         think of IBGP, IBGP is internal to a single AS (yes I know
>         there are exceptions) but that is kind of the meaning, while
>         this is mostly between peers (whom could do IBGP between them
>         but is that required? Can't we validate without IBGP direct
>         connections?)
>
>         Metric System < +000 > -000
>
>         Extra People's Terribly Good Meals Kept mY uNCLE Ned   Purring
>         For     Ages
>
>         Exa   Peta        Tera     Giga   Mega  Kilo milli
>         Micro(u) Nano Pico    Femto Atto
>
>         [e-mail] <mailto:[e-mail]>
>
>         ------------------------------------------------------------------------
>
>         *From:*Idr [[e-mail]
>         <mailto:[e-mail]>] on behalf of John Scudder
>         [[e-mail] <mailto:[e-mail]>]
>         *Sent:* Thursday, May 10, 2018 12:28 PM
>         *To:* idr@ietf. org
>         *Cc:* [e-mail]
>         <mailto:[e-mail]>
>         *Subject:* Re: [Idr] WGLC for draft-ietf-idr-bgp-flowspec-oid-06
>
>         Hi All,
>
>             On Apr 26, 2018, at 3:58 PM, John Scudder <[e-mail]
>             <mailto:[e-mail]>> wrote:
>
>             The authors have requested a working group last call for
>             draft-ietf-idr-bgp-flowspec-oid-06. Please respond with
>             your comments before Friday, May 11.
>
>         A quick update on the status of this WGLC:
>
>         - All the authors have responded about IPR (thank you!).
>
>         - Three people who are not authors (Acee, Shyam, Keyur) have
>         responded supporting publication.
>
>         - Nobody has responded with other comments or opposition.
>
>         Three respondents is not a very large number; it would be
>         helpful if others would chime in.
>
>         The WGLC period is scheduled to end tomorrow.
>
>         Thanks,
>
>         --John
>
>         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.
>
>         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] <mailto:[e-mail]>
>
>         https://www.ietf.org/mailman/listinfo/idr
>         <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.
>
>     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] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/idr
>     <https://www.ietf.org/mailman/listinfo/idr>
>
>