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

: Secure Inter-Domain Routing WG (sidr)
: IETF 96 - Berlin, Germany
:
: CHAIR(s): Sandra Murphy sandy at tislabs.com
:           Chris Morrow morrowc at ops-netman.net
:
: =====================================================
:
:
:
: AGENDA:
:
: THURSDAY, July 21, 2016
: 1000-1230  Morning Session I                        Bellevue
:
:
:
: 1)  Administrivia & Draft status                                       
1000-1010 : :     Presenter: Chairs : :    - Mailing list:
http://www.ietf.org/mail-archive/web/sidr/index.html :    - WG Resources:
http://tools.ietf.org/wg/sidr/ :    - Minute taker? :    - Jabber Scribe? :   
- Blue Sheets :    - Agenda Bashing : : 2)  Existing WG Drafts : : a)  RRDP and
HTTPS                                                        1010-1025 :    
RPKI Repository Delta Protocol :    
https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/ :    
https://tools.ietf.org/html/draft-ietf-sidr-delta-protocol-03 : :    
Presenter: Tim Bruijnzeels

Rob: Mine https in TAL; trivial implementation with Python/OpenSSL.

Tim: Java makes it painful but there is a way to do it, while we have not done
it; fall back to accept eveything strategy.

:
: b)  Updates to ROA and BGPSec Router Certificate profiles               
1025-1045 :     RPKI Validation Reconsidered :    
https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-validation-reconsidered/
:    
https://tools.ietf.org/html/draft-ietf-sidr-rpki-validation-reconsidered-06 : :
    Presenter: Tim Bruijnzeels

Tim: Good idea to issue separate ROA for each prefix.
Tim: "Intent was to break relying parties... but with plenty of time to update
relying party software so it wouldn't ever break in practice." Rob: It is a
protocol change (so, agreeing). Also, there's a problem with OpenSSL (the
libraries), has been for a decade. I want to make sure that once we've changed
the semantics we don't trip over the broken library code. Backward
compatibility == a ticking time bomb. Tim: I'll need help to identify OIDs that
need to be updated and what refs need to be chased. I'm ok with the idea in
principle but need help in practice. Also need to know that there is WG
consensus for the general approach -- if you have an objection, please speak
up. Sandy: In previous cases everyone has asked Russ to fix anything with "OID"
in the sentence. Russ: I don't do that any more. IANA does it now. (Describes
the usual early allocation process.) Still expert reviewer for registry. Tim: I
knew that but we have lots of docs with refs to 3779, we need to validate all
those and it's a lot of detail to get right. Russ: The OIDs we're discussing
are in 3779. Doug: The other RIRs should also comment on whether they're
comfortable with the plan. Tim: The specific dates on the timeline are just a
strawman. We do need to finalize a timeline in the eventual doc. Andy N: All
the RIRs are discussing the issue, and do support the idea. Rob: The CA side is
a trivial change. Only real work is on the RP side... and the document changes.
Tim: And delegated CAs (parent new/child old or vice-versa). Sandy (as WG
member): Are we going to need to keep the trees distinct, or can we mix them?
In terms of algo transition? I agree that has to be considered. Glad you
changed thinking about EE certs. Ruediger: Don't say "ensure all RPs behave the
same" when you mean "they use the same algorithm". Tim: Understood. That's what
I meant. Rob: To Sandy, I think it works if for each object you obey the rules
for the object when in mixed state. You may not get intended results, but you
get consistent results. Sandy: I understand that. Reason for OID is to make
difference in semantics clear, though. So mix in tree sounds... I'd have to
think about semantics of validation-reconsidered -- are they a subset of the
other. Other comment was about separate EE certs for distinct prefixes, I
understand that's easy for 12/8 and 100/16 in same cert, can separate those,
but in cases where you have a /16 and are carving a /18 out of that you can't
do that as distinct certs. Tim: It's already best practice to ROA the
announcements you're doing. Technically you're right but I don't think it's a
huge issue. Sandy: ARIN i/f has org ID and whatnot, you click to certify all at
once -- does that make it difficult for them to separate them out? Point being,
different RIRs might have architectural complexity to do this. Tim: I think in
case of ARIN, actual ROA is specced by the user, not the hosted system. As for
us we automatically create the ROA. In ARIN's case, anybody could manually do
it. Andy: Confirmed. Tim: It's a recommendation, not a mandate. Identify the
risk and offer the option of separation to mitigate it. Sandy: Also I agree
with you that more updates may need to be added to the header. Sean Turner:
(for the chairs) since bgpsec-pki-profiles is through WGLC the authors are
looking to be directed as to whether to incorporate the changes inspired by
rpki-considered? Sandy: Since none of the changes are fundamental (they were
already possible) it's OK. Sean: great I'll post away!

Tim: In our (RIPE) case it is trivial to create separate ROAs.
Sandy: We can end up with graph dependency problems between the two docs.

Randy: I thought we'd agreed this doc would have in its boilerplate header what
docs it modifies and updates. Sandy: We wanted to avoid the inclusion of
anything in the PKI profiles that would make the PKI profiles rely normatively
on this doc. Tim: To the chairs -- can this doc update the profile doc that's
now in the queue? When it's published we'll have a RFC to cite, and this doc
will just update it. If that makes the process easier, we can do that. Sandy:
Will check with the AD when and if needed. Alvaro (RTG AD): Whatever you want.
It's all good. You don't have to wait for an RFC number to put UPDATES in.
Process will work.

:
: 3)  Other Work, Not WG Drafts
:
: a)  RPKI vs BGP Global Statistics                                       
1045-1100 : :     Presenter: Tim Bruijnzeels

Focused on v4, not sure if v6 prefix span is a reasonable proxy for affected
users, unlike v4. Lot of big players participating in France. Explains why a
lot of address space is covered. Where adoption is low, seems to also correlate
with low valid fraction.

Sandy (WG member): what's the relevance of PI space to space covered by
announcements? Tim: In our terminology these are orgs that have resources but
aren't a RIPE member. Less contact with us so probably less likely to use RPKI.
Tend to be smaller orgs, less network-oriented, smaller prefixes. Ruediger.
Opposite of PI is Provider-Connected, in RIPE region, PI means (more or less)
end users, tend to have small blocks, expertise and resources for RPKI are
lower than for network operators who do it as a primary business. (Further
comment regarding difference between difficulty of PI and PA to update DB
because of authentication mechanism, I think I'm suggesting PI has a harder
time doing it.) Tim: It's possible but yes, PI has a harder time. (Elided long
description of RIPE auth mechanism.) Taiji (JPNIC): Japan is similar. 2000
address holders in PI. They have a web portal but don't necessarily know what
AS is origin AS. : : b)  Problem Statement and Considerations for ROA Mergence 
              1100-1112 :    
https://datatracker.ietf.org/doc/draft-yan-sidr-roa-mergence/ :    
https://tools.ietf.org/html/draft-yan-sidr-roa-mergence-00 : :     Presenter:
Yu Fu Approximately, 50% ROAs have single prefix and the other 50% have >=2.
Avg # prefixes per ROA is about 7.6. Many prefixes in ROA imples that any
change in the ROA causes much churn in RPKI and may impact BGP convergence.

Randy: Thanks for teaching me a new word! "Mergence!" It is exactly the right
word to have used. Randy: You are right. One prefix per ROA is the right
operational thing to do. Multiple optimizes the wrong resource. There are 27
ROAs in the global RPKI with > 100 prefixes. Tim: Touched on this in
validation-reconsidered. There we do recommend what you suggest. Might cover
what you want, I hope so. Other thing, on one slide you mention that an
announcement would be invalid if there were multiple pfx and one was not valid.
Actually would be not-found, not invalid. Ruediger: AFAIK mfg ROAs is something
no user of a CA actually does. AFAIK in multiple implementations, the CA user
works with a frontend system and the CA implementation manufactures the ROAs
from that. If you see something that looks weird, the CA front end software is
at fault. Good news is a few points can be fixed to correct this. Ruediger: A
surprising number of resource holders say "please do this ROA for my /16 and
include all more-specifics down to /24" and then I see a long list of
more-specifics that are already covered ALSO be explicitly configured. If you
look at a current table from the beginning you'll see an example right away,
another within a few pages of scroll. It's weird but not harmful. But what were
they thinking? Rob: To RV's point, the approach we've taken for years in our
implemenation is that's it's possible to do multiple prefixes but we don't make
it easy. Our GUI doesn't do it. The CLI can be persuaded to do it, if you try
hard enough. Default is one per ROA. Highest we are seeing is about 370 per
ROA. Carlos, LACNIC: It's not possible to make general assertions about what
GUI does. LACNIC GUI will let you do whatever. It will suggest you pack, will
let you unpack if you want. Tim, RIPE NCC: We do bundle, but we're happy to
change that. Will make our code easier, glad to do it.

:
: c)  RPKI Deployment Considerations:                                       
1112-1125 :     Problem Analysis and Alternative Solutions :    
https://datatracker.ietf.org/doc/draft-lee-sidr-rpki-deployment/ :    
https://tools.ietf.org/html/draft-lee-sidr-rpki-deployment-02 : :    
Presenter: Yu Fu Doug Montgomery: The same comment Tim made earlier. You want
be careful about "Invalid". Quite often it would be "Not Found / Unknown"
rather than Invalid unless there were specifc actions that cause specifc ROA
changes. : Tim: Regarding call for adoption, I think it's good for you, if you
see concerns, to bring that up. Good to discuss. For many of these issues,
there's been an excess of discussion. Many of these things have solutions. In
present form I don't think it's ready for adoption. That doesn't mean we can't
talk about it, I hope you see the difference. WG adoption however, implies we
agree there is a problem and agree needs a new solution developed. Yu Fu:
Question, do you think this work makes sense/is meaningful? Tim: For example,
scale of repo, already in RRDP doc. Not sure why we need another doc for it. We
can discuss it of course. YF: Information draft for guidance for deployment. Do
you think there is a place for RPKI deployment drafts? Tim: Not sure how to
make myself better understood. There are a lot of issues you touch on, it's
fine that you raise them, but I would prefer to discuss them as a non-WG doc.
YF: Thank you. Randy Bush: The word that frames this is "guidance", RIPE and
CNNIC have seen issues with deployment. Want to communicate them. Not sure
that's strong enough for BCP, but informational doc framed as "best hacking
practice", I can live with that. Ruediger: Agree. We haven't yet figured out
how to group the problems. So I agree with some of Tim's concerns. Operational
concerns and guidance are needed, this is a good contribution. I don't think we
are in a state where we feel this is the right grouping of problems to publish.

Doug:    Don't we have OV operations doc?
Sandy: Yes, we do
Doug: Distributed system; linkages between components fail. Take the OV
operations doc and see of enough is said there about it. If not, revise the doc
and see if issues are addressed and recommendations enhanced  there. Many of
these have been discussed for a long time.

Tim: I have no issue w/ a guidance doc, I just don't think this doc is in that
state. Let's have the discussion, see what remains to determine what should go
in a general document. This is a good initiative, just don't think it's in a
state where it's ready to be a general document. YF: Thanks. Randy: Doug, I
can't think of anything we haven't discussed repeatedly. There are two
religions about doco acceptance by WG. For example IDR, the document must be
perfect before adopted, then wait for two implementations. Other, that I
learned as a child, this is something we want to work on, doco gives us some
place to discuss. It's a placeholder. Sandy (WG member): some of the issues you
raise sound related to adverse actions draft (slide 16/19, CAs revoking certs).
Have you encountered this issue (CA revocation improperly) in deployment? Or is
this a theoretical? IMO it's been built in deliberatly from the beginning. So
what am I supposed to do with the observation? How am I supposed to act on it?
YF: It could happen. Sandy: Have you experienced it? YF: Testbed. Ruediger:
Insistence on observed problems is a bit weird in the security area -- security
is about trying to foresee attacks before they are observed in the wild. So
those questions are very valid. There is overlap with adverse actions doc.
Resolving overlap and producing a result that's useful for a RP to figure out
what attacks its implementation might be vulnerable to, is a good goal. This
doc is not yet doing that. We should discuss these problems, we should generate
docs about them, this doc is not perfect. I would support admitting and
discussing this document, refactor with adverse actions doc. Rob: Work is
useful. Overlap with existing docs means it is not ready to be moved forward.
We should adopt it but understand that it might never be published as an RFC.
Main point, WG should work on these issues. Do not assume it will become an
RFC. Zhiwei Yan, cnnic: This document is mostly problem statement. I hope in
the future it addresses solutions.

: d)  Observations reported previously and a few new findings.               
1125-1135 : :     Presenter:  Ruediger Volk

Canceled.

:
: e)  Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties
:                                                                              
                   1135-1145 :    
https://datatracker.ietf.org/doc/draft-madi-sidr-rp/ :    
https://tools.ietf.org/html/draft-madi-sidr-rp-00 :     Presenter: Declan Ma

Rob: Abstain from opinion as to whether it should go forward. I am the worst
person to evaluate clarity of current doc set. One specific followup -- my
current implementation is close to what RIPE does since techniques are dictated
by RRDP. I wouldn't say I'm 100% following RIPE, but closer than you might
think. Russ H: in PCIX we have similar docs, don't know if implementors find
them useful. Would be worth checking before repeating the exercise. Let's not
create a write-only document. Oleg: I commented on the list, to reiterate I'm
not opposed to your effort, but not sure it won't create yet another document
to the 11. So does this simplify matters, or just add one more piece of
mandatory reading? If we're going to accept the work, you and the WG have to
commit to actively keeping the doc updated and consistent. Declan: So, if we do
this work we have to spend more time to keep it up to date? Is that your point?
Are you saying that means the work is not reasonable? Oleg: There are two ways
forward, either this is yet another doc that describes everything an RP should
do, that means it has to be consistent all the time, or it's more informational
in which case the document is too specific and detailed. Start by making it all
one thing or all the other. Ruediger: Slide 9, the way I look at this is the
RIPE NCC doc should be a precise product description, the users need it for
operation, potential users need it for procurement. Your doc could be useful
for someone evaluating offerings. (more points elided) I very much agree with
your bottom line ("appropriate to proceed with both"). Sandy (WG member): I was
struck by Oleg's comment about how are we going to keep this current? This doc
will have to be updated constantly.

John: About keeping the doc up to date for years to come.. we have existence
proof that Internet Drafts that are constantly revised and never completed can
happen. Options: ID that never goes to RFC or keep it as a wiki instead.

De Ma: Requested Tim for a recap of his suggestion.

Tim: Time is limited for all of us. Have the same concerns about how you are
going to keep it current. It is also a concern for our own doc. Something we
need to think about also. May be we consider it (your doc) should be something
other than than an RFC. Even that (something else) may be a lot of work.

De Ma: May be we continue this topic on the mailing list.
:
: f)  RPKI Multiple "All Resources" Trust Anchors Applicability Statement
1145-1200 :    
https://datatracker.ietf.org/doc/draft-rir-rpki-allres-ta-app-statement/ :    
https://tools.ietf.org/html/draft-rir-rpki-allres-ta-app-statement-01 : :    
Presenter: Carlos M. Martinez

No comments
Sandy: We'll request WG adoption soon

SIDR in OPSarea
Presenter: Chris

"SIDR is almost done" 3-6 months of work left. (grim chuckling).
Proposal for creation of sidr-ops in OPS area.

Randy: Will both groups coexist?
Chris: AD question but RTG mailing list will continue to exist but otherwise WG
will close. Randy: Will there be a relaxation of impl requirement? Chris:
Hopefully OPS isn't speccing protocol. Joel J (OPS AD): Hopefully we won't be
looking at protocol enhancements. So charter should steer clear of
implementation. It's not operationally useful if everyone does everything
differently. Alavaro (RTG AD): Yes, protocol enhancements will be done in RTG.
We'll recharter WG if required, or find an appropriate home WG (RTGWG, IDR,
etc). I would love to see OPS group meet in Korea and RTG group finish before
Korea. Don't hope for long coexistence but it's up to you. Randy: To be
specific, we don't have interoperable full impls of CAs. That is not FUTURE
work. Joel: Call it out in the charter if you want to work on that. That may be
a specific work item. We should tease that out. Ruediger: To Randy, what does
interoperability testing mean for CAs? Delegation? We've done that in at least
one direction. Right? Randy: Not all CAs impl all objects. John: If the
documents really are almost done, comments on the previous talk don't apply. If
the document set is "done", it makes sense to try to write an overview doc and
not have to revise it constantly.

Chris: Some focus. FOCUS on "Finish". Get the docs that are ready for
publication request to move ahead -- all the protocol related documents (that
were listed in the slide).

Joel: The preconditin to from an ops group is that we have something that is
deployable.

Carlos: It's pretty deployable.
Rob: To WG as a whole -- how concerned are we about not having complete,
interoperable implementations of CA? To my knowlege I implement everything. I
think the rest implement almost everything but not quite (e.g. Ghostbuster
records). I dunno if Java-based ones handle up/down. How much do we care?
Everyone has their own work priorities. Chris: Someone needs to do an
implementation report (with fewer guesses). Sandy: RRDP implementations? Tim:
RRDP is there. We don't have running "child" code but we have it in a test
setup, not blocking from a protocol PoV. We don't implement Ghostbuster records
and router certs. Issue for hosted platform. Depends on what our members tell
us they want. We could work on it if people tell us to do so. We have
constraints just like everyone. Not sure if that blocks protocol. Randy: Let's
not go into all the details on the floor, now. Let us do ops testing and
inter-op testing. : : g)  ROA Misconceptions                                   
                    1200-1205 : :     Presenter: Randy Bush

Ruediger: if we'd been more careful in wording we could've avoided using the
word "valid" so many times in so many places and contexts. We have used "Valid"
in Validation-Reconsidered in one sense also and "Valid" in origin validation
in a different sense. In continuing and further work, maybe we should make the
language unambiguous. Rob: We tried that. People appear to prefer to be
confused. One quibble, Randy stated you never see invalid ROAs in the crypto
sense. Not 100% true, if looking at raw data you can see them, else not. Jakob
Heitz: Why did you put this up? I didn't think it was a surprise. But anyway,
another to add -- if you put a ROA in, you must advertise that prefix. (shouts
of "no!") Jakob: If you intend not to advertise it you should put the ROA for
AS 0. (shouts of "no!") Randy: I'll tell you why not. I'm Ruediger's customer.
I want to switch to Jared. Make-before-break. I'm going to ROA on Jared's
network while I switch over. Dup ROAs are a common MBB practice. Jakob: I never
said otherwise. Randy: Yes you did. Jakob: If you intend the prefix should be
private, then ROA it with AS 0. Randy: Oh sure. Sandy (WG member): Agree w/ RV.
(At one point, in path validation (BGPsec), we tried using "not good" but no
more.) About never seeing ones that are invalid, RPKIViz will show you such (or
ones about to expire).

:
: h)  Berlin's ROA Signing Party                                               
1205-1210 : :     Presenter: Markus de Brun

(no slides)

We had a ROA signing party during the lunch break Wednesday. About 20
attendees. Some knew what RPKI was, some German ISPs being introduced to it.
Five ops present, three decided to create ROAs, a success. I would like to see
this become a regular thing, invite local ops and introduce them to RPKI, to
build traction. Suggests for next time, send invitation more than two weeks in
advance.

Sandy: We also had network problems.
Markus: Nope. We had some trouble with explaining max prefix length. Also a
problem w/ web site from RIPE but otherwise no problem.

Randy: there is a real running RPKI -- parent/child up/down

Taiji: We had a similar event, important for deployment. But sometimes IP
address holders aren't network operators. We prepared materials for
dissemination w/in organization to connect address holders.

Meeting closed 12:35 pm
:
: 4)  Discussion                                                               
1210-1230

:
: