[sidr] I-D Action: draft-ietf-sidr-adverse-actions-04.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   : Adverse Actions by a Certification Authority (CA) or 
Repository Manager in the Resource Public Key Infrastructure (RPKI)
Authors : Stephen Kent
  Di Ma
Filename: draft-ietf-sidr-adverse-actions-04.txt
Pages   : 25
Date: 2017-01-12

Abstract:
   This document analyzes actions by or against a CA or independent
   repository manager in the RPKI that can adversely affect the Internet
   Number Resources (INRs) associated with that CA or its subordinate
   CAs.  The analysis is done from the perspective of an affected INR
   holder.  The analysis is based on examination of the data items in
   the RPKI repository, as controlled by a CA (or independent repository
   manager) and fetched by Relying Parties (RPs).  The analysis does not
   purport to be comprehensive; it does represent an orderly way to
   analyze a number of ways that errors by or attacks against a CA or
   repository manager can affect the RPKI and routing decisions based on
   RPKI data.


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-sidr-adverse-actions-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-adverse-actions-04


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] IPv4 examples for draft-ietf-sidr-bgpsec-pki-algs

[Sean Turner]

> On Jan 12, 2017, at 17:33, Randy Bush  wrote:
> 
> mornin' oliver,
> 
>> This most likely would set a bad example for others that might start
>> issuing certificates with “infinite” life spans.
> 
> 'zactly
> 
>> In this regards what about a Validity of 365 days within the
>> example. This seems feasible to me.
> 
>>> of course that leaves open what lifetime to recommend.  we're not
>>> gonna do oscp, but rather withdraw from the rpki.  so to keep from
>>> making too much bgp noise, let me toss out O(year) to start the
>>> discussion.
> 
> i can live with a year.  i will be interested if others comment.
> 
> i have a vague memory of talking about this before.  one needs to deploy
> the replacement key in advance, as it can take some time to propagate to
> the far corners of the internet.  and one probably does not want to
> reannounce all one's routes at once.
> 
> a small i-d may be in order.

The CPS really dictates the validity period.  Can you check what your RIPE 
issued RPKI certificates have as a validity date?

You’re right that you need to get the replacement cert early to make sure you 
don’t end up being without a certificate.  RFC 6484 recommends 1 week prior to 
the expiration of the old cert.  I think the CPS also allows some addition time 
to account for this problem.

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

Re: [sidr] Spencer Dawkins' No Objection on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT)

[Randy Bush]

>>Note that BGPsec update messages can be quite large, therefore any
>>BGPsec speaker announcing the capability to receive BGPsec messages
>>SHOULD also announce support for the capability to receive BGP
>>extended messages [I-D.ietf-idr-bgp-extended-messages].
>> 
>> isn't a MUST, but Section 7 explains this 
>> 
>>In Section 2.2, is was stated that a BGPsec speaker SHOULD announce
>>support for the capability to receive BGP extended messages.  Lack of
>>negotiation of this capability is not expected to pose a problem in
>>the early years of BGPsec deployment.  However, as BGPsec is deployed
>>more and more, the BGPsec update messages would grow in size and some
>>messages may be dropped due to their size exceeding the current 4K
>>bytes limit.  Therefore, it is strongly RECOMMENDED that all BGPsec
>>speakers negotiate the extended message capability within a
>>reasonable period of time after initial deployment of BGPsec.

how about just saying

   A router announcing the capability to send or to receive BGPsec
   updates MUST also announce the capability to send and receive BGP
   extended messages [I-D.ietf-idr-bgp-extended-messages].

and call it a day?

randy

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

Re: [sidr] Spencer Dawkins' No Objection on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT)

[Sriram, Kotikalapudi (Fed)]

Hi Spencer,

Please see my comments inline below marked with [Sriram].
I have made changes in the document in response to your comments. 
You’ll see them in version-22 (to be uploaded in the next few days). 

>Perhaps I'm just having a good day, but this is 
>one of the clearest BGP-related specifications 
>I can remember reviewing. Thanks for that, 
>and especially for the background on design decisions.

[Sriram] Very kind of you. Thank you.

> 
> I did have questions on two points 
>(which are spread across multiple sections).
> 
> I started out wondering why
> 
>Note that BGPsec update messages can be quite large, therefore any
>BGPsec speaker announcing the capability to receive BGPsec messages
>SHOULD also announce support for the capability to receive BGP
>extended messages [I-D.ietf-idr-bgp-extended-messages].
> 
> isn't a MUST, but Section 7 explains this 
> 
>In Section 2.2, is was stated that a BGPsec speaker SHOULD announce
>support for the capability to receive BGP extended messages.  Lack of
>negotiation of this capability is not expected to pose a problem in
>the early years of BGPsec deployment.  However, as BGPsec is deployed
>more and more, the BGPsec update messages would grow in size and some
>messages may be dropped due to their size exceeding the current 4K
>bytes limit.  Therefore, it is strongly RECOMMENDED that all BGPsec
>speakers negotiate the extended message capability within a
>reasonable period of time after initial deployment of BGPsec.
> 
> Perhaps that's worth a forward pointer? 
>(or maybe even dragging this paragraph forward from Section 7)

[Sriram] I have put in a forward pointer in Section 2.2.
It reads, “Please see related operational guidance in Section 7.” 

> 
> I'm looking at 
> 
>BGPsec speakers SHOULD drop
>incoming update messages with pCount set to zero in cases where the
>BGPsec speaker does not expect its peer to set pCount to zero. 
> (That
>is, pCount is only to be set to zero in cases such as route servers
>or AS Number Migration where the BGPsec speaker's peer expects pCount
>to be set to zero.)
> 
> and wondering why that's not a MUST.  If I'm understanding this 
>correctly (which is theoretically possible), the BGPsec speaker 
>is telling its peer that it's not participating as a transit AS, 
>but the peer thinks it should be. Is there anything intelligent 
>that the peer can do with the update?

[Sriram] You are absolutely right: MUST makes sense. Because later in 
Section 5.2 check list, we say: 

   7.  If the update message was received from a peer that is not
   expected to set pCount equal to zero (see Section 4.2 and
   Section 4.3) then check to ensure that the pCount field in the
   most-recently added Secure_Path Segment is not equal to zero.
   (See router configuration guidance related to this in Section 7.)

[Sriram] In Section 5.2, we also say: 

   If any of these checks fail, it is an error in the BGPsec_Path
   attribute.  

[Sriram] Since the receiver action is clearly stated in Section 5.2, 
I have dropped the two sentences you cited beginning with 
“BGPsec speakers SHOULD drop incoming update 
messages with pCount set to zero…”
from Section 4.2 which is all about sender actions.
That particular paragraph now reads:

   A route server that participates in the BGP control plane, but does
   not act as a transit AS in the data plane, may choose to set pCount
   to 0.  This option enables the route server to participate in BGPsec
   and obtain the associated security guarantees without increasing the
   length of the AS path.  (Note that BGPsec speakers compute the length
   of the AS path by summing the pCount values in the BGPsec_Path
   attribute, see Section 5.)  However, when a route server sets the
   pCount value to 0, it still inserts its AS number into the
   Secure_Path Segment, as this information is needed to validate the
   signature added by the route server.  See
   [I-D.ietf-sidr-as-migration] for a discussion of setting pCount to 0
   to facilitate AS Number Migration.  Also see Section 4.3 for the use
   of pCount=0 in the context of an AS confederation.  See Section 7 for
   operational guidance for configuring a BGPsec router for setting
   pCount=0 and/or accepting pCount=0 from a peer.

> 
> Section 7 refers to this SHOULD, while adding a few more SHOULDs. 
> 
>A peer that is an Internet Exchange Point (IXP) (i.e.  Route Server)
>with a transparent AS is expected to set pCount = 0 in its
>Secure_Path Segment while forwarding an update to a peer (see
>Section 4.2).  Clearly, such an IXP SHOULD configure itself to set
>its own pCount = 0.  As stated in Section 4.2, "BGPsec speakers
>SHOULD drop incoming update messages with pCount set to zero in cases
>where the BGPsec speaker does not expect its peer to set pCount to
>zero."  This means that a BGPsec speaker SHOULD be configured so that
>