[sidr] Jabber scribe + Notes Taker

[Chris Morrow]

Howdy folks, Before the meeting start :) Are there folk willing to
volunteer 'now' for the event 'then'? :)

we'll need both before start.

-chris

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

[sidr] Jabber scribe + Notes Taker

[Chris Morrow]

Howdy folks, Before the meeting start :) Are there folk willing to
volunteer 'now' for the event 'then'? :)

we'll need both before start.

-chris

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

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

[Chris Morrow]

i think the plan is to shift the -ops document (this one) to the
sidrops group...I meant to ask about: "how do we do that?" I'll do
that in person tonight.

At Wed, 2 Nov 2016 15:35:18 +,
"Alvaro Retana (aretana)"  wrote:
> 
> Randy:
> 
> Hi!  Thanks for working on this document!
> 
> I have two issues I want to highlight upfront, and then some comments
> (below).  I would like to see these two issues addressed, along with
> the Major comments below, before moving the document forward.
> 
> These two upfront issues are probably more questions for the
> Chairs/Shepherd.
> 
> 1. Why is this document a BCP?  A BCP is a document that describes
>“the community's best current thinking…on what is believed to be
>the best way to perform some operations” [rfc2026].  This document
>meets that bar of the description, but there is clearly not a lot
>of practice behind the considerations – which I think is reflected
>in the lack of significant comments from the WG.  I would prefer if
>this document as Informational, pending some actual experience.
>But I’ll settle for a good explanation (to be also included in the
>Shepherd’s write-up) of why BCP.

i think the intent of this document is to write down (document) the
inteded 'best practices' for running bgpsec enabled networks.

viewed in that light, there aren't any of these things out there
today, but as a place to start looking and planning for deployment
operations folk (me) want some guidance on what thingsto expect/do/fix
as we roll out.

i think bcp fits for that... much like bcp 17. I have updated the
shepherds doc to reflect the above paragraph's intent/ideas.

> 2. This document, as a companion of draft-ietf-sidr-bgpsec-protocol,
>is the only place where Operational (or Management) Considerations
>are discussed.  However, important items recommended in RFC5706
>(Guidelines for Considering Operations and Management of New
>Protocols and Protocol Extensions), such as migration or fault
>management are not covered anywhere.  Given the tone and current

Ideally the migration is covered in the protocol document, I see it
only talk about as migrations (business events), which seems
ok.

Migrations of keys or algorithms are covered in other documents and
mentioned in this document. which migrations are you referring to?

>content of this document, I don’t think extending it is the way
>forward -- so, in my review of draft-ietf-sidr-bgpsec-protocol [1],
>I asked the authors to include an Operations and Management Section
>there and to consider using this document as the base.  Merging

I'm not sure I'd stick more into the protocol document though,
especially things which don't explicitly describe the protocol
itself. I think keeping the protocol description/design in one
document and the operations of the system in a seperate document isn't
unreasonable.

I expect the set of ops documents to change/evolve over time, I'd hate
to -bis the protocol for operational work later.

>this document into draft-ietf-sidr-bgpsec-protocol is an action
>that the WG/authors/Chairs/Shepherds should consider.  While that
>is my preferred solution, I will move forward with publication of
>this document if that is the consensus.
> 
> Thanks!
> 
> Alvaro.
> 
> [1]
> https://mailarchive.ietf.org/arch/msg/sidr/UOSfI4drrFvnO7271ivU3j9RFm4
> 
> 
> Major:
> M1. In Section 5, you wrote: “As they are not formally verifiable, an eBGP 
> listener SHOULD NOT strongly trust unsigned security markings such as 
> communities received across a trust boundary.”  After reading this piece of 
> text several times, I think I picked up on the subtle message: don’t trust 
> unsigned *security markings* -- vs what I got from the first n-1 readings: 
> don’t trust communities.  I think that this paragraph would greatly benefit 
> from more details or an example related to security markings.
> 
> M2. In Section 7. (Routing Policy): “As BGPsec will be rolled out over…a long 
> time.  Hence a normal operator's policy SHOULD NOT be overly strict, perhaps 
> preferring Valid paths and giving very low preference, but still using, Not 
> Valid paths.”  This recommendation concerns me because “Not Valid” talks 
> directly to the fact that the announcement is, well, not valid – vs just 
> unable to be verified (because there’s no BGPsec_Path  attribute, for 
> example).  The next sentence is a reflection of my concern: “Operators should 
> be aware that accepting Not Valid announcements…will often be the equivalent 
> of treating them as fully Valid.”  I-D.sidr-bgpsec-protocol suggests the same 
> thing (in 5.1, pointing to this document).  I am left with the question: why 
> validate at all if the BCP recommendation is to use all announcements no 
> matter the state?  I obviously realize that it is still early days – maybe it 
> is too early for a BCP document if the “practice” is not there yet…
> 
> M3. Also in 

Re: [sidr] AD Review of sidr-origin-validation-signaling-09

[Alvaro Retana (aretana)]

Either way is fine.  The document is scheduled for the Telechat on Dec/15. I 
expect maybe a couple of directorate reviews before that – if they come in by 
Dec/9 and you have time to pdate, then please do.  Otherwise, let’s wait for 
the IESG to comment.

Thanks!

Alvaro.

On 11/13/16, 4:25 PM, "Randy Bush" > wrote:

C1. The reference to rfc7607 should be Informative.
C2. [Major] Security Considerations.  I think that there is one
consideration that should be mentioned in this section: Given that the
largest value is preferred (2 = invalid), there is an attack vector
where a router in the path (yes, even an internal router) can inject a
community indicating that the route is invalid; the communities are
not protected.  This action could result in inconsistent routing or in
even a DoS.  I know the document is not explicit about what to do with
the validation state (which is ok), but the clear intention (from
rfc6811 and rfc7115) is that it will be used to make routing
decisions.  Please add some text about this potential issue.

would you prefer a revision soon, or wait for other iesg comments?

randhy

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

Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-16.txt

[Sean Turner]

This version addresses AD review comments.  Most were related to the wording in 
the IANA considerations section.

spt

> On Nov 14, 2016, at 07:21, 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   : BGPsec Algorithms, Key Formats, & Signature Formats
>Author  : Sean Turner
>   Filename: draft-ietf-sidr-bgpsec-algs-16.txt
>   Pages   : 7
>   Date: 2016-11-13
> 
> Abstract:
>   This document specifies the algorithms, algorithm parameters,
>   asymmetric key formats, asymmetric key size and signature format used
>   in BGPsec (Border Gateway Protocol Security).  This document updates
>   the Profile for Algorithms and Key Sizes for Use in the Resource
>   Public Key Infrastructure (RFC 7935).
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs-16
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-algs-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 mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

[sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-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 Algorithms, Key Formats, & Signature Formats
Author  : Sean Turner
Filename: draft-ietf-sidr-bgpsec-algs-16.txt
Pages   : 7
Date: 2016-11-13

Abstract:
   This document specifies the algorithms, algorithm parameters,
   asymmetric key formats, asymmetric key size and signature format used
   in BGPsec (Border Gateway Protocol Security).  This document updates
   the Profile for Algorithms and Key Sizes for Use in the Resource
   Public Key Infrastructure (RFC 7935).


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

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

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-algs-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] Last Call: (BGP Prefix Origin Validation State Extended Community) to Proposed Standard

[The IESG]

The IESG has received a request from the Secure Inter-Domain Routing WG
(sidr) to consider the following document:
- 'BGP Prefix Origin Validation State Extended Community'
   as Proposed
Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
i...@ietf.org mailing lists by 2016-12-07. Exceptionally, comments may be
sent to i...@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   This document defines a new BGP opaque extended community to carry
   the origination AS validation state inside an autonomous system.
   IBGP speakers that receive this validation state can configure local
   policies allowing it to influence their decision process.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sidr-origin-validation-signaling/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-sidr-origin-validation-signaling/ballot/


No IPR declarations have been submitted directly on this I-D.




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