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

[Zhuangshunwan]

Hi Sriram,

Functionally, your solution does detect the route leak.
But the actual operation may be difficult, how to encourage so many RS Clients 
to claim their ASPAs?
Or do we need to create an ASPA database with such ASPAs locally by collecting 
and analyzing Internet routing and data?

In a project I've been through, we did do something similar. We mine those RS 
Clients that are interconnected by IXP RS, and then create a P2P relational 
database for them.

Take the following topology as an example:

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

By some probing we can find AS1/AS3/AS5 are AS2 (RS)'s clients, so we can add 
AS-Pairs: {AS1 AS3}, {AS1 AS5}, {AS3 AS5} into the local P2P AS-Relationships 
database.

By the similar method, we can also create a local RS-Client to RS ASPA 
database. 

Kind Regards,
Shunwan


> -Original Message-
> From: Sriram, Kotikalapudi (Fed) [mailto:kotikalapudi.sri...@nist.gov]
> Sent: Thursday, March 24, 2022 3:01 AM
> To: Zhuangshunwan ; Jakob Heitz (jheitz)
> ; Jeffrey Haas 
> Cc: sidr...@ietf.org; grow@ietf.org; Nick Hilliard 
> Subject: RE: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route
> Server question)
> 
> Hi Shunwan,
> 
> >> AS1 (RS Client) -> AS2 (RS) ->  AS3 (RS Client) ---p2p (lateral 
> >> peer) --->
> AS4 (validating AS)
> 
> >2. AS3 is not included in the set of C2P AS numbers set registered by AS1;
> 
> #2 (above) from your list is what we have focused on as a solution. Please
> see my previous post responding to Jakob where the set of ASPAs is
> enumerated.
> 
> 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 Jeff,

Thank you. We are now in sync with you. The design focuses only on transparent 
RS (i.e., the RS ASN does not appear in the AS path in BGP). We are assuming 
that non-transparent RS is rare/abnormal.  

It turns out that the solution that works for transparent RS also works for 
non-transparent RS with no extra effort. Just an observation, not saying that 
the non-transparent RS case has any importance. 

I have a talk in SIDROPS on Friday where the WG discussions will be summarized 
and a solution presented: 
"ASPA Verification Procedures: Enhancements and RS Considerations".

Sriram  

From: Jeffrey Haas  
Sent: Monday, March 21, 2022 12:43 PM
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

___
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)]

Ok. You are saying that's illegal.
A RS rule is that clients cannot be customers or providers of other clients.
That's fine, but it has nothing to do with ASPA.
Write it into another draft.

Regards,
Jakob.

-Original Message-
From: Sidrops  On Behalf Of Sriram, Kotikalapudi (Fed)
Sent: Wednesday, March 23, 2022 12:45 PM
To: Jakob Heitz (jheitz) ; Zhuangshunwan 
; Jeffrey Haas 
Cc: sidr...@ietf.org; grow@ietf.org; Nick Hilliard 
Subject: Re: [Sidrops] [GROW] ASPA and Route Server (was RE: IXP Route Server 
question)

>If AS1 attests that AS3 is its provider, then there is no leak.
>That would be weird, but is it illegal?

No that wouldn't work. If you propose that then for an Update that is 
propagating in the opposite direction, you would also want the reverse: 'AS3 
attests that AS1 is its provider'. That would make AS1 and AS3 siblings. Then 
the leak in question will not be detected (the ASPA verification outcome will 
be Valid)!

We considered and dismissed it before:
https://mailarchive.ietf.org/arch/msg/grow/bfchBrjqMqvMRoP7WrPR-OKOXT8/

Sriram
   

___
Sidrops mailing list
sidr...@ietf.org
https://www.ietf.org/mailman/listinfo/sidrops

___
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)]

>If AS1 attests that AS3 is its provider, then there is no leak.
>That would be weird, but is it illegal?

No that wouldn't work. If you propose that then for an Update that is 
propagating in the opposite direction, you would also want the reverse: 'AS3 
attests that AS1 is its provider'. That would make AS1 and AS3 siblings. Then 
the leak in question will not be detected (the ASPA verification outcome will 
be Valid)!

We considered and dismissed it before:
https://mailarchive.ietf.org/arch/msg/grow/bfchBrjqMqvMRoP7WrPR-OKOXT8/

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)]

If AS1 attests that AS3 is its provider, then there is no leak.
That would be weird, but is it illegal?

Regards,
Jakob.

-Original Message-
From: Sriram, Kotikalapudi (Fed)  
Sent: Wednesday, March 23, 2022 12:01 PM
To: Zhuangshunwan ; Jakob Heitz (jheitz) 
; Jeffrey Haas 
Cc: sidr...@ietf.org; grow@ietf.org; Nick Hilliard 
Subject: RE: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route Server 
question)

Hi Shunwan,

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

>2. AS3 is not included in the set of C2P AS numbers set registered by AS1;

#2 (above) from your list is what we have focused on as a solution. Please see 
my previous post responding to Jakob where the set of ASPAs is enumerated.  

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)]

That would work.
AS1 and AS3 could attest AS0 as provider. That would work too.
AS2 does not need an attestation, but any attestation that AS2 wants to make 
will make no difference.

Regards,
Jakob.

-Original Message-
From: Sriram, Kotikalapudi (Fed)  
Sent: Wednesday, March 23, 2022 11:57 AM
To: Jakob Heitz (jheitz) ; Zhuangshunwan 

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

Hi Jakob,

>> AS1 (RS Client) -> AS2 (RS) ->  AS3 (RS Client) ---p2p (lateral 
>> peer) ---> AS4 (validating AS)
...
>The AS-path at AS4 is (4 3 1).
>If you assume that AS1 and AS3 are bilateral peers, then both sides of AS3 
>declare AS3 not to be its provider. AS3 >has both sides non-customer. That's a 
>leak.

Right. It seems we agree. A set of APSAs needs to be in place. They can  be 
enumerated as follows:
{AS1, AS2} – AS1 attests AS2 (RS) as a provider
{AS3, AS2} – AS3 attests AS2 (RS) as a provider
{AS2, AS 0} – RS (AS2) creates an ASPA with AS 0  (this is already specified in 
the draft)

The first two ASPAs *implicitly* declare that AS3 is not a provider of AS1 and 
vice versa. That implies that they are p2p. AS4 does not need to look at its 
own ASPA. It knows it is p2p with AS3.

Specifying that each RS-client creates ASPA showing the RS as a provider is a 
solution component that we (Nick, me, Shunwan, ...) seem to be converging to.

Just to be sure the focus is on transparent RS.  

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 Shunwan,

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

>2. AS3 is not included in the set of C2P AS numbers set registered by AS1;

#2 (above) from your list is what we have focused on as a solution. Please see 
my previous post responding to Jakob where the set of ASPAs is enumerated.  

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,

>> AS1 (RS Client) -> AS2 (RS) ->  AS3 (RS Client) ---p2p (lateral 
>> peer) ---> AS4 (validating AS)
...
>The AS-path at AS4 is (4 3 1).
>If you assume that AS1 and AS3 are bilateral peers, then both sides of AS3 
>declare AS3 not to be its provider. AS3 >has both sides non-customer. That's a 
>leak.

Right. It seems we agree. A set of APSAs needs to be in place. They can  be 
enumerated as follows:
{AS1, AS2} – AS1 attests AS2 (RS) as a provider
{AS3, AS2} – AS3 attests AS2 (RS) as a provider
{AS2, AS 0} – RS (AS2) creates an ASPA with AS 0  (this is already specified in 
the draft)

The first two ASPAs *implicitly* declare that AS3 is not a provider of AS1 and 
vice versa. That implies that they are p2p. AS4 does not need to look at its 
own ASPA. It knows it is p2p with AS3.

Specifying that each RS-client creates ASPA showing the RS as a provider is a 
solution component that we (Nick, me, Shunwan, ...) seem to be converging to.

Just to be sure the focus is on transparent RS.  

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)]

The AS-path at AS4 is (4 3 1).
If you assume that AS1 and AS3 are bilateral peers, then both sides of AS3 
declare AS3 not to be its provider. AS3 has both sides non-customer. That's a 
leak.

Regards,
Jakob.


> On Mar 21, 2022, at 10:31 PM, Zhuangshunwan  wrote:
> 
> 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)

[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] [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<mailto:sidr...@ietf.org>; grow@ietf.org<mailto: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<mailto:sidr...@ietf.org>; grow@ietf.org<mailto: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 detect

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)  <mailto:kotikalapudi.sriram=40nist@dmarc.ietf.org>>
> Cc: Ben Maddison mailto:benm@workonline.africa>>; 
> sidr...@ietf.org <mailto:sidr...@ietf.org>; grow@ietf.org 
> <mailto: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 
> mi

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<mailto:sidr...@ietf.org>; grow@ietf.org<mailto: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<mailto:grow@ietf.org>; sidr...@ietf.org<mailto: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, 

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<mailto:grow@ietf.org>; sidr...@ietf.org<mailto: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 

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

[Sriram, Kotikalapudi (Fed)]

Hi Shunwan,

Please see the comments below marked with [KS].

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

[SW] IMO, this idea essentially solves the problem of ASPA verification.

[KS] Please see the previous message I posted on the list.

[SW] Regarding "The RS client also includes in its SPAS/ASPA any AS with whom 
it connects in the control plane via the RS.",  is this equivalent to sign the 
AS pair of the P2P as-relationship to the ASPA database?

[KS] p2p relationship is not signed/registered in ASPA. The way it works is... 
if a hop ASx-ASy is such that ASx has signed ASPA but has not included ASy as a 
Provider, then that means that ASy is "attested not Provider" of ASx. In turn, 
that means that ASy is a customer or lateral peer of ASx.   

[SW] Back to Section 5.3, it said "A route received from a RS at IX has much in 
common with route received from a provider." Actually I also think that "A 
route received from P2P BGP neighbor has much in common with route received 
from a provider. (for ASPA validation purposes only)". Does this seem 
reasonable?

[KS] I don't see it that way. A provider may send any available routes to a 
customer but lateral peers (p2p) may send only their customer routes to each 
other.   

Thank you.

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)

[Zhuangshunwan]

Hi Sriram and all,

> 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.
> 
> The idea is that a path segment ASx-RS-ASy (where ASx and ASy are RS-clients
> connected in BGP via the RS) will be always verifiable with this proposal
> whether or not the RS is transparent. If the ASPAs are created by ASx and ASy
> per the proposal above, then the ASx-RS-ASy segment will be evaluated as
> Valid in either direction. I  think this proposal in conjunction with other
> ideas discussed above takes care of both transparent and non-transparent
> RSs in the ASPA verification algorithms. Does this seem reasonable?

[SW] IMO, this idea essentially solves the problem of ASPA verification.
Regarding "The RS client also includes in its SPAS/ASPA any AS with whom it 
connects in the control plane via the RS.",  is this equivalent to sign the AS 
pair of the P2P as-relationship to the ASPA database?
Back to Section 5.3, it said "A route received from a RS at IX has much in 
common with route received from a provider." Actually I also think that "A 
route received from P2P BGP neighbor has much in common with route received 
from a provider. (for ASPA validation purposes only)". Does this seem 
reasonable?

Thanks,
Shunwan

> -Original Message-
> From: Sidrops [mailto:sidrops-boun...@ietf.org] On Behalf Of Sriram,
> Kotikalapudi (Fed)
> Sent: Tuesday, March 15, 2022 11:34 PM
> To: Nick Hilliard 
> Cc: Ben Maddison ; grow@ietf.org;
> sidr...@ietf.org
> Subject: [Sidrops] ASPA and Route Server (was RE: [GROW] 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
> 
> Based on the above observations from you, I am proposing the following:
> 
> 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.
> 
> The idea is that a path segment ASx-RS-ASy (where ASx and ASy are RS-clients
> connected in BGP via the RS) will be always verifiable with this proposal
> whether or not the RS is transparent. If the ASPAs are created by ASx and ASy
> per the proposal above, then the ASx-RS-ASy segment will be evaluated as
> Valid in either direction. I  think this proposal in conjunction with other
> ideas discussed above takes care of both transparent and non-transparent
> RSs in the ASPA verification algorithms. Does this seem reasonable?
> 
> Thank you.
> 
> Sriram
> 
> ___
> Sidrops mailing list
> sidr...@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow