Minutes for SIDR at IETF-88
minutes-88-sidr-1

SIDR WG Meeting (IETF 88, Tuesday, November 5, 2013 0900-1130)

Draft statuses: Active: -as-migration-00, bgpsec-overview-03,
-multiple-publication-points-00, -origin-validation-signaling-02, -publication,
-rtr-keying-01.  -bgpsec-algs-05 and bgpsec-pki-profiles-06 are waiting on
their referenced documents.  -bgpsec-protocol-08 and -bgpsec-reqs-08 have
relatively new versions posted.  Drafts that have expired include:
-bgpsec-rollover-02, -ltamgmt-08, -rpki- grandparenting-01, -bgpsec-ops,
-bogons, and -rpsl-sig.  Two drafts are in the IESG’s hands: -bgpsec-threats-07
and -origin-ops-2.  Two others are waiting for write-ups: -cps-03 and
-policy-qualifiers-00. -rpki-rtr-impl-03 is currently in IETF Last Call after
clearing some issues with the Routing Area.

There are outstanding requests for input on three drafts: -bgpsec-rollover,
-rtr-keying, and -as-migration.  Insufficient comments have been received to
date.

------------------------------------------------------------------------

1st Presentation: Rob Austein (Dragon Research Labs) -- RPKI Out-Of-Band Setup
Protocol

The idea of this draft is to provide a protocol (developed outside of the WG)
that will simplify the initial setup of the various provisioning and
publication protocols.  Keys need to be exchanged, along with subject names,
and contact URLs for the server side of the protocols.  This protocol provides
a mean to set those values up.  The transport doesn’t matter; the setup
protocol needs to provide security regardless.  Traditionally, these BPKI
(Business PKI) certificates and URLs are passed around with frequent mistakes
leading to difficulties in development, testing, and deployment.  The setup
protocol encapsulates the values used in the setup and labels them clearly. 
This protocol doesn’t rely on wholly new mechanisms; the syntax used may be
different, but the semantics of the data remain the same.  It should be
relatively simple to update existing implementations of the RPKI protocols to
use the setup protocol.  Use of the rsync protocol led to hierarchical
placement of children nodes under parent nodes in the repository for reasons of
efficiency.  None of the entities in the protocol (publisher/child, repository,
parent) have to provide services to each other just because the protocol is
used.  BPKI keys are formatted as self-signed BPKI certificates.  Is the WG
interested in adopting this de facto standard? (Question remains open.) BPKI
certificates are X.509 certificates and are used in verifying CMS signatures on
published information.

Q&A and comments from floor:

Tim: I assume that BPKI certs look like RPKI certs.  Austen: good working
assumption.  Kent: not sure that SIA and AIAs are needed in BPKI certs. 
Austen: agreed – but the similarities between RPKI and BPKI certs within the
scope of PKIX certs are fairly strong.  Austein suggests that this draft should
be on the Standards Track. Sandy: Acceptance decision for WG draft will happen
on the mailing list.

------------------------------------------------------------------------

2nd Presentation: Rob Austein -- Whither draft-ietf-sidr-publication?

This draft is already a WG draft (from October 2010) but hasn’t seen a lot of
updates.  It basically lists what Austein’s implementation does.  No major
protocol changes in over two years.  The protocol allows one to separate two
different functions in the CA side of the RPKI system.  The engine that
generates the certificates doesn’t have to control where they are published. 
They might be the same, but they don’t have to be.  The repository should be
highly available, while the CA engine need not be.  This leads to different
security policies and it may lead to their separation.  The protocol specified
in this draft defines how the CA engine talks to the publication engine. 
There’s only one implementation of this protocol, although Tim Bruijnzeels has
re-used parts of the protocol.  He suggests that the protocol could be
simplified down to the <publish/> and <withdraw/> operations.  The authors
believe the draft could be finished off with some examples and the usual
mandatory sections; they are divided on whether to do the suggested
simplifications.  They do not believe it should wait to see what the rsync
replacement will look like.  The rsync replacement could have implications for
the publication protocol, but the timeframe for the replacement is too far in
the future to hold up this draft.

Q&A and comments from floor:

Randy: There is only one implementation currently. Trimming back (accepting
Tim’s suggestions for simplification) may make it easier for others to
implement.

Andy Newton: How many have deployed this?

Randy: This is used in Asia and Europe.

Steve Kent: Make this “a” standard way not “the” standard way.

Rob: Large # CAs and small # repositories; then we are talking about “the”
standard way.

Randy: Google may be a publication point. Rest of the net doesn’t want you
necessarily publishing where the CA is. Your fetch is going to hang if you’re
out on an island.

Rob: Consensus seems to be that we drop the extra stuff per Tim’s suggestion.
This is intended for standards track.

Tim: Yes, standards track will be good.

Note taker observations: Feedback from the group was mostly in favor of moving
forward with the draft. There isn’t a one-to-one mapping of CA engines to
repositories, so it makes sense to have a single standard to cover publication
services.  This draft would probably be headed for the Standards Track.

------------------------------------------------------------------------

3rd Presentation: David Mandelberg (BBN) – RPKI Validator Testing

Recent testing was against BBN’s conformance cases (349 of them).  Bugs were
found in all three tested validators and in one conformance case.  Questions
were raised about ambiguities in the specifications: 1) Can SIAs contain
non-URI accessLocations?  2) Can CRLs list invalid serial numbers? (Certificate
serial numbers are bounded, but CRLs currently aren’t prohibited from
containing invalid serial numbers.)  Next steps: fix some bugs in the test
suite and re-run the tests on Thursday.  More participation is welcome.  The
conformance cases are available from SourceForge.

Q&A and comments from floor:

Rob: CRL serial number zero or >20 octets? Can you revoke if they did that?

Steve Kent: No one should accept. We need to provide strong feedback to CAs.

Wes Hardaker: We’ve started to accept things that should never have been
allowed. Get stronger about not accepting rather than live with ambiguities
later.

Kent: CRL syntax cannot be ambiguous. Any failure to conform should result in
rejection.

Sandy: Are conformance tests part of the RPSTIR software release?

David: Yes. If anyone wants, I can also send performance test cases.

------------------------------------------------------------------------

4th Presentation: Steve Kent (BBN) – Suspenders: Mechanisms to Protect RPKI
Resources Holders Against Errors (and Worse).

Local Trust Anchor Management was presented at the last meeting without a
draft, so one was requested.  A -00 version was published a month and a half
ago.  LTAM addresses two primary use cases: 1) allow local use of RFC 1918
address space by an ISP without breaking things for the ISP; 2) provide a basis
for protecting resource assignments against errors or law enforcement actions
that go beyond the law enforcement agency’s jurisdiction.  LTAM has been
presented at SIDR meetings since July 2009.  Suspenders is a replacement for
LTAM (except for the RFC 1918 address space use case), covering the resource
protection case (use case #2 above).  The focus is on bad things that could
happen to ROAs.  It could be extended to deal with router certificates in
BGPsec.  The three components are: 1) INR holders detect when their own ROAs no
longer validate (meaning something bad happened); 2) INR holder publish
external info to “protect” their ROAs against unnoticed change; 3) RPs detect
adverse ROA changes and use the externally published info to decide on the
validity of the changes or whether to use previous data.  Adverse ROA changes
come in two forms: 1) Whacking: Somewhere between the trust anchor and ROA EE
cert, something changes that invalidates the ROA cert: this could be EE or CA
cert revocation, or CA cert changes that percolate down the chain, etc., and 2)
Competition: A new ROA is published by another entity that improperly overlaps
in prefix with an existing ROA.  INR holders should monitor their own ROA data
to verify that no adverse changes have occurred.  INR holders need to be able
to signal to RPs whether an observed change was an error (and subject to
correction).  Information published separately from the RPKI repository system
would allow the INR holder to do so.  With outsourced CA and publication
services, this scheme is a bit harder since the INR holder may not be able to
affect those services directly.  The Suspenders scheme is optional.  RPs
shouldn’t find it much of a burden since it only comes into play when an
adverse change is detected.  The solution involves a LOCK record that the INR
holder adds to its publication point.  This is signed within the RPKI.  The
object points (via a URL) to a data file and public key (to validate the data
file).  The data file lists changes (additions/deletions) made and when they
were made.  The data file is changed prior to the INR holder making the actual
changes to its ROA data.  The data file (called an INRD file) is retrieved by
the RP if it believes there has been an adverse change, assuming a LOCK object
exists to point to the INRD file.  Inconsistencies between the change and the
INRD file cause the RP not to accept the change. Proposed next steps: 1) revise
the LTAM document so it contains only the 1st use case; 2) take on the
Suspenders draft as new work; 3) update RFC 6481, 6483, and maybe 6480 to use
the new LOCK/INRD scheme.  No decision was made on going forward with these
next steps.

Q&A and comments from floor:

Sriram: Consider a little guy who has a /16. A big guy in the cert hierarchy
above the little guy creates two competing ROAs (/17s) that cover the little
guy’s /16. The big guy then announces the two /17s. How does your scheme
protect the little guy in this case? (/17s announcements trump the /16 in BGP
route selection).

Steve Kent: Time history comes into play. Make use of the timeline of changes
made in order to let the little guy’s /16 ROA and update prevail over the big
guy’s /17 ROAs and updates.

Doug Montgomery: Socially acceptable vs. not socially acceptable changes made
by the higher authority; adverse change that might be legitimate.

Steve Kent: Old stuff carries greater weight over the new stuff. The scheme
deliberately favors the little guy.

Sam Weiler: (note taker missed the question)

Steve Kent: Same answer as given to Doug’s question. We’ll have to later see
how to take care of the adverse but legitimate change.

Andrei Robachevsky: Regarding the time duration consideration, when you say a
little while, how long can it last?

Steve Kent: How far back we go in terms of list of additions and deletions?
LOCK does not expire; change it when needed. How long someone holds on to it is
up to them.

Andrei Robachevsky: There is BGP, RPKI, and now a third pace. This third
universe will grow. You are not mandating RPs to do this?

Steve Kent: If no one ever publishes LOCK records and INRD, then RP may say it
is not worth implementing this. You cannot mandate anything on RPs.

Wes George: How do you do this systematically? Who does the RP trust, who do
they not trust? The side band (with suspenders proposal) makes it more complex
(than what we have today). Analogous to the route leaks problem. Makes it
difficult to know what to pay attention to, and what not to pay attention to.

Doug Montgomery: Changes due to normal business relations changes far outnumber
whacks. So you risk muddying things. Hierarchical relationship adds strength.
With this [proposal], you have to have “Valid”, Invalid”, and a third state
“under dispute”.

Tim: This is suspicious of [adverse] changes by nature. It is saying, “Ignore a
change to resources”. A low tech way to provide additional protection in an out
of band way.

Ruediger: It is trying to address a question we (operators) have been asking
for many years. In the real-world, if something breaks, how do I know what
exactly happened? Once in a while, I need to admit, things are looking dubious,
and I need to look at explicit fallback data, if I want to be more than just
naïve. I am happy there is proposal here, but we need to scrutinize it; it
should not explode in an unexpected way.

Randy: I agree with Ruediger, but we don’t have use cases, requirements, etc.
The additional extra data has appeal, but the new timing-based decision
elements in it are not appealing.

Wes George: How do you manage it on the other side? Consider the RFD analogy --
I am in a recovery mode but this time sequence stuff hinders me.

Wes Hardaker: May be split the document into two separate documents. The first
one speaks of the detection mechanism (lessons learned; what new things have
detected, etc.). The second one (at a later date), defines “whacked” etc. and
the solution.

Steve Kent: When you talk about detection, self-detection is possible.

Wes Hardaker: Others can also help monitor others. Whatever you can detect
(concerning what is going wrong) based on who you are.

Sandy: The RIPE community is urging members, telling them that they are
responsible to manage their address space. But you say that this is all skewed
towards the little guy. So there appears to be a conflict here.

Steve Kent: I think this will be rare but will check.

------------------------------------------------------------------------

5th Presentation: Sandra Murphy (Sparta) – “RPKI Validation Revisited” –
revisited

This is a follow-up to the presentation at the last meeting by Geoff Huston and
subsequent discussion on the mailing list.  No conclusion on the topic seems to
have been reached. There appear to be multiple motivations for this work: 1) to
support resource transfers; or 2) a CA is compelled by law to make a change; or
3) a fat fingers error needs to be corrected. Murphy’s opinions on the
motivations (from her presentation) were batted down without full presentation.
 The discussion comes down to whether the problem is something important and
whether to cover it in the IETF; if it is, is Huston’s draft the solution or
one of the solutions?  Huston believes that the current system is fragile and
requires too much perfection high in the RPKI tree from the entities in the
system.  He states that his proposal subtly alters the validation scheme
resulting in simplicity and more robust operation.  Steve Kent suggests
removing the “transfers” motivation from the list as he has a draft addressing
it separately and he posits that transfers may not turn out to be particularly
frequent.  There’s a debate over the semantics of the certificates in Huston’s
scheme.  The authors of the draft believe they have not changed the semantics,
while some others (Austein, etc.) do not agree.  Kent notes that Huston’s
scheme will have a performance impact, with performance already being a
complaint about the RPKI in certain cases.  This discussion will be continued
on the mailing list, but it looks like the WG will adopt the document for
further work.

Some additional specifics of Q&A and comments from floor:

Steve Kent: Like to take the transfers part of it out of the motivation in
this. APNIC -- with 2 good presentations on transfers -- takes good steps to do
this. In APNIC, there is the ability to provide advance notice to resource
owners. As of July 2013, thirteen transfers took place ARIN -> APNIC; this may
grow in the future. With IPv6 working well enough, price of IPv4 address space
may go down. Not expecting large transfers across RIR boundaries. Geoff can
tell me if I can’t find the right TA that can validate. Need to see that kind
of precedent.

Someone at the mike: The draft solves an issue for RIRs. We support it.

Geoff: Can I find that every cert in the validation chain has a superset of
what [resources] I am validating in that EE cert? The question is not cert
based; instead ask can the system validate the resources in the EE cert?

Rob: I agree with Steve Kent – I don’t understand what cert is in Geoff’s
model. As I see it, cert holder holds these resources for now. Geoff’s model is
much murkier for me.

Rob: I am concerned because it is a very expensive change.

George Michaelson: There is no semantic change to the meaning of the cert. It
doesn’t change what you do when you do the attestation; changes only the
validation procedure.

Steve Kent: Changes have to be made in multiple documents [in order to
accommodate the proposal]. Ruediger: There is a need for documenting how
transfers should happen. There are problems that higher up CAs can cause that
need to be identified.

Rob: I didn’t get that at all.

Ruediger: I get resources from APNIC and ARIN, with Geoff suggestion I could
actually make a joint certificate.

Rob: I don’t understand how to make a joint certificate.

Randy: Geoff is willing to show it on paper.

Randy: I can see the shrink [in allocated resources] happening in reality. But
I am not sure that there are no side effects [of the solution].

Geoff: Keys you use “up” are not the same as those you use “down”. Validation
says I need a path all the way to the root. Any resources that get validated
are those that pass all the way up the chain. Semantics of how you create certs
does not change. If you flip this and look at a different validation model …. 
It is not the cert semantic that is causing [complexity]; it is the resources
in the certs. This cert has these resources; nothing else changes; win is one
of robustness.

Ruediger: I don’t have an opinion what this means in RPKI system. Responding to
Randy’s comment, is it worth the complexity? If we go with this, certain
problems go away for RPs. May be I have to pay for complexity to help solve the
problem? I don’t have an opinion if complexity should be added but it may be
worth it if it is solving a problem.

Andrei Robachevsky: I agree that this may make the system more robust. It might
be that changes along these lines [Geoff’s proposal] may solve some the
problems identified with the “suspenders” proposal.

Randy: This goes first to the list. Adopt when it is interesting discussing and
working on it; not when it is perfect.

Sandy: Encourage people to consider what the problems are that we are concerned
about and if this proposal addresses the problem.