Re: [GROW] is TCP the right layer for BMP session resumption?

[John Kristoff]

On Tue, 9 Mar 2021 20:44:18 +
"Jakob Heitz \(jheitz\)"  wrote:

> I've seen this session resumption technique in the '90s.
> BMP is a one-way protocol. The BMP server sends nothing.

I kind of wish my BMP router monitor was able to transport data over UDP
to the listening station like syslog and flow data.  I would have
especially liked this after that time a blocked TCP port and the
inability to opena TCP connection once caused my BMP monitor router
doing the active open to crash (known and now fixed bug).

> Thus adding this is a significant rework of BMP.

I assume my desire for UDP above will never happen as a result.  Oh
well.

John

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Limiting AS path length?

[John Kristoff]

On Mon, 16 Sep 2019 08:21:08 +
Iljitsch van Beijnum  wrote:

> Dear Global Routing Operators,

And medium-size academic netop.

> My question: is rejecting excessively long AS paths something we want
> to do?

It is something I've decided to do.  When I looked at the paths we were
getting a few months back I decided to drop at 20.  I've pointed people
to my template doc so it is possible that others may have done this as
well.

  

John

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Last Call: (BLACKHOLE BGP Community for Blackholing) to Proposed Standard

[John Kristoff]

On Sun, 26 Jun 2016 16:31:17 +
joel jaeggli  wrote:

> It's not clear to me how that would even work. assuming for the sake
> of arguement that the IXP by way of configured policy on the
> route-server adds this community to a prefix.

Here is some detail on how DE-CIX implements it:

  

John

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] ISC Response to draft-ietf-grow-unique-origin-as

[John Kristoff]

On Thu, 29 Sep 2011 19:07:06 +
Leo Bicknell bickn...@isc.org wrote:

 time. I think the question is if anyone else on the list cares one
 way or another, because if no other opinions have been changed we
 might as well stop.

I often play contrarian or skeptic, if not an honest critic when I take
the time to review a proposal such as this.  My review posted to this
list almost a year ago resulted in no responses or changes in the
draft.  While I didn't find the initial draft as written very convincing
of BCP status, I don't feel strongly about it one way or another to
argue for changes.

It seems to me this is VeriSign trying to document a BCP that works for
them and may work for others.  So perhaps it is just the BCP status
that is disconcerting?

John
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] last call for draft-ietf-grow-unique-origin-as-00

[John Kristoff]

On Fri, 17 Dec 2010 12:54:55 +0800
Peter Schoenmaker p...@lugs.com wrote:

 Please review the draft and provide any last comments.

My thanks to Danny for prodding me to review it and comment.

There are a handful of spelling mistakes and some words that are
if not found in the OED, are at least uncommon (e.g. influencer's).

Some sentences are also quite lengthy and come across awkward, at
least to me.  For instance,

   Tools such as traceroute are also used to determine which
   location a given query is being routed to, although it may not
   reveal local-scope anycast instances, or if there are multiple
   servers within a given anycast node, which of the servers responded
   to a given query, in particular when multiple servers within an
   anycast node are connected to a single IP router.

could perhaps be rewritten as:

   Tools such as traceroute are also used to help determine which
   location a given query is being routed to.  However, they may not
   reveal local-scope anycast instances, if there are multiple
   servers within a given anycast node or which of the servers responded
   to a given query.

This sentence:

   This detection model would need to be expanded to account for unique
   origin ASNs per node if a given service operators chooses to employ
   such as a model, and given that AS paths are trivial to manipulate,
   the above technique would only assist in the event of unintentional
   configuration errors that reoriginate the route (e.g., it doesn't
   even detect leaks that preserve the initial path elements).

could perhaps be rewritten as:

   This detection model would need to be expanded to account for unique
   origin ASNs per node.  Given that AS paths may be manipulated,
   the above technique would only assist in the event of unintentional
   configuration errors that re-originate the route.  That is, the
   technique doesn't detect leaks that preserve the initial path
   elements.

The abstract states this is for critical infrastructure and only
eludes to what that is by later mentioning DNS root and TLD servers as
examples.  Perhaps either make this explicitly for root and TLD servers,
deal with what critical means or just make this is a generally accepted
practice.

That said, is there any current deployment of this technique?  I'd be
interested in reviewing any papers or case studies.  If not, I think it
would be prudent to have some before publication.  I want to make sure
the following paragraph is justified:

  Furthermore, inconsistent origin AS announcements associated with
  anycasted services for critical infrastructure SHOULD NOT be deemed
  undesirable by routing system reporting functions, but should instead
  be embraced in order to better identify the connectedness and
  footprint of a given anycasted service.

This document is making the case for this technique around management
and policy improvements, but I have some questions with how complete
the arguments are.

First, there is no discussion of BGP attributes, particular communities,
which would seem to be a viable policy alternative to unique origin
ASNs.

Second, the document isn't convincing when it claims unique origin ASNs
would enable detection of leaked or hijacked instances more quickly.
Adding more origin ASNs would just seem to complicate matters, because
now you not only need to know the path, but also which origin ASN
goes with each path.  It may also actually broaden the attack surface.

Examples might help me better understand what I'm missing.

I think the following statement is irrelevant and best removed:

  Additionally, critical infrastructure employment of 32-bit ASNs for
  new nodes might well help to foster adoption of native 32-bit ASN
  support by network operators.

The discussion about potential benefits for RPKI is interesting, but
seems to be putting the cart before the horse.  I'm not up on the SIDR
work, but if along the lines of my earlier comment, communities along
with the announced prefix were validated, would that help?

John
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow