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

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

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