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" <[email protected]> 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" <[email protected]> wrote: > >>On Fri, Jan 24, 2014 at 9:56 AM, George, Wes <[email protected]> >>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" <[email protected]> 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 + >>>>[email protected] mailing list. >>>> >>>>This WGLC completes in 1,209,600 seconds, or 20,160 minutes. >>>> >>>>Thanks! >>>> >>>>-chris >>>>co-chair >>>> >>>> >>>>_______________________________________________ >>>>sidr mailing list >>>>[email protected] >>>>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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/sidr >>_______________________________________________ >>sidr mailing list >>[email protected] >>https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
