Re: [Idr] Validation for BGP Flow-Spec Redirect to IP Action

[PVLR Pavana Murthy <[e-mail]>]

Hi Adam,
   In draft-ietf-idr-bgp-flowspec-oid-06(Revised Validation Procedure for
BGP Flow Specifications), the following is mentioned.  Probably this could
be the reason to use the  peer-as.

"Note, comparing only the last ASes is
sufficient for EBGP learned flow specification NLRIs. Requiring a
full AS_PATH match would limit origination of inter-domain flow
specifications to the origin (or first) AS of the best-match unicast
route for the destination prefix embedded in the flow specification
only. As such, a full AS_PATH validity check may prevent transit
ASes from originating inter-domain flow specifications which is not
desirable."


Also in draft-ietf-idr-flowspec-redirect-ip-00.txt, the term 'las AS' is
used instead of 'Origin As'. Even the CISCO document (
https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r5-2/routing/configuration/guide/b_routing_cg52xasr9k/b_routing_cg52xasr9k_chapter_011.html
)  uses the term 'last AS'.


Anyways, thanks for explaining the philosophy behind the validation.

-Pavana.


On Mon, Apr 30, 2018 at 9:00 PM, Simpson, Adam 1. (Nokia - CA/Ottawa) <
[e-mail]> wrote:

