---------
SIDR
---------

Minutes: Matt Lepinski and Karen O'Donogue

Sandy: There has been so much traffic on ROA Validation, I am not yet
comfortable saying that the working group has reached consensus on ROA
Validation draft


RPKI-RTR Protocol by Randy Bush

-- Newest version removed the fields Color and Source

-- This draft has running code (both client and server)

-- This draft is ready to move forward to WGLC


Certificate Profile by Karen Seo

-- Karen Seo: ... Presents slide on Overview Paragraph 2

-- Geoff : IANA currently runs a special purpose IPv4 registry, and thus has
the ability to allocate

-- Randy : It is not our prerogative to state policy for IANA

-- Terry M: Currently IANA is interested in this text, please send the
revised text to IANA for review

-- Andre: Make the text in this section as simple as possible

-- Geoff: The current text implies exclusivity that doesn't exist (IANA does
not allocate only to the RIRs)
          ... But I think that Andre's version is too short, I want more
words

[Note: Randy and Geoff agree on what's wrong with the text this is
unprecedented]

-- Tim (SEC AD): We should not let one paragraph keep this document from
moving forward out of the working group.
          We need to make this shortly



-- Sandy: What about 6to4, how does that work in our architecture?

-- Randy: This is just anycast ... if it needs to be validated, whoever owns
the space (IANA) should issue a ROA to everyone who wants to originate it

-- Russ: Or we can just define an "Any" ROA

-- Randy: We do not want to go with wildcard ROAs




Many Documents Updated by Geoff

-- Keyroll is ready for WGLC

-- Res-Cert is ready for WGLC

-- Repos-Struct is ready for WGLC

-- Russ H: I think that CMS Signing Time is the right answer,
   ... but you need some text in the security considerations that indicates
what happens if someone gets their clock screwed up and signs something way
in the future

-- Provisioning Protocol is ready for WGLC

-- Geoff presents about ROA-Validation

-- Geoff: The simplest text that conforms to the current BGP spec is that if
the aggregator field is present, then it is the origin
          (This is the text in the -07 version)

-- Randy: Can we not speak to AS-SETs and then they'll go away?

-- Sandy Chair: No

-- Sandy Chair: I don't care what the answer is on AS-SETs but there needs
to be an answer

-- Rutiger V: Can we just say that if there is an AS-SET, then we don't
evaluate

-- Dave W: I believe there may be implementations of Pordosh's draft (which
draft) which addresses this AS-SET issue

-- Sandy Chair: If you come across such an implementation, can you ask them
to provide their implementation experience to the list

-- Rob A: We need text that says ROAs don't apply to AS-SETs
          Can Sandy Murphy as an individual put forward a statement that
says "to hell with AS-SETs and ROAs", and then we can all agree with her and
the chairs will be happy and we're done

-- John S: I think Warren's draft will progress through IDR and will cease
to be watered and down and will have the effect of making sure we no longer
need to have these conversations
           I think there are about 6 routes in the wild that exhibit this
particular pathology
           I think that Geoff has misinterpreted the BGP appendix on proxy
aggregation, but it doesn't matter because we've spent way too much time on
this already

-- No one in the room objects to saying that "UNKNOWN" is always the result
if there is an AS-SET in the path

-- RPKI-Algs is ready for WGLC

-- RPKI-Manifests is ready for WGLC


Publication Protocol by Sam W

-- This was adopted as a working group item
   There appear to be no significant updates to the technical content of the
document

-- Please read the document and provide feedback (document has not received
sufficient review yet)


Local Trust Anchor by Steve K

-- Has not yet been published as a working group document, but there is
working group concensus to accept the document

-- No significant changes since Stockholm

-- Sandy Chair: How does this work with Net-10 space, and leaks of Net-10
announcements

-- Steve K: The RPKI will help people ignore leaks of Net-10 announcements
            ... both with this draft or without this draft, things just work


Algorithm Transition by Steve K

-- Rob A: Our test bed experience indicates that negotiating the parent
child relation is challenging
          ... I'm not sure what the best trade-offs is, I'll have to think
about it and get back to the list

-- Randy: agrees with Geoff [shockingly] that this just works when you have
a top-down algorithm transition
          ... The problem that Rob was worried about was the
establishment/exchange of business PKI certificates for the up/down protocol

-- Rob A: One thing where thing where we might want to extend the
provisioning protocol is ... <scribe missed Rob's point>

-- Andre: My can't you have a mixed validation path A-B-A-B-A
    Answer:  Until we get near the end of the transition we can't assume
that all relying parties understand B
          ... therefore until you reach this point (Phase 4 in the document)
there must be an A-only chain for all resources

-- Randy: Note that the time for this is measured in years

-- Steve K: This is complicated stuff, we the authors will do another
simplifying spin, but after that we will need reviewers

-- Sandy Chair: I think that this document needs to have text about
validating routes

-- Steve K: I think that once we define validation of certificates, then
validation of BGP routes just works

-- The chairs will ask on the list for working group adoption

-- Geoff: The current draft version is deeply flawed and should be revised
before we accept it

-- Randy: Drafts don't need to be perfect before the working group decides
to work