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

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

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