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

From: "Montgomery, Douglas" <[email-masked]>
Date: Tue, 13 Jan 2015 00:02:00 +0000

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-masked]> wrote:

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

---

From: "Montgomery, Douglas" <[email-masked]>
Date: Tue, 13 Jan 2015 00:09:31 +0000

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
—

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 13 Jan 2015 11:15:06 -0500

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