Re: [sidr] AD Review of draft-ietf-sidr-bgpsec-ops-10

[Randy Bush]

[ side comment best ignored ]

>> otoh, private AS numbers are used in non-confed topologies, e.g. the bgp
>> stub customer who uses a private AS.  they should not sign of course.
>> but once i receive their announcement and strip the private AS,
>> can/should i sign?  i just looked at bgpsec-protocol and found no
>> guidance.
> 
> from that vantage point you are the origin. it's not clear to me that a
> customer  relationship is substantively then if you do this internal to
 ^ different [ i presume ]
> your org. operationally the'yre probably also registering route objects,
> issuing LOAS and operating on behalf of the private ASN.

i buy everything but the LOAs.  issues of legal authority to enter into
contracts et alia.

randy

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

[sidr] Suresh Krishnan's No Objection on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT)

[Suresh Krishnan]

Suresh Krishnan has entered the following ballot position for
draft-ietf-sidr-bgpsec-protocol-21: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/



--
COMMENT:
--

* Section 2.1

The IANA registry at
http://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml
may be a better reference for AFIs than RFC4760.

* Section 4.2

Is there a specific reason that the signature construction algorithm
orders the fields in the way it does? It does look pretty complicated to
parse out and arrange the fields this way from the BGPsec packet that was
received.  Something like the following seems much simpler to calculate

 ++
 | Target AS Number   |
 ++ ---\
 | Signature Segment   : N-1  | \
 ++ \
... |
 ++ |
 | Signature Segment   : 2| |
 ++ |
 | Signature Segment   : 1| \
 ++  >  Data from
 | Secure_Path Segment : N| /   N Segments
 ++ |
... |
 ++ |
 | Secure_Path Segment : 2| |
 ++ /
 | Secure_Path Segment : 1|/
 ++---/
 | Algorithm Suite Identifier |
 ++
 | AFI|
 ++
 | SAFI   |
 ++
 | Prefix |
 ++

as the segment fields and signature fields are naturally grouped together
in the packet. Is there a difference in cryptographic strength between
these two constructions?


___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Confederations and Private ASNs (WAS: AD Review of draft-ietf-sidr-bgpsec-protocol-18)

[Randy Bush]

>> that is not the core of the problem.  the bgpsec protocol doc has to
>> specifically say that the public AS upon receiving the update from the
>> private AS
>>   o if the private signed to the public, public should check sig, then
>> strip it and then might sign as the originating AS or might not.  on
>> what criteria does it decide?
>>   o if the private did not sign, the public might sign or it might not.
>> on what criteria does it decide?
> 
>> as i said, once you burn that in, i will hack the ops doc
> 
> Does this change (in Section 7 in the document) work for you?
> 
> [OLD]
> 
>It is possible that a stub customer of an ISP employs a private AS
>number.  Such a stub customer cannot publish a ROA in the global RPKI
>for the private AS number and the prefixes that they use.  Also, the
>stub customer cannot become a BGPsec speaker.  If a BGPsec speaker in
>the ISP's AS receives an announcement for a prefix from the stub
>customer and chooses to propagate it to BGPsec peers, then it MUST
>strip the private AS and re-originate the prefix.  In order to do
>this, the prefix MUST have a ROA authorizing the ISP's AS to
>originate it.
> 
> [NEW]
> 
>It is possible that a stub customer of an ISP employs a private AS
>number.  Such a stub customer cannot publish a ROA in the global RPKI
>for the private AS number and the prefixes that they use.  Also, the
>global RPKI cannot support private AS numbers for issuing router
>certificates for eBGP routers in the private AS.  For interactions
>between the stub customer and the ISP, the following two scenarios
>are possible:
> 
>1.  The stub customer sends an unsigned BGP update for a prefix to
>the ISP's AS.  An edge BGPsec speaker in the ISP's AS may choose
>to propagate the prefix to its non-BGPsec and BGPsec peers.  If
>so, the ISP's edge BGPsec speaker MUST strip the AS_PATH with the
>private AS number, and then (a) re-originate the prefix without
>any signatures towards its non-BGPsec peer and (b) re-originate
>the prefix including its own signature towards its BGPsec peer.
>In both cases (i.e. (a) and (b)), the prefix MUST have a ROA in
>the global RPKI authorizing the ISP's AS to originate it.
> 
>2.  The ISP and the stub customer may use a local RPKI repository
>(using a mechanism such as described in [I-D.ietf-sidr-slurm]).
>Then there can be a ROA for the prefix originated by the sub AS,
>and the eBGP speaker in the stub AS can be a BGPsec speaker
>having a router certificate, albeit the ROA and router
>certificate are valid only locally.  With this arrangement, the
>stub AS sends a signed update for the prefix to the ISP's AS.  An
>edge BGPsec speaker in the ISP's AS validates the update using
>RPKI data based the local RPKI view.  Further, it may choose to
>propagate the prefix to its non-BGPsec and BGPsec peers.  If so,
>the ISP's edge BGPsec speaker MUST strip the Secure_Path and the
>Signature Segment received from the stub AS with the private AS
>number, and then (a) re-originate the prefix without any
>signatures towards its non-BGPsec peer and (b) re-originate the
>prefix including its own signature towards its BGPsec peer.  In
>both cases (i.e. (a) and (b)), the prefix MUST have a ROA in the
>global RPKI authorizing the ISP's AS to originate it.

