Subject: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting

From: Alexey Melnikov <[email-masked]>
Date: Sat, 4 Aug 2012 11:12:45 -0700

Hi,
On behalf of SIDR WG chairs I would like to initiate 2 weeks acceptance call for draft-ymbk-rpki-grandparenting starting from today, August 4th. Please send your positive or negative feedback to the mailing list or directly to chairs.

Thank you,
Alexey

---

From: Byron Ellacott <[email-masked]>
Date: Mon, 6 Aug 2012 11:25:16 +1000

Hi Alexey and list,

I oppose this acceptance call.  The draft makes no reference to the conflict with the CP draft (6484) [1] with respect to the requirement that certificates issued by a CA conform to the record of current holdings.  If a grandchild is not listed in the record of current holdings, a 6484 compliant CA must not issue certificates in their name; if the grandchild is listed the record of current holdings, then they are no longer a grandchild, and there is no need for a grandparenting process.

  Byron

[1] http://tools.ietf.org/html/rfc6484 sections 1.1, 1.4, and 4.2.2.

On 05/08/2012, at 4:12 AM, Alexey Melnikov wrote:

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

---

From: "George, Wes" <[email-masked]>
Date: Mon, 6 Aug 2012 14:10:15 -0400

As I noted at the mic, I’d much prefer that we find a place to incorporate the information in this draft into an existing draft(s). I don’t understand the need for having this info separated in yet another draft and therefore do not support adoption. I think the information is useful, just would prefer it integrated into an existing document.
If the best place for it would be in a document that is already an RFC, then I support adoption, with the caveat that it should formally update the appropriate document to make it easier to track the info.

The reason I don’t make a specific recommendation as to which document it belongs in is precisely why I think we shouldn’t have this in a separate document if at all possible – I simply can’t keep track of where all of the information lives because it’s spread across so many drafts.

Thanks,

Wes

From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexey Melnikov
Sent: Saturday, August 04, 2012 2:13 PM
To: [email-masked]
Subject: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting

Hi,

Thank you,
Alexey

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: "Montgomery, Douglas" <[email-masked]>
Date: Mon, 6 Aug 2012 14:26:14 -0400

I would be interested in seeing the issue below resolved in definitive
language (maybe someplace stronger than the CP template).

While I think the spirit of this draft was to show techniques that could
be useful during incremental/partial deployment, there are some folks
highly concerned about the potential for unwanted manipulation of the RPKI
by outside influences on the allocation hierarchy.  This draft has become
the cook-book for their arguments of how this could be done.  I.e.,
grandparents issues certs and ROAs that conflict with, or invalidate the
CERT/allocation hierarchy beneath them.

I see enough FUD in this space, that I think the issue should be addressed
in SIDR somehow.

dougm 
-- 
Doug Montgomery  Mgr. Internet & Scalable Systems Research / ITL / NIST

On 8/5/12 9:25 PM, "Byron Ellacott" <[email-masked]> wrote:

>Hi Alexey and list,
>
>I oppose this acceptance call.  The draft makes no reference to the
>conflict with the CP draft (6484) [1] with respect to the requirement
>that certificates issued by a CA conform to the record of current
>holdings.  If a grandchild is not listed in the record of current
>holdings, a 6484 compliant CA must not issue certificates in their name;
>if the grandchild is listed the record of current holdings, then they are
>no longer a grandchild, and there is no need for a grandparenting process.
>
>  Byron
>
>> On behalf of SIDR WG chairs I would like to initiate 2 weeks acceptance
>>call for draft-ymbk-rpki-grandparenting starting from today, August 4th.
>>Please send your positive or negative feedback to the mailing list or
>>directly to chairs.
>> 
>> Thank you,
>> Alexey
>>

---

From: Stephen Kent <[email-masked]>
Date: Mon, 06 Aug 2012 16:05:26 -0400

I am in favor of having a WG document addressing this topic. But, I 
agree that the proposal
MUST be consistent with the RPKI CP (RFC 6484).

Steve

On 8/4/12 2:12 PM, Alexey Melnikov wrote:
> Hi,
> On behalf of SIDR WG chairs I would like to initiate 2 weeks 
> acceptance call for draft-ymbk-rpki-grandparenting starting from 
> today, August 4th. Please send your positive or negative feedback to 
> the mailing list or directly to chairs.
>
> Thank you,
> Alexey
>
>
>

---

