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

[Sandra Murphy <[e-mail]>]

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