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

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Tue, 15 Mar 2022 15:33:42 +0000

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

---

From: Zhuangshunwan <[email-masked]>
Date: Fri, 18 Mar 2022 02:50:13 +0000

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:[email-masked]] On Behalf Of Sriram,
> Kotikalapudi (Fed)
> Sent: Tuesday, March 15, 2022 11:34 PM
> To: Nick Hilliard <[email-masked]>
> Cc: Ben Maddison <[email-masked]>; [email-masked];
> [email-masked]
> 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
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Sun, 20 Mar 2022 14:59:13 +0000

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 <[email-masked]> On Behalf Of Sriram, Kotikalapudi (Fed)
Sent: Tuesday, March 15, 2022 11:34 AM
To: Nick Hilliard <[email-masked]>
Cc: Ben Maddison <[email-masked]>; [email-masked]; [email-masked]
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... 

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

Thank you.

Sriram

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Sun, 20 Mar 2022 15:36:28 +0000

Hi Shunwan,

Please see the comments below marked with [KS].

>> SPAS/ASPA. The RS client also includes in its SPAS/ASPA any AS with 
>> whom it connects in the control plane via the RS.
>> ....

[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

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 20 Mar 2022 12:19:40 -0400

Hi Sriram

On Sun, Mar 20, 2022 at 10:59 AM Sriram, Kotikalapudi (Fed)
<kotikalapudi.sriram=[email-masked]> wrote:

> #1: An RS client of an RS (transparent or not) includes the RS AS in their
> 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
>
> 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 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

    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.

> 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
>
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Mon, 21 Mar 2022 15:13:05 +0000

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 <[email-masked]> On Behalf Of Gyan Mishra
Sent: Sunday, March 20, 2022 9:20 AM
To: Sriram, Kotikalapudi (Fed) <kotikalapudi.sriram=[email-masked]>
Cc: Ben Maddison <[email-masked]>; [email-masked]; [email-masked]; Zhuangshunwan <[email-masked]>; Nick Hilliard <[email-masked]>
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) <kotikalapudi.sriram=[email-masked]<mailto:[email-masked]>> wrote:
I think a correction is required. Instead of what was said before -

Thank you.

Sriram

-----Original Message-----
From: GROW <[email-masked]<mailto:[email-masked]>> On Behalf Of Sriram, Kotikalapudi (Fed)
Sent: Tuesday, March 15, 2022 11:34 AM
To: Nick Hilliard <[email-masked]<mailto:[email-masked]>>
Cc: Ben Maddison <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [GROW] ASPA and Route Server (was RE: [Sidrops] IXP Route Server question)

Nick (and all),

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

Thank you.

Sriram

_______________________________________________
GROW mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/grow
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

---

From: Zhuangshunwan <[email-masked]>
Date: Mon, 21 Mar 2022 15:48:27 +0000

+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:[email-masked]]
Sent: Monday, March 21, 2022 11:13 PM
To: Gyan Mishra <[email-masked]>; Sriram, Kotikalapudi (Fed) <kotikalapudi.sriram=[email-masked]>
Cc: Ben Maddison <[email-masked]>; [email-masked]; [email-masked]; Zhuangshunwan <[email-masked]>; Nick Hilliard <[email-masked]>
Subject: RE: [Sidrops] [GROW] ASPA and Route Server (was RE: IXP Route Server question)

Regards,
Jakob.

From: Sidrops <[email-masked]<mailto:[email-masked]>> On Behalf Of Gyan Mishra
Sent: Sunday, March 20, 2022 9:20 AM
To: Sriram, Kotikalapudi (Fed) <kotikalapudi.sriram=[email-masked]<mailto:kotikalapudi.sriram=[email-masked]>>
Cc: Ben Maddison <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Zhuangshunwan <[email-masked]<mailto:[email-masked]>>; Nick Hilliard <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Sidrops] [GROW] ASPA and Route Server (was RE: IXP Route Server question)

Hi Sriram

Thank you.

Sriram

-----Original Message-----
From: GROW <[email-masked]<mailto:[email-masked]>> On Behalf Of Sriram, Kotikalapudi (Fed)
Sent: Tuesday, March 15, 2022 11:34 AM
To: Nick Hilliard <[email-masked]<mailto:[email-masked]>>
Cc: Ben Maddison <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [GROW] ASPA and Route Server (was RE: [Sidrops] IXP Route Server question)

Nick (and all),

Thank you.

Sriram

Gyan Mishra

M 301 502-1347

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Mon, 21 Mar 2022 15:52:16 +0000

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 pat…

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

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 21 Mar 2022 11:56:57 -0400

Thanks Sriram

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

-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 21 Mar 2022 12:43:12 -0400

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 <zhuangshunwan=[email-masked]> wrote:
> 
> +1
> From: Sidrops <[email-masked] <mailto:[email-masked]>> On Behalf Of Gyan Mishra
> To: Sriram, Kotikalapudi (Fed) <kotikalapudi.sriram=[email-masked] <mailto:kotikalapudi.sriram=[email-masked]>>
> Cc: Ben Maddison <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; Zhuangshunwan <[email-masked] <mailto:[email-masked]>>; Nick Hilliard <[email-masked] <mailto:[email-masked]>>
> On Sun, Mar 20, 2022 at 10:59 AM Sriram, Kotikalapudi (Fed) <kotikalapudi.sriram=[email-masked] <mailto:[email-masked]>> wrote:
> From: GROW <[email-masked] <mailto:[email-masked]>> On Behalf Of Sriram, Kotikalapudi (Fed)
> To: Nick Hilliard <[email-masked] <mailto:[email-masked]>>
> Cc: Ben Maddison <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/grow <https://www.ietf.org/mailman/listinfo/grow>
> -- 
> Email [email-masked] <mailto:[email-masked]>
> M 301 502-1347
> 
>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Mon, 21 Mar 2022 17:14:09 +0000

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 <[email-masked]>
Sent: Monday, March 21, 2022 9:43 AM
To: Zhuangshunwan <zhuangshunwan=[email-masked]>
Cc: Jakob Heitz (jheitz) <[email-masked]>; Gyan Mishra <[email-masked]>; Sriram, Kotikalapudi (Fed) <kotikalapudi.sriram=[email-masked]>; Ben Maddison <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route Server question)

Two comments here:

-- Jeff

On Mar 21, 2022, at 11:48 AM, Zhuangshunwan <zhuangshunwan=[email-masked]<mailto:zhuangshunwan=[email-masked]>> wrote:

+1

Kind Regards,
Shunwan

To: Gyan Mishra <[email-masked]<mailto:[email-masked]>>; Sriram, Kotikalapudi (Fed) <kotikalapudi.sriram=[email-masked]<mailto:kotikalapudi.sriram=[email-masked]>>

Regards,
Jakob.

Hi Sriram

Thank you.

Sriram

-----Original Message-----
From: GROW <[email-masked]<mailto:[email-masked]>> On Behalf Of Sriram, Kotikalapudi (Fed)
Sent: Tuesday, March 15, 2022 11:34 AM
To: Nick Hilliard <[email-masked]<mailto:[email-masked]>>
Cc: Ben Maddison <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [GROW] ASPA and Route Server (was RE: [Sidrops] IXP Route Server question)

Nick (and all),

Thank you.

Sriram

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Mon, 21 Mar 2022 21:09:06 +0000

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? 

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&index=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

---

From: Zhuangshunwan <[email-masked]>
Date: Tue, 22 Mar 2022 05:31:26 +0000

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

> From: Sriram, Kotikalapudi (Fed) [mailto:[email-masked]]
> Sent: Tuesday, March 22, 2022 5:09 AM
> To: Jakob Heitz (jheitz) <[email-masked]>; Jeffrey Haas <[email-masked]>
> Cc: [email-masked]; [email-masked]; Zhuangshunwan
> <[email-masked]>; Nick Hilliard <[email-masked]>
> Subject: RE: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route
> Server question)
> 
> Hi Jakob,
> 
> Even if you assume that all route servers are transparent, what would you
> like to propose to solve the following problem?
> 
> 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?
> 
> 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

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 22 Mar 2022 07:20:05 +0000

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 <[email-masked]> wrote:
> 
> Hi Sriram and all,
>

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Wed, 23 Mar 2022 18:56:41 +0000

Hi Jakob,

>> AS1 (RS Client) -----> AS2 (RS) ----->  AS3 (RS Client) ---p2p (lateral peer) ---> AS4 (validating AS)
...
>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

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Wed, 23 Mar 2022 19:01:22 +0000

Hi Shunwan,

>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

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 23 Mar 2022 19:02:22 +0000

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) <[email-masked]> 
Sent: Wednesday, March 23, 2022 11:57 AM
To: Jakob Heitz (jheitz) <[email-masked]>; Zhuangshunwan <[email-masked]>
Cc: Jeffrey Haas <[email-masked]>; [email-masked]; [email-masked]; Nick Hilliard <[email-masked]>
Subject: RE: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route Server question)

Hi Jakob,

...

Sriram

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 23 Mar 2022 19:06:52 +0000

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) <[email-masked]> 
Sent: Wednesday, March 23, 2022 12:01 PM
To: Zhuangshunwan <[email-masked]>; Jakob Heitz (jheitz) <[email-masked]>; Jeffrey Haas <[email-masked]>
Cc: [email-masked]; [email-masked]; Nick Hilliard <[email-masked]>
Subject: RE: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route Server question)

Hi Shunwan,

Sriram

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Wed, 23 Mar 2022 19:45:14 +0000

>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

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 23 Mar 2022 19:59:29 +0000

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 <[email-masked]> On Behalf Of Sriram, Kotikalapudi (Fed)
Sent: Wednesday, March 23, 2022 12:45 PM
To: Jakob Heitz (jheitz) <[email-masked]>; Zhuangshunwan <[email-masked]>; Jeffrey Haas <[email-masked]>
Cc: [email-masked]; [email-masked]; Nick Hilliard <[email-masked]>
Subject: Re: [Sidrops] [GROW] ASPA and Route Server (was RE: IXP Route Server question)

Sriram

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Wed, 23 Mar 2022 20:29:04 +0000

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 <[email-masked]> 
Sent: Monday, March 21, 2022 12:43 PM
To: Zhuangshunwan <[email-masked]>
Cc: Jakob Heitz (jheitz) <[email-masked]>; Gyan Mishra <[email-masked]>; Sriram, Kotikalapudi (Fed) <[email-masked]>; Ben Maddison <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [GROW] [Sidrops] ASPA and Route Server (was RE: IXP Route Server question)

Two comments here:

-- Jeff

---

From: Zhuangshunwan <[email-masked]>
Date: Thu, 24 Mar 2022 12:19:32 +0000

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:

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

> Sent: Thursday, March 24, 2022 3:01 AM
> To: Zhuangshunwan <[email-masked]>; Jakob Heitz (jheitz)
> <[email-masked]>; Jeffrey Haas <[email-masked]>
> #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