From: Terry Manderson <[email-masked]>
Date: Mon, 6 Aug 2012 17:07:23 -0700

After re-reading the -02 version, I do not think that this draft, as
written, should be be adopted. I also retract my 'at mic' statement that
this could work if termed as "interim" in function - as I doubt that there
is any real mutual understanding of 'interim'.

So while the current RFCs do not specifically speak against this, I think
that in making this an option and allowing such 'grandparent' objects that
validate will create ambiguity and complexity. Just because it's possible,
doesn't mean we should.

I'd also note that with the concepts of the up-down protocol and the amazing
level of flexibility in the RFC3779 extensions which allows both range and
prefix options. Slicing and dicing the various cert's 3779 extensions to
take away the chunk from "C" and give to "G" should be a case of machine
work and a small set of up/down processing.

Cheers
Terry

On 5/08/12 4:12 AM, "Alexey Melnikov" <[email-masked]> wrote:

> Hi,
> On behalf of SIDR WG chairs I would like to initiate 2 weeks acceptance call
> for draft-ymbk-rpki-grandparenting starting from today, August 4th. Please
> send your positive or negative feedback to the mailing list or directly to
> chairs.
> 
> Thank you,
> Alexey
>

---

From: George Michaelson <[email-masked]>
Date: Tue, 7 Aug 2012 11:38:29 +1000

I am very concerned the impact this kind of activity has on the integrity of public allocation registries.

How are external parties meant to understand what should exist, if the RPKI signing leaps over intermediate parties that are explicitly listed as having substantive authority over the disposition of resources?

I am struggling to imagine how this activity happens in the context of lawsuit, and the risk of lawsuit by the skipped-over party, and other unrelated parties.

The Grandparent has no contractual relationship with the Grandchild. What is the basis for entering into an agreement to certify these resources, rather than performing a publicly recognized transfer of control? Whats the long-term relationship between the new child, and the Grandparent? on what basis does RPKI certification continue, or cease? Does the parent retain any control? What if the parent does wake up an RPKI engine, and issues conflicting signing state? 

I don't think these are subjects which vest well inside the IETF process, or an RFC. I think they go to address policy questions  currently handled inside the RIR policy framework, by address holders. Since the affected parties include address holders I cannot see how this should be documented or defined outside of that process.

-George

---

From: Tim Bruijnzeels <[email-masked]>
Date: Wed, 8 Aug 2012 07:52:18 -0700

Hi,

Thank you George for phrasing this so accurately. I fully agree that in case of the RIRs there already exists a frame work (address policy) that provides all the process needed for this. I am not sure how many big ISPs / LIRs follow this discussion, but I expect that there commercial contractual concerns exist regarding this and I highly doubt that such companies will follow this document's advice, just because it's a standard..

Tim

---

From: Randy Bush <[email-masked]>
Date: Thu, 09 Aug 2012 10:34:06 -0400

for those who might not have thought about the document very much

   Or a child, C, in the process of going out of business might place
   their grandchildren in precarious circumstances until they can re-
   home.  The grandparent, without disturbing the child's data, could
   simply issue ROAs for the grandchildren, or issue certificates for
   those willing to manage their own rpki data.

randy

---

From: Randy Bush <[email-masked]>
Date: Thu, 09 Aug 2012 10:50:16 -0400

tim,

i see where some confusion might come from

> I am not sure how many big ISPs / LIRs follow this discussion, but I
> expect that there commercial contractual concerns exist regarding this
> and I highly doubt that such companies will follow this document's
> advice, just because it's a standard.

i know rirs like to speak for their members, but this document was
written by one of them :)

as a large isp, we serve a fair number of smaller isps.  i specifically
had in mind the circumstance where one of our customers failed and their
child needed support.  we're engineers, and our primary concern is that 
the packets get delivered.

indeed, the contractual concerns you raise are specifically why one may
not want to disturb the child's cert while seeing that the grandchild's
packets are delivered.

i also have concern that rirs are not seeing the needs of the community,
which includes the grandchildren (even though you do not rent integers
to them directly).

the issue here is operational packet delivery, not rir policy.

randy

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 9 Aug 2012 14:25:24 -0400

an interesting outgrowth of the grandparenting could be the ability to
'avoid' LEA actions at middle tiers of the address allocation
heirarchy... that's something to consider, i'd say.

---

From: Andy Newton <[email-masked]>
Date: Thu, 9 Aug 2012 20:26:06 +0000

> On behalf of SIDR WG chairs I would like to initiate 2 weeks acceptance call for draft-ymbk-rpki-grandparenting starting from today, August 4th. Please send your positive or negative feedback to th…

In its present form, I do not believe this draft is acceptable as a working group document.

In addition to the issue Byron pointed out about the incompatibility of this document with the 6484 CP, there are a number of other issues that should be addressed.

1. Section 1 and Section 3 could be made more readable with the use of tree diagrams describing the relationships and reworking of the paragraphs to setup the relationship of the entities from the described scenarios. At present, the prose can be difficult to read.

2. Section 4 notes social engineering attacks but does not clearly enumerate the damage done by such attacks. This section should more clearly and expressly talk to the danger and damage to the RPKI system should such attacks be successful.

3. If paragraph 4 of section 1 is suggesting that RIRs develop grandchild/grandparent policies and that ISPs insert grandchild/grandparent contract clauses, that should probably be more explicitly stated.

4. This draft does not list or describe situations where and at what levels this type of grandparenting may not be appropriate. Nor does it provide suggestions with regards about resolving conflicts (are grandchildren always allowed to go to their grandparents?).

5. It is not clear why this draft is necessary given the mechanisms available in 3779 and the RPKI ecosystem (this is the point Terry was speaking of). This draft should be more assertive about its own necessity.

Thinking about this, it may be that #3 and #5 are intertwined and that resolving one resolves the other. Also it maybe that #4 and #5 will be resolved when the CP issue is resolved. But from my reading of this document, none of this is clear.

-andy

---

From: Arturo Servin <[email-masked]>
Date: Thu, 9 Aug 2012 18:26:38 -0300

Yes, and that's is why I have double feelings.

	I concur with you about the usability to 'overcome' LEA actions but also I agree with others about some of the negative sides. I think the draft has good intentions but IMHO it needs more thinking. Otherwise it could create more problems than solving them.
	
	I will keep trying to digest it, and f I have something more constructive to say I will.

Regards,
as

---

From: Randy Bush <[email-masked]>
Date: Thu, 09 Aug 2012 23:18:26 -0400

> heirarchy... that's something to consider, i'd say.

yep.  the point is
  o this is not pretty
  o but it is well defined
  o and can be useful as a hack around breakage

so i wrote it up

randy

---

From: Byron Ellacott <[email-masked]>
Date: Fri, 10 Aug 2012 14:36:37 +1000

Hi,

> heirarchy... that's something to consider, i'd say.

I don't believe this is true.

If C has taken some action, LEA triggered or otherwise, that means the RPKI system no longer asserts that G's intent for packet delivery is true, then merely allowing G to issue an RPKI assertion does not prevent C from asserting whatever they like, too.  If a LEA requires C to issue an AS0 ROA 10.42.2.0/23, then creating an ASn ROA for the same prefix, same maxLength will not ensure packets are delivered correctly.

Perhaps the underlying operational problem where A is not quite sure yet of C's status could be better addressed by section 4.9.4 of the CPS - if A has been convinced that G is the current holder of the resources, A could register the change of holding, but include in their CPS that they may provide a grace period for revocation on a case by case basis.

(If A has not been convinced that G is the current holder of the resources, then delivering packets to G for those resources would not be a positive engineering outcome, it would be deliberately mis-directing packets, which the RPKI is intended to prevent!)

  Byron, speaking only for myself

---

From: "Montgomery, Douglas" <[email-masked]>
Date: Fri, 10 Aug 2012 01:02:44 -0400

On 8/10/12 12:36 AM, "Byron Ellacott" <[email-masked]> wrote:

>If C has taken some action, LEA triggered or otherwise, that means the
>RPKI system no longer asserts that G's intent for packet delivery is
>true, then merely allowing G to issue an RPKI assertion does not prevent
>C from asserting whatever they like, too.  If a LEA requires C to issue
>an AS0 ROA 10.42.2.0/23, then creating an ASn ROA for the same prefix,
>same maxLength will not ensure packets are delivered correctly.

The way I understand
http://tools.ietf.org/html/draft-ietf-sidr-pfx-validate-08, if there is a
valid ROA that matches a route, and a valid AS0 ROA that also covers the
route, the route will be considered VALID.

AS0 ROAs don't "trump" other valid ROAs.

