Re: [sidr] draft-ietf-sidr-bgpsec-protocol

[Sriram, Kotikalapudi (Fed)]

Keyur,

Thank you for taking the time to read and offer comments. 
I find the comments very insightful and helpful. 
My comments are marked with [Sriram] below.

>From: Keyur Patel ke...@arrcus.com

>Sent: Wednesday, January 4, 2017 5:53 PM

>The document is well written, easy to read and follow.
 
>Some minor comments are listed below:


>1)  Section 4.1 “The BGPsec Path attribute and the AS_PATH attribute are 
>mutually exclusive. That is, any update message containing the BGPsec Path 
>attribute MUST NOT contain the AS_PATH attribute”.  For any restarting 
>speakers in a GR mode, where the bgp capability is not exchanged, the existing 
>stale routes won’t have an AS_PATH attribute. We could add some clarifying 
>that helps to indicate that such routes should be considered valid in stale 
>mode (till they get refreshed)?


[Sriram]  As you have clarified for me on the phone, what you are saying here 
is that the two BGPsec peers lost the BGPsec session and now restarting in GR 
mode, but they have not exchanged BGPsec capability this time. Hence, they are 
now simple BGP (non-BGPsec) peers in GR mode. RFC4271 considers update message 
received without a well-known AS_PATH attribute as an error, and unfortunately 
in this case the cached BGPsec updates do not have AS_PATH (albeit they have 
BGPsec_Path). So you are saying "the router should not panic" and instead 
simply treat each cached update as NOT-IN-ERROR even though it is missing 
AS_PATH attribute. This way the GR can work properly. Of course, shortly the 
updates will have AS_PATH (and not considered in error) when they get refreshed 
(over the new simple BGP session). Per your suggestion, I will include new text 
in Section 7 to describe this required behavior for the GR mode. 


>2)   4.1 4th paragraph: "Note also that new signatures are only added to a 
>BGPsec update message when a BGPsec speaker is generating an update message to 
>send to an external peer (i.e., when the AS number of the peer is not equal to 
>the BGPsec speaker's own AS number).  Therefore, a BGPsec speaker who only 
>sends BGPsec update messages to peers within its own AS does not need to 
>possess any private signature keys." This text doesn't seem to apply to confed 
>peers? If so, it would be nice to clarify that this text doesn't apply to any 
>confed peers.


[Sriram] You have clarified in our phone conversation that you consider the 
inter-AS-member sessions as "iBGP" since they are all within a confederation AS 
domain. The BGPsec document considers the inter-AS-member sessions as "eBGP" 
(not "iBGP") and intra-Member-AS sessions as "iBGP".  You also clarified that 
you may call inter-AS-member sessions as "confederation-eBGP" sessions. 
Obviously, private key is required to sign over such 
"confederation-eBGP/BGPsec" sessions. I understand your point. I will put in 
new text (notes) to clarify this in the document.


>3)  Section 5 and Section 5.2, 1st paragraph: RFC4271 considers update message 
>received without a well-known AS_PATH attribute as an error.  We need some 
>text to clarify the (error handling if any) behavior when an update message is 
>received without a bgpsec and an aspath attribute. The current draft text 
>seems unclear about generation of bgpsec attribute as well (in a ibgp 
>scenario). Is it a requirement to generate an empty bgpsec attribute?


[Sriram]  As you have clarified for me over the phone, RFC 4271 (page 26) says 
the following :

   "When a BGP speaker originates a route then:
   b) the originating speaker includes an empty AS_PATH attribute in
 all UPDATE messages sent to internal peers.  (An empty AS_PATH
 attribute is one whose length field contains the value zero)."


[Sriram]  So what needs to be said in the BGPsec document is the following:  
The BGPsec_Path attribute is not attached in updates originated inside an AS 
and propagated to BGPsec capable internal peers. However, when a route is 
originated inside an AS and propagated to non-BGPsec internal peers, an empty 
AS_PATH attribute is included in the update (see [RFC 4271], page 26).


>4)   With an AS_PATH attribute in 4271 there was loop detection in place.  
>With BGPSec I don’t see that being called explicitly other than a passing 
>remark in section 5. Section 5.2 should have a check that allows a BGPsec 
>speaker to bail out of a validation procedure when a aspath loop is detected.


[Sriram]  I agree. I will include loop detection in the list of error checks in 
Section 5.2.


Sriram


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

Re: [sidr] draft-ietf-sidr-bgpsec-protocol

[Randy Bush]

did i miss the response to this?  i think some of the points are
important.

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)

[Ben Campbell]

On 5 Jan 2017, at 16:24, Randy Bush wrote:

>> Thanks, that helps. Would it make the last sentence say something to
>> the effect of "... and MUST additionally be signed by the propagating
>> router."?
>
> alvaro has asked me to stop editing
>
> randy

Understood :-)

___
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, that helps. Would it make the last sentence say something to
> the effect of "... and MUST additionally be signed by the propagating
> router."?

alvaro has asked me to stop editing

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)

[Ben Campbell]

On 5 Jan 2017, at 16:14, Randy Bush wrote:


Sorry, I did not mean that stripping was suggested; the previous

phrase (non-normatively) recommends against stripping. My question
is, since the subject of the sentence is "signed paths" whether the
"MUST be signed" language means "MUST NOT strip the signature"
(which I suspect to be the case), or something else.


how about

   As the mildly stochastic timing of RPKI propagation may cause
   version skew across routers, 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) MUST NOT have signatures stripped and MUST be signed if 
sent

   to external BGPsec speakers.

if not, use larger clue bat


It's likely I have this particular bat by the wrong end.

In the last sentence, does "MUST be signed" mean it must have a
signature (which would seem to make "MUST NOT strip" and "MUST be
signed" redundant), or does it mean the propagating router must add
it's own signature in addition to the existing one(s)?


yes, it must preserve the signed path and add its own signature.


Thanks, that helps. Would it make the last sentence say something to the 
effect of "... and MUST additionally be signed by the propagating 
router."?


Ben.

___
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]

>> Sorry, I did not mean that stripping was suggested; the previous
>>> phrase (non-normatively) recommends against stripping. My question
>>> is, since the subject of the sentence is "signed paths" whether the
>>> "MUST be signed" language means "MUST NOT strip the signature"
>>> (which I suspect to be the case), or something else.
>> 
>> how about
>> 
>>As the mildly stochastic timing of RPKI propagation may cause
>>version skew across routers, 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) MUST NOT have signatures stripped and MUST be signed if sent
>>to external BGPsec speakers.
>> 
>> if not, use larger clue bat
> 
> It's likely I have this particular bat by the wrong end.
> 
> In the last sentence, does "MUST be signed" mean it must have a
> signature (which would seem to make "MUST NOT strip" and "MUST be
> signed" redundant), or does it mean the propagating router must add
> it's own signature in addition to the existing one(s)?

yes, it must preserve the signed path and add its own signature.

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)

[Ben Campbell]

On 4 Jan 2017, at 19:29, Randy Bush wrote:


Sorry, I did not mean that stripping was suggested; the previous
phrase (non-normatively) recommends against stripping. My question 
is,

since the subject of the sentence is "signed paths" whether the "MUST
be signed" language means "MUST NOT strip the signature" (which I
suspect to be the case), or something else.



how about

   As the mildly stochastic timing of RPKI propagation may cause 
version
   skew across routers, 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) MUST NOT have
   signatures stripped and MUST be signed if sent to external BGPsec
   speakers.

if not, use larger clue bat


It's likely I have this particular bat by the wrong end.

In the last sentence, does "MUST be signed" mean it must have a 
signature (which would seem to make "MUST NOT strip" and "MUST be 
signed" redundant), or does it mean the propagating router must add it's 
own signature in addition to the existing one(s)?


Ben.

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

Re: [sidr] Benoit Claise's No Objection on draft-ietf-sidr-bgpsec-ops-16: (with COMMENT)

[Randy Bush]

> Proposal: one extra section on migration/deployability
> There is text in draft-ietf-sidr-bgpsec-protocol-21
> 
>How will migration from BGP to BGPsec look like?  What are the
>benefits for the first adopters?  Initially small groups of
>contiguous ASes would be doing BGPsec.  There would be possibly one
>or more such groups in different geographic regions of the global
>Internet.  Only the routes originated within each group and
>propagated within its borders would get the benefits of
>cryptographic
>AS path protection.  As BGPsec adoption grows, each group grows in
>size and eventually they join together to form even larger BGPsec
>capable groups of contiguous ASes.  The benefit for early adopters
>starts with AS path security within the contiguous-AS regions
>spanned
>by their respective groups.  Over time they would see those
>contiguous-AS regions grow much larger.
> 
> 

i see no merit in reproducing text from another document.  i could refer
to it, but i prefer to add

7.  Routing Policy

   As BGPsec signed paths can not traverse non-BGPsec topology, partial
   BGPsec deployment forms islands of assured paths.  As islands grow to
   touch each other, they become larger islands.

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-protocol-21: (with COMMENT)

[Alexey Melnikov]

On Wed, Jan 4, 2017, at 06:30 PM, Mirja Kuehlewind wrote:
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-sidr-bgpsec-protocol-21: No Objection

 [...]

> 1) Why do you need to send two different negotiation capabilities for
> each direction instead of just using two flags in the same capability?
> And similar why don't you just announce multiple address families in the
> same capability (using variable length)? 

This is a nit, but I was wondering about this myself.

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

[sidr] Benoit Claise's No Objection on draft-ietf-sidr-bgpsec-ops-16: (with COMMENT)

[Benoit Claise]

Benoit Claise has entered the following ballot position for
draft-ietf-sidr-bgpsec-ops-16: 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:
--

Happy to see an operational considerations document at the same time at
the protocol specifications, even if we know that "It is expected to
evolve as BGPsec is formalized and initially deployed."
Thanks Randy

Proposal: one extra section on migration/deployability
There is text in draft-ietf-sidr-bgpsec-protocol-21

   How will migration from BGP to BGPsec look like?  What are the
   benefits for the first adopters?  Initially small groups of
   contiguous ASes would be doing BGPsec.  There would be possibly one
   or more such groups in different geographic regions of the global
   Internet.  Only the routes originated within each group and
   propagated within its borders would get the benefits of
cryptographic
   AS path protection.  As BGPsec adoption grows, each group grows in
   size and eventually they join together to form even larger BGPsec
   capable groups of contiguous ASes.  The benefit for early adopters
   starts with AS path security within the contiguous-AS regions
spanned
   by their respective groups.  Over time they would see those
   contiguous-AS regions grow much larger.


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

Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-protocol-21: (with DISCUSS and COMMENT)

[Stephen Farrell]

Hiya,

On 05/01/17 14:10, Sriram, Kotikalapudi (Fed) wrote:
> Stephen,
> 
> Thank you for the detailed review and comments.
> Please see my responses marked with [Sriram] inline below.
> 
> [Sriram] Your DISCUSS points (1) and (3) were already
> discussed /being discussed in separate threads.

Yep, thanks. I need to check back to see how close we are
to resolving those, but I had thought the ball wasn't in my
court at the moment:-) I'm sure we'll sort 'em soon though.

> 
>> (2) Figure 8: It seems to me to be an error to omit the
> signer's ASN from the signed data and only have that
> included in the signer's certificate. Why is that intimate
> level of binding to the RPKI desirable? There may well be
> reasons but I'm not seeing 'em, and I am recalling that it
> took a chunk of effort to make CMS less dependent on
> X.509 for similar reasons (meaning identifying signers
> exclusively via cert issuer and serial in that case).  I
> would expect that there could be demand to have some level
> of independence between BGPsec and RPKI for at least
> internal uses such as those noted in the spec already.
> 
> [Sriram] Signer's ASN is indeed included in the signed data.
> In Figure 8, "Secure_Path Segment : N" corresponds
> to the signing AS (current AS) and that is where the 
> signer's ASN is included along with its pCount and Flags.

Hmm. That's the target ASN of the previous signer though.
I thought there were cases where they could differ? But
if not, then you probably need to state that as a rule
for checking signatures, is that there already? (Happy to
check later, but don't have time right now.)

One other thing below...

> 
>> --
>> COMMENT:
>> --
> 
>> - Figures 2 and 5 present the fields in different orders.
> That seems like a bad idea.
> 
> [Sriram] Good catch. Already fixed in my editor copy of version-22. 
> 
>> - 3.2: The reference to the pki profile doc is not precise
> enough, the string "key identifier" does not occur in that
> draft - it's in RFC6487, 4.8.2. 
> 
> [Sriram] Again, a good catch. Already fixed in my editor copy of version-22.  
> 
>> - 4.1, last para: is the distinction between an "internal
> peer" and "iBGP peer" sufficiently clear to routing folk?
> For me they sound similar but I assume it's ok.
> 
> [Sriram] I think it is well understood. But when I push version-22 out, 
> I’ll consider if I should simply just use "iBGP peer" consistently 
> and avoid using "internal peer". 
> 
>> - 5.2, I think you need to say something to the effect
> that every Secure_Path MUST have a signature with an
> algorithm that is supported. As I read the text, the
> algorithm as stated here could be read to not require
> that. E.g. the para before the bullets on p25 could be
> read to mean "drop all stuff involving unsupported algs
> and then continue to process the rest of the stuff."
> 
> [Sriram] Seems like a bit of a pathological case. 
> Could happen only if the sender behavior was incorrect. 

Yes, but 5.2 is verifier behaviour and out not
assume a correct signer, so I do thing the alg
presented here needs to cover such things.

> Sender is not required to know which algorithms a peer supports 
> but sender's expected behavior is this: MUST include a Signature_Block 
> for the "current" algorithm (which every BGPsec speaker 
> MUST support through the transition period), 

Where does it say that the current/next thing applies
to the entire world of BGPsec? I didn't read it that
way as it happens, but rather that the current/next
could involve different algorithms at different nodes
at the same time.

So e.g. I read it to be allowed that a migration from
rsa/sha256 then to ecdsa then to eddsa could occur
with some non-updated nodes still signing with rsa/sha256
whilst some shiny new nodes are doing ecdsa and eddsa and
others are in between.

I do agree that a global current/next pair of algs
is nicer, if that is what's wanted. But I don't recall
the text saying that. (Again happy to check later, but
no time right now;-)

Cheers,
S.


> and if the sender supports the "next" algorithm, 
> then it MUST include a Signature_Block for the "next" algorithm also.
> So the peer BGPsec receiver (who MUST support 
> at least the "current" algorithm) is not expected to be starved 
> of a Signature_Block it can work with.   
> 
>> - section 7: WRT non-deterministic signature algorithms, I
> think it'd be useful to note here that all such algorithms
> require good random number generation on the signer's
> system and that failing in that respect can expose the
> signer's private key.  IMO deterministic signature schemes
> are better for this reason but the need for a good RNG is
> I think a real operational issue worthy of note.
> 
> [Sriram] I will include wording to cover this in Section 7 in version-22.
> 
> Sriram 
> 



smime.p7s
Description: S/MIME Cryptographic Si

Re: [sidr] Alissa Cooper's No Objection on draft-ietf-sidr-bgpsec-ops-13: (with COMMENT)

[Alissa Cooper]

> On Jan 4, 2017, at 11:46 AM, Randy Bush  wrote:
> 
>>   "Route Reflectors MUST have BGPsec enabled if and only if there are
>>   eBGP speakers in their client cone, i.e. an RR client or the
>>   transitive closure of a client's customers' customers' customers'
>>   etc."
>> 
>> "MUST ... if and only if" is a strange construction.
> 
> the syntax may be stressed but the semantics are correct.
> 
>> I'm assuming what is meant here is that Route Reflectors MUST NOT
>> enable BGPsec unless there are eBGP speakers in their client cone --
> 
> nope.  if there are no bgpsec speakers in the client cone, the RRs MAY
> still choose to validate.  the point is that, if there are *any* bgpsec
> speakers in the client cone, then you'll want them to receive signed
> paths.  hence the RRs would have to enable bgpsec signing.

Ok, after reading it a few times I get it.

> 
>> for a normative requirement I think it would be better to be specific
>> rather than saying "etc." (e.g., "a client's customers or customers
>> thereof" or something like that).
> 
> how about tossing the extra words and going with
> 
>i.e. an RR client or the transitive closure of a client's customers.

Sounds good.

> 
>>   "Additionally, outsourcing verification is not prudent security
>>   practice."
>> 
>> Isn't that part of the point of draft-ietf-sidr-rpki-rtr-rfc6810-bis
>> though? I know this paragraph is not talking about that but since use
>> of a trusted cache was mentioned in the protocol draft, this struck me
>> as a slight discrepancy.
> 
> 6810 sec 3
> 
>   Local Caches: A local set of one or more collected and verified
>  caches.  A relying party, e.g., router or other client, MUST have
>  a trust relationship with, and a trusted transport channel to, any
>  authoritative cache(s) it uses.
> 
> contrast this with this document's
> 
>   BGPsec does not sign over communities, so they are not formally
>   trustable.  Additionally, outsourcing verification is not prudent
>   security practice.  Therefore an eBGP listener SHOULD NOT strongly
>   trust unsigned security signaling, such as communities, received
>   across a trust boundary.
> 
> note that this document is advising not crossing a trust boundary
> carrying data where integrity and authenticity are not protected, while
> 6810 advises quite the opposite.

Ok, fair enough.

Alissa

> 
> but if you want to stab me with outsourced security, have a look at
> draft-ietf-sidr-origin-validation-signaling-10.txt.  note that, while i
> am a co-author, i raised my hum against adopting, progressing, ...  it
> was one of those rock and hard place things.
> 
> randy

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

Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-protocol-21: (with DISCUSS and COMMENT)

[Sriram, Kotikalapudi (Fed)]

Stephen,

Thank you for the detailed review and comments.
Please see my responses marked with [Sriram] inline below.

[Sriram] Your DISCUSS points (1) and (3) were already
discussed /being discussed in separate threads.

> (2) Figure 8: It seems to me to be an error to omit the
signer's ASN from the signed data and only have that
included in the signer's certificate. Why is that intimate
level of binding to the RPKI desirable? There may well be
reasons but I'm not seeing 'em, and I am recalling that it
took a chunk of effort to make CMS less dependent on
X.509 for similar reasons (meaning identifying signers
exclusively via cert issuer and serial in that case).  I
would expect that there could be demand to have some level
of independence between BGPsec and RPKI for at least
internal uses such as those noted in the spec already.

[Sriram] Signer's ASN is indeed included in the signed data.
In Figure 8, "Secure_Path Segment : N" corresponds
to the signing AS (current AS) and that is where the 
signer's ASN is included along with its pCount and Flags.

> --
> COMMENT:
> --

> - Figures 2 and 5 present the fields in different orders.
That seems like a bad idea.

[Sriram] Good catch. Already fixed in my editor copy of version-22. 

> - 3.2: The reference to the pki profile doc is not precise
enough, the string "key identifier" does not occur in that
draft - it's in RFC6487, 4.8.2. 

[Sriram] Again, a good catch. Already fixed in my editor copy of version-22.  

> - 4.1, last para: is the distinction between an "internal
peer" and "iBGP peer" sufficiently clear to routing folk?
For me they sound similar but I assume it's ok.

[Sriram] I think it is well understood. But when I push version-22 out, 
I’ll consider if I should simply just use "iBGP peer" consistently 
and avoid using "internal peer". 

> - 5.2, I think you need to say something to the effect
that every Secure_Path MUST have a signature with an
algorithm that is supported. As I read the text, the
algorithm as stated here could be read to not require
that. E.g. the para before the bullets on p25 could be
read to mean "drop all stuff involving unsupported algs
and then continue to process the rest of the stuff."

[Sriram] Seems like a bit of a pathological case. 
Could happen only if the sender behavior was incorrect. 
Sender is not required to know which algorithms a peer supports 
but sender's expected behavior is this: MUST include a Signature_Block 
for the "current" algorithm (which every BGPsec speaker 
MUST support through the transition period), 
and if the sender supports the "next" algorithm, 
then it MUST include a Signature_Block for the "next" algorithm also.
So the peer BGPsec receiver (who MUST support 
at least the "current" algorithm) is not expected to be starved 
of a Signature_Block it can work with.   

> - section 7: WRT non-deterministic signature algorithms, I
think it'd be useful to note here that all such algorithms
require good random number generation on the signer's
system and that failing in that respect can expose the
signer's private key.  IMO deterministic signature schemes
are better for this reason but the need for a good RNG is
I think a real operational issue worthy of note.

[Sriram] I will include wording to cover this in Section 7 in version-22.

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

Re: [sidr] Terry Manderson's No Objection on draft-ietf-sidr-bgpsec-ops-14: (with COMMENT)

[Randy Bush]

> Just one nit: RFC6490 was obsoleted by rfc7730.

-16 pushed with fix

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

[sidr] I-D Action: draft-ietf-sidr-bgpsec-ops-16.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-16.txt
Pages   : 9
Date: 2017-01-05

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-16

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


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] Terry Manderson's No Objection on draft-ietf-sidr-bgpsec-ops-14: (with COMMENT)

[Alvaro Retana (aretana)]

Randy:

Just one nit: RFC6490 was obsoleted by rfc7730.

Sorry I didn’t catch this earlier.  I think this is the last change needed, so 
I’ll take care of it with a note to the RFC Editor.

Thanks!

Alvaro.


On 1/4/17, 11:06 PM, "iesg on behalf of Randy Bush" 
mailto:iesg-boun...@ietf.org> on behalf of 
ra...@psg.com> wrote:

"The considerations for RPKI objects (Certificates, Certificate
Revocation Lists (CRLs), manifests, Ghostbusters Records [RFC6481]),
Trust Anchor Locators (TALs) [RFC6490], cache behaviours of
synchronisation and validation from the section on RPKI Distribution
and Maintenance of [RFC7115] apply. Specific considerations relating
to ROA objects do not apply to this document"

done.  one can tell you hang out with lawyers who are paid by the word.
it says the exact same think with six times as many words.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-21.txt

[Sean Turner]

This version incorporates the things I missed in the GENART review (thank Jari).

spt

> On Jan 5, 2017, at 08:02, internet-dra...@ietf.org wrote:
> 
> 
> 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   : A Profile for BGPsec Router Certificates, 
> Certificate Revocation Lists, and Certification Requests
>Authors : Mark Reynolds
>  Sean Turner
>  Stephen Kent
>   Filename: draft-ietf-sidr-bgpsec-pki-profiles-21.txt
>   Pages   : 12
>   Date: 2017-01-05
> 
> Abstract:
>   This document defines a standard profile for X.509 certificates used
>   to enable validation of Autonomous System (AS) paths in the Border
>   Gateway Protocol (BGP), as part of an extension to that protocol
>   known as BGPsec.  BGP is the standard for inter-domain routing in the
>   Internet; it is the "glue" that holds the Internet together. BGPsec
>   is being developed as one component of a solution that addresses the
>   requirement to provide security for BGP.  The goal of BGPsec is to
>   provide full AS path validation based on the use of strong
>   cryptographic primitives.  The end-entity (EE) certificates specified
>   by this profile are issued to routers within an Autonomous System.
>   Each of these certificates is issued under a Resource Public Key
>   Infrastructure (RPKI) Certification Authority (CA) certificate.
>   These CA certificates and EE certificates both contain the AS
>   Identifier Delegation extension.  An EE certificate of this type
>   asserts that the router(s) holding the corresponding private key are
>   authorized to emit secure route advertisements on behalf of the
>   AS(es) specified in the certificate.  This document also profiles the
>   format of certification requests, and specifies Relying Party (RP)
>   certificate path validation procedures for these EE certificates.
>   This document extends the RPKI; therefore, this documents updates the
>   RPKI Resource Certificates Profile (RFC 6487).
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-pki-profiles/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-pki-profiles-21
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-pki-profiles-21
> 
> 
> 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

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

[sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-21.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   : A Profile for BGPsec Router Certificates, Certificate 
Revocation Lists, and Certification Requests
Authors : Mark Reynolds
  Sean Turner
  Stephen Kent
Filename: draft-ietf-sidr-bgpsec-pki-profiles-21.txt
Pages   : 12
Date: 2017-01-05

Abstract:
   This document defines a standard profile for X.509 certificates used
   to enable validation of Autonomous System (AS) paths in the Border
   Gateway Protocol (BGP), as part of an extension to that protocol
   known as BGPsec.  BGP is the standard for inter-domain routing in the
   Internet; it is the "glue" that holds the Internet together. BGPsec
   is being developed as one component of a solution that addresses the
   requirement to provide security for BGP.  The goal of BGPsec is to
   provide full AS path validation based on the use of strong
   cryptographic primitives.  The end-entity (EE) certificates specified
   by this profile are issued to routers within an Autonomous System.
   Each of these certificates is issued under a Resource Public Key
   Infrastructure (RPKI) Certification Authority (CA) certificate.
   These CA certificates and EE certificates both contain the AS
   Identifier Delegation extension.  An EE certificate of this type
   asserts that the router(s) holding the corresponding private key are
   authorized to emit secure route advertisements on behalf of the
   AS(es) specified in the certificate.  This document also profiles the
   format of certification requests, and specifies Relying Party (RP)
   certificate path validation procedures for these EE certificates.
   This document extends the RPKI; therefore, this documents updates the
   RPKI Resource Certificates Profile (RFC 6487).


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

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

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


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] Review of draft-ietf-sidr-bgpsec-ops-12

[Randy Bush]

> I think the document need an editorial review, a lot of text in
> passive language, for example third paragraph in section 1
> "BGPsec needs to be spoken only by an AS's eBGP speaking, AKA border,
> routers, and is designed so that it can be used to protect 
> announcements which are originated by resource constrained edge 
> routers." is written in passive language and it is also a long
> sentence.

-15 has

   BGPsec needs to be spoken only by an AS's eBGP-speaking border
   routers.  It is designed so that it can be used to protect
   announcements which are originated by resource constrained edge
   routers.  This has special operational considerations, see Section 6.

from wikipedia, the authority for everything :)

Use of the passive in English varies with writing style and field.
Some publications' style sheets discourage use of the passive
voice,[3] while others encourage it.[4] Although some purveyors of
usage advice, including George Orwell in Politics and the English
Language and William Strunk, Jr. and E. B. White in The Elements of
Style, discourage use of the passive in English, its usefulness is
generally recognized, particularly in cases where the patient is
more important than the agent,[5] but also in some cases where it is
desired to emphasize the agent.

randy

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

[sidr] I-D Action: draft-ietf-sidr-bgpsec-ops-15.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-15.txt
Pages   : 9
Date: 2017-01-05

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-15

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


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

[sidr] Jari Arkko's No Objection on draft-ietf-sidr-as-migration-06: (with COMMENT)

[Jari Arkko]

Jari Arkko has entered the following ballot position for
draft-ietf-sidr-as-migration-06: 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-as-migration/



--
COMMENT:
--

Per Wassim Haddad's Gen-ART review (thanks!), there seems to be a word
missing here:

"Route Origin Validation as defined by RFC 6480 [RFC6480] does not
modification to enable AS migration, ..."


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

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

[Randy Bush]

thanks roni.  i wonder how i missed your message.  my bad.

>> I think the document need an editorial review, a lot of text in
>> passive language, for example

i confess it is my normal mode, despite being a strunk and white fan.
sometimes rfced agrees, sometimes not and fixes.  unless it is a real
problem, i think i will not chase this one.

randy

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

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

[Jari Arkko]

Dale, all,

Thanks for the review, re-review, and changes. I’m posting a No Objection 
position for this draft in today’s IESG telechat.

But:

> 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.

Is a good question.

> 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.

That would be clearer for me, assuming that is what was actually meant, of 
course :-)

> 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.

I think that’s right.

>   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/.

Right.

> 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.

OK

Jari



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

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

[Jari Arkko]

Thanks for your review, Roni.

> I think the document need an editorial review, a lot of text in
> passive language, for example

Authors — do take a note.

I am posting a No Objection vote on the document in today’s IESG telechat.

Jari



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Alexey Melnikov's Yes on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT)

[Alexey Melnikov]

> On 5 Jan 2017, at 03:19, Suresh Krishnan  wrote:
> 
>> On 01/04/2017 09:38 AM, Sean Turner wrote:
>> 
 On Jan 4, 2017, at 05:09, Randy Bush  wrote:
 
 +1 to the comment from Suresh about order. I though that something like
 what he proposed will minimize memcopies and possibly use of memory why
 hashing. So I am also curious to know answer to his question.
>>> 
>>> a vendor engineer actually implementing requested the change to the
>>> current syntax for ease of generating/parsing.
>>> 
>>> randy
>> 
>> I believe this is that thread that resulted in the final organization:
>> 
>> https://mailarchive.ietf.org/arch/msg/sidr/8B_e4CNxQCUKeZ_AUzsdnn2f5MU
> 
> Thanks for the pointer Sean. Very interesting.

Indeed! I wish a few words about design could be added to the draft.


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

Re: [sidr] Terry Manderson's No Objection on draft-ietf-sidr-bgpsec-ops-14: (with COMMENT)

[Terry Manderson]

Super, Thanks.

T.

On 5/01/2017, 2:06 PM, "iesg on behalf of Randy Bush"  wrote:

> "The considerations for RPKI objects (Certificates, Certificate
> Revocation Lists (CRLs), manifests, Ghostbusters Records [RFC6481]),
> Trust Anchor Locators (TALs) [RFC6490], cache behaviours of
> synchronisation and validation from the section on RPKI Distribution
> and Maintenance of [RFC7115] apply. Specific considerations relating
> to ROA objects do not apply to this document"

done.  one can tell you hang out with lawyers who are paid by the word.
it says the exact same think with six times as many words.

> This is surely early days of BGPsec adoption and use. I have personal
> opinions about how adoption will go and what will be learnt or
> discovered along the way. So I do share Stephen's observation about
> painting one's self into a corner.

we all have our worries.  but when a major rtgsec hits the wsj, at elast
we wil have a plan.

randy




smime.p7s
Description: S/MIME cryptographic signature
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr