I agree that intent can not be known.
Which is why I had asked that the motivation / intent related text be
included in the introduction, not in the requirements.
i have done so in the yet-to-be-released version
3.19 A BGPsec design SHOULD NOT presume to know the intent of the
Original Message -
From: Joel M. Halpern j...@joelhalpern.com
To: Randy Bush ra...@psg.com
Cc: t.petch ie...@btconnect.com; sidr@ietf.org
Sent: Wednesday, March 02, 2011 11:25 PM
Unfortunately, that change shifts things just enough to miss an
important part of what I was hoping to
- Original Message -
From: Joel M. Halpern j...@joelhalpern.com
To: Randy Bush ra...@psg.com
Cc: sidr@ietf.org
Sent: Wednesday, March 02, 2011 12:25 AM
I think that would help, and it is good enough for me.
Thank you,
Joel
On 3/1/2011 6:07 PM, Randy Bush wrote:
something like
Worded like this, with the emphasis on the consequences, would seem to
include such things as inserting spurious communities, as opposed to
just modifying the AS-Path in an unacceptable way. Is that the
intention?
It is quite a shift from the focus of 10 days ago, which I read as
solely
i could make it something like
3.1 A BGPsec design MUST allow the receiver of an announcement to
detect that one or more ASes have manipulated the AS-Path in an
attempt to lure the receiver into sending traffic to an incorrect
next hop.
in a private email, a friend
...@ietf.org] On Behalf Of
Randy Bush
Sent: Wednesday, March 02, 2011 3:00 PM
To: t.petch
Cc: sidr@ietf.org
Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation
work
i could make it something like
3.1 A BGPsec design MUST allow the receiver of an announcement
Unfortunately, that change shifts things just enough to miss an
important part of what I was hoping to achieve.
While it is true that we can not know why anyone does anything, the
reason we care about it is that certain kinds of path falsification can
result in traffic being lured to places
While it is true that we can not know why anyone does anything
...
The purpose of the whole exchange was to try to get a motivation into
the picture
a conundrum wrapped in a cabbage leaf. the draft can not meet the
desires of both directions here, and the new version needs to get out.
being
Randy, would you be willing to be wording like this, with your
corrections, into section 1 of the document?
lemme try to reword it, but later in the day.
o To prevent any advertiser from sending an advertisement that would
cause other properly behaving parties to send traffic iin a way that
something like
A BGPsec design MUST allow the receiver of an announcement to
detect that one or more ASes on the AS-Path is attempting to
lure the receiver into sending traffic in a way that an
announcer is not entitled to receive.
?
randy
I think that would help, and it is good enough for me.
Thank you,
Joel
On 3/1/2011 6:07 PM, Randy Bush wrote:
something like
A BGPsec design MUST allow the receiver of an announcement to
detect that one or more ASes on the AS-Path is attempting to
lure the receiver
actually, a bit more coffee inclines me toward an even more restrictive
statement
A BGPsec design MUST allow the receiver of an announcement to
detect that one or more ASes on the AS-Path is attempting to
lure the receiver into sending traffic to an incorrect next
John,
But wouldn't a record of an existing announcement also show that AS_B did in
fact announce which of AS_A's routes and in what form? Why does it need to be
signed if all we want to do is record what happened? Perhaps I'm missing
something
Andrew
On Feb 24, 2011, at 5:27 AM, John
: Wednesday, February 23, 2011 6:17 PM
To: Sandra Murphy
Cc: sidr@ietf.org
Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work
--- snip ---
From a work item perspective, it would be useful to have a relationship
object signed that
says I'm AS_A, and I have AS_B and AS_Q
Geoff,
My reasoning is that without a specific policy statement, such as B should
be announcing this route, signed A, then we can demonstrate that B did
announce it, but not if B should have announced it. With that policy object
then we can construct the route filter to check that not only
John,
To reply to my own message, after reading through the rest of this chain.
Is all we're trying to do here is to establish a custodial chain of a route
to prevent some ill-behaving AS in the middle attempting to hijack a route,
effectively by pretending that the source AS is behind it,
On Mon, Feb 28, 2011 at 11:28 PM, Andrew Lange
andrew.la...@alcatel-lucent.com wrote:
If that is the case, having a set of policy objects expressing AS
relationship should do the same
thing and more with less overhead? (yes, I know that data integrity becomes
an issue, but data
integrity
If that is the case, having a set of policy objects expressing AS
relationship should do the same thing and more with less overhead?
real policy is per prefix, customer, peer, and things disgustingly more
complex, with complications of backdoor relationships, ibgp policies to
implement
If that is the case, having a set of policy objects expressing AS
relationship should do the same
thing and more with less overhead? (yes, I know that data integrity becomes
an issue, but data
integrity is always an issue.)
I was deliberately keeping away from participating in this
If you can establish the former (that the route did travel across the
path it said it did), that outcome can be used as input to policy.
This is exactly analogous to draft-ietf-sidr-pfx-validate-01, BTW.
Divide, conquer. A commonly used trick in computing. :-)
more like what is taught in
On Feb 24, 2011, at 10:00 PM, Russ White wrote:
Can you explain the difference in some other way that doesn't mix the
two ideas?
Since after reading your message carefully three times I don't understand your
question, I'm unable to answer it. Sorry.
--John
Can you explain the difference in some other way that doesn't mix the
two ideas?
Since after reading your message carefully three times I don't understand
your question, I'm unable to answer it. Sorry.
You're apparently trying to separate the idea of proving an update
traveled a specific
On Feb 25, 2011, at 4:10 PM, Russ White wrote:
Can you explain the difference in some other way that doesn't mix the
two ideas?
Since after reading your message carefully three times I don't understand
your question, I'm unable to answer it. Sorry.
You're apparently trying to separate
You're apparently trying to separate the idea of proving an update
traveled a specific path from the idea of using this information to
actually filter or determine any other policy. I don't see how you can
separate the two --can you explain how you can?
If you can establish the former
Let me try phrasing the issue differently. I may still be missing the
point, from all sides.
I believe that what is actually wanted is primarily:
o To prevent any advertiser from sending an advertisement that would
cause other properly behaving parties to send traffic iin a way that
they are
I think that is more or less right.
--John
On Feb 25, 2011, at 4:29 PM, Joel M. Halpern wrote:
Let me try phrasing the issue differently. I may still be missing the point,
from all sides.
I believe that what is actually wanted is primarily:
o To prevent any advertiser from sending an
On Feb 25, 2011, at 4:26 PM, Russ White wrote:
You're apparently trying to separate the idea of proving an update
traveled a specific path from the idea of using this information to
actually filter or determine any other policy. I don't see how you can
separate the two --can you explain how
* Is the AS-Path represented in the route the same as the path
through which the route update traveled
This doesn't speak to any particular AS in the path. It just asks whether
there is a custodial chain that extends back to the route's origin.
Why does the custodial chain
On Feb 25, 2011, at 4:54 PM, Russ White wrote:
Why does the custodial chain matter?
I think Joel summed it up pretty well. Rather than continue to pick at this
nit, why not switch gears and see what you think of his alternate formulation?
--John
___
On 2/25/2011 9:56 AM, John Scudder wrote:
On Feb 25, 2011, at 4:54 PM, Russ White wrote:
Why does the custodial chain matter?
I think Joel summed it up pretty well. Rather than continue to pick at this
nit, why not switch gears and see what you think of his alternate formulation?
I
[extra cc's dropped]
On Feb 25, 2011, at 5:00 PM, Russ White wrote:
On 2/25/2011 9:56 AM, John Scudder wrote:
...
I think Joel summed it up pretty well. Rather than continue to pick at this
nit, why not switch gears and see what you think of his alternate
formulation?
I thought I
Andrew,
On Feb 24, 2011, at 1:17 AM, Andrew Lange wrote:
Given the thread, I can understand your frustration. And, I could have made
myself more clear. I'll try: given the policies that AS_B might be
implementing, we cannot know for certain, without AS_B publishing their
policies, if
I interpret the proposed charter item to be asking not if AS_B *should* in
fact be announcing which of AS_A's routes or in what form but rather roughly
if AS_B *did* in fact announce which of AS_A's routes and in what form.
Isn't this a difference without a distinction? Let me put it
On Tue, 22 Feb 2011, Andrew Lange wrote:
To divert the discussion a bit back into the realm of requirements.
What is the current diameter of the Internet? From my recollections it was
converging toward about 4 ASes in diameter. This would mean that for most paths we have:
AS_A -- AS_B --
On Feb 16, 2011, at 7:53 PM, Christopher Morrow wrote:
[...]
The purpose of the SIDR working group is to reduce vulnerabilities in
the inter-domain routing system. The two vulnerabilities that will be
addressed are:
* Is an Autonomous System (AS) authorized to originate an IP prefix
*
Randy,
On Feb 22, 2011, at 20:11 MST, Randy Bush wrote:
If we have already authenticated the route origin, with either offline
or online enforcement depending on your preference, we have
cryptographically bound a route object to an aut num.
btw, the sidr work to date has not formally bound
On Wed, 23 Feb 2011, Shane Amante wrote:
Randy,
On Feb 22, 2011, at 20:11 MST, Randy Bush wrote:
If we have already authenticated the route origin, with either offline
or online enforcement depending on your preference, we have
cryptographically bound a route object to an aut num.
btw,
Hi Sandy,
Reply is inline.
On Feb 23, 2011, at 2:52 AM, Sandra Murphy wrote:
On Tue, 22 Feb 2011, Andrew Lange wrote:
To divert the discussion a bit back into the realm of requirements.
What is the current diameter of the Internet? From my recollections it
was converging toward about
On 24/02/2011, at 09:17, Andrew Lange wrote:
From a work item perspective, it would be useful to have a relationship
object signed that says I'm AS_A, and I have AS_B and AS_Q as legitimate
connections.
Geoff published a (now expired) draft for just such an object:
Can you clarify what you mean by the sidr work to date has not
formally bound the route origin ... and [is] easily spoofed?
rpki has roa binding prefix P to asn A0. i run A1. i inject a route
for P with as-path A1 A0. the origin, A0, is what the roa allows, but
has no crypto sig.
that is
Geoff,
Do you disagree as to its utility?
Andrew
On Feb 23, 2011, at 4:16 PM, Geoff Huston wrote:
On 24/02/2011, at 8:09 AM, Robert Loomans wrote:
On 24/02/2011, at 09:17, Andrew Lange wrote:
From a work item perspective, it would be useful to have a relationship
object signed
Andrew,
I hope I was neutral in neither agreeing or disagreeing as to its utility in my
comment.
I was simply checking your assertion that it would be useful to have a
relationship object and gently trying to understand your reasoning behind
holding that view.
Geoff
On 24/02/2011, at
On Wed, Feb 23, 2011 at 9:01 PM, Geoff Huston g...@apnic.net wrote:
Andrew,
I hope I was neutral in neither agreeing or disagreeing as to its utility in
my comment.
I was simply checking your assertion that it would be useful to have a
relationship object and gently trying to understand
Sandy,
Thank you for responding! Please see below.
On Feb 23, 2011, at 13:26 MST, Sandra Murphy wrote:
Can you clarify what you mean by the sidr work to date has not formally
bound the route origin ... and [is] easily spoofed?
This is something that has been mentioned in the wg many
Hello,
On Wed, Feb 23, 2011 at 8:26 PM, Sandra Murphy sandra.mur...@sparta.com wrote:
It is quite easy for an AS to construct an AS_PATH with the legitimate
authorized origin on the origin end, without every having received such an
announcement from the origin. Without the legitimate origin
Randy, please do not indulge in ad-hominem attacks. It does nothing to
help in finding the right answer.
--Sandy
On Tue, 22 Feb 2011, Randy Bush wrote:
|So the only security problem anyone faces, currently, is people cheating
|on the AS Path length?
I thougth my previous post (as well as
To divert the discussion a bit back into the realm of requirements.
What is the current diameter of the Internet? From my recollections it was
converging toward about 4 ASes in diameter. This would mean that for most
paths we have:
AS_A -- AS_B -- AS_C -- AS_D
If we have already
If we have already authenticated the route origin, with either offline
or online enforcement depending on your preference, we have
cryptographically bound a route object to an aut num.
btw, the sidr work to date has not formally bound the route origin. it
is informal, and easily spoofed. the
At 2:12 PM -0500 2/20/11, Russ White wrote:
... the semantic of BGP has never been that the AS Path is used
for anything other than determining if the path is loop free.
That assertion seems to ignore the fact that routing decisions often
take into account path length. Are you saying that
Whatever the primary purpose may have been initially, the fact is that
path length is an important input to path selection as implemented. That
justifies
an effort to ensure that the path seen by a recipient is authentic.
So the only security problem anyone faces, currently, is people
No, messing with an AS_PATH is the fundamental problem.
Cheating on AS_PATH length is just one way to exploit that fundamental
vulnerability.
See other messages for other examples of ways to exploit.
--Sandy
On Mon, 21 Feb 2011, Russ White wrote:
Whatever the primary purpose may have
See other messages for other examples of ways to exploit.
Countering these should be the requirements and the statement in the
charter, not signing the update.
:-)
Russ
signature.asc
Description: OpenPGP digital signature
___
sidr mailing list
On Mon, 21 Feb 2011, Russ White wrote:
|So the only security problem anyone faces, currently, is people cheating
|on the AS Path length?
I thougth my previous post (as well as other) have been pretty clear on
this topic. The Kapella style attacks are sucessful because an
organization can add
On Mon, Feb 21, 2011 at 11:02 AM, Jason Schiller schil...@uu.net wrote:
On Mon, 21 Feb 2011, Russ White wrote:
|So the only security problem anyone faces, currently, is people cheating
|on the AS Path length?
I thougth my previous post (as well as other) have been pretty clear on
this
On Mon, 21 Feb 2011, Shane Amante wrote:
|
|But, who is certifying what are legitimate vs. illegitimate AS_PATH's
|when the AS_PATH is greater than 2?
|
|IOW, let's take a simple case of a stub AS, (AS_A), who is purchasing
|transit from two upstream providers: AS_B and AS_C. In that case, the
Sent: Monday, February 21, 2011 11:40 AM
To: Jason Schiller
Cc: sidr@ietf.org; Russ White
Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation
work
Jason, All,
On Feb 21, 2011, at 09:02 MST, Jason Schiller wrote:
On Mon, 21 Feb 2011, Russ White wrote:
|So the only
-Original Message-
From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of
Shane Amante
Sent: Monday, February 21, 2011 11:40 AM
To: Jason Schiller
Cc: sidr@ietf.org; Russ White
Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation
work
Jason, All
On Fri, 18 Feb 2011, Russ White wrote:
and because AS-Sets are opaque when it comes to security semantics
(which asn in the set is responsible for what part of the aggregate?)
they are excluded from the discussion, and on the road to deprecation.
The point wasn't to say, can each of these
I think we do need to be a little careful about what the AS path
always meant, and what we are going to end up with it meaning if we
follow the path and discussion.
For example, there is long practice of adding not just ones own AS, but
sometimes other AS numbers to a path for policy reasons.
The AS_PATH has always been intended to represent the ASs that
propagated the update.
The AS_PATH can be used to detect loops ONLY because it does represent
the ASs that propagated the update.
Sorry --but I just gave 5 examples of where the AS Path is intentionally
modified without causing
Not to be pedantic, but the BGP spec *does* say that the AS_PATH documents the
path of an UPDATE, and that each AS must add itself:
This attribute identifies the autonomous systems through which routing
information carried in this UPDATE message has passed.
...
When a BGP speaker propagates
Not to be pedantic, but the BGP spec *does* say that the AS_PATH documents
the path of an UPDATE, and that each AS must add itself:
No, it says that's the normal mode of operation... There's no MUST in
here anyplace:
This attribute identifies the autonomous systems through which routing
|So the only security problem anyone faces, currently, is people cheating
|on the AS Path length?
I thougth my previous post (as well as other) have been pretty clear on
this topic.
they were. you are dealing with a one man dos. do not feed the troll.
randy
Feb 2011, Randy Bush wrote:
|Date: Tue, 22 Feb 2011 08:30:01 +0800
|From: Randy Bush ra...@psg.com
|To: Jason Schiller jason.schil...@verizonbusiness.com
|Cc: Russ White r...@cisco.com, sidr@ietf.org
|Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work
|
| |So the only
...@verizonbusiness.com
|Cc: Russ Whiter...@cisco.com, sidr@ietf.org
|Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work
|
| |So the only security problem anyone faces, currently, is people cheating
| |on the AS Path length?
|
| I thougth my previous post (as well as other) have
Actually, I suspect that there is a useful, but badly articulated,
question underlying Russ' emails.
might be. hard to tell. having lived through the slanging match of
rpsec, i am not willing to spend a whole lot more time on one slanger
than the other.
randy
At 1:06 PM -0500 2/18/11, Russ White wrote:
...
Let me ask you something --does IPsec try to verify the path the packet
takes, or the contents of the packet? If the right solution for IPsec is
to validate the content of the packet, then why is the right solution
for BGP to verify the path of the
... the semantic of BGP has never been that the AS Path is used
for anything other than determining if the path is loop free.
That assertion seems to ignore the fact that routing decisions often
take into account path length. Are you saying that such decisions are
not part of the semantics
... the semantic of BGP has never been that the AS Path is used
for anything other than determining if the path is loop free.
That assertion seems to ignore the fact that routing decisions often
take into account path length. Are you saying that such decisions are
not part
Russ White r...@cisco.com wrote:
To: Christopher Morrow christopher.mor...@gmail.com
* Is an Autonomous System (AS) authorized to originate an IP prefix
* Is the AS-Path represented in the route the same as the path
through which the route update traveled
As we've been discussing on the
On 02/18/11 12:11, John Leslie wrote:
Russ White r...@cisco.com wrote:
To: Christopher Morrow christopher.mor...@gmail.com
* Is an Autonomous System (AS) authorized to originate an IP prefix
* Is the AS-Path represented in the route the same as the path
through which the route update
(my originaly wouldn't have made it to the list... so here it is again
from the right src-addr)
On Fri, Feb 18, 2011 at 12:20 PM, Chris Morrow morr...@ops-netman.net wrote:
On 02/18/11 12:11, John Leslie wrote:
Russ White r...@cisco.com wrote:
To: Christopher Morrow
On Fri, 18 Feb 2011, Russ White wrote:
* Is an Autonomous System (AS) authorized to originate an IP prefix
* Is the AS-Path represented in the route the same as the path
through which the route update traveled
As we've been discussing on the list --I don't think this is a
...@cisco.com
|Cc: sidr-cha...@ietf.org, Adrian Farrel adrian.far...@huawei.com,
|sidr@ietf.org
|Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work
|
|On Fri, Feb 18, 2011 at 11:35 AM, Russ White r...@cisco.com wrote:
|
| * Is an Autonomous System (AS) authorized to originate
In my view of things, this is exactly the right way to do things.
Anything else is baling wire holding some pieces together, not a solution.
The problem lies right here:
In BGP, the semantics of the protocol are that the AS_PATH represents
the AS's through with the update has traveled.
No,
On Fri, Feb 18, 2011 at 1:06 PM, Russ White r...@cisco.com wrote:
Let me ask you something --does IPsec try to verify the path the packet
takes, or the contents of the packet? If the right solution for IPsec is
to validate the content of the packet, then why is the right solution
for BGP to
because with ipsec the content inside the encrypted payload (or even
the content after the AH header) is not intended to be played with by
anyone along the path. Detection of bit flippage in the packet is the
point of ipsec.
BGP requires that folk along the path adjust metrics,
and because AS-Sets are opaque when it comes to security semantics
(which asn in the set is responsible for what part of the aggregate?)
they are excluded from the discussion, and on the road to deprecation.
The point wasn't to say, can each of these be solved, it was to say,
the AS Path
It's not. The AS Path is to prove the path is loop free. It was never
intended to prove where the update went in the network.
ok, so what other tool do we have today that does this? (can tell us
that an path is not fictitious)
There never was a tool intended to solve that problem --from a
Russ White r...@cisco.com wrote:
[Christopher Morrow christopher.mor...@gmail.com wrote:]
[Russ White wrote:]
I could go on giving examples, but to state, BGP's semantic is that the
AS Path represents the path through which the update has traveled, is
simply untrue.
eh... but it is. one
Howdy, as mentioned a few weeks back we need to re-charter the WG in
order to move on from simply validating origination of routing
information to possibly validating path information as well, here's a
strawman charter re-work, how about we discuss some on the list and
have some more chat about it
81 matches
Mail list logo
