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