- Test - lists.nanog.org

Out of ideas - Comcast issue BGP peering with Tata
by Jamie Chetta 22 Nov '23

22 Nov '23

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.helpdesk(a)tatacommunications.com<mailto:corp.helpdesk@tatacommunications.com> Tata Communications IP Service Support( AS-6453) IPServiceSupport(a)tatacommunications.com<mailto:IPServiceSupport@tatacommunications.com> IPNOC (Tata Communications - AS6453) IPNOC(a)tatacommunications.com<mailto:IPNOC@tatacommunications.com> lg(a)as6453.net<mailto:lg@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."

9 9

100 KvA Chicago DC
by Alexandre Legrix 22 Nov '23

22 Nov '23

Hello Nanog We are looking for a private room in Chicago with ~100kVA of power capability. Equinix Cyrus and co are not very keen to answer this demand Does anyone have contacts please ? Best regards -- Alexandre

1 0

Re: Your Input Needed: Can ROA Replace LOA? ? Short Survey (7 mins)
by George Toma 21 Nov '23

21 Nov '23

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.

3 2

DoD contact
by Scott Q. 21 Nov '23

21 Nov '23

Can anyone recommend a preferred method for contacting the network folks at the DoD ? It seems they blanket banned large swaths of our upstream provider ( Aptum AS 13768 ) which includes all of our subnets as well. We can't connect to any IP that they manage which includes DNS resolution for .mil , mail service, etc. I tried reaching out ( and Aptum as well ) to disa.columbus.ns.mbx.hostmaster-dod-nic(a)mail.mil from an external address and although the e-mail didn't bounce, we also didn't receive any answer for a few days now. Is there another way to get in touch with them ? Thanks! Scott

2 1

Re: Advantages and disadvantages of legacy assets
by Rubens Kuhl 20 Nov '23

20 Nov '23

On Mon, Nov 20, 2023 at 4:15 PM Lukas Tribus <lukas(a)ltri.eu> wrote: > > On Mon, 20 Nov 2023 at 20:08, Rubens Kuhl <rubensk(a)gmail.com> wrote: > > > > You can get IRR from RADB or AltDB. > > Which is not going to be useful forever ... see [1]: > > > Please note that 'route' and 'route6' objects created after 2023-Aug-15 > > in non-authoritative registries like RADB, NTTCOM, ALTDB won't be > > processed. > > > > > [1] https://lg.as6453.net/doc/cust-routing-policy.html First time I see a Tier-1 complaining about non-authoritative IRR. I wonder what they do with IRR sources that do validate although not being run by a RIR/NIR, like TC. Rubens

1 0

BGP-iSec: Improved Security of Internet Routing Against Post-ROV Attacks
by Amir Herzberg 20 Nov '23

20 Nov '23

Hi NANOGers, We will present our new work, titled: `BGP-iSec: Improved Security of Internet Routing Against Post-ROV Attacks', in NDSS'24. If you're interested in security of Internet routing (BGP), and want a copy, see URL below, drop me a message/email - or see us in the conference - or just read the final version. Available from: https://www.researchgate.net/publication/375553362_BGP-iSec_Improved_Securi… -- 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

4 6

Help with Frontier circuits AS5650
by Dennis Burgess 20 Nov '23

20 Nov '23

I have two frontier circuits that are not working correctly with BGP, prefixes that are announced are not showing in the global table etc. Any frontier people can tell me where I can call to find someone that can assist. End users are currently down ☹ been calling numbers for the past hour, no one is picking up. [LTI-Full_175px] Dennis Burgess Mikrotik : Trainer, Network Associate, Routing Engineer, Wireless Engineer, Traffic Control Engineer, Inter-Networking Engineer, Security Engineer, Enterprise Wireless Engineer Hurricane Electric: IPv6 Sage Level Cambium: ePMP Author of "Learn RouterOS- Second Edition” Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net<http://www.linktechs.net/> Create your own Tickets via https://hd.linktechs.net Create Wireless Coverage’s with www.towercoverage.com Need MikroTik Cloud Management: https://cloud.linktechs.net<https://cloud.linktechs.net/> Remote Winbox Service: http://rwb.linktechs.net

3 2

ipv6 address management - documentation
by Aaron Gould 20 Nov '23

20 Nov '23

For years I've used an MS Excel spreadsheet to manage my IPv4 addresses. IPv6 is going to be maddening to manage in a spreadsheet. What does everyone use for their IPv6 address prefix management and documentation? Are there open source tools/apps for this? -- -Aaron

17 16

CBS / Paramount+ geoloctaion contact
by George Toma 20 Nov '23

20 Nov '23

We are getting Unauthorized location response headers from Irtdeto on Paramount Plus content when accessed from some of our subnets (several subnets within a particular /21). {"code":130301,"message":"Content is not available in this location."} Other subnets (different /22s) of ours work fine. Irdeto says the geolocation acceptance is done by the customer, in this case Paramount Plus / CBS. Does anybody have a contact at CBS/Paramount+ with whom I could escalate these issues? Thank you. George Toma VISNETWORK SRL

1 0

Call for Participation -- ICANN DNSSEC and Security Workshop for ICANN79 Community Forum
by Jacques Latour 20 Nov '23

20 Nov '23

Call for Participation – ICANN DNSSEC and Security Workshop for ICANN79 Community Forum In cooperation with the ICANN Security and Stability Advisory Committee (SSAC), we are planning a DNSSEC and Security Workshop for the ICANN79 Community Forum being held as a hybrid meeting from 02-07 March 2024 San Juan, Puerto Rico in the Atlantic Standard Time - AST (UTC-4). This workshop date will be determined once ICANN creates a block schedule for us to follow; then we will be able to request a day and time. The DNSSEC and Security Workshop has been a part of ICANN meetings for several years and has provided a forum for both experienced and new people to meet, present and discuss current and future DNSSEC deployments. For reference, the most recent session was held at the ICANN78 The Annual General Meeting on Wednesday, 25 October 2023. The presentations and transcripts are available at: https://icann78.sched.com/. The DNSSEC Workshop Program Committee is developing a program for the upcoming meeting. Proposals will be considered for the following topic areas and included if space permits. In addition, we welcome suggestions for additional topics either for inclusion in the ICANN78 workshop, or for consideration for future workshops. 1. Global DNSSEC Activities Panel For this panel, we are seeking participation from those who have been involved in DNSSEC deployment as well as from those who have not deployed DNSSEC but who have a keen interest in the challenges and benefits of deployment, including Root Key Signing Key (KSK) Rollover activities and plans. 2. DNSSEC Best Practice Now that DNSSEC has become an operational norm for many registries, registrars, and ISPs, what have we learned about how we manage DNSSEC? * Do you still submit/accept DS records with Digest Type 1? * What is the best practice around key roll-overs? * What about Algorithm roll-overs? * Do you use and support DNSKEY Algorithms 13-16? * How often do you review your disaster recovery procedures? * Is there operational familiarity within your customer support teams? * What operational statistics have been gathered about DNSSEC? * Are there experiences being documented in the form of best practices, or something similar, for transfer of signed zones? Activities and issues related to DNSSEC in the DNS Root Zone are also desired. 3. DNSSEC Deployment Challenges The program committee is seeking input from those that are interested in implementation of DNSSEC but have general or particular concerns with DNSSEC. In particular, we are seeking input from individuals that would be willing to participate in a panel that would discuss questions of the following nature: * Are there any policies directly or indirectly impeding your DNSSEC deployment? (RRR model, CDS/CDNSKEY automation) * What are your most significant concerns with DNSSEC, e.g., complexity, training, implementation, operation or something else? * What do you expect DNSSEC to do for you and what doesn't it do? * What do you see as the most important trade-offs with respect to doing or not doing DNSSEC? 4. Security Panel The program committee is looking for presentations on DNS, DNSSEC, routing and other topics that could impact the security and/or stability of the Internet. We are looking for presentations that cover implementation issues, challenges, opportunities and best practices for: * Emerging threats that could impact the security and/or stability of the Internet * DoH and DoT * RPKI (Resource Public Key Infrastructure) * BGP routing & secure implementations * MANRS ( Mutually Agreed Norms for Routing Security) * Browser security – DNS, DNSSEC, DoH * EMAIL & DNS related security – DMARC, DKIM, TLSA, etc… If you are interested in participating, please send a brief (1-3 sentence) description of your proposed presentation to dnssec-security-workshop(a)icann.org<mailto:dnssec-security-workshop@icann.org> by COB Friday, 19 January 2024. Thank you, Kim and Kathy On behalf of the DNSSEC Workshop Program Committee: Steve Crocker, Edgemoor Research Institute Mark Elkins, DNS/ZARC Jacques Latour, .CA Russ Mundy, Tislabs Yoshiro Yoneya Dan York, Internet Society CLASSIFICATION:PUBLIC

1 0