Re: [sidr] Kathleen Moriarty's Discuss on draft-ietf-sidr-as-migration-05: (with DISCUSS)

[George, Wes]

On 5/3/16, 6:30 AM, "Stephen Farrell"  wrote:

>
>Hi Wes,
>
>This is only a timing problem if bgpsec doesn't change in some
>incompatible manner. If such a change happens then this is more
>than a timing issue.
>What'd be bad about just holding this in the WG until bgpsec is
>ready? Since there's a normative reference anyway getting the
>IESG to approve both at once seems like it'd be better.

WG] Well, I don't think the BGPSec protocol draft is really far enough
behind that holding this one would make much difference in the outcome. My
co-author (and WG Chair) replied in another thread that the BGPSec doc is
past WGLC and waiting for chair publication request. The primary thing
outstanding is a discussion between the Routing ADs and WG as to whether
it will be experimental status or PS. If you have concerns, both drafts
are sufficiently complete that you could review both now, but I don't
expect major chances of the type you express concern about at this late
stage.
As primary author, I can say that I'd really like this to be off my plate
and in the RFC editor's queue, because given current job/merger
uncertainty, I can't be certain what my involvement with IETF will be in
the coming months. Completing approval on this one while it's in queue
also seems a better use of IESG cycles rather than re-cycling the draft
such that it has to be reviewed and discussed by IESG a second time, but I
defer to the WG and IESG as to how to proceed here.

Thanks,

Wes George

Anything below this line has been added by my company’s mail server, I
have no control over it.
---





This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Kathleen Moriarty's Discuss on draft-ietf-sidr-as-migration-05: (with DISCUSS)

[George, Wes]

On 5/2/16, 1:04 PM, "Kathleen Moriarty" 
wrote:


>
>--
>DISCUSS:
>--
>
>1.  Why is this document preceding the BGP spec?  Shouldn't this be part
>of the BGPSec protocol document?  If BGPSec isn't getting deployed
>because of the AS path migration problem and this gets us a little
>further, but not quite as secure, maybe that's a trade off we need to
>accept.  But this document coming through first is a little concerning
>even though the protocol spec is a normative reference.

WG] This is largely a timing problem. The protocol draft was written
first, but after this issue was identified, AS-migration was written, and
both drafts were revised and reviewed in parallel.
The WG discussed integrating AS-migration into the protocol spec, and
decided to keep it separate. At the time, this was due to several
dependencies and assumptions:
First, the WG consensus between SIDR, GROW, and RTGWG was that BGPSec
definitely needed to allow for AS-Migration, but before BGPSec could be
expected to support AS-Migration, those tools needed to be documented as a
formal part of the BGP protocol (in RTGWG), rather than just being de
facto standard on account of their being implemented by all major router
vendors and widely used by ISPs. That resulted in RFC 7705 (aka
idr-as-migration), also written largely in parallel with sidr-as-migration
(in fact they started as one document and were split).
Second, the BGPSec protocol document was thought to be much closer to
completion and publishing than either of these documents, and was expected
to be completed well prior to sidr-as-migration such that it didn't make
much sense to delay the protocol doc to integrate them.
In the meantime, the protocol document underwent additional reviews that
uncovered issues requiring more significant revision and delayed its
progress such that the as-migration document is now ready first. The
protocol document has had edits to ensure proper integration between the
two documents where appropriate (adding clarity via references and
language to ensure no conflict in what is being directed in each standard).
Last, part of the rationale for keeping them separate is that while the WG
strongly recommends that both parts be implemented, BGPSec does not
strictly require the additional support for AS-migration (I.e.
Implementing the functionality defined in BGPSec protocol document is a
MUST, AS-migration is a SHOULD), and thus having the documents be separate
makes a clear distinction between basic protocol function and add-on
features.

>
>
>2.  The introduction makes this sound rather innocuous, but the security
>considerations section is more explicit that this is a work around BGPSec
>and isn't quite as secure.  I'd like to see some text explaining this
>better in the introduction, more similar to what's in the first paragraph
>of the security considerations section.

WG] The intent was not to imply that BGPSec with AS-Migration support is
fundamentally less secure than BGPSec without it, so if that's what we're
conveying between the two sections, I'd appreciate additional guidance on
what specifically is giving you that impression. It's not really a
work-around BGPSec as much as it's observing that the BGPSec protocol as
written would break this common method for AS-Migration, and this document
addresses that gap by ensuring that it can be done within the security
framework provided by BGPSec.


Thanks,

Wes George


Anything below this line has been added by my company’s mail server, I
have no control over it.
---






This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] wglc for draft-ietf-sidr-bgpsec-15

[George, Wes]

Ship it.

Thanks,

Wes



On 3/17/16, 9:33 AM, "sidr on behalf of Sandra Murphy"
 wrote:

>This starts a two week wglc for draft-ietf-sidr-bgpsec-15.
>
>The draft is available at
>https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-15.
>
>Please respond with your opinion of the draft’s readiness for publication.
>
>Remember that positive replies are needed, so please do provide comments
>to the list.
>
>—Sandy, speaking as one of the wg co-chairs
>___
>sidr mailing list
>sidr@ietf.org
>https://www.ietf.org/mailman/listinfo/sidr




This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] I-D Action: draft-ietf-sidr-as-migration-04.txt

[George, Wes]

I believe that this draft is complete and ready to move forward. This
version addresses AD-review comments received at WGLC, so I think we're
just waiting for it to be resubmitted to IESG for IETF LC, as the changes
made were likely not substantive enough to require a new WGLC. I do *not*
need time to discuss this during the meeting either.

Thanks,

Wes




On 10/16/15, 11:53 AM, "sidr on behalf of 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 Working
>Group of the IETF.
>
>Title   : BGPSec Considerations for AS Migration
>Authors : Wesley George
>  Sandy Murphy
>Filename: draft-ietf-sidr-as-migration-04.txt
>Pages   : 15
>Date: 2015-10-16
>
>Abstract:
>   This document discusses considerations and methods for supporting and
>   securing a common method for AS-Migration within the BGPSec protocol.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-sidr-as-migration/
>
>There's also a htmlized version available at:
>https://tools.ietf.org/html/draft-ietf-sidr-as-migration-04
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-as-migration-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




This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

[sidr] as-migration nit in bgpsec-protocol-13

[George, Wes]

I just made another pass through sidr-as-migration and bgpsec-protocol-13
back to back to make sure that they are in sync, and I only found one
sentence in the security considerations (7.4) that probably needs to be
changed:

Current:
However, entities other than route servers could
   conceivably use this mechanism (set the pCount to zero) to attract
   traffic (by reducing the effective length of the AS-PATH)
   illegitimately.  This risk is largely mitigated if every BGPsec
   speaker drops incoming update messages that set pCount to zero but
   come from a peer that is not a route server.


Proposed:
... if every BGPsec
speaker drops incoming update messages that set pCount to zero unless
explicitly configured to accept them from a specific peer where pCount=0
messages are expected, such as a route server.

Thanks,

Wes


On 7/6/15, 7:21 PM, "sidr on behalf of 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 Working
>Group of the IETF.
>
>Title   : BGPsec Protocol Specification
>Author  : Matthew Lepinski
>Filename: draft-ietf-sidr-bgpsec-protocol-13.txt
>Pages   : 39
>Date: 2015-07-06
>
>Abstract:
>   This document describes BGPsec, an extension to the Border Gateway
>   Protocol (BGP) that provides security for the path of autonomous
>   systems through which a BGP update message passes.  BGPsec is
>   implemented via a new optional non-transitive BGP path attribute that
>   carries a digital signature produced by each autonomous system that
>   propagates the update message.
>
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/
>
>There's also a htmlized version available at:
>https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-13
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-protocol-13
>
>
>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




This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
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)

[George, Wes]

On 10/15/15, 7:02 AM, "Sandra Murphy"  wrote:

>Do you think the bgpsec-ops draft is the right place for that discussion?
>
>Sriram’s draft is an individual submission, not a wg draft.

WG] Well, I'm the wrong person to answer that question because I feel like
SIDR is especially bad about making the reader chase things across
multiple drafts in some mistaken attempt to make the individual documents
more concise. I had to go look at 3 or 4 documents (the BGPsec overview
intro references 8) in order to see if there was more info available
discussing this point that was confusing me, and from Sriram's response
it's clear that I missed at least one portion of that discussion in my
cursory search. I have read many of the documents in the past and should
have some familiarity with them that the average reader may not, so I
think this is indicative of a problem with our document organization, and
in how we decide what is relevant enough to be in the primary document vs
being pigeonholed in a separate one.

Sriram is always quite responsive to feedback, so I'm sure he'll address
some of the discussion in his draft. But given that at least this WG
draft, and possibly others are referencing Sriram's draft in lieu of
explaining things like this directly, is there any reason why we shouldn't
just adopt Sriram's draft? It seems to be representing previous consensus
within the WG on a significant number of major protocol design elements,
so the fact that it isn't a consensus document seems odd.

Wes




This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
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)

[George, Wes]

On 10/14/15, 7:20 PM, "Sriram, Kotikalapudi"
 wrote:

>>There is a discussion in 6.4 of Sriram's design-choices doc, but I think
>>it's incomplete
>>since it only discusses it in terms of it being unacceptable to sign
>>updates that it can't verify.
>
>"unacceptable to sign updates that it can't verify" -- I don't read that
>in Section 6.4.

WG] I interpreted it that way based on 6.4.2. More about that below.
>
>>Put differently: "I have no idea whether the people before Randy were
>>telling the truth, but I can assert that Randy, Sandy, Chris, Matt, and
>>Rob
>>all verifiably told the truth about their part of the path when they
>>sent the route to me." I think maybe that has some value in an
>>incremental model,
>>but if it doesn't (or is sufficiently difficult to implement as to
>>negate the potential benefit), we should explain why.
>
>The AS that you named Randy could be a bad actor,
>and may have changed the AS path segment before it
>(dropped some ASes, reduced AS prepends, etc.).
>Imagine Rob receives another update for the same NLRI that is completely
>unsigned,
>and it has a path via Wes, Chris, and Jeff.
>Let us say both updates pass origin validation.
>Should Rob trust the partially-singed update via Randy, Sandy, Chris, and
> Matt,
>or should he trust the completely unsigned latter update?
>If Rob gives priority to partially-signed path over completely unsigned
>path,
>there is potential for trouble (as in the example above).
>Then what is the use of partially signed updates?

WG] I understand that. I think you're missing the distinction I'm making
between the signed and unsigned parts of the update. In this partial-sign
mode, the way I expect it would work to be at all useful is that any
policy based on the trust of signed updates would only apply to the
portion that is signed, not the entire path. I can't see a blanket trust
of a partially signed route as a binary thing such that you could
automatically prefer partial sign over unsigned, and so your attack vector
is overly simplistic. The partial signing only matters if you care about
the actual data that is being protected inside the signed part. I might
not care that I can't explicitly verify that the AS path started at your
house, then went through Joe's Bait Shop and WISP before connecting to
Randy. But I might care that I can explicitly verify that it went from
Randy to Sandy to Chris to Matt without any unplanned excursions through
Alice or Bob.
As I said, the logic starts getting difficult from a route policy
perspective, but I was trying to point out that the existing text seems to
say that a partially signed update (one that originates unsigned and is
later signed from mid-path to end) is somehow implying a level of trust on
the unsigned portion that doesn't exist. I think the reality is that
partially signed updates would require some additional changes in the
protocol to make that useful, and a significant amount of additional logic
to make it work in policy-land, which may not be worth the effort, but
saying that we don't want to protect the BGPSec-capable part of the path
because we can't protect the preceding part of the path that isn't BGPSec
capable seems circular logic to me.

Wes




This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
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)

[George, Wes]

Gave this a review, and stumbled across an issue that may not necessarily
be gating to this draft, but should probably be addressed in some other
drafts.

Regarding this text in 4.2:
"Additionally, BGPsec requires that all BGPsec speakers will support
   4-byte AS Numbers [RFC6793]. This is because the co-existence
   strategy for 4-byte AS numbers and legacy 2-byte AS speakers that
   gives special meaning to AS 23456 is incompatible with the security
   the security properties that BGPsec seeks to provide."

Nit: "the security" appears to be duplicated.

Substantive: I had to think through this for a bit to make sure I
understood why this is true beyond the obvious problem of AS23456 not
being unique. I think we need some additional words explaining why, though
I am not sure if it belongs here, in the protocol draft, or in sriram's
design-choices doc (7.6 is very thin on explanation). I think that this is
a specific corner case for the more generic case of incremental
deployment, where a given path has some routers/ASNs that support BGPSec
and some that do not, and as far as I can tell, incremental deployment
isn't really discussed as a concept beyond the [non]negotiation of support
between peers.

When a BGPSec-capable router sends updates to a non-capable peer, it
strips the BGPSEC_Path attribute from any BGPSec-protected routes it is
propagating and announces a regular AS_PATH, and therefore any protection
beyond that point is lost.
Section 4.2 of the protocol doc says that if a BGPSec-capable router
receives updates from a non-BGPSec peer, it will not sign those updates
when propagating them to other BGPSec-capable peers. As a result, that
route's path will not be protected at all. However, I couldn't find that
particular set of interactions discussed in any of the documents in the
context of incremental deployment, and what it can and cannot do to
protect different route announcements.

In other words, BGPSec supports securing the path when:
- All routers end to end support BGPSec, which results in the entire path
being protected.
- The originating router and one or more contiguous routers (ASNs) in the
downstream path support BGPSec, but one or more routers before the route's
final destination do not support it. This results in the BGPSec signatures
being stripped and falling back to insecure mode beyond the last
contiguous BGPSec-capable router, but still provides partial protection
through the portion of the path that is BGPSec-capable. This is true even
when a gap of one or more BGPSec-incapable routers exists in the middle,
followed by additional BGPSec-capable routers, as only the first part will
be secured.

BGPSec does *not* support securing the path even partially when:
- The originating router and one or more routers in the downstream path do
not support BGPSec, but send the update to router(s) that do support
BGPSec.
I.e. There is no model in BGPSec for updates that have [unsigned AS_PATH
of one or more ASNs] + [Signed BGPSec_Path] of one or more additional ASNs
to at least secure the part of the path where BGPSec is supported.
So you can grow BGPSec's chain of protection from origin to "middle" and
gain some incremental benefit across the part of the path that supports
BGPSec, but you cannot grow BGPSec's chain of protection from "middle" to
end and gain the same incremental benefit, even in the case where only the
originating router doesn't support BGPSec but the rest of the path does. I
think I understand the reasons why we chose not to allow this case, but I
don't know that this is discussed anywhere in these terms. There is a
discussion in 6.4 of Sriram's design-choices doc, but I think it's
incomplete since it only discusses it in terms of it being unacceptable to
sign updates that it can't verify. IMO there's a difference between
signing an unsigned update and carrying unsigned updates alongside signed
ones so that it is clear which part of the path is rigorously protected vs
not. Put differently: "I have no idea whether the people before Randy were
telling the truth, but I can assert that Randy, Sandy, Chris, Matt, and
Rob all verifiably told the truth about their part of the path when they
sent the route to me." I think maybe that has some value in an incremental
model, but if it doesn't (or is sufficiently difficult to implement as to
negate the potential benefit), we should explain why.

Thanks,

Wes



On 10/7/15, 11:32 AM, "sidr on behalf of 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
>
>__

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

[George, Wes]

 On 10/8/15, 9:54 AM, "sidr on behalf of Sandra Murphy"
 wrote:



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

Oops. Now that I've (finally) gotten through the multiple significant
revisions necessary on the parent doc in IDR, and it sits in the RFC
editor's queue, I have some cycles to finish this one up. I'll work to get
an update before the posting cutoff for Yokohama, though I'm not sure we
need to discuss it during the meeting to get it moving forward again.
I'll also try to carve some time next before this document's WGLC ends to
review it with the as-migration draft in mind.

Thanks,

Wes





This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] New Version: draft-ietf-sidr-bgpsec-protocol-12

[George, Wes]

From: Matthew Lepinski 
mailto:mlepinski.i...@gmail.com>>
Date: Friday, July 24, 2015 at 1:31 AM
To: "George, Wes" mailto:wesley.geo...@twcable.com>>
Cc: "sidr@ietf.org<mailto:sidr@ietf.org>" mailto:sidr@ietf.org>>
Subject: Re: [sidr] New Version: draft-ietf-sidr-bgpsec-protocol-12

That being said, I agree with you that from the point of view of a 
denial-of-service prevention, that we should be recommending that 
implementations "Skip out" after a failed signature verification. When I read 
the text in "Step III" on page 29 within Section 5.2, I interpret that text as 
indicating that implementations should skip the remaining signatures once they 
get a failed signature verification. If you interpret that text differently, 
please let me know, but in my reading of the document, I understand the 5.2 
algorithm as saying implementations should "skip out" when a signature is bad.

WG] I agree with your interpretation. As Randy pointed out, this is probably a 
case of misinterpretation due to the fact that I'm not the target audience 
(implementers) and thus I missed something that would have been obvious to your 
target audience.

Thanks
Wes




This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] New Version: draft-ietf-sidr-bgpsec-protocol-12

[George, Wes]

Matt -

I finally got a chance to review the updates you put in for –12 and 13. It has 
addressed most of the concerns I raised. Only thing I see missing is this 
comment from my previous review.

Section 5.2 - elsewhere in the document (7.3), you note that validation
should stop when an invalid signature is found. However, I see no mention
of that in the actual validation algorithm. That seems like good practice
even if there isn't a long chain of signatures to validate.
Additionally, 7.1's text "Thus, a BGPsec speaker MUST completely validate
all BGPsec update messages received from external peers." seems to
conflict with this recommendation because it says "completely". I think
it's a wording problem, i.e. We're not saying you MUST validate the
*entire* update, but rather you must validate ALL updates that you
*receive* until you encounter an invalid signature within a given update,
in which case you can stop and move to the next update.


Thanks,

Wes


From: sidr mailto:sidr-boun...@ietf.org>> on behalf of 
Matthew Lepinski mailto:mlepinski.i...@gmail.com>>
Date: Monday, June 15, 2015 at 12:41 AM
To: "sidr@ietf.org" mailto:sidr@ietf.org>>
Subject: [sidr] New Version: draft-ietf-sidr-bgpsec-protocol-12

I have submitted a new version of the BGPsec protocol specification.

This version includes some minor fixes as well as all of the changes discussed 
at IETF 92. (Minutes can be found here -- 
http://www.ietf.org/proceedings/92/minutes/minutes-92-sidr) I believe that all 
open issues with this document have been addressed.

The only normative changes in the -12 version are the following:
-- BGPsec speakers MUST support the multi-protocol extension (RFC 4760)
-- BGPsec now signs the entire MP_REACH_NLRI attribute. (Recall that there was 
an error previously where the AFI was not protected under the signature)

I believe that this document is now ready to ship to the IESG. If you disagree, 
please let me know what still needs to be addressed.

- Matt Lepinski


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Review of draft-ietf-sidr-as-migration

[George, Wes]

More inline

Thanks,

Wes

From: "Alvaro Retana (aretana)" mailto:aret...@cisco.com>>
Date: Thursday, April 9, 2015 at 2:57 PM
To: "George, Wes" 
mailto:wesley.geo...@twcable.com>>, 
"sidr@ietf.org<mailto:sidr@ietf.org>" mailto:sidr@ietf.org>>
Cc: 
"draft-ietf-sidr-as-migrat...@tools.ietf.org<mailto:draft-ietf-sidr-as-migrat...@tools.ietf.org>"
 
mailto:draft-ietf-sidr-as-migrat...@tools.ietf.org>>
Subject: Re: Review of draft-ietf-sidr-as-migration

rfc2119 says, about the keywords: "MUST only be used where it is actually 
required for interoperation or to limit behavior which has potential for 
causing harm”.

While I completely agree that the transition shouldn’t take forever, the use 
that you’re proposing doesn’t have anything to do with interoperability, nor 
will taking longer than expected/usual actually causes harm from the 
specification point of view.  Yes, the operator will have to deal with a 
cumbersome configuration/deployment, but the knobs in this case are specified 
"to keep the additional complexity during the transition period to a minimum”.

To all this, how would you even determine if someone was not adhering to the 
recommendation?  Do you measure the time in days, weeks, months, years?   I’m 
sure that the transition timeframe is very dependent on the 
network/deployment/operations and probably many other things I haven’t even 
thought about.

WG] well, I'll be honest, the philosophy behind 2119 words isn't a hill I'm 
willing to die on. If it is for you, that's fine and I'll change it, but I've 
read plenty of IETF documents that are pretty liberal in their interpretation 
of harmful as justification for using normative words – it isn't limited simply 
to the protocol and unless we start explicitly prohibiting 2119 language 
outside of protocol specs, you're going to have this argument with a lot of 
people I think. As for enforcement, this isn't tied to an elapsed time, and I 
don't even really understand what enforcement means in this context – how does 
IETF enforce anything, especially outside of protocol interop?


I’m not sure if you’re agreeing with me or if you’re further justifying the use.

WG] justifying.

The section we’re talking about reads:

3.2.1.  Outbound announcements (PE-->CE)

   When PE1 is moved from AS64510 to AS64500, it will be provisioned
   with the appropriate keys for AS64500 to allow it to forward-sign
   routes using AS64500.  However, there is currently no guidance in the
   BGPSec protocol specification on whether or not the forward-signed
   ASN value MUST match the configured "remote-as" to validate properly.
   That is, if CE1's BGP session is configured as "remote-as 64510", the
   presence of "local-as 64510" on PE1 will ensure that there is no ASN
   mismatch on the BGP session itself, but if CE1 receives updates from
   its remote neighbor (PE1) forward-signed from AS64500, there is no
   guidance as to whether the BGPSec validator on CE1 still consider
   those valid by default.  RFC4271 [RFC4271] section 6.3 mentions this
   match between the ASN of the peer and the AS_PATH data, but it is
   listed as an optional validation, rather than a requirement.
   Assuming that this mismatch will be allowed by vendor implementations
   and using it as a means to solve this migration case is likely to be
   Problematic.

Sounds to me that you want BGPSec to say that the values MUST match, is that 
correct?

WG] No. In that section, I'm still reviewing the problem and options to solve 
the problem. The key is in the last sentence of what you quoted above.
In other words, in theory you might be able to get away with the first AS in 
the AS_PATH deviating from the configured remote_AS on some liberal 
implementations, but it's probably not valid to assume that all implementations 
will make this work, because the spec doesn't provide normative guidance saying 
that it MUST.


 1.  5.3  "While this is not prohibited by BGPSec 
[I-D.ietf-sidr-bgpsec-protocol], routers that receive updates from iBGP 
neighbors MUST NOT reject updates with new (valid) BGPSec attributes..”  Does 
this represent an update to BGPSec?  Are you implying that the iBGP receiver 
should check the validity of the attributes?  I know that at this point it is a 
little weird to update a draft (not an RFC), but the process should take care 
of the appropriate references. [Maybe the update is not needed based on the 
discussion in the WG today.]

WG] what this is saying is that BGPSec is currently silent on this, and making 
an update to clarify what the behavior needs to be. As to whether the updates 
need to be validated in iBGP, I'm not explicitly requiring that, as I think 
it's really more of an implementation detail.

Ok, so it is an update to BGPSec.  This is important beca

Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-rollover-03.txt

[George, Wes]

One question that comes up when reading this document. Now that we've
removed the dependency between Origin Validation and Path Validation but
are expecting them to run in parallel with some shared components, do we
need to discuss how BGPSec cert rollover interacts with Origin Validation
cert rollover, possibly giving hints to what a combined rollover process
looks like? Are we expecting that they should be done at the same time, or
that they should NOT be done at the same time, or does it just not matter?
For example, if it's better to have the rolls done separately, then
probably some guidance about the expiry times not lining up might be good.
It's conceivable that if you're doing an emergency roll on account of
compromised keys, you might be doing both at once, regardless of whether
it's a good idea normally, so I think we need to highlight any gotchas
that may be present. Maybe this belongs in the ops doc?

Thanks,

Wes



On 3/6/15, 7:43 PM, "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 Working
>Group of the IETF.
>
>Title   : BGPSEC Router Certificate Rollover
>Authors : Roque Gagliano
>  Keyur Patel
>  Brian Weis
>   Filename: draft-ietf-sidr-bgpsec-rollover-03.txt
>   Pages   : 15
>   Date: 2015-03-06
>
>Abstract:
>   BGPSEC will need to address the impact from regular and emergency
>   rollover processes for the BGPSEC End-Entity (EE) certificates that
>   will be performed by Certificate Authorities (CAs) participating at
>   the Resource Public Key Infrastructure (RPKI).  Rollovers of BGPSEC
>   EE certificates must be carefully managed in order to synchronize
>   distribution of router public keys and the usage of those pubic keys
>   by BGPSEC routers.  This document provides general recommendations
>   for that process, as well as describing reasons why the rollover of
>   BGPSEC EE certificates might be necssary.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-rollover/
>
>There's also a htmlized version available at:
>http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-rollover-03
>
>A diff from the previous version is available at:
>http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-rollover-03
>
>
>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


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Review of draft-ietf-sidr-as-migration

[George, Wes]

Added SIDR, responses below inline, which of course messed up your original 
numbering.
I haven't pushed the rev yet, as I'm waiting to make sure that I don't need to 
make additional changes based on the revision to the BGPSec protocol doc.

Thanks,

Wes

From: "Alvaro Retana (aretana)" mailto:aret...@cisco.com>>
Date: Monday, March 23, 2015 at 11:18 AM
To: "George, Wes" mailto:wesley.geo...@twcable.com>>
Cc: 
"draft-ietf-sidr-as-migrat...@tools.ietf.org<mailto:draft-ietf-sidr-as-migrat...@tools.ietf.org>"
 