i am easily confused.  can this be said with significantly less words so
i have a chance to actually understand it?

randy

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Mirja Kühlewind's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT)

[Randy Bush]

> Agreed. I guess you could in addition be very clear that a router that
> once negotiated (and/or send) BGPsec (attributes) should not be
> expected to always do so.

whoops!  that'll be in -14.  thanks.

randy

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT)

[Randy Bush]

i posted -13 so iesg has fresh

randy

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

[sidr] I-D Action: draft-ietf-sidr-bgpsec-ops-13.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Secure Inter-Domain Routing of the IETF.

Title   : BGPsec Operational Considerations
Author  : Randy Bush
Filename: draft-ietf-sidr-bgpsec-ops-13.txt
Pages   : 9
Date: 2017-01-03

Abstract:
   Deployment of the BGPsec architecture and protocols has many
   operational considerations.  This document attempts to collect and
   present the most critical and universal.  It is expected to evolve as
   BGPsec is formalized and initially deployed.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-ops/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-ops-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-ops-13


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT)

[Randy Bush]

thanks for the review.

> Update: I noted when reviewing other sidr drafts on this telechat
> agenda that this draft treats 2119 keywords differently than the other
> drafts.  That is, this draft explicitly excludes lower case versions
> of the 2119 keywords

which is, i believe, the current wisdom; see long discussion on ietf
list.

> while the other related drafts do not.

have fun with that. :)

> -1, first paragraph: "It is thought...": Can you mention "who" thinks
> -it?

phrase removed

> -1, third paragraph: Please consider writing out "also known as"

rich got that

> -4, first paragraph: I found "either" followed by "and/or" a bit
> confusing. I suggest simply dropping the word "either".

   As described in [I-D.ietf-sidr-rtr-keying] BGPsec-speaking routers
   are either capable of generating their own public/private key-pairs
   and having their certificates signed and published in the RPKI by the
   RPKI CA system, and/or are given public/private key-pairs by the
   operator.

but the router(s) might not be capable of generating key-pairs.  they
might, they might not, the op may generate or not, or both.  an absurd
corner case might be that a router with two ASs has the as0 key stuffed
by the as0 noc, and the as1 key is generated on device because that is
the as1 policy.

> -4, 2nd paragraph: The MAY seems like a statement of fact. Is it intended
> to offer permission, or describe reality? (The latter should not use a
> 2119 keyword.)

sure

> -4, last paragraph: "a prudent operator will..." sounds like it might be
> worthy of a SHOULD.

given the previous, how about lower case should

> -6, first paragraph: "SHOULD/MUST only" constructions tend to be
> ambiguous. In this case, are we saying SHOULD only originated signed
> announcements, as opposed to unsigned announcements? Or as opposed to
> validating received assignments? If the latter, then the "need not
> validate" seems to weaken the SHOULD.

   An edge site which does not provide transit and trusts its
   upstream(s) may only originate a signed prefix announcement and not
   validate received announcements.

> -6, last paragraph: Can something be cited for the 84% assertion?

easier to remove it.  actually, i thought i had done so already; which
causes me to worry if i lost other edits.

> -7, paragraph 6: This seems to say that signed paths MUST be signed. Does
> the "MUST be signed if sent to external BGP speakers" mean that the
> existing signature must not be stripped (as stated more weakly in the
> previous sentence), or does it mean the sender must re-sign the path?

   Because of possible RPKI version skew, an AS Path which does not
   validate at router R0 might validate at R1.  Therefore, signed paths
   that are Not Valid and yet propagated (because they are chosen as
   best path) should have their signatures left intact and MUST be
   signed if sent to external BGPsec speakers.

i am not seeing where bgpsec stripping was suggested; in fact, the
opposite.  if router r0 receives a signed path and intends to pass that
signed path to the next listener, r0 must sign the path.  i am at a loss
to understand your question.  clue bat please.

> -7, paragraph 7: "a signed path learned via iBGP MAY be Not Valid."
> seems like a statement of fact.

are you suggesting to downcase it?  i will assume so.

> -12.2: [I-D.ietf.sider.bgpsec.overview] is mentioned in section 2 as
> needed to understand this document. That suggests it should be a
> normative reference. 

ennie meenie.  i think some other reviewer had me push refs around.  i
don't have a dog in this fight.  my personal opinion would be that
overview is informative and the protocol spec itself is normative.

again, thanks.

randy

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

[sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT)

[Ben Campbell]

Ben Campbell has entered the following ballot position for
draft-ietf-sidr-bgpsec-ops-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-ops/



--
COMMENT:
--

Update:  I noted when reviewing other sidr drafts on this telechat agenda
that this draft treats 2119 keywords differently than the other drafts.
That is, this draft explicitly excludes lower case versions of the 2119
keywords, while the other related drafts do not. Assuming that these
drafts have the same target audience, I think that will be confusing to
readers.

I am okay with either approach; in fact I somewhat prefer excluding lower
case versions. But I think consistency among a related group of drafts is
more important.

Just a few minor and editorial comments:

-1, first paragraph: "It is thought...": Can you mention "who" thinks it?
Otherwise that reads as "weasel words".

-1, third paragraph: Please consider writing out "also known as"

-4, first paragraph: I found "either" followed by "and/or" a bit
confusing. I suggest simply dropping the word "either".

-4, 2nd paragraph: The MAY seems like a statement of fact. Is it intended
to offer permission, or describe reality? (The latter should not use a
2119 keyword.)

-4, last paragraph: "a prudent operator will..." sounds like it might be
worthy of a SHOULD.

-6, first paragraph: "SHOULD/MUST only" constructions tend to be
ambiguous. In this case, are we saying SHOULD only originated signed
announcements, as opposed to unsigned announcements? Or as opposed to
validating received assignments? If the latter, then the "need not
validate" seems to weaken the SHOULD.

-6, last paragraph: Can something be cited for the 84% assertion?

-7, paragraph 6: This seems to say that signed paths MUST be signed. Does
the "MUST be signed if sent to external BGP speakers" mean that the
existing signature must not be stripped (as stated more weakly in the
previous sentence), or does it mean the sender must re-sign the path?

-7, paragraph 7: "a signed path learned via iBGP MAY be Not Valid." seems
like a statement of fact.

-12.2: [I-D.ietf.sider.bgpsec.overview] is mentioned in section 2 as
needed to understand this document. That suggests it should be a
normative reference. 



-


___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Mirja Kühlewind's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT)

[Randy Bush]

>> ok, i have had coffee.
>> 
>> as a bif gedanken experiment, posit a global registry where r0 can say
>> "i can speak bgpsec."  i am a distant r1 and receive an unsigned path
>> with r0 in it.
>>   o did someone before r0 on the path not speak bgpsec, so the path was
>> never signed?
>>   o did someone between us not speak bgpsec, so the path was stripped?
>>   o was there a monkey in the middle?
>> 
>> i think we did discuss this problem space, and decided that, as long as
>> we allow islands of partial deployment, and therefore path stripping,
>> the monkey is on our back.  we might have been wrong in this; but even
>> with coffee i do not see a way out.
>> 
>> and i do not think the idea of partial path signing, r0 signing a
>> received unsigned path, would have helped a lot.
>> 
>> it is not clear to me that this is a space where the ops doc can help
>> much.  i am open to ideas.
> 
> I'm currently not using bgpsec (or rpki for that matter).  BUT, if there
> was no path to go back, I would never ever use it.  Destroying my ASN
> because I wasn't ready to migrate is a straight-up No Go(tm).
> 
> Mistakes will be made.  Rolling back will happen.  Preventing rolling
> back will kill the baby and will guarentee this will never be rolled
> out.

what do you mean by "no path to go back" and "rolling back?"

where do you see "destroying" your AS?

my only guess is that
  o you have not read the spec or any documentation on it, and
  o you triggered on the phrase "path stripping"

fwiw, path stripping is removing the bgpsec gorp from a bgpsec path and
rendering a classic bgp4 path to hand to a bgp listener who does not
understand bgpsec.  no ASs are harmed in the process.

randy

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

[sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT)

[Ben Campbell]

Ben Campbell has entered the following ballot position for
draft-ietf-sidr-bgpsec-ops-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-ops/



--
COMMENT:
--

Just a few minor and editorial comments:

-1, first paragraph: "It is thought...": Can you mention "who" thinks it?
Otherwise that reads as "weasel words".

-1, third paragraph: Please consider writing out "also known as"

-4, first paragraph: I found "either" followed by "and/or" a bit
confusing. I suggest simply dropping the word "either".

-4, 2nd paragraph: The MAY seems like a statement of fact. Is it intended
to offer permission, or describe reality? (The latter should not use a
2119 keyword.)

-4, last paragraph: "a prudent operator will..." sounds like it might be
worthy of a SHOULD.

-6, first paragraph: "SHOULD/MUST only" constructions tend to be
ambiguous. In this case, are we saying SHOULD only originated signed
announcements, as opposed to unsigned announcements? Or as opposed to
validating received assignments? If the latter, then the "need not
validate" seems to weaken the SHOULD.

-6, last paragraph: Can something be cited for the 84% assertion?

-7, paragraph 6: This seems to say that signed paths MUST be signed. Does
the "MUST be signed if sent to external BGP speakers" mean that the
existing signature must not be stripped (as stated more weakly in the
previous sentence), or does it mean the sender must re-sign the path?

-7, paragraph 7: "a signed path learned via iBGP MAY be Not Valid." seems
like a statement of fact.

-12.2: [I-D.ietf.sider.bgpsec.overview] is mentioned in section 2 as
needed to understand this document. That suggests it should be a
normative reference. 



-


___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Confederations and Private ASNs (WAS: AD Review of draft-ietf-sidr-bgpsec-protocol-18)

[David Farmer]

On Mon, Jan 2, 2017 at 9:32 AM, Borchert, Oliver (Fed) <
oliver.borch...@nist.gov> wrote:
>
> To avoid unnecessary confusion with the ambiguity of the word private, I
> would change
> the wording of “the (private) Member-AS Number” to “the Member-AS Number”
> by
> removing the wording of “(private)” within parenthesis.
> This leaves the usage of private only for the signing parties private key
> which I think
> is well understood.
>
> Oliver
>

I'd suggest the use of "private use" in the parenthesis instead of
eliminating the word "private", and maybe add an informational reference to
RFC6996 as well.  If the intent that a "Member-AS Number" is to be from the
private use range as defined in RFC6996, then that should be stated some
place.

-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Review of draft-ietf-sidr-bgpsec-pki-profiles-19

[Yaron Sheffer]

Hi Sean,

Please see below.


On 03/01/17 18:12, Sean Turner wrote:

Yaron,

Thanks for the review.


On Jan 1, 2017, at 11:26, Yaron Sheffer  wrote:

Reviewer: Yaron Sheffer
Review result: Has Nits

* 3.1.1: The serial number in RFC 6487 is still a real, unique serial
number that uniquely identifies the certificate. Here it is used as
something other than a serial number, which is explicitly NOT unique,
and the CA is left to decide how to make it unique in the face of
potentially repeating BGP IDs. If this is not a real issue (e.g.
because duplicate IDs are rare and never within a RIR), please say
so.

As Rob pointed out this paragraph is talking about the serial number naming 
attribute.  Maybe something like:

r/only two attributes/only two naming attributes
and
r/common name and serial number/common name (i.e., X520CommonName) and serial 
number (i.e., X520SerialNumber)

People ought to them be able to track down the definitions.
I'm good with these changes. However, according to Randy's response to 
my review, the text later on is subtly incorrect (or at least 
misleading). Router IDs are not globally unique, but the combination of 
AS Number and Router ID is in fact globally unique.





* 3.2: earlier we said that Basic Constraints must not be included in
the EE cert. Now we are saying that only a particular boolean flag
must not be honored when processing the Cert Request. What happens if
Basic Constraints is included in the Cert Request but with other
flags?

The CA is ultimately the one who decides what gets issued.  A good CA would know to 
only issue properly formatted BGPsec certificates either by ignoring the improperly 
requested “feature" or rejecting it outright.  Since these CAs really aren’t 
open CAs then the CA ought not get caught off-guard with requests.
I'm not sure I understand. Why not give a consistent advice to EEs and 
CAs, e.g., reject any request that includes any Basic Constraints.



* 3.3: ID.sidr-rfc6485bis -> RFC 7935

drat I missed one.


* 6: in the paragraph that discusses hash functions, please spell out
the names of the two key identifiers, because I cannot determine what
they are from the document.

Ack they’re the key identifiers in the cert: Subject Key Identifier and Issuer 
Key Identifier

r/two key identifier extensions./two key identifier extensions (i.e., Subject 
Key Identifier and Issuer Key Identifier)

Yes.


spt


___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Mirja Kühlewind's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT)

[Sriram, Kotikalapudi (Fed)]

Hi Peter,

>At Tue, 3 Jan 2017 09:39:07 +0100,
>Peter Hessler  wrote:
>>
>> I'm currently not using bgpsec (or rpki for that matter).  BUT, if there
>> was no path to go back, I would never ever use it.  Destroying my ASN
>> because I wasn't ready to migrate is a straight-up No Go(tm).

>yup, I think this was part of the original thought process for bgpsec.

A BGP speaker always has the option to drop a BGPsec session,
and send a new BGP open request without the BGPsec capability
(Section 2.2 in the protocol spec document). 
Please also see my response to Mirja.

Thank you.

Sriram
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

[sidr] Review of draft-ietf-sidr-bgpsec-pki-profiles-19

[Dale Worley]

Reviewer: Dale Worley
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft.  The General Area
Review Team (Gen-ART) reviews all IETF documents being processed by
the IESG for the IETF Chair.  Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

Document: draft-ietf-sidr-bgpsec-pki-profiles-19
Reviewer: Dale R. Worley
Review Date: 3 Jan 2017
IETF LC End Date: 19 Dec 2016
IESG Telechat date: 5 Jan 2017

Summary:

This draft is basically ready for publication, but has nits that
should be fixed before publication.

The draft is much improved relative to the Gen-ART review of -18, but
a few items remain.

3.1.1.  Subject 

   However, each
   certificate issued by an individual CA MUST contain a Subject name
   that is unique to that CA context.

E-mail from Sean Turner on 22 Dec 2016 says:

I think this is just a case of a missing "CA" in front of the
word
"context" so tweaking it to: " that is unique to that CA
context".  The certs only need to be unique on a per CA basis the
subject name does not need to be unique across the whole of the
RPKI.  The combination of issuer+subject+serial # plus all the
parent certs provides the uniqueness.

However, there doesn't seem to be a standard meaning of the phrase
"CA
context".  I can't find any occurrences in any RFC or in any I-D
other
than draft-ietf-trans-threat-analysis-NN.

It seems to me that the best solution is to put a cleaned-up version
of Sean's statement "The combination of issuer+subject+serial # plus
all parent certs provides the uniqueness." into the draft, as that is
admirably clear.  (Unless, of course, there is a standard PKI phrase
for that requirement, in which case that could be used.)  For
instance:

   However, the combination of subject name, serial number, issuer,
   and certification path must be globally unique.

3.3.  BGPsec Router Certificate Validation 

   The validation procedure used for BGPsec Router Certificates is
   identical to the validation procedure described in Section 7 of
   [RFC6487] (and any RFC that updates this procedure), as modified
   below.  For example, in step 3: "The certificate contains all
field
   that must be present" - refers to the fields that are required by
   this specification.

This picks up the changes from Sean Turner's e-mail of 22 Dec 2016
except it omits changing "that updates this procedure" to "that
updates that procedure", which seems to me to necessary to make the
wording correct.

   step 3: "The certificate contains all field that must be present"

This doesn't match the text in RFC 6487, despite claiming to be
quoted:
s/all field/all fields/ and s/must/MUST/.

7.  IANA Considerations

   No IANA allocations are request of IANA, ...

I think this should be "No IANA allocations are requested of IANA",
or
probably better "No allocations are requested of IANA".

E-mail from Sean Turner on 22 Dec 2016 says "Alvaro had a similar
comment on the IANA considerations and he suggested the first
option.", but no change has been made.

Dale


___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Review of draft-ietf-sidr-bgpsec-pki-profiles-19

[Sean Turner]

Yaron,

Thanks for the review.

> On Jan 1, 2017, at 11:26, Yaron Sheffer  wrote:
> 
> Reviewer: Yaron Sheffer
> Review result: Has Nits
> 
> * 3.1.1: The serial number in RFC 6487 is still a real, unique serial
> number that uniquely identifies the certificate. Here it is used as
> something other than a serial number, which is explicitly NOT unique,
> and the CA is left to decide how to make it unique in the face of
> potentially repeating BGP IDs. If this is not a real issue (e.g.
> because duplicate IDs are rare and never within a RIR), please say
> so.

As Rob pointed out this paragraph is talking about the serial number naming 
attribute.  Maybe something like:

r/only two attributes/only two naming attributes
and
r/common name and serial number/common name (i.e., X520CommonName) and serial 
number (i.e., X520SerialNumber) 

People ought to them be able to track down the definitions.

> * 3.2: earlier we said that Basic Constraints must not be included in
> the EE cert. Now we are saying that only a particular boolean flag
> must not be honored when processing the Cert Request. What happens if
> Basic Constraints is included in the Cert Request but with other
> flags?

The CA is ultimately the one who decides what gets issued.  A good CA would 
know to only issue properly formatted BGPsec certificates either by ignoring 
the improperly requested “feature" or rejecting it outright.  Since these CAs 
really aren’t open CAs then the CA ought not get caught off-guard with requests.

> * 3.3: ID.sidr-rfc6485bis -> RFC 7935

drat I missed one.

> * 6: in the paragraph that discusses hash functions, please spell out
> the names of the two key identifiers, because I cannot determine what
> they are from the document.

Ack they’re the key identifiers in the cert: Subject Key Identifier and Issuer 
Key Identifier 

r/two key identifier extensions./two key identifier extensions (i.e., Subject 
Key Identifier and Issuer Key Identifier)

spt
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Mirja Kühlewind's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT)

[Sriram, Kotikalapudi (Fed)]

Hi Mirja,

>I actually might be mixing this up with some discussion about DNSsec a while 
>ago, where the problem was that once enable others will remember that it was 
>supported and will not accept non secured requests anymore.

>But as we are talking about this, could there be a similar case here, where a 
>router is known to support BGPsec and others would ignore/drop non-signed 
>announcements? (Sorry if that’s all discussed in the protocol doc; in this 
>case just ignore my questions ;-); didn’t review the protocol spec yet but 
>it’s the next doc on my list; probably should have read that one first…)

In BGPsec peering session, it is allowed to send signed updates for some 
prefixes and 
unsigned updates for other prefixes. This is necessary for backward 
compatibility
and incremental deployment. 

In this scenario,

AS1-BGP(unsigned)-AS3---BGPsec(signed)AS4
 
  |
AS2BGPsec(signed)

AS3 forwards to AS4 unsigned updates originated from AS1 
and also forwards signed updates originated from AS2.

Just because an AS is known to support BGPsec, it is not required that it must 
send only signed updates. 
On the receive side, it would be purely a matter of local policy to prefer a 
signed update 
over an unsigned update for the same prefix or how to treat an unsigned update
in path selection process, etc.   

Excerpt from Section 4.1 in the BGPsec protocol draft:
 
   If a BGPsec router has received only a non-BGPsec update message
   containing the AS_PATH attribute (instead of the BGPsec_Path
   attribute) from a peer for a given prefix, then it MUST NOT attach a
   BGPsec_Path attribute when it propagates the update message.  
   

   Conversely, if a BGPsec router has received a BGPsec update message
   (with the BGPsec_Path attribute) from a peer for a given prefix and
   it chooses to propagate that peer's route for the prefix, then it
   SHOULD propagate the route as a BGPsec update message containing the
   BGPsec_Path attribute.

Does this answer your question?

Thanks.

Sriram
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Mirja Kühlewind's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT)

[Mirja Kuehlewind (IETF)]

Agreed. I guess you could in addition be very clear that a router that once 
negotiated (and/or send) BGPsec (attributes) should not be expected to always 
do so. This is implicitly said already, so please decide on your own if you’d 
like to add anymore text.

Thanks!
Mirja

> Am 03.01.2017 um 16:20 schrieb Alvaro Retana (aretana) :
> 
> Hi!
>  
> I don’t think there’s anything to be done, besides the guidance already in 
> the draft about path preference: prefer Valid paths.  If the validity state 
> changes later, then it becomes a local policy to use or not.
>  
> Alvaro.
>  
>> On 1/2/17, 8:37 PM, "Randy Bush"  wrote:
>>  
>> it is not clear to me that this is a space where the ops doc can help
>> much.  i am open to ideas.
>>  

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Mirja Kühlewind's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT)

[Chris Morrow]

At Tue, 3 Jan 2017 09:39:07 +0100,
Peter Hessler  wrote:
> 
> I'm currently not using bgpsec (or rpki for that matter).  BUT, if there
> was no path to go back, I would never ever use it.  Destroying my ASN
> because I wasn't ready to migrate is a straight-up No Go(tm).

yup, I think this was part of the original thought process for bgpsec.

> Mistakes will be made.  Rolling back will happen.  Preventing rolling
> back will kill the baby and will guarentee this will never be rolled
> out.

one (me) hopes that we can rollout over time, and make progress on a
better network.

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Mirja Kühlewind's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT)

[Peter Hessler]

On 2017 Jan 03 (Tue) at 10:37:38 +0900 (+0900), Randy Bush wrote:
:ok, i have had coffee.
:
:as a bif gedanken experiment, posit a global registry where r0 can say
:"i can speak bgpsec."  i am a distant r1 and receive an unsigned path
:with r0 in it.
:  o did someone before r0 on the path not speak bgpsec, so the path was
:never signed?
:  o did someone between us not speak bgpsec, so the path was stripped?
:  o was there a monkey in the middle?
:
:i think we did discuss this problem space, and decided that, as long as
:we allow islands of partial deployment, and therefore path stripping,
:the monkey is on our back.  we might have been wrong in this; but even
:with coffee i do not see a way out.
:
:and i do not think the idea of partial path signing, r0 signing a
:received unsigned path, would have helped a lot.
:
:it is not clear to me that this is a space where the ops doc can help
:much.  i am open to ideas.
:
:randy
:

I'm currently not using bgpsec (or rpki for that matter).  BUT, if there
was no path to go back, I would never ever use it.  Destroying my ASN
because I wasn't ready to migrate is a straight-up No Go(tm).

Mistakes will be made.  Rolling back will happen.  Preventing rolling
back will kill the baby and will guarentee this will never be rolled
out.

-- 
Help fight continental drift.

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr