Re: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route Server question)

[Zhuangshunwan]

Hi Sriram and all,

IMO, for the scenario described in the following email (AS4 and AS3 are P2P 
connection; AS3 and AS1 are connected via a RS and being treated as a P2P 
connection ), it can be determined that AS-PATH: AS4 AS3 AS1 is a route leak if 
one of the following conditions is met:
1. If AS1 is a Tier 1 ISP;
2. AS3 is not included in the set of C2P AS numbers set registered by AS1;
3. Determine that AS1 and AS3 are P2P relationships (one of the ways is to 
obtain them is: a) Create a P2P relationships database; b) lookup in the P2P 
relationships database);
4. AS4 detects that AS3 and AS1 are interconnected through IXP (for example, 
Traceroute), which is equivalent to a specific way of obtaining the P2P 
relationship between AS1 and AS3 in branch 3.
5. Make sure that AS3 is not the Customer of AS1 (it may be P2P, that is, 
branch 3;(or) it may be P2C).

Thanks,
Shunwan

> -Original Message-
> From: Sriram, Kotikalapudi (Fed) [mailto:kotikalapudi.sri...@nist.gov]
> Sent: Tuesday, March 22, 2022 5:09 AM
> To: Jakob Heitz (jheitz) ; Jeffrey Haas 
> Cc: sidr...@ietf.org; grow@ietf.org; Zhuangshunwan
> ; Nick Hilliard 
> Subject: RE: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route
> Server question)
> 
> Hi Jakob,
> 
> >To be clear, I'm talking about BGP devices that do not insert their ASN into
> the AS path.
> 
> Even if you assume that all route servers are transparent, what would you
> like to propose to solve the following problem?
> 
> AS1 (RS Client) -> AS2 (RS) ->  AS3 (RS Client) ---p2p (lateral peer) 
> --->
> AS4 (validating AS)
> 
> The arrows indicate the direction of the flow of the Update. Let us say that
> the RS is transparent.
> 
> AS4 is the receiving/validating AS. The AS path is {AS3 AS1}. Do you agree
> this is a route leak as seen at AS4? The question is how will AS4 detect it?
> What ASPAs should be in place?
> 
> Suppose the RS-clients (i.e., AS1 and AS3) have ASPAs each attesting the RS's
> AS (i.e., AS2) as a provider. That is all that it takes for AS4 to be able to 
> detect
> the leak.
> 
> Is there another way? Do we assume that AS1 and AS3 have some other ISP
> provider(s) for which they have ASPA attestation?
> 
> In this solution, AS4 does not have to know anything about the presence of
> an RS, etc.
> 
> This solution works fine even if the RS happens to be non-transparent.
> 
> In an earlier related thread,
> 
> https://mailarchive.ietf.org/arch/browse/sidrops/?gbt=1=I2a05YrOEY
> rRRdEg1ZHOOln6BCw
> 
> Nick Hillard and Rob Mosher left the door slightly open for a possibility that
> there might be a rare RS out there that is non-transparent.
> 
> Sriram

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route Server question)

[Sriram, Kotikalapudi (Fed)]

Hi Jakob,

>To be clear, I'm talking about BGP devices that do not insert their ASN into 
>the AS path.

Even if you assume that all route servers are transparent, what would you like 
to propose to solve the following problem? 

AS1 (RS Client) -> AS2 (RS) ->  AS3 (RS Client) ---p2p (lateral peer) 
--->  AS4 (validating AS)

The arrows indicate the direction of the flow of the Update. Let us say that 
the RS is transparent.

AS4 is the receiving/validating AS. The AS path is {AS3 AS1}. Do you agree this 
is a route leak as seen at AS4? The question is how will AS4 detect it? What 
ASPAs should be in place?

Suppose the RS-clients (i.e., AS1 and AS3) have ASPAs each attesting the RS's 
AS (i.e., AS2) as a provider. That is all that it takes for AS4 to be able to 
detect the leak.

Is there another way? Do we assume that AS1 and AS3 have some other ISP 
provider(s) for which they have ASPA attestation? 

In this solution, AS4 does not have to know anything about the presence of an 
RS, etc. 

This solution works fine even if the RS happens to be non-transparent.

In an earlier related thread,

https://mailarchive.ietf.org/arch/browse/sidrops/?gbt=1=I2a05YrOEYrRRdEg1ZHOOln6BCw

Nick Hillard and Rob Mosher left the door slightly open for a possibility that 
there might be a rare RS out there that is non-transparent.

Sriram

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] NACM for action: Re: New draft: Yanog module for BMP - draft-cptb-grow-bmp-yang

[tom petch]

From: Benoit Claise 
Sent: 19 March 2022 17:27

Hi Tom,

Great feedback.

I would like to come back your NACM comment below.
We added "nacm:default-deny-all" to our action (in our temp version).

I have not been following the detailed history of
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-13. And I
don't know whether this point was already discussed but I was surprised
to observe that this draft does not have "nacm:default-deny-all" for its
action. Bringing this issue here since I guess we deal with the same set
of people in GROW/IDR.


Benoit

I think that this is one for IDR rather than GROW, that is it is just a 
question of getting the authors to include it,  not a question of good 
operational practice to include or not include it.  I don't think I have 
commented on bgp-model lately - there is much in it that I would rather were 
done differently such as how many separate modules and submodules there should 
be.  For the latter, I start at zero and do not count upwards.

Tom Petch
Regards, Benoit


On 3/11/2022 5:43 PM, tom petch wrote:
> From: GROW  on behalf of Camilo Cardona 
> 
> Sent: 07 March 2022 10:06
> Hi Grow,
>
> We just submitted a new draft proposing a yang module for configuring and 
> managing BMP on a device.
>
> It would be nice to get some comments, observations, etc.
>
> 
>
> prefix bmp seems more than adequate to me - ietf in the name but not in the 
> prefix
>
> import must have a reference and the reference must be Normative References 
> for the I-D
>
> YANG must be plain text - I am always suspicious of [] as in
>  "[RFC-to-be]: BMP YANG Module";
>
> an enum with only one value  could do with an explanation
> looking at how it is used, I do not understand it
>
> your ip type include the zone - is this intended?
>
> leaf destination-port {
>   type inet:ip-address;
> looks like an oxymoron
>
> statistics interval has no units
>
> statistics commonly have a discontinuity leaf
>
> unit32 may be small for counters
>
> actions commonly have a NACM default deny-all
>
> '   BGP data is sensible for security considerations.'
>   looks a bit odd
>
> IANA considerations are incomplete - you must register the prefix
>
> YANG needs references, BGP. BMP!. etc
>
> This  e-mail comes from two addresses neither of which are the address in the 
> I-D; I wonder if they will bounce:-(
>
>
> Have a 'nice' day,
>
> Tom Petch
>
> Grow Chairs, will it be possible to get a 5 minute slot in the next session 
> to give an overview of this module?
>
> Thanks,
> Camilo Cardona
>
>
>
>> On 7/3/22, 10:51, "internet-dra...@ietf.org"  
>> wrote:
>>
>>
>> A new version of I-D, draft-cptb-grow-bmp-yang-01.txt
>> has been successfully submitted by Camilo Cardona and posted to the
>> IETF repository.
>>
>> Name:  draft-cptb-grow-bmp-yang
>> Revision:  01
>> Title: BMP YANG Module
>> Document date: 2022-03-07
>> Group: Individual Submission
>> Pages: 14
>> URL:
>> https://www.ietf.org/archive/id/draft-cptb-grow-bmp-yang-01.txt
>> Status: 
>> https://datatracker.ietf.org/doc/draft-cptb-grow-bmp-yang/
>> Htmlized:   
>> https://datatracker.ietf.org/doc/html/draft-cptb-grow-bmp-yang
>> Diff:   
>> https://www.ietf.org/rfcdiff?url2=draft-cptb-grow-bmp-yang-01
>>
>> Abstract:
>>This document proposes a YANG module for BMP (BGP Monitoring
>>Protocol) configuration and monitoring.  A complementary RPC triggers
>>a refresh of the session of a BMP station.
>>
>>
>>
>>
>> The IETF Secretariat
>>
>>
>>
>>
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route Server question)

[Jakob Heitz (jheitz)]

To be clear, I'm talking about BGP devices that do not insert their ASN into 
the AS path.
I understand that route leaks can happen after a route server.
My point is that such a route leak is of no concern to ASPA.

Regards,
Jakob.

From: Jeffrey Haas 
Sent: Monday, March 21, 2022 9:43 AM
To: Zhuangshunwan 
Cc: Jakob Heitz (jheitz) ; Gyan Mishra 
; Sriram, Kotikalapudi (Fed) 
; Ben Maddison 
; sidr...@ietf.org; grow@ietf.org
Subject: Re: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route Server 
question)

Two comments here:

If the BGP Speaker is inserting itself into the AS_PATH, it's not really a 
Route Server in the traditional sense.

A normal BGP Speaker can happily pass along routes via eBGP peering with the 
nexthop unchanged with all devices that it shares a common nexthop subnet with.

My recommendation is to not to try to consider these devices a Route Server.  
For ASPA purposes, just add the BGP connections to the inputs.

If providers are unhappy with having a IXP router's AS in the ASPA data and 
thus lose the desired ASPA filtering properties, the IXP should install a real 
route server.

-- Jeff



On Mar 21, 2022, at 11:48 AM, Zhuangshunwan 
mailto:zhuangshunwan=40huawei@dmarc.ietf.org>>
 wrote:

+1
I think Jacob's suggestion is reasonable.
I once worked on a route leak analysis project. There is a first step in that 
project, which is to clear the IXP’s AS number added to the AS-PATH by the 
non-transparent RS.
The basic idea is that a path segment “AS1 - ASx - RS’s ASN - ASy - ASn” (where 
ASx and ASy are RS-clients connected in BGP via the RS) will be corrected to 
“AS1 - ASx - ASy - ASn”.
With this process, we can exclude the influence of non-transparent RS on the 
accuracy of route-leak analysis.

Kind Regards,
Shunwan

From: Jakob Heitz (jheitz) [mailto:jhe...@cisco.com]
Sent: Monday, March 21, 2022 11:13 PM
To: Gyan Mishra mailto:hayabusa...@gmail.com>>; Sriram, 
Kotikalapudi (Fed) 
mailto:kotikalapudi.sriram=40nist@dmarc.ietf.org>>
Cc: Ben Maddison mailto:benm@workonline.africa>>; 
sidr...@ietf.org; grow@ietf.org; 
Zhuangshunwan mailto:zhuangshun...@huawei.com>>; Nick 
Hilliard mailto:n...@foobar.org>>
Subject: RE: [Sidrops] [GROW] ASPA and Route Server (was RE: IXP Route Server 
question)

Route servers are a distraction for ASPA.
ASPA is about BGP path validation.
As such it concerns itself with ASNs in the AS path.
It is about relationships between adjacent ASes in the AS path.
Since RSes are not in the AS path, they cannot be included in ASPA.
RSes are only visible and relevant to the direct neighbors of the RS.
The ASN of the RS does not appear in the AS path, therefore it is of no concern 
to anyone that is trying to validate the AS path.
Could we please remove all references to route servers from the ASPA draft and 
issue a new draft about treatment of route servers only?

Regards,
Jakob.

From: Sidrops mailto:sidrops-boun...@ietf.org>> On 
Behalf Of Gyan Mishra
Sent: Sunday, March 20, 2022 9:20 AM
To: Sriram, Kotikalapudi (Fed) 
mailto:kotikalapudi.sriram=40nist@dmarc.ietf.org>>
Cc: Ben Maddison mailto:benm@workonline.africa>>; 
sidr...@ietf.org; grow@ietf.org; 
Zhuangshunwan mailto:zhuangshun...@huawei.com>>; Nick 
Hilliard mailto:n...@foobar.org>>
Subject: Re: [Sidrops] [GROW] ASPA and Route Server (was RE: IXP Route Server 
question)


Hi Sriram

On Sun, Mar 20, 2022 at 10:59 AM Sriram, Kotikalapudi (Fed) 
mailto:40nist@dmarc.ietf.org>>
 wrote:
I think a correction is required. Instead of what was said before -

#1: An RS client of an RS (transparent or not) includes the RS AS in their 
SPAS/ASPA. The RS client also includes in its SPAS/ASPA any AS with whom it 
connects in the control plane via the RS.

only the following simpler statement is required in the draft:

#2: An RS client of an RS (transparent or not) includes the RS AS in their 
SPAS/ASPA.

The reason is as follows. Consider the following topology and Update flow per 
arrows:

AS1 (RS Client) -> AS2 (RS) ->  AS3 (RS Client) ---p2p (lateral peer) 
--->  AS4 (validating AS)

AS4 is the receiving/validating AS. Regardless of whether the RS inserts its 
ASN in the AS path or not, the Update is Invalid (route leak) at AS4. Because 
once the Update transitioned to a downward path after the RS, it cannot be 
subsequently sent to a provider or lateral peer. But with #1, the Update will 
be evaluated as Valid (not route leak) by the ASPA verification procedure in 
case the RS is transparent. But with #2, the Update will be correctly detected 
as a route leak (whether the RS is transparent or not).

Explanation: With #1, the hop AS1-AS3 in the transparent case is evaluated as 
Valid (C2P) (as part of an ascending up-ramp on the left) by the procedure and 
that is not good. I.e., the detection of the apex in the AS path at the RS (not 
visible in the path) and inversion (non-upward flow) after 

Re: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route Server question)

[Jeffrey Haas]

Two comments here:

If the BGP Speaker is inserting itself into the AS_PATH, it's not really a 
Route Server in the traditional sense.

A normal BGP Speaker can happily pass along routes via eBGP peering with the 
nexthop unchanged with all devices that it shares a common nexthop subnet with.

My recommendation is to not to try to consider these devices a Route Server.  
For ASPA purposes, just add the BGP connections to the inputs.

If providers are unhappy with having a IXP router's AS in the ASPA data and 
thus lose the desired ASPA filtering properties, the IXP should install a real 
route server.

-- Jeff


> On Mar 21, 2022, at 11:48 AM, Zhuangshunwan 
>  wrote:
> 
> +1
> I think Jacob's suggestion is reasonable.
> I once worked on a route leak analysis project. There is a first step in that 
> project, which is to clear the IXP’s AS number added to the AS-PATH by the 
> non-transparent RS.
> The basic idea is that a path segment “AS1 - ASx - RS’s ASN - ASy - ASn” 
> (where ASx and ASy are RS-clients connected in BGP via the RS) will be 
> corrected to “AS1 - ASx - ASy - ASn”.
> With this process, we can exclude the influence of non-transparent RS on the 
> accuracy of route-leak analysis.
>  
> Kind Regards,
> Shunwan
>  
> From: Jakob Heitz (jheitz) [mailto:jhe...@cisco.com] 
> Sent: Monday, March 21, 2022 11:13 PM
> To: Gyan Mishra ; Sriram, Kotikalapudi (Fed) 
> 
> Cc: Ben Maddison ; sidr...@ietf.org; grow@ietf.org; 
> Zhuangshunwan ; Nick Hilliard 
> Subject: RE: [Sidrops] [GROW] ASPA and Route Server (was RE: IXP Route Server 
> question)
>  
> Route servers are a distraction for ASPA.
> ASPA is about BGP path validation.
> As such it concerns itself with ASNs in the AS path.
> It is about relationships between adjacent ASes in the AS path.
> Since RSes are not in the AS path, they cannot be included in ASPA.
> RSes are only visible and relevant to the direct neighbors of the RS.
> The ASN of the RS does not appear in the AS path, therefore it is of no 
> concern to anyone that is trying to validate the AS path.
> Could we please remove all references to route servers from the ASPA draft 
> and issue a new draft about treatment of route servers only?
>  
> Regards,
> Jakob.
>  
> From: Sidrops mailto:sidrops-boun...@ietf.org>> On 
> Behalf Of Gyan Mishra
> Sent: Sunday, March 20, 2022 9:20 AM
> To: Sriram, Kotikalapudi (Fed)  >
> Cc: Ben Maddison mailto:benm@workonline.africa>>; 
> sidr...@ietf.org ; grow@ietf.org 
> ; Zhuangshunwan  >; Nick Hilliard  >
> Subject: Re: [Sidrops] [GROW] ASPA and Route Server (was RE: IXP Route Server 
> question)
>  
>  
> Hi Sriram
>  
> On Sun, Mar 20, 2022 at 10:59 AM Sriram, Kotikalapudi (Fed) 
>  > wrote:
> I think a correction is required. Instead of what was said before -
> 
> #1: An RS client of an RS (transparent or not) includes the RS AS in their 
> SPAS/ASPA. The RS client also includes in its SPAS/ASPA any AS with whom it 
> connects in the control plane via the RS.
> 
> only the following simpler statement is required in the draft:
> 
> #2: An RS client of an RS (transparent or not) includes the RS AS in their 
> SPAS/ASPA. 
> 
> The reason is as follows. Consider the following topology and Update flow per 
> arrows:
> 
> AS1 (RS Client) -> AS2 (RS) ->  AS3 (RS Client) ---p2p (lateral peer) 
> --->  AS4 (validating AS)
> 
> AS4 is the receiving/validating AS. Regardless of whether the RS inserts its 
> ASN in the AS path or not, the Update is Invalid (route leak) at AS4. Because 
> once the Update transitioned to a downward path after the RS, it cannot be 
> subsequently sent to a provider or lateral peer. But with #1, the Update will 
> be evaluated as Valid (not route leak) by the ASPA verification procedure in 
> case the RS is transparent. But with #2, the Update will be correctly 
> detected as a route leak (whether the RS is transparent or not). 
> 
> Explanation: With #1, the hop AS1-AS3 in the transparent case is evaluated as 
> Valid (C2P) (as part of an ascending up-ramp on the left) by the procedure 
> and that is not good. I.e., the detection of the apex in the AS path at the 
> RS (not visible in the path) and inversion (non-upward flow) after the RS is 
> obscured with #1 (in the transparent case). However, with #2, the hop AS1-AS3 
> is evaluated as "attested not Provider". That means that the detection of 
> apex/inversion at the RS (though not visible in the path) is effectively not 
> missed out by the procedure with #2. 
> 
> Thank you.
> 
> Sriram  
> 
> -Original Message-
> From: GROW mailto:grow-boun...@ietf.org>> On Behalf 
> Of Sriram, Kotikalapudi (Fed)
> Sent: Tuesday, March 15, 2022 11:34 AM
> To: Nick Hilliard mailto:n...@foobar.org>>
> Cc: Ben Maddison mailto:benm@workonline.africa>>; 
> grow@ietf.org 

Re: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route Server question)

[Gyan Mishra]

Thanks Sriram

Gyan
On Mon, Mar 21, 2022 at 11:53 AM Sriram, Kotikalapudi (Fed)
 wrote:

