Hi Tobias, WG,
Diff from rfc7454 as follows:
https://author-tools.ietf.org/iddiff?url1=rfc7454&url2=draft-ietf-grow-bgpopsecupd-01&difftype=--html
There are quite a lot of changes there and I'm going to make a bunch of
specific comments about the text changes in this ID in separate emails,
but want to say some more general things first.
First and foremost, bcp194 needs an update, so thanks for taking up the
gauntlet on this - it's very welcome.
The main concern I have is that BCP194 is a document which is already
referenced in national telecommunications security policies, and which
will become more widely referenced in future, as the world moves towards
risk-management based approaches to telecoms security.
From this point of view, the IETF needs to be careful about what's put
into the document, and more importantly, what's not put in the document.
There are plenty of potentially useful additions in the current round of
updates, but for a document update of this type, future amendments need
to be added sparingly, and should be conservative and principle-based in
approach, rather than getting too detailed about implementation specifics.
In other words, I'd be in favour of the approach that the best outcome
will be not when there's nothing left to add, but when there's nothing
more that can be taken away.
In terms of the draft as it currently stands, I have concerns about the
following areas of principal (in no particular order):
- scope creep: the abstract has moved from "describes measures to
protect" to "This document provides a comprehensive list". I don't think
that this is a wise move either to claim this or to aim in this direction.
- there are experimental / development ideas in there which are not
widely used on production networks, and therefore inappropriate for BCP
status, e.g. ASPA (still undergoing protocol behavioral change at the
ietf in SIDROPS), RFC5549, etc. There's a mention of TCP-MD5 but using
SHA1/SHA512 instead of MD5, which I'm not sure even exists.
- stuff which is bgp stack implementation dependent: e.g. Idempotency
for Prefix filter Changes, prefix ruleset optimisation, etc.
- defining / redefining well known terms (most of section 3).
- being overly prescriptive, e.g. "9.2.1.1. Inbound Filtering" or
"9.1.2. Order of Prefixfilters". All this is too detailed.
- things which don't really need to be mentioned, or if they do, then by
reference only. e.g. "7.1.3. Recursively Computing Filters", or using
BGP communities to signal ROV state (should reference
draft-rpki-communities-harmful instead).
- things which seem like they're a good idea on first glance, e.g.
"operators SHOULD NOT set a higher local preference for NLRI received
via an IXP RS": no document is going to stop people from using localpref
at IXPs, and other operators are going to drain traffic via RSs by
draining prefixes from RSs, not by increasing the as-path length. Or
e.g. recommending route flap dampening: we need extensive production
telemetry to ensure that this is actually a good idea. The last time it
was turned on globally, a lot of damage was done.
- things which are ephemeral. This is a document where everything that's
written in it should be relevant in 10-20 years time. E.g. "Recently,
an attack was observed", or section 6.3. notes "at the time of writing
of this document" and suggests /24 + /48 for ipv4 / ipv6 prefixes
lengths for interdomain routing. But for example, a well-known CDN has
been announcing more specific prefixes over interdomain bgp sessions for
several years.
- less is more.
These are general principles which should be kept in mind when writing
text, i.e. the above isn't intended to be an exhaustive list of issues
with the document.
I'll take up specific items in separate email threads.
Nick
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
