Subject: [sidr] corrected minutes uploaded

From: Sandra Murphy <[email-masked]>
Date: Mon, 11 May 2015 18:26:11 -0400

There were places in the minutes that noted incompleteness, but no comments on the list.  I reviewed the audio and filled in the noted places.

Since I had the audio and Meetecho open, I added audio times noted by my player and the timestamps noted in the Meetecho chat room for the beginning of each talk.

Diff of old minutes to new minutes below.

--Sandy

P.S.  Note: chat room during the meeting reported a delay in the audio compared to video.  This seems to be true in the audio archive as well.

0a1,7
> Audio times taken by observation from audio player.  Meetecho timestamps taken from Meetecho chat entries
> 
> audio URL: http://www.ietf.org/audio/ietf92/ietf92-parisian-20150323-0900-am1.mp3
> Meetecho URL: http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=IETF92_SIDR&chapter=chapter_0
> 
> audio archive time: 0:05:55  Meetecho timestamp (slide 7):  00:11:23
> 
2a10,11
> audio archive time: 0:14:50  Meetecho timestamp:  00:14:48
> 
18c27,29
<           In the existing model you would need two signatures, right?
---
>           In the existing trust model you would need two authorizations, right?
>          A: What we are mandating is that you must follow the 3779 attributes
> Andrei : Understand but do you require two signatures for a route object, to follow the trust model?
21c32
<    Are you suggesting we remove some of the constraints of the existing system?
---
>    Are you suggesting we remove some of the constraints of the existing system?  That is, if RPSL sigs validate, but RPSS authorization does not validate, will the system be changed so that the object can be entered into the database?
29,30c40,45
< Sandy: In IRR databases that do not use RPSS authentication, we have reports of people sneaking in objects for prefixes they were about to hijack.
<       Is it possible to have 
---
> Sandy: In IRR databases that do not use RPSS authentication, we have
> reports of people sneaking in objects for prefixes they were about to
> hijack.  If you only have one signature on route objects, that would
> continue to allow that behavior. 
>        A: You could have two attributes, one for each authorization.
> Or one certificate that included both resources.
38a54,56
> 
> audio archive time: 29:32  Meetecho time stamp:  00:30:32
> 
46c64
< Sriram asked re: the detail of deferred validation visibility.  Matt
---
> Sriram asked re: the detail (eg per update) of deferred validation visibility.  Matt
50,51c68,69
< Ruediger: made a case for per-session policy (???).  Wes George: in
< the route policy, you might want to specify something about an AS in
---
> Ruediger: made a case for per-session policy versus per-AS policy.  Wes George: in
> the route policy, you might also want to specify policy about an AS in
55,56c73,78
< incredibly obvious, but you should probably say it anyway.  [missed
< Randy's point]
---
> incredibly obvious, but you should probably say it anyway.  
> 
> Randy: Wes is confusing two things.  Documents in other areas say that
> you can specify for a peer or a set of prefixes, whether the markings
> will be placed on the received path.  That is different from deciding
> to apply policy if the path includes an AS number.
60c82
< would be useful for debugging/packet capture.  [Missed resolution]
---
> would be useful for debugging/packet capture.  Matt suggests: send text.
63,65c85,117
< re: current code and AFI] Matt jumped to issue 7 re: mandating support
< for multiprotocol extensions.  No objection to requiring RFC4760
< support.
---
> re: current code and AFI] 
> 
> John: I wonder if SAFI should also be there.  Matt: This version of
> BGPSEC only covers the AFI of IPv4 and IPv6, which means SAFI is not a
> concern.  Rob: There is a SAFI -- the only one allowed is the null SAFI
> - hash the non-existent byte.
> 
> Doug Montgomery: We briefly discussed to have BGPsec only use MP BGP -
> so no multiple encodings of v4 and v6, and where it is getting the
> hashes, so we could simplify things by saying all NLRI are carried in
> the MP extensions.  AFI is already in there.
> 
> Jeff Haas: One of the reasons why SAFI is a good thing to include is
> that when it is time to support VPNs later we don't have to revise the
> protocol to change the validation strategy of what we sign.    (Matt
> says: future proofing.)
> 
> Doug Montgomery: The fact that we have separated origin and path
> validation means that we could at some point need to support other AFI
> or SAFI, so a good idea to make it possible now, to use later.
> 
> Jeff Hass: Pretty much all code treats the non-MP case (IPv4 unicast)
> as MP anyway.  For common procedural stuff, instead of treating it as
> null 0, treat it as the 1 SAFI, so even in then you are still
> consistent even if it is in a different part of the packet.
> 
> Rob: John commented privately that there is no such thing as the null
> SAFI in BGP.  But there is in the RPKI.  In RFC3779 - the SAFI is an
> optional byte and in the RPKI as deployed that byte is required to be
> absent.  So you will have to deal with the fact that there is no SAFI.
> 
> Matt jumped to issue 7 re: mandating support for multiprotocol
> extensions.  No objection to requiring RFC4760 support.
79a132,133
> audio archive time 1:00:09  Meetecho timestamp:  01:04:02
> 
95a150
> audio archive time: 1:10:30  Meetecho timestamp:  01:14:03
101c156,161
< Kent : We should have clear (not informational) documentation somewhere as to exactly what the replying parties MUST do in order to understand the security properties of the system
---
> Note: slides used in the meeting were an old version:
> https://www.ietf.org/proceedings/92/slides/slides-92-sidr-8.pdf
> 
> Kent : We should have clear (not informational) documentation
> somewhere as to exactly what the replying parties MUST do in order to
> understand the security properties of the system
104c164,170
<        (Not to say that we should, but such relying party documentation shouldn't hold up this rrdp specification)
---
> 
>        (Not to say that we shouldn't, but such relying party documentation shouldn't 
>         hold up this rrdp specification)
> 
> Tim B: would prefer to keep this document clean.  Text should take care not to restrict
>        relying parties more than necessary.  Maybe, if wg agrees, we could write a document
>        and share it with the wg.
111c177,178
<           We don't trust withdrawl messages (if it hasn't been revoked or removed from the manifest then we don't forget about it)
---
>           We don't trust withdrawal messages (if it hasn't been revoked or removed from the 
>           manifest then we don't forget about it)
117c184,185
<        We are happy to do HTTP since pervassive HTTPS is the world we live in, as long as it doesn't break the protocol
---
>        We are happy to do HTTP since pervasive HTTPS is the world we live in, as long as it 
>        doesn't break the protocol
119c187,189
< Jeff H: We don't care about privacy, but we should want integrety of the transport
---
> Jeff H: We don't care about privacy, but we should want integrity of the transport session.  Problem
>         is also withholding object or getting a stale object.  Look at lesson
>         of SMTP where bootstrapping stuff in a non-secure environment and that being meddled with.
124c194
<       If I can't trust that I am speaking to the right server, then I can be DoS'ed (in nice ways)
---
>       If I can't trust that I am speaking to the right server, then I can be DoS'ed (in "nice" ways)
131a202,203
> audio time:  1:44:25  Meetecho timestamp: 01:45:10
> 
146a219,220
> audio archive time: 1:57:28  Meetecho timestamp:  01:57:24
> 
164a239
> audio archive time: 2:15:40    Meetecho timestamp: 02:16:18 
166c241
< **** Extemperaneous Presentation : Rutiger Volk
---
> **** Extemporaneous Presentation : Rutiger Volk
185c260,261
<   ... for splitting a PA aggregrate, first you inject the more specific route, but before that you do the documenation (IRR and RPKI)
---
>   ... for splitting a PA aggregrate, first you inject the more specific route, but before that 
>       you do the documentation (IRR and RPKI)
188c264,265
< Should have an AS zero ROA for the aggregate which will no longer be advertised?
---
> I extended the ROA, I created the route objects, I looked a bit ahead and said I would 
> eventually need a AS zero ROA for the aggregate that will no longer be advertised.
194,195c271
< 
< Terry M: Did you violate any procedure in RFC 6907 Section ???
---
> Terry M: Did you anything you did agree or disagree with RFC 6907 Section 3?
205,206c281,283
< Randy: Two major problems with RPKI deployment
<       ... Most Egregious: Operators who issue a ROA for their 16 (and clobber customers who have 24, but don't have ROAs)
---
> Randy: Two major problems with RPKI deployment and then one more minor thing.
>       ... Most Egregious: Operators who issue a ROA for their 16 (and clobber customers who have 24, 
>           but don't have ROAs)
208d284
<       ... Three: As RIPE and LACNIC scale up, we will eventually have scaling issues with the transport mechanism         
210,212c286,289
< Rob A: 3 of 5 RIRs have had trouble with this
<        Some implementors have chosen to have the EE cert expiration very similar to the Manifest Next Update
<           ... This is dangerous if you are 
---
> Rob A: (interjection) 3 of 5 RIRs have had trouble with this (the manifest expiration problem)
>        Some implementors have chosen to have the EE cert expiration very close to the Manifest Next Update time
>           ... This is dangerous if you are down for the weekend etc (for RIRs, this makes all the region  
>           ...          go poof)  
215c292,296
< Jeff Haas: The SIDR group has a WIKI it would be easy for anyone with an operational comment to toss it into the Wiki
---
> (back to Randy):
>       ... Three: As RIPE and LACNIC scale up, we will eventually have scaling issues with the transport mechanism         
> 
> Jeff Haas: The SIDR group has a WIKI it would be easy for anyone with an operational comment to toss it 
> into the Wiki
217c298
< Kavah: K-root address space has been signed in RPKI
---
> Kavah: K-root anycast address space has been signed in RPKI