mailto:draft-ietf-sidr-as-migrat...@tools.ietf.org>>
Subject: Review of draft-ietf-sidr-as-migration

Minor:

 1.  It would be nice to have some sort of road map in the Introduction.  
Indicating that Section 3 presents the problem, 4 the requirements and 5 the 
solution itself.  Even though section 5 in in fact named ‘Solution’ it is not 
clear, at least not to me what the order of the document is; when reading 
section 3 I kept wondering to myself “what about the solution?”.

WG] isn't this what the table of contents is for? This isn't a long enough 
document that it really needs an "agenda slide"

 1.  Section 3. s/SHOULD NOT/should not We can’t use rfc2119 language to 
mandate the behavior of an operator; in this case related to the amount of time 
the transition phase lasts.  I think you have made a good point about the need 
to not stay there forever, but have also said that the transition is not always 
under the control of the operator.

WG] I disagree with the blanket assertion that we can't normatively mandate the 
behavior of an operator in the context of a standard or BCP document, and I 
think that the guidance is correct here – operators SHOULD NOT stay in 
transition indefinitely. Should rather than must because we know that there are 
extenuating circumstances and acknowledging that we tried to keep it simple.

 1.  3.1   The text sort of circles around a couple of scenarios and it finally 
settles on “a new ROA SHOULD also be created that authorizes AS64500”.  
Shouldn’t it be a ‘MUST’?  In the same paragraph you make the point that the 
"validation check will fail unless a ROA is *also* available for AS64500”..  
I’m guessing that the ‘SHOULD’ is used in case there are routes which AS64500 
is not originating yet..but it is just confusing to me what exactly is intended.

WG] I changed it to MUST. Having an additional ROA isn't a big deal, and so 
even if those are all generated up front before migration starts for any 
prefixes, the right thing will happen.

 1.  3.2.1 s/MUST/must You’re making reference to something that is not 
specified in another document..

WG] right, I'm observing that the behavior is not normatively specified, hence 
the caps.

 1.  Section 5.  You lost me here (end of the second paragraph): “. . .the most 
appropriate place to implement this is on the local PE that still has eBGP 
sessions associated with AS64510 (using the transition knobs detailed in the 
companion draft).  Since that PE has been moved to AS64500, it is not possible 
for it to forward-sign AS64510 with pCount=0 . . .”  You first said that the PE 
has sessions associated with AS64510, but then said that it had moved to 
AS64500, what am I missing?  Maybe you’re referring to a specific session..

WG] what I mean is that it still has peers expecting it to be 64510. Replaced 
"sessions associated with" with "sessions with peers expecting to peer with"

 1.  5.3  "While this is not prohibited by BGPSec 
[I-D.ietf-sidr-bgpsec-protocol], routers that receive updates from iBGP 
neighbors MUST NOT reject updates with new (valid) BGPSec attributes..”  Does 
this represent an update to BGPSec?  Are you implying that the iBGP receiver 
should check the validity of the attributes?  I know that at this point it is a 
little weird to update a draft (not an RFC), but the process should take care 
of the appropriate references. [Maybe the update is not needed based on the 
discussion in the WG today.]

WG] what this is saying is that BGPSec is currently silent on this, and making 
an update to clarify what the behavior needs to be. As to whether the updates 
need to be validated in iBGP, I'm not explicitly requiring that, as I think 
it's really more of an implementation detail.

Nits:

 1.  Introduction.  Just a style preference:  get to the point faster.  Maybe 
something more direct like: “A method of managing an ASN migration not formally 
part of the BGP4 [RFC4271] protocol specification is described in 
[I-D.ietf-idr-as-migration].  Accordingly, it is necessary . . .”

WG] ack, some of that was a holdover from previous versions of the doc, cleaned 
it up

 1.  s/draft/document

WG] ack

 1.  Section 2.  s/Figure 1/Figures 1 and 2/BTW, it would be nice (even if 
they’re referenced) to paste a copy of the figures.

WG] what say you, SIDR folks?

 

Re: [sidr] WGLC for draft-ietf-sidr-rpki-rtr-rfc6810-bis-03

[George, Wes]

On 3/18/15, 11:10 PM, "David Mandelberg"  wrote:

>Are you suggesting comparison of all the data from each single cache as
>an atomic entity, or comparison of individual IPvX and Router Key PDUs?
>
>If the former, then I think that would work fine as long as a majority
>(or maybe even a plurality) of the caches has the exact same data. But
>what does the router do if this is not the case? If the caches all
>download from the RPKI at different times, then I would expect it to be
>common for no two caches to have the same data.
>
>If the latter, then the semantics depend heavily on exactly how the
>comparison is done. Lets say a CA simultaneously issues one ROA for {AS
>65536, 10.0.0.0/8} and another for {AS 65537, 10.0.0.0/8}. Some of the
>caches see the publication point before both ROAs are issued; some see
>the pub point after both ROAs are issued and published. Can you
>guarantee that the voting mechanism will always result in either both
>ROA payloads, or neither, being used? (If a router ends up using one but
>not the other, then a previously unknown route becomes invalid.)

WG] well, that is mainly why I brought up the concern. Voting comparisons
like this can be hard to do with this amount of data, so if it was our
intent to allow multiple full views, we need better guidance on how we
think it's most likely to actually work. I'm not sure we'd see enough
consistency between caches to benefit from atomic comparisons, so it may
be a matter of taking age and other things into account. Building or
adapting a voting algorithm seems like a lot of effort for what may well
be a corner case, but if we're going to allow retention of multiple
caches' data, we have to address the issue of how to handle disagreement
between caches. Unless perhaps this part of section 10 is just
poorly-worded and the intent was only ever to allow retention of other
cache's data to keep a quasi-complete view during a failover/resync, i.e.
As one entry is pulled from the new cache, its corresponding entries
[SHOULD/MUST] be purged from the other one(s), etc.


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] WGLC for draft-ietf-sidr-rpki-rtr-rfc6810-bis-03

[George, Wes]

nit:
If this is 6810bis, shouldn't it formally list 6810 in the
updates/obsoletes metadata?

Other comments:
Section 6 Expire interval - this seems out of step with the way that we've
done most things in RPKI, i.e. what to do with the information provided is
usually thought of as a matter of local policy. I realize that there is
increasing risk to keeping the data beyond the expiry time as it grows
more stale, but there isn't much justification for why this MUST NOT is
present. I think that perhaps the tradeoff between staleness and
everything failing back to unknown status is something that the operator
needs to weigh themselves. We could provide guidance that [MUST/SHOULD]
NOT keep data from a certain cache beyond expiry time *if* another cache
is available, but acknowledge that in some cases stale info may be more
desirable than nothing at all (unless that's not actually true and I'm
missing something...) This is discussed in the failover scenarios in the
bottom of section 10 (only keep data if you don't have a full set from
another cache) but figured I'd mention it in case we think there's some
tweaks necessary in the section 6 text.

Also -
Since we say in section 10 that it is permissible to hold data from
multiple caches, the doc appears to be missing guidance on what the router
side of RPKI-router should do in the case where there are multiple caches
that disagree with one another. It does say MUST NOT distinguish between
data sources when validating, but that may not cover this scenario. This
may be as simple as recommending that in the case where data from multiple
caches is held and specific entries conflict with one another, there
SHOULD be an odd number of caches so that there is basis for comparison to
determine which cache is out of sync or providing incorrect info. (i.e.
Have 3 so that you can go with the 2/3 that agree)

Thanks,

Wes


On 3/17/15, 4:07 AM, "Sandra Murphy"  wrote:

>A reminder to everyone that this wglc ends Mar 20.
>
>There have been a couple of detailed responses.  There should be more, in
>order to judge consensus to publish.
>
>--Sandy, speaking as one of the wg co-chairs and chief nag
>
>On Mar 6, 2015, at 4:22 AM, Sandra Murphy  wrote:
>
>> The authors of  The Resource Public Key Infrastructure (RPKI) to Router
>>Protocol believe that the work is ready for a working grow last call.
>>
>> This starts a last call for that draft.  You may find it at
>>https://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-rfc6810-bis-03.
>>
>> Please comment to the list whether you believe that this draft is ready
>>for publication.  The wglc will be two weeks, ending on Friday, March 20.
>>
>> --Sandy, speaking as one of the wg co-chairs
>


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] AD review and progressing draft-ietf-sidr-as-migration-02

[George, Wes]

I posed some questions about this in my WGLC review of bgpsec spec, but
haven't heard anything back. Current schedule has this being evaluated by
IESG prior to our next meeting. If we need to discuss during the meeting
in Dallas, we could certainly delay processing of the document. It has a
normative block on the bgpsec spec, so it's not like it's getting
published right away anyway.

Thanks,

Wes



On 2/6/15, 11:15 AM, "Randy Bush"  wrote:

>has the wg really looked at 5.2 and 5.3 with respect to how the ibgp
>hacks affect the bgpsec spec?
>
>randy


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] AD review and progressing draft-ietf-sidr-as-migration-02

[George, Wes]

I went ahead and pushed a revision that covers Alia's and Keyur's reviews.

Thanks,

Wes


From: , "George, Wes" 
mailto:wesley.geo...@twcable.com>>
Date: Tuesday, February 3, 2015 at 3:30 PM
To: Alia Atlas mailto:akat...@gmail.com>>, 
"draft-ietf-sidr-as-migrat...@tools.ietf.org<mailto:draft-ietf-sidr-as-migrat...@tools.ietf.org>"
 
mailto:draft-ietf-sidr-as-migrat...@tools.ietf.org>>,
 "sidr@ietf.org<mailto:sidr@ietf.org>" mailto:sidr@ietf.org>>
Subject: Re: AD review and progressing draft-ietf-sidr-as-migration-02
Resent-To: mailto:sa...@tislabs.com>>, "George, Wes" 
mailto:wesley.geo...@twcable.com>>

update: I added the following text at the end of section 5.3 to cover Alia's 
question about iBGP AS migration. Let me know whether this is acceptable:

Additionally, section 4 of draft-ietf-idr-as-migration discusses methods in 
which AS migrations can be completed for iBGP peers such that a session between 
two routers will be treated as iBGP even if the neighbor ASN is not the same 
ASN on each peer's global configuration. As far as BGPSec is concerned, this 
requires the same procedure as when the routers migrating are applying AS 
migration knobs to eBGP peers, but the router functioning as the "ASBR" between 
old and new ASN is different. In eBGP, the router being migrated has direct 
eBGP sessions to the old ASN and signs from old ASN to new with pCount=0 before 
passing the update along to additional routers in its global (new) ASN. In 
iBGP, the router being migrated is receiving updates (that may have originated 
either from eBGP neighbors or other iBGP neighbors) from its downstream 
neighbors in the old ASN, and MUST sign those updates from old ASN to new with 
pCount=0 before sending them on to other peers.

Thanks,

Wes


From: , "George, Wes" 
mailto:wesley.geo...@twcable.com>>
Date: Monday, February 2, 2015 at 1:38 PM
To: Alia Atlas mailto:akat...@gmail.com>>, 
"draft-ietf-sidr-as-migrat...@tools.ietf.org<mailto:draft-ietf-sidr-as-migrat...@tools.ietf.org>"
 
mailto:draft-ietf-sidr-as-migrat...@tools.ietf.org>>,
 "sidr@ietf.org<mailto:sidr@ietf.org>" mailto:sidr@ietf.org>>
Subject: Re: AD review and progressing draft-ietf-sidr-as-migration-02
Resent-To: mailto:sa...@tislabs.com>>, "George, Wes" 
mailto:wesley.geo...@twcable.com>>

Alia – thanks for the review. Consider this ACK for all comments except the 
ones below, inline with WG]
I have a –03 draft in the edit buffer, and will publish once the below is 
resolved.

Thanks,

Wes


From: Alia Atlas mailto:akat...@gmail.com>>
Date: Friday, January 30, 2015 at 3:50 PM
To: 
"draft-ietf-sidr-as-migrat...@tools.ietf.org<mailto:draft-ietf-sidr-as-migrat...@tools.ietf.org>"
 
mailto:draft-ietf-sidr-as-migrat...@tools.ietf.org>>,
 "sidr@ietf.org<mailto:sidr@ietf.org>" mailto:sidr@ietf.org>>
Subject: AD review and progressing draft-ietf-sidr-as-migration-02
Resent-To: mailto:sa...@tislabs.com>>, "George, Wes" 
mailto:wesley.geo...@twcable.com>>

a) Language around draft-ietf-idr-as-migration is more tentative than is 
appropriate
when that draft and this are going to be RFCs.  Please clean that up.

WG] other than removing the first paragraph of section 4 (done), and fixing the 
intro (removed de facto), were there other places that this needs to be 
addressed?


b) In Sec 3.1, it says

"If the route now shows up as originating
   from AS64500, any downstream peers' validation check will fail unless
   a ROA is *also* available for AS64500 as the origin ASN, meaning that
   there will be overlapping ROAs until all routers originating prefixes
   from AS64510 are migrated to AS64500."

I think the second AS64500 should be AS64510.

WG] no. This is saying that a ROA already exists for 64510, but needs to exist 
for 64500. The distinction the second half of that section is making is that in 
addition to generating a ROA for 65400 for any prefixes originated by the 
router being moved, because of replace-AS, you may have to generate ROAs for 
65400 for routes that are originating on routers still in 65410. If that 
explanation is any clearer, I can try to edit the text to reflect this.



e) In draft-ietf-idr-as-migration, the case of handling AS migration in iBGP 
sessions is also covered.  I assume that because it is iBGP sessions, there is 
no work to be done for BGPsec.  Could you please add a quick obvious statement 
to that effect?

WG] hmm. This solution was originally written before the iBGP stuff was added, 
and it didn't occur to me that it may need to be discussed here. Pitfalls of 
two largely parallel docs, I guess.
The iBGP AS migration discussed is basically just listening for open on either 
ASN, but otherwise treats the session as iBGP even 

Re: [sidr] AD review and progressing draft-ietf-sidr-as-migration-02

[George, Wes]

update: I added the following text at the end of section 5.3 to cover Alia's 
question about iBGP AS migration. Let me know whether this is acceptable:

Additionally, section 4 of draft-ietf-idr-as-migration discusses methods in 
which AS migrations can be completed for iBGP peers such that a session between 
two routers will be treated as iBGP even if the neighbor ASN is not the same 
ASN on each peer's global configuration. As far as BGPSec is concerned, this 
requires the same procedure as when the routers migrating are applying AS 
migration knobs to eBGP peers, but the router functioning as the "ASBR" between 
old and new ASN is different. In eBGP, the router being migrated has direct 
eBGP sessions to the old ASN and signs from old ASN to new with pCount=0 before 
passing the update along to additional routers in its global (new) ASN. In 
iBGP, the router being migrated is receiving updates (that may have originated 
either from eBGP neighbors or other iBGP neighbors) from its downstream 
neighbors in the old ASN, and MUST sign those updates from old ASN to new with 
pCount=0 before sending them on to other peers.

Thanks,

Wes


From: , "George, Wes" 
mailto:wesley.geo...@twcable.com>>
Date: Monday, February 2, 2015 at 1:38 PM
To: Alia Atlas mailto:akat...@gmail.com>>, 
"draft-ietf-sidr-as-migrat...@tools.ietf.org<mailto:draft-ietf-sidr-as-migrat...@tools.ietf.org>"
 
mailto:draft-ietf-sidr-as-migrat...@tools.ietf.org>>,
 "sidr@ietf.org<mailto:sidr@ietf.org>" mailto:sidr@ietf.org>>
Subject: Re: AD review and progressing draft-ietf-sidr-as-migration-02
Resent-To: mailto:sa...@tislabs.com>>, "George, Wes" 
mailto:wesley.geo...@twcable.com>>

Alia – thanks for the review. Consider this ACK for all comments except the 
ones below, inline with WG]
I have a –03 draft in the edit buffer, and will publish once the below is 
resolved.

Thanks,

Wes


From: Alia Atlas mailto:akat...@gmail.com>>
Date: Friday, January 30, 2015 at 3:50 PM
To: 
"draft-ietf-sidr-as-migrat...@tools.ietf.org<mailto:draft-ietf-sidr-as-migrat...@tools.ietf.org>"
 
mailto:draft-ietf-sidr-as-migrat...@tools.ietf.org>>,
 "sidr@ietf.org<mailto:sidr@ietf.org>" mailto:sidr@ietf.org>>
Subject: AD review and progressing draft-ietf-sidr-as-migration-02
Resent-To: mailto:sa...@tislabs.com>>, "George, Wes" 
mailto:wesley.geo...@twcable.com>>

a) Language around draft-ietf-idr-as-migration is more tentative than is 
appropriate
when that draft and this are going to be RFCs.  Please clean that up.

WG] other than removing the first paragraph of section 4 (done), and fixing the 
intro (removed de facto), were there other places that this needs to be 
addressed?


b) In Sec 3.1, it says

"If the route now shows up as originating
   from AS64500, any downstream peers' validation check will fail unless
   a ROA is *also* available for AS64500 as the origin ASN, meaning that
   there will be overlapping ROAs until all routers originating prefixes
   from AS64510 are migrated to AS64500."

I think the second AS64500 should be AS64510.

WG] no. This is saying that a ROA already exists for 64510, but needs to exist 
for 64500. The distinction the second half of that section is making is that in 
addition to generating a ROA for 65400 for any prefixes originated by the 
router being moved, because of replace-AS, you may have to generate ROAs for 
65400 for routes that are originating on routers still in 65410. If that 
explanation is any clearer, I can try to edit the text to reflect this.



e) In draft-ietf-idr-as-migration, the case of handling AS migration in iBGP 
sessions is also covered.  I assume that because it is iBGP sessions, there is 
no work to be done for BGPsec.  Could you please add a quick obvious statement 
to that effect?

WG] hmm. This solution was originally written before the iBGP stuff was added, 
and it didn't occur to me that it may need to be discussed here. Pitfalls of 
two largely parallel docs, I guess.
The iBGP AS migration discussed is basically just listening for open on either 
ASN, but otherwise treats the session as iBGP even if the ASN is not the same 
as the globally-configured one. Thus there are two ASNs involved, and this is 
mainly the same as AS migration with eBGP, in that the migrating router would 
need to have a pcount=0 from old ASN to New in order to hide that path in 
routes that are signed to the old ASN from downstream eBGP peers. The wrinkle 
is that instead of the migration point being on the edge router between its 
eBGP peers and its iBGP peers, the migration point is now one router upstream, 
between two iBGP peers (i.e. The router in the old ASN doesn't necessarily know 
to mask its global ASN with pcount=0, and so the router that is at the actual 
border between the two ASNs will have to do the

Re: [sidr] AD review and progressing draft-ietf-sidr-as-migration-02

[George, Wes]

Alia – thanks for the review. Consider this ACK for all comments except the 
ones below, inline with WG]
I have a –03 draft in the edit buffer, and will publish once the below is 
resolved.

Thanks,

Wes


From: Alia Atlas mailto:akat...@gmail.com>>
Date: Friday, January 30, 2015 at 3:50 PM
To: 
"draft-ietf-sidr-as-migrat...@tools.ietf.org<mailto:draft-ietf-sidr-as-migrat...@tools.ietf.org>"
 
mailto:draft-ietf-sidr-as-migrat...@tools.ietf.org>>,
 "sidr@ietf.org<mailto:sidr@ietf.org>" mailto:sidr@ietf.org>>
Subject: AD review and progressing draft-ietf-sidr-as-migration-02
Resent-To: mailto:sa...@tislabs.com>>, "George, Wes" 
mailto:wesley.geo...@twcable.com>>

a) Language around draft-ietf-idr-as-migration is more tentative than is 
appropriate
when that draft and this are going to be RFCs.  Please clean that up.

WG] other than removing the first paragraph of section 4 (done), and fixing the 
intro (removed de facto), were there other places that this needs to be 
addressed?


b) In Sec 3.1, it says

"If the route now shows up as originating
   from AS64500, any downstream peers' validation check will fail unless
   a ROA is *also* available for AS64500 as the origin ASN, meaning that
   there will be overlapping ROAs until all routers originating prefixes
   from AS64510 are migrated to AS64500."

I think the second AS64500 should be AS64510.

WG] no. This is saying that a ROA already exists for 64510, but needs to exist 
for 64500. The distinction the second half of that section is making is that in 
addition to generating a ROA for 65400 for any prefixes originated by the 
router being moved, because of replace-AS, you may have to generate ROAs for 
65400 for routes that are originating on routers still in 65410. If that 
explanation is any clearer, I can try to edit the text to reflect this.



e) In draft-ietf-idr-as-migration, the case of handling AS migration in iBGP 
sessions is also covered.  I assume that because it is iBGP sessions, there is 
no work to be done for BGPsec.  Could you please add a quick obvious statement 
to that effect?

WG] hmm. This solution was originally written before the iBGP stuff was added, 
and it didn't occur to me that it may need to be discussed here. Pitfalls of 
two largely parallel docs, I guess.
The iBGP AS migration discussed is basically just listening for open on either 
ASN, but otherwise treats the session as iBGP even if the ASN is not the same 
as the globally-configured one. Thus there are two ASNs involved, and this is 
mainly the same as AS migration with eBGP, in that the migrating router would 
need to have a pcount=0 from old ASN to New in order to hide that path in 
routes that are signed to the old ASN from downstream eBGP peers. The wrinkle 
is that instead of the migration point being on the edge router between its 
eBGP peers and its iBGP peers, the migration point is now one router upstream, 
between two iBGP peers (i.e. The router in the old ASN doesn't necessarily know 
to mask its global ASN with pcount=0, and so the router that is at the actual 
border between the two ASNs will have to do the pcount=0 trick to the "iBGP" 
updates it receives. I'll need to add some text in 5.3 to cover this case. Good 
catch.




This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11

[George, Wes]

Gave this another review. Other than what I identify below, I think that
this is ready to publish.

First, some comments specific to the interaction between this draft's
language and draft-ietf-sidr-as-migration:

Section 4 discusses behavior for iBGP speakers. It may be appropriate to
include another reference to the slightly different behavior defined in
sidr-as-migration (see sections 5.2 and 5.3).

Also, 4.1 says that AS_Path and BGPSec_Path are mutually exclusive (must
not send both, etc.) and section 4 says that routes originated to other
iBGP peers should omit BGPSec attributes. I don't think that this and
sidr-as-migration are in conflict, but I want to have another pair of eyes
looking at it to make sure that the recommendations for iBGP peers are in
sync. This includes if you think that the text in sidr-as-migration should
be updated for better clarity.

5.2 item 5- pcount=0 - again, want to make sure that the way that this is
treated in as-migration is not in conflict with this instruction. The idea
is that any AS-migration configuration should be local to the edge router
under migration, and not require configuration changes on every router in
the ASN pair (old + new), but since there is a signature from old_ASN to
New_ASN with Pcount=0 coming from an iBGP neighbor, this is a detail we
have to have right, whether it drives changes in your text or mine.


Note: after Keyur's review, I made some wording changes to section 5.2 of
as-migration, but it's still in my edit buffer, so the text in the current
version is replaced by:
5.2 "When a PE router receives an update from an eBGP neighbor that is
locally configured with AS-migration knobs (i.e. the opposite direction of
the previous route flow), it MUST generate a signature from the old
(local) ASN forward signing to the new (global) ASN with pCount=0. It is
not necessary to generate the second signature from the new (global) ASN
because the ASBR will generate that when it forward signs towards its eBGP
peers as defined in normal BGPSec operation. Note that a signature is not
normally added when a routing update is sent across an iBGP session. The
requirement to sign updates in iBGP represents a change to the normal
behavior for this specific AS-migration implementation only."

Now, some general comments:
Section 5: extreme circumstances...defer validation. Perhaps we should add
a recommendation that this behavior be visible (i.e. Log messages, visible
in bgp diagnostic information, etc.) While the circumstances that invoke
this behavior is a matter of local policy/implementation, I think it's
reasonable to add this recommendation to make sure that it's visible to
the operator when it is happening.

Section 5.2 - elsewhere in the document (7.3), you note that validation
should stop when an invalid signature is found. However, I see no mention
of that in the actual validation algorithm. That seems like good practice
even if there isn't a long chain of signatures to validate.
Additionally, 7.1's text "Thus, a BGPsec speaker MUST completely validate
all BGPsec update messages received from external peers." seems to
conflict with this recommendation because it says "completely". I think
it's a wording problem, i.e. We're not saying you MUST validate the
*entire* update, but rather you must validate ALL updates that you
*receive* until you encounter an invalid signature within a given update,
in which case you can stop and move to the next update.

Also, it may be appropriate to state that the application of local policy
on validation state may be dependent on the ASN, i.e. I may want to say
that I want to drop or depref invalid BGPSec routes but carve out a list
of exception ASNs where the policy is bypassed (or vice versa). This is
largely an implementation detail and probably better discussed in detail
in the ops considerations doc, but it may be important in the protocol doc
because it requires more info to be passed from the validation machinery
to the policy machinery - in other words, it can't just know that
somewhere in this update, there was an invalid signature, and thus the
update is invalid, it may need to know that the update is valid except for
the signature for ASN1701 in order to have granular enough policy control.

Section 6.1
"It is anticipated that, in the future mandatory, the algorithm suites
   document will be updated to specify a transition from the 'current'
   algorithm suite to a 'new' algorithm suite."

This sentence is pretty hard to parse, wasn't sure if it's a misplaced
word or just clunky.
"We anticipate that in the future, the mandatory algorithm suites
document..."?

Or if that was the intended word order, I think it says that we're
anticipating that the algorithm suites doc will be mandatory and that it
will be updated to transition to new suites. Let's be a little clearer -
we already know that the algorithm suites doc will be mandatory, so we
shouldn't really need to qualify this statement so much.



Thanks,

Wes 

Re: [sidr] wg adoption call for draft-tbruijnzeels-sidr-delta-protocol-03

[George, Wes]

As one of the folks that has been rather publicly poking at rsync's
limitations as one of the things blocking my deployment of RPKI, I
strongly support adoption of this document. I will participate in the
discussion.

Thanks,

Wes George



On 1/14/15, 3:38 PM, "Sandra Murphy"  wrote:

>The authors of draft-tbruijnzeels-sidr-delta-protocol-03 have requested
>working group adoption.
>
>A working group adoption call starts now and will end 14 days from now on
>28 January.
>
>Please respond to say whether you support adoption of this work as a
>working group work item AND whether you will participate in the
>discussion.
>
>Remember that working group consensus to adopt the work needs responses,
>not just absence of objection, so speak up.
>
>--Sandy, speaking as one of the wg co-chairs


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] New version : draft-ietf-sidr-bgpsec-protocol-10

[George, Wes]

On 11/17/14, 12:13 AM, "Randy Bush"  wrote:


>could you please describe how an attacker can send many long bgpsec
>paths?  how are these long paths signed?

Though I'm guessing it might be possible to try it as a replay attack
(grab a string of signed ASNs from the path of one or more routes that go
past you, then add them to another set of routes that doesn't already have
them), I was thinking the attacker likely has to have the ability to sign
those ASNs (they have the keys) so that they're valid, otherwise the route
just gets dropped.
It's not hard to get an ASN or 10. $Dayjob have 12 or 15 that I know
about, Comcast has 30+ ASNs, and plenty of hosting providers use an ASN
per location to avoid needing ways to connect islands of the same ASN
together. Normally they don't have routes that go through each ASN, but
spinning up BGP speaking VM instances on Quagga or similar to generate
routes to inject and sign from one ASN to another is not hard. In order to
avoid the protections that Origin Validation would provide, it's less
likely that this is going to be done at origin, but rather by an ASN that
is in the middle of the path.
I.e.  --  --  -- 
Bad upstream receives routes from its downstream, and adds the list of
ASNs it can sign for plus any churn it wants to induce, sends it to
upstream 3, which in this case would be the target of the attack, and if
it propagates the routes further, networks beyond it would also be
affected. Even if the added ASNs in the path have the result of
redirecting traffic to another candidate with a shorter AS Path, the route
update itself will propagate on and still eat CPU and memory on the
routers it transits, and maybe even be amplified as it gets duplicated to
be sent to the learning router's BGP peers. This attack is different from
the normal AS Path attacks BGPSec was designed to protect against, because
it's not necessarily trying to add a specific ASN to shift traffic to a
certain network, that's just a side-effect of the attempt to attack the
routers running BGPSec themselves.

I'm thinking of this in terms of worst-case scenario, where one builds a
nice long ASN path, then uses it to lengthen a few thousand routes as they
pass, and then churn them, either on the assumption that RFD isn't
configured, or keeping the churn on an individual route low enough to keep
from triggering the dampening, but churn lots of routes simultaneously.

I admit that this seems like a stretch since exploiting it requires access
to ASNs and keys and possibly compromising a router in the middle of a
network so that you can have a platform to launch the attack, but there is
also the possibility that the simple act of having a long string of valid
ASNs in the actual forwarding path could cause this, especially in
conjunction with churn, lots of route deaggregation, and misconfiguration
(route leaks) that has the net result of taking a long AS path and making
it longer. The key question as to how much of a problem this actually
might be is, "how long of an AS Path is too long in BGPSec?" or
alternately, "when does the product of number of signed routes and number
of ASNs per route start causing performance degradation during
validation?") I'm not sure we can know that at this point, because it'll
depend on a lot of things, so unless we can make some common-sense
inferences based on what we see in the routing table, we mainly have to
identify it as a potential problem.

Thanks,

Wes


Anything below this line has been added by my company’s mail server, I
have no control over it.
---








This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] New version : draft-ietf-sidr-bgpsec-protocol-10

[George, Wes]

Matt-

Per discussion during IDR/SIDR meeting Friday, there may need to be some
text in the security considerations around the attack vector of sending
many updates with long (but valid) AS_Paths, since the analysis Sriram
provided indicated a correlation between the length of the AS Path to be
validated and CPU impact or convergence time impact. Sounds like we don't
have a problem with long paths comprised of  multiple prepends because
Pcount means that there aren't multiple signatures, but validly signed
strings of unique ASNs could still trigger this problem, whether they are
generated accidentally or maliciously. We may also need to make the
observation that rapid route churn with these sorts of prefixes are likely
to make the impact even higher, such that it may be advisable to implement
route flap dampening to provide additional protection against route churn.


That said, I'm not sure that this is strictly a security considerations
addition, because we may need to make some suggestions in the design to
protect against these sorts of scaling problems.
I'm not sure if we can use analysis of existing routing table data to
identify an 80/20 threshold of the longest credible AS Path and put a
recommendation on a max_as_length value for the limit for protection
against this attack, or whether we cannot recommend a value, and have to
simply acknowledge that this is a problem and recommend that implementers
provide a knob for setting a limit on AS Path such that implementations
can intercept and drop long AS_Paths before the BGPSec machinery tries to
validate them. Perhaps both, i.e. A reasonable default limit that can be
raised or lowered if a user sees fit. Alternatively, we could suggest a
fall-back method whereby excessively long-path BGPSec updates are
deprioritized or throttled to avoid causing adverse performance impacts,
perhaps in conjunction with existing RFD implementations for routes that
are both long-path and churning.

I can try to contribute some text once the WG weighs in on what direction
they want to take to address this, but I wanted to at least get the
discussion started.

Thanks,

Wes George



On 10/27/14, 7:40 PM, "Matthew Lepinski"  wrote:

>Just posted the -10 revision of the document.
>
>The only normative change was to decouple BGPsec validation from
>Origin Validation. (This is a normative change to the validation
>algorithm in Section 5.) This is based on working group discussions at
>IETF 90 and confirmed on the list in September.
>
>Additionally, there were some text changes made, including a reference
>to the AS-Migration document (and an accompanying text change
>regarding pCount=0).
>
>I have a couple of improvements to the security considerations text
>that I wasn't able to fold into this version of the document.
>
>Other than improving the security considerations, I am not aware of
>any open issues in this particular document.
>
>- Matt Lepinski
>
>___
>sidr mailing list
>sidr@ietf.org
>https://www.ietf.org/mailman/listinfo/sidr


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] WGLC - draft-ietf-sidr-as-migration

[George, Wes]

On 9/29/14, 9:18 PM, "Randy Bush"  wrote:


>> 1. Figures 3 and 4 from the companion I-D draft-ietf-idr-as-migration
>>are referenced several times in this document. It would be easier
>>for the readers if those two figures are reproduced in this
>>document when they are first referenced.
>
>uh, having data in two places is a recipe for trouble.  this is why we
>do references.  i really don't like copy and paste between docs.  but
>perhaps i am alone in this.

WG] I agree, my preference is to leave the diagrams in the referenced
document, and assume that those reviewing can manage to have two parallel
windows open (one of the few places where IETF's self-imposed text-width
restrictions come in handy) or briefly commit the "high-quality" ASCII
diagrams to memory.

Sriram, I'll incorporate the rest of your feedback into my next version,
which will likely be posted either at IETF LC or due to directorate review.

Thanks for giving it another look

Wes


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt

[George, Wes]

On 8/11/14, 7:13 AM, "Carlos M. Martinez"  wrote:

>3- because we understand them

For small values of "we" and "understand"

;-)

Wes


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt

[George, Wes]

On 8/4/14, 5:47 PM, "Sandra Murphy"  wrote:

>An invalid ROA does not necessarily mean an invalid route.
>
>If there is no other covering ROA, then a BGP route for that prefix
>becomes unknown, as Terry pointed out.
>
>If there is another ROA which covers the same prefix, then a route may be
>invalid -- if no covering ROA authorizes the ASN that the invalidated ROA
>mentions.

WG] I'm once again bitten by an incomplete understanding of the way that
the PKI interacts with the routing side. Sigh. That makes more sense, but
since I have often volunteered to be "new guy who's not an RPKI expert"
thus serving as the canary in the coal mine for finding the hidden gotchas
like this, we have a very important detail here that may or may not be
properly covered in our existing documents.

I went poking through 6907, and it contains a useful definition for a
covering ROA that seems to imply that an invalid ROA could technically
still be considered a covering ROA, but for this:
"For all of the use cases in this document, it is assumed that RPKI
   objects (e.g., resource certificates, ROAs) validate in accordance
   with [RFC6487] and [RFC6480].  In other words, we assume that
   corrupted RPKI objects, if any, have been detected and eliminated."

So that text explicitly declares this case of invalid ROA and how to
handle it out of scope for the scenarios discussed.

Restating the combination of this text and your answer above, is it
accurate to say that invalid ROAs are removed before the RP ever gets to
the step where it checks to see if they are covering or matching, thus it
is impossible for an invalid ROA to invalidate a route? Is that required
by the standard, or simply an implementation convention that some or all
of the existing RP software follows?

I think that begs some further questions: Is there ever a case where we
*want* an invalid ROA to translate to an invalid route, or do we *always*
want to simply punt those from the system so that the routes they would
have covered are tested only against any remaining valid ROAs? Do we ever
see a need to treat an invalid ROA as a revoke? Is the behavior any
different if the ROA was previously valid and unexpired, and suddenly
becomes invalid vs if it was previously unknown and the first ROA that
shows up is invalid? I'm quite sure that diving into this will also
generate a bunch of unpleasant questions about tiebreaker behavior when
both valid and invalid ROAs match or cover prefixes, so it may be simpler
to just make it clear that this is the intended behavior, but I figured
I'd pose the questions since that's what we seem to be having a
fundamental misunderstanding about.

I think that there are probably still cases during a transfer where if you
get the order of operations wrong, in addition to the invalid ROA, you
will have a second valid covering ROA that might not match what's being
announced and thus a potentially invalid route. That's probably what needs
to be enumerated in the validation-reconsidered draft as the problem with
the biggest potential impact, even if it's secondary to the main failure
mode where a bunch of routes just go to unknown status and temporarily
lose the protection that origin validation is supposed to provide.

Thanks
Wes George


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt

[George, Wes]

Late to the discussion because I needed to have cycles to read and think
about this draft...


On 7/31/14, 4:03 PM, "Stephen Kent"  wrote:

>Terry has reminded us that, even if such accidents occur, the world does
>not end, at
>least wrt origin validation. Thus, for the current set of SIDR RFCs, the
>damage that
>would occur is not nearly so great as some have suggested; until the
>error is fixed (which
>one would presume would be fairly quickly), origin validation would
>treat the affected
>routes as no worse than they are treated today.

WG] Maybe I'm missing something, but I'm not sure I agree with this
characterization. This is probably true for routes that transition from
Valid to Unknown, but not if they are actually found to be Invalid, which
is what I understand would be the result of the problem discussed in this
draft - invalid certs = invalid routes. While policy is ultimately a local
matter, in 7115 we recommend dropping invalids due to the fact that it
isn't possible to depref any routes enough to ensure that they are never
used if they are more specific than a valid or unknown route with a
comparably higher local pref. Unless we're changing that guidance, "%
Network not in table" is worse than they'd be treated today.

Deploying SIDR OV is about risk vs reward, i.e. How much benefit do I gain
in terms of what outages (attack vectors) I'm protecting myself and my
customers against vs what risk the same parties incur for experiencing
other outages that only exist if I am deploying OV. The possibility of
routes being invalidated and dropped on account of a botched cert overlap
or migration puts this squarely on the wrong side of the risk/reward
balance.

Thanks

Wes George


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

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

[George, Wes]

From: Matthew Lepinski 
mailto:mlepinski.i...@gmail.com>>
Date: Friday, July 4, 2014 at 6:16 PM
To: "sidr@ietf.org" mailto:sidr@ietf.org>>
Subject: [sidr] New version draft-ietf-sidr-bgpsec-protocol

I submitted a new version of the bgpsec protocol document. This revision 
includes a fair number of editorial changes but does not include any normative 
changes.

Now that the BGPSEC requirements document is essentially done, I look forward 
to discussing the protocol document again in Toronto. In particular, between 
now and the Toronto meeting I will write up (and send to the list) a brief 
comparison between the requirements in the final version of the reqs draft and 
what we deliver in the protocol document.

The only open issue in the protocol document that I am aware of is the 
following:

[snip]

Matt -

One additional change I think is necessary is to add a reference to 
ietf-sidr-as-migration. This is effectively an extension of the BGPSec protocol 
that is contained in a separate document. If the BGPSec doc was already done, 
I'd most likely be using the metadata of as-migration to update RFC so that 
the link would exist from the BGPSec protocol doc in addition to the normative 
reference to -protocol from as–migration, but in the current form where it's 
trivial to update the -protocol draft, I think that should instead be 
accomplished by a forward reference, and then the two documents will simply be 
part of the group of interdependent docs that get released for BGPSec (assuming 
of course that -as–migration passes LC).

That said, my quick scan of –protocol didn't reveal an obvious place to insert 
that reference, so if you or others have ideas of where it should go, I'm happy 
to contribute a few lines of wrapper text.

Thanks,

Wes

Anything below this line has been added by my company’s mail server, I have no 
control over it.
---



This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes

[George, Wes]

On 6/13/14, 5:07 AM, "bruno.decra...@orange.com"
 wrote:

>If this is the choosen way, draft-ietf-sidr-origin-validation-signaling
>should also say that:
>- ASBR should remove such community from routes received over eBGP
>sessions (possibly modulo confederation, 2 AS from the same
>organization/trusted...)
>- this community must not be used in the AS until all ASBR are upgraded
>to support draft-ietf-sidr-origin-validation-signaling

Just wanted to note that as an operator of a network where my Autonomous
System (i.e. The span of the network under common control) spans multiple
Autonomous System NUMBERS, these carve-outs to handle confeds and multiple
ASNs from same org are pretty important if I am to implement Origin
Validation. Being able to validate at external ASBRs and keep that info
across the internal ASN boundaries would make a deployment in networks
like mine much simpler than if we have to revalidate at the internal ASBRs.

Thanks
Wes George


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs

[George, Wes]

On 5/20/14, 10:38 AM, "Randy Bush"  wrote:

>>  we got past
>folk looking up 'per se' in their dictionaries.

Well not exactly, since that was never the initial problem. I just decided
not to make an issue out of it any further since I seemed to be the only
one expressing the concern.

Wes


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-05.txt

[George, Wes]

Works for me.

Though I’m not sure that there is a huge distinction between disabling
BGPSec and taking the router offline since disabling BGPSec would trigger
neighbor session resets for capability renegotiation unless we’ve
specified otherwise in the protocol docs (doesn’t look like it in my quick
skim), and most likely force an entirely ungraceful set of updates as the
neighbors re-send their announcements with AS_PATH instead of BGPSEC_PATH.

Thanks,

Wes



On 5/12/14, 9:50 PM, "Sean Turner"  wrote:

>Wes,
>
>Randy and I bashed some text around; would this work:
>
>When it is decided that an active router key is to be revoked, the
>process of requesting the CA to revoke, the process of the CA
>actually revoking the router’s certificate, and then the process of
>rekeying/renewing the router’s certificate, (possibly distributing a
>new key and certificate to the router), and distributing the status
>takes time during which the operator must decide how they wish
>to maintain continuity of operations, with or without the compromised
>private key, or whether they wish to to bring the router offline to
>address the compromise.
>
>Keeping the router operational and BGPsec-speaking is the ideal goal,
>but if operational practices do not allow this then reconfiguring the
>router to disabling BGPsec is likely preferred to bringing the router
>offline.
>
>Routers which support more than one private key, where one is
>operational and the other(s) are soon-to-be-opertional, facilitate
>revocation events because the operator can configure the router to make
>a soon-to-be-operational key operational, request revocation of the
>compromised key, and then make a new soon-to-be-operational key, all
>hopefully without needing to take offline or reboot the router.  For
>routers which support only one operational key, the operators should
>create or install the new private key, and then request revocation of
>the compromised private key.
>
>spt
>
>On Apr 30, 2014, at 16:26, George, Wes  wrote:
>
>> This update address my comments on the document, and I think it’s in
>>good
>> shape now. The new section 4 is really good. The one thing I might
>> recommend adding for completeness is a few additional words around
>> revocation process at the end of section 4, specifically if there is any
>> difference or recommendation in process for make before break (provision
>> new key, then revoke old) or when that may not be a good idea compared
>> with the risk of outage caused by revoking and then rekeying. It may be
>>as
>> simple as saying something similar to the above about whether a router
>> supports multiple private keys or not, but I’m not sure if there are
>> additional considerations that need to be discussed.
>>
>> Thanks,
>>
>> Wes
>>
>>
>>
>> On 4/29/14, 10:14 AM, "Sean Turner"  wrote:
>>
>>> Hi,
>>>
>>> This version includes a new section 4 that addresses key management
>>> (i.e., keep a timer to make sure your cert doesn’t expire).  There’s
>>>also
>>> some editorial/readability corrections.  Please review as the authors
>>> think this version pretty much wraps up what we wanted to say.
>>>
>>> spt
>>>
>>> On Apr 29, 2014, at 10:10, 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 Working
>>>> Group of the IETF.
>>>>
>>>>   Title   : Router Keying for BGPsec
>>>>   Authors : Sean Turner
>>>> Keyur Patel
>>>> Randy Bush
>>>> Filename: draft-ietf-sidr-rtr-keying-05.txt
>>>> Pages   : 10
>>>> Date: 2014-04-29
>>>>
>>>> Abstract:
>>>>  BGPsec-speaking routers are provisioned with private keys to sign BGP
>>>>  messages; the corresponding public keys are published in the global
>>>>  RPKI (Resource Public Key Infrastructure) thereby enabling
>>>>  verification of BGPsec messages.  This document describes two ways of
>>>>  provisioning the public-private key-pairs: router-driven and
>>>>  operator-driven.
>>>>
>>>>
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/
>>>>
>>>> There's also a htmlized version available at:
>>&g

Re: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-05.txt

[George, Wes]

This update address my comments on the document, and I think it’s in good
shape now. The new section 4 is really good. The one thing I might
recommend adding for completeness is a few additional words around
revocation process at the end of section 4, specifically if there is any
difference or recommendation in process for make before break (provision
new key, then revoke old) or when that may not be a good idea compared
with the risk of outage caused by revoking and then rekeying. It may be as
simple as saying something similar to the above about whether a router
supports multiple private keys or not, but I’m not sure if there are
additional considerations that need to be discussed.

Thanks,

Wes



On 4/29/14, 10:14 AM, "Sean Turner"  wrote:

>Hi,
>
>This version includes a new section 4 that addresses key management
>(i.e., keep a timer to make sure your cert doesn’t expire).  There’s also
>some editorial/readability corrections.  Please review as the authors
>think this version pretty much wraps up what we wanted to say.
>
>spt
>
>On Apr 29, 2014, at 10:10, 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 Working
>>Group of the IETF.
>>
>>Title   : Router Keying for BGPsec
>>Authors : Sean Turner
>>  Keyur Patel
>>  Randy Bush
>>  Filename: draft-ietf-sidr-rtr-keying-05.txt
>>  Pages   : 10
>>  Date: 2014-04-29
>>
>> Abstract:
>>   BGPsec-speaking routers are provisioned with private keys to sign BGP
>>   messages; the corresponding public keys are published in the global
>>   RPKI (Resource Public Key Infrastructure) thereby enabling
>>   verification of BGPsec messages.  This document describes two ways of
>>   provisioning the public-private key-pairs: router-driven and
>>   operator-driven.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-05
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rtr-keying-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/
>>
>> ___
>> I-D-Announce mailing list
>> i-d-annou...@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>___
>sidr mailing list
>sidr@ietf.org
>https://www.ietf.org/mailman/listinfo/sidr


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

[sidr] SIDR-AS-Migration updates?

[George, Wes]

The current version of draft-ietf-sidr-as-migration is expired. Before I just 
push a keepalive draft, any comments I need to incorporate, or discussion that 
should happen in Toronto, or is this ready for a WGLC?

Thanks,

Wes

Anything below this line has been added by my company’s mail server, I have no 
control over it.
---


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs

[George, Wes]

On 1/25/14, 3:33 AM, "Randy Bush"  wrote:


>hence the "per se," meaining in and of itself.  some cases of pouring
>cement into a router (see london tube) are security issues, some are
>not.
>
>how would you make that more clear?
I think Warren’s suggestion of simply eliminating the assertion about
whether it’s a security issue, per se or otherwise, and just saying that
it’s out of scope is enough for the intro.

> they are announcements of P by A
>to B which are not agreed by all parties concerned (including A, B,
>neighbors of A and B, the originator of P, ...).  the problem lies in
>detecting them, especially from a distance.
So I think that goes back to my suggestion that since you already discuss
intent in 3.22, that might be a place to add something about leaks, either
as a part of that req or a follow-on, because that’s really what you’re
saying here - we understand theoretically what they are, but not how to
detect them such that we could do anything to prevent the undesired ones.

Wes


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs

[George, Wes]

On 1/24/14, 10:04 AM, "Warren Kumari"  wrote:


>Would simply:
>"issues of business relationship conformance (of which routing 'leaks'
>are a subset), while important to operators, are outside the scope of
>this document.”
>
>cover things well enough?

It would at least address the concern about declaring them not to be
security concerns, and is enough for the intro, IMO

>
>>My issue with this text is the reason it provides as to why they’re
>> considered out of scope. I don’t think that it’s entirely accurate to
>> assert that route leaks are not security issues. While not all route
>>leaks
>> are security issues, some are. It would be more accurate to reflect the
>> discussion that led us to the conclusion that we can’t secure them
>>because
>> we don’t know what “them” is yet, and are awaiting GROW to define them
>>in
>> such a way so that we can evaluate if it’s even possible to secure them
>>in
>> this framework. That may be a longer discussion that doesn’t belong in
>>the
>> intro, I don’t know.
>>
>
>I suspect it is. It somewhat seems like a non-terminating discussion

I think it might be appropriate to add a new req in the form of req 3.3 to
explain why this is out of scope, or bolster 3.22 to expand on intent as
it relates to this, perhaps with some reference to the fact that route
leaks are currently not well-enough defined to consistently (and more
importantly, systematically) identify them and secure the right BGP
attributes to help prevent them

Thanks
Wes


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs

[George, Wes]

I’ve reviewed, it’s mostly ready, minor comments:

I’m not happy with this text in the intro: “issues of business
   relationship conformance, of which routing 'leaks' are a subset,
   while quite important to operators (as are many other things), are
   not security issues per se, and are outside the scope of this
   document.”

Let me be clear up front, my issue is *not* that these are declared out of
scope, since my comments on the threats document seemed to be interpreted
otherwise.

My issue with this text is the reason it provides as to why they’re
considered out of scope. I don’t think that it’s entirely accurate to
assert that route leaks are not security issues. While not all route leaks
are security issues, some are. It would be more accurate to reflect the
discussion that led us to the conclusion that we can’t secure them because
we don’t know what “them” is yet, and are awaiting GROW to define them in
such a way so that we can evaluate if it’s even possible to secure them in
this framework. That may be a longer discussion that doesn’t belong in the
intro, I don’t know.

Also I think the parenthetical “as are many other things" is unnecessary
and clunky.


Thanks,

Wes


On 1/10/14, 8:38 PM, "Chris Morrow"  wrote:

>
>Working Group Folken,
>Today starts a WGLC for the subject draft:
>  
>
>Abstract:
>   This document describes requirements for a BGP security protocol
>   design to provide cryptographic assurance that the origin AS had the
>   right to announce the prefix and to provide assurance of the AS Path
>   of the announcement.
>
>Please have a read-through and send comments at the authors +
>sidr@ietf.org mailing list.
>
>This WGLC completes in 1,209,600 seconds, or 20,160 minutes.
>
>Thanks!
>
>-chris
>co-chair
>
>
>___
>sidr mailing list
>sidr@ietf.org
>https://www.ietf.org/mailman/listinfo/sidr


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-07.txt

[George, Wes]

From: Stewart Bryant [mailto:stbry...@cisco.com]
Sent: Tuesday, October 29, 2013 12:58 PM
To: Stephen Kent; George, Wes; sidr
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-07.txt

I acknowledge that there are wider threats, that need to
be addressed, but as Steve says this I-D should not be
a hostage to us putting in place solutions to those problems.
[WEG] We can certainly discuss in more detail, but I did want to respond to 
this one thing...
I am not requesting that the doc be held hostage, certainly not until there are 
solutions. I am mainly requesting that the problems left unaddressed be 
discussed in a bit more detail to make the security posture clearer, without so 
many references to the specific choices made by SIDR's charter.
I can't seem to make it clear that I'm not trying to do an end-run around the 
charter nor editorialize on those choices post-facto. Rather I am merely 
stating that SIDR's charter does not make the problem disappear, and I'd rather 
see it discussed for what it is instead of handwaving it away because it's not 
in charter.

Wes


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-07.txt

[George, Wes]

I better understand your comment. Your concern appears to be that a reader of 
this doc will assume that we decided to not consider the security of other path 
attributes because they are less important than AS_Path. However, by stating  
that securing these other attributes is deemed out of scope, based on the 
charter,  I think we  make it clear that we have  not made a value judgement 
about the relative importance of them.
[WEG] That's part of the problem. I think you *should* be making a value 
judgment as to their importance (more accurately, their risk of being 
exploited) for the sake of completeness of the vulnerability analysis.

[WEG] I've seen the addition. It's not adequate to address my concern, because 
the text in section 5 was not changed at all to remove the reference to charter 
and "changes to this document at a later time" for both route leaks and 
secondary attributes.

I don't see why you believe that references to the charter,  augmented by the 
salient text from the charter, are not appropriate here; that's the reason 
these topics are not addressed.
[WEG] There is no "salient text from the charter" augmenting section 5. And I 
don't think that a paraphrase in the intro is nearly as helpful as actual 
quotes where appropriate.
  I also think
the note about updating the threat doc, if and when the charter is changed to 
include these concerns,
is appropriate. It tells the reader that these topics may be addressed in the 
future.
[WEG] Your horizon for "future" and the lifecycle of this document don't match 
up. Assuming that this document proceeds to RFC, "this document should be 
revised" is impossible - it would require an entirely new document. As I said, 
that wording is fine as a placeholder for a document in active discussion, but 
is far too ephemeral for something as carved in stone tablets as an RFC. 
Dropping the last sentence from each of the first 2 bullets in section 5 
pathsec residual vulnerabilities would help to address this concern.

[WEG] I'm no connoisseur of threat analyses, so I don't have a large basis of 
comparison, but I do think that a threats document should not identify a 
residual threat and then hand-wave it away as "out of scope" instead of 
explaining the relative risk that it might be exploited. It might even perhaps 
draw the conclusion that the risk is negligible, but based on your explanation, 
WG charter and scope shouldn't figure into the discussion. Worse yet, as this 
section is currently written, it's circular logic: pathsec doesn't protect 
non-AS_Path attributes, so there's a risk of those attributes being manipulated 
without pathsec detecting it, but that's ok because pathsec isn't required to 
protect against those things. Why isn't pathsec required to protect against 
those things? Because the charter says it isn't. Why does the charter say that? 
Because...reasons?

We fundamentally disagree on this point. A threat doc is always constrained by 
some set of contextual
assumptions. Stating that we are aware of some concerns that are not addressed, 
and that they may be
addressed in the future is a reasonable way to convey to the reader what some 
of the contextual
constraints are. Your characterization of the discussion as "circular 
reasoning" is faulty. What
the text says is that path security is the focus of the WG, and thus is a 
constraint adopted by
this threat analysis, period.
[WEG] whether you agree with my characterization or not, I stand behind it. I 
believe the scope of a threat analysis should be limited by the likelihood of a 
given vulnerability to be exploited for an attack, not the arbitrary charter of 
a WG.



>From a threat analysis perspective, either the ability to manipulate 
>unprotected attributes is a threat (a capability for an adversary to carry out 
>an attack) to BGP Path security, or it's not. I believe the fact that you/the 
>WG included it in the discussion means that you/the WG believe that it's a 
>threat. I could infer based on the fact that SIDR chose not to design 
>protections against that exploit that it's a real threat but very low risk, or 
>extremely difficult to exploit, or whatever, but the document doesn't 
>currently say anything about the relative level of risk for the threat being 
>identified. You're right in that the design/requirements decisions that SIDR 
>WG made about whether to address that threat are mostly irrelevant, but the 
>fact that you discuss it in terms of design scope makes that confusing if one 
>is to evaluate this text as purely a threats analysis. It goes back to a 
>recurring issue that has happened with the order of these documents, where 
>we're writing a threats doc and a requirements doc based on an existing design 
>rather than the other around, and are tailoring these documents based on the 
>current design to the exclusion of things deemed out of scope instead of 
>documenting everything and then deciding some of the specific scope items in 
>the requirement

Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-07.txt

[George, Wes]

In order to make this thread a bit more readable, I've added [Wes] to my 
original comments if I kept them, [SK] to yours, and my new replies are [WEG]


From: Stephen Kent [mailto:k...@bbn.com]

[SK]The increased sensitivity to nation-level threats is understandable.The 
threats doc lists nations as a category of adversary in Section 3; we have not 
ignored them. (Can you name any other IETF threat analysis that has done so?)  
The doc does not discuss attacks by nations against LTAM. The RPKI, as 
specified in RFCs 6480-91, is addressed for completeness, and because the SIDR 
charter mandates use of the RPKI. LTAM is still an I-D; it is not part of the 
RPKI standards. As such, I don't consider it to be in scope for this doc.

More to the point, as lead author of the LTAM doc, I anticipate reducing its 
scope in a way that
may remove the concern you raised. However, our new I-D, "Suspenders" may raise 
similar
concerns. I think it appropriate to discuss them if and when the WG elects to 
adopt that doc
as a work item.
[WEG] That's a reasonable distinction (discuss only the standards not drafts) 
and an acceptable way forward.
[Wes]That said, I also think that the discussion of this topic at the end of 
session 5 is inadequate for a document in IETF LC. The SIDR WG made a conscious 
decision to secure *only* the AS_Path attribute, and leave other attributes 
insecure, but there is no summary of the underlying rationale supporting this 
choice. Pointing to a WG charter as the sole explanation, and noting that this 
document should be changed if the charter is updated is unacceptable, as it 
provides no context to a reader that was not privy to the discussion leading to 
that charter/scope decision.
[SK]No one (other than you) suggested that we include a discussion of the 
history of the charter/scope discussion here. I do not recall seeing such a 
discussion in any other threat analysis doc. I don't plan to add such a 
discussion here.

[WEG] I think I was unclear in the way that I raised the concern, and your 
response (below) helped me see that, so I'll try to clarify. I don't care 
whether it's a charter/scope issue, and I'm not asking for the summary for that 
reason. I care about it from the perspective of its relative risk as a threat, 
and I made reference to the scope/WG/charter/design discussion because I 
thought that would inform the discussion of the level of risk (i.e. we decided 
that the risk was not high enough to justify changes to the design to secure 
additional attributes).


[Wes]It also makes reference to something fairly ephemeral (a WG and charter) 
in a permanent document. Fine for a draft in WG discussion to have that sort of 
placeholder, but not anymore.
[SK]The latest version (-07) of the threats document added a paraphrase of the 
relevant charter text to address the concern about referencing a charter, an 
issue raised by David Black in his GENART review.
[WEG] I've seen the addition. It's not adequate to address my concern, because 
the text in section 5 was not changed at all to remove the reference to charter 
and "changes to this document at a later time" for both route leaks and 
secondary attributes.

[Wes]There is a brief (and IMO incomplete) discussion of this matter to be 
found in section 2.3 of draft-sriram-bgpsec-design-choices that could be 
referenced, but since that document's future is unclear, some standalone 
discussion within this document might be more appropriate. At a minimum, a 
threats document should discuss why these threats are not considered high 
enough risk to justify the added complexity of securing them using the RPKI.
[SK]A threat analysis, in principle, identifies adversaries, their motivations 
for carrying out classes of attacks, and their capabilities to do so. It need 
not establish requirements for acceptable designs, or propose countermeasures 
to address classes of attacks. In this doc we went beyond those essential 
threat analysis elements, because there was no RPKI threat doc (and because the 
charter calls for use of the RPKI as a basis for BGPSEC). A requirements doc is 
a place where one defines what needs to be done by a solution, to address the 
threats previously described.

[WEG] I'm no connoisseur of threat analyses, so I don't have a large basis of 
comparison, but I do think that a threats document should not identify a 
residual threat and then hand-wave it away as "out of scope" instead of 
explaining the relative risk that it might be exploited. It might even perhaps 
draw the conclusion that the risk is negligible, but based on your explanation, 
WG charter and scope shouldn't figure into the discussion.

Worse yet, as this section is currently written, it's circular logic: pathsec 
doesn't protect non-AS_Path attributes, so there's a risk of those attributes 
being manipulated without pathsec detecting it, but that's ok because pathsec 
isn't required to protect against those things. Why isn't pathsec required to 
pro

Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-07.txt

[George, Wes]

This update does not address any of my comments from my review (message sent on 
9/12).

Thanks,

Wes


> -Original Message-
> From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of
> internet-dra...@ietf.org
> Sent: Tuesday, October 08, 2013 4:41 PM
> To: i-d-annou...@ietf.org
> Cc: sidr@ietf.org
> Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-07.txt
>
>
> 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   : Threat Model for BGP Path Security
>   Author(s)   : Stephen Kent
>   Andrew Chi
>   Filename: draft-ietf-sidr-bgpsec-threats-07.txt
>   Pages   : 19
>   Date: 2013-10-08
>
> Abstract:
>This document describes a threat model for the context in which
>(E)BGP path security mechanisms will be developed.  The threat model
>includes an analysis of the RPKI, and focuses on the ability of an AS
>to verify the authenticity of the AS path info received in a BGP
>update.  We use the term PATHSEC to refer to any BGP path security
>technology that makes use of the RPKI.  PATHSEC will secure BGP
>[RFC4271], consistent with the inter-AS security focus of the RPKI
>[RFC6480].
>
>The document characterizes classes of potential adversaries that are
>considered to be threats, and examines classes of attacks that might
>be launched against PATHSEC.  It does not revisit attacks against
>unprotected BGP, as that topic has already been addressed in
>[RFC4271].  It concludes with brief discussion of residual
>vulnerabilities.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-threats
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-threats-07
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-threats-07
>
>
> 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

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Last Call: (RPKI-Based Origin Validation Operation) to Best Current Practice

[George, Wes]

> From: Randy Bush [mailto:ra...@psg.com]
>
> i don't even know what geographic redundancy is, alternate earths?
[WEG] nah, the latency is too high until we sort out IP over Quantum 
Entanglement. ;-) Geographic redundancy in the context of things that live on 
servers is that it exists on servers in more than one physical location (e.g. 
Datacenter East and Datacenter West) so that there isn't a single point of 
failure. In this case, that'd probably be in the form of two caches backing 
each other up (router configured to use both).

 if
> you mean redundant network topology, i think it is more than that.  i
> really think physical line length matters.  as i said, the longer the
> circuit the more likely a boat anchor will whack it.  hence close.
[WEG] yes, but ultimately that's dependent on your network topology. If "close" 
is the only way to mitigate that (vs having a truly redundant backup that 
doesn't share any topology in its path), then sure, that's what you do. But I 
don't think it directly translates to "should be close". We clearly disagree, 
but I'm not going to belabor the point any further.
>
>
> i think i understand what you want made more explicit.  today's try
>
>To relieve routers of the load of performing certificate validation,
>cryptographic operations, etc., the RPKI-Router protocol, [RFC6810],
>does not provide object-based security to the router.  I.e. the
>router can not validate the data cryptographically from a well-known
>trust anchor.  The router trusts the cache to provide correct data
>and relies on transport based security for the data received from the
>cache.  Therefore the authenticity and integrity of the data from the
>cache should be well protected, see Section 7 of [RFC6810].
>
>As RPKI-based origin validation relies on the availability of RPKI
>data, operators SHOULD locate RPKI caches close to routers that
>require these data and services in order to minimize the impact of
>likely failures in local routing, intermediate devices, long
>circuits, etc.  One should also consider trust boundaries, routing
>bootstrap reachability, etc.  E.g. a router should bootstrap from a
>chache which is reachable with minimal reliance on other
>infrastructure such as DNS or routing protocols.
>
>For example, if a router needs its BGP and/or IGP to converge for the
>router to reach a cache, once a cache is reachable, the router will
>then have to reevaluate prefixes already learned via BGP.  Such
>configurations should be avoided if possible.

[WEG] close enough, ship it.

Wes

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Last Call: (RPKI-Based Origin Validation Operation) to Best Current Practice

[George, Wes]

> From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of
> Randy Bush
>
> how about
>
>To relieve routers of the load of performing certificate validation,
>cryptographic operations, etc., the RPKI-Router protocol, [RFC6810],
>does not provide object-based security to the router.  I.e. the
>router may not validate the data cryptographically from a well-known
>trust anchor.  The router trusts the cache to provide correct data
>and relies on transport based security for the data received from the
>cache.  Therefore the authenticity and integrity of the data from the
>cache should be well protected, see Section 7 of [RFC6810].
[WEG] fine, though it's unclear if "may" in the above is intended to be 
normative. I think it's not, but just pointing it out.

>
>As RPKI-based origin validation relies on the availability of RPKI
>data, operators SHOULD locate RPKI caches close to routers that
>require these data and services in order to minimize the impact of
>likely failures in local routing, intermediate devices, long
>circuits, etc.  One also should consider trust boundaries, routing
>bootstrap reachability, etc.  E.g. a router should bootstrap from a
>chache which is reachable with minimal reliance on other
>infrastructure such as DNS or routing protocols.
[WEG] this is better, but I still maintain that in the first sentence, "close" 
isn't actually the goal we're trying for.

How about:

...operators SHOULD consider the relationship between the routers that require 
these data and services and the location of the RPKI caches in the network's 
topology. Caches SHOULD be located so that they can take advantage of 
geographic redundancy and minimize the impact of likely failures in local 
routing, 

And add this at the end to explain why reliance on routing protocols @ 
bootstrap is risky:

...or routing protocols. Reliance on routing protocol convergence to reach a 
cache at bootstrap time can result in significant increases in total 
convergence time as the router converges partially, synchronizes with the RPKI 
cache, and then must re-converge based on the data from the cache.


Thanks

Wes

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Last Call: (RPKI-Based Origin Validation Operation) to Best Current Practice

[George, Wes]

> From: christopher.mor...@gmail.com [mailto:christopher.mor...@gmail.com]
>
> [CLM]
> In the RPKIcache example, 'consumer' is 'routers in your network'.
> 'Close' is 'close enough that bootstrapping isn't a problem', balanced
> with 'gosh, maybe I don't want to put one on top of each router! plus
> associated management headaches to deal with these new
> systems/appliances'.
[WEG] that's part of my issue - the only way that you get "close enough that 
bootstrapping isn't a problem" is when the cache and router are directly 
connected. Otherwise there *is* going to be some amount of time while the 
router is coming up that it can't talk to its configured caches e.g. while it 
learns the route(s) to the cache(s). I think that supports a recommendation to 
put the caches in your IGP instead of BGP, so that you get faster convergence 
of those routes and therefore have access to the cache when BGP comes up and 
starts converging, rather than once BGP is partially converged. But the draft 
doesn't say that.
The question is, does the propagation/convergence delay for an IGP in an 
average network (let's call it somewhere between subsecond and 5 seconds) make 
a non-trival difference in RPKI's bootstrap behavior, especially since BGP 
convergence is also dependent on IGP convergence? Can we make a clearer 
recommendation of the performance envelope we're shooting for so that people 
can design accordingly? I'm not sure I buy a general "faster(or closer) is 
always better" recommendation - at some point, we hit diminishing returns, 
given that this is mostly a human time-scale system. The document doesn't 
provide clear guidance on how to balance that tradeoff.
>
>
> [CLM]
> I guess one way is to say: "People should understand the dependencies
> and engineer appropriately" ... which you kind of asked to not say in
> the original comment. (or is the issue that the dependencies aren't
> clear?)

[WEG] The issue is that the dependencies aren't clear. I'm not expecting the 
text to be too prescriptive here, because all networks are different, but I 
need enough technical discussion to properly "understand the dependencies and 
engineer accordingly". This is an operational considerations document, so it 
needs to tell operators what breaks if they don't do it as recommended. If this 
is about bootstrapping, then we need to be clearer about the relationship 
between bootstrapping and network convergence (since recommending that the 
cache is directly connected to the router is impractical) and how it impacts 
RPKI cache-router communication and performance. If it's about reducing latency 
via proximity, then we need to explain how much latency is too much latency and 
why. If it's about proper geographic diversity within a network's topology, 
then we need to say that. If we don't actually know if it makes a difference, 
and so are defaulting to recommendations that most folks agree
  are generally a good idea, we should say that. But right now we're assuming 
too much, IMO.

Wes

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Last Call: (RPKI-Based Origin Validation Operation) to Best Current Practice

[George, Wes]

> From: Randy Bush [mailto:ra...@psg.com]
>
> are you really saying that i should be comfortable configuring a seattle
> router to use a cache in tokyo even though both are in my network and
> there is a pretty direct hop?
[WEG] not necessarily. But I'm also not saying that there would *never* be a 
scenario where that makes sense.
>
> i am willing to hack the text.  but i am just not sure that proximity is
> not a good attribute.  the longer the wire the greater the likelihood of
> it being cut.
[WEG] Proximity is generally a good attribute, but it's not free, so help the 
reader understand the tradeoffs so that they can justify spending money to get 
better proximity. The draft hasn't provided a good explanation of how proximity 
improves RPKI (or what problems a lack of it creates), nor how to determine 
whether the level of proximity in a given design is "good enough" to provide 
the perceived benefit.

Your statement about long wires being cut is an argument for redundancy and 
geographic diversity, not proximity. Of course an operator needs to take into 
account the topology of their network when considering geographic diversity, 
but that's not necessarily going to translate to a need for proximity.

The draft says one should consider latency, but never explains how increased 
latency impacts RPKI, nor gives any guidance on how much might be too much, 
especially when one considers that RPKI is an asymmetric system that changes on 
mostly human time-scales (order of hours or days). Most places where latency 
matters, it's a function of what RTT does to throughput or the perception of 
speed for interaction (how long it takes between when I click and when 
something happens). This isn't an interactive system. What is latency-sensitive 
in this system on the subsecond scale such that it can be affected by moving 
the cache closer? Even on systems configured for very frequent synchronization, 
are we expecting anything to change on that timescale?

See my other response to CMorrow for questions around bootstrapping.

Wes

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Last Call: (RPKI-Based Origin Validation Operation) to Best Current Practice

[George, Wes]

> From: Randy Bush [mailto:ra...@psg.com]
> i think the two paragraphs you would like to see improved are
[snip]
> i am not against further explanation, send text. but short text.  :)
[WEG] just the first paragraph really, and as I'll note below - I'd love to 
send text, but I don't understand one of the recommendations
>
> experiments have shown that latency between cache and router, and
> between caches in a cache dag, is not an appreciable issue.
[WEG] ok, so why is "close" important then?

> i thought bootstrap reachability would be fairly obvious to an operator.
> but if simple routing and no dns dependency were not obvious to you,
> then a few words are indeed needed.  or am i missing your point here?
[WEG] yes, completely obvious. Though the last two sentences of your suggested 
text in the other email is a useful addition
>
>
> what is missing from the second paragraph?
[WEG] I'm actually happy with second para
>
>
> i am not sure it would be useful to go into the general issue of why
> caches should be proximal to the consumer as it is a rather well-
> explored area, from akamia and limelight to dns.  but if you have a
> sentence or two that communicates this, send it over.
[WEG] Generally, I understand why closer is better for content caches 
(Akamai/llnw) and DNS, but not for RPKI caches. You're making a link between 
the two that I'm not following. Both of the former benefit from proximity 
because it reduces latency and reduces unnecessary backhaul and potentially 
allows for a geographically customized service, resulting in improved user 
experience. If latency isn't a factor (at least in the average-sized 
propagation domain), and RPKI caches aren't particularly bandwidth intensive, 
why does proximity matter? Is this just an extension of the trust domain and 
limited dependence on routing protocols? If so, I'd dispense with recommending 
"close" because it confuses the issue and just keep the discussion about 
secondary dependencies and trust domains.

Thanks
Wes George


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Last Call: (RPKI-Based Origin Validation Operation) to Best Current Practice

[George, Wes]

I've reviewed multiple iterations of this draft, and I believe it is mostly 
ready to go.

However, the concerns I raised during WGLC in 
http://www.ietf.org/mail-archive/web/sidr/current/msg05010.html regarding the 
ambiguity of some of the guidance regarding location of RPKI caches ("close") 
in section 3 still have not been addressed. IMO if it is important enough to 
discuss proximity, it is important enough to devote some words to explaining 
the rationale for that recommendation so that operators can make an informed 
design decision.

Thanks,

Wes George



> -Original Message-
> From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-
> boun...@ietf.org] On Behalf Of The IESG
> Sent: Tuesday, September 17, 2013 10:52 AM
> To: IETF-Announce
> Cc: sidr@ietf.org
> Subject: Last Call:  (RPKI-Based
> Origin Validation Operation) to Best Current Practice
>
>
> The IESG has received a request from the Secure Inter-Domain Routing WG
> (sidr) to consider the following document:
> - 'RPKI-Based Origin Validation Operation'
>as Best Current Practice
>
> 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 2013-10-01. 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
>
>
>Deployment of RPKI-based BGP origin validation has many operational
>considerations.  This document attempts to collect and present those
>which are most critical.  It is expected to evolve as RPKI-based
>origin validation continues to be deployed and the dynamics are
>better understood.
>
>
>
>
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-sidr-origin-ops/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-sidr-origin-ops/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

[sidr] draft-ietf-sidr-as-migration-00

[George, Wes]

Haven't really gotten any comments on this since I made the changes to address 
the comments identified at WG adoption. Could I get another review pass so that 
we can maybe put this one to bed?

Thanks,

Wes

> -Original Message-
> From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of
> internet-dra...@ietf.org
> Sent: Wednesday, July 10, 2013 1:57 PM
> To: i-d-annou...@ietf.org
> Cc: sidr@ietf.org
> Subject: [sidr] I-D Action: draft-ietf-sidr-as-migration-00.txt
>
>
> 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   : BGPSec Considerations for AS Migration
>   Author(s)   : Wesley George
>   Sandy Murphy
>   Filename: draft-ietf-sidr-as-migration-00.txt
>   Pages   : 14
>   Date: 2013-07-10
>
> Abstract:
>This draft discusses considerations and methods for supporting and
>securing a common method for AS-Migration within the BGPSec protocol.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-sidr-as-migration
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-sidr-as-migration-00
>
>
> 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

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-02.txt

[George, Wes]

> From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of
> Randy Bush
>
> > Note that cut/copy and paste operations over a SSH-proected CLI
> session
> > for keys over a certain sizes is error-prone; a less error process is
> to
> ^-prone
> > use a USB or CF device to copy the key to and then insert the device
> in
> > to the router.
>
> way too detailed.  you noted that pure text copy/paste is error prone.
> that's enough.  do you really want to get into the 42 other ways of
> doing it?  how about copy/paste of a checksummed package containing the
> credential?  or xmodem?  and don't forget paper tape!  :)
>

[WEG] Agree with Randy. Was more thinking about this in terms of the hardware 
swap scenario (section 5), rather than initial key provisioning. You say that 
vendors SHOULD allow the key to be offloaded and then provide examples of 
offload methods, but sneakernet isn't one of them. I don't think we have to 
tell implementers to support importing a key from a filesystem (in whatever 
form) but being explicit about the ability to EXPORT it to a filesystem is a 
different matter.

Thanks
Wes

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-02.txt

[George, Wes]

> From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of
> Sean Turner
>
> Better late than never?
>
> I believe this version addresses Wes' comments (if he can remember them
> :)
>
[WEG] I had to go find the email, but yes, this addresses my comments, with one 
exception - we'd talked about sneakernet key transfers (copy to USB or CF and 
move the card, copy back to restore) in the hardware swap case. I don't know if 
you want to explicitly mention that in section 5 or not. I'd sort of prefer 
that to hoping that router vendors understand that etc. = sneakernet. :-)

Did another review, found a few more mostly minor things:

Section 3.1 "...can be directly transferred to the RPKI CA over the Ethernet 
port..." I'd be less specific here and say something like "over the network" 
since "the Ethernet port" is both ambiguous and overly specific. Also you 
probably need to say something like "assuming that the router has direct 
connectivity to the CA at this point in the provisioning process" -- for that 
matter, it might be useful for both 3.1 and 3.2 if you were explicit about what 
the router needs to be able to talk to both inside and outside of the provider 
network at this stage of the provisioning process to make sure that none of 
these validation and key exchange steps fail on account of not being able to 
talk to the right server. In other words, which of these validations are local 
and which require communicating with an external TA, CA, etc.?

The draft currently skips from section 3 to section 5. I might suggest that 
section 4 should cover key rolls (if, for example, the private key is 
compromised somehow, or if you simply wish to do this periodically), since 
you've covered provisioning a new router, and then go to scenarios where you 
want to swap hardware and keep the same keys. I don't think there's a lot that 
is different between initial provisioning and doing a key roll, but if there is 
anything different, it's worth highlighting, especially if there are gotchas 
around making sure that you don't accidentally break validation when you swap 
router keys (overlapping expiry, etc), and if there isn't, it's worth 
mentioning that the process is the same.

A few grammar nits as well, but I expect the RFC editor can handle those. :-)

> > Title   : Router Keying for BGPsec
> > Author(s)   : Sean Turner
> >Keyur Patel
> >Randy Bush
> > Filename: draft-ietf-sidr-rtr-keying-02.txt
> > Pages   : 9
> > Date: 2013-09-12
> >

[WEG] Nice job in making this more accessible for those of us less familiar 
with PKI wrangling, this is a really helpful draft.

Wes

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Last Call: (Threat Model for BGP Path Security) to Informational RFC

[George, Wes]

I've reviewed this document and have some comments.

First, an apology, because although I'm an active participant in the SIDR WG, 
I'm pretty sure I missed the WGLC on this, so these comments shouldn't 
necessarily be construed as me taking my argument to ietf@ietf because I felt 
that SIDR ignored my concerns.

Now, my actual comments:

Maybe I'm hypersensitive to such in light of recent accusations of national 
actors subverting supposedly secure infrastructure to behave badly, but I find 
it odd that this threats document doesn't discuss the interaction between a 
national actor and the machinery provided by draft-ietf-sidr-ltamgmt. i.e. a 
national actor imposes upon SPs that operate inside their borders to use their 
own Local (and compromised) Trust Anchor to subvert the protections provided by 
RPKI. While this is primarily a concern for origin validation, I view it as 
distinct from the existing discussion of attacks on a CA covered in 4.5, and 
there is no equivalent Origin Validation threats document. It may be that the 
right path is to augment the discussion of this issue in the LTA management 
draft, and simply reference it from this draft, but I don't think that this is 
discussed suitably in the security considerations of either draft.


Section 4.2 is missing any discussion regarding manipulation of other route 
attributes that may be used to affect a BGP route's selection, such as MED, 
Local Pref. It's covered in section 5, but since this occurred to me whilst 
reading section 4.2, perhaps some mention in 4.2 would be useful, I don't know.
That said, I also think that the discussion of this topic at the end of session 
5 is inadequate for a document in IETF LC. The SIDR WG made a conscious 
decision to secure *only* the AS_Path attribute, and leave other attributes 
insecure, but there is no summary of the underlying rationale supporting this 
choice. Pointing to a WG charter as the sole explanation, and noting that this 
document should be changed if the charter is updated is unacceptable, as it 
provides no context to a reader that was not privy to the discussion leading to 
that charter/scope decision. It also makes reference to something fairly 
ephemeral (a WG and charter) in a permanent document. Fine for a draft in WG 
discussion to have that sort of placeholder, but not anymore. There is a brief 
(and IMO incomplete) discussion of this matter to be found in section 2.3 of 
draft-sriram-bgpsec-design-choices that could be referenced, but since that 
document's future is unclear, some standalone discussion within thi
 s document might be more appropriate. At a minimum, a threats document should 
discuss why these threats are not considered high enough risk to justify the 
added complexity of securing them using the RPKI.

Thanks,

Wes George


> -Original Message-
> From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of
> The IESG
> Sent: Monday, September 09, 2013 6:26 PM
> To: IETF-Announce
> Cc: sidr@ietf.org
> Subject: [sidr] Last Call: 
> (Threat Model for BGP Path Security) to Informational RFC
>
>
> The IESG has received a request from the Secure Inter-Domain Routing WG
> (sidr) to consider the following document:
> - 'Threat Model for BGP Path Security'
>as Informational RFC
>
> 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 2013-09-23. 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 describes a threat model for the context in which
>(E)BGP path security mechanisms will be developed.  The threat model
>includes an analysis of the RPKI, and focuses on the ability of an AS
>to verify the authenticity of the AS path info received in a BGP
>update.  We use the term PATHSEC to refer to any BGP path security
>technology that makes use of the RPKI.  PATHSEC will secure BGP
>[RFC4271], consistent with the inter-AS security focus of the RPKI
>[RFC6480].
>
>The document characterizes classes of potential adversaries that are
>considered to be threats, and examines classes of attacks that might
>be launched against PATHSEC.  It does not revisit attacks against
>unprotected BGP, as that topic has already been addressed in
>[RFC4271].  It concludes with brief discussion of residual
>vulnerabilities.
>
>
>
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-threats/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-threats/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.

Anything below this line has been added by my company's mail server, I have no 
control over it.
-


This E-mail and any of its attachments ma

[sidr] New SIDR-AS-Migration revision notes

[George, Wes]

New version of the draft formerly known as draft-george-sidr-as-migration

This version incorporates a good bit of feedback from several reviews of the 
previous version, changes to documentation ASNs, and renamed to reflect WG 
adoption. The only thing not incorporated was Sriram's additional example case 
he suggested in his previous review message, because I am awaiting feedback as 
to whether that is helpful or necessary.

I also posted a new version of the companion draft in IDR, but that's mainly 
limited to changes to its example ASNs so that the two documents remain 
consistent. It would be helpful to get another set of eyes to look at the 
"Internal BGP Alias" section of that document (see draft-ga-idr-as-migration 
section 4.1) and see if any additional text is required in the SIDR document to 
address that. I don't think there's anything too groundbreaking there, mainly 
the question of whether we need to explicitly discuss the BGPSec behavior for a 
command switch that basically allows a PE to accept a BGP session from either 
the old ASN or the new, rather than being explicitly configured for one or the 
other. We already have described what happens when it is peered with the old 
ASN, and the new ASN would be standard configuration, where none of these 
tweaks to support AS Migration should be necessary anymore, but I wasn't sure 
if we needed to specifically address this.
And of course, additional reviews are most welcome!

Thanks,

Wes George


-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Wednesday, July 10, 2013 1:57 PM
To: Sandy Murphy; Dr.Sandra L.Murphy; George, Wes
Subject: New Version Notification for draft-ietf-sidr-as-migration-00.txt


A new version of I-D, draft-ietf-sidr-as-migration-00.txt
has been successfully submitted by Wesley George and posted to the
IETF repository.

Filename:draft-ietf-sidr-as-migration
Revision:00
Title:   BGPSec Considerations for AS Migration
Creation date:   2013-07-10
Group:   sidr
Number of pages: 14
URL: 
http://www.ietf.org/internet-drafts/draft-ietf-sidr-as-migration-00.txt
Status:  http://datatracker.ietf.org/doc/draft-ietf-sidr-as-migration
Htmlized:http://tools.ietf.org/html/draft-ietf-sidr-as-migration-00


Abstract:
   This draft discusses considerations and methods for supporting and
   securing a common method for AS-Migration within the BGPSec protocol.


This draft replaces draft-george-sidr-as-migration.

The IETF Secretariat

[WEG] Anything below this line has been added by my company’s mail server, I 
have no control over it.
-

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] review/adoption of draft-george-sidr-as-migration

[George, Wes]

From: Roque Gagliano (rogaglia) [mailto:rogag...@cisco.com]


The document is intended as "Informational" but do have requirement language. 
Is this what you intended?
[WEG] originally, it was just covering the problem statement. This last 
revision added the solution, and thus required some normative language to guide 
the implementation. That probably means the doc type needs to change, but I was 
looking to the WG for feedback on how to proceed (whether this should remain a 
standalone document as companion to the BGPSec protocol draft, or be integrated 
into it, or what). Last meeting, it sounded like the preference was to have 
this remain a standalone document, but I didn't hear any real guidance on 
whether it should formally update the BGPSec document or not.

Personally, I would rather all requirements to be moved to the requirements 
document so we have one unique point to read. We could publish then this 
document even as a "BCP" on a specific practice. Does point 3.15 of the BGPSEC 
requirements document seams not to cover your own requirements in Section 4. Do 
you think we can move the BGPSEC specific requirements to the other document?
[WEG] I have no objection to moving section 4 to sidr-bgpsec-reqs to add to 
3.15. I documented them here because as noted above, originally this was a 
problem statement, and so it seemed important to ensure that any solutions 
could be evaluated against their success in meeting these requirements that are 
specific to AS-migration and aliasing.

Wes

On May 29, 2013, at 3:59 PM, "George, Wes" 
mailto:wesley.geo...@twcable.com>> wrote:


All - I have not received any feedback regarding this draft since I posted the 
revision incorporating the solution into it in February. Perhaps it's time to 
call WG adoption so that it can move forward?

http://tools.ietf.org/html/draft-george-sidr-as-migration-01

Thanks,

Wes George


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org<mailto:sidr@ietf.org>
https://www.ietf.org/mailman/listinfo/sidr

* Persona Not Validated - 1368524010073 
mailto:rogag...@cisco.com>>
* Issuer: Symantec Corporation - Unverified

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

[sidr] review/adoption of draft-george-sidr-as-migration

[George, Wes]

All - I have not received any feedback regarding this draft since I posted the 
revision incorporating the solution into it in February. Perhaps it's time to 
call WG adoption so that it can move forward?

http://tools.ietf.org/html/draft-george-sidr-as-migration-01

Thanks,

Wes George


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-01.txt

[George, Wes]

> -Original Message-
> From: Sean Turner [mailto:turn...@ieca.com]
>
>
> Comments inline.
[WEG] me too
>
>
> We're trying to head off the typical knee-jerk reaction about non-client
> generated keys where somebody says oh no can't do that because that's
> what their BPKI does.  But, I get your point.  How about:
>
> The difference between the two methods is where the keys are generated:
> on the router in the router-driven method and elsewhere in the operator-
> driven model.  Different equipment necessitates the two methods.  Some
> equipment doesn't allow the private key to be off-loaded while other
> equipment does.  Off-loading private keys supports hot-swappable routers
> that need to have the same private key needs installed in the soon-to-be
> online router that was installed in the soon-to-be offline router.
[WEG] yes this is much clearer
>
> Do you think we need to say anything like:
>
> NOTE: Unlike humans, routers can be easily cloned; hence, operators
> generating the private keys make sense.
>
[WEG] I'm not sure I follow the logic on this one, so I don't have a good 
answer for you - is it meant to be a justification of using the 
operator-generated model, or a recommendation to do so, or something else?

> >
> > The key (pun very
> much intended) thing here is to highlight things that are different from
> normal provisioning and explain why they're important.
>
> I was shooting for something more narrative, but yeah I could see that
> it would make sense to say here's what's different.  Now, any idea where
> this BCP is? :)  I'm not sure there is one.
[WEG] There isn't a BCP in the IETF sense of the word. I was thinking more 
generally in terms of the fact that most folks who can provision a router from 
bare metal know how to do this, IOW, it's common practice. If we really need a 
reference, modulus the specific commands being typed, any "how to enable SSH 
access to your RouterBrand (tm) router using the  fantastic and intuitive 
IJunSRScreenOS CLI" documentation would probably be sufficient to serve as a 
baseline for something like: "this document assumes that the reader is capable 
of provisioning a router for SSH access per the manufacturer's instructions. 
The following additional steps are necessary/recommended to prepare for keying 
the router for SIDR because of foo" where foo would be any security 
recommendations like requiring certificate-based authentication, etc. 
Basically, limit your discussion to things that are either critical enough that 
you don't want to simply assume they'll be present in the vendor documentati
 on, or different from the norm because that's what's necessary for your 
process to be secure.
>
>
> Ah for this section, the only key transferred is public and it's in the
> PKCS#10, which is the only thing that gets transferred.  But, you asking
> this question makes me think I should make it clearer about what's being
> transfer and why anybody'd care.
[WEG] Yes, your brief explanation above makes this much clearer, so adding it 
will be helpful
>
> > Also, I don't follow your last sentence "...linkage between private
> key and a router..." - why is that important?
>
> The idea is that you want to be able to know the router's got the
> private key associated with the public key.  Another way to say this is
> POP - and I agree this could be made clearer.  Something like:
>
>   Note that even if the operator can not get the private key off the
>   router this still provides a linkage between a private key and a
>   router.  That is the server can do a proof of possession (POP),
>as required by [RFC6484].
[WEG] Makes more sense, but "this" is ambiguous in the above sentence, even 
when read with the preceding text. Replacing "this" with its antecedent will 
help.
>
> > 3.2 "installed over the ssh session..." - are we talking simple copy
> and paste of a huge string of text representing the key, or is it
> actually SCP/SFTP of a file that is then read into the router's config
> via additional commands?
> > If you're talking copy/paste, it's probably worth warning that for
> keys over a certain size, this method is error-prone. I've seen a lot of
> mangled config because someone exceeded a paste buffer when trying to
> copy/paste a config, especially over a 9600 bps console at the other end
> of 90ms of latency.
>
> An excellent point, but I'm sure hope it's commands and not ctrl-c/v.
[WEG] well... I (and probably lots of other people) learned from the school of 
hard knocks on this one, so I'd say it's a point worth making explicitly.

Wes George


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copyin

Re: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-01.txt

[George, Wes]

I gave this a review since I am one of the folks who raised my hand as willing 
to be the resident PKI n00b to make sure that things like this are clear to 
"router guys" who are dealing with PKI for the first time outside of maybe 
generating the SSH keys for tty access to a router.

The second paragraph of the intro, starting with the sentence "The 
router-driven model is most..." is difficult to parse (grammatically). I 
recommend re-wording to eliminate "often times for human subscribers" from the 
middle of the phrase and generally streamline the point being made here.

Editorial nit: multiple instances of %s/drive/driven

3. instead of serial/craft, I'd just say console.
Or more generally, you could refer to in-band management vs out of band, as 
that covers a wider set of scenarios than specifically referring to an Ethernet 
port and a serial port. Yes, that doesn't exactly cover the hair-split when 
people use a management Ethernet port connected to a separate management 
network for "in band" (non-console) management of the device, but maybe that's 
clear enough, I don't know.
I also don't think proprietary is the right word. Console access via a terminal 
server is pretty universal, and unless there's some sort of a tool pushing out 
the initial config snippets over console to bootstrap the box so that it can 
talk to it inband and finish the provisioning, "operator going typey-typey on a 
terminal" is definitely not proprietary either.

Another thought - console access via remote terminal server isn't actually 
secure in every case. In a typical setup you have:
User host -> (ssh) bastion/jump box -> (telnet) local terminal server -> 
RS232/USB connection to console
Unless the path between the jump box and the local terminal server is such that 
it is nearly impossible to sniff the traffic (private network, direct 
connection, etc) using this to provision sensitive config might be ill-advised. 
Might be worth explicitly stating that for this reason, use of the console to 
provision the SIDR keys is NOT recommended.

It's not clear to me whether the method being described in this first part of 
section 3 is actually important. Do you actually have to do something different 
in the way that you bring a router online (get it basic connectivity to the 
network) in this process in order to preserve proper security and trust for the 
keys, or is this just illustrating a typical process to provision a router from 
bare metal such that you have secure access to it to further manipulate the 
configuration? Is certificate-based authentication (instead of password auth) a 
MUST, or a SHOULD, or does it matter? If this is just illustrating a standard 
example, you can probably just say something like "this assumes that standard 
(BCP?) procedures have been followed to initially configure the router for 
secure remote access, via either inband or out of band means" and then just 
specify that it's necessary to have the secure connection between the router 
and operator before the router keying for SIDR is done (
 because). Some of this is down in the security considerations today, and I 
think it's important to actually discuss it here instead since it's basically a 
critical part of the provisioning process. The key (pun very much intended) 
thing here is to highlight things that are different from normal provisioning 
and explain why they're important.

3.1 - wouldn't it be sFTP/SCP or HTTPS or some similar?
Direct/indirect makes sense, but the process for indirect transfer is a little 
light on details - what steps must be taken to ensure that the keys are not 
compromised in this transfer, either from the router or to the RPKI CA? Even a 
reference to section 5 might be enough to cover this.
Also, I don't follow your last sentence "...linkage between private key and a 
router..." - why is that important?

3.2 "installed over the ssh session..." - are we talking simple copy and paste 
of a huge string of text representing the key, or is it actually SCP/SFTP of a 
file that is then read into the router's config via additional commands?
If you're talking copy/paste, it's probably worth warning that for keys over a 
certain size, this method is error-prone. I've seen a lot of mangled config 
because someone exceeded a paste buffer when trying to copy/paste a config, 
especially over a 9600 bps console at the other end of 90ms of latency.

5. when you talk about offload methods, you should probably specify the 
required/recommended security precautions associated with handling the key so 
that it isn't intercepted across the transfer method used (e.g. use SNMPv3 with 
encryption, use sFTP/SCP, CLI with SSH, etc, as well as any considerations 
around chain of possession and level of trust as the keys are stored and 
transferred between old and new box. There are a lot of risk factors if a tech 
is transferring it to his (possibly compromised) laptop when compared with 
transferring to parts of the infrastru

[sidr] FW: New Version Notification for draft-george-sidr-as-migration-01.txt

[George, Wes]

This draft is a significant update from the -00 version, including the addition 
of the solution we discussed in Atlanta. Sandy Murphy (temporarily devoid of 
her festive WG chair regalia) has been added as a co-author, thanks to her 
extensive contributions in the solution and example section and her thorough 
review of the rest. I think it's complete enough to request some additional 
reviews and adoption as a WG draft. I will note that it is currently still an 
informational document. I don't know if it would be more appropriate for it to 
be PS given that it does require some changes that could arguably be considered 
protocol changes.

Thanks
Wes George

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Friday, February 01, 2013 9:13 AM
To: George, Wes
Cc: sa...@tislabs.com
Subject: New Version Notification for draft-george-sidr-as-migration-01.txt


A new version of I-D, draft-george-sidr-as-migration-01.txt
has been successfully submitted by Wesley George and posted to the IETF 
repository.

Filename:draft-george-sidr-as-migration
Revision:01
Title:   BGPSec Considerations for AS Migration
Creation date:   2013-02-01
WG ID:   Individual Submission
Number of pages: 14
URL: 
http://www.ietf.org/internet-drafts/draft-george-sidr-as-migration-01.txt
Status:  http://datatracker.ietf.org/doc/draft-george-sidr-as-migration
Htmlized:http://tools.ietf.org/html/draft-george-sidr-as-migration-01
Diff:
http://www.ietf.org/rfcdiff?url2=draft-george-sidr-as-migration-01

Abstract:
   This draft discusses considerations and methods for supporting and
   securing a common method for AS-Migration within the BGPSec protocol.




The IETF Secretariat


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Poll: WG acceptance of draft-ymbk-rpki-grandparenting-02

[George, Wes]

>
> 1) Is the problem described/solved by draft-ymbk-rpki-grandparenting-02
> actually a problem that the WG needs to address? (Answer: yes or no.
> Additional information is welcomed, but I don't want people to repeat
> the whole discussion.)
[WEG] yes, but I tend to agree that it's not a technical problem.
>
> 2) If you answered "yes" to the question #1, please also answer the
> following question:
>
> Is draft-ymbk-rpki-grandparenting-02 a reasonable starting point to
> become a WG document? Please choose one of the following:
>
>
> a) Ready for Adoption (whether or not you have some specific issues with
> it. Also, this answer is unrelated to whether this should be a separate
> draft or a part of an existing draft).
>
> b) Needs more work BEFORE Adoption
>
> c) Should not be adopted. In particular this mean that you don't believe
> any amount of work on the proposed draft will address your issues. So
> any solution to this problem should be a new draft written from scratch.
>
> d) Abstain/don't care
[WEG] b. The text itself is ok, but we need to resolve #3 before adoption.
>
>
> 3) If you answered "a" or "b" above, please also answer the following
> question:
>
> Does this need to be in a standalone draft, or can it be incorporated
> into another existing WG draft? When answering this question please only
> base your answer on technical reasons, in particular please leave the
> decision on who is going to edit the document (if it is standalone) to
> WG chairs.
[WEG] It needs to be incorporated into an existing draft.
This text is covering a very specific gotcha with some helpful recommendations 
and no actual requirements. It currently reads like an orphaned section of 
another draft, probably the operational considerations (origin-ops) draft.


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting

[George, Wes]

> From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of
> Alexey Melnikov
> >
> >> On Mon, Oct 15, 2012 at 1:36 AM, Byron Ellacott 
> wrote:
> >>> Hi Chris,
> >>>
> >>> When did the WG reach consensus on adopting this draft?
> >> when it spent ~50 mesasages discussing it?
> >> it seems that, even if we abandon it in the end, discussing this over
> >> a draft is a good thing to do.
[WEG] Chris, I realize that every WG and WG Chair has a different 
interpretation of the discuss/adoption/refinement/WGLC lifecycle, but IMO, 
discussion != "should adopt". There are plenty of drafts that get lots of 
discussion because lots of people say "stop, no, this is a bad idea" or there 
is controversy over a specific part of the draft along with some back-and-forth 
with the authors as they defend or refine their idea. In some WGs (which shall 
remain nameless to protect the clueless), 50 messages can show up in *one day* 
on a draft that is never going to be adopted.

> Byron and others,
> I think WG chairs (collectively) dropped the ball here: 3 of us have
> discussed the acceptance call a couple of times. We would like to
> apologize for sending inconsistent messages.
>
> After talking to various people this week, it looks like the best way
> forward is for the chairs to redo the acceptance call and ask very
> specific questions to keep everybody unconfused and hopefully happy.
>

I see two questions the WG needs to answer:
1) Is the problem described/solved by this draft actually a problem that we 
need to address?
2) Does this need to be in a standalone draft, or can it be incorporated into 
another existing draft

If #1 is yes, even if people don't agree with the solution proposed, that's a 
decent starting point for refinement.

As to the need to have refinement discussions over a document: I posed question 
#2 during the adoption call, and the reasoning for having it as a separate 
draft was never really discussed, so I think that's still outstanding. 
Personally I think the answer to #1 is probably yes, so I'm not opposed to the 
*content* and think it's worthwhile to refine it, but I'm not convinced it 
needs to be separate.

With apologies to Wheeler/Henney - all problems can be solved with another IETF 
draft, except the problem of too many IETF drafts.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] comments on recent as migration drafts

[George, Wes]

> From: Murphy, Sandra [mailto:sandra.mur...@sparta.com]
>
> No, I did not mean to suggest that there was an actual ebgp session.  I
> think maybe I was reading the replace-as example incorrectly.  I am not
> sure what the AS_PATH is when it is transmitted between PE1 and PE2 and
> it looked like PE1 might be adding ASNs to the AS_PATH it sent over the
> ibgp session to PE2.
[WEG] I think maybe the confusion comes from the fact that these commands have 
to interact with BGP route updates in both directions (PE-> CE and CE -> PE). 
In the routes that the PE receives from the CE, it has to make the change in AS 
in the AS_PATH so that the rest of the routers in its global ASN don't see 
routes with the configured local ASN in the path, but the way I think of it is 
that it's doing this when it receives and processes the routes from the CE 
before it installs them into its RIB, not when it generates the updates towards 
its neighbors, since this is a neighbor-specific configuration rather than a 
global one.

>
> I think this is already a MUST in the protocol because the protocol
> makes sure the AS listed are the ones that the packet came through.  If
> the update came from the neighbor and the first AS in the path is not
> the neighbor's AS, then the validation will fail.  (Unless the neighbor
> has the keys to two ASs and uses an AS other than is used in the OPEN
> packet.  It's all about the keys.)
[WEG] Understand that. I was specifically asking about the case where the PE is 
in possession of keys for both ASNs and therefore can choose which of the two 
valid ASNs to sign with. Does it fail if the signature is valid but the AS in 
the OPEN message is different from the one in the signature? If not, should it, 
or are we expecting similar behavior to the "enforce-first-AS" keyword, where 
by default it fails, but you can twist a knob to make it acceptable? I think 
this is one of those things that we have to be clear about which way we want 
the behavior to be, since it's a MAY in BGP. It is even more important to 
specify if it has to be a certain way in order to prevent security concerns in 
BGPSec.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] comments on recent as migration drafts

[George, Wes]

Thanks for the quick review. Responses below inline.


> From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of
> Murphy, Sandra
>
> It appears to me that the ga-idr-as-migration talks about a merger of AS
> 200 and AS 300, with AS 200 being the eventually retained ASN but
> george-sidr-as-migration talks about a merger of AS 200 and AS 300 with
> AS 300 being the eventually retained ASN.  If that is true, then those
> reading both drafts should keep that in mind when looking at the
> examples.
[WEG] oops. Sigh. I'll get that corrected in subsequent versions of george-sidr 
so that the two agree.
>
> In the idr-as-migration draft, from the discussion it appears that the
> implementation of the local-as feature on the PE router in AS supports
> the local-as as something like an ebgp session inside the router.  (like
> it adds the old 300 ASN on AS_PATHs sent over ibgp sessions to AS 200
> neighbors).  Am I understanding the examples correctly?
[WEG] Not exactly no. There's no additional internal eBGP session between the 
two ASNs on the PE, and remember that the PE has been reconfigured to be in the 
retained AS, not the legacy one, so this local-as and its related switches are 
used on the PE-CE sessions and their associated updates, not PE-PE. All it's 
doing is overriding the values from the global config that would normally be 
used to populate "MY ASN" and "AS_PATH" when generating BGP messages to a 
specific neighbor.

>
> The goal is for the AS_PATH length to be the same length in the
> migration interval as it was before migration.  Does it matter if that
> effect is accomplished some other way than the knobs currently
> implemented?
[WEG] the implementation details probably don't matter if the result is the 
same, other than the fact that this one exists and is in lots of code, while a 
different approach may not be widely implemented. You could make the argument 
that since we're talking about trying to make this work on BGPSec-capable 
routers, you could also assume that a BGPSec-friendly AS-migration method would 
also be supported in the same code I guess, but that's only if it's a required 
feature as a part of the BGPSec implementation. If it's a standalone, it might 
require code upgrades that may not be possible for a number of different 
reasons.

 IE the local-as knob has a side effect of getting the 300
> ASN into the AS_PATH to ibgp neighbors so the second knob no-prepend
> makes that go away.  Do you need both behaviors -- local-as AND local-as
> + no-prepend?  Would it be OK if the side effect did not happen and you
> got to the no-increase-in-path-length goal without needing the no-
> prepend knob?
[WEG] different use cases require different configurations. Local-AS no-prepend 
ensures that the AS_PATH length doesn't change, which is critical to this 
migration technique, so I guess it's safe to say that you don't need the 
local-as behavior by itself, but that if you don't care about the AS-path 
length, using only local-as will still enable you to change the global BGP AS 
of the PE for migrations, and will be less complex/risky since you're not 
manipulating the AS_PATH in ways that could result in route loops.
>
> wrt the replace-as technique.  The text says that "only the historical
> (or, legacy) AS will be prepended in the outbound BGP UPDATE toward the
> customer's network".  But the example says "After ISP A' changes PE-1 to
> include the "Replace AS" feature, CE-1 would receive an AS_PATH of: 200
> 400. " That is indeed "the same AS_PATH length pre-AS migration" as the
> text says, which accomplishes that goal, but it would require
> configuration of the CE router to accept a first-as that was different
> from the one used in the OPEN.  I suspect that's a typo, that is after
> using replace-as the AS_PATH toward the CE would be "300 400".  But it
> is an important point so I'd like to make sure.
[WEG] I think you're right that it's a typo, I'll doublecheck with my co-author.
>From the referenced cisco doc: "The replace-as keyword is used to prepend only 
>the local autonomous-system number (as configured with the ip-address 
>argument) to the AS_PATH attribute. The autonomous-system number from the 
>local BGP routing process is not prepended."

However...
4271 6.3 lists the requirement you mention for the Open "My ASN" value and 
AS_Path to match as a MAY:
   "If the UPDATE message is received from an external peer, the local
   system MAY check whether the leftmost (with respect to the position
   of octets in the protocol message) AS in the AS_PATH attribute is
   equal to the autonomous system number of the peer that sent the
   message.  If the check determines this is not the case, the Error
   Subcode MUST be set to Malformed AS_PATH."
I don't know if most common implementations perform this check. In fact, that's 
why I point out that the question needs to be answered as far as path 
validation is concerned - does the ASN of the established neighbor

[sidr] FW: New Version Notification for draft-george-sidr-as-migration-00.txt

[George, Wes]

Folks, this is the companion draft to draft-ga-idr-as-migration that discusses 
the specific implications to SIDR. I'll caveat by saying that it's quite likely 
that I have a few mistakes in terminology and would appreciate any corrections 
to make the discussion crisper and clearer, but I think I have at least some of 
the considerations documented in a way that we can have some more discussion 
about it. This probably isn't a complete set of considerations yet, but 
hopefully this will get folks thinking about it so that they come up with 
others.

Thanks,

Wes



-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Monday, September 24, 2012 1:21 PM
To: George, Wes
Subject: New Version Notification for draft-george-sidr-as-migration-00.txt


A new version of I-D, draft-george-sidr-as-migration-00.txt
has been successfully submitted by Wesley George and posted to the IETF 
repository.

Filename:draft-george-sidr-as-migration
Revision:00
Title:   BGPSec Considerations for AS Migration
Creation date:   2012-09-24
WG ID:   Individual Submission
Number of pages: 8
URL: 
http://www.ietf.org/internet-drafts/draft-george-sidr-as-migration-00.txt
Status:  http://datatracker.ietf.org/doc/draft-george-sidr-as-migration
Htmlized:http://tools.ietf.org/html/draft-george-sidr-as-migration-00


Abstract:
   This draft discusses considerations for supporting and securing a
   common method for AS-Migration within the BGPSec protocol.




The IETF Secretariat


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] WGLC for draft-ietf-sidr-bgpsec-protocol-05

[George, Wes]

> From: Murphy, Sandra [mailto:sandra.mur...@sparta.com]
> Sent: Tuesday, September 18, 2012 5:04 PM
> To: George, Wes; sidr@ietf.org
> Subject: RE: WGLC for draft-ietf-sidr-bgpsec-protocol-05
>
> The use of pcount=0 was hoped/expected to require NO changes in the
> update validation algorithm.  If you have discovered places where it
> would require changes, it will indeed be interesting to see and discuss.

[WEG] use of pcount=0 for AS migration may not require changes to the 
*algorithm* itself, as much as it will simply require discussion of the process 
for handling pcount=0 in the cases where it is used and the neighbor is not a 
transparent route-server, since currently that case is discussed specifically 
in the draft, and there is a specific recommendation that pcount=0 updates be 
dropped if they didn't come from a known route-server neighbor.

That said, I'm not convinced it completely solves the problem, as I (hopefully) 
articulated in my pending draft, and *that* may require algorithm changes.

Wes

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] WGLC for draft-ietf-sidr-bgpsec-protocol-05

[George, Wes]

Nits:
Multiple sections have "musts" and "shoulds" that are not 2119-formatted 
(lower-case) - please ensure that this is intentional

Substantial:

Any reason why we're using "good" and "not good"  for validation state instead 
of valid/invalid (and unknown)? I'd think that consistency between this and the 
language in the origin validation stuff would be helpful unless we have a 
specific reason not to use the same language. And I realize that there isn't 
really an "unknown" status as the result of trying to validate a BGPSec update, 
but as far as the implementation is concerned, standard BGP updates (those 
without BGPSec) are considered unknown, and it might be good to explicitly 
state that as a part of the validation algorithm.

I'm awaiting co-author review of the I-D version of the email I wrote about 
AS-Migration, and am hoping to have it posted next week sometime. I think that 
we need to discuss the considerations from that issue to ensure that no changes 
need to be made in the protocol spec document/design before we progress this. 
There's been some discussion of using pcount=0 to manage some parts of this, 
but that would have to be covered in the update validation and origination 
algorithm if we choose to solve the problem that way. Also I'm not completely 
certain that pcount will solve the use case completely. I'm not opposed to 
using the draft as a follow-on to the protocol draft (update it) to handle this 
specific case, but I'd like to have WG consensus that this is the route we 
should take rather than incorporating any solution for this use case into the 
current document since it is still in draft.

Thanks,

Wes George


> -Original Message-
> From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of
> Murphy, Sandra
> Sent: Saturday, September 15, 2012 7:45 AM
> To: sidr@ietf.org
> Subject: [sidr] WGLC for draft-ietf-sidr-bgpsec-protocol-05
>
> This starts a working group last call for draft-ietf-sidr-bgpsec-
> protocol-05.  The draft is available at
> http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-05 and
> https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/
>
> Please review this draft to see if you think it is ready for
> publication.  Send end comments to the list.
>
> The WGLC will end on 29 September 2012.
>
> --Sandy, speaking as wg co-chair
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] WGLC: draft-ietf-sidr-origin-ops-

[George, Wes]

I think we're ready to move this on, and I commend Randy for his work on it.

The only substantive comment I have is something that I believe Shane and I 
raised in previous versions' review and is not addressed yet. In section 3, 
where it discusses location of cache relative to routers "...'close' is of 
course complex..." - the current text still does not adequately explain why 
'close' is a recommendation, or how latency might affect performance of the 
chosen deployment. This is a system that is by nature a loosely synchronized 
system, asymmetric in distribution of information, where elsewhere in this doc 
we say that the clock has to be accurate to the hour, which isn't exactly a 
high bar. If latency is a consideration, we need a bound on that - how much is 
too much latency such that the cache should be closer to the consuming 
router(s)? If there isn't a definite recommendation, what is the consideration 
that operators should be using to determine latency's impact? Is this just 
about latency's impact on TCP throughput, or is there something more comple
 x to be considered?
I'd suggest text, but I still don't understand why geographic proximity 
matters. Reachability, sure, but not proximity.

Similarly with "consider trust boundaries..." - what should one be considering 
here? How are trust boundaries related to a cache's proximity to a given router?

I understand why bootstrap reachability between router and cache is important, 
but a few additional words about the reason might be helpful for the intended 
audience (that is, operators implementing RPKI for the first time)
Suggested text: "If the cache is not reachable via IGP or even locally, this 
will delay initial synchronization with the RPKI cache on boot, and may cause 
multiple BGP convergence events, first without RPKI data, and then again once 
RPKI data is synchronized."

Generally, if we are recommending that there should be some sort of proximity, 
we need to provide some rationale or a view into the considerations that went 
into that recommendation so that operators can make their own informed decision 
about placement, justify standalone equipment instead of VMs, etc. Otherwise, I 
can see having the following discussion with our systems folks internally:
"This RPKI cache thingy is just a server with an app running on it, right?"
"yeah"
"ok, we're going to stick it in a VM on our two national data center compute 
infrastructures like the rest of our servers, we can spin up more instances if 
you need to scale it"
"but RFC mumble mumble says that we shouldn't do that..."
"ok, why? And where do you want to put it?"
"ummm... 'close' to the routers? Because...reasons"

Thanks,

Wes George


> -Original Message-
> From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of
> Christopher Morrow
> Sent: Friday, August 17, 2012 11:03 AM
> To: sidr@ietf.org; sidr-cha...@ietf.org; sidr-...@tools.ietf.org
> Subject: [sidr] WGLC: draft-ietf-sidr-origin-ops-
>
> Hello WG folk,
> This draft has undergone 9 revisions since the last WGLC, which seemed
> to end with requests for changes by the authors.
> Can we now have a final-final-please-let's-progress WGLC for this draft
> now? Let's end the call: 08/31/2012 (Aug 31 2012).
>
> Htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-sidr-origin-ops-19
>
> Abstract:
> "Deployment of RPKI-based BGP origin validation has many operational
>considerations.  This document attempts to collect and present the
>most critical.  It is expected to evolve as RPKI-based origin
>validation is deployed and the dynamics are better understood."
>
> Thanks!
> -Chris
> 
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting

[George, Wes]

As I noted at the mic, I’d much prefer that we find a place to incorporate the 
information in this draft into an existing draft(s). I don’t understand the 
need for having this info separated in yet another draft and therefore do not 
support adoption. I think the information is useful, just would prefer it 
integrated into an existing document.
If the best place for it would be in a document that is already an RFC, then I 
support adoption, with the caveat that it should formally update the 
appropriate document to make it easier to track the info.

The reason I don’t make a specific recommendation as to which document it 
belongs in is precisely why I think we shouldn’t have this in a separate 
document if at all possible – I simply can’t keep track of where all of the 
information lives because it’s spread across so many drafts.

Thanks,

Wes


From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of Alexey 
Melnikov
Sent: Saturday, August 04, 2012 2:13 PM
To: sidr@ietf.org
Subject: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting

Hi,
On behalf of SIDR WG chairs I would like to initiate 2 weeks acceptance call 
for draft-ymbk-rpki-grandparenting starting from today, August 4th. Please send 
your positive or negative feedback to the mailing list or directly to chairs.


Thank you,
Alexey




This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] WG Adoption call for draft-rogaglia-sidr-bgpsec-rollover-01.txt

[George, Wes]

Apologies for my tardiness.
Read and support.

Wes George



> -Original Message-
> From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of
> Murphy, Sandra
> Sent: Thursday, June 28, 2012 4:46 PM
> To: Roque Gagliano (rogaglia); sidr@ietf.org
> Cc: sidr-cha...@ietf.org
> Subject: Re: [sidr] WG Adoption call for draft-rogaglia-sidr-bgpsec-
> rollover-01.txt
>
> There were only two responses to this call for adoption.  Both were
> positive (and one was followed by extensive comments), but that's a
> pretty low indication of wg interest.
>
> On the chance that people might be on holiday, we will give the wg until
> 5 July (one week from today) to consider this work.
>
> This is your last chance, so speak up.
>
> --Sandy, speaking as wg co-chair
> 
> From: sidr-boun...@ietf.org [sidr-boun...@ietf.org] on behalf of Murphy,
> Sandra [sandra.mur...@sparta.com]
> Sent: Tuesday, June 12, 2012 5:27 PM
> To: Roque Gagliano (rogaglia); sidr@ietf.org
> Cc: sidr-cha...@ietf.org
> Subject: [sidr] WG Adoption call fordraft-rogaglia-sidr-bgpsec-
> rollover-01.txt
>
> The authors request below that the wg adopt this work as a work item.
>
> The draft is available at http://tools.ietf.org/html/draft-rogaglia-
> sidr-bgpsec-rollover.
>
> Please respond to the list to say whether you accept this draft as a
> working group draft and are willing to work on it.  Remember that you do
> not need to accept all content in a draft to adopt, as draft editors are
> required to reflect the consensus of the working group.
>
> This call will end 26 Jun 2012.
>
> --Sandy, speaking as wg co-chair
>
>
>
> From: sidr-boun...@ietf.org [sidr-boun...@ietf.org] on behalf of Roque
> Gagliano (rogaglia) [rogag...@cisco.com]
>
> Sent: Tuesday, June 05, 2012 8:05 AM
>
> To: sidr@ietf.org
>
> Subject: [sidr] Fwd: New Version Notification for draft-rogaglia-sidr-
> bgpsec-rollover-01.txt
>
>
>
>
>
> Dear WG,
>
>
>
> We submitted a new version of this draft based on the feedback from our
> last meeting in Paris.
>
>
>
> As mentioned during Brian's presentation we would like to ask for WG
> adoption.
>
>
>
> Regards,
> Roque
>
>
>
>
> Begin forwarded message:
>
>
>
> From: 
>
>
>
> Date: June 5, 2012 1:58:52 PM GMT+02:00
>
>
>
> To: 
>
>
>
> Cc: ,
>  
>
>
>
> Subject: New Version Notification for draft-rogaglia-sidr-bgpsec-
> rollover-01.txt
>
>
>
>
> A new version of I-D, draft-rogaglia-sidr-bgpsec-rollover-01.txt has
> been successfully submitted by Roque Gagliano and posted to the IETF
> repository.
>
>
>
> Filename: draft-rogaglia-sidr-bgpsec-rollover
>
> Revision: 01
>
> Title: BGPSEC router key rollover as an alternative to beaconing
>
> Creation date: 2012-06-05
>
> WG ID: Individual Submission
>
> Number of pages: 15
>
>
>
> Abstract:
>
>   The current BGPSEC draft documents do not specifies a key rollover
>
>   process for routers.  This document describes a possible key rollover
>
>   process and explores its impact to mitigate replay attacks and
>
>   eliminate the need for beaconing in BGPSEC.
>
>
>
>
>
>
>
>
>
> The IETF Secretariat
>
>
>
>
>
>
>
>
>
>
> ___
> 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

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] AS Migration and aliasing

[George, Wes]

I unfortunately won't be attending much of today's interim if at all - $day_job 
calls...

Thanks,

Wes

> -Original Message-
> From: Murphy, Sandra [mailto:sandra.mur...@sparta.com]
> Sent: Thursday, June 28, 2012 6:20 PM
> To: George, Wes; sidr wg list (sidr@ietf.org)
> Subject: RE: AS Migration and aliasing
>
> Lots of stuff to consider here!
>
> Last minute, but would you like to fit this into the interim meeting
> tomorrow?
>
> --Sandy, speaking as co-chair
> 
> From: sidr-boun...@ietf.org [sidr-boun...@ietf.org] on behalf of George,
> Wes [wesley.geo...@twcable.com]
> Sent: Thursday, June 28, 2012 4:27 PM
> To: sidr wg list (sidr@ietf.org)
> Subject: [sidr] AS Migration and aliasing
>
> During the last SIDR Interim, we talked about BGP Aliasing as a means to
> migrate from one ASN to another. I proxied some concerns from Shane
> Amante and others who weren't present, but I ended up being the stuckee
> to write up the requirements/use case so that we can make sure that it's
> being appropriately addressed. Shane and I have worked to put together
> the below. If it's helpful to put this in draft form, we're happy to do
> so, or the relevant bits of text can be incorporated into existing
> drafts, or whatever. I figured the main thing was that I needed to get
> this out of my edit buffer and in front of the right people without any
> additional delay so that we can discuss it further as necessary, so I'm
> sending it to the list as raw text for now.
>
>
>
>
> General scenario - merging two or more ASNs, where eventually one
> subsumes the other(s). Confederations are NOT being implemented between
> the ASNs. In this example, AS200 is being subsumed by AS300. The reason
> that this may drive a slightly different solution in BGPSec than a
> standard confederation is that unlike in a confed, eBGP peers may not be
> peering with the "correct" external ASN, and the forward-signed updates
> are for a public ASN, rather than a private one, so there is no
> expectation that we should strip them.
>
> There are two types/directions of migration to consider, each of which
> uses some set of implementation-specific knobs to tweak the AS-Path.
> It's important to emphasize that a fundamental goal of these
> "proprietary knobs" is to (absolutely) ensure that you are NOT changing
> the AS_PATH length during the ASN migration.  Note, this is critical in
> *both* the inbound (CE -> PE) and outbound (PE -> CE) directions.  This
> is important because for large carriers who bill customers based on bits
> (usage), any lengthening of the AS_PATH in either direction will cause
> traffic to shift away from their network, which is bad (less usage ==
> less revenue).
>
> Local-AS: You have an end customer/eBGP peer that is peering with AS200.
> You wish to reconfigure that router to be in AS300, and need to be able
> to do so without disrupting/coordinating the change with all of the eBGP
> peers simultaneously. So you reconfigure the peers with Local AS 200 so
> that the router still appears to be in the same ASN. However, if the
> peer is doing BGPSec, you have some additional wrinkles. For outbound
> announcements, this would require the router to have the right keys for
> AS200 so that it can continue signing with the right ASN towards peers
> configured this way.
> Inbound is more complicated - the peer doesn't know that you've changed
> ASNs, so it is forward-signing all of its routes with AS200, not AS300.
> How do you fix?
>
> Reference:
> http://www.cisco.com/en/US/docs/ios/12_2t/12_2t11/feature/guide/ft11bhla
> .html
>
> In the direction of CE -> PE (inbound), and speaking about IOS
> specifically, (although equivalent knobs do exist in JUNOS and possibly
> others):
> 1)  'local-as ': appends the  value to the AS_PATH of
> routes received from the CE
> 2)  'local-as  no-prepend': DOES NOT prepend  value to
> the AS_PATH of routes received from the CE.
>
> For the reason stated above, one prefers configuration #2.  This ensures
> that routes received by a PE through eBGP sessions with this 'local-as
>  no-prepend' knob configured get transmitted out to SFI peers
> and/or customers with normal/natural  neighbor sessions so that
> they do not see a longer AS_PATH.  IOW, if you had the following:
>
> NOTE: Direction of BGP Update as per the arrows.
> PE-1 is a PE whose "global configuration AS" has been changed from AS
> 200 to AS 300 to make it part of the "go forward/keep" ASN.
> PE-1 needs the configuration:
>
> router bgp 300
>  neighbor  remote-as 400
>  neighbor  loca

[sidr] AS Migration and aliasing

[George, Wes]

During the last SIDR Interim, we talked about BGP Aliasing as a means to 
migrate from one ASN to another. I proxied some concerns from Shane Amante and 
others who weren't present, but I ended up being the stuckee to write up the 
requirements/use case so that we can make sure that it's being appropriately 
addressed. Shane and I have worked to put together the below. If it's helpful 
to put this in draft form, we're happy to do so, or the relevant bits of text 
can be incorporated into existing drafts, or whatever. I figured the main thing 
was that I needed to get this out of my edit buffer and in front of the right 
people without any additional delay so that we can discuss it further as 
necessary, so I'm sending it to the list as raw text for now.




General scenario - merging two or more ASNs, where eventually one subsumes the 
other(s). Confederations are NOT being implemented between the ASNs. In this 
example, AS200 is being subsumed by AS300. The reason that this may drive a 
slightly different solution in BGPSec than a standard confederation is that 
unlike in a confed, eBGP peers may not be peering with the "correct" external 
ASN, and the forward-signed updates are for a public ASN, rather than a private 
one, so there is no expectation that we should strip them.

There are two types/directions of migration to consider, each of which uses 
some set of implementation-specific knobs to tweak the AS-Path. It's important 
to emphasize that a fundamental goal of these "proprietary knobs" is to 
(absolutely) ensure that you are NOT changing the AS_PATH length during the ASN 
migration.  Note, this is critical in *both* the inbound (CE -> PE) and 
outbound (PE -> CE) directions.  This is important because for large carriers 
who bill customers based on bits (usage), any lengthening of the AS_PATH in 
either direction will cause traffic to shift away from their network, which is 
bad (less usage == less revenue).

Local-AS: You have an end customer/eBGP peer that is peering with AS200. You 
wish to reconfigure that router to be in AS300, and need to be able to do so 
without disrupting/coordinating the change with all of the eBGP peers 
simultaneously. So you reconfigure the peers with Local AS 200 so that the 
router still appears to be in the same ASN. However, if the peer is doing 
BGPSec, you have some additional wrinkles. For outbound announcements, this 
would require the router to have the right keys for AS200 so that it can 
continue signing with the right ASN towards peers configured this way.
Inbound is more complicated - the peer doesn't know that you've changed ASNs, 
so it is forward-signing all of its routes with AS200, not AS300. How do you 
fix?

Reference:
http://www.cisco.com/en/US/docs/ios/12_2t/12_2t11/feature/guide/ft11bhla.html

In the direction of CE -> PE (inbound), and speaking about IOS specifically, 
(although equivalent knobs do exist in JUNOS and possibly others):
1)  'local-as ': appends the  value to the AS_PATH of routes 
received from the CE
2)  'local-as  no-prepend': DOES NOT prepend  value to the 
AS_PATH of routes received from the CE.

For the reason stated above, one prefers configuration #2.  This ensures that 
routes received by a PE through eBGP sessions with this 'local-as  
no-prepend' knob configured get transmitted out to SFI peers and/or customers 
with normal/natural  neighbor sessions so that they do not see a 
longer AS_PATH.  IOW, if you had the following:

NOTE: Direction of BGP Update as per the arrows.
PE-1 is a PE whose "global configuration AS" has been changed from AS 200 to AS 
300 to make it part of the "go forward/keep" ASN.
PE-1 needs the configuration:

router bgp 300
 neighbor  remote-as 400
 neighbor  local-as 300 no-prepend

CE-1 ---> PE-1 ---> PE-2 ---> CE-2
 400  Old_ASN: 200  New_ASN: 300  100
  New_ASN: 300

CE-2 should see an AS_PATH that looks like: 400 300, (without seeing AS 200 
*anywhere* in the AS_PATH due to the 'local-as no-prepend' knob).  (NOTE: if 
you *just* had the "local-as 300" knob configured on PE-1, then CE-2 would see 
an AS_PATH that looked like: 400 200 300).

So, to answer the questions above: yes, in a BGPSec world, CE-1 in AS 400 would 
(by default) be forward-signing toward , (a.k.a: AS 200).  I'm 
guessing the ISP would still need to publish public-keys for AS 200 if it is to 
appear in the BGPSec_Path_Signature in order that receivers can validate the 
BGPSEC_Path_Signature arrived intact/whole.  And, you need to roll the keys for 
AS 200 indefinitely (or, as long as you keep AS 200 around in your network).


Replace-AS: You are trying to remove AS200 from the AS-path to ensure that 
routes learned from AS200 don't have a longer AS-path and/or you want to make 
them look like they only transited AS300, not AS200->AS300. So you configure 
routers to do replace-AS. How do you manage the routes that have been 
forward-signed into AS200? What about routes originated by AS2

Re: [sidr] Confeds and clusters

[George, Wes]

> -Original Message-
> From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of
> Jakob Heitz
> Sent: Saturday, June 16, 2012 3:31 AM
>
> IMHO: AS boundaries are for marking boundaries of trust.
> Confeds are for achieving scalability within an AS.

[WEG] Yes and no. While confeds are sometimes used for scale, they aren't 
*exclusively* used for scale, and therefore your two statements are in conflict 
with one another. In some cases Confeds have nothing to do with scale and 
everything to do with boundaries of trust for those of us with different 
internal and autonomous organizations responsible for managing different parts 
of our network. A confed requires some manner of coordination between the 
members of the confed, but it in no way implies that all of the members of the 
confed are centrally managed, nor should it.

Wes George


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] draft-ymbk-rpki-grandparenting-00.txt

[George, Wes]

Randy -

I'm thinking that there's a simpler use case for this -

In the situation where A delegated space to C, who delegated it further to G, 
and G would like help managing data, but C is not willing or able to do so, and 
so G works with A to make this happen. The concept of changing providers may 
not be necessary to illustrate the point.

Regarding adoption, I'm not certain I understand from the current text why this 
can't be incorporated into existing drafts as a brief note. If I'm interpreting 
this draft correctly, you're saying that there's nothing technically hard about 
doing this, but that there are some business and contractual issues to deal 
with, mainly on account of the potentially fractured business relationship 
between the parties involved, and proper validation of the information you're 
certifying. But that's true of any relationship where one party certifies on 
anothers' behalf. What's different about this case that requires it to be 
treated separately from other operational considerations? I love the 
"responsible grandparenting" title, but I'm just thinking it's easier for 
reader and implementer alike if this is consolidated.

Thanks,

Wes George


> -Original Message-
> From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of
> Randy Bush
> Sent: Wednesday, June 06, 2012 10:00 AM
> To: sidr wg list
> Subject: [sidr] draft-ymbk-rpki-grandparenting-00.txt
>
> this draft is relevant to the sidr wg work and i, as author, request it
> be made a work item.
>
> randy
>
>
> From: internet-dra...@ietf.org
> To: ra...@psg.com
> Subject: New Version Notification for draft-ymbk-rpki-grandparenting-
> 00.txt
> Message-ID: <20120606135903.5473.73476.idtrac...@ietfa.amsl.com>
> Date: Wed, 06 Jun 2012 06:59:03 -0700
>
> A new version of I-D, draft-ymbk-rpki-grandparenting-00.txt has been
> succes= sfully submitted by Randy Bush and posted to the IETF
> repository.
>
> Filename:  draft-ymbk-rpki-grandparenting
> Revision:  00
> Title: Responsible Grandparenting in the RPKI
> Creation date: 2012-06-06
> WG ID: Individual Submission
> Number of pages: 5
>
> Abstract:
>There are circumstances in RPKI operations where a resource
> holder's
>parent may not be able to, or may not choose to, facilitate full and
>proper registration of the holder's data.  As in real life, the
>holder may form a relationship to their grandparent who is willing to
>aid the grandchild.  This document describes simple procedures for
>doing so.
>
>
> The IETF Secretariat
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] WGLC for draft-ietf-sidr-pfx-validate-06

[George, Wes]

I have read this draft and previous versions and I support publishing it.

One nit - we've had several conversations about whether to use AS_Path as 
synonymous with AS4_Path since we require (with a MUST) support for 4-octet 
ASNs. I don't remember which way we came down on the matter, whether to 
explicitly say AS4_PATH since that is what will really be used, or to leave 
that as an exercise for the implementer.

Thanks,

Wes George



> -Original Message-
> From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of
> Murphy, Sandra
> Sent: Friday, June 01, 2012 7:00 PM
> To: sidr@ietf.org
> Subject: [sidr] WGLC for draft-ietf-sidr-pfx-validate-06
>
> The authors have stated that they believe that draft-ietf-sidr-pfx-
> validate-06 "BGP Prefix Origin Validation" is ready for a working group
> last call.
>
> The draft can be accessed at http://tools.ietf.org/html/draft-ietf-sidr-
> pfx-validate-06 and https://datatracker.ietf.org/doc/draft-ietf-sidr-
> pfx-validate/
>
> This announces the beginning of the wglc.  The last call will end on
> Friday, 15 Jun 2012.
>
> Please judge whether you believe that this work is ready for publication
> and send any comments to the list.
>
> --Sandy, speaking as wg co-chair
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] request for agenda items for interim meeting 6 Jun

[George, Wes]

> From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of
> Randy Bush
> Sent: Wednesday, May 23, 2012 6:09 PM
> To: Murphy, Sandra
> Cc: sidr@ietf.org
> Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun
>
> > In the interim in San Diego, there were requests (from operators) that
> > guidance to operators of how to provision a router with the needed
> > keys would be a good idea.  We had some discussion in the Paris
> > meeting of two drafts discussing provisioning the routers with their
> > needed private keys.  There's also been a recent flurry of discussion
> > on the list.
>
> no comments on the new version of draft-ietf-sidr-rtr-keying-00.txt.
> would appreciate some now or we can ask for wglc.
>

[WEG] We're again having an interim collocated with NANOG, ostensibly to gain 
additional operator participation (as well as batch travel).
However, in order to gain any benefit from the location, we probably need to 
publicize the interim on the NANOG list, though the window for doing it before 
travel plans are made is probably closing/closed.
Wasn't it on the NANOG agenda in SD? It's not this time...
It may even be useful to have a set of questions to fire off in a lightning 
talk regarding the things we plan to discuss in more detail over the course of 
the interim, so that people who have opinions on the matters can weigh in.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] docco changes from minutes

[George, Wes]

> -Original Message-
> From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of
> Randy Bush
>
> so i reviewed the minutes from last month, looking for what i had to hack in
> the docs i edit.

> surely there was more.  help!!!
>

[WEG] I have some notes implying I owe you text, but one of them is a bit 
cryptic through the filter of waiting too long after the meeting to look at it, 
perhaps it'll make sense if we both stare at it?

Send Randy text about *why* you should drop invalid

Origin ops/ BGP Sec ops
Text - Deploy (upgrade code),
apply policy just to tag with a community,
then do analysis to ensure it's doing what you expect,
then deploy policy to actually do things like drop invalid, prefer 
valid over unknown, etc."

I think the former is reference to a comment I made saying that if we were 
recommending (SHOULD? Or MUST?) that invalid be dropped, rather than simply 
de-preffed, we needed to spend some time explaining why (what badness can ensue 
if you don't drop). You wanted text, but I'm not totally sure that I know the 
complete rationale well enough to supply said text. Is it just a matter of the 
risk of eventually using an invalid route if the better options go away, or is 
there more to it?

The latter looks to me like a deployment guideline to address the concerns that 
I think Brian brought up about OV/BGPSec potentially creating non-trivial 
changes to routing during deployment. I can flesh that text out a bit if people 
agree that it's useful to add.

Thanks,
Wes George

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)))

[George, Wes]

> -Original Message-
> From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of
> Christopher Morrow
> Sent: Friday, May 11, 2012 2:51 PM
> hrm, so... normally something like this happens:
>   1) router go boom
>   2) troubleshooting ensues to see where the problem is (what to fix)
>   3) RE/RSP is determined to be at fault
>   4) spares call placed
>   5) spare arrives and is placed into the chassis
>   6) reboot/checkout happens
>   7) customer links brought back online
>   8) things return to 'normal'
>
> I think that at 1 all routing stops (or enough stops that you stop it all 
> anyway).
>
[WEG] How prevalent is this scenario going to be in the hardware of sufficient 
burliness and shiny newness to manage BGPSec in the first place? Isn't it far 
more likely that the router going boom because of an RE/RP problem is a 
transient while it switches to the backup, and the sync of the config between 
primary and backup includes syncing the keys? (and replacing the spare is now 
only to restore full redundancy)
I do think that it's fair to know what the scenario looks like if you have a 
router that actually does go totally Tango Uniform and has to be resuscitated 
from spares including rebuilt configs and pushing keys, but I'm thinking that 
if it's a little more complex, that's not as big of a deal because of the fact 
that it's likely to be less common.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] [Idr] No BGPSEC intradomain ?

[George, Wes]

> -Original Message-
> From: Jeffrey Haas [mailto:jh...@pfrc.org]
> Sent: Thursday, April 12, 2012 10:51 AM
> To: Robert Raszuk
> Cc: George, Wes; Paul Jakma; i...@ietf.org List; sidr@ietf.org
> Subject: Re: [Idr] [sidr] No BGPSEC intradomain ?
>
> On Thu, Apr 12, 2012 at 03:52:29PM +0200, Robert Raszuk wrote:
> > I very much agree with both Paul and Wes that new BGP version number
> > or at least new set of AFIs would be the best way to smoothly
> > migrate unsecure BGP to secure one.
>
> If it's not backward compatible, sure.
[WEG] that's sort of the point -- there are a lot of factors to consider when 
determining what "backward compatible" truly means as far as BGPSec is 
concerned, especially when it comes to monitoring tools and other things that 
need to know the data but not necessarily make routing decisions on it.
>
> > I have not seem anyone resisting that idea yet with real technical
> > arguments against it ;)
>
> See my migration comments earlier.  If you think you can get a given SP that
> might be willing to install BGPSEC at the edges also willing to upgrade
> every other BGP speaker inside their AS... you're more optimistic than I.

[WEG] I'm not totally sure which message you're referring to, but I think that 
may be a red herring. I'm not seeing how incrementing the BGP version 
automatically means that all routers in an ASN must upgrade to it. This isn't 
exactly the same flag day sort of driver as the move between v3 and v4. BGP 
speakers that support BGPv5 also SHOULD support BGPv4, and would determine 
which they should use on initial capability negotiation. Same way as they would 
do if BGPSec (and any other option) is a standalone capability to negotiate. 
Even if you look at this from a scaling perspective (the BGPv5 speaker would 
have to craft and send out two different versions of update) we've already sort 
of said that this is acceptable collateral damage because of the fact that it 
can't send the same updates to neighbors of multiple different ASNs because it 
has to sign them all differently.
What am I missing?

Wes George

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] [Idr] No BGPSEC intradomain ?

[George, Wes]

Trying again without the signature block. Sorry about that, hit send too soon. 
*blush*
>
> > -Original Message-
> > From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of
> > Christopher Morrow
> > Sent: Wednesday, April 11, 2012 11:23 AM
> > To: Paul Jakma
> > Cc: i...@ietf.org List; sidr@ietf.org
> > Subject: Re: [sidr] [Idr] No BGPSEC intradomain ?
> >
> > On Wed, Apr 11, 2012 at 10:12 AM, Paul Jakma  wrote:
> > > On Tue, 10 Apr 2012, Jakob Heitz wrote:
> > >
> > >> I agree with Robert. Today, there are many tools that interact with BGP
> > >> messages. If the AS_PATH disappears, they will all break.
> > >
> > >
> > > Indeed. If mandatory, well-known attributes are removed, then the BGP
> > > protocol version number needs to be bumped.
> > >
> > > There's near-0-cost in doing that for those interested in implementing the
> > > new functionality, and it avoids a world of hurt for all the various tools
> > > (sometimes in-house/home-grown) out there that believe they know what
> > > they're getting when the version says 4.
> >
> > "if you don't ask for the 'bgpsec capability' then ... you get what
> > you get today."
> >
> > also
> >
> > "if you ask for the 'bgpsec capabiltiy' then ... you get (and can
> > presumably handle) the changes"
> >
> > so, everything you do today, ought to just keep right on working, or
> > that's the plan.
>
> [WEG] Why *are* we so resistant to incrementing the BGP version? I think that
> there's some merit to the idea that this suite of things represents a
> significant enough change to BGP that a change in version number might be a
> cleaner way to do the capability negotiation, perhaps even incorporating other
> secondary capabilities so that there isn't so much individual capability
> negotiation for all of the things that we've tacked onto BGP4 over the years.
> In other words, if you support BGPv5, you support the a list of capabilities
> (eg 4-byte ASN, GR, route refresh, etc), and they no longer have to be
> negotiated separately. Even if we move directly from version 4 to 6 as it
> seems we are wont to do, I think this bears some consideration (by IDR, of
> course) ;-)
>
> Wes George
>
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject to
> copyright belonging to Time Warner Cable. This E-mail is intended solely for
> the use of the individual or entity to which it is addressed. If you are not
> the intended recipient of this E-mail, you are hereby notified that any
> dissemination, distribution, copying, or action taken in relation to the
> contents of and attachments to this E-mail is strictly prohibited and may be
> unlawful. If you have received this E-mail in error, please notify the sender
> immediately and permanently delete the original and any copy of this E-mail
> and any printout.
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] iBGP, BGPSEC and incremental deployment (was No BGPSEC intradomain ?)

[George, Wes]

> From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of
> Christopher Morrow
> Sent: Wednesday, April 11, 2012 12:29 PM
> To: Jakob Heitz
> Cc: i...@ietf.org List; sidr@ietf.org
> Subject: Re: [sidr] iBGP, BGPSEC and incremental deployment (was No BGPSEC
> intradomain ?)
>
> On Wed, Apr 11, 2012 at 12:17 PM, Jakob Heitz 
> wrote:
> > Confeds are out of scope.
>
> how are confeds out of scope?
> if you want path validation for ibgp/originated-by-you routes and the
> originating router is in one of the confed sub-ases you have that
> router sign with the confed-external/public asn, no? I'm fairly
> certain we planned to support this sort of activity... though I could
> be missing the part which is out-of-scope?
>

[WEG] There was discussion on the SIDR list on November 12 (subject line 
"various") specifically regarding private ASNs and confeds and their discussion 
in the bgpsec-ops draft. I am writing offline and therefore can't provide a 
more specific pointer to the message itself nor confirm (as memory of the more 
previous versions that I've reviewed fails) that the product of that discussion 
has made it to an updated version, but I'm pretty sure that it has. I'd 
encourage you to look back at this and see if you have additional feedback 
regarding in/out of scope and implementation.

FWIW, confeds being truly out of scope may make BGPSec a no-op in my network, 
as I can't guarantee that confeds will be gone (unless you are suggesting that 
they should be deprecated a la AS_SETs). My earlier recommendation is that we 
have to be specific about how BGPSec handles signing and stripping to manage an 
ASPath including confeds, whether it only signs at the external side and 
previous signatures (if exist) are dropped, or if it is capable of handling 
something like this:

Origin ASN (public) -> Transit ASN1 (public) -> [confed ASN(s) (private)] -> 
confed ASN42 (public) -> confed ASN55 -- in that example, if the entire path is 
BGPSec capable, what does ASN42 send as the signed path? You have several ASNs 
that maybe need path count 0 in their signature so that they are signed but 
don't interfere with the externally-visible path, or the Transit ASN1 has to 
forward sign its updates as if they are directly connected to confed ASN42 
(public), meaning that we are potentially allowing it to transit multiple ASNs 
within the confed unsigned. Randy had said previously that confed ASNs 
shouldn't sign towards each other, so maybe that answers that question, but 
since it has come back up, please give it some thought.

Thanks
Wes George

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] [Idr] No BGPSEC intradomain ?

[George, Wes]

Thanks,

Wes

Wesley George
Time Warner Cable
ATG Technology Development
office: 703-561-2540 | mobile: 703-864-4902


> -Original Message-
> From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of
> Christopher Morrow
> Sent: Wednesday, April 11, 2012 11:23 AM
> To: Paul Jakma
> Cc: i...@ietf.org List; sidr@ietf.org
> Subject: Re: [sidr] [Idr] No BGPSEC intradomain ?
>
> On Wed, Apr 11, 2012 at 10:12 AM, Paul Jakma  wrote:
> > On Tue, 10 Apr 2012, Jakob Heitz wrote:
> >
> >> I agree with Robert. Today, there are many tools that interact with BGP
> >> messages. If the AS_PATH disappears, they will all break.
> >
> >
> > Indeed. If mandatory, well-known attributes are removed, then the BGP
> > protocol version number needs to be bumped.
> >
> > There's near-0-cost in doing that for those interested in implementing the
> > new functionality, and it avoids a world of hurt for all the various tools
> > (sometimes in-house/home-grown) out there that believe they know what
> > they're getting when the version says 4.
>
> "if you don't ask for the 'bgpsec capability' then ... you get what
> you get today."
>
> also
>
> "if you ask for the 'bgpsec capabiltiy' then ... you get (and can
> presumably handle) the changes"
>
> so, everything you do today, ought to just keep right on working, or
> that's the plan.

[WEG] Why *are* we so resistant to incrementing the BGP version? I think that 
there's some merit to the idea that this suite of things represents a 
significant enough change to BGP that a change in version number might be a 
cleaner way to do the capability negotiation, perhaps even incorporating other 
secondary capabilities so that there isn't so much individual capability 
negotiation for all of the things that we've tacked onto BGP4 over the years. 
In other words, if you support BGPv5, you support the a list of capabilities 
(eg 4-byte ASN, GR, route refresh, etc), and they no longer have to be 
negotiated separately. Even if we move directly from version 4 to 6 as it seems 
we are wont to do, I think this bears some consideration (by IDR, of course) ;-)

Wes George

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Interim Meeting Dates/Locations (Proposed)

[George, Wes]

>   2) would having these coincident with existing events and ~1/month
> be acceptable to the majority
>
> we (everyone involved) do know that not everyone can make every
> meeting... aiming for best participation level is the goal.
>
> -chris
>

[WEG] Avoiding some number of messages saying "can't/can attend x, y, z" is 
exactly why I requested that the chairs use a doodle poll or similar to gather 
that feedback (a bit more quietly), especially when there is more than one 
alternative for a date (before vs after an event, for example). You're asking 
for feedback, which is good, but you've still pre-set the dates, which really 
isn't aiming for best participation level. It's simply giving people an 
opportunity to throw rocks, and hope that enough people throw rocks of the same 
shape to change the schedule as necessary.

For example, although it means I have to give up more weekend for travel, I'd 
rather see us go on the front side of NANOG. I am unlikely to be able to do 
anything not World V6 launch related on June 6, and I'd bet I'm not the only 
one.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-overview-01.txt

[George, Wes]

I'll re-review, but I think that this is similar to origin-ops, where until the 
protocol design is stable, it's not really ready. We have a similar group of 
docs that block each other as we did with the big chunk for origin validation.

Thanks,

Wes

> -Original Message-
> From: christopher.mor...@gmail.com [mailto:christopher.mor...@gmail.com] On
> Behalf Of Christopher Morrow
> Sent: Wednesday, March 28, 2012 8:30 AM
> To: sidr@ietf.org; sidr-cha...@ietf.org
> Cc: Matt Lepinski; Sean Turner; George, Wes
> Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-overview-01.txt
>
> Matt/Sean,
> This document hasn't changed in a while, Wes (copied) had some
> comments which I believe were addressed in the October/2011 update? Is
> this document ready to move forward? Wes, did you review the changes
> sent?
>
> -Chris
> 
>
> On Mon, Oct 31, 2011 at 2:02 PM,   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
> Working Group of the IETF.
> >
> >Title   : An Overview of BGPSEC
> >Author(s)   : Matt Lepinski
> >  Sean Turner
> >Filename: draft-ietf-sidr-bgpsec-overview-01.txt
> >Pages   : 10
> >Date: 2011-10-31
> >
> >   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.
> >
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-overview-01.txt
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > This Internet-Draft can be retrieved at:
> > ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-overview-01.txt
> > ___
> > sidr mailing list
> > sidr@ietf.org
> > https://www.ietf.org/mailman/listinfo/sidr

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] draft-ietf-sidr-bgpsec-ops - Ready for WGLC?

[George, Wes]

> -Original Message-
> From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of
> Christopher Morrow
> Sent: Wednesday, March 28, 2012 8:25 AM
> To: Randy Bush; sidr@ietf.org; sidr-cha...@ietf.org
> Subject: [sidr] draft-ietf-sidr-bgpsec-ops - Ready for WGLC?
>
> Is this document prepared/ready/willing for WGLC in the near future?
[WEG] There are far too many things in flux within BGPSec design for this 
companion doc to be anywhere near ready. As things coalesce, there are 
undoubtedly going to be updates to this draft.

Origin ops, sure, but not BGPsec-ops.

Wes

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] wg adoption call for draft-ymbk-bgpsec-rtr-rekeying-00.txt

[George, Wes]

> -Original Message-
> From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of
> Christopher Morrow
> Sent: Saturday, March 24, 2012 10:09 AM
> To: Matt Lepinski
> Cc: sidr@ietf.org
> Subject: Re: [sidr] wg adoption call for draft-ymbk-bgpsec-rtr-rekeying-00.txt
>
> oh, except that the -rollover doc says:
> "The BGPSEC key roll-over process should be very tighten to the key
>provisioning mechanisms that would be in place.  The key provisioning
>mechanisms for BGPSEC are not yet documented.  We will assume that
>such an automatic provisioning mechanism will be in place (a possible
>provisioning mechanism when the private key lives only inside the BGP
>speaker is the Enrollment over Secure Transport (EST).  This protocol
>will allow BGPSEC code to include automatic re-keying scripts with
>minimum development cost."
>
> in the second sentence it's asking for this doc... (the first sentence
> seems to have some missing words though)
>
> > thanks!
> > -chris
> >


[WEG] the cited text can be changed, especially now that the referenced 
documentation exists. :-)
My point was not that all of the information isn't important, but rather that 
this occupies similar space and I don't know that it needs to be separated, 
other than as a separate section in one document. This WG generates a lot of 
documents that are logically separated by subject matter, but by necessity very 
intertwined, which sometimes makes it hard for those not intimately involved in 
writing/reviewing the drafts to keep track of what information is discussed 
where, and requires a fair amount of cross-referencing to truly understand the 
implementation. I'm thinking that if there are obvious places to consolidate, 
we should do so.

Wes

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] wg adoption call for draft-ymbk-bgpsec-rtr-rekeying-00.txt

[George, Wes]

Yes, support. Anything that teaches router jockeys how to wrangle keys and not 
compromise the security of the system in the process is a good thing IMO.

Though I'm wondering if perhaps this doc and bgpsec-rollover should be 
integrated

Thanks,

Wes George



> -Original Message-
> From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of
> Christopher Morrow
> Sent: Saturday, March 24, 2012 6:19 AM
> To: Sean Turner
> Cc: Murphy, Sandra; sidr@ietf.org
> Subject: Re: [sidr] wg adoption call for draft-ymbk-bgpsec-rtr-rekeying-00.txt
>
> 
> Hey folk,
> Is this draft stating something obvious and doesn't need to be
> documented? or are we in need of this doc to keep us all on the same
> page (us == ops + vendors) as to getting a cert created and installed
> on our lovely devices?
>
> If people could take a few minutes to read the 4 pages (minus
> boilerplate) and think/comment that would be nice.
>
> (for the record, it seems like documenting this is a good thing, from
> my perspective.)
>
> -chris
>
> On Mon, Mar 12, 2012 at 4:13 PM, Sean Turner  wrote:
> > Well I'd like to see it adopted and I promise to work on it ;)
> >
> > spt
> >
> >
> > On 3/7/12 6:07 PM, Murphy, Sandra wrote:
> >>
> >> An alert eye pointed out that the URL below is incorrect.  The correct
> >> pointer is
> >>
> >> http://tools.ietf.org/html/draft-ymbk-bgpsec-rtr-rekeying-00
> >>
> >> --Sandy, speaking as clumsy wg co-chair
> >>
> >> 
> >> From: sidr-boun...@ietf.org [sidr-boun...@ietf.org] on behalf of Murphy,
> >> Sandra [sandra.mur...@sparta.com]
> >> Sent: Wednesday, March 07, 2012 5:40 PM
> >> To: sidr@ietf.org
> >> Subject: [sidr] wg adoption call for draft-ymbk-bgpsec-rtr-rekeying-00.txt
> >>
> >> The following request has been made for wg adoption of
> >> draft-ymbk-bgpsec-rtr-rekeying-00.txt.
> >>
> >> The draft is available at
> >> http://tools.ietf.org/html/draft-ymbk-rpki-rtr-impl-01.
> >>
> >> Please respond to the list to say whether you accept this draft as a
> >> working group draft and are willing to work on it. Remember that you do not
> >> need to accept all content in a draft to adopt, as draft editors are
> >> required to reflect the consensus of the working group.
> >>
> >> This call will end 21 Mar 2012.
> >>
> >> --Sandy, speaking as wg co-chair
> >>
> >>
> >> 
> >> From: sidr-boun...@ietf.org [sidr-boun...@ietf.org] on behalf of Randy
> >> Bush [ra...@psg.com]
> >> Sent: Monday, March 05, 2012 8:54 PM
> >> To: sidr wg list
> >> Subject: [sidr] draft-ymbk-bgpsec-rtr-rekeying-00.txt
> >>
> >> chairs, please consider as a wg work item.  thanks.
> >>
> >> randy
> >>
> >> ---
> >>
> >> From: internet-dra...@ietf.org
> >> Subject: New Version Notification for
> >> draft-ymbk-bgpsec-rtr-rekeying-00.txt
> >>
> >> A new version of I-D, draft-ymbk-bgpsec-rtr-rekeying-00.txt has been
> >> succes=
> >> sfully submitted by Sean Turner and posted to the IETF repository.
> >>
> >> Filename:draft-ymbk-bgpsec-rtr-rekeying
> >> Revision:00
> >> Title:   Router Keying for BGPsec
> >> Creation date:   2012-03-05
> >> WG ID:   Individual Submission
> >> Number of pages: 7
> >>
> >> Abstract:
> >>BGPsec-speaking routers must be provisioned with private keys and the
> >>corresponding public key must be published in the global Resource
> >>PKI.  This document describes two ways of doing so, router-driven and
> >>operator-driven.
> >> ___
> >> 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 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 mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org

Re: [sidr] additional interim meetings

[George, Wes]

> From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of Henk
> Uijterwaal
> Sent: Friday, March 23, 2012 9:01 AM
> To: sidr@ietf.org
> Subject: Re: [sidr] additional interim meetings
>
>
> The IETF has a limited number of slots (150 or so) and about as many working
> groups.  That gives about 1 slot to each WG, a second slot is only granted
> after
> all requests for a 1st slot have been met.  That makes it hard to plan for
> multiple slots during the week, as it isn't clear that the 2nd slot will
> be available.
>
[WEG] One point to make here... I think you're overselling the difficulty of 
requesting and receiving additional slots when they are all requested at the 
same time, rather than retroactively as was done this time. Yes by strict math 
you're correct, but rarely do all of the WGs meet. Once the agenda is set, you 
know how many sessions you have, it's not like the add'l sessions are scheduled 
after the agenda is set. V6ops has consistently had 2 sessions per IETF, and 
was up to 3 sessions in one IETF before a number of folks told the chairs that 
this was excessive and that we needed to better manage what was actually 
getting agenda time. So it can be done.

Really, the problem with multiple sessions is that they are opposite 7 other WG 
meetings no matter what their timeslot, meaning that it becomes increasingly 
difficult to deconflict time for those who need to attend.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] additional interim meetings

[George, Wes]

> >> Are there enough central locations to where the folks who want to
> >> participate to make more network connected office conversations
> >> workable? (sunnyvale/pao/etc + washington + london + ???)
>
> is the idea of showing up in 3 locations close to a majority of
> participants and participating over video conference laughable or
> possibly doable?
[WEG] well, I think that videoconf would be an acceptable option, assuming we 
can cobble together the right set of multi-location supporting gear among the 
candidate locations. Other than those pesky timezones, the problem we run into 
with coordinated virtual meetings of this type is usually one of poor execution 
of the technology - e.g. systems that can only talk to other identical systems 
within the company network (no external/interwork support), huge rooms without 
appropriate mics/speakers to make a video or audio conf anything other than 
frustrating, or systems that aren't capable of managing a presentation + a 
speaker video at the same time, etc.
We won't know unless we try it, and I think that we should. The worst that 
happens is that we decide it's not worth the hassle in the future and simply 
rely on the built-in support for webcams in things like Webex in lieu of 
videoconf. The benefit of having it in a physical location is that it helps to 
reduce distractions and let us focus on what we're actually there to do.

I would assume that if Cisco is willing to volunteer the resources for its 
customers' use, there are likely telepresence rooms in the Cisco offices 
convenient to nearly all of us, and that's a system that I know from personal 
experience would work for this type of thing. The challenges are that there is 
an 8-10 person limit to the rooms, meaning that some of the areas with larger 
clusters of folks might need multiple rooms, and it's typically difficult to 
schedule that many simultaneous rooms for any length of time without doing so 
months in advance.

Thanks
Wes George

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] additional interim meetings

[George, Wes]

> -Original Message-
> From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of
> Murphy, Sandra
> Sent: Thursday, March 22, 2012 12:08 PM
> To: sidr@ietf.org
> Subject: [sidr] additional interim meetings
>
> Interim meetings would be face-face meetings co-located with venues of
> communities of interest to this work (ie nanog, ripe, arin, etc.) when
> facilities are volunteered, or virtual meetings when volunteer hosts can not
> be found.
>
[WEG] I think I'd rather see these be planned as solely virtual meetings when 
they are not collocated with another event which contains an audience we'd like 
to engage (either current SIDR participants or "tourists" whose input would be 
valuable). Personally, I'm already approaching the maximum amount of travel 
that I can do and still keep my happy home, well, happy, so carving out time 
for separate trips even for short-duration things like this is less than 
preferable. Finances are a consideration as well. I'm responding with some 
ideas about virtual meetings in another reply.


> The idea is to meet to discuss thorny topics at length.  Agendas announced
> ahead of time, remote participation always available, minutes reported to the
> wg, proceedings published.  When webex is used, recordings will be taken.
[WEG] Generally, I think that the topics proposed are important, and would 
benefit from discussion beyond the typical few hours at IETF meetings or 200+ 
message threads, so I support the idea of some focused time outside of IETF 
meetings. However, I'm not convinced that monthly is necessary. It may be that 
they are scheduled with that frequency and we do some agenda bashing to make 
sure that people can attend the things that they have opinions about without 
needing to commit one full day a month to this. When one considers keeping up 
with the rest of IETF + $day_job, that starts to get difficult in a hurry.

>
> Here is a suggested semi-schedule for the next several months.
>
> 30 April (chosen so as not to conflict with RIPE or ARIN in the preceding
> weeks)  (Likely important topic - the government oversight concerns at RIPE
> and mitigating possibilities, impacts of the ARIN and RIPE meeting)
[WEG] prefer virtual
>
> 6 Jun, co-located with NANOG (that is the Wed after NANOG ends - there are
> indications that nanog may be able to lend a room after noon.)
[WEG] Makes sense, please publicize WELL (6wks+) in advance on NANOG so that 
people in the operations community who aren't paying attention to SIDR can make 
plans to attend, focus the agenda on operational considerations.

>
> the last part of June: 25 Jun - 3 July
[WEG] I'm not convinced we need this one, and summer scheduling is problematic 
due to vacation. We may have to wait and see what comes of the previous few 
before determining if we need another one prior to IETF.
>
> at one end or the other of the IETF (sort of like iegp meets at IETFs) in July
[WEG] Manageable as long as the date is set before people make travel plans, 
probably at least 6 weeks out, preferably 8.

Thanks,
Wes George

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] SIDR Interim 24/March is CANCELLED

[George, Wes]

I'm sorry to harp on this Sandy, and I appreciate your apology, but frankly I 
think this communications breakdown is far larger than whether you accidentally 
missed a bit of the letter of the law on scheduling process because of 
timezones and missed email addresses, so I want to make sure that what I 
believe to be the real problem is addressed.

How is it that these interim meetings have been scheduled without soliciting 
the WG for acceptable dates PRIOR to setting the date?

How did you determine that an(other) interim was necessary and the 
appropriateness of the date chosen? I gather that consensus to hold an interim 
or when/where it is held is not strictly required[*], but it seems odd to me 
that the WG list wouldn't be involved in the discussion until the mandatory 
notification deadline.

In fairness to the chairs, the NANOG interim's timing and location were more 
self-explanatory, which is why I didn't bring this up before. Also, I should 
have posted about my travel schedule conflict as soon as I saw the 3/7 
announcement, but that announcement was an invite to a webex session, implying 
at least to me that things were already scheduled, rather than soliciting 
feedback regarding the date, so I let it go until I saw others raising 
questions about the scheduling.

So while we're making notes for next time, I believe that this process should 
start with "dear WG, an interim meeting has been requested to discuss 
$topic(s). Here are some candidate dates [and locations]. Please respond with 
feedback."
This obviously has to happen well enough prior to the candidate dates to ensure 
that you have the proper time to work through the process, so if 4 weeks 
notification are necessary, that discussion probably has to start at 6 weeks 
out.


* From http://www.ietf.org/iesg/statement/interim-meetings.html :
"Area Directors will advise the Working Group Chair on interim face-to-face 
meeting location, timing, and other aspects of the proposed meeting that with a 
goal of not unfairly favoring some subset of the potential participants or not 
unfairly biasing the working group discussions. Working Group Chairs will 
evaluate the proposed conference call or jabber session logistics for similar 
fairness concerns, consulting with Area Directors as necessary to resolve any 
concerns raised by potential participants."


I'm wondering if perhaps the above needs to be amended to recommend/require 
discussion on the WG list? Anyone have opinions on that?

Wes George

> -Original Message-
> From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of
> Murphy, Sandra
> Sent: Wednesday, March 21, 2012 1:38 PM
> To: sidr@ietf.org
> Subject: Re: [sidr] SIDR Interim 24/March is CANCELLED
>
> In the flurry of apologetic emails that preceeded and followed this
> announcement, I did not apolgize to the working group.
>
> This was my strictly my bungle, in two different directions.
>
> First, I announced the meeting to the sidr mailing list within the time frame
> required by process.  The bungle was that I did not copy the iesg-secretary as
> I MEANT to do and I KNEW is required by process.  I noticed this myself the
> next week, but too late to meet the required deadline.  I informed the iesg-
> secretary.  They sent the announcement and complaints of process violation
> came in immediately.
>
> Second, I announced the agenda as is required by process one week ahead of
> time, by my local time zone.  However, due to the time of day and time zone
> differences, it was reckoned the next day in other time zones.
>
> --Sandy, the apologetic wg co-chair
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] replies needed quickly RE: possible additional meeting times

[George, Wes]

Yes to either/both

Thanks,

Wes

> -Original Message-
> From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of
> Murphy, Sandra
> Sent: Monday, March 19, 2012 5:58 PM
> To: sidr@ietf.org
> Subject: [sidr] replies needed quickly RE: possible additional meeting times
>
> One important point.
>
> The routing AD needs to know the decision by COB UTC time on Tuesday
> (tomorrow).
>
> So replies are needed quickly.
>
> --Sandy
>
> 
> From: sidr-boun...@ietf.org [sidr-boun...@ietf.org] on behalf of Murphy,
> Sandra [sandra.mur...@sparta.com]
> Sent: Monday, March 19, 2012 5:37 PM
> To: sidr@ietf.org
> Subject: [sidr] possible additional meeting times
>
> The routing ADs have suggested that sidr could use the cancelled  EAI and/or
> the cancelled CODEC slot to make up for the cancelled virtual meeting.
>
> EAI was to meet 1300-1500 Afternoon Session I on Monday March 26.
> CODEC was to meet 1120-1220 Afternoon Session I Friday March 30.
>
> Please speak up as to whether either of these two spots would work.
>
> --Sandy
> ___
> 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

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] agenda for virtual meeting Mar 24

[George, Wes]

Was the WG consulted on scheduling this virtual meeting and I missed the 
message?

The first message I see on the matter is the announcement of the meeting on 
3/7. I don't know about anyone else, but I'm traveling to Paris the day it's 
scheduled (actually ON the plane during the meeting), and based on a couple of 
messages in response to the general announcement (on ietf@ietf), I'm not the 
only one. My travel arrangements have been made for significantly more than 3 
weeks, as are most people's when planning a trip to IETF. Virtual meetings 
don't need as much advance notice due to the fact that no one needs to travel 
to *attend* but scheduling conflicts do exist.

As far as I can tell, there was no attempt to determine the appropriateness of 
the date for this or the previous Interim with the WG prior to setting the 
date. I know of several folks who found out about it during NANOG and would 
have liked to attend, but couldn't rearrange their travel plans at the last 
minute.

In the future, I respectfully ask the chairs to solicit opinions on potential 
scheduling of interim meetings PRIOR to setting the date. I have no problem 
with there being a self-selecting core group of folks that make up a design 
team, but when they are working directly with the chairs to schedule supposedly 
official WG interim meetings without involving the WG until the dates are 
already set, we have a problem.

For that matter, I believe that this interim/virtual meeting should be 
rescheduled once an appropriate date can be determined based on consensus of 
the *entire* WG. Put up a doodle poll with some potential dates, publish it 
along with the goal of the meeting to sidr@ietf.org and let those interested in 
attending choose.

Thanks,

Wes


> -Original Message-
> From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of
> Murphy, Sandra
> Sent: Saturday, March 17, 2012 10:49 PM
> To: sidr@ietf.org
> Cc: iesg-secret...@ietf.org
> Subject: [sidr] agenda for virtual meeting Mar 24
>
> Here is the agenda for the sidr virtual meeting on Sat 24 Mar 2012.
>
> UTC 0800-1030. Protocol spec
> In depth protocol review, doc structure, forward path, etc.
> draft-ietf-sidr-bgpsec-protocol-02
> http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol
>
> UTC 1030-1230 Break
>
> UTC 1230-1330
> draft-ietf-sidr-origin-ops-15
> draft-ietf-sidr-bgpsec-reqs-03
> draft-ietf-sidr-bgpsec-ops-04
> http://tools.ietf.org/html/draft-ietf-sidr-origin-ops
> http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-reqs
> http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-ops
> (if there is time, discussion of
> draft-ymbk-bgpsec-rtr-rekeying-00
> http://tools.ietf.org/html/draft-ymbk-bgpsec-rtr-rekeying
> draft-rogaglia-sidr-bgpsec-rollover-00
> http://tools.ietf.org/html/draft-rogaglia-sidr-bgpsec-rollover-00)
>
>
> UTC 1330-1430 Alternate architectures
> RPKI delivery and scaling
>
> UTC 1430-1600 pfx-validate
> recent discussions on the sidr list.
> draft-ietf-sidr-pfx-validate-04
> http://tools.ietf.org/html/draft-ietf-sidr-pfx-validate
>
> --Sandy, speaking as working group co-chair
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] route leaks message to IDR

[George, Wes]

I'm basically fine with the wording below. The only thing I might add would be 
some mention of the reason why we're talking about route leaks, why they're 
considered a problem that should be solved in the context of SIDR, etc - mainly 
that there are those among the WG and operator community that believe BGPSec as 
currently proposed is incomplete without a method to prevent route leaks, and 
given the costs to deploy and manage BGPSec, the inability to protect against 
this problem limits its attractiveness for deployment.

This is covered in detail in the referenced drafts, but is worth including in 
the summary text.

Thanks,

Wes


> -Original Message-
> From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of
> Murphy, Sandra
> Sent: Tuesday, March 13, 2012 10:23 AM
> To: sidr@ietf.org
> Subject: [sidr] route leaks message to IDR
>
> In the interim meeting, the consensus was that we needed idr to be involved in
> any definition and solution for route leaks.  It was decided to discuss a
> message to the idr wg on the sidr list.
>
> Brian Dickson has submitted drafts about route leaks, as he offered in the
> meeting.
>
> So here is a first draft at a messate to idr.  Comments please.
>
> ==
>
> The sidr interim meeting in February discussed the problem of route leaks.
>
> While those in the room could recognize route leaks in a diagram, they could
> not determine a way to determine that from information communicated in BGP.
>
> Proposals to stop route leaks add information to BGP updates that would be
> used to restrict the propagation of those updates by the neighbor onward to
> providers, customers, peers, etc.
>
> This is a change to BGP behavior, which now relies on local configuration only
> to choose a best path and advertise it.  Adding features to stop route leaks
> would restrict that advertisement and restrict what local policy could choose.
>
> The consensus in the room was that adding a new feature to a protocol as part
> of a security protection  (i.e., not just ensuring an already defined behavior
> but producing brand new behavior) is unwise and leads to problems.
>
> The sidr working group requests that idr discuss the route leaks problem with
> sidr and determine the best path forward.
>
> The idr wg should also be aware that drafts have been submitted about route
> leaks, so work is underway.
>
> http://tools.ietf.org/html/draft-foo-sidr-simple-leak-attack-bgpsec-no-help-01
> http://tools.ietf.org/html/draft-dickson-sidr-route-leak-def-01
> http://tools.ietf.org/html/draft-dickson-sidr-route-leak-reqts-02
> http://tools.ietf.org/html/draft-dickson-sidr-route-leak-solns-01
>
> ===
>
> --Sandy
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-04.txt

[George, Wes]

> -Original Message-
> From: Pradosh Mohapatra [mailto:pmoha...@cisco.com]
> Sent: Tuesday, March 13, 2012 4:07 PM
> To: George, Wes
> Cc: internet-dra...@ietf.org; i-d-annou...@ietf.org; sidr@ietf.org
> Subject: Re: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-04.txt
>
> > In section 2:
> > "No ROA can match an origin
> >  AS number of "NONE".  No Route can match a ROA whose origin AS
> >  number is zero."
> >
> > I'm wondering if there should be a 2119 normative or two in there?
> > This sounds like a validation instruction. (eg MUST/SHOULD declare
> > prefixes covered by an origin AS number of none/zero invalid)
>
>
> Could you suggest text with 2119 language?

[WEG] Originally I stopped short of fully suggesting text because I didn't 
think that I had a complete grasp of what the authors are suggesting should 
happen here based on the combination of the text above.
In rereading the surrounding text to make another attempt at it, I don't think 
that this sentence belongs in the definition for Route Origin ASN at all, 
because it's not really part of the definition. This is instructional about a 
special case of match/cover, and should probably be moved down a few sentences 
to where you talk about valid/invalid/unknown. The same is also true for the 
following from the definition of Matched.
"keeping in mind that a ROA ASN of zero can never be matched, nor can a 
route origin AS
  number of "NONE"."

So I would strike the references to ASN 0 and origin AS NONE from the 
definitions altogether, and then reword the next section as follows:
CURRENT TEXT

" Given these definitions, any given BGP Route will be found to have
   one of the following "validation states":

   o  NotFound: No ROA Covers the Route Prefix.

   o  Valid: At least one ROA Matches the Route Prefix.

   o  Invalid: At least one ROA Covers the Route Prefix, but no ROA
  Matches it."

NEW TEXT

"Given these definitions, any given BGP route MUST [SHOULD?] be found to have 
one of the following "validation states":
   o  NotFound: No ROA Covers the Route Prefix.

   o  Valid: At least one ROA Matches the Route Prefix.

   o  Invalid: At least one ROA Covers the Route Prefix, but no ROA
  Matches it.
It should be noted that a ROA ASN of zero or a route origin AS number of "NONE" 
MUST NOT ever be considered matches. This means that routes with a covering ROA 
ASN of zero MUST be declared Invalid, and routes with a route origin AS number 
of "NONE" and one or more covering ROAs MUST be declared Invalid."

Is that a reasonably accurate interpretation of the intent?

>
> > Lastly:
> > "We observe that a Route can be Matched or Covered by more than one
> >   ROA.  This procedure does not mandate an order in which ROAs must be
> >   visited; however, the "validation state" output is fully
> > determined."
> > Is there guidance on this in one of the other documents? If so,
> > please reference it here. Does longest-match still apply? This seems
> > a fairly big question to simply leave open to implementation.
> > Please apply cluebrick liberally if I'm being thick.
>
>
> I looked around in sidr-usecases and origin-ops, but couldn't find an
> example. May be we should add one. But is there anything that you are
> specifically worried about? All that the text says is that ordering is
> not relevant. It's a classic OR operation for the match.

[WEG] I didn't get "ordering not relevant" from the current text, but now that 
you say it, I see how it could be interpreted that way. See my suggested change 
as a reply to Randy's explanation.

Thanks
Wes George

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-04.txt

[George, Wes]

> -Original Message-
> From: Randy Bush [mailto:ra...@psg.com]
> Sent: Tuesday, March 13, 2012 5:03 PM
>
> you want the inclusive or, if any one matches it's Valid.  otherwise,
> you can not do a make-before-break provider switch, for example.
>
> as to the matching rules, i have extracted a few slides from a recent
> hands-on workshop, see .
>
> randy


[WEG] makes perfect sense, thanks. Do you think that it's worth saying this 
more explicitly here?
Something like -

" We observe that a Route can be Matched or Covered by more than one
  ROA.  This procedure does not mandate an order in which ROAs must be
  Visited, because the match is a logical OR, which makes the order irrelevant. 
This enables, among other things, a make-before-break change for such things as 
changing providers."

Thanks
Wes George

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-04.txt

[George, Wes]

Not replying to a specific message, since I'm replying to several issues 
simultaneously.

In section 2:
"No ROA can match an origin
  AS number of "NONE".  No Route can match a ROA whose origin AS
  number is zero."

I'm wondering if there should be a 2119 normative or two in there? This sounds 
like a validation instruction. (eg MUST/SHOULD declare prefixes covered by an 
origin AS number of none/zero invalid)

"If validation is not performed on a Route, the implementation SHOULD
   initialize the validation state of such a route to "Valid"."

No. Absolutely not. I agree with Randy that default for unchecked != valid. I 
can manage the handling of unknwon routes via route policy such that during 
incremental deployment I don't make a decision to prefer valid over unknown if 
that's what you're trying to prevent with this choice. Valid needs to have an 
explicit "permit" such that I know categorically that everything with the 
status of valid was in fact validated. We already have a status for the ones 
that we don't know, whether it's because they weren't validated or aren't 
participating/no covering ROA exists -- unknown.

I don't understand the suggestion of a 4th value NotChecked. What additional 
information is that providing? I saw Hannes's response regarding JunOS, but I 
think that's implementation-specific enough that it's not necessary to codify 
in the standard. What am I missing?

Lastly:
"We observe that a Route can be Matched or Covered by more than one
   ROA.  This procedure does not mandate an order in which ROAs must be
   visited; however, the "validation state" output is fully determined."
Is there guidance on this in one of the other documents? If so, please 
reference it here. Does longest-match still apply? This seems a fairly big 
question to simply leave open to implementation.
Please apply cluebrick liberally if I'm being thick.

Thanks
Wes George

> -Original Message-
> From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of
> internet-dra...@ietf.org
> Sent: Monday, March 12, 2012 7:27 PM
> To: i-d-annou...@ietf.org
> Cc: sidr@ietf.org
> Subject: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-04.txt
>
>
> 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   : BGP Prefix Origin Validation
>   Author(s)   : Pradosh Mohapatra
>   John Scudder
>   David Ward
>   Randy Bush
>   Rob Austein
>   Filename: draft-ietf-sidr-pfx-validate-04.txt
>   Pages   : 11
>   Date: 2012-03-12
>
>To help reduce well-known threats against BGP including prefix mis-
>announcing and monkey-in-the-middle attacks, one of the security
>requirements is the ability to validate the origination AS of BGP
>routes.  More specifically, one needs to validate that the AS number
>claiming to originate an address prefix (as derived from the AS_PATH
>attribute of the BGP route) is in fact authorized by the prefix
>holder to do so.  This document describes a simple validation
>mechanism to partially satisfy this requirement.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-sidr-pfx-validate-04.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-pfx-validate-04.txt
>
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Burstiness of BGP updates (was: WGLC: draft-ietf-sidr-bgpsec-reqs)

[George, Wes]

> From: Brian Dickson [mailto:brian.peter.dick...@gmail.com]
> Sent: Tuesday, November 15, 2011 12:16 AM

> Sorry to jump in here, but I think that there is a drifting into
> conjecture...
>
> It would be best to stay within the realm of facts.

[WEG] To clarify, the issue got conflated between the impact of simple beacon 
updates and the case where an actual route update comes in, but the signature 
is processed after the update is processed, potentially triggering a route 
recalc.
Route recalc does mean 2x the processing, WHEN it happens, but it will not 
happen in all cases. My apologies for being unclear.

Wes George


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Burstiness of BGP updates (was: WGLC: draft-ietf-sidr-bgpsec-reqs)

[George, Wes]

> From: Jakob Heitz [mailto:jakob.he...@ericsson.com]
> Sent: Monday, November 14, 2011 8:47 PM
> To: George, Wes; Randy Bush
> Cc: Sriram, Kotikalapudi; sidr wg list
> Subject: RE: [sidr] Burstiness of BGP updates (was: WGLC: draft-ietf-
> sidr-bgpsec-reqs)
>
> I can not believe that it will be 2X.

[WEG] the objective amount of impact is probably not the important bit here.

>
> First case: A beacon will very rarely cause a different bestpath.
[WEG] True. However... your comment was not specific to beacons. Also when it 
does, it makes the load problem you're trying to solve worse.
>
> Second case: There is actually a changed route being updated.
> You will receive both a regular update and a signature.
> Only one of those will casue a new bestpath in the great majority of
> cases.
>
> Basically, in the large majority of cases, a signature does not change
> the bestpath.
>
[WEG] Not true. Bestpath in BGPSec land is chosen based on policy informed by 
the difference between valid, invalid and unknown. Even if the absence or 
presence of the signature only toggles the route between valid and unknown, 
given that those have a defined policy action (eg raise or lower local pref, 
etc), the only way to ensure that receiving a signature later than the initial 
route update does not trigger a change of best path (let alone a recompute that 
doesn't trigger a change, which probably has nearly the same impact) is to set 
ones policy such that unknown and valid are the same preference. While that may 
be reasonable in early incremental deployment, eventually I don't think that's 
a safe assumption, and really eventually is when we have a scaling problem, not 
in early deployment.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Burstiness of BGP updates (was: WGLC: draft-ietf-sidr-bgpsec-reqs)

[George, Wes]

> From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of
> Jakob Heitz
>
> The difference is that today's updates all have the same urgency.
> BGPSEC is not urgent. It doesn't matter if you don't receive a
> signature for a few minutes.
> An UNREACH is not signed.

[WEG] I don't totally agree with this characterization. If the BGPSec info 
triggers a recalculation of bestpath from what was chosen when the unsigned 
update came through, this has the potential to drive 2x the work, essentially 
take 2x longer for convergence, plus push another round of updates to 
downstream neighbors, another reprogram of the FIB, etc. Seems to me by the 
time we've gained any benefit of saving updates for later because the box is 
busy, we've triggered a far worse potential death spiral on a busy box. 
Processing a few additional updates is rather pale in comparison to having to 
consistently recalculate a non-trivial percentage of the table when the box 
gets "busy."
Similar to buffering and QoS, you can't get something for nothing here, and 
there are limits to where deferred processing can help to smooth out peaks vs. 
simply throwing more capacity at the problem, especially in the land of often 
underutilized multi-core systems.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] WGLC: draft-ietf-sidr-origin-ops

[George, Wes]

> From: christopher.mor...@gmail.com

> there were a slew of changes (or a slew of comments made) requested, a
> document update happened ~13 days ago, did the changes account for the
> comments/requests or not?
>

[WEG] I diffed 11 and 12 when 12 came out, and no, not really. As I recall, 
Shane already replied that the proposed text (that made it into -12) was not 
adequate in explaining rationale around the recommendation of "close" for RPKI 
cache placement, among other things. (cf. emails on 10/31). Don't know if 
additional changes are pending for -13 based on those comments, but the mail 
thread died on the 31st with no further responses.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] various

[George, Wes]

> From: Randy Bush [mailto:ra...@psg.com]
> Sent: Saturday, November 12, 2011 9:58 AM
> To: George, Wes
> Cc: sidr wg list
> Subject: Re: various
>
> > Do you or do you not agree that on the transition between private ASN
> > and public, if remove-private is configured, any signatures
> containing
> > private ASN must be removed even if the eBGP peer is BGPSec capable?
>
> with the statement as is, if it is a private asn or a public asn, it is
> not signing.

[WEG] sigh. Let me try one more time.
This question is not about confederations so "the statement" is not applicable.
Think just bog-standard, vanilla eBGP, with two BGPSec speakers, one of whom is 
using a private ASN, announcing routes that must be carried to the DFZ. Make 
more sense now as to why I'm making the distinction between private and public 
ASN?

Wes

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] various

[George, Wes]

> From: Randy Bush [mailto:ra...@psg.com]
> Sent: Saturday, November 12, 2011 5:45 AM
> To: George, Wes
> Cc: sidr wg list
> Subject: Re: various
>
> > "However, signed updates received from BGPSec speakers outside of the
> > confederation (i.e. those transiting the confederation ASes) MUST be
> > passed to the other Member-ASes BGPSec speakers intact.
>
> nope.  you could decide to strip toward one or more confed peers which
> are not bgpsec capable.  your routers, your decision, your policy.
> don't go there.

[WEG] there's no deciding. If the peers are not BGPSec capable, you're already 
required to strip towards that peer, no exception was made for confed peers. 
The only available policy decision is whether or not you want the info carried 
across the confed to other BGPSec capable peers, so maybe make it a SHOULD so 
that it's configurable, but I think it's incomplete as is.
>
> imiho, saying anything more is either adding unnecessary words at best
> or opening up large complexity holes at worst.

[WEG] yes, there's a fine line, but as I've said before, an operational 
considerations document is where some of these details and their associated 
primrose paths have to be discussed, because you get into the shades of gray 
world of operationalizing this stuff. We're not always going to be able to 
consult you for a ruling on all of the things that you didn't say, and the IETF 
has no Supreme Court to interpret the "founders" intentions for those left 
behind.

> > I figured it'd be clear from the above discussion
>
> and yet you want to me to go into unnecessary complications not
> directly needed given my brutally specific statement?  :)
[WEG] Your brutally specific statement is so specific that it does not mention 
the second case at all, because it's not about confeds. :-)
Do you or do you not agree that on the transition between private ASN and 
public, if remove-private is configured, any signatures containing private ASN 
must be removed even if the eBGP peer is BGPSec capable?

Wes

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr