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

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

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

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 p

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

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 read

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

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

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

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

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

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 t

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

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 v

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

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

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

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) g

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

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: dr

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

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 si

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

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>

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

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 roll

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

varo 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-s

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

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)

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

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

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

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 normati

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

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

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

er 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

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

gressing 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 u

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

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 anot

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

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

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

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

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

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 val

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

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 reference

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

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 belong

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

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

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

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, th

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

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 in

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

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/t

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

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

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

t;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 1

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

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 reco

[sidr] SIDR-AS-Migration updates?

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

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

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

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

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 de

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

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

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

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

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

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,

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

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

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

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

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

> 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

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

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

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

> 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

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

> 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

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

> 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

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

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

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

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]

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

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

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

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

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

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 ignore

[sidr] New SIDR-AS-Migration revision notes

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

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

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

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

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 __

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

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

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

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 pa

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

me 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-geor

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

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

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

> 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

Re: [sidr] comments on recent as migration drafts

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

Re: [sidr] comments on recent as migration drafts

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] FW: New Version Notification for draft-george-sidr-as-migration-00.txt

riginal 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 successful

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

> 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

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

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 thi

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

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

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

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

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

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

Re: [sidr] AS Migration and aliasing

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.

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

Re: [sidr] Confeds and clusters

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

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

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

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

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

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

> 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 (fr

Re: [sidr] docco changes from minutes

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

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

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

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

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

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

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

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

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

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

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

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

> 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

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

e- > 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-i

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

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

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

> -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, exce

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

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:

Re: [sidr] additional interim meetings

> 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

Re: [sidr] additional interim meetings

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

Re: [sidr] additional interim meetings

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

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

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 w

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

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

Re: [sidr] agenda for virtual meeting Mar 24

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 ba

Re: [sidr] route leaks message to IDR

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

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

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

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

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

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

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 s

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

> 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

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

> 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

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

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

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

> 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

Re: [sidr] various

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

Re: [sidr] various

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

  1   2   >