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

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 04 Jan 2017 05:53:08 -0800

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.

---

From: Sean Turner <[email-masked]>
Date: Wed, 4 Jan 2017 13:48:07 -0500

> On Jan 4, 2017, at 08:53, Stephen Farrell <[email-masked]> wrote:
> 

Not sure it absolutely needs a length field; if the RPKI does ever decide to change to another hash algorithm for SKI, e.g., SHA-256/384/512, or to change to a hash of the SubjectPublicKeyInfo they could always the procedures from https://datatracker.ietf.org/doc/rfc7093/ to generate the values for a 20-byte value.  

spt

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 4 Jan 2017 19:05:44 +0000

Hiya,

On 04/01/17 18:48, Sean Turner wrote:
>> 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.
>> 
>> 
>> (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 
> Not sure it absolutely needs a length field; if the RPKI does ever
> decide to change to another hash algorithm for SKI, e.g.,
> SHA-256/384/512, or to change to a hash of the SubjectPublicKeyInfo
> they could always the procedures from
> https://datatracker.ietf.org/doc/rfc7093/ to generate the values for
> a 20-byte value.

Something like that could work I guess e.g. if this draft
said "if a router cert contains an SKI that's != 20 bytes
long, then here's what you do..." that'd be fine. I'm not
sure that's identical to what's in 7093 though but it is
close and should be fairly obvious and uncontroversial.

I do think it very worthwhile though to not so closely
couple the code for generating SKIs with that for BGPsec
as they will (I guess) tend to be different codebases not
evolving in a tightly coupled manner.

Cheers,
S.

---

From: Russ Housley <[email-masked]>
Date: Wed, 4 Jan 2017 14:24:05 -0500

> [snip]

I am not sure what you mean by a "compromised AS,” but it may not matters …

If a link goes down, and that causes an alternative path to be selected, that forces the validation a new path which might involve a previously unvalidated AS.  If an OCSP responder or repository that provides RPKI objects is contacted as part of that validation, then some external entities can detect that something is changing.  That is, stuff not normally validated because it is associated with a unselected path gets fetched.

That said, the NOC could fetch a snapshot of the RPKI, then the exposure of the switch to a new path can be limited to that AS.  This assumes that the snapshot uses CRLs, which seems like a very reasonable choice in the RPKI.

Russ

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 4 Jan 2017 19:33:00 +0000

>> (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.)
> 

More or less if traffic to/from ASxxxx is visible to an
attacker and/or can be modified by an attacker. That could
be due to collusion between the AS and an attacker for
example, or because an attacker has compromised some routers
within a transit AS.

> If a link goes down, 

I'm not sure this is only if a link goes down. I'd guess the same
risk would exist when any BGPsec path is first seen at a relying
party and where that RP doesn't have all the necessary RPKI stuff
cached before signature validation.

. and that causes an alternative path to be
> selected, that forces the validation a new path which might involve a
> previously unvalidated AS.  If an OCSP responder or repository that
> provides RPKI objects is contacted as part of that validation, then
> some external entities can detect that something is changing.  That
> is, stuff not normally validated because it is associated with a
> unselected path gets fetched.

Right. Sorry to not be clearer on what might become visible to
the network outside the RP's AS - I'm afraid I just don't have all
the RPKI details in my head;-)

> 
> That said, the NOC could fetch a snapshot of the RPKI, then the
> exposure of the switch to a new path can be limited to that AS.  This
> assumes that the snapshot uses CRLs, which seems like a very
> reasonable choice in the RPKI.

Right, I think all that'd be needed for this would be to ack that
there's this (normally fairly minor) new risk and that you can
avoid it if you pre-fetch enough stuff. (As a separate question,
I wonder if the amount of stuff involved in the RPKI is such that
it'd be fairly easy to pre-fetch it all frequently enough to
nearly never hit this problem.)

Cheers,
S.

---

From: "Mehmet Adalier (Antara Teknik)" <[email-masked]>
Date: Wed, 4 Jan 2017 19:54:37 +0000 (UTC)

while i would also like to see less use of sha-1 in new network protocols...
limiting the SKI length to a fixed 20 bytes is not really a bad idea for implementation efficiency and interoperability.
as Sean points out, rfc7093's straight forward (leftmost 160 bits --20bytes) of a SHA-2 algorithm digest works well for the use of a hash value in this particular context (generating Key Identifiers)..
mA      From: Sean Turner <[email-masked]>
 To: Stephen Farrell <[email-masked]> 
Cc: [email-masked]; [email-masked]; The IESG <[email-masked]>; [email-masked]; [email-masked]
 Sent: Wednesday, January 4, 2017 10:48 AM
 Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-protocol-21: (with DISCUSS and COMMENT)

spt
_______________________________________________
sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr

---

From: "Montgomery, Douglas (Fed)" <[email-masked]>
Date: Wed, 4 Jan 2017 20:00:13 +0000

Stephen,

If I understand your question, I don’t think one can infer anything about
the BGP feeds or route selection processes of an AS based upon the traffic
a validating cache sends to RPKI repositories.

The design of RPKI validating caches (and all implementations that I know
of) prefetch and validate RPKI objects independent of BGP traffic
processing.   That is, they are background processing the entire RPKI, and
are not event driven by BGP traffic.  As a matter of fact, the RPKI
validating cache’s are typically on systems that have no reason to
implement BGP at all.

Also the RPKI-to-Rtr protocol between the cache and router is batch driven
(roughly) by the validation process, not BGP event driven.

I.e., the RPKI traffic to a validating cache in an AS with no BGP feeds
and one with full BGP feeds is the same, and both independent of BGP event
processing.

If that was not the supposition of your question … please ignore.
dougm

— 
Doug Montgomery, Mgr Internet & Scalable Systems Research at  NIST/ITL/ANTD

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 4 Jan 2017 20:48:02 +0000

Hiya,

> a validating cache sends to RPKI repositories.

Is that the same traffic a BGPsec relying party sends?

I can imagine that it might or might not be, but don't
recall the BGPsec spec saying.

If, in fact, it isn't possible to infer which ASes are
likely to be used from the traffic emitted by an RP
for PKI purposes, then yes, this discuss point goes
away. (I think:-)

Cheers,
S.

---

From: "Montgomery, Douglas (Fed)" <[email-masked]>
Date: Wed, 4 Jan 2017 21:39:04 +0000

The RPKI validating caches *are* the relaying parties for BGPsec, they are
(a) designed to be run on a separate box than the router itself and (b)
their behavior WRT exchanges with RPKI repositories is independent of BGP
message processing by any of the routers that they serve.

Maybe the first few sections of https://tools.ietf.org/html/rfc6810 would
make that point better than my mumblings.

e.g., For various research / measurement reasons we run 3 different
validating caches that don’t serve a single BGP router.   Their exchanges
with the repositories are no different than if they served a DFZ BGP
router.

Dougm

—

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 4 Jan 2017 21:45:18 +0000

Hiya,

> message processing by any of the routers that they serve.

Sure. That makes sense. But where's it stated for BGPsec that
the RP ought act that way?

Cheers,
S.

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Thu, 5 Jan 2017 14:10:06 +0000

Stephen,

Thank you for the detailed review and comments.
Please see my responses marked with [Sriram] inline below.

[Sriram] Your DISCUSS points (1) and (3) were already
discussed /being discussed in separate threads.

[Sriram] Signer's ASN is indeed included in the signed data.
In Figure 8, "Secure_Path Segment : N" corresponds
to the signing AS (current AS) and that is where the 
signer's ASN is included along with its pCount and Flags.

[Sriram] Good catch. Already fixed in my editor copy of version-22. 

[Sriram] Again, a good catch. Already fixed in my editor copy of version-22.  

[Sriram] I think it is well understood. But when I push version-22 out, 
I’ll consider if I should simply just use "iBGP peer" consistently 
and avoid using "internal peer". 

[Sriram] Seems like a bit of a pathological case. 
Could happen only if the sender behavior was incorrect. 
Sender is not required to know which algorithms a peer supports 
but sender's expected behavior is this: MUST include a Signature_Block 
for the "current" algorithm (which every BGPsec speaker 
MUST support through the transition period), 
and if the sender supports the "next" algorithm, 
then it MUST include a Signature_Block for the "next" algorithm also.
So the peer BGPsec receiver (who MUST support 
at least the "current" algorithm) is not expected to be starved 
of a Signature_Block it can work with.   

[Sriram] I will include wording to cover this in Section 7 in version-22.

Sriram

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 5 Jan 2017 14:26:59 +0000

Hiya,

> discussed /being discussed in separate threads.

Yep, thanks. I need to check back to see how close we are
to resolving those, but I had thought the ball wasn't in my
court at the moment:-) I'm sure we'll sort 'em soon though.

> signer's ASN is included along with its pCount and Flags.

Hmm. That's the target ASN of the previous signer though.
I thought there were cases where they could differ? But
if not, then you probably need to state that as a rule
for checking signatures, is that there already? (Happy to
check later, but don't have time right now.)

One other thing below...

> Could happen only if the sender behavior was incorrect. 

Yes, but 5.2 is verifier behaviour and out not
assume a correct signer, so I do thing the alg
presented here needs to cover such things.

> MUST support through the transition period), 

Where does it say that the current/next thing applies
to the entire world of BGPsec? I didn't read it that
way as it happens, but rather that the current/next
could involve different algorithms at different nodes
at the same time.

So e.g. I read it to be allowed that a migration from
rsa/sha256 then to ecdsa then to eddsa could occur
with some non-updated nodes still signing with rsa/sha256
whilst some shiny new nodes are doing ecdsa and eddsa and
others are in between.

I do agree that a global current/next pair of algs
is nicer, if that is what's wanted. But I don't recall
the text saying that. (Again happy to check later, but
no time right now;-)

Cheers,
S.

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Mon, 9 Jan 2017 05:22:20 +0000

Stephen,

Please see responses inline below.

>Hmm. That's the target ASN of the previous signer though.

Semantically the "Secure_Path Segment: N" shown in the
data to be hashed in Figure 8, contains the current 
signer's ASN, although logically it is equal to 
the target ASN of the previous signer. 

>check later, but don't have time right now.)

They had differed in one situation but that was
before we put in a fix for the confederation boundary,
and that fix is in the second paragraph of Section 4.3
of version-21. So now we are good. Yes, now 
a signer's ASN always equals the target ASN 
used in the hashed data by the previous signer. 
So in the signature validation, the verifier always
plugs in its own ASN as the target ASN for validation
of the most recently added signature. Without that the
validation of that signature will fail.
That rule is built in into the validation process (page 26):

"For the first segment to be processed (the most
      recently added segment (i.e.  N = K) given that there are K hops
      in the Secure_Path), the 'Target AS Number' is AS(K+1), the AS
      number of the BGPsec speaker validating the update message."

>Yes, but 5.2 is verifier behaviour and ought not
>assume a correct signer, so I do think the alg

Please see response below.

>the text saying that. (Again happy to check later, but

The text does describe it in terms of 
"a global current/new pair of algs" in Section 6.1 (p. 28, v-21):

  "To this end, a mandatory algorithm suites document exists which
   specifies a mandatory-to-use 'current' algorithm suite for use by all
   BGPsec speakers [I-D.ietf-sidr-bgpsec-algs].

   It is anticipated that, in the future, the mandatory algorithm suites
   document will be updated to specify a transition from the 'current'
   algorithm suite to a 'new' algorithm suite.  During the period of
   transition (likely a small number of years), all BGPsec update
   messages SHOULD simultaneously use both the 'current' algorithm suite
   and the 'new' algorithm suite.  (Note that Section 3 and Section 4
   specify how the BGPsec_Path attribute can contain signatures, in
   parallel, for two algorithm suites.)  Once the transition is
   complete, use of the old 'current' algorithm will be deprecated, use
   of the 'new' algorithm will be mandatory, …."

Thank you.

Sriram

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Mon, 9 Jan 2017 05:41:40 +0000

Stephen,

>From: sidr <[email-masked]> on behalf of Stephen Farrell <[email-masked]>
>Sent: Wednesday, January 4, 2017 4:45 PM
>To: Montgomery, Douglas (Fed); Russ Housley

>the RP ought act that way?

I propose adding the following paragraph in Section 7. 
Please let me know if this would help resolve your concern/comment.  

The deployment structure, technologies and best 
practices concerning global RPKI data to reach routers 
(via local RPKI caches) are described in [RFC6810] 
[RFC7115] [I-D.ietf-sidr-bgpsec-ops] 
[I-D.-ietf-sidr-delta-protocol] [rsync]. 
For example, serial-number based incremental update 
mechanisms are used for efficient transfer of just the 
data records that have changed since last update [RFC6810]. 
Update notification file is used by relying parties (RPs) 
to discover whether any changes exist between the state of 
the global RPKI repository and the RP's cache 
[I-D.-ietf-sidr-delta-protocol]. The notification describes 
the location of the files containing the snapshot and 
incremental deltas which can be used by the RP to 
synchronize with the repository. Making use of these 
technologies and best practices results in enabling 
robustness, efficiency, and better security for the 
BGPsec routers and RPKI caches in terms of the flow 
of RPKI data from repositories to RPKI caches 
to routers (in distilled form). 

If you feel that the following sentence adds additional value, 
it can be added at the end:

In particular, by following these methods, security concerns 
related to possible correlation of RPKI data access 
and BGP update events are also mitigated.  

You may edit/suggesting any wording improvements. 
I look forward to your further guidance on this. 
Thank you.

Sriram

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 9 Jan 2017 11:37:17 +0000

Hiya,

Adding the text you propose for section 7 seems good.
You also asked about adding this:

> and BGP update events are also mitigated.  

Maybe better to say something like:

"With these caching mechanisms it is believed that an
attacker wouldn't be able to meaningfully correlate
RPKI data flows with BGPsec RP actions, thus avoiding
attacks that attempt to determine the set of ASes
interacting with an RP via the interactions between
the RP and RPKI servers."

Also, I had a look back at the overall thread and I think
this is where we're at:

discuss point #1: the draft needs a bit of text saying
how to handle an SKI that is not 20 bytes long. I don't
think we have a text proposal but it should be easy
enough, e.g. you could say "If the SKI in a certificate is
not 20 bytes long then if it is longer, use the leftmost
20 bytes. If the SKI value is shorter than 20 bytes,
then pad left with zero bytes." Note that I don't care
which way you prefer to fix this, any way is fine.

discuss point #2: this one's sorted. (I updated my
ballot to indicate this one's cleared.)

discuss point #3: with your suggested text and something
like the above we should be good with this one too

If you'd like to submit a revised ID with those changes
then I should be fine to clear.

Cheers,
S.

---

From: Randy Bush <[email-masked]>
Date: Tue, 10 Jan 2017 14:43:34 +0900

i had to do some ascii porn for rob to deal with a secdir reviewer for
draft-ietf-sidr-publication.  it may help here.  i added the routers for
this discussion.

       +------+    +------+    +------+
       |  CA  |    |  CA  |    |  CA  |
       +------+    +------+    +------+
           |           |           |      Publication Protocol
           |           |           |   draft-ietf-sidr-publication
           +-------+   |  +--------+ Business Relationship Set Up by
                   |   |  |          draft-ietf-sidr-rpki-oob-setup
              +----v---v--v-----+
              |                 |
              |   Publication   |
              |   Repository    |
              |                 |
              +-----------------+     Distribution Protocols
                       |           draft-ietf-sidr-delta-protocol
        +--------------+----------------+  and/or rcynic
        |              |                |
+-------v-----+ +------v------+  +------v------+
|   Relying   | |   Relying   |  |   Relying   |
|    Party    | |    Party    |  |    Party    |
+-+-----+----++ +---+-----+---+  +-+--------+--+
  |     |    |      |     |        |  |     |
  |     |    ++     |     |     +--+  |     |  RPKI to Router Protocol (RFC 6810)
  |     |     |     |     |     |     |     | draft-ietf-sidr-rpki-rtr-rfc6810-bis
  v     v     v     v     v     v     v     v
 / \   / \   / \   / \   / \   / \   / \   / \
|Rtr| |Rtr| |Rtr| |Rtr| |Rtr| |Rtr| |Rtr| |Rtr|
 \ /   \ /   \ /   \ /   \ /   \ /   \ /   \ /
  V     V     V     V     V     V     V     V

we're talking about 6810-bis here, the rpki-rtr protocol which carries
the router keys and origin roas for bgpsec and origin validation.

it is a total database push from the RP cache to the router, not a
piecemeal router driven request protocol.  so a monkey in the middle
receives no clues as to what the router is using.  there is no side
channel leakage that i can see.  i would be happy to be educated
otherwise.

as 6810[-bis] has stripped the crypto of the rpki validataion chain to
the root TA, it no longer has object security; red alert.  so the two
ops drafts, 7115 for origin validation and draft-ietf-sidr-bgpsec-ops
for bgpsec, try to be very explicit about transport protection for these
data.

draft-ietf-sidr-bgpsec-ops points to rfc 7115 for RP cache advice.

  As RPKI-based origin validation relies on the availability of RPKI
  data, operators SHOULD locate RPKI caches close to routers that
  require these data and services in order to minimize the impact of
  likely failures in local routing, intermediate devices, long
  circuits, etc.  One should also consider trust boundaries, routing
  bootstrap reachability, etc.

  For example, a router should bootstrap from a cache that is reachable
  with minimal reliance on other infrastructure such as DNS or routing
  protocols.  If a router needs its BGP and/or IGP to converge for the
  router to reach a cache, once a cache is reachable, the router will
  then have to reevaluate prefixes already learned via BGP.  Such
  configurations should be avoided if reasonably possible.

  If insecure transports are used between an operator's cache and their
  router(s), the Transport Security recommendations in [RFC6810] SHOULD
  be followed.  In particular, operators MUST NOT use insecure
  transports between their routers and RPKI caches located in other
  Autonomous Systems.

so maybe the bgpsec-protocol document can remove, as opposed to add,
text just this once?

randy