Subject: [sidr] request for wg adoption

From: Sandra Murphy <[email-masked]>
Date: Fri, 10 Oct 2008 10:58:56 -0400 (Eastern Daylight Time)

Terry Manderson submitted a new draft "RPKI Repository Retrieval 
Mechanism" in repsonse to comments received.  The draft is available at
http://www.ietf.org/internet-drafts/draft-manderson-sidr-fetch-00.txt.

He asks for adoption of the draft as a sidr work item.

I'm opening the question of whether this should be adopted as a wg work 
item.  Please respond, indicating whether you are for or against 
adoption and whether you would participate in that work.

The question is open for two weeks.  Respond by Friday, Oct 22.

--Sandy

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

---

From: Robert Loomans <[email-masked]>
Date: Mon, 13 Oct 2008 10:59:31 +1000

> The question is open for two weeks.  Respond by Friday, Oct 22.

I'm for adoption: I would like to see the idea explored.

I will participate in any discussion.

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: Roque Gagliano <[email-masked]>
Date: Tue, 14 Oct 2008 16:57:58 -0200

I do support this draft become WG item as a different fetching  
mechanism.

I believe a reference to section 4.3 of the architecture draft (Access  
protocols) should be added in order to be sure that the proposed  
protocol complies with all the requirements stated there.

Roque

On Oct 10, 2008, at 12:58 PM, Sandra Murphy wrote:

> I'm opening the question of whether this should be adopted as a wg  
> work item.  Please respond, indicating whether you are for or  
> against adoption and whether you would participate in that work.
>

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 15 Oct 2008 15:08:07 -0400

I believe this document should become a WG work item.

Dave

Sandra Murphy wrote:
> work item.  Please respond, indicating whether you are for or against

---

From: Andy Newton <[email-masked]>
Date: Fri, 17 Oct 2008 10:30:04 -0400

I'm not opposed to this idea, though I still don't know how this will shake
out against rsync.  Frankly, it would be simpler if there were just one
mechanism, and perhaps that question ought to be asked of the working group.
I do not think we are doing the broader community any favors by specifying
two methods.  I share the discomfort some people have with rsync and feel
that an HTTP approach would be easier to troubleshoot and manipulate
operationally.

That being said, this draft does not appear to be revised with feedback from
the last IETF.  Without clarification and modification, the algorithm
specified in this draft would have serious performance issues with HTTPS.
So, when are we expecting a draft revision that addresses this issue and the
others brought forward in Dublin?

-andy

---

From: Randy Bush <[email-masked]>
Date: Fri, 17 Oct 2008 09:53:52 -0700

> others brought forward in Dublin?

when will there be running code we can actually compare?

randy

---

From: Terry Manderson <[email-masked]>
Date: Sat, 18 Oct 2008 16:22:04 +1000

Hi Andy,

> I do not think we are doing the broader community any favors by  

I'm torn on this. I see the simplicity side and really appreciates  
that, but I also see the benefits of heterogeneity.

> specified in this draft would have serious performance issues with  

Yes, I didn't "go all the way" on the changes requested - I addressed  
most, but refrained from some as I felt under-qualified at the time to  
target some specifics.

But I do accept that I need to go further, and willing to to do so  
under a WG item.

> others brought forward in Dublin?

When do you want it? prior to adoption as a WG item? or as a WG item  
revision?

Cheers
Terry

---

From: Terry Manderson <[email-masked]>
Date: Sat, 18 Oct 2008 16:28:48 +1000

> when will there be running code we can actually compare?

Good question. I've been tinkering (note: I am an ops person - not a  
coder) with some code to do this and over the next few weeks in my  
spare time I shall tidy it up before it falls under the eyes of the  
programming 'guns' in the WG.

Although, that timeline may not work in for the deadline for the WG  
Adoption request.

Is that then a stopping block for you?

Terry

---

From: Randy Bush <[email-masked]>
Date: Sat, 18 Oct 2008 08:59:55 -0700

as there are deep suspicions that the http approach will have serious
implementation and performance issues, indeed lack of running code is a
big blocker in my view.

andy is a serious hacker and seems interested.  perhaps he can help.

randy

---

From: Rob Austein <[email-masked]>
Date: Sat, 18 Oct 2008 15:22:44 -0400

