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

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

Hi Dave,
  Did you get comments or reply from any author?

Thanks,
Pavana.

On Wed, May 9, 2018 at 3:40 AM, David Smith (djsmith) <[e-mail]>
wrote:

> Hi Pavana,
>
>
>
> This is a good question and not currently described in the redirect-ip
> draft so I’ll defer to the authors for additional comments. In the
> meantime, I’ll also mention the following:
>
> ·        “IF” transit ASes are able to modify a redirect-ip flowspec
> “target address”, then it would make sense to compare with the peer AS of
> the redirect-ip flowspec. However, this isn’t covered in the current draft.
>
> ·        Otherwise, it would make sense to compare the origin ASes or the
> whole AS-PATHs for a redirect-ip flowspec.
>
>
>
> Regards,
>
>
>
> /dave
>
>
>
>
>
> *From:* PVLR Pavana Murthy <[e-mail]>
> *Sent:* Sunday, May 06, 2018 9:32 AM
>
> *To:* David Smith (djsmith) <[e-mail]>
> *Cc:* idr wg <[e-mail]>; Pradosh Mohapatra <[e-mail]>;
> [e-mail]; Simpson, Adam 1. (Nokia -
> CA/Ottawa) <[e-mail]>
> *Subject:* Re: Validation for BGP Flow-Spec Redirect to IP Action
>
>
>
> Hi Dave,
>
>   What is the possible reason or explanation for comparing the origin AS
> of best match route of target X with the peer-as of the flowspec route
> instead of comparing origin AS of both the routes?
>
>
>
> Thanks,
>
> Pavana.
>
>
>
> On Fri, May 4, 2018 at 11:23 PM, David Smith (djsmith) <[e-mail]>
> wrote:
>
> Hi Pavana,
>
>
>
> The redirect-ip draft specifies this additional validation step as the
> default behavior, however, it also allows it to be disabled via
> configuration.
>
>
>
> Regards,
>
>
>
> /dave
>
>
>
>
>
> *From:* PVLR Pavana Murthy <[e-mail]>
> *Sent:* Friday, May 04, 2018 11:42 AM
> *To:* David Smith (djsmith) <[e-mail]>
> *Cc:* idr wg <[e-mail]>; Pradosh Mohapatra <[e-mail]>;
> [e-mail]; Simpson, Adam 1. (Nokia -
> CA/Ottawa) <[e-mail]>
>
>
> *Subject:* Re: Validation for BGP Flow-Spec Redirect to IP Action
>
>
>
> Hi Dave and Adam,
>
>   Thanks for the reply.
>
>
>
> Lets take the example as I gave earlier.
>
>
>
>     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 of Flowspec route is 2
>
>
>
> According to Dave,since the peer-AS 2 does not match the origin AS 1 of
> the best route for target X,  this redirect IP action will be  considered
> invalid for the flowspec route received at C.
>
> This is a typical scenario. Like this, we can't propagate the Flowspec
> routes with "redirect IP" action, more than one AS. I think, that's not
> expected.
>
>
>
> I feel, we should compare origin AS or neighbor-as for both Flowspec route
> and the best match route of target X. We should not be using peer-AS for
> flowspec route and nbr-as for best match route of target x. Otherwise the
> above typical scenarios never work.
>
> Probably, we need to edit the draft for "redirect-ip" action.
>
>
>
> Thanks,
>
> Pavana.
>
>
>
> On Thu, May 3, 2018 at 11:08 PM, David Smith (djsmith) <[e-mail]>
> wrote:
>
> Hi Pavana,
>
>
>
> >I went through the latest draft-ietf-idr-bgp-flowspec-oid-06. It calls
> the first AS the Origin AS. Is it so?
>
>
>
> Correct, first AS = first AS added = last AS in AS_PATH_SEQ hex-string =
> origin AS.
>
> last AS = last AS added = first AS in AS_PATH_SEQ hex-string = neighboring
> AS.
> neighbor AS = peering AS: if update is coming from EBGP and
> enforce-first-AS used -as mandated by RFC 5575.
>
> Note that draft-ietf-idr-bgp-flowspec-oid-06 uses 'last  AS *added*' in
> most cases, and when it does just use 'last AS', it can be inferred.
>
>
>
> >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?
>
>
>
> The RFC 5575 validation procedure required that for EBGP learned flowspecs
> the ‘neighboring AS’ be in the left-most (or last) position of the AS_PATH
> attribute. Since this is not valid for all topologies,
> draft-ietf-idr-bgp-flowspec-oid-06 redefines the BGP flowspec validation
> procedures including AS_PATH attribute. Further, the redirect-ip draft
> imposes an additional AS_PATH validation check (specific for redirect-ip
> flowspecs only) to validate that the best matching route to the redirect-ip
> 'target address' is a BGP route with origin AS matching the last AS added
> within the AS_PATH attribute of the redirect-ip flowspec. As
>
>
>
> >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?
>
>
>
> See feedback above. Draft-ietf-idr-bgp-flowspec-oid-06 only needs to
> consider last AS while redirect-ip draft needs to consider both per above.
>
>
>
> >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 (for redirect-ip target address)?
>
>
>
> The redirect-ip draft allows for its added validation check to be disabled
> via configuration. This allows for a non-BGP route to the redirect-ip
> target address.
>
>
>
> Regards,
>
>
>
> /dave
>
>
>
>
>
> *From:* PVLR Pavana Murthy <[e-mail]>
> *Sent:* Saturday, April 28, 2018 12:40 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]
> *Subject:* Re: Validation for BGP Flow-Spec Redirect to IP Action
>
>
>
> 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.
>
>
>
>
>
>
>
>
>
>
>
>
>