Jeffrey Haas

@[email protected]
12 Followers
47 Following
53 Posts
Working on Internet routing since 2000.
Show threadJeffrey HaasMay 13
[1] https://mailarchive.ietf.org/arch/msg/idr/ZsLHdmThstk66e-g6hqfBh0whH4/
[Idr] WG last call and IPR call for draft-ietf-idr-linklocal-capability (May 13, 2026 to May 27, 2026)

Search IETF mail list archives

Jeffrey HaasMay 13

The IDR Working Group, which standardizes BGP in the IETF, is doing last call for the linklocal capability feature.

IPv6-linklocal-only peering is a popular mechanism for some operators who want to avoid uniquely numbering links in network scenarios where the number is irrelevant. This is especially the case for things that are otherwise point to point links. Some people like these in data center use cases!

However, linklocal-only peering has been underspecified and buggy between implementations. This draft fixes that.

Please consider reviewing the draft and providing feedback to the working group mailing list.[1] This can be "yeah, it's ready to go" or "I see a problem here"...

https://datatracker.ietf.org/doc/draft-ietf-idr-linklocal-capability/

#bgp #ietf

Link-Local Next Hop Capability for BGP

To support IPv6 [RFC4291] reachability, BGP [RFC4271] relies on the Multiprotocol Extensions as defined in [RFC4760]. [RFC2545] defines the structure of IPv6 next hops. These IPv6 next hops may contain a Global IPv6 address, and optionally can contain an IPv6 Link-Local address when the BGP peer is directly attached and shares a common subnet with the IPv6 Global address. This document updates [RFC2545] to clarify the encoding of the BGP next hop when the advertising system is directly attached and only an IPv6 Link-Local address is available. A new BGP Capability [RFC5492] is defined to signal support for this updated encoding. This clarification applies specifically to IPv6 Link-Local addresses and does not pertain to IPv4 Link-Local addresses as defined in [RFC3927].

IETF Datatracker
Jeffrey HaasMay 3
Steve BellovinApr 30

New book, released under a Creative Commons BY-NC-ND license: "Don't Get Hacked! Protecting Yourself at Home": https://www.cs.columbia.edu/~smb/homesec/index.html

Retoot for reach!

#cybersecurity #homeCybersecurity #dontGetHacked

Don't Get Hacked!

Show threadJeffrey HaasApr 25

And one other cool thing the CCR tooling gets us - we can see database "version" in YANG modules exposing the cache server state.

https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rtr-yang-05

YANG Data Model for RPKI to Router Protocol

This document defines YANG data models for managing Resource Public Key Infrastructure (RPKI) to Router Protocol (RFC6810 and RFC8210).

IETF Datatracker
Show threadJeffrey HaasApr 25

And perhaps while you're at it, toss a coin to your witcher... er, open source developer who's working on building these tools:

https://www.rpki-client.org/funding.html

rpki-client: Funding

Rpki-client is mission-critical software which needs your help!

Jeffrey HaasApr 25

As the RPKI ecosystem continues to evolve to provide the data for securing BGP Internet routing, the foundations are being laid for the long term need for forensic analysis tools and the long term study of that ecosystem.

For BGP, we've long had the MRT files gathered by various looking glass projects such as route-views. That data today is part of long term trend analysis for BGP and a tool for triaging global routing problems.

The rpki-views work and related IETF drafts for it, largely driven by Job Snijders, is providing a way to capture the state of the RPKI. As Internet routing analysis eventually becomes more dependent on the state of the RPKI at a given moment, such state becomes a critical component of any ex post facto analysis of BGP routing security from BGP routing data.

While the attached article is effectively discussing an "oops" while building out this ecosystem, it provides a good set of links to spelunk for the above topics.

#bgp #rpki #rpkiclient #ietf

https://blog.qrator.net/en/repairing-the-rpkiviews-h1-2026-archives_227/

Blog — Repairing the RPKIViews H1 2026 Archives

Jeffrey HaasApr 25
Paul CantrellApr 24

Yes, security is hard, and yes, security is inconvenient and in direct tension with usability…

BUT

security is also broken! So there’s that https://infosec.exchange/@adamshostack/116457349787883964

Adam Shostack :donor: :rebelverified: (@[email protected])

How’s your evening going? Mine is … watching @1Password and Apple password fight over who gets to login to the Alaska app to the point of locking my account and I don’t even remember why I last had to change my password and now I remember why everyone hates security.

Infosec Exchange
Show threadJeffrey HaasMar 8
FYI, the link bandwidth feature motivating this work:
https://datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth/
BGP Link Bandwidth Extended Community

This document defines a BGP Extended Community, the Link Bandwidth Extended Community, which carries bandwidth information to enable weighted load-balancing in multipath scenarios. It specifies the format and processing rules for this extended community type.

IETF Datatracker
Jeffrey HaasMar 8

IDR and BESS, which standardize BGP and BGP related VPN features in IETF, are doing working group last calls on features relating to BGP extended communities and are looking for community input.

The motivation for this update was the link bandwidth feature, extensively used by data center and service provider networks. That feature completed last call recently. The related plumbing for the main extended community feature, and the EBGP DMZ use case for link bandwidth that allows for aggregation, are the pieces going through last call.

4360-bis last call thread:
https://mailarchive.ietf.org/arch/msg/idr/fftaCU5jpiYynWFfgex0dkjXB4E/

EBGP DMZ last call thread:
https://mailarchive.ietf.org/arch/msg/bess/7t7F7X2yf59V-6YWv1v3L5NErXY/

#ietf #idr #bess #bgp #ietf125

[Idr] WG LC on draft-ietf-idr-rfc4360-bis-02 (03/02/2026 - 03/16/2026)

Search IETF mail list archives

Jeffrey HaasMar 6
Dan YorkMar 5

RE: https://mastodon.social/@kiwix/116175641532766269

For #InternetResilience, I believe having offline access to #Internet content is critically important. If you haven’t been paying attention to what the good folks at Kiwix are doing, I encourage you to take a look!

They began many years ago with making #Wikipedia available offline, and have expanded to make many more resources available- and have developed a great system for displaying offline content… and very crucially for *updating* the offline content.

Do check them out!