> Hi Pavana,
>
>
>
> Peer-AS is not a consideration in draft -02. I don’t recall why it was
> mentioned in an earlier version of the draft.
>
>
>
> If the routers inside B and C enable the extra validation check (it is
> optional as explained in the draft) then they would only install a flowspec
> route originated by a router inside A ,with a redirect-to-IP action, if the
> redirect IP address itself was observed to originate inside A as well.
>
>
>
> So flow-spec routes originated by one AS can be valid in another AS, but
> only under restrictive circumstances.
>
>
>
> -Adam
>
>
>
> *From: *PVLR Pavana Murthy <[e-mail]>
> *Date: *Monday, April 30, 2018 at 2:24 AM
> *To: *"Simpson, Adam 1. (Nokia - CA/Ottawa)" <[e-mail]>
> *Cc: *"David Smith (djsmith)" <[e-mail]>, idr wg <[e-mail]>,
> Pradosh Mohapatra <[e-mail]>, "draft-ietf-idr-bgp-flowspec-
> [e-mail]" <[e-mail]>, "[e-mail]"
> <[e-mail]>, "[e-mail]" <[e-mail]>, "
> [e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>,
> "[e-mail]" <[e-mail]>, "
> [e-mail]" <[e-mail]>, "
> [e-mail]" <[e-mail]>
>
> *Subject: *Re: Validation for BGP Flow-Spec Redirect to IP Action
>
>
>
> Hi Adam,
>
>   Thanks for the reply. If its the first AS that is added to the AS_PATH,
> then "the redirect IP" action received from the AS's that are not directly
> connected may be invalid always.
>
>
>
> eg:
>
>     A---B----C
>
>
>
> A, B and C are 3 routers in different AS's  1, 2 and 3 respectively.
>
> A advertises a route for target X and also a Flowspec route with
> "redirect  IP(target X)". C receives these routes via B.
>
> Now the the origin AS or first AS in the AS_PATH of the route to target X
> is 1 but the peer-AS is 2 since the route is received from B.
>
> Since the peer-AS does not match the first AS of the best route target X,
> this redirect IP action is considered invalid.
>
>
>
>
>
> Please let me know if that's expected.
>
>
>
> --Pavana.
>
>
>
> On Mon, Apr 30, 2018 at 1:12 AM, Simpson, Adam 1. (Nokia - CA/Ottawa) <
> [e-mail]> wrote:
>
> Hi Pavana,
>
>
>
> The purpose of this text in the draft was to close the door on the ability
> for an accidental/malicious originator of a flow-spec route in AS=x from
> redirecting flows towards a target IP address in some other AS=y.
>
>
>
> So, in this context we are interested in looking at the first AS in
> AS_PATH of the flow-spec route, not the most recently added AS in the
> AS_PATH (which would be the ‘neighbor AS’).
>
>
>
> The route that resolves the target redirect IP address could be a BGP
> route or it could be a non-BGP route, despite the wording in the draft. If
> it is a BGP route the origin AS is determined as described above. If is a
> non-BGP route it would probably be appropriate to consider the route as
> locally originated (i.e. the same as a BGP route with null/empty AS_PATH or
> having only confed related elements).
>
>
>
> I hope this helps.
>
>
>
> -Adam
>
>
>
>
>
> *From: *PVLR Pavana Murthy <[e-mail]>
> *Date: *Saturday, April 28, 2018 at 12:45 AM
> *To: *"David Smith (djsmith)" <[e-mail]>
> *Cc: *idr wg <[e-mail]>, Pradosh Mohapatra <[e-mail]>, "
> [e-mail]" <draft-ietf-idr-bgp-flowspec-
> [e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <[e-mail]>, "
> [e-mail]" <[e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <
> [e-mail]>, "Simpson, Adam 1. (Nokia - CA/Ottawa)"
> <[e-mail]>, "[e-mail]" <[e-mail]>
> *Subject: *Re: Validation for BGP Flow-Spec Redirect to IP Action
>
>
>
> Hello,
>
>   Including all the authors mentioned in draft-ietf-idr-flowspec-redirect-ip-02,
> as the alias did not work. Also pasting doubts again here.
>
>
>
> In the draft  draft-ietf-idr-flowspec-redirect-ip-02.txt, the following
> procedure is mentioned to validate the extended community of 'Flowspec
>
> redirect to IP'.
>
>
>
>    BGP speakers that support the extended communities defined in this
>
>    draft MUST also, by default, enforce the following check when
>
>    receiving a flow-spec route from an EBGP peer: if the received flow-
>
>    spec route has a 'redirect to IP' extended community with a 'target
>
>    address' X (in the global administrator field) and the best matching
>
>    route to X is not a BGP route with *origin AS* matching the peer AS
>
>    then the extended community should be discarded and not propagated
>
>    along with the flow-spec route to other peers.
>
>
>
> *I have 2 doubts related to this statement.*
>
>
>
> *What is 'origin AS' here? Is it the AS no. that is first added to the AS_PATH? *
> *In the previous version of the draft its mentioned as the last AS in the AS_PATH.*
> *Is it the last AS no. that has been added to the AS_PATH or the last AS no. from left in AS_PATH? *
>
>
>
> *What if the redirect target X is directly connected or reachable by a static route and its not advertised by EBGP?*
>
> *Do we need to consider that action invalid in that case?*
>
>
>
> Thanks,
>
> Pavana.
>
>
>
>
>
> On Sat, Apr 28, 2018 at 10:10 AM, PVLR Pavana Murthy <[e-mail]>
> wrote:
>
> Hi Dave,
>
>    Thanks for the reply and including respective draft author aliases.
>
>
>
> I went through the latest draft-ietf-idr-bgp-flowspec-oid-06. It calls
> the first AS the Origin AS. Is it so?
>
> If that's the case, the validation will fail for any 'redirect IP' actions
> coming from the AS other than neighbor AS. Is that the intention?
>
> Also In  draft-ietf-idr-flowspec-redirect-ip-00.txt, instead of 'origin
> AS', the word 'last AS' is used.It is confusing.   Does the validation need
> to consider the first AS or last AS?
>
>
>
> Regarding my second doubt, I could not get any pointers from
> draft-ietf-idr-bgp-flowspec-oid-06 .  Do we need to consider only BGP
> routes always?
>
>
>
> Thanks,
>
> Pavana.
>
>
>
>
> On Sat, Apr 28, 2018 at 3:37 AM, David Smith (djsmith) <[e-mail]>
> wrote:
>
> Hi Pavana,
>
>
>
> Your points are valid. With that said, I’ll defer you to
> draft-ietf-idr-bgp-flowspec-oid-05 (and later) and, specifically, section
> 4 (revised validation procedure) which addresses your points below.
>
>
>
> Co-incidentally, a WG last call was issued for draft-ietf-idr-bgp-flowspec-oid-06
> yesterday.
>
>
>
> Regards,
>
>
>
> /dave
>
>
>
>
>
> *From:* PVLR Pavana Murthy <[e-mail]>
> *Sent:* Friday, April 13, 2018 1:51 AM
> *To:* idr wg <[e-mail]>; [e-mail]; David Smith
> (djsmith) <[e-mail]>
> *Subject:* Validation for BGP Flow-Spec Redirect to IP Action
>
>
>
> Hello,
>
>   In the draft  draft-ietf-idr-flowspec-redirect-ip-02.txt, the following
> procedure is mentioned to validate the extended community of 'Flowspec
>
> redirect to IP'.
>
>
>
>
>
>    BGP speakers that support the extended communities defined in this
>
>    draft MUST also, by default, enforce the following check when
>
>    receiving a flow-spec route from an EBGP peer: if the received flow-
>
>    spec route has a 'redirect to IP' extended community with a 'target
>
>    address' X (in the global administrator field) and the best matching
>
>    route to X is not a BGP route with *origin AS* matching the peer AS
>
>    then the extended community should be discarded and not propagated
>
>    along with the flow-spec route to other peers.
>
>
>
> *I have 2 doubts related to this statement.*
>
>
>
> *What is 'origin AS' here? Is it the AS no. that is first added to the AS_PATH? *
> *In the previous version of the draft its mentioned as the last AS in the AS_PATH.*
> *Is it the last AS no. that has been added to the AS_PATH or the last AS no. from left in AS_PATH? *
>
>
>
> *What if the redirect target X is directly connected or reachable by a static route and its not advertised by EBGP?*
>
> *Do we need to consider that action invalid in that case?*
>
>
>
>
>
> Thanks,
>
> Pavana.
>
>
>
>
>
>
>
>
>
>
>
>
>