Subject: [sidr] WGLC for draft-ietf-sidr-bgpsec-protocol-05

From: "Murphy, Sandra" <[email-masked]>
Date: Sat, 15 Sep 2012 11:45:13 +0000

This starts a working group last call for draft-ietf-sidr-bgpsec-protocol-05.  The draft is available at http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-05 and https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/

Please review this draft to see if you think it is ready for publication.  Send end comments to the list.  

The WGLC will end on 29 September 2012.

--Sandy, speaking as wg co-chair

---

From: "George, Wes" <[email-masked]>
Date: Tue, 18 Sep 2012 16:21:55 -0400

Nits:
Multiple sections have "musts" and "shoulds" that are not 2119-formatted (lower-case) - please ensure that this is intentional

Substantial:

Any reason why we're using "good" and "not good"  for validation state instead of valid/invalid (and unknown)? I'd think that consistency between this and the language in the origin validation stuff would be helpful unless we have a specific reason not to use the same language. And I realize that there isn't really an "unknown" status as the result of trying to validate a BGPSec update, but as far as the implementation is concerned, standard BGP updates (those without BGPSec) are considered unknown, and it might be good to explicitly state that as a part of the validation algorithm.

I'm awaiting co-author review of the I-D version of the email I wrote about AS-Migration, and am hoping to have it posted next week sometime. I think that we need to discuss the considerations from that issue to ensure that no changes need to be made in the protocol spec document/design before we progress this. There's been some discussion of using pcount=0 to manage some parts of this, but that would have to be covered in the update validation and origination algorithm if we choose to solve the problem that way. Also I'm not completely certain that pcount will solve the use case completely. I'm not opposed to using the draft as a follow-on to the protocol draft (update it) to handle this specific case, but I'd like to have WG consensus that this is the route we should take rather than incorporating any solution for this use case into the current document since it is still in draft.

Thanks,

Wes George

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Murphy, Sandra
> Sent: Saturday, September 15, 2012 7:45 AM
> To: [email-masked]
> Subject: [sidr] WGLC for draft-ietf-sidr-bgpsec-protocol-05
>
> This starts a working group last call for draft-ietf-sidr-bgpsec-
> protocol-05.  The draft is available at
> http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-05 and
> https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/
>
> Please review this draft to see if you think it is ready for
> publication.  Send end comments to the list.
>
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

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: "Murphy, Sandra" <[email-masked]>
Date: Tue, 18 Sep 2012 21:03:30 +0000

>There's been some discussion of using pcount=0 to manage 
>some parts of this, but that would have to be covered in the 
>update validation and origination algorithm if we choose to 
>solve the problem that way.

The use of pcount=0 was hoped/expected to require NO changes in the update validation algorithm.  If you have discovered places where it would require changes, it will indeed be interesting to see and discuss.

--Sandy
________________________________________
From: [email-masked] [[email-masked]] on behalf of George, Wes [[email-masked]]
Sent: Tuesday, September 18, 2012 4:21 PM
To: Murphy, Sandra; [email-masked]
Subject: Re: [sidr] WGLC for draft-ietf-sidr-bgpsec-protocol-05

Nits:

Substantial:

Thanks,

Wes George

---

From: "George, Wes" <[email-masked]>
Date: Wed, 19 Sep 2012 13:15:54 -0400

> From: Murphy, Sandra [mailto:[email-masked]]
> Sent: Tuesday, September 18, 2012 5:04 PM
> To: George, Wes; [email-masked]
> Subject: RE: WGLC for draft-ietf-sidr-bgpsec-protocol-05
>
> The use of pcount=0 was hoped/expected to require NO changes in the
> update validation algorithm.  If you have discovered places where it
> would require changes, it will indeed be interesting to see and discuss.

[WEG] use of pcount=0 for AS migration may not require changes to the *algorithm* itself, as much as it will simply require discussion of the process for handling pcount=0 in the cases where it is used and the neighbor is not a transparent route-server, since currently that case is discussed specifically in the draft, and there is a specific recommendation that pcount=0 updates be dropped if they didn't come from a known route-server neighbor.

That said, I'm not convinced it completely solves the problem, as I (hopefully) articulated in my pending draft, and *that* may require algorithm changes.

Wes

---

From: Danny McPherson <[email-masked]>
Date: Thu, 20 Sep 2012 10:42:19 -0400

Sandy, 
I don't understand how we can WG LC this document when the requirements document isn't complete, and the requirements document isn't complete because we're still working out the threats document.  

Can you explain the logic here?

-danny

---

From: Sean Turner <[email-masked]>
Date: Thu, 20 Sep 2012 17:46:59 -0400

Here's my review:

One biggie:

1) MUST have an "IANA Considerations" section even if it says "none". 
But, I think you've Flags and Info Types to register right?

Algs are getting done elsewhere ;)

One not so biggie but a required formatting thing:

1) s9: If all references are normative, put "Normative" in the section 
title.

A bunch of nits mixed in with requests for additional clarifications 
(i.e., no biggies):

1) s1: r/must have an/needs an

2) s1: r/does not require/does not need

3) s2: r/[4]that/[4] that

4) s2, bits 2 and 3 as well as the fourth octet: normally this should 
would be a must any reason it's not a must?:

  These
  reserved bits should be set to zero by the sender and ignored by the
  receiver.

5) s2: contains the following:

  If there does not exist at least one version of BGPSEC that is
  supported by both peers in a BGP session, then the use of BGPSEC has
  not been negotiated.  (That is, in such a case, messages containing
  the BGPSEC_Path_Signatures MUST NOT be sent.)

Should this paragraph say something about the BGP NOTIFICATION message 
with the Error Code 2 (OPEN Message Error) and the OPEN Message Error 
SubCode 4 (Unsupported Optional Parameter) or is it the SubCode 7 
(Unsupported Capability) MUST be returned if both don't support bgpsec?

6) s2, Figure: If the AFI is 2 octets can we do the following:

    +---------------------------------------+
    |               AFI                     |
    +                                       +
    |                                       |
    +---------------------------------------+

so people won't ask what's in the blank line ;)

7) s2: Is there a reference for AFI that we can point to?

8) s2: ? r/speaker must include two/speaker includes two

9) s2: r/it has also advertises/it has also advertised

10) s2: r/(see RFC 4893)./[RFC 4893] - and add a reference.

