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,
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
Ok, with an offline (off email?) conversation with one of the authors
I think it's time to call an end to this very long WGLC.
It seems, to me, that all of the comments and questions were dealt
with, and that overall the document is ready to move along to the next
step in the ponderous (though
ok. i will recover a bit from jet-lag and then hack in a sec cons on
the good issue roque raised.
randy
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
On 5/20/14, 10:38 AM, Randy Bush ra...@psg.com wrote:
we got past
folk looking up 'per se' in their dictionaries.
Well not exactly, since that was never the initial problem. I just decided
not to make an issue out of it any further since I seemed to be the only
one expressing the concern.
On Wed, May 21, 2014 at 3:18 PM, George, Wes wesley.geo...@twcable.com wrote:
On 5/20/14, 10:38 AM, Randy Bush ra...@psg.com wrote:
we got past
folk looking up 'per se' in their dictionaries.
Well not exactly, since that was never the initial problem. I just decided
not to make an issue
ok, so we're just holding on roque then?
no. i know how to deal with that one. but i do not want to make
multiple updates. so waiting for wglc to finish (actually, i think
it timed out already), so i can issue one hack.
randy
___
sidr mailing list
On Wed, May 21, 2014 at 3:53 PM, Randy Bush ra...@psg.com wrote:
ok, so we're just holding on roque then?
no. i know how to deal with that one. but i do not want to make
multiple updates. so waiting for wglc to finish (actually, i think
it timed out already), so i can issue one hack.
yes,
funny. datatracker does not show wglc for this document
randy, trying to time that small fix for roque
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
i didn't update the tracker... (i hadn't ever in the past).
Did we circle down on an answer for the leak/persay language that
everyone's happy with? If so I'd like to push out a pub request today.
On Tue, May 20, 2014 at 9:52 AM, Randy Bush ra...@psg.com wrote:
funny. datatracker does not show
i didn't update the tracker... (i hadn't ever in the past).
uh, that is between you and the datawhacker
Did we circle down on an answer for the leak/persay language that
everyone's happy with? If so I'd like to push out a pub request today.
as far as i am aware, there is no issue with leak
On Tue, May 20, 2014 at 10:38 AM, Randy Bush ra...@psg.com wrote:
i didn't update the tracker... (i hadn't ever in the past).
uh, that is between you and the datawhacker
Did we circle down on an answer for the leak/persay language that
everyone's happy with? If so I'd like to push out a pub
Randy,
while checking the docco, i found
3.14 While the trust level of a route should be determined by the
BGPsec protocol, local routing preference and policy MUST then
be applied to best path and other routing decisions. Such
mechanisms SHOULD conform with
3.14 While the trust level of a route should be determined by the
BGPsec protocol, local routing preference and policy MUST then
be applied to best path and other routing decisions. Such
mechanisms SHOULD conform with [I-D.ietf-sidr-ltamgmt].
...
3.17 If a
On Mon, May 5, 2014 at 12:41 PM, Randy Bush ra...@psg.com wrote:
3.14 While the trust level of a route should be determined by the
BGPsec protocol, local routing preference and policy MUST then
be applied to best path and other routing decisions. Such
mechanisms
3.14 While the trust level of a route should be determined by the
BGPsec protocol, local routing preference and policy MUST then
be applied to best path and other routing decisions. Such
mechanisms SHOULD conform with [I-D.ietf-sidr-ltamgmt].
...
3.17 If a
On May 5, 2014, at 9:41 AM, Randy Bush ra...@psg.com wrote:
3.14 While the trust level of a route should be determined by the
BGPsec protocol, local routing preference and policy MUST then
be applied to best path and other routing decisions. Such
mechanisms SHOULD
coming back to this discussion...
On Fri, Feb 7, 2014 at 10:17 PM, Randy Bush ra...@psg.com wrote:
perhaps people should use a dictionary and look up per se.
(from dictionary.com, or wherever bing.com 'define per se' comes from)
per se
1. by or in itself or themselves; intrinsically.
so, as I
I could easily replace per se with 'intrinsically' like:
yes. do we need to play synonyms when, ab definito, they mean the same
thing? i chose my words. as you point out, they are correct.
Is there a reason to keep the mention of route-leaks in this document?
i think it was shane who
On Mon, Apr 14, 2014 at 11:00 AM, Randy Bush ra...@psg.com wrote:
while checking the docco, i found
3.14 While the trust level of a route should be determined by the
BGPsec protocol, local routing preference and policy MUST then
be applied to best path and other routing
perhaps people should use a dictionary and look up per se.
randy
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
Randy,
hence the per se, meaining in and of itself. some cases of pouring
cement into a router (see london tube) are security issues, some are
not.
how would you make that more clear?
I think Warren’s suggestion of simply eliminating the assertion about
whether it’s a security issue, per se
On 1/25/14, 3:33 AM, Randy Bush ra...@psg.com wrote:
hence the per se, meaining in and of itself. some cases of pouring
cement into a router (see london tube) are security issues, some are
not.
how would you make that more clear?
I think Warren’s suggestion of simply eliminating the assertion
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.”
My issue
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
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
On 1/24/14, 10:04 AM, Warren Kumari war...@kumari.net wrote:
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?
It would at least address the concern
I support publication of this document as RFC.
Regards,
Keyur
On 1/10/14 5: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
On Tue, Jan 14, 2014 at 6:38 PM, Sriram, Kotikalapudi
kotikalapudi.sri...@nist.gov wrote:
I support publication of this document as an RFC.
As do I.
W
I have some comments listed below that are meant to help improve clarity.
3.2 (current) A BGPsec design must allow the receiver of a BGP
I support publication of this document as an RFC.
I have some comments listed below that are meant to help improve clarity.
3.2 (current) A BGPsec design must allow the receiver of a BGP announcement to
determine, to a strong level of certainty, that the received PATH attribute
accurately
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
On Fri, Oct 28, 2011 at 2:40 PM, Christopher Morrow
christopher.mor...@gmail.com wrote:
Seems that the authors, at least, expect this doc to be prepared for
WGLC, could we do that concluding 11/11/11 please?
Sorry, didn't notice the date in the request.
I do have some brief comments about a
Hey everyone,
So, based on both a long flight, and the comments already made about this
draft, I re-read it and wanted to make the following additional comments. I
don't think these are redundant with the comments other have made, but if any
of them are, sorry for the noise.
First, I think
On Nov 11, 2011, at 12:07 PM, Sriram, Kotikalapudi wrote:
So yes, I did consider the _prefix _ updates as is the case in BGPSEC (not
updates with packing in it).
Sriram,
Yes, I saw this, and it is a useful datapoint.
I was looking for something more quantitative and closer to core
ISPs
be different, of
course.
-chris
-Original Message-
From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf
Of Eric Osterweil
Sent: Thursday, November 10, 2011 10:46 AM
To: Christopher Morrow
Cc: Sriram, Kotikalapudi; sidr wg list
Subject: Re: [sidr] WGLC: draft-ietf-sidr
On Fri, Nov 11, 2011 at 8:49 AM, Danny McPherson da...@tcb.net wrote:
On Nov 11, 2011, at 8:19 AM, Christopher Morrow wrote:
There's actually some research on this, I recall the number 'globally'
as 1.2 avg packing... but internally, that may be different, of
course.
I'd be interested in a
: draft-ietf-sidr-bgpsec-reqs
On Fri, Nov 11, 2011 at 8:49 AM, Danny McPherson da...@tcb.net wrote:
On Nov 11, 2011, at 8:19 AM, Christopher Morrow wrote:
There's actually some research on this, I recall the number 'globally'
as 1.2 avg packing... but internally, that may be different, of
course
-
From: Jakob Heitz [mailto:jakob.he...@ericsson.com]
Sent: Tuesday, November 08, 2011 12:09 PM
To: Sriram, Kotikalapudi
Cc: Christopher Morrow; Eric Osterweil; sidr wg list
Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs
Proposal was 24 hour beacon timeout and 3 beacons per timeout
On Nov 10, 2011, at 1:41 PM, Christopher Morrow wrote:
On Wed, Nov 9, 2011 at 3:37 PM, Eric Osterweil eosterw...@verisign.com
wrote:
Hey Sriram, Russ, and Jakob,
Thanks for the #s. I think I get the general notion that adding n updates
per day per prefix equals (n * #prefixes)/1. :) I
, Kotikalapudi; sidr wg list
Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs
On Nov 10, 2011, at 1:41 PM, Christopher Morrow wrote:
On Wed, Nov 9, 2011 at 3:37 PM, Eric Osterweil
eosterw...@verisign.com wrote:
Hey Sriram, Russ, and Jakob,
Thanks for the #s. I think I get
Hi, Sriram,
Could you supply similar kinds of numbers, but with peak instead of
average, esp. 50%ile, 75%ile, and 95%-ile levels for peak?
Average is much less important than peak, in my experience.
Steady-state is easy.
Also, in noisy/spiky data, mean != median typically. BGP is noisy/spiky.
]
Sent: Tuesday, November 08, 2011 12:09 PM
To: Sriram, Kotikalapudi
Cc: Christopher Morrow; Eric Osterweil; sidr wg list
Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs
Proposal was 24 hour beacon timeout and 3 beacons per timeout. That makes 3
beacons per day.
--
Jakob Heitz
On Nov 8, 2011, at 12:19 PM, Sriram, Kotikalapudi wrote:
Now the ops doc has much longer beaconing interval recommendations
for what you may consider a normal prefix.
http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-ops-01#section-7
Normal Prefix: Most prefixes SHOULD announce
ooc, in regards to the above: is there any detailed analysis of how much
extra overhead we can expect from these beacons if BGPSec were deployed
universally today? Specifically, the comment above, an AS could cause the
same impact on the routing system by changing other route parameters
Now if we consider a BGPSEC island of 100,000 participating prefixes
(multiple ISPs form a BGPSEC island and there is BGPSEC between
them and also in each ISP's entire customer cone):
With 24 hour beaconing interval, we would have:
Prefix Updates per Day = 100,000 (seen at each BGPSEC router)
It's one additional update per table entry per day, assuming a 24 hour
beacon. If the table is 300,000 routes, it's 300,000 additional
updates a day --on top of normal churn.
note that this is not churn, in the sense of fib update, which is 90% of
the cost of an update.
At some point you're
nope. gains absolute zero replay protection. see my preso from VdeQ.
I fail to see how this is possible. Please send a pointer.
but i am not really interested in the noise about beaconing. as i said
in VdeQ, the feature is nice but not all that important.
You're saying replay
nope. gains absolute zero replay protection. see my preso from VdeQ.
I fail to see how this is possible. Please send a pointer.
from slide 10
A originates the announcement
If everyone beacons, assume the beacon TTL applies only to that hop
B gets it from A, C gets it from B, D gets it from
and, slide 11
So try believing minimum TTL in chain
But are all redundant to the first, since if that one expires none of the
others should even be sent
An intermediate might want a lower one, in case its downstream link goes down,
but why?
The downstream neighbor will announce a different
Proposal was 24 hour beacon timeout and 3 beacons per timeout. That makes 3
beacons per day.
--
Jakob Heitz.
On Nov 8, 2011, at 5:00 AM, Sriram, Kotikalapudi
kotikalapudi.sri...@nist.gov wrote:
ooc, in regards to the above: is there any detailed analysis of how much
extra overhead we
three days.
Sriram
-Original Message-
From: Jakob Heitz [mailto:jakob.he...@ericsson.com]
Sent: Tuesday, November 08, 2011 12:09 PM
To: Sriram, Kotikalapudi
Cc: Christopher Morrow; Eric Osterweil; sidr wg list
Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs
Proposal was 24 hour beacon
On Nov 3, 2011, at 11:59 AM, Stephen Kent wrote:
At 9:32 PM -0400 11/2/11, Danny McPherson wrote:
On Nov 2, 2011, at 11:04 AM, Stephen Kent wrote:
snip
More specifically, if I have perform a cost/benefit analysis it's not at all
clear to me
that tightening exposure windows to the
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
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 speakers in different
trust domains. iBGP integrity
From: Christopher Morrow
Seems that the authors, at least, expect this doc to be prepared for
WGLC
-Chris
wg-co-chair-haircut == completed
[WEG]] So should we expect you to have SIDR or WGCHAIR shaved into your
hair when we see you in Taipei? ;-)
More seriously, some comments...
Seems that the authors, at least, expect this doc to be prepared for
WGLC, could we do that concluding 11/11/11 please?
Draft link: http://tools.ietf.org/wg/sidr/draft-ietf-sidr-bgpsec-reqs/
01 link: http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-reqs
diff link:
On Oct 28, 2011, at 2:40 PM, Christopher Morrow wrote:
Seems that the authors, at least, expect this doc to be prepared for
WGLC, could we do that concluding 11/11/11 please?
I've got a couple of comments.
Some high-level bits captured with specific comments below
include:
1) this
57 matches
Mail list logo
