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

From: Danny McPherson <[email-masked]>
Date: Tue, 5 Aug 2008 04:31:14 -0600

On Jul 29, 2008, at 7:10 AM, Terry Manderson wrote:
>
> Does that help or add to your understand of where I'm coming from  
> with this work?

Yes, it does, thanks for taking them time to explain
your position.

I don't have large concerns about this but I am interested
in hearing from other folks that have or are planning to
build tools here.

Thanks Terry!

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

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 12 Aug 2008 09:58:50 -0400 (Eastern Daylight Time)

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

---

From: Terry Manderson <[email-masked]>
Date: Wed, 13 Aug 2008 17:54:38 +1000

On 12/08/2008, at 11:58 PM, Sandra Murphy wrote:
>>
>>
>> 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.
>
> 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

Thanks for the clarification Sandy, I'll step back from the "non-ietf"  
point of view. (although in some ways it still drags on me, but it  
isn't a defining factor) I think your two points are far more salient  
in the broader view of the SIDR system architecture.

Cheers
Terry

---

From: David Ward <[email-masked]>
Date: Wed, 13 Aug 2008 10:50:38 -0500

Note that there are folks working to make the use of rsync a non- 
issue by clearing up the IPR and get reference implementations and  
docs together. Clearly rsync has been in use for millenia (in  
internet time scales).

-DWard

On Aug 13, 2008, at 2:54 AM, Terry Manderson wrote:

>>> 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  
> Thanks for the clarification Sandy, I'll step back from the "non- 
> ietf" point of view. (although in some ways it still drags on me,  
> but it isn't a defining factor) I think your two points are far  
> more salient in the broader view of the SIDR system architecture.
>
> Cheers
> Terry
>

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 18 Aug 2008 13:10:29 -0700

How active is the work on documenting RSYNC in a referencable, stable  
way?  If I don't see an I-D, I tend to have low expectations of  
clearing up the reference in cases like these.  I have sent mails to  
Andrew Tridgell in the past and gotten no response.  I also  
corresponded with Dan Shearer ([email-masked]) who may be able to get  
us answers if we have specific questions about the IPR.

Lisa

---

From: Terry Manderson <[email-masked]>
Date: Mon, 25 Aug 2008 13:36:25 +1000

.. and in the bad form of following-up to my own post.

On 29/07/2008, at 11:10 PM, Terry Manderson wrote:
>
> 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?

I had the opportunity on the weekend to catch up with an old colleague  
who now spends her time dealing with banking sector network security.  
After the usual banter about the selection of red wine we 'talked shop'.

She was quite immovable in her view that regardless of the validation  
constructs of RPKI, the end to end fetching and publishing MUST be  
over a path that covers confidentiality, integrity, and availability.

So in her eyes the important things are:
	- That when you establish a discussion with endpoint you are (to the  
best of current technology) certain it really is the endpoint.
	- That you are talking (unmolested) to the endpoint you think you are  
for the entirety of the session.
	- That what is retrieved by the client is audit-able at both the  
server and the client.
	- That retrievals are predictable, and perfectly repeatable.
	- That the client _never_ permits a downgrade, or unsecured retrieval  
of information
	- That Trust anchor management for both the client ssl and the PRKI  
is considered in such a way that it minimises the fact there is no  
such thing as trusted computing (her words).

I asked for situations that she could identify (ie problems) and after  
the expected Kaminsky DNS issue discussion, I was showed the secret  
decoder ring and she suggested that I wasn't being paranoid enough  
given we are dealing with and constructing operational systems which  
affect the control plane.

I'm not sure how this might reflect in the ARRRM draft yet, but I  
thought it worthwhile to share.

Cheers,
Terry

---

From: Roque Gagliano <[email-masked]>
Date: Mon, 25 Aug 2008 09:37:16 -0500

Hi Terry,

I wanted to ask you about this line:
- ------------------
4.1.1
e. Confirm that all of the objects listed in the downloaded manifest  
have been retrieved.
- ------------------

What if I have a partial download of the URIs from the manifest?  What  
if the successfully downloaded object files match the stored hashes?

I personally believe that the manifest itself has to be only entirely  
download but partial downloads of object should be permitted.

Regards,

Roque

---

From: Sandra Murphy <[email-masked]>
Date: Mon, 25 Aug 2008 15:09:54 -0400 (Eastern Daylight Time)

On Mon, 25 Aug 2008, Roque Gagliano wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Terry,
>

There's a "not" missing in here somewhere, I think.   (Successful
download and match of hashes seem like entirely good things.)

> download but partial downloads of object should be permitted.