I'd also question the purpose of TLS (ie, HTTPS vs HTTP) in this
context.  All the data are signed, there's no confidentiality or
access control reuirement as far as I know, and the manifest design
was specifically intended to remove the need for channel security.
The draft doesn't contain any real analysis of what threats the
protocol needs to defend against or why TLS is the right solution.
_______________________________________________
sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr

---

From: Robert Kisteleki <[email-masked]>
Date: Sun, 19 Oct 2008 03:54:28 -0700

> protocol needs to defend against or why TLS is the right solution.

I also have serious concerns about the use of HTTPS, especially about how a 
relying party should verify the server's certificate. I believe that the 
current RPKI certificate policy and/or profile prohibits certificate use for 
client/server authentication purposes. That'd mean that a different (yet 
another?) PKI should be used for this. What PKI would that be?

Robert

---

From: Terry Manderson <[email-masked]>
Date: Mon, 20 Oct 2008 15:51:47 +1000

Hi Rob,

> protocol needs to defend against or why TLS is the right solution.

Here is a hypothetical scenario that I think is technically viable.

Consider two initial parties, Party A and B. Party A is the well  
mannered ISP who regularly fetches and validates the RPKI repository.  
Party B who is multi-homed is intent on doing an attack of some form  
on party A's customers. The entity that allocated the IP address space  
to party B for some reason retracts the allocation (expired  
membership, Law enforcement action etc) and issues a BOA.

Party B somehow sees this happen and puts into play a mechanism close  
to the repository which identifies the collection of the updated  
manifest, 3779 certificate, and associated BOA - They then in transit  
modify one bit of data such that any of the following occurs for  
relying parties:
	manifest fails to validate
	the object's hash doesn't match those of the manifest and the objects  
fail to validate

This means that depending on the policy of the relying parties, the  
bgp announcement from party B will remain in place for as long as the  
MiTM attack is happening on the repository elements related to party  
B, and party B's attack on customers of party A (or others) can remain  
in place.

Using TLS would make this MiTM attack substantially more difficult to  
do with the intent of successfully downloading valid data from the  
repository for RPKI validation.

.. Am I mistaken, is this not a valid attack on the RPKI infrastructure?

Terry

---

From: Terry Manderson <[email-masked]>
Date: Mon, 20 Oct 2008 15:58:23 +1000

On 19/10/2008, at 8:54 PM, Robert Kisteleki wrote:
>>
> I also have serious concerns about the use of HTTPS, especially  
> about how a relying party should verify the server's certificate. I  
> believe that the current RPKI certificate policy and/or profile  
> prohibits certificate use for client/server authentication purposes.  
> That'd mean that a different (yet another?) PKI should be used for  
> this. What PKI would that be?
>

There is already a well accepted PKI for handling web based security -  
and as much as that may irritate some as equally open to abuse - it is  
far better than not having channel security.

Although, I'm not closed to the idea of a TA being distributed for the  
purposes of RPKI Repository server security - just not sure if  
creating one is substantially better than using the existing known  
framework of third party certificate authorities already listed in  
most browsers/distributions.

Please advise.

Cheers
Terry

---

From: Andy Newton <[email-masked]>
Date: Mon, 20 Oct 2008 06:17:31 -0400

> that, but I also see the benefits of heterogeneity.

Well, unless one method clearly has a trade-off the other method does not, I
see no reason for having two.  Do you see any?

> When do you want it? prior to adoption as a WG item? or as a WG item

I'd prefer a revision prior to adoption.  But failing that, an enumerated
list of changes agreed upon by the wg is good enough.

-andy

---

From: Andy Newton <[email-masked]>
Date: Mon, 20 Oct 2008 06:22:42 -0400

> andy is a serious hacker and seems interested.  perhaps he can help.

Hmmm... This couldn't be too hard to test, now could it.  Using curl or
Apache libraries should be easy.  If somebody could throw out what they
consider to be a good size for the number of files in the repository and
file size ranges, I'll cook something up.

-andy

---

From: Randy Bush <[email-masked]>
Date: Mon, 20 Oct 2008 08:35:39 -0500

Andy Newton wrote:
>> I also see the benefits of heterogeneity.
> Well, unless one method clearly has a trade-off the other method does
> not, I see no reason for having two.  Do you see any?

i am still completely stunned and confused by this.  i have been unable
to understand "hetrogeneity" as other than two mandatory to implement
protocols which have to offer then same end functionality.  this not
only has no benefits but is a major pain with no gain.

i must be misunderstanding something.

randy

---

From: Rob Austein <[email-masked]>
Date: Mon, 20 Oct 2008 18:09:52 -0400

