Re: [External] announcing IPs by scrubbing service to help with DDoS attacks and ROAs

[Amir Herzberg]

Tom, thanks. I'm an academic researcher, no a network operator, sorry for
the confusion, I should have been clearer.

The practice you described indeed shouldn't requite ROA. I didn't even
consider it, probably since I've been working so much on prefix hijacks,
and this prefix would result in increased vulnerability to prefix hijacks.
But if there's only a DDoS attack on the prefix and it's not being hijacked
at the same time, then I think this practice may be fine - which would make
such `emergency ROA' unnecessary.
So that's very very useful feedback, thanks a lot!! Amir
-- 
Amir Herzberg

Comcast professor of Security Innovations, Computer Science and
Engineering, University of Connecticut
Homepage: https://sites.google.com/site/amirherzberg/home
`Applied Introduction to Cryptography' textbook and lectures:
https://sites.google.com/site/amirherzberg/cybersecurity




On Fri, Nov 17, 2023 at 12:09 AM Tom Krenn  wrote:

> It has been a few years, but I recall advertising my routes to the
> scrubbing center via a tunnel and just prepending to my other peers when in
> mitigation. This was pre-RPKI days, but my ASN was still originating the
> route. So, I would assume no change in ROA would be needed in that
> scenario. Are you allowing them to originate your routes or are they just
> another hop in your as-path?
>
>
>
> Tom Krenn
>
> Network Architect
>
> Enterprise Architecture - Information Technology
>
> [image: Hennepin County logo]
>
>
>
>
>
> *From:* NANOG  *On Behalf
> Of *Amir Herzberg
> *Sent:* Thursday, November 16, 2023 19:58
> *To:* NANOG 
> *Subject:* [External] announcing IPs by scrubbing service to help with
> DDoS attacks and ROAs
>
>
>
> *CAUTION:* This email was sent from outside of Hennepin County. Unless
> you recognize the sender and know the content, do not click links or open
> attachments.
>
> Hi, do people use scrubbing services, when under DDoS attack, by having
> the scrubbing service announce the attacked IP prefix(es)?
>
>
>
> If so, and you have a ROA for these prefixes, do you authorize the
> scrubbing AS (by issuing ROA or otherwise), and if so, do you do it in
> advance or only when you need the scrubbing service to announce your
> prefix?
>
>
>
> To clarify: we have a possible method to allow such `emergency ROAs' but
> I'm not convinced if we have a solution to a real problem - or if we just
> found a cute crypto solution and will end up writing it for a non-real
> problem. I prefer not to waste our time on presenting cute solutions to
> non-real problems :)
>
>
>
> So thanks for your help! Use your judgement if to respond on list or off
> list.
>
>
>
> Many thanks, Amir
>
> --
>
> Amir Herzberg
>
>
>
> Comcast professor of Security Innovations, Computer Science and
> Engineering, University of Connecticut
>
> Homepage: https://sites.google.com/site/amirherzberg/home
>
> `Applied Introduction to Cryptography' textbook and lectures:
> https://sites.google.com/site/amirherzberg/cybersecurity
>
>
>
>
>
>
> *Disclaimer:* If you are not the intended recipient of this message,
> please immediately notify the sender of the transmission error and then
> promptly permanently delete this message from your computer system.
>

Re: Out of ideas - Comcast issue BGP peering with Tata

[Lukas Tribus]

On Fri, 17 Nov 2023 at 15:17, Jamie Chetta via NANOG  wrote:
>
> I am out of ideas on how to get this fixed.  Long story short I am a customer 
> of Comcast and am advertising my own /24 block I own through them.  Comcast 
> of course BGP peers with multiple ISPs.  Other ISPs are accepting my prefix 
> just fine, except Tata.

Why don't you share the exact prefix so people can actually look into it?

Tata is doing some strict filtering [1] at least for customers (but
maybe for peers as well), so if you only rely on non-authoritative
registries for recent objects, this may be the reason:

> Special note, deprecation of non-authoritative registries
>
> Please note that 'route' and 'route6' objects created after 2023-Aug-15 in 
> non-authoritative registries like RADB, NTTCOM, ALTDB won't be processed. It 
> is recommended to create RPKI ROA objects instead. In rare cases if that's 
> not possible, 'route' and 'route6' must be created in the authoritative 
> registry - AfriNIC, APNIC, ARIN, LACNIC, RIPE, RIPE, NIC.br or IDNIC.



cheers


