Oh, good. I was wondering what time warp I had just stepped into. Just so everyone realizes the status of the 2014 discussion - draft-ietf-sidr-bgpsec-reqs was published as RFC 7353 in August 2014.
--Sandy On Jan 12, 2015, at 7:09 PM, "Montgomery, Douglas" <do...@nist.gov> wrote: > Terribly sorry about that … ignore the post below. > > An odd search / view through my mailbox made me think this was a recent > comment. > > I was not trying to resurrect the discussion below. > > Sorry about that. > > dougm > — > Doug Montgomery, Mgr Internet & Scalable Systems Research @ NIST/ITL/ANTD > > > > > > On 1/12/15, 7:02 PM, "Montgomery, Douglas" <do...@nist.gov> wrote: > >> I doubt that using such vague / loose terms as “business relationship >> conformance” helps matters. >> >> Actually 3.22 is a bit loose in the use of the word “intended”. >> >> "3.22 A BGPsec design SHOULD NOT presume to know the intent of the >> originator of a NLRI, nor that of any AS on the AS Path, other >> than that they intended to pass it to the next AS in the Path.” >> >> >> I highly suspect that the same misconfigurations that can result in route >> leaks today, could result in BGPsec signed route leaks (I.e., not what was >> intended) tomorrow. >> >> >> One might try the following for 3.22 to both fix the above and address >> Wes’s concerns. >> >> 3.22 A BGPsec design SHOULD NOT presume to know the intent of the >> originator of a NLRI, nor that of any AS on the AS Path, other >> than that they announced the NLRI explicitly to the next AS in the Path. >> In particular there is no BGPsec requirement that the PATH for a given >> NLRI >> is consistent with the set of local routing or filtering policies of the >> sender, >> receiver or any AS along the PATH." >> >> That might kill two birds … or scare the whole flock from the trees. >> dougm >> — >> Doug Montgomery, Mgr Internet & Scalable Systems Research @ NIST/ITL/ANTD >> >> >> >> >> >> On 1/24/14, 10:04 AM, "Warren Kumari" <war...@kumari.net> wrote: >> >>> On Fri, Jan 24, 2014 at 9:56 AM, George, Wes <wesley.geo...@twcable.com> >>> wrote: >>>> 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.” >>>> >>> >>> 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? >>> >>>> 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. >>>> >>> >>> I suspect it is. It somewhat seems like a non-terminating discussion.... >>> >>> W >>>> 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" <morr...@ops-netman.net> wrote: >>>> >>>>> >>>>> Working Group Folken, >>>>> Today starts a WGLC for the subject draft: >>>>> <http://trac.tools.ietf.org/html/draft-ietf-sidr-bgpsec-reqs> >>>>> >>>>> 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 >>> _______________________________________________ >>> 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