> .. Am I mistaken, is this not a valid attack on the RPKI infrastructure?

You appear to be describing a selective DoS attack by an on-path
attacker.  Unless I'm missing something, adding TLS to the mix here
changes details but doesn't change the overall situation much, as:

a) The attack was already detectable without TLS (those validation
   failures you mentioned), and

b) An on-path attacker can DoS the relying party even when TLS is in
   use, albeit somewhat more crudely.

So I don't see that TLS buys you much here, and you haven't said
anything about the risks and costs of adding it: new trust
relationships (adding channel trust relationships to what had
previously been an end-to-end object security model) and new potential
attackers (who did you say issues the TLS certificates?).
_______________________________________________
sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr

---

From: Terry Manderson <[email-masked]>
Date: Tue, 21 Oct 2008 09:32:45 +1000

>   failures you mentioned), and

I think the difference is that the validation failures are much harder  
to nail down to a cause.
ie was the rpki repository itself compromised? was the file modified  
in transit? was file put to disk erroneously? and many others .. I'm  
not sure that is a clean outcome.

>   use, albeit somewhat more crudely.

That sort of attack that really is disruptive to the entire channel  
and therefore to the fetch entirely. Not just the validation. But yes,  
still a risk.

> So I don't see that TLS buys you much here, and you haven't said

What TLS buys is the acceptance of the 'uber' security-oids who have  
secret decoder rings that look on this effort to secure the routing  
path, but don't secure the fetch mechanism from common well known  
attacks that can be specific in nature, and thus consider the attempt  
less than ideal.

> attackers (who did you say issues the TLS certificates?).

No, I didn't, the issue there is who is the trusted party? I'm happy  
to explore the options, although would it be appropriate for resource  
repository servers to be issued certificates following the allocation  
path?

I don't see that using an un-secured channel to collect this  
information (validate-able or not) as going far enough to satisfy what  
the RPKI work is trying to achieve as a full end-to-end framework.

While I'm not in love with rsync for this, adding TLS to rsync  
directly would go a long way. Having said that the last rsync patch I  
saw for this ('07) failed to work properly - I'm not aware of further  
work.

Terry

---

From: Terry Manderson <[email-masked]>
Date: Wed, 22 Oct 2008 09:38:07 +1000

> file size ranges, I'll cook something up.

APNIC _had_ a test repository in place. I don't know if it is still  
there.
I'm not aware of any other organisation with a populated repository of  
test objects.

T.

---

From: Rob Austein <[email-masked]>
Date: Tue, 21 Oct 2008 20:16:14 -0400

At Wed, 22 Oct 2008 09:38:07 +1000, Terry Manderson wrote:
> > Hmmm... This couldn't be too hard to test, now could it.  Using
> > curl or Apache libraries should be easy.  If somebody could throw
> > out what they consider to be a good size for the number of files
> > in the repository and file size ranges, I'll cook something up.
> 
> there.  I'm not aware of any other organisation with a populated
> repository of test objects.

APNIC did indeed have a mock-up of a full-scale RPKI repository at one
point, based on available data from IANA and all five RIRs (ie, this
was an attempt to simulate what the full database in an RPKI world
would look like).  This test repository was a great help when I was
first writing validation code and we were all trying to figure out
what the certificate profile should be, but it was somewhat high
maintenance, and APNIC decommissioned it a while ago.

George Michaelson might be able to supply more details, but as I
recall it was on the order of 30,000 - 40,000 objects.  Didn't include
ROAs or manifests, just certificates and CRLs.  I no longer recall
whether it included EE certificates or only CA certificates.

Most of RPKI objects are quite small.  Disk space per se was never a
problem during testing with the full ~40k objects.  Inodes, on the
other hand, were a problem -- your average unix filesystem is
configured assuming a higher data/inode ratio.  The test objects that
I generate as part of my regression testing framework come in at about
2000 octets for a manifest, about 1250 octets for a certificate, and
about 435 octets for an empty CRL.  These are probably on the small
side, CRLs and manifests grow with the number of entries and
certificates grow with the number of discrete resources encoded as
extensions, but we're still talking about tiny files in most cases.

Manifests issued by RIRs are likely to be significantly larger, simply
because the tree is so flat there.  CRLs sizes depend on your
assumptions, but it's probably safe to assume that anybody who issues
a lot of certificates will need to revoke some of them.

Hope this helps.