11) s2: X2 (aligns with earlier sentences) r:/its open message/its BGP 
OPEN message/

12) s3: r/new optional/new OPTIONAL

13) High-Level Diagram of the BGPSEC_Path_Signatures Attribute
     BGPSEC_Path_Signatures figure: I might be reading way to much in to 
this but I don't want people to get the impression that signature X and 
Y for alg 1 and 2 are the same.  You might draw that conclusion from this:

  |     +-----------------+       +-----------------+       |
  |     | Sig Block 1     |       |  Sig Block 2    |       |
  |     +-----------------+       +-----------------+       |
  |     | Alg Suite 1     |       |  Alg Suite 2    |       |
  |     | SKI X           |       |  SKI X          |       |
  |     | Sig Length X    |       |  Sig Length X   |       |
  |     | Signature X     |       |  Signature X    |       |
  |     | SKI Length Y    |       |  SKI Length Y   |       |
  |     | SKI Y           |       |  SKI Y          |       |
  |     | Sig Length Y    |       |  Sig Length Y   |       |
  |     | Signature Y     |       |  Signature Y    |       |
  |     |      ...        |       |      ....       |       |
  |     +-----------------+       +-----------------+       |

Maybe in Sig Block 1 r/X/X1 and r/Y/Y1 and in Sig block 2 r/X/X2 and r/Y/Y2?

14) s3: If it does include the AS_PATH attribute what happens:

  That is, update messages that contain the
  BGPSEC_Path_Signatures attribute MUST NOT contain the AS_PATH
  attribute.

15) s3.1: Should probably add some ascii art for the flags:

+-+-+-+-+-+-+-+-+
|C|   Reserved  |
+-+-+-+-+-+-+-+-+

16) s3.1: r/These bits MUST be set to zero by the sender.
            /These bits MUST be set to zero by the sender and ignored
             by the recipient.

17) s3.1/3.2: Are the editor's notes going to get removed at some point 
or are we planning on keeping it?

18) s3.3: Probably worth adding the the SKI is copied from the signers 
certificate and need not be generated.  Or, is that implementation specific?

19) s4: In the last paragraph should the "must" be "MUST" x2.  It's in a 
"Note" paragraph so I could see not use MUST, but in that case maybe 
r/must possess/needs and r/must/needs to. If you use the MUST strike 
"Note" -  I don't think requirements should appear in Note paragraphs 
(though they often do).

20) s4.1: I'd just strike "Note that" from the those two paragraphs (x3).

21) s4.2: If we're going to keep NOT RECOMMENDED then you need to add it 
to the conventions.  Put it after RECOMMENDED so the nit checker won't 
barf on it.

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
    and "OPTIONAL" in this document are to be interpreted as described
    in RFC 2119 [8].

Actually, the RFC editor is going to move the requirements language to 
the mainbody so might as well do it now.  Just slap it in as s1.1.

22) s4.3: MUST instead of must:

   Members of autonomous system confederations [3] must additionally
   follow the instructions in this section for processing BGPSEC update
   messages.

23) s4.3: r/it must remove all
            /it MUST remove all ?
           r/confederation members must make
            /confederation members MUST make ?

24) s5.2: I think there a link missing to how you determine whether the 
certificate is valid in the following:

   To do this, consult the valid
   RPKI end-entity certificate data and look up all valid (AS, SKI,
   Public Key) triples in which the AS matches the AS number in the
   corresponding Secure_Path segment.

To me that means do the RPKI certificate checks in RFC 6487 as augmented 
by s3.3 of draft-ietf-sidr-bgpsec-pki-profiles.  Probably just adding a 
pointer to [11] would wfm.

   To do this, consult the valid
   RPKI end-entity certificate data and look up all valid (AS, SKI,
   Public Key) triples, see Section 3.3 of [11], in which the AS matches
   the AS number in the corresponding Secure_Path segment.

or something like that.

25) s6.1, 1st para: r/must/needs to X2

26) s6.1, 2nd para, 2nd sentence: I think the bit about the 'new' 
algorithm being specified in [12] should be deleted. It doesn't say 
anything about 'new' algorithm right now and the 3rd paragraph says if 
and when the new alg is chosen that draft will be updated.

27) s6.1: r/the future the mandatory/the future mandatory

That's it for now.

spt

---

From: Danny McPherson <[email-masked]>
Date: Fri, 21 Sep 2012 18:20:09 -0400

I do not intend to review this document in it's current state and am confused how we can WG LC it while the threat and [presumably subsequent] requirements documents are still being developed by the WG. 

I would like an explanation from the chairs regarding what the intention is here.

-danny

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 21 Sep 2012 19:13:59 -0400

> I would like an explanation from the chairs regarding what the intention is here.

I believe the hope was to stir up some discussion, interest and
readers prior to the interim meeting next saturday. As with all WGLC's
perhaps this document needs to wait on something else, or isn't ready
yet, or has other considerations to deal with... or is ready to fly
like a baby birdie. we won't know without some discussion, and I
believe there will be a bunch more of that in 8 days time.

-chris

---

From: "Murphy, Sandra" <[email-masked]>
Date: Fri, 21 Sep 2012 23:27:45 +0000

The protocol, threats and requirements documents are definitely tied together and will progress together.  The three documents have been in the working group for the same length of time, so you'd think that they, being so tied, would have had equal attention and be equally mature.

On the non-process, reality side of things:  The newest protocol draft came out on 7 Sep and I asked the working group to "look at this draft right away" because it would be discussed at the interim meeting.  After eight days with no comments, a wglc seemed a good idea.  Sad that our lives need a wglc to produce participation, but it is what it is.

--Sandy

---

From: Brian Dickson <[email-masked]>
Date: Fri, 21 Sep 2012 20:18:02 -0400

IMHO, attempting to generate discussion on a document by doing WGLC, is
completely bass-ackwards.

I don't believe it is at all appropriate to WGLC a document prior to
substantive review and maturity.

I.e. the chairs should ask FIRST, informally, if folks think we're ready to
WGLC, and wait a bit for answers.
The bar for saying "no" should be fairly low, and only in the absence of
lots of positive "hum" should WGLC proceed.

I would suggest the chairs review the processes adopted in other (more
mature) WGs, such as dnsext, for better processes and procedures.
E.g. commitment of >=5 reviewers to review, prior to WGLC. This excludes
authors, of course, from the review process.
It has worked very well there, IMHO.

Given that, as Danny notes, the entire content of -protocol depends on
-requirements, which itself depends on -threats, I have to concur with him
- "NO" to proceeding at this time.

So, to be clear:
- I don't think that, even if it were otherwise ready, that it wold be
appropriate to WGLC the -protocol doc
- I do not believe the -protocol doc is ready to go (independent of the
gating issue)

There are several areas that are not adequately settled, especially in the
pcount=0 and transition areas.

Consider this a formal request to bounce this document out of WGLC.

It would be fine to discuss on the interim meeting, and there does not need
to be a WGLC just to get discussion.

Brian

On Fri, Sep 21, 2012 at 7:13 PM, Christopher Morrow <[email-masked]
> wrote:

> > I do not intend to review this document in it's current state and am
> confused how we can WG LC it while the threat and [presumably subsequent]
> requirements documents are still being developed by the WG.
> >
> >> I don't understand how we can WG LC this document when the requirements
> document isn't complete, and the requirements document isn't complete
> because we're still working out the threats document.
> >>
> >>> This starts a working group last call for
> draft-ietf-sidr-bgpsec-protocol-05.  The draft is available at

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 21 Sep 2012 20:20:33 -0400

> substantive review and maturity.

it's on it's 5th revision, with substantive discussion along the way...

---

From: Brian Dickson <[email-masked]>
Date: Fri, 21 Sep 2012 20:24:37 -0400

With all due respect, Sandy, what are you smoking?

If there is a dependency that goes "A, then B, then C", then CLEARLY "C"
needs to bake longer than "B", and "B" longer than "A". Maybe not strictly
relative elapsed time, but certainly there would need to be a post-A
significant time before "B" finishes. Ditto for B->C.

In most cases, effort on C and B is likely to be potentially wasted prior
to A, and worse, it leads to work on "C" and "B" resulting in wrong-headed
decisions concerning "A", precisely *because* of the work on "B" and "C"
would otherwise be wasted.

The history of tech is littered with (frequently DOD subcontractors')
wasted efforts that end up bloating projects or putting them into dead-end
paths. ADA, anyone?

Let's look at the reality, rather than the theory, when evaluating
documents' progress and status, please. Especially when one is "chair" of a
WG.

I don't think putting any sort of time pressure is appropriate when we are
talking about a critical infrastructure security protocol.

Brian

On Fri, Sep 21, 2012 at 7:27 PM, Murphy, Sandra <[email-masked]>wrote:

> The protocol, threats and requirements documents are definitely tied
> together and will progress together.  The three documents have been in the
> working group for the same length of time, so you'd think that they, being
> so tied, would have had equal attention and be equally mature.
>
> On the non-process, reality side of things:  The newest protocol draft
> came out on 7 Sep and I asked the working group to "look at this draft
> right away" because it would be discussed at the interim meeting.  After
> eight days with no comments, a wglc seemed a good idea.  Sad that our lives
> need a wglc to produce participation, but it is what it is.
>
> --Sandy

---

From: Brian Dickson <[email-masked]>
Date: Fri, 21 Sep 2012 20:28:47 -0400

Discussion yes, revisions, not so much, and in particular, -threats is not
done. WGLC is inappropriate prior to -threats completion in WG.

Plus, -threats has not adequately accommodated criticism. Doing
s/BGPSEC/ANOTHER_NAME/g does not qualify as "substantive", IMHO.

There was no review post -05 publication. Review prior to that point is not
relevant, IMHO.

At a minimum, those whose comments were in theory addressed, should be
given the opportunity, each and every one of them, to speak up and be heard.

It is the job of the chairs to track issues and confirm with commentators
that revisions are adequate.

I am not a chair.

Brian

On Fri, Sep 21, 2012 at 8:20 PM, Christopher Morrow <[email-masked]

---

From: Randy Bush <[email-masked]>
Date: Sat, 22 Sep 2012 09:32:05 +0900

> The newest protocol draft came out on 7 Sep and I asked the working
> group to "look at this draft right away" because it would be discussed
> at the interim meeting.  After eight days with no comments, a wglc
> seemed a good idea.  Sad that our lives need a wglc to produce
> participation, but it is what it is.

i note that you got one actual reivew, which is good.  the only other
stuff i have seen is people telling the chairs what the process should
be, embarrassing.  i promise a detailed re-read in the next days.

randy

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 21 Sep 2012 20:52:01 -0400

I think your objection was noted... no need to belabour the point (or
become uncivil)

thanks for your opinion.
-chris

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 21 Sep 2012 20:52:21 -0400

> be, embarrassing.  i promise a detailed re-read in the next days.

thnx!

---

From: "Osterweil, Eric" <[email-masked]>
Date: Sat, 22 Sep 2012 01:14:55 +0000

Dear wg and wg chairs (those without and those with hats),

My comments on the requirements draft have never been addressed. This thread highlights a dependency that exists between the requirements of this protocol and the design of this protocol.  I do not think that (as engineers) should embrace the backward nature of this situation.

I object to this draft until we can mature the drafts it depends on.

Eric

----- Original Message -----
From: Randy Bush [mailto:[email-masked]]
Sent: Friday, September 21, 2012 08:32 PM
To: Sandra Murphy <[email-masked]>
Cc: sidr wg <[email-masked]>
Subject: Re: [sidr] WGLC for draft-ietf-sidr-bgpsec-protocol-05

randy

---

From: Randy Bush <[email-masked]>
Date: Sat, 22 Sep 2012 10:49:51 +0900

> My comments on the requirements draft have never been addressed.

not ignoring you.  i have kept them and plan a rev.  chairs have not
told me it's a rush so i am trying not to do a rev a day on this one.

randy

---

From: Danny McPherson <[email-masked]>
Date: Sat, 22 Sep 2012 13:24:46 -0400

On Sep 21, 2012, at 7:27 PM, Murphy, Sandra wrote:

> er.  The three documents have been in the working group for the same length of time, so you'd think that they, being so tied, would have had equal attention and be equally mature.

Sandy - The very fact that "The three documents have been in the working group for the same length of time" is PRECISELY why I have this concern.  

Until we've agreed upon requirements we intend to design for I don't know what problems we profess to be solving in a proposed protocol and therefore I am not capable of assessing if a protocol is meeting said requirements - the point of transparency here is so that others [who didn't bring these documents into the WG as a set] can have a fair say about their content before we progress.  

Further, if there wasn't such an apparent disconnect at the earlier stages of the process (e.g., what problems we are solving for), or IF we were designing these things in an IRTF group as EXPERIMENTAL and not as IETF Standards Track documents, I might be afforded the opportunity to care less.

-danny

---

From: Danny McPherson <[email-masked]>
Date: Sat, 22 Sep 2012 13:55:05 -0400

On Sep 21, 2012, at 8:32 PM, Randy Bush wrote:

> be, embarrassing. 

I concur - the stated fact that we're still awaiting revisions to the threats document and the requirements draft has long-standing unaddressed comments and the protocol document is being WG last called -- it is indeed embarrassing.

Given the potential array of implications of work here, as well as the climate surrounding Internet governance and the global stability of the routing system, open standards development and transparency, we ought to have the good sense to follow our own processes.  If solutions champions want less friction take it to the IRTF and make it EXPERIMENTAL...

Feeling a bit like "the wall" here [1]....

-danny

[1] http://archive.psg.com/051000.ccr-ivtf.html

---

From: Randy Bush <[email-masked]>
Date: Mon, 24 Sep 2012 06:59:29 +0200

my apologies for the bald and boring ascii text.  if you wish i can put
it in word perfect or pdf.  :)
</in joke>

the document seems to have lost that Router Certificates for key sets
may be per router, not just per AS.  see section 3.1.1.1 (sic), Subject,
of draft-ietf-sidr-bgpsec-pki-profiles.  as an AS may have hundreds of
BGPSEC speaking edge routers, you don't want to have to search the whole
bag of Router Certificates for an AS to find the cert/key that verifies
a particular signature.  and you can not just use the router-id of the
peer AS received in the bgp open, as you will also need the router-ids
of the signers further down the path.

the document repeaytedly refers to EE Certs etc. where it should simply
reference BGPsec Router Certificates as described in Section 3.1 of
[I-D.ietf-sidr-bgpsec-pki-profiles]

in general, i think the wording is redundant and unnecessarily complex
in many places.  but that is probably as much my disease than the editor's.

---

Abstract

   This document describes BGPSEC, an extension to the Border Gateway
   Protocol (BGP) that provides security for the AS-PATH attribute in
   BGP update messages.

uh, the bgp attribute is AS_PATH, note the underbar

and since it removes the AS_PATH attribute, it does not really secure
it.

in general, i think the nomenclature needs tightening, and it needs a
clear phrase for the ASs through which the announcement has been routed.

--

Requirements Language

fwiw, recently i have been using more specific language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to
   be interpreted as described in RFC 2119 [RFC2119] only when they
   appear in all upper case.  They may also appear in lower or mixed
   case as English words, without normative meaning.

--

1.  Introduction

   2.  Every AS listed in the AS_Path attribute of the update explicitly
       authorized the advertisement of the route to the subsequent AS in
       the AS_Path.

ain't no as_path attribute in a bgpsec update.  it seems to be the
bgpsec_path_signatures attribute.  btw, why not just bgpsec_path?
or more formally BGPSEC_PATH

--

   This document specifies a new optional (non-transitive) BGP path

why is "non-transitive" in parens?

--

   the documents referenced therein.)  Any BGPSEC speaker who wishes to
   send BGP update messages to external peers (eBGP) containing the
   BGPSEC_Path_Signatures

scrambled.  the external peers do not contain the BGPSEC_Path_Signatures

--

   must have an RPKI end-entity certificate (as
   well as the associated private signing key) corresponding to the
   BGPSEC speaker's AS number.

i think you want to refer to BGPsec Router Certificates as described in
Section 3.1 of [I-D.ietf-sidr-bgpsec-pki-profiles]

--

2.  BGPSEC Negotiation

   This document defines a new BGP capability [4]that allows a BGP
   speaker to advertise to its neighbors the ability to send and/or

it advertises to *a* neighbor

--

                    0        1        2  3       4 5 6 7
                 +---------------------------------------+
                 | Send | Receive | Reserved  |  Version |
                 +---------------------------------------+
                 |               AFI                     |
                 +---------------------------------------+
                 |                                       |
                 +---------------------------------------+
                 |             Reserved                  |
                 +---------------------------------------+
                 |               SAFI                    |
                 +---------------------------------------+

remove the middle part of the line between AFI and the following octet.
e.g.

                 +----             AFI           --------+

--

   The high order bit (bit 0) of the first octet is set to 1 to indicate
   that the sender is able to send BGPSEC update messages, and is set to
   zero otherwise.  The next highest order bit (bit 1) of this octet is
   set to 1 to indicate that the sender is able to receive BGPSEC update
   messages, and is set to zero otherwise.

this leaves open that both may be zero

--

   The BGPSEC_Path_Signatures algorithm carries the secured AS Path
   information, including the digital signatures that protect this AS

"algorithm?"  attribute, i suspect

--

   BGPSEC_Path_Signatures attribute replaces the AS_PATH attribute, in a
   BGPSEC update message.  That is, update messages that contain the
   BGPSEC_Path_Signatures attribute MUST NOT contain the AS_PATH
   attribute.

and vice versa

--

                     BGPSEC_Path_Signatures Attribute

         +-------------------------------------------------------+
         | Secure_Path                             (variable)    |
         +-------------------------------------------------------+
         | Additional_Info                         (variable)    |
         +-------------------------------------------------------+
         | Sequence of one or two Signature_Blocks (variable)    |
         +-------------------------------------------------------+

   The Secure_Path contains AS Path information for the BGPSEC update

"Path" should probably be lower case to avoid confusion

--

   message.  This is logically equivalent to the information that would
   be contained in the AS_PATH attribute.

s/would be contained in the/is contained in a non-BGPSEC/

--

                       The path information is used by BGPSEC speakers
   in the same way that information from the AS_PATH is used by non-
   BGPSEC speakers.

s/path information/Secure_Path/

--

   suite.  Each of the Signature_Blocks will contain a signature segment
   for each AS number (i.e, secure path segment) in the Secure_Path.

s/each/one/

--

                                       However, in order to enable a
   transition from an old algorithm suite to a new algorithm suite

without a flag day

--

   The Secure_Path Length contains the length (in octets) of the
   variable-length sequence of Secure_Path Segments.  As explained
   below, each Secure_Path segment is six octets long.  Note that this
   means the Secure_Path Length is six times the number Secure_Path
   Segments (i.e., the number of AS numbers in the path).

imiho, L in TLV includes itself so that you can just skip over that many
octets.  i.e. it would be 2 x segments + 2.  this occurs throughout.

--

   The Secure_Path contains one Secure_Path segment for each (distinct)

capitalize Segment

--

   Autonomous System in the path to the NLRI specified in the update
   message.

in the path to the origiating AS of the NLRI

--

                            Secure_Path Segment

                       +----------------------------+
                       | AS Number      (4 octets)  |
                       +----------------------------+
                       | pCount         (1 octet)   |
                       +----------------------------+
                       | Flags          (1 octet)   |
                       +----------------------------+

you are going to need the Router-ID of the signing router so that the
verifier knows which BGPsec Router Certificate to choose.

--

   The pCount field contains the number of repetitions of the associated
   autonomous system number that the signature covers.  This field
   enables a BGPSEC speaker to mimic the semantics of adding multiple

s/adding/prepending/

--

   The remaining seven bits of the Flags field are reserved for future
   use.  These bits MUST be set to zero by the sender.  The receiver
   uses the entire Flags octet to verify the digital signature
   (regardless of what value the reserved bits contain)

The remaining seven bits of the Flags MUST be set to zero by the sender,
and the signature is computed over all seven bits of the Flags.

--

                            Signature Segments
              +---------------------------------------------+
              | Subject Key Identifier        (20 octets)   |
              +---------------------------------------------+
              | Signature Length              (2 octets)    |
              +---------------------------------------------+
              | Signature                     (variable)    |
              +---------------------------------------------+

   The Subject Key Identifier contains the value in the Subject Key
   Identifier extension of the RPKI end-entity certificate 

again. please refer to BGPsec Router Certificates as described in
Section 3.1 of [I-D.ietf-sidr-bgpsec-pki-profiles]

--

4.  Generating a BGPSEC Update

   Note that in order to create or add a new signature to a BGPSEC
   update message with a given algorithm suite, the BGPSEC speaker must
   possess a private key suitable for generating signatures for this
   algorithm suite.  Additionally, this private key must correspond to
   the public key in a valid Resource PKI end-entity certificate whose
   AS number resource extension includes the BGPSEC speaker's AS number
   [11].

you do not mention that it could be a per-router-id key set.

--

4.1.  Originating a New BGPSEC Update

   The pCount field of the Secure_Path Segment is typically set to the
   value 1.  However, a BGPSEC speaker may set the pCount field to a
   value greater than 1.  Setting the pCount field to a value greater
   than one has the same semantics as repeating an AS number multiple
   times in the AS_PATH of a non-BGPSEC update message (e.g., for
   traffic engineering purposes).  Setting the pCount field to a value
   greater than one permits this repetition without requiring a separate
   digital signature for each repetition.

it may be zero in certain special circumstances, see section 42.666

--

   o  Construct a sequence of octets by concatenating the Target AS
      Number, the Secure_Path (Origin AS, pCount, and Flags), the
                                         ^ Router-ID

--

4.2.  Propagating a Route Advertisement

   If a BGPSEC router has received only non-BGPSEC update messages
   (without the BGPSEC_Path_Signatures attribute), containing the
   AS_Path attribute, from a peer for a given prefix 

s/messages/message/

--

   Note that removing BGPSEC signatures (i.e., propagating a route
   advertisement without the BGPSEC_Path_Signatures attribute) has
   significant security ramifications.  (See Section 7 for discussion of
   the security ramifications of removing BGPSEC signatures.)
   Therefore, when a route advertisement is received via a BGPSEC update
   message, propagating the route advertisement without the
   BGPSEC_Path_Signatures attribute is NOT RECOMMENDED.

unless the peer to which the BGPSEC speaker is sending did not signal
the ability to receive BGPSEC in the capability negotiation.  if this is
the case, see section 42.666 for converting to AS_PATH.

--

   If the BGPSEC speaker is not a member of an autonomous system
   confederation [3], then the Flags field of the Secure_Path Segment
   MUST be set to zero.

it might be prudent to not talk about the whole flags field, as we do
not know what exciting future may lie before it.  just talk about the 
Confed_Segment flag.

--

   If the received BGPSEC update message contains two Signature_ Blocks
   and the BGPSEC speaker supports both of the corresponding algorithms
   suites, then the new update message generated by the BGPSEC speaker
   SHOULD include both of the Signature_Blocks.  If the received BGPSEC
   update message contains two Signature_Blocks and the BGPSEC speaker
   only supports one of the two corresponding algorithm suites, then the
   BGPSEC speaker MUST remove the Signature_Block corresponding to the
   algorithm suite that it does not understand.  If the BGPSEC speaker
   does not support the algorithm suites in any of the Signature_Blocks
   contained in the received update message, then the BGPSEC speaker
   MUST NOT propagate the route advertisement with the
   BGPSEC_Path_Signatures attribute (i.e., propagate it as an unsigned
   BGP update message).

explain why.  the speaker can not add its info to a sig block for which
it does not understand the alg.  and there can not be a gap in the sig
block.

--

4.3.  Processing Instructions for Confederation Members

   o  First, starting with the least recently added Secure_Path
      segments, remove all of the consecutive Secure_Path segments that
      have the Confed_Segment flag set to one.

s/least/most/

--

4.4.  Reconstructing the AS_PATH Attribute

   2.  If the Confed_Segment flag in the Secure_Path segment is set to
       zero, then look at the most-recently added segment in the
       AS_PATH.

       *  In the case where the AS_PATH is empty then add (prepend to
          the AS_PATH) a new AS_PATH segment of type AS_SEQUENCE.

In the case where the AS_PATH is empty and pcount is greater than zero,
...

--

5.  Processing a Received BGPSEC Update

   Upon receiving a BGPSEC update message from an external (eBGP) peer,
   a BGPSEC speaker SHOULD validate the message to determine the
   authenticity of the AS PATH information contained in the
   BGPSEC_Path_Signatures attribute.

AS PATH is confusing.  maybe

   Upon receiving a BGPSEC update message from an external (eBGP) peer,
   a BGPSEC speaker SHOULD validate the message to determine the
   authenticity of the data covered by the BGPSEC_Path_Signatures
   attribute.

--

                                          However, in practice, it
   is expected that most implementations will not actually run the
   algorithm from Section 4.4, and will instead transform the
   BGPSEC_Path_Signatures attribute directly into some internal
   representation of AS path.

how about just saying that it will behave the same, and do not say it
actually has to transform it in any way?

--

   With regards to the processing of duplicate update messages, if the
   first update message is valid, then an implementation SHOULD NOT run
   the validation procedure on the second, duplicate update message
   (even if the bits of the signature field are different).  If the
   first update message is not valid, then an implementation SHOULD run
   the validation procedure on the second duplicate update message (as
   the signatures in the second update may be valid even though the
   first contained a signature that was invalid).

in the very next section, you use the words "Good" and "Not Good."
there is a consistency problem, and not just here.

--

  5.1.  Overview of BGPSEC Validation

   Validation of a BGPSEC update messages makes use of data from RPKI
   certificates and signed Route Origination Authorizations (ROA).  In
   particular, to validate update messages containing the
   BGPSEC_Path_Signatures attribute, it is necessary that the recipient
   have access to the following data obtained from valid RPKI
   certificates and ROAs:

   o  For each valid RPKI end-entity certificate containing an AS Number
      extension, the AS Number, Public Key and Subject Key Identifier
      are required,

and router-id

--

   o  For each valid ROA, the AS Number and the list of IP address
      prefixes.

what is a 'valid' roa?

--

   Note that the BGPSEC speaker could perform the validation of RPKI
   certificates and ROAs on its own and extract the required data, or it
   could receive the same data from a trusted cache that performs RPKI
   validation on behalf of (some set of) BGPSEC speakers.  (The latter
   case in analogous to the use of the RPKI-RTR protocol [13] for origin
   validation.)

draft-ymbk-rpki-rtr-keys is soon to describe a new rpki-rtr pdu to
handle the per-as and per-router keys

--

   It is expected that the output of the validation procedure will be
   used as an input to BGP route selection.  However, BGP route
   selection and thus the handling of the two validation states is a
   matter of local policy, and shall be handled using existing local
   policy mechanisms.

s/existing// i.e. a vendor could create a new testable attribute
bgpsec-state.

--

  It is expected that BGP peers will generally
   prefer routes received via 'Good' BGPSEC update messages over routes
   received via 'Not Good' BGPSEC update messages as well as routes
   received via update messages that do not contain the
   BGPSEC_Path_Signatures attribute.  However, BGPSEC specifies no
   changes to the BGP decision process and leaves to the operator the
   selection of an appropriate policy mechanism to achieve the
   operator's desired results within the BGP decision process.

someone should write a draft something like draft-ietf-sidr-bgpsec-ops

--

   BGPSEC validation needs only be performed at eBGP edge.  The
   validation status of a BGP signed/unsigned update MAY be conveyed via
   iBGP from an ingress edge router to an egress edge router.

how?  where are the bits to carry validation state?

--

   Local
   policy in the AS determines the specific means for conveying the
   validation status through various pre-existing mechanisms (e.g.,
   modifying an attribute).

imiho, this document should not get into all the lovely things local
policy might do unless it is required for bgpsec, and nothing should
be in that set.

--

   As discussed in Section 4, when a BGPSEC
   speaker chooses to forward a (syntactically correct) BGPSEC update
   message, it SHOULD be forwarded with its BGPSEC_Path_Signatures
   attribute intact (regardless of the validation state of the update
   message).

no.  not when the speaker does not understand one of the algorithms.

--

   Based entirely on local policy settings, an egress router
   MAY trust the validation status conveyed by an ingress router or it
   MAY perform its own validation.

or it can just sign it and not test anything at all.  this does not need
to be said

--

5.2.  Validation Algorithm

   3.  Check that the update message does not contain both a
       BGPSEC_Path_Signatures attribute and an AS_PATH attribute.

this sentence implies bgpsec validation could happen on an update with
only as_path.  you want to simply say no as_path is allowed.

--

   If there are two Signature_Blocks within the BGPSEC_Path_Signatures
   attribute and one of them is poorly formed (or contains the wrong
   number of Signature segments) , then the recipient should log that an
   error occurred

s/log/inform the operator/  i.e. it could snmp trap etc

--

   strip off that particular Signature_Block and process
   the update message as though it arrived with a single
   Signature_Block.  If the BGPSEC_Path_Signatures attribute contains an
   error that is not local to one of two Signature_Blocks, then the
   recipient should log that an error occurred

s/log/inform the operator/

--

   message containing the error.  (In particular, if any of checks 3-5
   above fail, the recipient should log that an error occurred and drop
   the update message containing the error.)

s/log/inform the operator/

--

   o  (Step II): Compute the digest function (for the given algorithm
      suite) on the appropriate data.  If the segment is not the (least
      recently added) segment corresponding to the origin AS, then the
      digest function should be computed on the following sequence of
      octets:

                      Sequence of Octets to be Hashed

     +-------------------------------------------+
     | AS Number of Target AS         (4 octets) |
     +-------------------------------------------+
     | AS Number                      (4 octets) |  ---\
     +-------------------------------------------+      \
     | pCount                         (1 octet)  |       >  Secure_Path
     +-------------------------------------------+      /
     | Flags                          (1 octet)  |  ---/
     +-------------------------------------------+
     | Sig Field in the Next Segment  (variable) |
     +-------------- ----------------------------+
                    ^
did the router-id fall through that little hole? :)

--

7.  Security Considerations

   o  The origin AS number corresponds to an autonomous system that has
      been authorized by the IP address space holder to originate route
                     ^ in the RPKI
      advertisements for the given prefix.

   o  For each AS number in the AS Path, a BGPSEC speaker authorized by
                                                        in the RPKI ^
      the holder of the AS number intentionally chose (in accordance
      with local policy) to propagate the route advertisement to the
      next AS in the Secure_Path.

--

   That is, the recipient of a valid BGPSEC Update message is assured
   that the Secure_Path corresponds to a sequence of autonomous systems
   who have all agreed in principle to forward packets to the given
   prefix along the indicated path.

we do not know what the bgp announcement is signaling.  while
willingness to forward has been the classic, idr is declaring bgp to be
a competitor to the dns for arbitrary signaling.

--

   (It should be noted that BGPSEC
   does not offer a precise guarantee that the data packets would
   propagate along the indicated path; it only guarantees that the BGP
   update conveying the path indeed propagated along the indicated
   path.)

this is more like it

--

   Therefore, it is important to note that when a BGPSEC speaker signs
   an outgoing update message, it is not attesting to a belief that all
   signatures prior to its are valid.  Instead it is merely asserting
   that:

   o  The BGPSEC speaker received the given route advertisement with the
      indicated NLRI and Secure_Path; and

   o  The BGPSEC speaker chose to propagate an advertisement for this
      route to the peer (implicitly) indicated by the 'Target AS'

and that it is capable of that particular algorithm suite (trivial)

--

   Finally, BGPSEC does not provide protection against all attacks at
   the transport layer.

s/all//

--

   EDITOR'S NOTE: Do we want to mandate a specific transport security
   mechanism (e.g., TCP-AO)?

slippery slope.

--

   Samuel Weiler
   Cobham

sparta again

-30-

---

From: Rob Austein <[email-masked]>
Date: Thu, 27 Sep 2012 18:58:48 +0200

Another review of draft-ietf-sidr-bgpsec-protocol-05.

...
>     BGPSEC relies on the Resource Public Key Infrastructure (RPKI)
>     certificates that attest to the allocation of AS number and IP
>     address resources.  (For more information on the RPKI, see [6] and
>     BGPSEC_Path_Signatures must have an RPKI end-entity certificate (as
>     BGPSEC speaker's AS number.  Note, however, that a BGPSEC speaker
>     does not require such a certificate in order to validate update
>     messages containing the BGPSEC_Path_Signatures attribute.

The BGPSEC speaker doesn't need the certificate, only the private key.
The certificate needs to exist in the RPKI, but unless I'm missing
something the BGPSEC speaker need never see its own certificate.

...
>                               Capability Value:
...
>     The fifth octet in the capability contains the 8-bit Subsequent
>     Address Family Identifier (SAFI).  This value is encoded as in the
>     BGP multiprotocol extensions [2].

Is zero SAFI the same thing as null SAFI?  It's not in RFC 3779: an
OCTET STRING of length two is not the same as an OCTET STRING of
length three with the third octet zeroed.

I suspect that presence of SAFI may require a flag bit, unless we are
certain that zero SAFI always means the same thing as null SAFI.

>  3.  The BGPSEC_Path_Signatures Attribute
...
>  
>          High-Level Diagram of the BGPSEC_Path_Signatures Attribute
>                            BGPSEC_Path_Signatures

What's the doubled attribute name supposed to mean?

>          +---------------------------------------------------------+
>          |     +-----------------+                                 |
>          |     |   Secure Path   |        +-----------------+      |
>          |     +-----------------+        | Additional Info |      |
>          |     |    AS X         |        +-----------------+      |
>          |     |    pCount X     |        |  Info Type      |      |
>          |     |    Flags X      |        |  Info Length    |      |
>          |     |    AS Y         |        |  Info Value     |      |
>          |     |    pCount Y     |        +-----------------+      |
>          |     |    Flags Y      |                                 |
>          |     |      ...        |                                 |
>          |     +-----------------+                                 |
>          |                                                         |
>          +---------------------------------------------------------+

I did not find this picture very clear and I thought I knew this
protocol.  Generally, in diagrams of this type, one does not assume
row major ordering of internal boxes.

>     The following is a more detailed explanation of the format of the

It's not more detailed, but it is clearer, because at least it's
obvious how the sections match up with the following text.

>  3.2.  Additional_Info
>  
>     Here we provide a detailed description of the Additional_Info in the
>                                Additional_Info
>                | Info Type                      (1 octet)    |
>                | Info Length                    (1 octet)    |
>                | Info Value                     (variable)   |
>     The Info Type field is a one-octet value that identifies the type of
>     additional information included in the Info Value field.  This
>     specification defines a single (null) type of Additional_Info.  The
>     Info Type for this null type is zero.
>  
>     The Info Length field contains the length in octets of the Info Value
>     field.  For the (null) Info Type zero specified in this document, the
>     Info Length MUST be zero.
>  
>     The syntax and semantics contained in the Info Value field depends on
>     the type contained in the Info Type field.  For the (null) Info Type
>     zero specified in this document, the Info Value field is empty (since
>     the Info Length field must be zero).
>  
>     Implementations compliant with this specification MUST set the Info
>     Type to zero in BGPSEC update messages for route advertisements that
>     they originate (see Section 4.1 for more details).  When an
>     implementation compliant with this specification receives a BGPSEC
>     update message with an Info Type field that it does not understand
>     (i.e., an Info Type other than zero), the implementation MUST use the
>     Additional_Info when it verifies digital signatures (as per Section
>     5.2).  However, other than signature verification, the implementation
>     MUST ignore the Info Value field when it does not understand the Info
>     Type.

So this is an expansion mechanism, fine, got that.  How many of these
appear in a message?  Looks like exactly one.  Not very flexible.  We
need to include this instead of just going to a new attribute type
because?

Overall, this extension format looks like it wants to be IPv4 header
options when it grows up, but the rest of the formats doom this to
being a singleton.  Kind of strange.

I don't really object, it's just more than a little odd as a
placeholder for we-have-no-real-idea-what.

...
>     In particular, this AS number MUST match the AS number in
>     the AS number resource extension field of the Resource PKI end-entity
>     certificate(s) that will be used to verify the digital signature(s)
>     constructed by this BGPSEC speaker.

"The" or "an"?   Is it legal for the EE certificate to cover more RFC
3779 resources than just a single ASN?

...
>     The BGPSEC speaker next copies the Additional_Info portion of the
>     BGPSEC_Path_Signatures directly from the received update message to
>     the new update message (that it is constructing).  Note that the
>     BGPSEC speaker MUST NOT change the Additional_Info as any change to
>     Additional_Info will cause the new BGPSEC update message to fail
>     validation (see Section 5).

So Additional_Info is generated only by the originator.  It would have
been kind to mention this earlier in the document.

>     BGPSEC_Path_Signatures attribute (i.e., propagate it as an unsigned

Parenthetical phrase says opposite of what I suspect it was intended
to mean.  I suspect you meant something like:

"(i.e., if it chooses to propagate this route advertisement at all, it
MUST do so as an unsigned BGP update message)".

...
>     When a confederation member receives a BGPSEC update message from a
>     peer within the confederation and propagates it to a peer outside the
>     confederation, it must remove all of the Secure_Path Segments added
>     by confederation members as well as the corresponding Signature
>     Segments.  To do this, the confederation member propagating the route
>     outside the confederation does the following:
>  
>        have the Confed_Segment flag set to one.  Stop this process once a
>        Scure_Path segment is reached which has its Confed_Segment flag
>        set to zero.  Keep a count of the number of segments removed in
>        this fashion.
>  
>     o  Second, starting with the most recently added Signature Segment,
>        remove a number of Signature Segments equal to the number of
>        Secure_Path Segments removed in the previous step.  (That is,
>        remove the K most recently added signature segments, where K is
>        the number of Secure_Path Segments removed in the previous step.)

Is "least recently added" in first bullet item a mistake?  Sure looks
like one.  If not, this seriously violates the Principal of Least
Astonishment, so the text needs a coherent explanation of why we
remove the least recent Secure_Path segments and the most recent
Signature Segments.

More generally, it would be nice if the document were clearer on the
circumstances under which there would ever be two or more blocks of
segments with the Confed_Segment flag turned on.  My guess is that
this should never happen, but, if so, the above description is an
awfully compled way of saying "strip out every Secure_Path segment
with the Confed_segment flag turned on, along with the corresponding
signature_segments."

...
>     Implementations that support such deferment of validation MUST
>     perform validation of these messages as soon as possible (i.e., as
>     soon as resources are available to perform validation) and MUST re-
>     run best path selection once the validation status of such update
>     messages is known.

Is it OK to do this incrementally if the implementation so desires, or
must the implementation only do this after catching up completely?  If
the latter, what should the implementation do if the flood continues
and the implementation doubts it will ever catch up?

>     This section specifies an algorithm for validation of BGPSEC update
>     messages.  A conformant implementation MUST include a BGPSEC update
>     validation algorithm that is functionally equivalent to the external
>     behavior of this algorithm.

s/external/externally visible/

>     error occurred, strip off that particular Signature_Block and process
>     recipient should log that an error occurred and drop the update

Do routers "log that an error occurred"?  Does incrementing a MIB
variable count?  What's the expected load from this logging?  What bad
thing (if any) happens if this logging is dropped or ignored?

>        signature is invalid, then mark the entire Signature-List Block as
>        'Not Good' and proceed to the next Signature_Block.  If the
>        signature validation algorithm determines that the signature is
>        valid, then continue processing Signature-Segments (within the
>        current Signature-List Block).

What's a "Signature-List Block"?  Never defined.

>     If all Signature-Segments within a Signature-List Block pass
>     validation (i.e., all segments are processed and the Signature-List
>     Block has not yet been marked 'Not Good'), then the Signature_Block
>     is marked as 'Good'.

What's a "Signature-Segment"?  Never defined.

>     If at least one Signature_Block is marked as 'Good', then the
>     validation algorithm terminates and the BGPSEC update message is
>     deemed to be 'Good'.  (That is, if a BGPSEC update message contains
>     two Signature_Blocks then the update message is deemed 'Good' if the
>     first Signature_Block is marked 'Good' OR the second Signature_Block
>     is marked 'Good'.)

I think this is saying that the validation algorithm requires that
there exist a complete valid chain for some single algorithm, ie, that
one cannot construct a valid chain by hopping between algorithms in
the middle of the chain.  This makes sense, since otherwise the
signature chaining won't work.  Might want to say so.

>  6.1.  Algorithm Suite Considerations
...
>     To this end, a mandatory algorithm suites document will be created
>     which specifies a mandatory-to-use 'current' algorithm suite for use
>     by all BGPSEC speakers [12].  Additionally, the document specifies an
>     additional 'new' algorithm suite that is recommended to implement.

Badly phrased, unless the real intent here is to say that we're going
to pick both the current and next algorithms right off the bat, which
seems unlikely to me.   I think it would be more correct to say that
we will specify an initial mandatory algorithm suite, and, once we
have some idea of what the next algorithm should be, we will publish
a series of updated documents phasing in the new one and (eventually,
years later) phasing out the old one.

>     It is anticipated

By whom?
                        
>     Once the transition has successfully been completed in this manner,
>     BGPSEC speakers SHOULD include only a single Signature_Block
>     (corresponding to the 'new' algorithm).

So we're going to start out with only one, right?

>  6.2.  Extensibility Considerations
...
>     At this point a transition would begin which is analogous to the
>     algorithm transition discussed in Section 6.2.

Specifying section numbers manually instead of using <xref/>, are we?

...
>     (It should be noted that BGPSEC does not offer a precise
>     guarantee that the data packets would propagate along the
>     indicated path; it only guarantees that the BGP update conveying
>     the path indeed propagated along the indicated path.)

"Precise guarantee", hell.  It provides no guarantee of any kind on
this point.  AFAIK nobody knows how to do that (yet).

---

From: Stephen Kent <[email-masked]>
Date: Fri, 28 Sep 2012 09:54:01 -0400

Rob,

> 3779 resources than just a single ASN?
yes, an EE cert can contain multiple ASNs, if they were allocated to the
cert holder by the same parent.
> years later) phasing out the old one.
that would be consistent with the alg migration strategy described in
draft-ietf-sidr-algorithm-agility-07

Steve

---

From: Rob Austein <[email-masked]>
Date: Fri, 28 Sep 2012 16:17:19 +0200

> cert holder by the same parent.

I know that RFC 3779 allows multiple ASNs, having implemented it. :)

What I'm asking is whether it was Matt's intent to restrict BGPSEC to
requiring that only a single ASN be certified in the relevant EE
certificate.  I do not recall any such restriction during earlier
discussions of this protocol, which is why I flagged it.

> draft-ietf-sidr-algorithm-agility-07

I assume (please correct if wrong) that your comment refers to my
suggested rephrasing being consistent with the algorithm migration
strategy.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 28 Sep 2012 11:09:53 -0400

Rob,

> I know that RFC 3779 allows multiple ASNs, having implemented it. :)
and I wrote it, so ...
> discussions of this protocol, which is why I flagged it.
OK, that was not clear from you question.
> suggested rephrasing being consistent with the algorithm migration
yes.

Steve