Subject: [sidr] Working Group Last Call - draft-ietf-sidr-arch-09.txt

From: Geoff Huston <[email-masked]>
Date: Wed, 28 Oct 2009 13:50:12 +1100

The WG chairs have received a Working Group Last Call request from the  
authors of draft-ietf-sidr-arch-09.txt.

The document (and the draft history) is at http://tools.ietf.org/html/draft-ietf-sidr-roa-arch-09

The Last Call will end as of the close of business on Monday 23rd  
November - this is a longer period than a conventional 2 week last  
call period in order to include the forthcoming SIDR WG meeting at  
IETF 76.

The intended status of this document is informational.

As usual, please address all comments to the WG mailing list, and  
please be clear in your comments to this last call if you are  
supporting the document's submission to the IESG or if you are  
opposed, or if you are not expressing a view either way. As there are  
a number of documents that are being last-called at this point in time  
it would be appreciated if responses could clearly identify which  
document is being referred to.

Thanks,

  Geoff

WG Co-CHair hat ON

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 27 Oct 2009 22:52:25 -0400 (Eastern Daylight Time)

On Wed, 28 Oct 2009, Geoff Huston wrote:

> The document (and the draft history) is at 
> http://tools.ietf.org/html/draft-ietf-sidr-roa-arch-09

I'm pretty sure Geoff means:

http://tools.ietf.org/html/draft-ietf-sidr-arch-09

--Sandy

>
> The Last Call will end as of the close of business on Monday 23rd November - 
> this is a longer period than a conventional 2 week last call period in order 
> to include the forthcoming SIDR WG meeting at IETF 76.
>
> As usual, please address all comments to the WG mailing list, and please be 
> clear in your comments to this last call if you are supporting the document's 
> submission to the IESG or if you are opposed, or if you are not expressing a 
> view either way. As there are a number of documents that are being 
> last-called at this point in time it would be appreciated if responses could 
> clearly identify which document is being referred to.
>
>
> Thanks,
>
> Geoff
>
> WG Co-CHair hat ON
>

---

From: Geoff Huston <[email-masked]>
Date: Wed, 28 Oct 2009 14:07:37 +1100

Indeed I did! Thanks for the correction.

   Geoff

On 28/10/2009, at 1:52 PM, Sandra Murphy wrote:

>> The WG chairs have received a Working Group Last Call request from  
>> the authors of draft-ietf-sidr-arch-09.txt.
>>
>> opposed, or if you are not expressing a view either way. As there  
>> are a number of documents that are being last-called at this point  
>> in time it would be appreciated if responses could clearly identify  
>> which document is being referred to.
>>
>>
>> Thanks,
>>
>> Geoff
>>
>> WG Co-CHair hat ON
>>

---

From: George Michaelson <[email-masked]>
Date: Thu, 29 Oct 2009 11:38:37 +1000

> which document is being referred to.

I object to this document as it stands.

I believe the document needs to have the 3 hour time cycle removed,  
and some form of operational guidelines placed in a distinct document  
(whether 3 hours, or some other time, is up to that document)

-George

---

From: Robert Loomans <[email-masked]>
Date: Thu, 29 Oct 2009 12:23:37 +1000

On 29/10/2009, at 11:38, George Michaelson wrote:
> and some form of operational guidelines placed in a distinct  
> document (whether 3 hours, or some other time, is up to that document)
>
>

Seconded. I think that this (and similar guesstimates) should be in an  
operational document.

For reference, the relevant text is in section 6:

>    Note that since relying parties will perform these operations
>    regularly, it is more efficient for the relying party to request  
> from
>    the repository system only those objects that have changed since  
> the
>    relying party last updated its local cache. A relying party may
>    choose any frequency it desires for downloading and validating
>    updates from the repository. However, any relying party that uses
>    RPKI data as an input to operational routing decisions (e.g., ISPs,
>    RIRs, NIRs) SHOULD download and validate updates at least once  
> every
>    three hours.

Rob

-- 
Robert Loomans                                 Email:  [email-masked]
Senior Software Engineer, APNIC                Phone:    +61 7 3858 3100
http://www.apnic.net                             Fax:    +61 7 3858 3199

---

From: Terry Manderson <[email-masked]>
Date: Wed, 28 Oct 2009 22:56:54 -0700

Oppose.

the following, I think, needs attention.

* Section 4.3 Access Protocols

" Current efforts to implement a repository system use RSYNC [14] as
   the single access protocol.  RSYNC, as used in this implementation,
   provides all of the above functionality. A document specifying the
   conventions for use of RSYNC in the PKI will be prepared."

I am not aware of rsync being used to upload/change/delete objects in a
repository as a single access protocol. My understanding is that rsync is
mandated as one of the protocols for download, and at present, the former
modification actions are done using Up/down otherwise known as
draft-ietf-sidr-rescerts-provisioning-05.

* Section 5. Manifests

This section enters the discussion that the repository system is
untrusted(sic), and the manifests are needed due to attack risks. Yet this
isn't further discussed or fleshed out as to why the repo structure is not
trusted and potentially why no further effort is made to have a trustable
repo structure irrespective of the attack vectors of an untrusted repository
system.

Terry

On 28/10/09 12:50 PM, "Geoff Huston" <[email-masked]> wrote:

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

---

From: Randy Bush <[email-masked]>
Date: Fri, 30 Oct 2009 07:09:36 +0900

> (whether 3 hours, or some other time, is up to that document)

i suspect it belongs in the CP, but am not sure.

randy

---

From: Stephen Kent <[email-masked]>
Date: Fri, 30 Oct 2009 11:51:20 -0400

>i suspect it belongs in the CP, but am not sure.

I don't think this is a CP topic, because we're recommending a 
frequency of RP accesses to the repository. The CP could have 
addressed the complimentary topic of the frequency of CRL and cert 
publication, but Andrei convinced us that this should be left to the 
CPS of each CA.

I think the arch doc could contain a paragraph discussing the issue, 
and proposing a default (for the reasons Rob cited) but not mandating 
a specific download frequency.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 30 Oct 2009 16:48:30 -0400

>draft-ietf-sidr-rescerts-provisioning-05.

OK. The text should characterize rsync as being used for read access, 
and not for R/W.

>repo structure irrespective of the attack vectors of an untrusted repository

Any widely distributed repository system will never be trusted to a 
high degree. The same threat model that motivates using DNESEC 
motivates using manifests.

Steve

---

From: Randy Bush <[email-masked]>
Date: Sat, 31 Oct 2009 10:11:45 +0900

> frequency of RP accesses to the repository.

point taken.  this makes sense.

> The CP could have addressed the complimentary topic of the frequency
> of CRL and cert publication, but Andrei convinced us that this should
> be left to the CPS of each CA.

color me quite unconvinced.  this is a global internet.  as someone
betting my routing on roas, i don't care which IR in the chain caused
the delay, as i can not route on blame.

randy