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

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?

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

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

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

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

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

From: Matthew Lepinski mlepinski.i...@gmail.commailto:mlepinski.i...@gmail.com Date: Friday, July 24, 2015 at 1:31 AM To: George, Wes wesley.geo...@twcable.commailto:wesley.geo...@twcable.com Cc: sidr@ietf.orgmailto:sidr@ietf.org sidr@ietf.orgmailto:sidr@ietf.org Subject: Re: [sidr] New Version

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

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

More inline Thanks, Wes From: Alvaro Retana (aretana) aret...@cisco.commailto:aret...@cisco.com Date: Thursday, April 9, 2015 at 2:57 PM To: George, Wes wesley.geo...@twcable.commailto:wesley.geo...@twcable.com, sidr@ietf.orgmailto:sidr@ietf.org sidr@ietf.orgmailto:sidr@ietf.org Cc: draft

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

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

...@cisco.commailto:aret...@cisco.com Date: Monday, March 23, 2015 at 11:18 AM To: George, Wes wesley.geo...@twcable.commailto:wesley.geo...@twcable.com Cc: draft-ietf-sidr-as-migrat...@tools.ietf.orgmailto:draft-ietf-sidr-as-migrat...@tools.ietf.org draft-ietf-sidr-as-migrat

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

On 3/18/15, 11:10 PM, David Mandelberg da...@mandelberg.org 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

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

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, George, Wes wesley.geo...@twcable.commailto:wesley.geo...@twcable.com Date: Tuesday, February 3, 2015 at 3:30 PM To: Alia Atlas akat...@gmail.commailto:akat...@gmail.com, draft-ietf-sidr

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

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, George, Wes wesley.geo

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

and progressing draft-ietf-sidr-as-migration-02 Resent-To: sa...@tislabs.commailto:sa...@tislabs.com, George, Wes wesley.geo...@twcable.commailto: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

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

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 sa...@tislabs.com

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

On 11/17/14, 12:13 AM, Randy Bush ra...@psg.com 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

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

On 8/11/14, 7:13 AM, Carlos M. Martinez carlosm3...@gmail.com 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

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

On 8/4/14, 5:47 PM, Sandra Murphy sa...@tislabs.com 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

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 k...@bbn.com 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

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

From: Matthew Lepinski mlepinski.i...@gmail.commailto:mlepinski.i...@gmail.com Date: Friday, July 4, 2014 at 6:16 PM To: sidr@ietf.orgmailto:sidr@ietf.org sidr@ietf.orgmailto:sidr@ietf.org Subject: [sidr] New version draft-ietf-sidr-bgpsec-protocol I submitted a new version of the bgpsec

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

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

On 5/20/14, 10:38 AM, Randy Bush ra...@psg.com 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.

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

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 wesley.geo...@twcable.com wrote: This update address my comments on the document, and I think it’s in good

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

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

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

On 1/25/14, 3:33 AM, Randy Bush ra...@psg.com 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

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] WGLC: draft-ietf-sidr-bgpsec-reqs

On 1/24/14, 10:04 AM, Warren Kumari war...@kumari.net 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

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

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

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] Last Call: draft-ietf-sidr-origin-ops-21.txt (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 the

Re: [sidr] Last Call: draft-ietf-sidr-origin-ops-21.txt (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 in

Re: [sidr] Last Call: draft-ietf-sidr-origin-ops-21.txt (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: draft-ietf-sidr-origin-ops-21.txt (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 of

Re: [sidr] Last Call: draft-ietf-sidr-origin-ops-21.txt (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

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 talked

Re: [sidr] Last Call: draft-ietf-sidr-bgpsec-threats-06.txt (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

[sidr] New SIDR-AS-Migration revision notes

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

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

to AS-migration and aliasing. Wes On May 29, 2013, at 3:59 PM, George, Wes wesley.geo...@twcable.commailto: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

[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

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

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 technical

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 b...@apnic.net wrote: Hi Chris, When did the WG reach consensus on adopting this draft? when it spent ~50 mesasages discussing it? it seems that,

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 validation algorithm. If you

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

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

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

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.org) Subject: RE

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 confeds

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] 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] 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 (from

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

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 to

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] 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 Wed, Apr

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...@ietf.org List;

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, 2012 at 03:52:29PM +0200, Robert

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 document

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

: 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

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

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] 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, except that

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

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

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

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

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] 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 a few

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.txt In section 2

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

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

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 totally

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] the statement attempts to very clearly apply ONLY to two members of the confed speaking to each other, period. if it is not clearly restricted to that case, please say how it could be reworded to more clearly be so restricted. ( i should be able to

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 transiting the confederation ASes) MUST be passed

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 configured, any signatures containing private

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

From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of Matt Lepinski The -01 version of the draft contains a mechanism (a field called pCount) which attempts to address this issue by having route servers create BGPSEC signatures without increasing the effective length of

Re: [sidr] Beacons in a separate TCP

From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of Jakob Heitz The beacons will be unlikely to come like the slow constant drizzle of Seattle weather, but more like the quick cloudbursts of Miami weather. Just guessing. Such beacons will cause head-of-line blocking for

Re: [sidr] various

From: Randy Bush [mailto:ra...@psg.com] Sent: Friday, November 11, 2011 10:41 PM To: George, Wes Cc: sidr wg list Subject: various draft-ietf-sidr-bgpsec-ops-02 To prevent exposure of the internals of BGP Confederations [RFC5065], a BGPsec speaker which is a Member

Re: [sidr] BGPSEC Threat Model ID

From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of Paul Hoffman the charter limits the topics that are meant to be fully covered by the protocols. Personally, I would prefer to see the threat model document say in the introduction the following topics are considered to

Re: [sidr] 4-byte vs 2 byte ASN (was re: I-D Action: draft-ietf-sidr-pfx-validate-03.txt)

-Original Message- From: Randy Bush [mailto:ra...@psg.com] aven i, an old fuddy duddy, kinda assume that an AS number is two or four bytes, an ip address is ipv4 or ipv6, etc. i can understand clarifying once in a document where it is critical to do so, but would not be inclined to

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

-Original Message- From: Randy Bush [mailto:ra...@psg.com] Bgpsec-reqs 3.4 provides a list of operational considerations to discuss. Would probably make sense to ensure that the document covers all of the listed items, perhaps even using those items as section headings for

[sidr] 4-byte vs 2 byte ASN (was re: I-D Action: draft-ietf-sidr-pfx-validate-03.txt)

Posing the question about 4-byte ASNs in my review of the BGPSec design reqs draft yesterday makes me wonder about the same in pfx-validate. The draft makes reference to AS_PATH in several locations. I'm thinking that we need a comment early in the draft stating that for the remainder of the

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

Randy, I think I know why you keep calling me Shane - we tend to raise similar concerns on your drafts ;-) See also http://www.ietf.org/mail-archive/web/sidr/current/msg03408.html Shane articulates it better, but consider this a +1 on his comments regarding the -12 proposed text. The only other

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

From: Christopher Morrow Seems that the authors, at least, expect this doc to be prepared for WGLC -Chris wg-co-chair-haircut == completed [WEG]] So should we expect you to have SIDR or WGCHAIR shaved into your hair when we see you in Taipei? ;-) More seriously, some comments...

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

Intro: I'm wondering whether instead of specifically saying may require large memory and crypto assist it would make more sense to discuss this more in terms of the hardware catching up with the software to ensure minimal performance impacts. Especially given that current crypto hardware isn't

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

I'm not sure I am following the rationale here: As RPKI-based origin validation relies on the availability of RPKI data, operators SHOULD locate caches close to routers that require these data and services. ... Peering with two or more, at least one local and others remote, is

Re: [sidr] important dates for IETF82

Are revisions pending for any of the ietf-sidr-bgpsec-* drafts prior to the submission cutoff? Current -00 versions are pre-QC vintage (and IIRC mostly unchanged from the non-WG versions). I'm trying to allocate cycles to review drafts I know are important before the standard deadline draft

Re: [sidr] time

-Original Message- From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of Randy Bush Sent: Tuesday, April 26, 2011 1:46 AM To: Christopher Morrow Cc: sidr wg list Subject: Re: [sidr] time   If a router has reason to believe its clock is seriouly incorrect, it 'has

Re: [sidr] Proposed draft-ymbk-bgpsec-reqs topic: dependance on network services

-Original Message- From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of Randy Bush Sent: Wednesday, April 06, 2011 7:22 AM To: Brian Weis Cc: sidr@ietf.org Subject: Re: [sidr] Proposed draft-ymbk-bgpsec-reqs topic: dependance on network services Personally, I'm leery

Re: [sidr] BCP for implementing RPKI?

-Original Message- From: Carlos Martinez-Cagnazzo [mailto:carlosm3...@gmail.com] Sent: Sunday, April 03, 2011 8:49 PM To: George, Wes E [NTK] Cc: sidr@ietf.org Subject: Re: [sidr] BCP for implementing RPKI? That said, I believe documenting best practices is always a good idea. Do you

  1   2   >