[sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-protocol-21: (with DISCUSS and COMMENT)

["Stephen Farrell" <[e-mail]>]

Stephen Farrell has entered the following ballot position for
draft-ietf-sidr-bgpsec-protocol-21: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------



I have a couple of fairly straightforward things I'd
like to briefly discuss...

(1) 3.2/Figure 7: A fixed 20 byte SKI being a sha-1 hash
of the public key is a bad plan, for all the usual
reasons. Why is it ok for that to be hardcoded here when
it could change if/when new alg choices are made for the
RPKI? If it is not too late then I think you should add a
length or alg field to that. If it is too late to do that,
then are we really ok that you will need to rev the BGPsec
version number in order to get rid of all sha-1 code from
your implementation? That seems like a bad plan for a new
protocol.

(2) Figure 8: It seems to me to be an error to omit the
signer's ASN from the signed data and only have that
included in the signer's certificate. Why is that intimate
level of binding to the RPKI desirable? There may well be
reasons but I'm not seeing 'em, and I am recalling that it
took a chunk of effort to make CMS less dependent on
X.509 for similar reasons (meaning identifying signers
exclusively via cert issuer and serial in that case).  I
would expect that there could be demand to have some level
of independence between BGPsec and RPKI for at least
internal uses such as those noted in the spec already.

(3) section 8: Is there a potential exposure here in that
a relying party who emits e.g.  certificate status checks
or cert retrieval queries for an RPKI cert they've not
previously seen is exposing something about the set of
paths its traffic is likely to follow. (This is similar to
why we have OCSP stapling in the web.) IIRC the RPKI specs
may cover this but I suspect it'd be worth noting here as
well even if so as this represents exposing something
about BGP announcement content to off-path parties which I
think is new for BGP. Is that a new thing for BGP? (I
think the new aspect to the attack is that a bad actor who
has already compromised some AS could more easily spot
that traffic from the relying party's AS is likely to
transit the compromised AS.)


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


- (Non actionable comment really aimed at the IESG and not
the authors/WG...) I'm kinda sad that even today we don't
appear to have learned to value deploy-ability more highly.
I fear that BGPsec and RPKI will suffer a similar lack of
deployment as seen with S/MIME and DNSSEC and for possibly
similar reasons (complexity, not starting with modest
improvements, requiring a number of parties to change
before seeing benefits).  I hope I'm wrong about that, but
equally, if I'm not and RPKI/BGPsec deployment turns out
to be very very slow, (as opposed to the optimistic, "just
slow";-) then I also hope the IESG at that time will be
willing to consider alternatives - it's too easy for the
IETF to just get stuck when a technology like this fails
to deploy. But maybe I'm wrong and this'll all be fine and
will be widely deployed and used in a few years.

- Figures 2 and 5 present the fields in different orders.
That seems like a bad idea.

- 3.2: The reference to the pki profile doc is not precise
enough, the string "key identifier" does not occur in that
draft - it's in RFC6487, 4.8.2. 

- 4.1, last para: is the distinction between an "internal
peer" and "iBGP peer" sufficiently clear to routing folk?
For me they sound similar but I assume it's ok.

- 5.2, I think you need to say something to the effect
that every Secure_Path MUST have a signature with an
algorithm that is supported. As I read the text, the
algorithm as stated here could be read to not require
that. E.g. the para before the bullets on p25 could be
read to mean "drop all stuff involving unsupported algs
and then continue to process the rest of the stuff."

- section 7: WRT non-deterministic signature algorithms, I
think it'd be useful to note here that all such algorithms
require good random number generation on the signer's
system and that failing in that respect can expose the
signer's private key.  IMO deterministic signature schemes
are better for this reason but the need for a good RNG is
I think a real operational issue worthy of note.