Re: [sidr] I-D Action: draft-ietf-sidr-origin-validation-signaling-10.txt

Updated security section to reflect SecDir and AD review. --John > On Nov 30, 2016, at 12:32 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 of the IETF.

Re: [sidr] AD Review of sidr-origin-validation-signaling-09

On Nov 30, 2016, at 9:18 AM, Randy Bush wrote: > section 4.5 of 4593 is relevant, or all of sec 4 Thanks, used in the text below. > i am kinda sad that 7132 is not too good on this I looked there first but it's a *path* security threat model so can't really be blamed for not

Re: [sidr] AD Review of sidr-origin-validation-signaling-09

On Nov 30, 2016, at 8:37 AM, Randy Bush wrote: > the point is the tcp 'stream' does not have to be hacked in any way. > the hack is at a layer above. I agree. I also agree with your earlier On Nov 29, 2016, at 8:40 PM, Randy Bush wrote: > none of this is new. I

Re: [sidr] AD Review of sidr-origin-validation-signaling-09

On Nov 29, 2016, at 9:02 PM, Chris Morrow wrote: > Of course, just wiping out the prefixes in flight Right, exactly. The OV "attack" is just a baroque version of underclaiming, only it's an inferior version because there's a greater audit trail. > and stitching back >

Re: [sidr] AD Review of sidr-origin-validation-signaling-09

On Nov 13, 2016, at 1:40 AM, Alvaro Retana (aretana) wrote: > C1. The reference to rfc7607 should be Informative. Done (in -10 candidate source). > C2. [Major] Security Considerations. I think that there is one consideration > that should be mentioned in this section:

Re: [sidr] BGPSec RFC status

All, Thanks to Geoff and Tom for pointing out that we do have definitions of what PS and Experimental mean. If those definitions are wrong (c.f. some of the comments relating to whether some designation does or doesn't advance some greater good or agenda) is not a question for SIDR to decide

Re: [sidr] I-D Action: draft-ietf-sidr-origin-validation-signaling-08.txt

Hi Everybody, Just when we thought we were completely done with this draft, we were approached by Thomas King who pointed out a use case that can be enabled by validation signaling, which benefits from a minor revision in the language of the draft. Here's the revision: OLD: By default,

[sidr] Fwd: I-D Action: draft-ietf-sidr-origin-validation-signaling-05.txt

Hi Everyone, This is a revision to address the comments that arose on the IDR list as part of the SIDR WGLC for this document. I summarized those comments back at IETF-90, see https://tools.ietf.org/agenda/90/slides/slides-90-sidr-5.pdf. The authors believe the document is ready to advance

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

Hi Wes, I believe -05 should work for you -- we updated it to say 'don't leak across AS boundaries unless configured to do so'. Presumably in your case you would do that configuration. Thanks, --John > On Jun 14, 2014, at 12:25 AM, George, Wes wrote: > > > On

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

Hi Robert, I didn't see any specific change requests in your followups to this thread and indeed the changes in -05 are (I believe) consistent with the positions you took, but in any case you might like to take a look at the update. Thanks, --John > On Jun 12, 2014, at 5:06 PM, Robert Raszuk

Re: [sidr] new agenda uploaded

If you don't mind uploading a new new one to reflect the current plan for Friday, it would be helpful. Thanks! --John > On Nov 3, 2015, at 7:48 AM, Sandra Murphy wrote: > > A new agenda was uploaded. > > Thanks to Tim to catching an error in the header, a holdover from a

Re: [sidr] [Idr] IETF-91 agenda topics

On Oct 20, 2014, at 12:50 PM, John Scudder j...@juniper.net wrote: ... We will also be holding a joint meeting with SIDR on November 9 from 9:00 to 11:30. ... Not sure how I came up with November 9. The correct date for the joint meeting is Friday, November 14, 9:00 to 11:30. Thanks,

Re: [sidr] origin attribute

On Oct 23, 2012, at 12:13 PM, Jakob Heitz jakob.he...@ericsson.com wrote: origin does not seem to be an attribute subject to change. In theory you're right, if the attribute were being used as originally envisioned. In practice, as Warren points out, you're not because it's not. People do set

Re: [sidr] bgpsec confeds bug, with fix

On Aug 3, 2012, at 1:51 PM, Sriram, Kotikalapudi kotikalapudi.sri...@nist.gov wrote: Let us consider this example: (B1B2)(B3B4)(B5B6) -AS1AS2AS3 where AS1, AS2 and AS3 form a confed, and the update is propagating from

Re: [sidr] bgpsec confeds bug, with fix

On Aug 3, 2012, at 2:12 PM, John G. Scudder j...@juniper.net wrote: One other option does occur to me however, and I'm not sure why I didn't think of it before: for *every* crossing of a confederation member border, set the flag, so it has the semantics of this is a confederation hop rather

[sidr] bgpsec confeds bug, with fix

Randy, Sandy and I realized there is a problem with confeds. As written right now, the entering-the-confed marker is applied by the first router sending the route across an internal-to-the-confed boundary (let's call this router R). It can't be applied by the external peer router sending it to

Re: [sidr] Confeds and clusters

In addition to Wes and Randy's observations about trust boundaries, it's also the case that mechanically, the confederation embeds its loop prevention information in the AS path, so we have to have *some* way of dealing with it since bgpsec is monkeying with the AS path. The same problem

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

True in the context of bgpsec. But this is just pfx-validate. Nonetheless, I am OK with leaving it as an exercise for the implementor -- as Hannes notes, this is how it ends up working anyway. --John On Jun 12, 2012, at 12:48 PM, Murphy, Sandra wrote: Speaking as regular ol' member: wrt:

Re: [sidr] BGPSEC proposal to drop AS_PATH [was: Fwd: request for agenda items for interim meeting 6 Jun]

Missed one: On May 29, 2012, at 2:24 PM, John G. Scudder wrote: Philosophically, the thing that makes me worry the most is that we're cutting out one of BGP's fundamental elements and replacing it with one which provides only a subset of its semantics. Specific things missing include

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

On May 30, 2012, at 8:02 PM, Sriram, Kotikalapudi wrote: Right, and agreed (see formally an attack above). But to repeat my further point, if the AS_PATH is present (even if not secured): at least there's scope for a network operator on the receiving end to tolerate the validation failure

Re: [sidr] BGPSEC proposal to drop AS_PATH [was: Fwd: request for agenda items for interim meeting 6 Jun]

[Sigh. Again with the right source email address.] Missed one: On May 29, 2012, at 2:24 PM, John G. Scudder wrote: Philosophically, the thing that makes me worry the most is that we're cutting out one of BGP's fundamental elements and replacing it with one which provides only a subset

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

[added IDR to cc] On May 30, 2012, at 12:10 PM, Murphy, Sandra wrote: ... About extensibility - as you say, any new segment type not built into implementations would result in fatal errors. So any new segment type would need to be built into implementations before use. The question then

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

On May 22, 2012, at 5:46 PM, Matt Lepinski wrote: Other than confeds are there any other potentially open issues related to the removal of AS_Path? (I think this just recapitulates what I said at the interim, but maybe it's worth saying again for the list.) Philosophically, the thing that

[sidr] BGPSEC proposal to drop AS_PATH [was: Fwd: request for agenda items for interim meeting 6 Jun]

represent a fairly major change to the protocol, I wanted to make sure those not following SIDR were aware of it. Please cross-post any comments to sidr@ietf.org. (See http://tools.ietf.org/html/ietf-sidr-bgpsec-protocol-03 Section 3.) --John Begin forwarded message: From: John G. Scudder j

Re: [sidr] BGPSEC proposal to drop AS_PATH [was: Fwd: request for agenda items for interim meeting 6 Jun]

On May 29, 2012, at 2:24 PM, John G. Scudder wrote: It's also worth noting that leaving AS_PATH in would not be without cost. In the cases where the content of AS_PATH is isomorphic to that of BGPSEC_Path_Signatures, there's no problem -- but in those cases AS_PATH clearly could have been

Re: [sidr] BGPSEC proposal to drop AS_PATH [was: Fwd: request for agenda items for interim meeting 6 Jun]

[Once more from proper account, sigh.] On May 29, 2012, at 2:24 PM, John G. Scudder wrote: It's also worth noting that leaving AS_PATH in would not be without cost. In the cases where the content of AS_PATH is isomorphic to that of BGPSEC_Path_Signatures, there's no problem -- but in those

Re: [sidr] sidrSlides for RPKI Over BitTorrent presentation

Wes, On May 23, 2012, at 9:22 PM, Wes Hardaker wrote: Bittorrent works well for sharing the load, but either requires a lot of bittorrent start files (whatever they're called), which then becomes hard to syncronize; or a small number of bittorrent files (one per aggregation point) that

Re: [sidr] Interim Meeting (Apr 30, 2012) fallout/lessons/room-foo

A few things in addition to what others have said: On May 3, 2012, at 12:08 AM, Chris Morrow wrote: o shared slides prior to the meeting (no slides, no slot. potentially) We covered a fair amount of ground at the interim without using slides at all. Based on that, I'm not sure where this

Re: [sidr] WG adoption call for draft-ymbk-rpki-rtr-impl-01.txt

Support. --John On Jan 20, 2012, at 4:19 PM, Murphy, Sandra wrote: The working group has been requested to adopt draft-ymbk-rpki-rtr-impl-01.txt as a working group draft. The draft is available at http://tools.ietf.org/html/draft-ymbk-rpki-rtr-impl. Please respond to the list to say

Re: [sidr] call for wg adoption of draft-turner-sidr-bgpsec-algs

Retro-support. --John On Oct 14, 2011, at 10:50 AM, Sandra Murphy wrote: This call for adoption did not get sufficient support to judge the wg as willing to adopt this draft. --Sandy, speaking as wg chair with wg ceremonial garb donned On Tue, 9 Aug 2011, Sandra Murphy wrote: The

Re: [sidr] Last Draft: ReCharter text

On Mar 4, 2011, at 5:39 AM, Christopher Morrow wrote: ... A few folks noted that perhaps 'route' was not the right word here, perhaps NLRI is. Using a wikipedia definition: I love Wikipedia, but the quoted definition is wrong, at least with respect to the definitions given in RFC 4271: 1.1.

Re: [sidr] SIDR ReCharter - to capture/cover path validation work

On Feb 24, 2011, at 10:00 PM, Russ White wrote: Can you explain the difference in some other way that doesn't mix the two ideas? Since after reading your message carefully three times I don't understand your question, I'm unable to answer it. Sorry. --John

Re: [sidr] SIDR ReCharter - to capture/cover path validation work

Andrew, On Feb 24, 2011, at 1:17 AM, Andrew Lange wrote: Given the thread, I can understand your frustration. And, I could have made myself more clear. I'll try: given the policies that AS_B might be implementing, we cannot know for certain, without AS_B publishing their policies, if

Re: [sidr] SIDR ReCharter - to capture/cover path validation work

On Feb 16, 2011, at 7:53 PM, Christopher Morrow wrote: [...] The purpose of the SIDR working group is to reduce vulnerabilities in the inter-domain routing system. The two vulnerabilities that will be addressed are: * Is an Autonomous System (AS) authorized to originate an IP prefix *

[sidr] Comments on draft-ietf-sidr-roa-validation-03

George and Geoff -- Some comments, questions, and nits for you (in that order). Comment: I think this text, from S 4.1, is not quite right: This approach to route object origination validation uses a model of positive security attestations, where information that cannot be validated