[1] https://lg.as6453.net/doc/cust-routing-policy.html

Re: Out of ideas - Comcast issue BGP peering with Tata

[TJ Trout]

Is your IRR and RPKI roas all squared away?

On Fri, Nov 17, 2023, 8:12 AM Diego Eduardo Zorrilla Fierro (diefierr) via
NANOG  wrote:

> Im not sure, just thinking, maybe is a thing with the /24. Is it possible
> to you get from Comcast maybe a /22 ??
>
>
>
> Regards
>
> Diego
>
>
>
> *From: *NANOG  on behalf of
> Mike Hammett 
> *Date: *Friday, November 17, 2023 at 09:51
> *To: *Jamie Chetta 
> *Cc: *nanog@nanog.org 
> *Subject: *Re: Out of ideas - Comcast issue BGP peering with Tata
>
> This passing the buck thing was old a very long time ago.
>
> CDNs and security services are great at it too.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
>
> --
>
> *From: *"Jamie Chetta via NANOG" 
> *To: *nanog@nanog.org
> *Sent: *Friday, November 17, 2023 8:17:42 AM
> *Subject: *Out of ideas - Comcast issue BGP peering with Tata
>
> I am out of ideas on how to get this fixed.  Long story short I am a
> customer of Comcast and am advertising my own /24 block I own through
> them.  Comcast of course BGP peers with multiple ISPs.  Other ISPs are
> accepting my prefix just fine, except Tata.  This is causing random
> destinations to drop connectivity if Comcast routes it through them.
> Comcast has confirmed they are advertising my block to Tata and that the
> RPKI is good, however when you check the Tata looking glass you can see
> they’re not accepting it.
>
>
>
> I’ve tried escalating within Comcast who refuses to contact Tata as
> they’ve validated the issue is not on their end but they agree with my
> assessment that Tata is not accepting the prefix for some reason.
>
>
>
> I’ve tried multiple email for Tata support (below), but they all circle
> around to a helpdesk who says I do not have a circuit with them so they
> cannot help me.
>
>
>
> Is there anyone from Tata willing to contact me off list to help sort this
> out?  Or anyone with ideas on specifically why other ISPs are accepting my
> route but not Tata?  It would be greatly appreciated.
>
>
>
> Emails I’ve tried
>
> Corporate  Helpdesk corp.helpd...@tatacommunications.com
>
> Tata Communications IP Service Support( AS-6453)
> ipservicesupp...@tatacommunications.com
>
> IPNOC (Tata Communications - AS6453) ip...@tatacommunications.com
>
> l...@as6453.net
>
>
> Response from Tata:
>
> “Acknowledge your email.
>
>
>
> However, since you are not associated with TCL we would not be in a
> position to help you on this.
>
>
>
> Request you to contact comcast for the assistance that you are seeking
> from us.”
>
>
>
> Response from Comcast:
>
> “This was sent back to me as not us. Basically, it’s not a RADB or RPKI
> issue. This is being accepted and re-advertised to TATA but not being
> accepted on their end. But another route that we checked off of that same
> SUR is being advertised the same way and accepted by them off
> pe12.350ecermak.il.ibone as an example of the TATA looking glass.  I would
> suggest that you would probably need to work with other networks as to why
> those that are specific ones are not accepting the block but as previously
> mentioned it’s not a RADB or RPKI issue and as a result not a Comcast
> issue.”
>
>
>

Weekly Global IPv4 Routing Table Report

[Routing Table Analysis Role Account]

This is an automated weekly mailing describing the state of the Global
IPv4 Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
UKNOF, TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net.

For historical data, please see https://thyme.apnic.net.

If you have any comments please contact Philip Smith .

IPv4 Routing Table Report   04:00 +10GMT Sat 18 Nov, 2023

  BGP Table (Global) as seen in Japan.

Report Website: https://thyme.apnic.net
Detailed Analysis:  https://thyme.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  935368
Prefixes after maximum aggregation (per Origin AS):  355908
Deaggregation factor:  2.63
Unique aggregates announced (without unneeded subnets):  454806
Total ASes present in the Internet Routing Table: 75063
Prefixes per ASN: 12.46
Origin-only ASes present in the Internet Routing Table:   64423
Origin ASes announcing only one prefix:   26500
Transit ASes present in the Internet Routing Table:   10640
Transit-only ASes present in the Internet Routing Table:481
Average AS path length visible in the Internet Routing Table:   4.2
Max AS path length visible:  55
Max AS path prepend of ASN (265020)  50
Prefixes from unregistered ASNs in the Routing Table:  1058
Number of instances of unregistered ASNs:  1060
Number of 32-bit ASNs allocated by the RIRs:  43068
Number of 32-bit ASNs visible in the Routing Table:   35403
Prefixes from 32-bit ASNs in the Routing Table:  177707
Number of bogon 32-bit ASNs visible in the Routing Table:30
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:533
Number of addresses announced to Internet:   3050179328
Equivalent to 181 /8s, 206 /16s and 11 /24s
Percentage of available address space announced:   82.4
Percentage of allocated address space announced:   82.4
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.6
Total number of prefixes smaller than registry allocations:  310771

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   248769
Total APNIC prefixes after maximum aggregation:   71647
APNIC Deaggregation factor:3.47
Prefixes being announced from the APNIC address blocks:  241951
Unique aggregates announced from the APNIC address blocks:99167
APNIC Region origin ASes present in the Internet Routing Table:   13773
APNIC Prefixes per ASN:   17.57
APNIC Region origin ASes announcing only one prefix:   4141
APNIC Region transit ASes present in the Internet Routing Table:   1854
Average APNIC Region AS path length visible:4.4
Max APNIC Region AS path length visible: 32
Number of APNIC region 32-bit ASNs visible in the Routing Table:   9105
Number of APNIC addresses announced to Internet:  771745152
Equivalent to 45 /8s, 255 /16s and 229 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-153913
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:273597
Total ARIN prefixes after maximum aggregation:   124288
ARIN Deaggregation factor: 2.20
Prefixes being announced from the ARIN address blocks:   278287
Unique aggregates announced from the ARIN address blocks:132362
ARIN Region origin ASes present in the Internet Routing Table:19079
ARIN Prefixes per ASN:   

Re: Out of ideas - Comcast issue BGP peering with Tata

[Diego Eduardo Zorrilla Fierro (diefierr) via NANOG]

Im not sure, just thinking, maybe is a thing with the /24. Is it possible to 
you get from Comcast maybe a /22 ??

Regards
Diego

From: NANOG  on behalf of Mike 
Hammett 
Date: Friday, November 17, 2023 at 09:51
To: Jamie Chetta 
Cc: nanog@nanog.org 
Subject: Re: Out of ideas - Comcast issue BGP peering with Tata
This passing the buck thing was old a very long time ago.

CDNs and security services are great at it too.


-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com


From: "Jamie Chetta via NANOG" 
To: nanog@nanog.org
Sent: Friday, November 17, 2023 8:17:42 AM
Subject: Out of ideas - Comcast issue BGP peering with Tata
I am out of ideas on how to get this fixed.  Long story short I am a customer 
of Comcast and am advertising my own /24 block I own through them.  Comcast of 
course BGP peers with multiple ISPs.  Other ISPs are accepting my prefix just 
fine, except Tata.  This is causing random destinations to drop connectivity if 
Comcast routes it through them.  Comcast has confirmed they are advertising my 
block to Tata and that the RPKI is good, however when you check the Tata 
looking glass you can see they’re not accepting it.

I’ve tried escalating within Comcast who refuses to contact Tata as they’ve 
validated the issue is not on their end but they agree with my assessment that 
Tata is not accepting the prefix for some reason.

I’ve tried multiple email for Tata support (below), but they all circle around 
to a helpdesk who says I do not have a circuit with them so they cannot help me.

Is there anyone from Tata willing to contact me off list to help sort this out? 
 Or anyone with ideas on specifically why other ISPs are accepting my route but 
not Tata?  It would be greatly appreciated.

Emails I’ve tried
Corporate  Helpdesk 
corp.helpd...@tatacommunications.com
Tata Communications IP Service Support( AS-6453) 
ipservicesupp...@tatacommunications.com
IPNOC (Tata Communications - AS6453) 
ip...@tatacommunications.com
l...@as6453.net

Response from Tata:
“Acknowledge your email.

However, since you are not associated with TCL we would not be in a position to 
help you on this.

Request you to contact comcast for the assistance that you are seeking from us.”

Response from Comcast:
“This was sent back to me as not us. Basically, it’s not a RADB or RPKI issue. 
This is being accepted and re-advertised to TATA but not being accepted on 
their end. But another route that we checked off of that same SUR is being 
advertised the same way and accepted by them off pe12.350ecermak.il.ibone as an 
example of the TATA looking glass.  I would suggest that you would probably 
need to work with other networks as to why those that are specific ones are not 
accepting the block but as previously mentioned it’s not a RADB or RPKI issue 
and as a result not a Comcast issue.”

Re: Out of ideas - Comcast issue BGP peering with Tata

[Tom Beecher]

>
> Comcast has to be the one contacting them
>

This is the correct answer. It's pretty straight forward ; Comcast needs to
get with Tata, say "hey, I'm announcing prefix FOO to you, your LGs don't
look like you're accepting it. Can we figure out why?"

On Fri, Nov 17, 2023 at 10:43 AM jim deleskie  wrote:

> I many years ago worked at Tata, responsible for their BGP, they are
> giving you the right answer, Comcast has to be the one contacting them, as
> then both sides can see what is being sent and received and can resolve
> this issue.
>
> -jim
>
> On Fri, Nov 17, 2023 at 10:04 AM Jamie Chetta via NANOG 
> wrote:
>
>> I am out of ideas on how to get this fixed.  Long story short I am a
>> customer of Comcast and am advertising my own /24 block I own through
>> them.  Comcast of course BGP peers with multiple ISPs.  Other ISPs are
>> accepting my prefix just fine, except Tata.  This is causing random
>> destinations to drop connectivity if Comcast routes it through them.
>> Comcast has confirmed they are advertising my block to Tata and that the
>> RPKI is good, however when you check the Tata looking glass you can see
>> they’re not accepting it.
>>
>>
>>
>> I’ve tried escalating within Comcast who refuses to contact Tata as
>> they’ve validated the issue is not on their end but they agree with my
>> assessment that Tata is not accepting the prefix for some reason.
>>
>>
>>
>> I’ve tried multiple email for Tata support (below), but they all circle
>> around to a helpdesk who says I do not have a circuit with them so they
>> cannot help me.
>>
>>
>>
>> Is there anyone from Tata willing to contact me off list to help sort
>> this out?  Or anyone with ideas on specifically why other ISPs are
>> accepting my route but not Tata?  It would be greatly appreciated.
>>
>>
>>
>> Emails I’ve tried
>>
>> Corporate  Helpdesk corp.helpd...@tatacommunications.com
>>
>> Tata Communications IP Service Support( AS-6453)
>> ipservicesupp...@tatacommunications.com
>>
>> IPNOC (Tata Communications - AS6453) ip...@tatacommunications.com
>>
>> l...@as6453.net
>>
>>
>> Response from Tata:
>>
>> “Acknowledge your email.
>>
>>
>>
>> However, since you are not associated with TCL we would not be in a
>> position to help you on this.
>>
>>
>>
>> Request you to contact comcast for the assistance that you are seeking
>> from us.”
>>
>>
>>
>> Response from Comcast:
>>
>> “This was sent back to me as not us. Basically, it’s not a RADB or RPKI
>> issue. This is being accepted and re-advertised to TATA but not being
>> accepted on their end. But another route that we checked off of that same
>> SUR is being advertised the same way and accepted by them off
>> pe12.350ecermak.il.ibone as an example of the TATA looking glass.  I would
>> suggest that you would probably need to work with other networks as to why
>> those that are specific ones are not accepting the block but as previously
>> mentioned it’s not a RADB or RPKI issue and as a result not a Comcast
>> issue.”
>>
>

Re: Generally accepted BGP acceptance criteria?

[Mike Hammett]

Everyone thinks they're a unicorn and they're special and it's a secret... 
other than those that don't. ;-) 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Tom Samplonius"  
To: nanog@nanog.org 
Sent: Thursday, November 16, 2023 6:54:17 PM 
Subject: Generally accepted BGP acceptance criteria? 


In the world of IRR and RPKI, BGP route acceptance criteria is important to get 
right. 

DE-CIX has published a detailed flow chart documenting their acceptance 
criteria: https://www.de-cix.net/en/locations/frankfurt/route-server-guide 

But I don’t see a lot of operators publishing their criteria. I imagine there 
is a some sort of coalescing industry standard out there, but so far I can’t 
find it. Of the upstreams I use, just one publishes a flowchart. Another is 
basically refusing to explain anything other than they “use” IRR and RPKI, ad 
that RPKI is “good”. 

I assumed that everyone implementing RPKI validation, would skip IRR route 
object validation if the route is RPKI-valid. I assumed that everyone is doing 
this now, or would do this when they implement RPKI validation. But I spoke to 
an operator today, which still expects all routes to pass IRR as well (and 
while they perform RPKI-validation, they effectively do nothing with the 
result). To me, this seems like a different direction than most operators are 
going. Or is it? 

The most surprising thing in the DE-DIX flow chart, was that they check that 
the origin AS exists in the IRR as-set, before doing RPKI, and if the set 
existence fails, they reject the route. I don’t see a problem with this, as 
maintaining as-sets is easy, but it does prevent an eventual 100% RPKI future 
with no IRR at all. 

I also thought there may be an informational RFC on this, but I couldn’t find 
anything. Has there been anything published or any presentations given, on 
generally accepted BGP route acceptance criteria? 


Tom 

Re: Out of ideas - Comcast issue BGP peering with Tata

[Mike Hammett]

This passing the buck thing was old a very long time ago. 

CDNs and security services are great at it too. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Jamie Chetta via NANOG"  
To: nanog@nanog.org 
Sent: Friday, November 17, 2023 8:17:42 AM 
Subject: Out of ideas - Comcast issue BGP peering with Tata 



I am out of ideas on how to get this fixed. Long story short I am a customer of 
Comcast and am advertising my own /24 block I own through them. Comcast of 
course BGP peers with multiple ISPs. Other ISPs are accepting my prefix just 
fine, except Tata. This is causing random destinations to drop connectivity if 
Comcast routes it through them. Comcast has confirmed they are advertising my 
block to Tata and that the RPKI is good, however when you check the Tata 
looking glass you can see they’re not accepting it. 

I’ve tried escalating within Comcast who refuses to contact Tata as they’ve 
validated the issue is not on their end but they agree with my assessment that 
Tata is not accepting the prefix for some reason. 

I’ve tried multiple email for Tata support (below), but they all circle around 
to a helpdesk who says I do not have a circuit with them so they cannot help 
me. 

Is there anyone from Tata willing to contact me off list to help sort this out? 
Or anyone with ideas on specifically why other ISPs are accepting my route but 
not Tata? It would be greatly appreciated. 

Emails I’ve tried 
Corporate Helpdesk corp.helpd...@tatacommunications.com 
Tata Communications IP Service Support( AS-6453) 
ipservicesupp...@tatacommunications.com 
IPNOC (Tata Communications - AS6453) ip...@tatacommunications.com 
l...@as6453.net 

Response from Tata: 
“ Acknowledge your email. 

However, since you are not associated with TCL we would not be in a position to 
help you on this. 

Request you to contact comcast for the assistance that you are seeking from 
us.” 

Response from Comcast: 
“ This was sent back to me as not us. Basically, it’s not a RADB or RPKI issue. 
This is being accepted and re-advertised to TATA but not being accepted on 
their end. But another route that we checked off of that same SUR is being 
advertised the same way and accepted by them off pe12.350ecermak.il.ibone as an 
example of the TATA looking glass. I would suggest that you would probably need 
to work with other networks as to why those that are specific ones are not 
accepting the block but as previously mentioned it’s not a RADB or RPKI issue 
and as a result not a Comcast issue.” 

Re: Out of ideas - Comcast issue BGP peering with Tata

[jim deleskie]

I many years ago worked at Tata, responsible for their BGP, they are giving
you the right answer, Comcast has to be the one contacting them, as then
both sides can see what is being sent and received and can resolve this
issue.

-jim

On Fri, Nov 17, 2023 at 10:04 AM Jamie Chetta via NANOG 
wrote:

> I am out of ideas on how to get this fixed.  Long story short I am a
> customer of Comcast and am advertising my own /24 block I own through
> them.  Comcast of course BGP peers with multiple ISPs.  Other ISPs are
> accepting my prefix just fine, except Tata.  This is causing random
> destinations to drop connectivity if Comcast routes it through them.
> Comcast has confirmed they are advertising my block to Tata and that the
> RPKI is good, however when you check the Tata looking glass you can see
> they’re not accepting it.
>
>
>
> I’ve tried escalating within Comcast who refuses to contact Tata as
> they’ve validated the issue is not on their end but they agree with my
> assessment that Tata is not accepting the prefix for some reason.
>
>
>
> I’ve tried multiple email for Tata support (below), but they all circle
> around to a helpdesk who says I do not have a circuit with them so they
> cannot help me.
>
>
>
> Is there anyone from Tata willing to contact me off list to help sort this
> out?  Or anyone with ideas on specifically why other ISPs are accepting my
> route but not Tata?  It would be greatly appreciated.
>
>
>
> Emails I’ve tried
>
> Corporate  Helpdesk corp.helpd...@tatacommunications.com
>
> Tata Communications IP Service Support( AS-6453)
> ipservicesupp...@tatacommunications.com
>
> IPNOC (Tata Communications - AS6453) ip...@tatacommunications.com
>
> l...@as6453.net
>
>
> Response from Tata:
>
> “Acknowledge your email.
>
>
>
> However, since you are not associated with TCL we would not be in a
> position to help you on this.
>
>
>
> Request you to contact comcast for the assistance that you are seeking
> from us.”
>
>
>
> Response from Comcast:
>
> “This was sent back to me as not us. Basically, it’s not a RADB or RPKI
> issue. This is being accepted and re-advertised to TATA but not being
> accepted on their end. But another route that we checked off of that same
> SUR is being advertised the same way and accepted by them off
> pe12.350ecermak.il.ibone as an example of the TATA looking glass.  I would
> suggest that you would probably need to work with other networks as to why
> those that are specific ones are not accepting the block but as previously
> mentioned it’s not a RADB or RPKI issue and as a result not a Comcast
> issue.”
>

Re: Your Input Needed: Can ROA Replace LOA? ? Short Survey (7 mins)

[Tom Beecher]

>
> Therefore, Cogent currently does not have and is not member of ARIN. It
> refuses to sign contract with ARIN and currently Cogent is not bound by
> this RUD rules and regulations.
>
> There is one downfall to not being ARIN member, Cogent cannot currently
> issue ROAs or RPKIs. They only update RIR in ROADB database for the leased
> out IP addresses.
>

Not entirely accurate.

Cogent Communications is already a General Member of ARIN. You can see that
for yourself here : https://account.arin.net/public/member-list
. *Membership* is not a prerequisite for anything RPKI.

ARIN requires an RSA or LRSA in place covering a number resource before
they will be the trust anchor for that number resource. In the design of
RPKI, this should make logical sense. Many legacy resource holders have
their own reasons on why they chose not to sign an LRSA for those
resources, so there is a chicken/egg problem here.

Cogent can participate in RPKI with any non-legacy resources without a
problem, as anything non-legacy is covered by an RSA.


On Fri, Nov 17, 2023 at 8:13 AM George Toma  wrote:

> There is IPV4 exhaustion and many ISPs lease IPV4 space from other
> entities, such as brokers and other providers. One of the biggest IPv4
> lessors is Cogent. By Cogent having legacy IP space from IANA which it
> inherited when it acquired PSInet, Cogent was not required to sign a
> contract when RIR ARIN was created.
>
> Therefore, Cogent currently does not have and is not member of ARIN. It
> refuses to sign contract with ARIN and currently Cogent is not bound by
> this RUD rules and regulations.
>
> There is one downfall to not being ARIN member, Cogent cannot currently
> issue ROAs or RPKIs. They only update RIR in ROADB database for the leased
> out IP addresses.
>
> By implicitly requiring ROA or RPKI for IPv4 space leased from Covent,
> about 70% of small ISPs that were created after IPv4 space exhaustion,
> would not be able to route their IPV4 traffic, because currently they lease
> IPv4 space from Cogent, and as we mentioned, by Cogent refusing to become
> ARIN member, it cannot issue ROAs or RPKIs, and therefore ISPs using this
> leased IPV4 space can only use LOAs for validation.
>

Out of ideas - Comcast issue BGP peering with Tata

[Jamie Chetta via NANOG]

I am out of ideas on how to get this fixed.  Long story short I am a customer 
of Comcast and am advertising my own /24 block I own through them.  Comcast of 
course BGP peers with multiple ISPs.  Other ISPs are accepting my prefix just 
fine, except Tata.  This is causing random destinations to drop connectivity if 
Comcast routes it through them.  Comcast has confirmed they are advertising my 
block to Tata and that the RPKI is good, however when you check the Tata 
looking glass you can see they're not accepting it.

I've tried escalating within Comcast who refuses to contact Tata as they've 
validated the issue is not on their end but they agree with my assessment that 
Tata is not accepting the prefix for some reason.

I've tried multiple email for Tata support (below), but they all circle around 
to a helpdesk who says I do not have a circuit with them so they cannot help me.

Is there anyone from Tata willing to contact me off list to help sort this out? 
 Or anyone with ideas on specifically why other ISPs are accepting my route but 
not Tata?  It would be greatly appreciated.

