Subject: [sidr] IETF79 minutes

From: Sandra Murphy <[email-masked]>
Date: Tue, 7 Dec 2010 08:32:19 -0500 (Eastern Standard Time)

Below are the minutes that I just uploaded to the meeting proceedings 
site.  Many thanks to Matt Lepinski and Karen O'Donaghue for being the 
minute takers.

The proceeding URL for sidr is: 
http://www.ietf.org/proceedings/79/minutes/sidr.txt.

If you have any modifications or additions, please post them to the list. 
Updates to IETF79 minutes are due by Jan 5, 2011.

--Sandy, with wg chair toque on.

---

From: Sandra Murphy <[email-masked]>
Date: Wed, 8 Dec 2010 12:22:42 -0500 (Eastern Standard Time)

OK, so now the minutes are below.

They were on the web site when I said they were, so I was half right.

--Sandy

On Tue, 7 Dec 2010, Sandra Murphy wrote:

> Below are the minutes that I just uploaded to the meeting proceedings site. 
> Many thanks to Matt Lepinski and Karen O'Donaghue for being the minute 
> takers.
>

---------
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

---

From: "Forhad Ahmed (foahmed)" <[email-masked]>
Date: Thu, 9 Dec 2010 22:05:47 -0800

Is there a text of this latest draft?  

Interested in knowing what the PDU formats will be if the 2 fields are
removed...

> -- This draft is ready to move forward to WGLC

-Forhad

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Sandra Murphy
Sent: Wednesday, December 08, 2010 9:23 AM
To: [email-masked]
Subject: Re: [sidr] IETF79 minutes

--Sandy

> Below are the minutes that I just uploaded to the meeting proceedings
site. 

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

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

-- 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

-- 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 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

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

-- Sandy Chair: No

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

-- 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

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

-- 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

-- 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

-- 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

-- 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

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

---

From: Randy Bush <[email-masked]>
Date: Thu, 09 Dec 2010 23:33:14 -0800

>> -- This draft is ready to move forward to WGLC

the pdus are described in draft-ietf-sidr-rpki-rtr-04.txt

randy