Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-overview ENDING: 10/21/2015)

[Sandra Murphy]

On Oct 7, 2015, at 5:24 PM, Sean Turner  wrote:

> We’ll need to figure out what to do about the I-D.sidr-as-migration reference 
> it’s in the “IESG Dead” state.

Thanks for the heads up, we’ll investigate with the AD.

—Sandy, speaking as wg co-chair

> 
> I guess s3.2 is going to match whatever updates are made to 
> bgpsec-protocol-14.

> 
> spt
> 
> On Oct 07, 2015, at 11:32, Chris Morrow  wrote:
> 
>> 
>> Howdy WG folks,
>> Please consider this your warning/notice that the WGLC has been started for:
>> 
>> draft-ietf-sidr-bgpsec-overview
>> 
>> Abstract:
>> "This document provides an overview of a security extension to the
>>  Border Gateway Protocol (BGP) referred to as BGPsec.  BGPsec improves
>>  security for BGP routing."
>> 
>> Please give this a read, send comments if there are any, and let us
>> know if this is prepared for publication request.
>> 
>> Thanks!
>> 
>> -chris
>> co-chair
>> 
>> ___
>> 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



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

Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-overview ENDING: 10/21/2015)

[Sandra Murphy]

Speaking as regular ol’ member
On Oct 7, 2015, at 5:24 PM, Sean Turner  wrote:

> We’ll need to figure out what to do about the I-D.sidr-as-migration reference 
> it’s in the “IESG Dead” state.
> 
> I guess s3.2 is going to match whatever updates are made to 
> bgpsec-protocol-14.
> 

Looking at that section, I think it matches the planned updates to the bgpsec 
protocol.

Ironically, I think it matches the planned updates more directly than it 
matches the current state of the bgpsec protocol, depending on how you read the 
exact wording.

 .  BGPsec_Path contains 3 signatures :
  o  Signature from AS 1 protecting

 192.0.2/24, AS 1 and AS 2

This will still be true in the updates, no problem.

  o  Signature from AS 2 protecting

 Everything AS 1's signature protected, and AS 3

Right now, the bgpsec protocol’s signature from AS 2 covers the signature from 
AS 1, not “Everything AS 1’s signature protected”.  Of course, by induction, 
that protects “Everything AS 1’s signature protected”.  So not wrong, just 
indirectly true.

The intent as I understand it of the updates to the bgpsec protocol are to make 
the signature from AS 2 cover and directly protect “Everything AS 1’s signature 
protected”.

IMHO.  You are an author, so…..

—Sandy, speaking as regular ol’ member


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

Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-overview ENDING: 10/21/2015)

[Sandra Murphy]

On Oct 8, 2015, at 5:14 AM, Sandra Murphy  wrote:

> 
> On Oct 7, 2015, at 5:24 PM, Sean Turner  wrote:
> 
>> We’ll need to figure out what to do about the I-D.sidr-as-migration 
>> reference it’s in the “IESG Dead” state.
> 
> Thanks for the heads up, we’ll investigate with the AD.

The answer from the AD is:

   The system changed it to Dead from "AD is Watching" when the draft expired.

   In any case, all "Dead" means is that the IESG is not tracking the document, 
not that we're in fact killing it.


—Sandy


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

Re: [sidr] preventing SKI collisions

[Rob Austein]

At Wed, 7 Oct 2015 09:22:40 -0400, Sean Turner wrote:
> 
> On Oct 06, 2015, at 08:30, Sandra Murphy  wrote:
>> On Oct 5, 2015, at 4:36 PM, David Mandelberg  wrote:
>>>
>>> 4. Add text warning relying parties to detect malicious CAs that
>>> cause too many KI collisions, and blacklist those CAs. Similarly,
>>> warn routers and/or rpki-rtr caches to detect AS numbers with too
>>> many public keys sharing the same SKI, and blacklist those AS
>>> numbers.
>> 
>> I?m ok with ?warn?, but ?blacklist? is a bit strong for me.  If you
>> mean stop using that CA, i.e. remove all objects produced by that
>> CA, then the whole tree under that CA would fall off the planet.  I
>> think that?s a potentially large cone of consequence and I believe
>> it should be undertaken by brains, not code.
>> 
>> I?d prefer a warning in the security considerations section and a
>> recommendation to alert the operator.
> 
> Yep let?s just put a warning in the security considerations and
> alert the operator.

Agreed.  "Blacklist" sounds too much like mandatory policy.
My RP, who are you to decide how much of its CPU time I should waste?

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

Re: [sidr] draft-ietf-sidr-rfc6490-bis-04 - " Revised I-D Needed "

[Geoff Huston]

> On 5 Oct 2015, at 2:03 PM, Sandra Murphy  wrote:
> 
> The draft draft-ietf-sidr-rfc6490-bis-04 was approved by the IESG, provided 
> the comments received during IETF Last Call were addressed.
> 
> The IETF Last Call comments were noted to the sidr list in 
> http://www.ietf.org/mail-archive/web/sidr/current/msg07208.html.
> 
> As wg co-chair, I am satisfied that wg has consensus is to adopt “Option #2” 
> [ (allow but do not mandate line breaks)] as mentioned in the message that 
> brought up the problem 
> [http://www.ietf.org/mail-archive/web/sidr/current/msg07164.html].
> 
> The draft authors are requested to submit a revised version of the draft 
> including this response.   That would get the draft to publication.
> 
> In the initial message, the following text was suggested.  The draft authors 
> may use this as they wish.
> 
> 2. Permit but don't require newlines.  For example, change Section 2.1
>  item #3 from:
> 
>3)  a subjectPublicKeyInfo [RFC5280] in DER format [X.509],
>encoded in Base64 (see Section 4 of [RFC4648].
> 
>  to:
> 
>3)  a subjectPublicKeyInfo [RFC5280] in DER format [X.509],
>encoded in Base64 (see Section 4 of [RFC4648]).  To avoid
>long lines,  or  line breaks MAY be inserted into
>the Base64 encoded string.
> 
> —Sandy, speaking as co-chair


Sorry for the delay - it slipped off the desk and the dog ate it.

Here’s the revised id with that vitally critical sentence added.


A new version of I-D, draft-ietf-sidr-rfc6490-bis-05.txt
has been successfully submitted by Geoff Huston and posted to the
IETF repository.

Name:   draft-ietf-sidr-rfc6490-bis
Revision:   05
Title:  Resource Public Key Infrastructure (RPKI) Trust Anchor Locator
Document date:  2015-10-08
Group:  sidr
Pages:  9
URL:
https://www.ietf.org/internet-drafts/draft-ietf-sidr-rfc6490-bis-05.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6490-bis/
Htmlized:   https://tools.ietf.org/html/draft-ietf-sidr-rfc6490-bis-05
Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rfc6490-bis-05

Abstract:
  This document defines a Trust Anchor Locator (TAL) for the Resource
  Public Key Infrastructure (RPKI).  This document obsoletes RFC6490 by
  adding support for multiple URIs in a TAL.




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.

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

Re: [sidr] comments on draft-ymbk-sidr-transfer-01???

[Stephen Kent]

Sandy,

I provided detailed comments on this document on June 2.

Randy later said he didn't see them, so I resent (just to Randy) on July 7.

Steve





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

[sidr] I-D Action: draft-ietf-sidr-rfc6490-bis-05.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 Working Group of 
the IETF.

Title   : Resource Public Key Infrastructure (RPKI) Trust 
Anchor Locator
Authors : Geoff Huston
  Samuel Weiler
  George Michaelson
  Stephen Kent
Filename: draft-ietf-sidr-rfc6490-bis-05.txt
Pages   : 9
Date: 2015-10-08

Abstract:
   This document defines a Trust Anchor Locator (TAL) for the Resource
   Public Key Infrastructure (RPKI).  This document obsoletes RFC6490 by
   adding support for multiple URIs in a TAL.


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-sidr-rfc6490-bis-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rfc6490-bis-05


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] comments on draft-ymbk-sidr-transfer-01???

[Sandra Murphy]

The draft draft-ietf-sidr-rpki-validation-reconsidered speaks forcefully of the 
potential for damage if a certificate over claims, i.e., claims more resources 
than its parent.  The draft discusses how that could result from a failure of 
timing in a transfer of resources.

In a presentation in the November 2014 IETF session on this topic, it was 
suggested that discussion of "a standard procedure for certificate management 
during resource transfer” and "current CA operational procedures for managing 
transfers” would help in the reconsideration of the validation algorithm.

A draft was submitted and discussed at the last meeting.  
https://tools.ietf.org/html/draft-ymbk-sidr-transfer  But no comments have been 
received.

This is an important topic, folks, and deserves our attention.

Please do read the draft and comment.

—Sandy


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