Subject: [sidr] draft-sidr-fetch-00.txt

From: Danny McPherson <[email-masked]>
Date: Mon, 28 Jul 2008 12:07:31 -0600

Terry et al.,
I just had a chance to read this..  As I stated at the microphone,
I'm quite interested in understanding the motivations for an
alternative mechanism at this point, as I'm concerned that given
all the other work that needs to be done, this will increase attack
surfaces without adding needed capabilities.

Do you mind iterating the motivations for this work, they're not
in the current version of the draft?  I'm genuinely interested in
your input here, as given that you're going to be the one that has
to implement, there's likely some obvious gaps (beyond "to
scale") you're aiming to fill, gaps which aren't entirely obvious
for me yet.

Thanks!

-danny

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

---

From: Andy Newton <[email-masked]>
Date: Mon, 28 Jul 2008 14:29:03 -0400

> scale") you're aiming to fill, gaps which aren't entirely obvious

Not being Terry, but I'd like to expand on Terry's scalability point.  The
number of tools available to for scaling HTTP are far greater than that for
rsync.  The same is true about monitoring tools, which is important for
large installations.

Additionally, if there were ever a need to put any "intelligence" on the
server side, the number of ways to do so with HTTP are far, far greater than
the number of ways to do that with rsync.  Of course, at the moment such a
need does not exist.

-andy

---

From: Terry Manderson <[email-masked]>
Date: Tue, 29 Jul 2008 23:10:35 +1000

Hi Danny,

There are several motivations for an additional / alternative  
mechanism for retrieval as I see it. We know that RSYNC is a MUST in  
the SIA of the issued RPKI certificate, and it then allows further  
multiple additional fetch URIs where order of those URIs is the  
preferred order of use according to the issuer.

Putting on the hat of a relying party, if for some reason the highest  
order URI is not immediately available it would be preferable to have  
access to a heterogeneous method and location to retrieve the  
information.

 From the perspective of the issuer, I should (I think) do whatever it  
takes to ensure that this information is available whenever a relying  
party requires it. Having a second valid and known mechanism to do  
this helps enormously for the obvious reasons.

As Andy mentioned there are a plethora of tools and techniques for  
building robust http(s) services, remembering that I'm not the only  
one who needs to do this. Every single entity that issues their own  
RPKI objects needs to place these objects in a repository, some will  
opt to use the repositories of their RIRs, other will not. Those  
others will need to create a robust repository structure and they may  
have their own preference for the server infrastructure in their  
organisation, this allows them to put focus on their preference, being  
either RSYNC or HTTP.

The ubiquity of HTTP provides a strong platform for both server and  
client development. I'm not sure it would expose an attack surface by  
adding http. It may be that specifying just https may eliminate  
additional vectors. Do you have any in mind?

A social aspect that I'm cognisant of is that there appeared to be  
reluctance by some parties to accept the rescerts draft because it had  
a non-ietf reference implementation which potentially could raise  
issues about interoperability between releases. This draft should  
nullify those as it does provide an IETF standard for retrieval - so  
with luck allowing the pivotal draft in question to gain adoption  
faster.

I'm not forgetting Rob A's mic comments about looking deeper into the  
TCP behaviours and the overall efficiency of the entire retrieval of  
all the objects at a publication point. Similarly Andy N's comments  
about making HTTP 1.1 a MUST and also to look at connection creation  
in light of HTTPS.

An attraction for me with the algorithm as stated is making the  
manifest the synchronisation point and unambiguously giving the  
retrieval decisions to the client, that is the client then has the  
explicit choice.

Does that help or add to your understand of where I'm coming from with  
this work?

Cheers
Terry