> Hi Gyan,
>
> >Gyan>I understand the issue with the ASPA path verification, however if
> the RS AS added to ASPA then that would influence the forwarding plane is
> the issue.  How do you insert RS AS for the ASPA path verification but not
> allow RS to be part of forwarding plane?  I guess you could do a
> next-hop-unchanged between the clients connected through the RS.
>
> Is this the confirmation (from RFC7947, Sec. 2.2.1) that you are looking
> for?
>
> "... As the route server
>does not participate in the actual routing of traffic, the NEXT_HOP
>attribute MUST be passed unmodified to the route server clients,..."
>
> Sriram
>
>
> ___
> Sidrops mailing list
> sidr...@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops
>
-- 



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route Server question)

[Zhuangshunwan]

+1
I think Jacob's suggestion is reasonable.
I once worked on a route leak analysis project. There is a first step in that 
project, which is to clear the IXP’s AS number added to the AS-PATH by the 
non-transparent RS.
The basic idea is that a path segment “AS1 - ASx - RS’s ASN - ASy - ASn” (where 
ASx and ASy are RS-clients connected in BGP via the RS) will be corrected to 
“AS1 - ASx - ASy - ASn”.
With this process, we can exclude the influence of non-transparent RS on the 
accuracy of route-leak analysis.

Kind Regards,
Shunwan

From: Jakob Heitz (jheitz) [mailto:jhe...@cisco.com]
Sent: Monday, March 21, 2022 11:13 PM
To: Gyan Mishra ; Sriram, Kotikalapudi (Fed) 

Cc: Ben Maddison ; sidr...@ietf.org; grow@ietf.org; 
Zhuangshunwan ; Nick Hilliard 
Subject: RE: [Sidrops] [GROW] ASPA and Route Server (was RE: IXP Route Server 
question)

Route servers are a distraction for ASPA.
ASPA is about BGP path validation.
As such it concerns itself with ASNs in the AS path.
It is about relationships between adjacent ASes in the AS path.
Since RSes are not in the AS path, they cannot be included in ASPA.
RSes are only visible and relevant to the direct neighbors of the RS.
The ASN of the RS does not appear in the AS path, therefore it is of no concern 
to anyone that is trying to validate the AS path.
Could we please remove all references to route servers from the ASPA draft and 
issue a new draft about treatment of route servers only?

Regards,
Jakob.

From: Sidrops mailto:sidrops-boun...@ietf.org>> On 
Behalf Of Gyan Mishra
Sent: Sunday, March 20, 2022 9:20 AM
To: Sriram, Kotikalapudi (Fed) 
mailto:kotikalapudi.sriram=40nist@dmarc.ietf.org>>
Cc: Ben Maddison mailto:benm@workonline.africa>>; 
sidr...@ietf.org; grow@ietf.org; 
Zhuangshunwan mailto:zhuangshun...@huawei.com>>; Nick 
Hilliard mailto:n...@foobar.org>>
Subject: Re: [Sidrops] [GROW] ASPA and Route Server (was RE: IXP Route Server 
question)


Hi Sriram

On Sun, Mar 20, 2022 at 10:59 AM Sriram, Kotikalapudi (Fed) 
mailto:40nist@dmarc.ietf.org>>
 wrote:
I think a correction is required. Instead of what was said before -

#1: An RS client of an RS (transparent or not) includes the RS AS in their 
SPAS/ASPA. The RS client also includes in its SPAS/ASPA any AS with whom it 
connects in the control plane via the RS.

only the following simpler statement is required in the draft:

#2: An RS client of an RS (transparent or not) includes the RS AS in their 
SPAS/ASPA.

The reason is as follows. Consider the following topology and Update flow per 
arrows:

AS1 (RS Client) -> AS2 (RS) ->  AS3 (RS Client) ---p2p (lateral peer) 
--->  AS4 (validating AS)

