3. So the ability to remove the B to E link from the possible paths
available to reach A, enforcable by D, is actually a new feature in BGP.
i don't think so, it's a 'feature' of bgp in general, isn't it? not 'new'.
Not advertising something already exists --telling a remote AS that the
i don't think the case you outline is one of actually telling the
remote-as that the path doesn't exist because of policy. the /fact of
policy/ can be inferred, and I outlined 3 (or more) places you could
infer at D that there was some policy decision happening. I don't
think it's at all
On Wed, Mar 21, 2012 at 7:46 AM, Russ White ru...@riw.us wrote:
i don't think the case you outline is one of actually telling the
remote-as that the path doesn't exist because of policy. the /fact of
policy/ can be inferred, and I outlined 3 (or more) places you could
infer at D that there
Let me try another, more concise phrasing. When one adds secruity to a
protocol, the goal is to enable it to operate in a hostile environment with
the same semantics that it offered in a non-hostile environment. Of course a
secure version of a protocol will exhibit some differences in its
The point is you've gone beyond the existence of the path here to the
rightful use of the path --and that is policy.
don't think so.
Yes, you have.
Because you've insisted on making the solution work per prefix, you've
moved the problem out of the realm of path validation and into the realm
On Wed, Mar 21, 2012 at 9:43 AM, Russ White ru...@riw.us wrote:
The point is you've gone beyond the existence of the path here to the
rightful use of the path --and that is policy.
don't think so.
Yes, you have.
Because you've insisted on making the solution work per prefix, you've
moved
The point is you've gone beyond the existence of the path here to the
rightful use of the path --and that is policy.
don't think so.
Yes, you have.
Because you've insisted on making the solution work per prefix, you've
moved the problem out of the realm of path validation and into the
On Wed, Mar 21, 2012 at 10:08 AM, Russ White ru...@riw.us wrote:
The point is you've gone beyond the existence of the path here to the
rightful use of the path --and that is policy.
don't think so.
Yes, you have.
Because you've insisted on making the solution work per prefix, you've
no, you never sent anything of this route to E so E never had anything
to pass along to C and then to D ... knowledge of this path is not
there, in both the SIDR and non-SIDR cases. All D knows in both SIDR
and non-SIDR cases is: Look at that, a path through C to B to A,
joy!
If E makes up
I think we are chasing our tails around the use of path as an abstraction
of the set of peering relationships and PATH as a specific sequence of
announcements of a given prefix (I.e., the AS_PATH attribute).
Not that the debate isn't amusing, but sorting out those terms out might
allow it to move
Chris,
On Mar 21, 2012, at 8:15 AM, Christopher Morrow wrote:
On Wed, Mar 21, 2012 at 10:08 AM, Russ White ru...@riw.us wrote:
The point is you've gone beyond the existence of the path here to the
rightful use of the path --and that is policy.
don't think so.
Yes, you have.
Because
By we I assume you are asking the bigger question about what the broad
requirements / objectives should be.
The current BGPSEC design, chooses to only focus on the protocol on the
wire, and starts with the attributes that had both an identified threat
and a existence proof of a reasonable
On Wed, Mar 21, 2012 at 10:52 AM, Russ White ru...@riw.us wrote:
no, you never sent anything of this route to E so E never had anything
to pass along to C and then to D ... knowledge of this path is not
there, in both the SIDR and non-SIDR cases. All D knows in both SIDR
and non-SIDR cases
On Wed, Mar 21, 2012 at 11:37 AM, Montgomery, Douglas do...@nist.govwrote:
By we I assume you are asking the bigger question about what the broad
requirements / objectives should be.
The current BGPSEC design, chooses to only focus on the protocol on the
wire, and starts with the attributes
I can't even begin to make sense out of this --can you explain?
nope. i don't play russ white ping pong
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
On Wed, Mar 21, 2012 at 11:50 AM, Brian Dickson
brian.peter.dick...@gmail.com wrote:
On Wed, Mar 21, 2012 at 11:37 AM, Montgomery, Douglas do...@nist.gov
wrote:
By we I assume you are asking the bigger question about what the broad
requirements / objectives should be.
The current BGPSEC
On Wed, Mar 21, 2012 at 12:10 PM, Christopher Morrow
morrowc.li...@gmail.com wrote:
On Wed, Mar 21, 2012 at 11:50 AM, Brian Dickson
brian.peter.dick...@gmail.com wrote:
On Wed, Mar 21, 2012 at 11:37 AM, Montgomery, Douglas do...@nist.gov
wrote:
By we I assume you are asking the
On Wed, Mar 21, 2012 at 12:36 PM, Brian Dickson
brian.peter.dick...@gmail.com wrote:
On Wed, Mar 21, 2012 at 12:10 PM, Christopher Morrow
morrowc.li...@gmail.com wrote:
On Wed, Mar 21, 2012 at 11:50 AM, Brian Dickson
brian.peter.dick...@gmail.com wrote:
On Wed, Mar 21, 2012 at 11:37
The prefix-to-AS mappings used by the BGP speaker are expected to be
updated over time. When a mapping is added or deleted, the
implementation MUST re-validate any affected prefixes. An affected
prefix is any prefix that was matched by a deleted or updated
mapping, or could be
In the flurry of apologetic emails that preceeded and followed this
announcement, I did not apolgize to the working group.
This was my strictly my bungle, in two different directions.
First, I announced the meeting to the sidr mailing list within the time frame
required by process. The bungle
Tue, Mar 20, 2012 at 04:28:15PM +0100, Bert Wijnen (IETF):
So I had been in discussion with Jeff in order to see
if we could get the BGP4-mibv2 module in good shape.
Below is out discussion.
Those who are interested in this MIB module at all
may want to take a look to make sure they agree
At 11:50 AM -0400 3/21/12, Brian Dickson wrote:
On Wed, Mar 21, 2012 at 11:37 AM, Montgomery, Douglas
mailto:do...@nist.govdo...@nist.gov wrote:
By we I assume you are asking the bigger question about what the broad
requirements / objectives should be.
The current BGPSEC design, chooses to
On Wed, Mar 21, 2012 at 1:40 PM, Stephen Kent k...@bbn.com wrote:
**
At 11:50 AM -0400 3/21/12, Brian Dickson wrote:
On Wed, Mar 21, 2012 at 11:37 AM, Montgomery, Douglas do...@nist.gov
wrote:
By we I assume you are asking the bigger question about what the broad
requirements / objectives
On Mar 21, 2012, at 12:45 PM, Christopher Morrow wrote:
On Wed, Mar 21, 2012 at 12:36 PM, Brian Dickson
brian.peter.dick...@gmail.com wrote:
On Wed, Mar 21, 2012 at 12:10 PM, Christopher Morrow
morrowc.li...@gmail.com wrote:
On Wed, Mar 21, 2012 at 11:50 AM, Brian Dickson
At 10:48 PM -0400 3/20/12, Eric Osterweil wrote:
On Mar 20, 2012, at 4:50 PM, Stephen Kent wrote:
...
For one: pedantic compilers are often helpful when it comes to
static analysis. By extension, _sometimes_ one can make the same
argument (about static analysis) to justify being pedantic for
While I am enjoying our rendition of Mr. Toad's Wild Ride (i.e. the meanderings
of this thread,
http://en.wikipedia.org/wiki/Mr._Toad%27s_Wild_Ride#Disneyland_version ), I
suspect others on the list may be growing tired of it. I will try to prune my
blow-by-blow to just what seems
The current BGPSEC design, chooses to only focus on the protocol on the
wire, and starts with the attributes that had both an identified threat
and a existence proof of a reasonable mechanism to address that threat.
BGPSEC:
1. Fails to actually protect the bits on the wire in a way that
On Mar 21, 2012, at 3:33 PM, Russ White wrote:
The current BGPSEC design, chooses to only focus on the protocol on the
wire, and starts with the attributes that had both an identified threat
and a existence proof of a reasonable mechanism to address that threat.
BGPSEC:
1. Fails to
Sorry to interject, but...
On Mar 21, 2012, at 3:01 PM, Stephen Kent wrote:
snip
I would also opine, that _not_ addressing other, identifiable and
identified vulnerabilities, would be seen by the rest of the IETF and by the
users of BGP (operators of the 30k ASNs) as a massive #FAIL.
nope, it's bits that you can choose to use or not.
In other words, you've added another set of wiggle words to your
definition. It's not policy because it's not signing something saying
you shouldn't do x, and because anyone can ignore the signature anyway.
Sorry, I don't buy it.
You are
On 2012-03-21 16:50, Brian Dickson wrote:
...
Doing so would require, at a minimum, stopping forward progress on
-protocol docs, until the -reqs- and -threat- are adequately addressed.
On 2012-03-21 20:33, Russ White wrote:
...
Given these failures, maybe it's time to start with
On Wed, Mar 21, 2012 at 3:19 PM, Eric Osterweil eosterw...@verisign.com wrote:
How about we turn this around with a simple question:
Suppose two different feasible paths are being evaluated for a single
prefix/origin pair and one was delivered via a signed bgpsec update, and the
other was
On Wed, Mar 21, 2012 at 3:40 PM, Eric Osterweil eosterw...@verisign.com wrote:
My input is that the current work that does not address the real route leak
threat, and it is therefore insufficient.
and many, many times ... 'how would you do this, really, show me the
math' has been asked. the
On Mar 21, 2012, at 4:57 PM, Christopher Morrow wrote:
On Wed, Mar 21, 2012 at 3:19 PM, Eric Osterweil eosterw...@verisign.com
wrote:
How about we turn this around with a simple question:
Suppose two different feasible paths are being evaluated for a single
prefix/origin pair and one
On Wed, Mar 21, 2012 at 5:04 PM, Eric Osterweil eosterw...@verisign.com wrote:
On Mar 21, 2012, at 4:57 PM, Christopher Morrow wrote:
On Wed, Mar 21, 2012 at 3:19 PM, Eric Osterweil eosterw...@verisign.com
wrote:
How about we turn this around with a simple question:
Suppose two different
On Mar 21, 2012, at 3:00 PM, Christopher Morrow wrote:
On Wed, Mar 21, 2012 at 3:40 PM, Eric Osterweil eosterw...@verisign.com
wrote:
My input is that the current work that does not address the real route leak
threat, and it is therefore insufficient.
and many, many times ... 'how would
On 3/21/12 3:56 PM, Robert Raszuk rob...@raszuk.net wrote:
On 2012-03-21 16:50, Brian Dickson wrote:
...
Doing so would require, at a minimum, stopping forward progress on
-protocol docs, until the -reqs- and -threat- are adequately addressed.
On 2012-03-21 20:33, Russ White wrote:
...
Hey Chris,
On Mar 21, 2012, at 5:00 PM, Christopher Morrow wrote:
On Wed, Mar 21, 2012 at 3:40 PM, Eric Osterweil eosterw...@verisign.com
wrote:
My input is that the current work that does not address the real route leak
threat, and it is therefore insufficient.
and many, many times ...
Hey Chris,
On Mar 21, 2012, at 5:06 PM, Christopher Morrow wrote:
On Wed, Mar 21, 2012 at 5:04 PM, Eric Osterweil eosterw...@verisign.com
wrote:
On Mar 21, 2012, at 4:57 PM, Christopher Morrow wrote:
On Wed, Mar 21, 2012 at 3:19 PM, Eric Osterweil eosterw...@verisign.com
wrote:
How
Hi Chris,
In the end, I think 'bgpsec suggests' that the operator would make
some decision... ideally the same decision across the network.
Such decision is inherently per prefix. So even assuming ideal case and
such policy like in your example would be the same across given AS how
would
On Wed, Mar 21, 2012 at 5:13 PM, Shane Amante sh...@castlepoint.net wrote:
On Mar 21, 2012, at 3:00 PM, Christopher Morrow wrote:
On Wed, Mar 21, 2012 at 3:40 PM, Eric Osterweil eosterw...@verisign.com
wrote:
My input is that the current work that does not address the real route leak
On Mar 21, 2012, at 3:21 PM, Christopher Morrow wrote:
On Wed, Mar 21, 2012 at 5:13 PM, Shane Amante sh...@castlepoint.net wrote:
On Mar 21, 2012, at 3:00 PM, Christopher Morrow wrote:
On Wed, Mar 21, 2012 at 3:40 PM, Eric Osterweil eosterw...@verisign.com
wrote:
My input is that the
On Wed, Mar 21, 2012 at 5:26 PM, Shane Amante sh...@castlepoint.net wrote:
On Mar 21, 2012, at 3:21 PM, Christopher Morrow wrote:
On Wed, Mar 21, 2012 at 5:13 PM, Shane Amante sh...@castlepoint.net wrote:
On Mar 21, 2012, at 3:00 PM, Christopher Morrow wrote:
On Wed, Mar 21, 2012 at 3:40 PM,
Answer: Evaluate policy.
'apply prefix lists' you mean?
No. Evaluate _policy_. Policy is about whether an ASN /intended/ to
announce a path to another ASN _or_ not. More succinctly: one needs
input to verify output, (since you said show me the math).
From: Randy Bush ra...@psg.com
On Mar 21, 2012, at 3:37 PM, Christopher Morrow wrote:
On Wed, Mar 21, 2012 at 5:26 PM, Shane Amante sh...@castlepoint.net wrote:
On Mar 21, 2012, at 3:21 PM, Christopher Morrow wrote:
On Wed, Mar 21, 2012 at 5:13 PM, Shane Amante sh...@castlepoint.net wrote:
On Mar 21, 2012, at 3:00 PM,
As I said in my prior message, I'm not going to continue contributing
to a thread that seems pointless at this stage.
Steve
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
in this:
http://mailman.nanog.org/pipermail/nanog/2012-February/045941.html
message. This is what you mean as well, yes?
Yes. And, to answer Randy's question in that message ... I'm not
asserting that this is a _simple_ problem to be solved, but we should
not ignore the problem b/c it's
Many moons ago (IETF attendance was 100) there was an effort to solve
this problem (Open Routing Working Group).
Stable refs are hard to find ... But the following gives a decent summary
of an approach to such a solution.
On Wed, Mar 21, 2012 at 5:19 PM, Robert Raszuk rob...@raszuk.net wrote:
Hi Chris,
In the end, I think 'bgpsec suggests' that the operator would make
some decision... ideally the same decision across the network.
Such decision is inherently per prefix. So even assuming ideal case and such
On Mar 21, 2012, at 5:42 PM, Shane Amante wrote:
On Mar 21, 2012, at 3:37 PM, Christopher Morrow wrote:
On Wed, Mar 21, 2012 at 5:26 PM, Shane Amante sh...@castlepoint.net wrote:
On Mar 21, 2012, at 3:21 PM, Christopher Morrow wrote:
On Wed, Mar 21, 2012 at 5:13 PM, Shane Amante
On 3/21/12 5:56 PM, Christopher Morrow morrowc.li...@gmail.com wrote:
On Wed, Mar 21, 2012 at 5:19 PM, Robert Raszuk rob...@raszuk.net wrote:
Hi Chris,
In the end, I think 'bgpsec suggests' that the operator would make
some decision... ideally the same decision across the network.
Such
On Wed, Mar 21, 2012 at 5:17 PM, Eric Osterweil eosterw...@verisign.com wrote:
Hey Chris,
On Mar 21, 2012, at 5:06 PM, Christopher Morrow wrote:
On Wed, Mar 21, 2012 at 5:04 PM, Eric Osterweil eosterw...@verisign.com
wrote:
On Mar 21, 2012, at 4:57 PM, Christopher Morrow wrote:
On Wed,
On Mar 21, 2012, at 3:47 PM, Randy Bush wrote:
in this:
http://mailman.nanog.org/pipermail/nanog/2012-February/045941.html
message. This is what you mean as well, yes?
Yes. And, to answer Randy's question in that message ... I'm not
asserting that this is a _simple_ problem to be solved,
The drafts (three of them, together) are an attempt to define, constrain,
and solve the problem.
Yes, it is tricky and difficult. I'm not saying that the solutions (two of
them to choose from) are the only way to do it.
But, I believe that either of them actually solves the problem.
In a
On 3/21/12 6:05 PM, Robert Raszuk rob...@raszuk.net wrote:
What happens in your example if singed comes with PATH_SIG listing
4 ASes
(pCount=1 of each) and real AS_PATH is length of 3 ?
so, pcount I'm not a fan of but, you're suggesting a path that's
invalid? or impossible?
Worse
brian, i scanned some time ago and am reading (trying to get other work
done too). i think you are too good a typist:) i think your ideas could
be reduced to a page. this is a feature, not a bug.
but i think you are on a constructive path as opposed to screaming that
someone else should solve
Maybe there is misunderstanding ...
Chris example was stating:
1) first path gets evaluated, is it 'good' (next-hop reachable, not
discarded by prefix-list/etc)
2) second path gets evaluated, is it 'good' (same as above +
origin-validate + path-validation)
One path comes without
57 matches
Mail list logo
