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

[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

[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

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