Re: [sidr] BGPSEC Threat Model ID

At 10:29 PM -0400 11/2/11, Danny McPherson wrote: On Nov 2, 2011, at 10:52 AM, Stephen Kent wrote: I interpret the task at hand as trying to secure BGP, not a new EGP. Since BGP semantics (and syntax) do not provide a basis for deciding when an advertisement constitutes a route leak, I think i

Re: [sidr] BGPSEC Threat Model ID

> To say that BGP routes "leaked" via an AS for purposes of MITM, DoS, or > benign, that is not an authorized transit for a given prefix is out of > scope > because it is not a "semantics violation" does not mitigate what I perceive > as a very significant risk to my operations. This is some

Re: [sidr] BGPSEC Threat Model ID

On Nov 3, 2011, at 7:09 AM, Stephen Kent wrote: > Having been motived to reread the SIDR charter by Brian's message, there is a > simple answer to the in/out of scope question, but it's one you will not like > :-). The charter for SIDR states that the secruity goals for the WG are to > address

Re: [sidr] BGPSEC Threat Model ID

Danny, I'm reducing my reply to minimize what has become a tedious process. ... The charter is temporal and the product of the WG in the form of RFCs will be much more persistent, I'm concerned by a line of reasoning that says "Let's ignore and not even enumerate or concern ourselves with thes

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

At 9:32 PM -0400 11/2/11, Danny McPherson wrote: On Nov 2, 2011, at 11:04 AM, Stephen Kent wrote: The focus of BGPSEC is eBGP, because the concern is verifying the authenticity of routes arriving from other ASes. The hard problems arise for eBGP because these routes are delivered via BGP spea

Re: [sidr] BGPSEC Threat Model ID

On Nov 3, 2011, at 8:43 AM, Stephen Kent wrote: >> If you're intended to play the "charter says .." card then we're wasting our >> time. > > Yes, we are both wasting our time at this stage. Maybe not. The charter does not say "every other topic cannot even be mentioned": instead, the charter

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

On Oct 31, 2011, at 7:56 PM, Sriram, Kotikalapudi wrote: > In this revised version, we (authors) have made changes with careful > consideration > of all the comments (mostly of editorial nature) received from Warren and > Randy. > > http://www.ietf.org/mail-archive/web/sidr/current/msg03349.h

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 consid

Re: [sidr] BGPSEC Threat Model ID

On Nov 3, 2011, at 11:33 AM, George, Wes wrote: >> 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

Re: [sidr] BGPSEC Threat Model ID

hint: the reqs draft was based first on draft-ietf-rpsec-bgpsecrec-10. randy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] BGPSEC Threat Model ID

On Nov 3, 2011, at 11:43 AM, Stephen Kent wrote: > Danny, > > I'm reducing my reply to minimize what has become a tedious process. > > ... > >> The charter is temporal and the product of the WG in the form of RFCs >> will be much more persistent, I'm concerned by a line of reasoning that >> sa

[sidr] agenda posted

I have posted an agenda from requests for time and from drafts with recent activity to discuss. Please look at the agenda and tell me whether you think the time you are allotted is adequate. We are still considering a time slot change. We have firm offers for a change to Mon afternoon and a m

Re: [sidr] BGPSEC Threat Model ID

> From: Randy Bush [mailto:ra...@psg.com] > > hint: the reqs draft was based first on draft-ietf-rpsec-bgpsecrec-10. > > randy [WEG] A useful thing to have noted in the document itself for us young whippersnappers, perhaps in the acknowledgements. I also note that there is good additional discussi

Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03

On Nov 2, 2011, at 4:34 AM, Stephen Kent wrote: > At 6:29 PM -0700 11/1/11, Terry Manderson wrote: >> On 31/10/11 11:59 PM, "Stephen Kent" wrote: >> >> I understand why you want to, but don't come to the same conclusion as to the mechanism. Is that really the IETF's

Re: [sidr] BGPSEC Threat Model ID

On Nov 3, 2011, at 11:43 AM, Stephen Kent wrote: > Can you point me to reports on those incidents. I have not heard about them. I could cite others, but this should serve the purpose: Consider this and assume operators had i

Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03

On 2/11/11 6:34 PM, "Stephen Kent" wrote: >> >> Architecture, yes. Structured approach, yes. To both of those I agree. >> Having the IETF define the dates when algorithms shift. I am not convinced. > > An architecture that ignores the need to have a global, uniform set > of milestones for tran

Re: [sidr] BGPSEC Threat Model ID

Hi, On Fri, Nov 4, 2011 at 3:19 AM, Paul Hoffman wrote: > Maybe not. The charter does not say "every other topic cannot even be > mentioned": instead, the charter limits the topics that are meant to be fully > covered by the protocols. > > Personally, I would prefer to see the threat model docu

Re: [sidr] BGPSEC Threat Model ID

(coming in late to the party, weee!) On Wed, Nov 2, 2011 at 1:08 PM, Brian Dickson wrote: >>> (5) If any BGP path attribute used in Path Selection is not signed, >>> then BGPSEC has failed to meet its charter requirements. >> >> Then MED and Local Pref must also be signed, along with a number of

[sidr] Route Leak fix: V free routing

I had a different idea. Model the internet as providers, customers and peers. A provider is above you, a customer is below you and a peer is level to you. Add a "down" bit to the BGPSEC signature block. If an AS sends an update to a customer, it sets the "down" bit. The rule is "V" free routing.

Re: [sidr] BGPSEC Threat Model ID

On Fri, Nov 4, 2011 at 12:49 AM, Christopher Morrow wrote: > (coming in late to the party, weee!) > > On Wed, Nov 2, 2011 at 1:08 PM, Brian Dickson > wrote: (5) If any BGP path attribute used in Path Selection is not signed, then BGPSEC has failed to meet its charter requirements. >>> >