If you mean a partial download of some individual object, the signature of 
that object could not verify if the object was only partially downloaded.

If you mean a partial download of the list of objects mentioned in the 
manifest, the manifest is designed particularly to detect when objects 
that should be in the repository are missing, so a partial download should 
not be permitted.

Unless I've misunderstood you.

--Sandy

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
>
> iEYEARECAAYFAkiyw5wACgkQnk+WSgHpbO7jNgCg1dHvT3z3QcYbecGKxIEw/ZpE
> Nu0An2hhqQd35VT9GOXYYq3K8H1H3IZ3
> =SzHP
> -----END PGP SIGNATURE-----

---

From: Roque Gagliano <[email-masked]>
Date: Mon, 25 Aug 2008 19:06:40 -0500

Sandy,
> download and match of hashes seem like entirely good things.)

let me clarified what was trying to say. The question is about the  
word "all", what if you only succeed on download some of the objects  
in the manifest.

Regards,
Roque

> If you mean a partial download of some individual object, the  
> signature of that object could not verify if the object was only  
> partially downloaded.
>
> If you mean a partial download of the list of objects mentioned in  
> the manifest, the manifest is designed particularly to detect when  
> objects that should be in the repository are missing, so a partial  
> download should not be permitted.
>

---

From: Terry Manderson <[email-masked]>
Date: Tue, 26 Aug 2008 10:25:05 +1000

Hi Roque,

On 26/08/2008, at 12:37 AM, Roque Gagliano wrote:
> What if I have a partial download of the URIs from the manifest?   
> What if the successfully downloaded object files match the stored  
> hashes?
>

The intention is to make sure a local cache is a 1:1 match of the  
publish point such that RPKI validation will be (for the most part)  
effortless. If you validly retrieve on object (and the hash values  
match) you may be in danger of not having enough of the pki chain to  
successfully PRKI validate the object.

> I personally believe that the manifest itself has to be only  
> entirely download but partial downloads of object should be permitted.
>

What I think you are saying that partial downloads of a publish point  
could be permitted, providing that all other parent objects associated  
with it have also been downloaded such that you can PPKI validate the  
'single' object? Yes? Here you don't know what the parent objects are  
until you look in the object, and walk back up the tree using AIA  
values.

Once you have all the objects you must then validate those in a top  
down sweep using the Trust Anchor. If the validation fails you need to  
discard all of those objects and try again (as expected).

I won't walk away from a bottom up fetch process. If it is thought to  
be of value I can certainly look into including it the ARRRM draft and  
look at the issues of cost Vs utility. ie for long chains I have a  
feeling it would be very costly, but for short ones I think simple  
enough - which probably highlights a scaling issue.

Terry

---

From: Robert Loomans <[email-masked]>
Date: Tue, 26 Aug 2008 20:36:36 +1000

Roque Gagliano wrote:
> let me clarified what was trying to say. The question is about the word
> "all", what if you only succeed on download some of the objects in the
> manifest.

Details of how to handle various error cases are described in
draft-ietf-sidr-rpki-manifests. In this case, in section 6.5:

>    If there exist files listed on the manifest that do not appear in the
>    repository, then these objects are likely to have been improperly
>    (via malice or accident) deleted from the manifest.  A primary
>    purpose of manifests is to detect such deletions.  Therefore, in such
>    a case this situation should result in a warning to the effect that:
>    "The following files that should have been present in the repository
>    at <pub point name>, are missing <file list>.  This indicates an
>    attack against this publication point, or the repository, or an error
>    by the publisher."

Rob

-- 
Robert Loomans                                  Email: [email-masked]
Senior Software Engineer, APNIC                 Phone:   +61 7 3858 3100
http://www.apnic.net                              Fax:   +61 7 3858 3199
_______________________________________________
sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 26 Aug 2008 09:28:27 -0400 (Eastern Daylight Time)

>>    (via malice or accident) deleted from the manifest.  A primary

                                                 ^^^^^^^^
                                                repository?

>>    attack against this publication point, or the repository, or an error

Yes, this is what I was trying to say - that the stated purpose of the 
manifest is to detect missing items, so permitting parital downloads of 
the list of objects would be counter to the purpose of the manifest. 
IMHO, of course.

--Sandy

---

From: Robert Loomans <[email-masked]>
Date: Thu, 28 Aug 2008 11:07:59 +1000

>>>    (via malice or accident) deleted from the manifest.  A primary

I think so :)

> the list of objects would be counter to the purpose of the manifest.

Yes, a partial manifest is useless. You can't validate it.

Rob