>
>Perhaps the underlying operational problem where A is not quite sure yet
>of C's status could be better addressed by section 4.9.4 of the CPS - if
>A has been convinced that G is the current holder of the resources, A
>could register the change of holding, but include in their CPS that they
>may provide a grace period for revocation on a case by case basis.
>
>(If A has not been convinced that G is the current holder of the
>resources, then delivering packets to G for those resources would not be
>a positive engineering outcome, it would be deliberately mis-directing
>packets, which the RPKI is intended to prevent!)
>

dougm

---

From: Byron Ellacott <[email-masked]>
Date: Fri, 10 Aug 2012 15:18:28 +1000

Hi Doug,

> AS0 ROAs don't "trump" other valid ROAs.

Substitute "ASm" for "AS0" in my example.

I believe you're right about AS 0.  I was taking the first sentence of the Security Considerations of draft-ietf-idr-as0 [1] too literally; AS0 ROAs are not entirely equivalent to BOAs, after all :-)

(But this is sort of my point, the RPKI system's verification of right of use breaks down if you start certifying multiple people as having a simultaneous right to use resources :-)

  Byron

[1] http://tools.ietf.org/html/draft-ietf-idr-as0

---

From: "Montgomery, Douglas" <[email-masked]>
Date: Fri, 10 Aug 2012 01:46:06 -0400

Hi Byron,

>Substitute "ASm" for "AS0" in my example.

It doesn't change the logic.    The validation algorithm basically
searches for a match first, only if one is not found is the issue of other
non-matching ROAs considered.  That being, if no match is found and their
exists at least one covering ROA, then the route is INVALID.

You can not change a VALID route to any other state by creating additional
valid ROAs.  You have to delete (revoke, etc) the valid matching ROAs to
achieve that. Creating a (covering) ROA can change an UNKNOW to an
INVALID.   

>
>I believe you're right about AS 0.  I was taking the first sentence of
>the Security Considerations of draft-ietf-idr-as0 [1] too literally; AS0
>ROAs are not entirely equivalent to BOAs, after all :-)
>
>(But this is sort of my point, the RPKI system's verification of right of
>use breaks down if you start certifying multiple people as having a
>simultaneous right to use resources :-)

The issues above can occur even when there is only a single issuer of such
ROAs.

While draft-ietf-idr-as0 and RFC6491 deal with what the semantics that a
single given AS0 ROA conveys, neither draft (maybe rightly so) goes into
the level of detail to note there might exist other valid ROAs that
contradict the semantics of a AS0 ROA.

I would agree on a weaker statement, that we should discuss and come to
some understanding about issues of consistency associated with overlapping
attestations from multiple levels of the resource hierarchy and/or a
single holder.  The current syntax of our objects and validation
algorithms allow considerable flexibility here.  If, and where policies
should curtail some of this flexibility is what we are discussing.

---

From: Byron Ellacott <[email-masked]>
Date: Fri, 10 Aug 2012 17:40:48 +1000

Hi Doug,

> achieve that. Creating a (covering) ROA can change an UNKNOW to an

You can change an INVALID route to a VALID route by creating a ROA for it, though, and if C doesn't think G should be getting their traffic, they could issue the ROA and announce the route and capture at least some traffic.

> should curtail some of this flexibility is what we are discussing.

I think that's a side discussion that might be interesting, but it's orthogonal to a draft proposing certification that is for a purpose other than authorisation of claims of current holdings.  We're not talking about attestations at multiple levels of the resource hierarchy with grandfathering, we're talking about issuing certificates that are intentionally not aligned with current holdings, to enable attestations about resources to be made before the question of who the right holder is has been resolved.

This could possibly be resolved through section 4.9.4 of the CPS document - a CA who wishes to allow themselves the flexibility to recognise a claim to resources from a grandchild without immediately severing their child could note that a grace period may be provided on revocation due to resource holding changes on a case by case basis.  This allows a grandfathering approach where the CA updates the record of current holding, but delays the revocation of the former holder while resolving questions about who should be the current holder - but it does not, in my view, solve the problem of getting packets to the right place, because "the right place" is not known until the identity of the current holder is known.

  Byron

---

From: "Montgomery, Douglas" <[email-masked]>
Date: Fri, 10 Aug 2012 04:01:18 -0400

On 8/10/12 3:40 AM, "Byron Ellacott" <[email-masked]> wrote:

>You can change an INVALID route to a VALID route by creating a ROA for
>it, though, and if C doesn't think G should be getting their traffic,
>they could issue the ROA and announce the route and capture at least some
>traffic.

Agreed.

>I think that's a side discussion that might be interesting, but it's
>orthogonal to a draft proposing certification that is for a purpose other
>than authorisation of claims of current holdings.  We're not talking
>about attestations at multiple levels of the resource hierarchy with
>grandfathering, we're talking about issuing certificates that are
>intentionally not aligned with current holdings, to enable attestations
>about resources to be made before the question of who the right holder is
>has been resolved.
>
>This could possibly be resolved through section 4.9.4 of the CPS document
>- a CA who wishes to allow themselves the flexibility to recognise a
>claim to resources from a grandchild without immediately severing their
>child could note that a grace period may be provided on revocation due to
>resource holding changes on a case by case basis.  This allows a
>grandfathering approach where the CA updates the record of current
>holding, but delays the revocation of the former holder while resolving
>questions about who should be the current holder - but it does not, in my
>view, solve the problem of getting packets to the right place, because
>"the right place" is not known until the identity of the current holder
>is known.
>
>  Byron

There seems to be a lot of assumptions in terms like "the right place".
Are you suggesting that EE Certs/attestations for a given resource can
only be made at the leaves of the allocation tree?   What about
attestations about aggregate routes at higher levels of the hierarchy?

dougm

---

From: Terry Manderson <[email-masked]>
Date: Fri, 10 Aug 2012 21:02:13 +1000

Speaking only, and strictly, as an individual.

I'm sorry Chris, I think this concern about having to 'avoid' LEA actions is FUD worthy. Regardless if it occurs at the peak of the hierarchy or any level underneath.

I'm quite sure from time to time LEA's WILL request some organisation at some level to "freeze" changes for a particular resource as was experienced in the DNSChanger event when ARIN and RIPE were 'ordered' (following proper process or not) by some LEA arrangements to stop any changes from occurring to some whois records. LEAs from my experience do not do these things on a whim. I would have said 5 years ago that the LEAs simply don't understand the internet, but recent experience suggests that they are learning rapidly. So I'm not so sure that, if a LEA takes some action involved in an ongoing criminal case, anything we attempt to put in play protocol wise to 'void' their intentions will actually help anyone's cause. Just as if a LEA where to issue a 'legal intercept' order (for those countries that have such) to your upstreams for your internet traffic, it's really unlikely that it is something you'll be able to avoid. And in the same breath as allowing some entity to 'avoid' a LEA action, it also provides "others" with a non-transparent tool (I'll let your imagination run wild with who "others" could be) to make stuff happen to your "secure" routing.

Further, in a situation when you have a trust anchor, and yes do note the word "trust", any event that occurs at those levels above you which violates your belief that some RPKI CA in question has acted, or been forced to act, in your best interests will simply degrade the trust afforded by both the certificate recipient as well as the relying parties. Again, I think LEAs are growing to understand this, at least the ones I have interacted with are. Ultimately that is why one would promote that the RPKI trust anchors are issued by good-for-the-internet-and-benevolent-fully-tranparent organisations. Your mileage may vary, but if you don't hold the trust in a TA you were expecting as a relying party, then this is why the local TA idea exists, or the entire premise about being able to trust the entities responsible for resource allocation in the resource allocation hierarchy is flawed to begin with.

So for me, I would much prefer a scenario where any action that affects my ROAs in any way is completely transparent to me and to all relying parties which have the belief I am practicing secure origination, such that if some CA in the hierarchy above me issues a ROA that includes, covers, or overlaps my resource holding then I would really love to see my cert revoked, and listed in a CRL, as a standard course of action first and foremost.

Cheers
Terry

---

From: Terry Manderson <[email-masked]>
Date: Fri, 10 Aug 2012 21:11:34 +1000

>  o and can be useful as a hack around breakage

And for that I am grateful. Truly.

But I think what might be of value (huge earth shattering value) is to take this, and also an analysis of the RPKI for where actors can create valid objects which will result in routing outcomes that are not by the strict design of the resource holder.

Such a document I think, in light of this observed functionality, is near mandatory to identify and perhaps ultimately address the imperfections. Not saying that RPKI and BGPSEC needs to be perfect first go, or even that we share a common definition of "imperfection" but I see this as a crack in the looking glass.

T.

---

From: "Carlos M. martinez" <[email-masked]>
Date: Fri, 10 Aug 2012 10:28:31 -0300

<speaking only for myself>

I support the concept of grandpareting. However, as others here, believe
the document needs more work.

