On Tue, 29 Jul 2008, Terry Manderson wrote:
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.
Sorry for the late reply, I missed this remark.
The objections I've heard raised about rsync are (1) it has NO
specification beyond the code, which of course changes daily, leading to
interoperability issues, should anyone else attempt to implement and (2)
there's this license issue (formerly GPL v2, now GPL v3) [IANAL, YMMV].
Lack of *IETF* spec, or reference implementation of same, has not been a
problem.
--Sandy
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
On 29/07/2008, at 4:07 AM, Danny McPherson wrote:
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 protected]
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
