Subject: Re: [Sidr] Multiple Signatures on a ROA

From: Henk Uijterwaal <[email-masked]>
Date: Thu, 02 Aug 2007 20:37:11 +0200

All,

> The discussion in SIDR addressed a different, more limited problem. The 
> question was what if an ISP receives two, adjacent allocations from the 
> SAME source at different times, and the source refuses to issue one cert 
> for both allocations, because they have different validity periods. That 
> was the motivation cited by Geoff Houston in the meeting.

I'm not sure if this would ever happen in practice.  Our current thinking
is that certs will be valid for the period for which LIRs have paid their
membership dues (plus some grace period after that).  So, if two allocations
are made on different dates, the end date for the cert will always be the
same and there is no reason why one would refuse handing out a cert
for the aggregate.

Henk

-- 
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.amsterdamned.org/~henk
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

# Lawyer: "Now sir, I'm sure you are an intelligent and honest man--"
# Witness: "Thank you. If I weren't under oath, I'd return the compliment."

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

---

From: Rob Austein <[email-masked]>
Date: Sat, 04 Aug 2007 13:40:39 -0400

Having thought about this a bit, I remain skeptical about the need for
or desirability of multiple signatures on ROAs.

First, as others have mentioned, this is a relatively low-probability
hypothetical case, and if it occurs at all it would be the result of
an issuer deliberately chosing to make life complicated for its
subjects.  This does not strike me as a strong case for complicating
the protocol (if anything, it strikes me as the opposite, absent proof
that this complexity really is necessary).

Second, I don't see why this can't be handled via multiple ROAs
instead of multiple signatures on a single ROA.  As I understand it,
relying parties in this system are going to have to deal with the
possibility of multiple ROAs for the same AS number in any case;
adding multiple signatures to ROAs will not change that.  So I don't
see a big gain here, just another code path that will need to be
debugged and a more complicated algorithm for deciding whether a ROA
is valid (what's a relying party supposed to do if if one signature on
a ROA is valid and the other is not?  If five are valid and three are
not?  Is there an upper limit to the number of signatures?  At one
point does this become a denial of service attack on the relying
party? ...).

So, since on the one hand this whole mess can be avoided by an issuer
who wants to avoid it, and on the other hand there's a perfectly good
way to handle it that we're going to have to support anyway, on the
gripping hand I do not support the proposed change to allow multiple
signatures.

---

From: Geoff Huston <[email-masked]>
Date: Sun, 05 Aug 2007 11:27:01 +1000

*wg chair hat off*

Rob Austein wrote:
> adding multiple signatures to ROAs will not change that.

So if seems to me that you are saying that an advertisement for 
192.0.2.0/24 originated from AS65000 could be validated by two ROAs, 
namely 192.0.2.0/25 authorizing AS65000 and 192.0.2.128/25 authorizing 
AS65000

To me, this appears to make the relying party's job harder given that 
the relying party is no longer just looking for either exact match ROAs 
or covering aggregate ROAs but now also has to search for a collection 
of more specific ROAs that could be used to construct an aggregate that 
matches the prefix to be validated.

In your model does either of the signing /25 parties need to demonstate 
knowledge of the other? Do they need to indicate their permission to 
have the aggregated originated rather than the more specific? How can 
they demonstrate that they are in effect the same party even though 
there may be different validation paths for the certs associated with 
each more prefix? How can a validating party uncover the original intent 
of the signers in this case?

> gripping hand I do not support the proposed change to allow multiple

I don't agree with this assessment and to me ruling out the ability of 
multiple signatures on a ROA introduces the potential for undue levels 
of uncertainty in relying party validation of route objects. For that 
reason I continue to support the concept of allowing multiple signatures 
on a ROAs.

---

From: Henk Uijterwaal <[email-masked]>
Date: Mon, 06 Aug 2007 07:38:06 +0200

All,

> that this complexity really is necessary).

I agree with Rob here.  I'd have no problem with extending the protocol
if there was a valid case for doing so.  However, the two cases that
were mentioned on the list so-far, are low probability cases that can
be handled by having 2 ROAs.  Until somebody comes up with a third
case that needs this, let's not make things more complicated than
they already are.

Henk

---

From: Matt Lepinski <[email-masked]>
Date: Mon, 06 Aug 2007 10:21:45 -0400

Geoff,

Geoff Huston wrote:

> the relying party is no longer just looking for either exact match 
> ROAs or covering aggregate ROAs but now also has to search for a 
> collection of more specific ROAs that could be used to construct an 
> aggregate that matches the prefix to be validated.

I completely agree. This option makes life very difficult for a relying 
party.

For instance, an advertisement for 192.0.0.0/18 could be authorized by
- A single ROA for 192.0.0.0/18
- A pair of ROAs, one for 192.0.0.0/19 and one for 192.0.32.0/19
- Three ROAs for 192.0.0.0/19, 19.0.32.0/20 and 19.0.48.0/20, respectively
- A large number of other possibilities including ROAs for the following 
set of prefixes:
  192.0.0.0/20
  192.0.16.0/22
  192.0.20.0/22
  192.0.24.0/22
  192.0.28.0/22
  192.0.32.0/21
  192.0.40.0/21
  192.0.48.0/20

At the very least, if we're going to pursue this option, we need to 
provide a description of the algorithm that a relying party would use to 
determine if AS65000 is authorized to advertise the prefix 192.0.0.0/18. 
(E.g., would the relying party take the collection of all ROAs for 
AS65000 and then construct all possible aggregates?)

- Matt Lepinski :->

---

From: Rob Austein <[email-masked]>
Date: Mon, 06 Aug 2007 17:08:14 -0400

> > that this complexity really is necessary).

I still stand by this part of what I said.

> matches the prefix to be validated.

Upon further consideration and some offline discussion, I agree with
you on this point.  I was confused about the other cases where I
thought one might need to construct an aggregate from multiple ROAs.

But this was a side point.  That my proposed work-around to a
non-problem is itself unworkable does not change the nature of the
non-problem.

> reason I continue to support the concept of allowing multiple signatures 

I don't see how this follows.  I still don't believe that there's any
real need for multiple signatures, because there's no good reason for
the issuer to force this mess upon its subjects.  As far as I can tell
this is a non-problem to which we do not need a solution.

---

From: George Michaelson <[email-masked]>
Date: Tue, 7 Aug 2007 15:02:57 +1000

On Mon, 06 Aug 2007 17:08:14 -0400

> > I don't agree with this assessment and to me ruling out the ability
> > of multiple signatures on a ROA introduces the potential for undue
> > levels of uncertainty in relying party validation of route objects.
> > For that reason I continue to support the concept of allowing
> > multiple signatures on a ROAs.
> 
 
I can foresee plausible circumstances where even if we didn't want
them, purposeful multiple signings could exist.

You say above 'the issuer' but we already know that ERX has resulted in
thousands of swampy fragments being distributed amongst the RIR, such
that there isn't one 'issuer' to sign over any re-combined prefixes in
the space.

I think that a standard in ROA which didn't admit of multiple signings
would be weak. I think we'd be forcing single-sign imperatives on the
community before we fully understand what people expect to do in ROA,
and in the litany of related signings which will exist under 3779
qualified certificates.

I want there to be a good definition of what a multiple sign looks
like, and I support the WG defining it. I suspect that it adds a very
small amount of ASN1 'overhead' in the simple case of a single-sign,
and I don't see why it causes you such a problem as a code developer.

-George

---

From: George Michaelson <[email-masked]>
Date: Wed, 8 Aug 2007 07:57:49 +1000

On Tue, 07 Aug 2007 08:02:24 -1000
Randy Bush <[email-masked]> wrote:

> [ imiho, it is strange and ill-mannered that this thread has been
> moved off the rescert list.  this should rectify that. ]

The issue came up in an IETF WG. The document in question is going into
IETF WG process. I think the primary driver here is going to be WG
consensus.

> 
> the last three times we went around this discussion (were you not on
> the other side?), we agreed that, for the exceedingly rare cases
> where an issuer might want a bit to expire at a time other than the
> rest of the resources, there was always reissue and revoke.

That does not directly affect why I believe we need multiple signatures
on a ROA. I'm finding this a bit of a non-sequiteur. What part of what
I wrote related to lifetimes?

> 
> this is not to say that i believe that different lifetimes for a
> resource subset from one issuer to one subject is operationally
> useful. i think it is yet one of a large and uninteresting set of
> "wow, we could have a nice feature someone might use someday."

but I was not addressing different lifetimes. I believe we need to
encompass ROAs with multiple signatures over them because we will not
be able to always ensure that resources lie under one trust anchor
path, and yet want to create signings over more efficient prefixes.

> 
> as, i think it was, steve kent said, this is already complex enough.
> and complexity and security protocols do not make good bedfellows.

The amount of complexity that is introduced by defining multiple
signatures is understood: It is purposeful. I don't believe its
avoidable.

-George

> randy

---

From: Geoff Huston <[email-masked]>
Date: Wed, 08 Aug 2007 09:48:55 +1000

Matt Lepinski wrote:
> Therefore, I was wondering if there was consensus that the ROA format 
> should be changed to allow multiple signatures? Or if the working group 
> felt there was a better approach for matching ROAs against the NLRI in a 
> BGP Update?
> 
> If we are going to allow two signatures on a ROA, I'd like to begin 
> revising the ROA format draft at some point next week so that we have 
> time to go through two versions of the ROA draft (if needed) before the 
> next IETF meeting. Therefore, if you do not believe that allowing 
> multiple signatures on a ROA is a good approach, please let me know 
> before August 8.

*wg chair hat off*

I've been reviewing the WG consideration of this topic so far 
<http://www1.ietf.org/mail-archive/web/sidr/current/index.html>

 From the thread of WG email so far on this topic it appears evident 
that no better approach for matching ROAs against the NLRI in a BGP 
update has been proposed in the case that the NLRI encompasses a span of 
addresses that are certified by multiple certificates.

The thread of conversation appears to be the view on the one hand that 
such a situation is sufficiently unlikely that it should not be 
encompassed in a ROA format specification, and on the other hand the 
view has been that a standard interoperable specification should cover 
all eventualities and leave nothing to creativity of individual 
implementors and that multiple signatures on a ROA should be allowed.

I don't believe that anyone has argued that this case would be one that 
would be commonly encountered. Equally, I have not seen a case made that 
this could _never_ happen under _any_ circumstances.

The question I ask myself is should a standard specification provide 
guidance to implementors and users of the tool that covers all envisaged 
situations or should it only cover the cases that are most likely to 
occur and leave the remainder unspecified?

My preference is the former approach, namely that a standard should be 
useful for interoperation in all envisaged use cases. Given the lack of 
workable alternatives here I remain of the view that the ROA 
specification should include this case, with the implication that a 
'standard' ROA within this specification may contain multiple signatures.

Geoff

---

From: Matt Lepinski <[email-masked]>
Date: Thu, 09 Aug 2007 09:53:42 -0400

Geoff,

Personally, I'm happy to have multiple signatures on a ROA. However, I 
think that multiple signatures is not the only way that we can provide 
guidence in all envisaged situations.

Sandy had previously posted the following list of possible solutions:

(1) create multiple singly signed ROAs, say for two /20's, and let the 
recipient interpret whether you meant to authorize the origination of 
the /19 as well.

(2) mandate that all sources (all CAs) MUST produce an aggregate cert 
when there are aggregatable certs

(3) tell prefix holders whose source is not willing to sign an aggregate 
cert that they are just out of luck in originating the aggregate, maybe 
just until the next prefix renewal period, maybe forever.

(4) allow a prefix holder whose source is not willing to sign an 
aggregate to sign an aggregate ROA with multiple signatures.

There seems to be consensus that (1) is not a workable solution. Some 
people (including myself) like option (4), but others feel that 
implementing multiple signatures would introduce needless complexity.

However, if the cases we are discussing are truly rare, then a 
combination of (2) and (3) may also be reasonable. Our documents could 
specify that a CA MUST produce an aggregate cert whenever possible and 
that a prefix holder needs to have an aggregate cert in order to 
advertise an aggregate prefix (otherwise, the prefix holder can only 
advertise the longer [non-aggregate] prefixes).

- Matt Lepinski :->

Geoff Huston wrote:

>> should be changed to allow multiple signatures? Or if the working 
>> group felt there was a better approach for matching ROAs against the 
>> NLRI in a BGP Update?
>>
>> time to go through two versions of the ROA draft (if needed) before 
>> the next IETF meeting. Therefore, if you do not believe that allowing 
> update has been proposed in the case that the NLRI encompasses a span 
> of addresses that are certified by multiple certificates.
>
> I don't believe that anyone has argued that this case would be one 
> that would be commonly encountered. Equally, I have not seen a case 
> made that this could _never_ happen under _any_ circumstances.
>
> guidance to implementors and users of the tool that covers all 
> envisaged situations or should it only cover the cases that are most 
> likely to occur and leave the remainder unspecified?
>
> useful for interoperation in all envisaged use cases. Given the lack 
> of workable alternatives here I remain of the view that the ROA

---

From: Geoff Huston <[email-masked]>
Date: Fri, 10 Aug 2007 08:39:54 +1000

Matt,

Firstly, this posting has the *wg chair hat off* disclaimer

> There seems to be consensus that (1) is not a workable solution.

yes, I agree with this perspective

  Some
> implementing multiple signatures would introduce needless complexity.

as is evident from the discussion in this wg mailing list.

> combination of (2) and (3) may also be reasonable.

I disagree with that position.

in response to 2) I am if the view that the entire discussion is about 
those cases where this does not happen. (i.e. yes, you can mandate that 
the tide must not come back in, but frankly its an exercise in Canutian 
posturing if issuers have local policies relating to certificate 
issuance that create differing validation paths of more specifics of an 
intended aggregate address advertisement!)

And in response to 3), it seems like the cart is placed before the horse 
here. One would've thought that any sensible exercise in securing BGP 
would be able to secure what we do today, rather than only a subset.

  Our documents could
> advertise the longer [non-aggregate] prefixes).

I find multiple signatures on a ROA a personally preferred option, 
supported already in available software and one that imposes minimal 
constraints on issuer policies, and minimal constraints on the ablity to 
secure BGP as we use it today.

regards,

     Geoff

---

From: Geoff Huston <[email-masked]>
Date: Fri, 10 Aug 2007 11:19:39 +1000

Randy Bush wrote:
> geoff,
> 
> your mail user agent has a bug.  somehow it repeatedly drops rescert
> list from cc:s, as in the message to which i am replying.  would
> appreciate your checking into it.  thanks.

Thank you for this advice. I will look at this.

On a similar topic, I note that your messages are not making it to the 
SIDR Working Group mailing list. It may be a bug in your mail user 
agent, or possibly a bug in the IETF's mailing list software, or 
possibly because you may not be subscribed to that mailing list. If you 
wish the SIDR Working Group to have the benefit of your perspectives on 
this topic you may want to check into this.

> and many of us don't, as you have read.

This has been noted in previous WG messages on this topic, all of which 
may not have reached you if you are not subscribed to the mailing list.
(an archive of the SIDR WG mailing list is at 
http://www.ietf.org/html.charters/sidr-charter.html)

>  when there is no consensus,
> possibly one should not add a feature.  and this is an addition.

Conventionally, the role of calling WG consensus of a WG topic is the 
responsibility of the WG Chairs. This particular co-chair thanks you for 
your advice concerning this role, and will be mindful of all advice and 
comments posted to the WG mailer as and when a WG consensus call is 
appropriate on this (or any other) topic.

>> supported already in available software
> 
> not in the sbgp implementations of which i am aware.  not in the code
> arin is producing.  in what code does it exist?

*WG co-chair hat OFF*

it is my understanding that OpenSSL supports such functionality.

To quote from: http://www.openssl.org/docs/apps/smime.html

"a signing certificate when signing or resigning a message, this option 
can be used multiple times if more than one signer is required. If a 
message is being verified then the signers certificates will be written 
to this file if the verification was successful."

I trust that this answers your query.

regards,

   Geoff Huston

---

From: Rob Austein <[email-masked]>
Date: Fri, 10 Aug 2007 09:12:59 -0400

> and I don't see why it causes you such a problem as a code developer.

ASN.1 overhead isn't the issue.  The problems start to arise when you
think about error handling and infrequently used code paths.  As I
said earlier in this thread:

At Sat, 04 Aug 2007 13:40:39 -0400, Rob Austein wrote:
> 
> ... just another code path that will need to be debugged and a more
> complicated algorithm for deciding whether a ROA is valid (what's a
> relying party supposed to do if if one signature on a ROA is valid
> and the other is not?  If five are valid and three are not?  Is
> there an upper limit to the number of signatures?  At one point does
> this become a denial of service attack on the relying party? ...).

Seldom-used code paths tend not to get debugged.  Whacky error cases
that almost never occur tends not to get debugged.  "Tend not to get
debugged" is a technical term, meaning, among other things, that even
if the developer attempts to simulate the error condition, that's
still just a lab test; the code doesn't get exercised in real life
until years later when some nogoodnik figures out how to turn it into
a security exploit.

If this were a feature I believed we needed, that need would dominate.
Absent such a need, all I see is the downside.

---

From: Tim Christensen <[email-masked]>
Date: Mon, 13 Aug 2007 06:55:15 -0400

> -----Original Message-----
> From: Henk Uijterwaal [mailto:[email-masked]]
> Sent: Monday, August 06, 2007 1:38 AM
> Subject: Re: [Sidr] Multiple Signatures on a ROA
>
> All,
>
> I agree with Rob here.  I'd have no problem with extending
> the protocol if there was a valid case for doing so.
> However, the two cases that were mentioned on the list
> so-far, are low probability cases that can be handled by
> having 2 ROAs.  Until somebody comes up with a third case
> that needs this, let's not make things more complicated than
> they already are.

Sorry I am late to this conversation, I've been on holiday for some time.

ARIN has never assigned address space in a manner consistent with the hypothetical cases raised on the SIDR list, and it is unlikely that it would ever do so.

Best regards to all, and happy to be back
Tim Christensen

---

From: [email-masked] (Sandy Murphy)
Date: Mon, 13 Aug 2007 10:55:02 -0400 (EDT)

>ARIN has never assigned address space in a manner consistent with the hypot=
>hetical cases raised on the SIDR list, and it is unlikely that it would eve=
>r do so.

I'm confused.

The ARIN NPRM says:

6.3.4. Aggregation
...
Further, RIRs should apply practices that maximize the potential for subsequent
allocations to be made contiguous with past allocations currently held. However,
there can be no guarantee of contiguous allocation.

and

6.5.7. Existing IPv6 address space holders

Organizations that received /35 IPv6 allocations under the previous IPv6
address policy (RIRv6-Policies) are immediately entitled to have their
allocation expanded to a /32 address block, without providing justification,
so long as they satisfy the criteria in Section 6.5.1.1. The /32 address
block will contain the already allocated smaller address block (one or
multiple /35 address blocks in many cases) that was already reserved by 
the RIR for a subsequent allocation to the organization. Requests for
additional space beyond the minimum /32 size will be evaluated as discussed
elsewhere in the document.

That's the sort of reserve for future allocation I was talking about.

These quotes are from the IPv6 portion of the manual, but I thought from
many references in conversation, email, etc. to space reserved for
expansion that this occurred in IPv4 as well.

--Sandy

---

From: Tim Christensen <[email-masked]>
Date: Mon, 13 Aug 2007 12:35:06 -0400

> From: Sandy Murphy [mailto:[email-masked]]
> Sent: Monday, August 13, 2007 10:55 AM
> To: [email-masked]; [email-masked]; Tim Christensen
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Sidr] Multiple Signatures on a ROA
>
> >ARIN has never assigned address space in a manner consistent
> with the
> >hypot= hetical cases raised on the SIDR list, and it is
> unlikely that
> >it would eve= r do so.
>
> I'm confused.
>
> The ARIN NPRM says:
>
[policy regarding reserves elided]
> These quotes are from the IPv6 portion of the manual, but I
> thought from many references in conversation, email, etc. to
> space reserved for expansion that this occurred in IPv4 as well.

The examples raised on-list, in my understanding, referred to the following:

-- The possibility of two adjacent allocations from the same source being issued at different times with different validity periods and the single issuer being unwilling to issue an aggregate cert (Dr. Kent, 7/31/07)

For this example (and ignoring the unwilling-to-issue part) ARIN has never, and will likely never, issue adjacent allocations at different times, ***with different validity periods*** (end point validity, that is).  All reserves allocations of adjacent space conform to the validity period of the address block being extended.  (FWIW, ARIN would not issue 'experimental' space that is contiguous/aggregatable with 'normal' space either, and has never been asked to nor done so.)

-- The possibility of two (or more) adjacent allocations, received by the same entity, coming from two (or more) different sources.

For this example, ARIN has never issued resources to two (or more) different organizations who, by happenstance or purpose, have registered further adjacent, aggregatable downstream reallocations to a single third-party entity.

To be clear, I understood from the thread that the issues centered on differing-validity-periods-while-adjacent (not happening at ARIN) and split-parent-while-adjacent (in my opinion rare, and not seen at ARIN from our observations).

Tim

---

From: Geoff Huston <[email-masked]>
Date: Tue, 14 Aug 2007 07:54:11 +1000

*wg chair hat off*

Tim,

I did not say that ARIN would or would not generate such a situation 
within its own issuance policies, nor did I mention any other RIR. It 
may well be the case that RIR certificate issuance practices would 
attempt to avoid such a situation, but I don't believe that this 
adequately addresses the issue here about the scope of the standard 
specification.

I took a more general view in my posting of the 10th when I noted that 
it was possible for

"issuers [to] have local policies relating to certificate issuance that 
create differing validation paths of more specifics of an intended 
aggregate address advertisement"

I noted, however that this was a possibility, and also noted in my 
posting of the 8th that:

"The question I ask myself is should a standard specification provide 
guidance to implementors and users of the tool that covers all envisaged 
situations or should it only cover the cases that are most likely to 
occur and leave the remainder unspecified?

'standard' ROA within this specification may contain multiple signatures. "

regards,

   Geoff

---

From: Cat Okita <[email-masked]>
Date: Tue, 14 Aug 2007 22:47:54 -0400 (EDT)

On Tue, 14 Aug 2007, Geoff Huston wrote:
> I noted, however that this was a possibility, and also noted in my posting of 
> the 8th that:
>
> situations or should it only cover the cases that are most likely to occur 
> and leave the remainder unspecified?
>
> My preference is the former approach, namely that a standard should be useful 
> for interoperation in all envisaged use cases. Given the lack of workable 
> alternatives here I remain of the view that the ROA specification should 
> include this case, with the implication that a 'standard' ROA within this 
> specification may contain multiple signatures. "

I agree - it's easier to have the capability defined in a way that ensures
interoperability in all cases than to have to shoehorn incompatible
implementations together later, when it turns out that we -do- have more
cases than we'd previously expected

cheers!.
==========================================================================
"A cat spends her life conflicted between a deep, passionate and profound
desire for fish and an equally deep, passionate and profound desire to
avoid getting wet.  This is the defining metaphor of my life right now."