Emails I've tried
Corporate  Helpdesk 
corp.helpd...@tatacommunications.com
Tata Communications IP Service Support( AS-6453) 
ipservicesupp...@tatacommunications.com
IPNOC (Tata Communications - AS6453) 
ip...@tatacommunications.com
l...@as6453.net

Response from Tata:
"Acknowledge your email.

However, since you are not associated with TCL we would not be in a position to 
help you on this.

Request you to contact comcast for the assistance that you are seeking from us."

Response from Comcast:
"This was sent back to me as not us. Basically, it's not a RADB or RPKI issue. 
This is being accepted and re-advertised to TATA but not being accepted on 
their end. But another route that we checked off of that same SUR is being 
advertised the same way and accepted by them off pe12.350ecermak.il.ibone as an 
example of the TATA looking glass.  I would suggest that you would probably 
need to work with other networks as to why those that are specific ones are not 
accepting the block but as previously mentioned it's not a RADB or RPKI issue 
and as a result not a Comcast issue."

Re: Generally accepted BGP acceptance criteria?

[Christopher Morrow]

> On Thu, Nov 16, 2023 at 9:31 PM Tom Samplonius  wrote:

>>   The most surprising thing in the DE-DIX flow chart, was that they check 
>> that the origin AS exists in the IRR as-set, before doing RPKI, and if the 
>> set existence fails, they reject the route.  I don’t see a problem with 
>> this, as maintaining as-sets is easy, but it does prevent an eventual 100% 
>> RPKI future with no IRR at all.

I don't think the future is ever really 'no irr'.
  * RPKI provides: "a cryptographically verifiable method to determine
authority to use ip number resources"
  * OriginValidation provides: "A route origin authorization
'database' for use eventually on BGP speakers"

IRR filters provide control over whom is provided reachability through
a particular peering/path.
(dale points this out as well, particularly the part about paths he points out)

Re: Generally accepted BGP acceptance criteria?

[Dale W. Carder]

Thus spake Tom Samplonius (t...@samplonius.org) on Thu, Nov 16, 2023 at 
04:54:17PM -0800:
> 
>   In the world of IRR and RPKI, BGP route acceptance criteria is important to 
> get right.
> 
>   DE-CIX has published a detailed flow chart documenting their acceptance 
> criteria:  https://www.de-cix.net/en/locations/frankfurt/route-server-guide
> 
>   But I don’t see a lot of operators publishing their criteria.

An example another IX: https://www.seattleix.net/route-servers

Here's at least one provider example: https://routing.he.net/algorithm.html

>  I imagine there is a some sort of coalescing industry standard out there, 
> but so far I can’t find it.  Of the upstreams I use, just one publishes a 
> flowchart.  Another is basically refusing to explain anything other than they 
> “use” IRR and RPKI, ad that RPKI is “good”.

I don't think there is a standard as there is a pretty wide range of
variance, ranging from "nothing" to static lists to `bgpq4` to whatever
you call what Hurricane is doing.

>   I assumed that everyone implementing RPKI validation, would skip IRR route 
> object validation if the route is RPKI-valid.

Not at all.  While an ROA provides an attestation about the originating
ASN for a prefix, there are no claims made as to the path or that all
prefixes for an ASN have ROAs.

>  I assumed that everyone is doing this now, or would do this when they 
> implement RPKI validation.  But I spoke to an operator today, which still 
> expects all routes to pass IRR as well (and while they perform 
> RPKI-validation, they effectively do nothing with the result).  To me, this 
> seems like a different direction than most operators are going.  Or is it?
> 
>   The most surprising thing in the DE-DIX flow chart, was that they check 
> that the origin AS exists in the IRR as-set, before doing RPKI, and if the 
> set existence fails, they reject the route.  I don’t see a problem with this, 
> as maintaining as-sets is easy, but it does prevent an eventual 100% RPKI 
> future with no IRR at all.

There are some possible things in the works you should consider, as
OTC, ASPA, rpki-prefixlist (essentially like an irr route-set), and
even partial deployment of bgpsec are emerging tools in the toolbox.  

Before embarking too far, we must also consider this from an ecosystem
perspective.  With RPKI ROA's, the integration with IRRd v4 elegantly 
sunsets blatantly invalid prefixes.  Additional tooling (IRRd v5?
bgpq5?) would need to be considered to further transition our way out
out of the IRR system, assuming an analog in RPKI.  

Would we even want to?  Dropping non-RIR IRR source databases might go
much further to get to very similar goals with much less work than for
example reimplementing as-sets (I think essentially the inverse of
ASPA's ASProviderAttestation) in RPKI.

Dale

Re: Fiber/OSP Technician Training and Apprenticeship Programs

[Josh Luthman]

I personally find college, for the most part, as a scam and simply a quick
way to enter into debt.  Yes there are exceptions, like everything.

I/We started doing fixed wireless in 2006 with no training.  We started
fiber to the home in 2019 with little training - a neighbor to the north
showed us splicing to get us comfortable enough to try it ourselves.  This
does go back to your "person-to-person transfer of internal knowledge" of
course, but with Youtube University it's certainly doable if you're
willing.  I've done light mechanical work on trucks/cars to avoid paying
someone else.  I know a great mechanic that had no help, no education, but
was put in a place with no money and a broken car and they fixed it
themselves.  Necessity breeds innovation.

If you're looking for input on your class I'm happy to provide you with
some input at no cost to you.  I still believe the average person willing
to put in work can simply learn themselves, but maybe someone who is dead
set on college would find their way into construction/OSP through your
course.

On Thu, Nov 16, 2023 at 4:44 PM Rhys Barrie via NANOG 
wrote:

> Hey all,
>
> I've recently been working with our county's broadband task force,
> investigating the expansion and equity of broadband networks on a
> local and state level. Through that, it's become clear that there's a
> painful shortage of fiber / outside plant technicians in the state of
> Michigan (if not nation-wide) in order to fulfill the workforce
> requirements of maintaining the current broadband fiber infrastructure
> in the state, much less to fuel fiber expansion, and especially in
> rural areas. There appear to be few options for training the required
> workforce, especially outside of the large enterprises that have the
> resources to run their own internal programs, and small (or even
> mid-sized) ISPs seem to be left with predominantly informal
> person-to-person transfer of internal knowledge, assuming that they
> have the required internal knowledge in the first place. This need for
> a qualified workforce is exacerbated in the face of the multitude of
> state and federal programs to encourage broadband internet expansion
> and equity, such as the upcoming $42.5 billion in BEAD grant funding
> and corresponding construction starting in ~12-18 months state- and
> nation-wide.
>
> As a result, our workforce development team over here at Mott
> Community College (Genesee County, MI) is working to develop a fiber /
> outside plant training and apprenticeship program in order to help
> address this shortage of qualified personnel and training options at a
> local and state level. We're looking for some industry contacts that
> would be interested in collaborating with us to establish high-level
> requirements regarding what skills need to be taught to prospective
> fiber / outside plant technicians, what qualifications trainees should
> have after completion in order to fulfill current workforce demands,
> and to otherwise provide input in sketching out a high-level
> curriculum. We're looking for feedback from a wide cross-section of
> industry stakeholders -- large enterprise backbone transit providers,
> rural residential ISPs, fiber co-ops and municipal networks,
> operations and outside plant managers, etc. -- in order to determine
> what the industry wants and needs, and how the entire community
> college system can help meet those needs.
>
> If anyone thinks that they have valuable input to provide regarding
> these workforce requirements, or knows the right people to talk to,
> please reach out and let me know!
>
> Rhys Barrie (He/Him)
> Network Engineer - Mott Community College
> Member - Genesee County Broadband Task Force
> (810) 762-0030 | rhys.bar...@mcc.edu | https://mcc.edu/
>

Re: Your Input Needed: Can ROA Replace LOA? ? Short Survey (7 mins)

[George Toma]

There is IPV4 exhaustion and many ISPs lease IPV4 space from other
entities, such as brokers and other providers. One of the biggest IPv4
lessors is Cogent. By Cogent having legacy IP space from IANA which it
inherited when it acquired PSInet, Cogent was not required to sign a
contract when RIR ARIN was created.

Therefore, Cogent currently does not have and is not member of ARIN. It
refuses to sign contract with ARIN and currently Cogent is not bound by
this RUD rules and regulations.

There is one downfall to not being ARIN member, Cogent cannot currently
issue ROAs or RPKIs. They only update RIR in ROADB database for the leased
out IP addresses.

By implicitly requiring ROA or RPKI for IPv4 space leased from Covent,
about 70% of small ISPs that were created after IPv4 space exhaustion,
would not be able to route their IPV4 traffic, because currently they lease
IPv4 space from Cogent, and as we mentioned, by Cogent refusing to become
ARIN member, it cannot issue ROAs or RPKIs, and therefore ISPs using this
leased IPV4 space can only use LOAs for validation.