Subject: Re: [sidr] is a longer announce invalid or not found?

From: Sandra Murphy <[email-masked]>
Date: Mon, 3 Oct 2011 04:54:26 -0400 (Eastern Daylight Time)

speaking as a regular ol' member

On Sat, 1 Oct 2011, Randy Bush wrote:

>>> cool hack 14.3: the router itself can gen the public/private key pair
>>> a la ssh, the person configuring can extract the public key and send
>>> it to the rpki goddesses to be signed by the appropriate cert and put
>>> in the rpki.  the private key never leaves the router!
>> I believe that Steve Kent says that usually a certificate request is
>> required to present Proof Of Possession (of the private key).  So just
>> discovering the public key somehow would not be sufficient to be able
>> to request a cert with that public key.
>
> dear dr nit pick,
>
> when dealing with goddesses, one always frames things as a request

I am not at all sure what you mean.

Cautiously, I'll try to say what I meant again.

You say "the person configuring" could extract the public key and get a 
cert created for that public key.

The request would have to be accompanied by Proof of Possesssion of the 
private key - e.g., something like a signature might do.

Unless the "person configuring" has access to the private key on the 
router, there would be no way to produce the Proof of Possession.

I read what you were suggesting as the customer router gen-ing the key 
pair and the "person configuring"  sitting at the provider, off-router.

Maybe you meant the provider was doing the configuration of the customer 
router, in which case the provider would have access to the private key 
for the proof of possession for the request.

(Of course, if the provider has that much access to the customer router, 
the line blurs between the key-gen-ing happening on the provider side or 
the customer side.)

--Sandy, speaking as regular ol' member

> randy

---

From: Randy Bush <[email-masked]>
Date: Mon, 03 Oct 2011 18:06:51 +0900

you don't think a router can sign a pks42 or whatever request without
the private key leaving the router?  or is it that, as a plain old wg
member, are you really asking for an email beating this into the ground
with every twitch specified to the finest detail?

randy

---

From: Sandra Murphy <[email-masked]>
Date: Mon, 3 Oct 2011 07:18:06 -0400 (Eastern Daylight Time)

No, just trying to figure out what you were saying.  With my first 
interpretation of you message, what you were suggesting was not possible. 
That's hardly a twitch or fine detail.

I think I've got you straight now.

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Mon, 3 Oct 2011 13:23:53 -0400

For the benefit of the WG members,
I would like to point out that the Use Cases and Interpretation
doc (draft-ietf-sidr-usecases-02) should also be quite useful
in the context of this discussion (complementing Pradosh's/Randy's 
explanations (below) and Section 3 in draft-ietf-sidr-origin-ops-10).

In Sections 3.3 and 3.4 in the Use Cases doc -
http://tools.ietf.org/html/draft-ietf-sidr-usecases-02#section-3.3  
it is pointed out by examples that max-length should be used
in a restrained manner (similar to Randy's example below)
when more specific prefixes are intended to be originated from 
the same AS or a different (say, customer) AS.

Also, if you are interested in enumeration of use cases pertaining to
validation outcomes vis-à-vis existence of certain ROAs and
max-length in the ROAs, then Section 7.1 is worth a read as well.
http://tools.ietf.org/html/draft-ietf-sidr-usecases-02#section-7.1 

Sriram

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Pradosh
> Mohapatra
> Sent: Thursday, September 29, 2011 11:21 PM
> To: Randy Bush
> Cc: sidr wg list
> Subject: Re: [sidr] is a longer announce invalid or not found?
> 
> > there has been a bit of confusion over whether announcement of a longer
> > prefix than is covered by a roa is valid, invalid, or not found.  so let
> > me try to clarify the underlying decision process for valid, invalid,
> > and not found so we are all on the same page.  i believe this is as it
> > is documented in pfx-validate.
> 
> 
> I concur.
> 
> From a partial deployment perspective, it does mean that once a ROA is
> published for an address block (and follows the ops guideline of being precise),
> further sub-allocations NEED to have the ROA published. Otherwise, they
> would be marked invalid and risk being not routed.
> 
> - Pradosh
> 
> >
> > ---
> >
> > if i publish a roa for 10.0.0.0/16-16 for AS 42 (and there are no other
> > roas for 10/...)
> >
> > no announcement of 10.0.0.0/16 or any longer prefix thereof from any AS
> > may be marked NOT FOUND, after all, a covering roa is there.
> >
> > any announcement of any prefixes in that space, from /16 to /32, from an
> > AS other than 42 are INVALID.  this is the purpose of the exercise.
> >
> > and, an announcement of 10.0.666.0/24 from AS 42 is INVALID, as it has a
> > prefix length not specified by the roa.  someone is trying to punch a
> > hole, not allowed.  this could be an origin forger trying to punch a /24
> > in my /16.
> >
> > but if i publish a roa for 10.0.0.0/16-24 for AS 42, then an
> > announcement for 10.0.666.0/24 from AS 42, would be marked VALID.
> >
> > randy

---

From: Stephen Kent <[email-masked]>
Date: Mon, 3 Oct 2011 14:04:27 -0400

At 4:56 PM -0400 9/30/11, Sandra Murphy wrote:
>S...
>
>I await correction in quoting Steve.
>

you are correct.  All good cert request protocols require PoP, as you
noted. But it's not too hard to send the public key and a signed blob.
We currently are working on a new PKIX standard, EST, that is intended to
offer a simpler enrollment protocol that the other 2 PKIX standards. It
might be a good choice for the BGPSEC context. The principle doc author
is Max Pritkin at Cisco.

Steve