Re: TCP-AO for BGP Peering?

[Andrew Gallo]

There's a github repo with configuration examples from a number of vendors

https://github.com/TCP-AO


As for usageslow adoption.  I only know of one production deployment 
(because I control both eBGP routers :)


https://labs.ripe.net/author/andrew-gallo/production-deployment-of-tcp-authentication-option/


(maybe Cunningham's law will apply and someone will prove me wrong)



On 6/12/2024 7:00 AM, Saku Ytti wrote:

I don't think that URL explains how commonly it is used.

In my experience TCP-AO use is extremely limited, partly because it's
super new in practice. Juniper had it for a long time, but it was
pre-standard even years after the standard was published, which
probably didn't matter much, as no one else had it at all until
somewhat recently.

I suspect this type of order of events may have led many people to
look into TCP-AO early on, and decided correctly it was not
operationally feasible, and that has stuck.



On Wed, 12 Jun 2024 at 13:57, Marco Paesani  wrote:

Hi,
you can start from here:
https://www.juniper.net/documentation/us/en/software/junos/transport-ip/topics/topic-map/tcp-configure-ao-bgp-ldp.html

Regards,


-

Marco Paesani




Skype: mpaesani
Mobile: +39 348 6019349
Success depends on the right choice !
Email: ma...@paesani.it




Il giorno mer 12 giu 2024 alle ore 12:52 7ri...@gmail.com <7ri...@gmail.com> ha 
scritto:

Y'all --

Does anyone know of a survey or study showing the rate of uptake for BGP over 
TCP-AO? I've poked around some and asked in a few places and not found 
anything, but I probably missed something out there.

If there's no studies, does anyone have any experiences possibly indicating BGP 
over TCP-AO usage they can share?

:-) /r





OpenPGP_0x1C61021F8B5942A2.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Setting sensible max-prefix limits

[Andrew Gallo]

On 8/18/2021 5:33 AM, Lars Prehn wrote:
As I understand by now, it is highly recommended to set a max-prefix 
limit for peering sessions. Yet, I can hardly find any recommendations 
on how to arrive at a sensible limit.


I guess for long standing peers one could just eyeball it, e.g., current 
prefix count + some safety margin. How does that work for new peers? Do 
you negotiate/exchange sensible values whenever you establish a new 
session? Do you rely on PeeringDB (if available)? Do you apply default 
values to everyone except the big fishes?


Apart from your peers, do you also apply a limit to your transit sessions?

Best regards,

Lars





Our semi-automated process...
Check the peering routers for any peers that have a prefix limit set (we 
don't set limits on transit or iBGP, so we skip those groups)


Record what the current limit is.

Check peeringDB for what the network says the limit should be.

If configured max prefix < peeringDB, inform a config change is needed;
if configured max prefix > peeringDB, the network isn't keeping its 
record up to date.  no need for change


I've thought about adding additional headroom to what is advertised in 
peeringDB, but we haven't had the limits triggered in so long, it may 
not be worth it.




OpenPGP_0x1C61021F8B5942A2.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Famous operational issues

[Andrew Gallo]

On 2/16/2021 2:37 PM, John Kristoff wrote:

Friends,

I'd like to start a thread about the most famous and widespread Internet
operational issues, outages or implementation incompatibilities you
have seen.

Which examples would make up your top three?



I don't believe I've seen this in any of the replies, but the AT&T 
cascading switch crashes of 1990 is a good one.  This link even has some 
pseudocode

https://users.csc.calpoly.edu/~jdalbey/SWE/Papers/att_collapse

Re: WWV Broadcast Outages

[Andrew Gallo]

On 3/6/2017 3:55 AM, Majdi S. Abbas wrote:

On Wed, Feb 22, 2017 at 04:59:53AM -0800, Hal Murray wrote:

Any suggestions for gear and/or software that works with WWV (or CHU)?
Or general suggestions for non GPS sources of time?

Hey Hal!

In North America, WWV and CHU are pretty much it for accessible
backups these days.  Unfortunately time and frequency distribution is a
niche that tends to get neglected (if not actively gutted) in US
budgets.



Agreed, but I'll share this- the recent FCC CSRIC V had a working group 
(4B) that studied the reliability of time and frequency distribution.

https://www.fcc.gov/about-fcc/advisory-committees/communications-security-reliability-and-interoperability

It may be of interest.

Leap Second planned for 2016

[Andrew Gallo]

Looks like we'll have another second in 2016:
http://www.space.com/33361-leap-second-2016-atomic-clocks.html


Time to start preparing

Re: IEEE OUI regauth (search ?) site

[Andrew Gallo]

What's even better is that if you can get the feedback button on the 
lower right to do anything, this is the response:


HTTP ERROR 404

Problem accessing /standards-ra-web/pub/%5Bappln.feedback.link%5D. Reason:

Not Found







On 12/9/2015 10:32 AM, Brandon Applegate wrote:

They’ve made some changes recently - I had a perl script that would do the 
lookup and scrape live - it was great.  It broke a week or so ago.

This seems to be the page to search for OUI:

https://regauth.standards.ieee.org/standards-ra-web/pub/view.html 


I’ve tried 4 Browsers across 2 OS’s - and that page pops up a “Loading” sub 
window - flashes and reloads (loop).

Anyone have any insight on how one can look up an OUI (yes I know about 
oui.txt, but I’m asking about a live query site).

Thanks in advance.

--
Brandon Applegate - CCIE 10273
PGP Key fingerprint:
830B 4802 1DD4 F4F9 63FE  B966 C0A7 189E 9EC0 3A74
"SH1-0151.  This is the serial number, of our orbital gun."

Followup: Survey results for the ARIN RPA

[Andrew Gallo]

There have been 28 response to the survey I put out last week.

The key numbers are:
We have read and will not sign the agreement 10 36%
We are considering signing the agreement 1  4%
We haven't yet read it 5 18%

and
Our legal staff has reviewed and rejected the agreement.   7 25%
We have provided specific legal feedback to ARIN on the agreement. 2 7%


I'll draw the obvious conclusion:
While not scientific, these numbers, combined with the, well, lively,
discussion the past few days show some serious dissatisfaction with the
agreement required in order to access, and therefore validate, ROAs in the
ARIN region.

And there in lies my interest in all of this- there is little value in
signing my org's routes if no one is going to validate them.  It's a bit of
an odd position in that I have a very high interest in what the rest of the
community thinks of and how they act with respect to the RPA.  In other
words, your relationship with ARIN is now of concern to me.

Maybe I'm being naively optimistic in thinking that these are solvable
problems.

Re: ARIN's RPKI Relying agreement

[Andrew Gallo]

Am I correct in thinking that the SIDR work going on in the IETF takes the
registries out of the real-time processing of route
authentication/attestation?

Is RPKI a stop-gap while we wait for full path validation?  Should we be
focusing our energies in that area?

On Thu, Dec 4, 2014 at 2:19 PM, Sandra Murphy  wrote:

>
> On Dec 4, 2014, at 12:39 PM, John Curran  wrote:
>
> > On Dec 4, 2014, at 11:35 AM, Christopher Morrow 
> wrote:
> >
>
>
> > Note that the claims that could ensue from an operator failing to follow
> best practices
> > and then third-parties suffering an major operational outage is likely
> to be large
>
>
> >
> > Undertaking that risk to the other services that everyone else presently
> rely upon
> > (Whois, reverse DNS) is not reasonable
>
> Which begs the question for me -- ARIN already operates services that
> operators rely upon.  Why are they different?  Does ARIN run no risk of
> litigation due to some perceived involvement of those services in someone's
> operational outage?
>
> Has there been litigation against ARIN tied to, for example, reverse DNS?
> Or the IRR?
>
> --Sandy
>
>

Re: ARIN's RPKI Relying agreement

[Andrew Gallo]

On 12/4/2014 11:22 AM, William Herrin wrote:

On Dec 4, 2014, at 7:35 AM, Andrew Gallo  wrote:
In my informal conversations, what I got was that lawyers read
the agreement, said 'no, we wont sign it' and then dropped it.  If
specific legal feedback isn't making it back to ARIN, then we
need to start providing it,

Hi Andrew,

The short version is that the would-be consumers of the RPKI data want the
data published in much the same way that whois data is published. Many of
the organizations aren't even in the ARIN region. Virtually any formal
contract ARIN is able to offer will be a non-starter for these folks.


Understood and good point.  I've heard rumblings of setting up a 
non-ARIN TAL, though I wonder what the value is in separating RPKI from 
the registry.  Wouldn't this put us in the same position we're in with 
routing registries (with respect to data quality)?

















On Thu, Dec 4, 2014 at 10:51 AM, Bill Woodcock  wrote:

All the specific legal feedback I’ve heard is that this is a liability

nightmare,

and that everyone wants ARIN to take on all the liability, but nobody
wants to pay for it.  Are you hearing something more useful than that?

Hi Bill,

No, nothing more useful. I've seen a lot of hand waving, but I still have
no clue how the publication of RPKI data places ARIN at a different risk
than publication of whois data. I think if we could better understand that,
we'd be better able assess what the next steps are. Do we beat down ARIN's
door and insist they publish the data? Do we pursue the creation of some
new organization to manage RPKI, one with intentionally shallow pockets,
and ask ARIN to cede the function? Something else? I think we all need a
better understanding of the alleged legal issue before we can zero in on
what should come next.

For sure ARIN's current solution, a contract few will sign, is
unsatisfactory.

Regards,
Bill Herrin



--
William Herrin  her...@dirtside.com  b...@herrin.us
Owner, Dirtside Systems . Web: <http://www.dirtside.com/>
May I solve your unusual networking challenges?

Re: ARIN's RPKI Relying agreement

[Andrew Gallo]

Honestly, that's what I'm trying to figure out as well.  In my informal 
conversations, what I got was that lawyers read the agreement, said 'no, 
we wont sign it' and then dropped it.  If specific legal feedback isn't 
making it back to ARIN, then we need to start providing it, otherwise, 
the agreement will stand.



On 12/4/2014 10:04 AM, valdis.kletni...@vt.edu wrote:

On Thu, 04 Dec 2014 09:57:05 -0500, Andrew Gallo said:


In the past few months, I've spoken with, or heard second hand, from a
number of organizations that will not or cannot sign ARIN's RPKI Relying
Agreement.

Do we have a handle on *why* organizations are having issues with the
agreement?

ARIN's RPKI Relying agreement

[Andrew Gallo]

Greetings:

In the past few months, I've spoken with, or heard second hand, from a 
number of organizations that will not or cannot sign ARIN's RPKI Relying 
Agreement.  Acceptance of this agreement is required in order to gain 
access to ARIN's Trust Anchor Locator (TAL).


Given the size and number of these organizations that can't or wont 
accept the agreement makes me wonder if this is a show stopper that will 
prevent the adoption of this technology.


I've created a quick survey to get an idea of the community's take on 
this agreement with the idea that if enough organizations indicate it is 
unacceptable, maybe we can get this agreement changed, or as with other 
regions, not explicitly required to use the TAL.


https://docs.google.com/forms/d/10RLBBpL05n1c_H4unHitlsVqNM3rZI5aXAX8iSBc_Kk/viewform?usp=send_form 




Thank you.

Re: Muni Fiber and Politics

[Andrew Gallo]

On 7/21/2014 2:58 PM, Mikael Abrahamsson wrote:

On Mon, 21 Jul 2014, William Herrin wrote:

The only exception I see to this would be if localities were 
constrained to providing point to point and point to multipoint 
communications infrastructure within the locality on a reasonable and 
non-discriminatory basis. The competition that would foster on the 
services side might outweigh the damage on the infrastructure side. 
Like public roads facilitate efficient transportation and freight 
despite the cost and potholes, though that's an imperfect simile.


While I might not agree with the parts of your email you cut out, I 
would definitely like to chime in on this part. Muni fiber should be 
exactly that, muni *fiber*. Point to point fiber optic single mode 
fiber cabling, aggregating thousands of households per location, 
preferrably tens of thousands.


It's hard to go wrong in this area, it either works or it doesn't, and 
in these aggregation nodes people can compete with several different 
technologies, they can use PON, they can use active ethernet, they can 
provide corporate 10GE connections if they need to, they can run 
hybrid/fiber coax, they can run point-to-point 1GE for residential. 
Anything is possible and the infrastructure is likely to be as viable 
in 30 years as it is day 1 after installation.


Agree 100%.  Layer-1 infrastructure is a high-cost, long term investment 
with little 'value-add'  You don't see too many companies clamoring to 
put in new water or sewer pipes.  Treat fiber the same way.


The money is in content, which is why we're seeing ISP and media 
consolidation.

Re: why haven't ethernet connectors changed?

[Andrew Gallo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 12/20/2012 1:20 PM, Michael Thomas wrote:
> I was looking at a Raspberry Pi board and was struck with how large the 
> ethernet
> connector is in comparison to the board as a whole. It strikes me:
ethernet
> connectors haven't changed that I'm aware in pretty much 25 years.
Every other
> cable has changed several times in that time frame. I imaging that if
anybody
> cared, ethernet cables could be many times smaller. Looking at wiring
closets,
> etc, it seems like it might be a big win for density too.
>
> So why, oh why, nanog the omniscient do we still use rj45's?
>
> Mike
>
>
The connector is to ubiquitous to change.  Other vendors have addressed
the space issue by not supporting Ethernet, but forcing the use of a USB
dongle (Macbook Air comes to mind).

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with undefined - http://www.enigmail.net/
 
iQEcBAEBAgAGBQJQ02leAAoJEBxhAh+LWUKihLsIAJFiUmoaKxHt0Cz0aDmtZGuT
sPh1ET0FcNcblshSnt/Ii0kVbgnFJSxfr4s6FSvwWHJaoNZRpIFLQB5XBMHLX4VZ
I61rc44XeQUABFoM+5dKFKUDLGcCTOttlFr9ndNDCJDiE3DYSe8yfel6t+Aq/mVf
FXxbBbrPceeXXokugbdoPTdW0dBf7xSn3+xY4l+N56wSgJVpe7UHnXh5+TwWpgsN
vQlP/RfVIeTuTLgcDqOUqiv/kj3g3cTQwpnuLSGshrJrepZbrgho/GX8yyf+ub45
KDo/k/uikvX5MTPnfbYGzsU4hloYTia8dSO/pQqz5DYx8kuJPr/dUCC62xUXXx8=
=d80Z
-END PGP SIGNATURE-

Re: Internet routing table "completeness" monitoring?

[Andrew Gallo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 10/3/2012 10:16 AM, William F. Maton Sotomayor wrote:
> On Wed, 3 Oct 2012, Joseph Jackson wrote:
>
>> I have cacti graph the amount of prefixes announced and withdrawn
from a BGP peer on each BGP router.
>
> +1
>
> Note that not all router OSs support fetching data like that via SNMP.
>
> We use a custom built thing internally that does this two, which we
then tack on an alert threshold for. So if a downstream peer sends us
less than that, we get an alert. Handy for those times when they call
and ask us what we did to their network. :-)
>
> Prior to that, we had a script which whould login, munge the 'show ip
bgp summary' table output, figure out the deltas and graph or report as
needed on a particularly troublesome peer.
>
>>
>>
>>
>> -Original Message-
>> From: ML [mailto:m...@kenweb.org]
>> Sent: Tuesday, October 02, 2012 11:43 PM
>> To: North American Networking and Offtopic Gripes List
>> Subject: Internet routing table "completeness" monitoring?
>>
>> Has anyone put in place a method to identify if one their BGP peers
suddenly withdraws X% of their prefixes?
>>
>> e.g I should expect ~420k prefixes in a "complete"[1] routing table
from a transit peer today. If suddenly I'm only getting 390k prefixes
I'd guess a major network was depeered or similiar.
>>
>> If so how are people doing this? SNMP MIB, screen scrape?
>>
>>
>>
>> [1] Varying levels of completeless apply.
>>
>>
>>
>
> wfms
>
>
So, there is something called the BGP Monitoring Protocol (BMP):
http://tools.ietf.org/html/draft-ietf-grow-bmp-06
http://www.nanog.org/meetings/nanog45/abstracts.php?pt=MTM2NiZuYW5vZzQ1&nm=nanog45

Looks like it is supported in JunOS.

Has anyone used it?  If so, what monitoring software are you using?


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
 
iQEcBAEBAgAGBQJQbFsYAAoJEBxhAh+LWUKi/WwIAKxVmcCfI6xng0lAL5UxHSGK
v+fp5Q1d40hCu1aWWeeV/eYvyOEZSwkY/jSK0EaVrdmv0y4GQttQqSfGk+1RQOK/
jZAD/r0Fd9K9vMLJ5Te+bkjYuOp23G2bDn8QWuls4HBc1nHxkPc6arzUTgTzEFAZ
+Ljk3MQSHiZ+nb6fkX+Yb7e3UJZjpkuWaNeqGcKz9FR9PJT5UZI8Yf2iwMHtVl/l
R9XfAIG/xDd64oKEDbt8JmtQkqS64ZnCFe+B/yEuTKC6Pl0DUm4orH7322oxjxOW
yDloqmhO5pCmVETFHwn0ocTpDKqG2zE4zA4bHL+w+xePSS61DpUf51V3eg8JgZo=
=Ofld
-END PGP SIGNATURE-

Re: Apple updates - Effect on network

[Andrew Gallo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 10/12/2011 5:41 PM, Chad Burnham wrote:
> HI,
>
> Our GigaPOP (Front Range GigaPOP) and our own Akamai cache server's
traffic
> jumped significantly today. The theory (no data) is the Apple updates
> released today.
>
> Chad Burnham
> University of Denver
>
>
> -Original Message-
> From: Zachary McGibbon [mailto:zachary.mcgibbon+na...@gmail.com]
> Sent: Wednesday, October 12, 2011 2:10 PM
> To: nanog@nanog.org
> Subject: Apple updates - Affect on network
>
> With all of Apple's updates today (MacOS, iOS, Apps, etc) we saw a big
> increase on one of our links to our ISP at 1pm Eastern.
>
> Did anyone else notice significant traffic jumps on their networks?
>
> [image: image.png]
>
 
Yesterday, around 1PM ET, we saw a nearly 40% increase in inbound
traffic, almost all from Akamai.  It continued until around 2AM this
morning, though, at one point, the traffic switched providers. 
Interestingly enough, we are peered directly with Akamai at Equnix-
Ashburn, and at no point did this traffic use that link.
 
Last time we saw such discrete large inbound flows was the World Cup.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQEcBAEBAgAGBQJOltybAAoJEBxhAh+LWUKil5UH/i1KvIWy7OrrKNhVjWFQ/VuH
OUJg5hJFTns8wT8VkBLT0ANwODA4f8UI8AUJU6nhSeOPvHHor10gw9tytT6H5vh4
znDbxqVhOkCeSms+lKWiylKpVaLrenZ/L649as1ThkxZTogUhZfoRzbmQPJXXTw5
kTuwSrkPjOTmjJNffZ7bo7AvM/dyo56XI1TMsnCp3idRxpIGgvZZm0rlQ2GflVtj
UhN205L+bLC0T4l1qZOYTs/62uZZLZn4Mb5aAp6kufzcfYIVi0RUqOwGjTYztfAe
FytOdzQThZObQoHR253hov/Ogkf11+/vbP7gsGVd9kpjATVk4FbOM75vrcMGn9Q=
=738W
-END PGP SIGNATURE-

Re: EAP-SIM authentication for WiFi networks

[Andrew Gallo]

On 5/24/2011 1:48 PM, Rogelio wrote:
> Can anyone share a working model / solution for EAP-SIM authenticated
> smart phones on Wi-Fi networks? (Or even EAP-AKA?)
>
> i.e. instead of having to login a portal with a user / password or
> pre-authenticate MAC addresses, have it be seemless if they are
> already a subscriber.
>
> AT&T does this with the WISPr client on the iPhones, but I was hoping
> for something that worked across the board with Android devices for a
> given carrier.
>
> Any suggestions here on who I might talk to?
>
While this may not answer your question directly, I know that JANET &
eduroam just announced EAP-SIM service:

http://billstarnaud.blogspot.com/2011/05/uk-r-network-janet-3g-service.html


Maybe there is some useful information here.

Re: FCC releases Internet speed test tool

[Andrew Gallo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 3/12/2010 11:26 AM, Scott Berkman wrote:
> So have other people noticed that the Ookla/Speedtest.net/Speakeasy
> Bandwidth test often comes up VERY short on upload bandwidth results for
> anything other than residential-grade asymmetrical services?
> 
> We often get complaints from customers saying "I'm not getting the upload
> bandwidth I'm paying for", and when we ask what they are using to determine
> this, the answer is almost always either Speakeasy or Speedtest.net.
> 
> We certainly don't depend on or recommend these sites to customers (we have
> our own internal tools and usually recommend FTP or iperf), but everyone who
> deems themselves semi-knowledgeable seems to find their way there anyway.
> Do these sites simply not have the downstream bandwidth to handle the upload
> tests?  If that?s the case I'd really like to see the admins add a
> disclaimer of some form directly to the site.
> 
>   Thanks,
> 
> -Scott

I'm seeing big disparity between upload and download speeds.  I had the
same thought as to the testing platform expecting asymmetrical speeds
typical of a residential link.

Why didn't they go with NDT?



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuadI0ACgkQQr/gMVyFYyT5ywCfTjlYgTs9qV3AaXHsHX3wkm15
QJYAoJoSxNzDqrdX86MoLNB+gObbhZ9/
=qGyL
-END PGP SIGNATURE-

Re: 1G/10G options over 130 km of fiber

[Andrew Gallo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 3/5/2010 3:36 PM, Justin M. Streiner wrote:
> A dark fiber path was recently ordered to a remote location on our
> network, and to my surprise, the engineering report on the path is
> coming back at around 130 km, which is substantially longer than I
> expected the span to be.
> 
> While I am researching gear that will drive a signal this far without a
> mid-span regen, I'm also inquiring with the carrier to see if there is
> any way to shorten the span, but I also have to be prepared for the
> chance that a shorter span is not possible.
> 
> I've seen some pieces from MRV and Transition that might be up to the
> job, though most of the options I've seen are rated to 120 km, tops.
> 
> That said, I'd be interested in hearing about what people who are
> driving similar spans.  I don't think I'm going to have the budget to go
> out and buy Ciena/Infinera/Cisco ONS kit just for this, since I don't
> have any at the present time.  The link is still being built, so I
> haven't gotten an engineering report yet.  My gut tells me that the
> 2-point loss on the span at 1550nm will be somewhere around 30-35 dB.
> 
> jms
> 

You have to be real careful running 10G at those distance.  Loss isn't
the only thing you have to worry about...you may need dispersion
compensation, which by itself is going to add to your loss.

If loss is your only worry, then you might be able to do a pre/post
amplification.  130km is far, but you might be able to skip midspan
amplification.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuRb0wACgkQQr/gMVyFYyRolQCglE6LvTfj9fFcBGejAoCIrTGD
R1EAn0p2LHd32OMbLzH+h83vjRkmcmE/
=bOT0
-END PGP SIGNATURE-