AS4 is the receiving/validating AS. Regardless of whether the RS inserts its 
ASN in the AS path or not, the Update is Invalid (route leak) at AS4. Because 
once the Update transitioned to a downward path after the RS, it cannot be 
subsequently sent to a provider or lateral peer. But with #1, the Update will 
be evaluated as Valid (not route leak) by the ASPA verification procedure in 
case the RS is transparent. But with #2, the Update will be correctly detected 
as a route leak (whether the RS is transparent or not).

Explanation: With #1, the hop AS1-AS3 in the transparent case is evaluated as 
Valid (C2P) (as part of an ascending up-ramp on the left) by the procedure and 
that is not good. I.e., the detection of the apex in the AS path at the RS (not 
visible in the path) and inversion (non-upward flow) after the RS is obscured 
with #1 (in the transparent case). However, with #2, the hop AS1-AS3 is 
evaluated as "attested not Provider". That means that the detection of 
apex/inversion at the RS (though not visible in the path) is effectively not 
missed out by the procedure with #2.

Thank you.

Sriram

-Original Message-
From: GROW mailto:grow-boun...@ietf.org>> On Behalf Of 
Sriram, Kotikalapudi (Fed)
Sent: Tuesday, March 15, 2022 11:34 AM
To: Nick Hilliard mailto:n...@foobar.org>>
Cc: Ben Maddison mailto:benm@workonline.africa>>; 
grow@ietf.org; sidr...@ietf.org
Subject: [GROW] ASPA and Route Server (was RE: [Sidrops] IXP Route Server 
question)

Nick (and all),

I was also rereading/reviewing Section 5.3 and had similar thoughts about the 
two options you outlined. As you noted, "the approach in Section 5.3 gives a 
workable outcome".  However...

>... the RS should be treated as a provider by the rs client; the rs client 
>should include the RS ASN in its SPAS; the rs client should evaluate ASPA as 
>if the RS ASN were included in the path; the rs should evaluate clients as 
>customers

Yes, I agree that "the rs client should include the RS ASN in its SPAS." 
Alexander and I have talked about this, and he mentioned that this would be 
added to the draft.

Yes, I also feel that it is a better option that the RS client adds the ASN of 
the transparent RS to the AS path (for ASPA validation 

Re: [GROW] ASPA and Route Server (was RE: [Sidrops] IXP Route Server question)

[Sriram, Kotikalapudi (Fed)]

Hi Gyan,

>Gyan>I understand the issue with the ASPA path verification, however if the RS 
>AS added to ASPA then that would influence the forwarding plane is the issue.  
>How do you insert RS AS for the ASPA path verification but not allow RS to be 
>part of forwarding plane?  I guess you could do a next-hop-unchanged between 
>the clients connected through the RS.

Is this the confirmation (from RFC7947, Sec. 2.2.1) that you are looking for?

"... As the route server
   does not participate in the actual routing of traffic, the NEXT_HOP
   attribute MUST be passed unmodified to the route server clients,..."

Sriram
 

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route Server question)

[Jakob Heitz (jheitz)]

Route servers are a distraction for ASPA.
ASPA is about BGP path validation.
As such it concerns itself with ASNs in the AS path.
It is about relationships between adjacent ASes in the AS path.
Since RSes are not in the AS path, they cannot be included in ASPA.
RSes are only visible and relevant to the direct neighbors of the RS.
The ASN of the RS does not appear in the AS path, therefore it is of no concern 
to anyone that is trying to validate the AS path.
Could we please remove all references to route servers from the ASPA draft and 
issue a new draft about treatment of route servers only?

Regards,
Jakob.

From: Sidrops  On Behalf Of Gyan Mishra
Sent: Sunday, March 20, 2022 9:20 AM
To: Sriram, Kotikalapudi (Fed) 
Cc: Ben Maddison ; sidr...@ietf.org; grow@ietf.org; 
Zhuangshunwan ; Nick Hilliard 
Subject: Re: [Sidrops] [GROW] ASPA and Route Server (was RE: IXP Route Server 
question)


Hi Sriram

On Sun, Mar 20, 2022 at 10:59 AM Sriram, Kotikalapudi (Fed) 
mailto:40nist@dmarc.ietf.org>>
 wrote:
I think a correction is required. Instead of what was said before -

#1: An RS client of an RS (transparent or not) includes the RS AS in their 
SPAS/ASPA. The RS client also includes in its SPAS/ASPA any AS with whom it 
connects in the control plane via the RS.

only the following simpler statement is required in the draft:

#2: An RS client of an RS (transparent or not) includes the RS AS in their 
SPAS/ASPA.

The reason is as follows. Consider the following topology and Update flow per 
arrows:

AS1 (RS Client) -> AS2 (RS) ->  AS3 (RS Client) ---p2p (lateral peer) 
--->  AS4 (validating AS)

AS4 is the receiving/validating AS. Regardless of whether the RS inserts its 
ASN in the AS path or not, the Update is Invalid (route leak) at AS4. Because 
once the Update transitioned to a downward path after the RS, it cannot be 
subsequently sent to a provider or lateral peer. But with #1, the Update will 
be evaluated as Valid (not route leak) by the ASPA verification procedure in 
case the RS is transparent. But with #2, the Update will be correctly detected 
as a route leak (whether the RS is transparent or not).

Explanation: With #1, the hop AS1-AS3 in the transparent case is evaluated as 
Valid (C2P) (as part of an ascending up-ramp on the left) by the procedure and 
that is not good. I.e., the detection of the apex in the AS path at the RS (not 
visible in the path) and inversion (non-upward flow) after the RS is obscured 
with #1 (in the transparent case). However, with #2, the hop AS1-AS3 is 
evaluated as "attested not Provider". That means that the detection of 
apex/inversion at the RS (though not visible in the path) is effectively not 
missed out by the procedure with #2.

Thank you.

Sriram

-Original Message-
From: GROW mailto:grow-boun...@ietf.org>> On Behalf Of 
Sriram, Kotikalapudi (Fed)
Sent: Tuesday, March 15, 2022 11:34 AM
To: Nick Hilliard mailto:n...@foobar.org>>
Cc: Ben Maddison mailto:benm@workonline.africa>>; 
grow@ietf.org; sidr...@ietf.org
Subject: [GROW] ASPA and Route Server (was RE: [Sidrops] IXP Route Server 
question)

Nick (and all),

I was also rereading/reviewing Section 5.3 and had similar thoughts about the 
two options you outlined. As you noted, "the approach in Section 5.3 gives a 
workable outcome".  However...

>... the RS should be treated as a provider by the rs client; the rs client 
>should include the RS ASN in its SPAS; the rs client should evaluate ASPA as 
>if the RS ASN were included in the path; the rs should evaluate clients as 
>customers

Yes, I agree that "the rs client should include the RS ASN in its SPAS." 
Alexander and I have talked about this, and he mentioned that this would be 
added to the draft.

Yes, I also feel that it is a better option that the RS client adds the ASN of 
the transparent RS to the AS path (for ASPA validation purposes only) and 
applies the downstream ASPA algorithm. Algorithmically this seems more 
appropriate. This is also better from a diagnostics point of view (if the need 
ever arises) because in this approach the relevant ASPA is used for validating 
the hop from the AS just before the RS to the RS.

That said, I think there is a bigger issue about transparent RS in the middle 
of the AS path. Maybe this is what Ben's question was hinting at. I think you 
are also raising this issue when you say:

>RSs do not partake in traffic forwarding, so they are not part of the data 
>path between two ASNs; they're only part of the signaling path between the two 
>ASNs.  This is a useful hack from a practical point of view, but it causes 
>algorithmic breakage in places which assume congruency between the data plane 
>and the signaling plane.  One of these places is AS path verification.

> ASPA verification should proceed as if the two rs-client ASNs were 
> directly connected and each should treat the other as a provider

Gyan>I understand the issue with the