I share Andy's concerns, and personally believe that if grandparenting
is going to be an 'approved' practice (a RFC or even a WG draft tends to
give people such feelings) then this document or other document needs to
clearly state requirements for grandparents so relying parties can keep
trusting the system.

I'd love to see a flag somewhere that marks that a given cert/roa
represents a grandchild and not a direct child.

regards

Carlos

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 10 Aug 2012 10:00:49 -0400

> (But this is sort of my point, the RPKI system's verification of right of use breaks down if you start certifying multiple people as having a simultaneous right to use resources :-)

but that model has to exist as you have many situations today with a
single prefix and multiple ASN for origin... there's a commentor on
this thread who proposed (and got through the IESG) such a draft/rfc,
in the GROW wg I believe.

It's not that the system breaks down, so much as you have multiple
possible VALID origins, that's not bad, it's just how the network
works.  Now, if you have NO ROA (unknown) it's another story, I think
the point of the grandparenting draft is to 'save' a customer's
customer in the case of failure at the middle layer.

-chris

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 10 Aug 2012 10:11:37 -0400

> I'm sorry Chris, I think this concern about having to 'avoid' LEA actions is FUD worthy. Regardless if it occurs at the peak of the hierarchy or any level underneath.

<lots of words elided>

hrm, so... LEA folk figuring things out aside, which I think is a
valid point (they are getting smarter, and they will just move their
request to the right hinge)

1) the grandparenting idea permits a party above you in the chain to
make an attestation that others would believe (presuming your current
attestation times out/expires).

2) there is already support for multiple valid ROA's for the same
resource (1.2.3.0/24 origined by AS1 and AS2 and AS3)

3) the actions available are:
  a) revoke cert for resource (invalidates roas and other bits along the way)
  b) issue a competing roa

4) both of the above are 'fixable' with grandparenting

I wasn't actually trying to frighten anyone, I was just pointing out
that if the original intent was to permit someone above me to 'fix' me
in the case of a problem in the middle layer(s), that intent could be
used for 'good' or for 'bad'. I don't see that that is an incorrect
point here. I do agree with Terry that it's certainly seems dangerous.
I'm also not sure that even without enumerating the facts in a draft
people wouldn't eventually figure this out on their own...

-chris

---

From: "Murphy, Sandra" <[email-masked]>
Date: Fri, 10 Aug 2012 14:49:30 +0000

speaking as co-chair

A reminder to the group that the question is whether to adopt this draft as a working group work item.  The content of the draft is not the discussion point here, the acceptance for the group to work on it.

Whether you like the content or not, you should say whether you think the wg should adopt this draft.

--Sandy, speaking as co-chair

---

From: Arturo Servin <[email-masked]>
Date: Fri, 10 Aug 2012 18:31:28 -0300

It is difficult to judge without considering the content. 
	
	But I think that grandparenting is not the right approach to solve the problem with "strangled" grandchildren, then I'm sorry to say that I oppose to adopt.

Regards,
as

---

From: "Murphy, Sandra" <[email-masked]>
Date: Fri, 10 Aug 2012 21:38:10 +0000

speaking as regular ol' member:

wrt:
------
------

The CA certs assert the right to use resources.  The ROAs assert authorization to originate routes.  That's different.

There can be multiple ROAs for the same address space, so people can be multi-homed.  (This could maybe also be useful in AS migration cases.)

I believe Doug Montgomery is right.  By the algorithm for validating BGP routes, issuing one ROA does not "trump" other existing ROAs, and thereby make previously valid routes look invalid.

--Sandy, speaking as regular ol' member

________________________________________
From: [email-masked] [[email-masked]] on behalf of Byron Ellacott [[email-masked]]
Sent: Friday, August 10, 2012 1:18 AM
To: Montgomery, Douglas
Cc: sidr wg
Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting

Hi Doug,

  Byron

---

From: "Montgomery, Douglas" <[email-masked]>
Date: Fri, 10 Aug 2012 19:51:04 -0400

On 8/10/12 5:38 PM, "Murphy, Sandra" <[email-masked]> wrote:

>The CA certs assert the right to use resources.  The ROAs assert
>authorization to originate routes.  That's different.
>
>There can be multiple ROAs for the same address space, so people can be
>multi-homed.  (This could maybe also be useful in AS migration cases.)
>
>I believe Doug Montgomery is right.  By the algorithm for validating BGP
>routes, issuing one ROA does not "trump" other existing ROAs, and thereby
>make previously valid routes look invalid.

Certainly that is the way the the origin validation algorithm works.  But
as I noted before, there is text in idr-as0 and RFC6491 that *might* lead
one to believe AS0 ROAs have "special powers".  Some additional text,
maybe in prefix-validate, to explicitly note the multiple matching ROA
situation might be useful.

As for grandfathering ... We seem to struggle without a clear, and/or
shared technical definition of "right to use".   Personally, when an ISP
is allocated a block to use for customer assignment,  in my mind it has
the "right to use that block" (in the common language sense).  Even if
sub-blocks are assigned to customers.   The ISP might sign other types of
objects with EE certs from the aggregate block CA.

As Sandy notes, right to use is a different concept than route origination
authorization.   If we are careful to keep those concepts distinct in the
conversation ... It will help.

dougm

---

From: Byron Ellacott <[email-masked]>
Date: Mon, 13 Aug 2012 14:56:34 +1000

Hi Chris,

> in the GROW wg I believe.

Sorry, I wasn't very clear there - I don't mean to suggest that an operator should not be able to issue multiple ROAs, I mean to suggest that a CA should not certify multiple entities as the current, unique holder of resources, as per RFC 6484, and that it is the trust model that breaks down when you violate the CP document, not the operational verifiability of the bits and bytes.

I have objected to adoption because it seems to me that the intent of the draft is to create a practice of certifying two entities at once, indefinitely; I do not object to solving a real operational problem, so I would withdraw my objection if the draft's intent is for a strictly transitional process, with revocation of C to be addressed somehow.

I consider this an objection to adoption because the intent is not clear.  The intent can be clarified without updating the document's content, though a content update would be necessary to express the intent, down the line.

  Byron
Still speaking for myself, of course.

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 13 Aug 2012 09:45:22 -0400

> Sorry, I wasn't very clear there - I don't mean to suggest that an operator should not be able to issue multiple ROAs, I mean to suggest that a CA should not certify multiple entities as the curren…

ah! i agree that a CA shouldn't, ideally, certify more than 1 entity
as 'owning' a resource. I think this gets at part of terry's
concern(s) as well?

> I have objected to adoption because it seems to me that the intent of the draft is to create a practice of certifying two entities at once, indefinitely; I do not object to solving a real operation…

I think the  point of the doc is to fix broken downstreams... I
suppose a step to de-register/de-certify could be put in the middle
between 'oh crap, vzb disappeared as a business' and 'oh,
johnny-vzb-customer can no longer be seen in the routing system, quick
issue him a replacement cert!'.

Objecting to the draft because of a missing step seems draconian...

> I consider this an objection to adoption because the intent is not clear.  The intent can be clarified without updating the document's content, though a content update would be necessary to express…

if the content isn't clear then we need to rev the draft with the
'right' content, right? In principle the problem (oops, ISP12
disappeared as a business) shows up 'often' in the real world, we
ought to have a documented solution to that problem, and this draft
seems to aim us in that direction... sure it has some rough edges to
smooth out, I'm sure the authors would welcome text for their
grindstone.

> Still speaking for myself, of course.

me too! (though if I try speaking for others my lips still move, I'm a
horrible ventriloquist)
-chris

---

From: Carlos Martinez-Cagnazzo <[email-masked]>
Date: Mon, 13 Aug 2012 11:10:12 -0300

I didn't state it in so many words, but, here it is. At this point I
'kinda' support the concept (meaning that, like others here, have an
uneasy feeling about TAs issuing certs/roas for organizations they don't
have contractual relationships with), and that if some changes were
considered (see my earlier comment) I would support the adoption of the
document.

If the question is limited to the document in its current form, then I'm
sorry to say that I oppose.

regards

~Carlos

---

From: Eric Osterweil <[email-masked]>
Date: Thu, 23 Aug 2012 10:27:21 -0400

> --Sandy, speaking as co-chair

I do not think this should be adopted as a wg item.  I think the topic of this draft fits better as supporting text in another existing draft (we have a plethora of those to choose from), but the contributions / opinions in this draft do not (imho) stand firmly enough on their own to be an atomic draft.

Eric

---

From: "Murphy, Sandra" <[email-masked]>
Date: Wed, 29 Aug 2012 16:10:46 +0000

Speaking as wg co-chair:

Certainly a very lively acceptance call!

The chairs do not see that there was consensus that the wg should adopt this draft.

But there was ample evidence that the wg was interested in the issue - by the wg spending lots of time discussing the issue.

So that leaves the chairs with an ambivalent message.  The wg is very interested in the topic but not in adopting a draft that would record any decisions about the topic.

What would the wg like to do now?  Particularly those who disagreed with the content of the draft - if you would dislike the recommendations, are you OK with no recommendations instead?

--Sandy, speaking as wg co-chair

________________________________
From: [email-masked] [[email-masked]] on behalf of Alexey Melnikov [[email-masked]]
Sent: Saturday, August 04, 2012 2:12 PM
To: [email-masked]
Subject: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting

Hi,

Thank you,
Alexey

---

From: Arturo Servin <[email-masked]>
Date: Wed, 29 Aug 2012 12:26:46 -0400

My recommendation would be to follow the registry.

	If the parent disappears then the grandparent should re-allocate the resource to the grandchildren (which then will become a new child).

	IMHO is the only way to guarantee some RPKI <-> allocation consistency.

Regards,
as

Disclaimer: I work for a grandparent but this is my personal view.

---

From: "Carlos M. martinez" <[email-masked]>
Date: Wed, 29 Aug 2012 14:47:01 -0300

<personal opinion>

IMO the idea is worth considering, but only iif some implementable
mechanism can be devised that:

1- guarantees following the registries (this would require grandparents
somehow being able to check children's registries)

2- makes the fact that a given object has been produced on behalf of a
grandchild explicit

At some point I started thinking about some form of 'lightweight
up/down' for lack of a better name, something that submits requests
upwards but doesn't require operating a CA, but I'm not sure if it's
worth the effort and probably parents won't deploy it anyways.

</personal opinion>

~CArlos

On 8/29/12 1:10 PM, Murphy, Sandra wrote:
> But there was ample evidence that the wg was interested in the issue -
> by the wg spending lots of time discussing the issue.
> 
> So that leaves the chairs with an ambivalent message.  The wg is very
> interested in the topic but not in adopting a draft that would record
> any decisions about the topic.
> 
> What would the wg like to do now?  Particularly those who disagreed with
> the content of the draft - if you would dislike the recommendations, are
> you OK with no recommendations instead?
> 
> ------------------------------------------------------------------------
> *From:* [email-masked] [[email-masked]] on behalf of
> Alexey Melnikov [[email-masked]]
> *Sent:* Saturday, August 04, 2012 2:12 PM
> *To:* [email-masked]
> *Subject:* [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting
> 
> Hi,

---

From: Andy Newton <[email-masked]>
Date: Wed, 29 Aug 2012 20:56:04 +0000

Are the chairs not allowing the draft authors to address the issues and try again?

-andy

From: <Murphy>, Sandra <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, August 29, 2012 12:10 PM
To: Alexey Melnikov <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting

Speaking as wg co-chair:

________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] on behalf of Alexey Melnikov [[email-masked]<mailto:[email-masked]>]
Sent: Saturday, August 04, 2012 2:12 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting

Hi,

Thank you,
Alexey

---

From: "Murphy, Sandra" <[email-masked]>
Date: Wed, 29 Aug 2012 21:06:46 +0000

Speaking as wg co-chair

Of course revision and new request for acceptance is possible.

Even arguing some more leading to acceptance of draft as is is a possibility.

Some commentors specifically requested that the discussion be added to some existing draft.

Trying to judge wg desire of a way to proceed.

--Sandy

From: [email-masked] [[email-masked]] on behalf of Andy Newton [[email-masked]]

Sent: Wednesday, August 29, 2012 4:56 PM

To: Murphy, Sandra; Alexey Melnikov; [email-masked]

-andy

From: <Murphy>, Sandra <[email-masked]>

To: Alexey Melnikov <[email-masked]>, "[email-masked]"
 <[email-masked]>

<!--
p
	{margin-top:0;
	margin-bottom:0}
-->
BODY {direction: ltr;font-family: Arial;color: #000000;font-size: 10pt;}P {margin-top:0;margin-bottom:0;}

Speaking as wg co-chair:

From:

[email-masked] [[email-masked]] on behalf of Alexey Melnikov [[email-masked]]

To: 
[email-masked]

Hi,

On behalf of SIDR WG chairs I would like to initiate 2 weeks acceptance call for draft-ymbk-rpki-grandparenting starting from today, August 4th. Please
 send your positive or negative feedback to the mailing list or directly to chairs.

Thank you,
Alexey