> 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
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 was not trying
to change the requirements. Rather, I am asking that the document
include some context, to help the reader accur
the current, yet to be pushed, text is
3.1 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 represents the sequence of eBGP
exchanges that propagated the NLRI from
Original Message -
From: "Joel M. Halpern"
To: "Randy Bush"
Cc: "t.petch" ;
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 achieve.
> While it is true that we can not know why anyone
> 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.
bei
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 tha
mailto:sidr-boun...@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 B
> 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 fr
> 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
> so
- Original Message -
From: "Joel M. Halpern"
To: "Randy Bush"
Cc:
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
> >
> > A BGPsec design MUST a
sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of
> >> Andrew
> Lange
> >> Sent: Wednesday, February 23, 2011 6:17 PM
> >> To: Sandra Murphy
> >> Cc: sidr@ietf.org
> >> Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validat
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
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 into
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
> 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 w
Thanks Sandy. Yes, I mean "it", not "they".
Thanks for catching that.
Joel
On 3/1/2011 4:59 PM, Sandra Murphy wrote:
On Tue, 1 Mar 2011, Joel M. Halpern wrote:
Randy, would you be willing to be wording like this, with your
corrections, into section 1 of the document?
Thank you,
Joel
On 2/
On Tue, 1 Mar 2011, Joel M. Halpern wrote:
Randy, would you be willing to be wording like this, with your corrections,
into section 1 of the document?
Thank you,
Joel
On 2/26/2011 6:47 AM, Randy Bush wrote:
o To prevent any advertiser from sending an advertisement that would
cause other pr
Randy, would you be willing to be wording like this, with your
corrections, into section 1 of the document?
Thank you,
Joel
On 2/26/2011 6:47 AM, Randy Bush wrote:
o To prevent any advertiser from sending an advertisement that would
cause other properly behaving parties to send traffic iin a w
>>
>> 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
> 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 regiona
On Mon, Feb 28, 2011 at 11:28 PM, Andrew Lange
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 is always an issue.)
if y
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, s
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 onl
@ietf.org] On Behalf Of
>> Andrew Lange
>> Sent: 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
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 G.
> 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 not "entitled" to cause
close, but i am not entirely comfortable with this
o we can not hope to prevent the advertisement, only detect it is
> 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
Russ White wrote:
> To: John Scudder
>
>> * 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'
[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 thou
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 t
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
___
> * 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 m
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 exp
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 a
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
>> 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 fo
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 t
>> 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 sp
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
__
Andrew,
Comment below.
Sriram
> -Original Message-
> From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of
> Andrew Lange
> Sent: Wednesday, February 23, 2011 6:17 PM
> To: Sandra Murphy
> Cc: sidr@ietf.org
> Subject: Re: [sidr] SIDR ReCharter -
> 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
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
Hello,
On Wed, Feb 23, 2011 at 8:26 PM, Sandra Murphy 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 ever having
> actually
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 man
On Wed, Feb 23, 2011 at 9:01 PM, Geoff Huston 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 your re
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 9
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
>>> ob
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 that says "I'm AS_A, and I have AS_B and AS_Q as legitimate
>> connections."
>
> Geoff published a
> 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
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:
http://tools.ietf.
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 to
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, the
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
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
>
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
> 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. t
> What is the current "diameter" of the Internet? From my recollections
> it was converging toward about 4 ASes in diameter.
that was the mean, not the diameter. not counting prepends and other
kink, the effective diameter is considerably larger.
randy
__
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 auth
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 ot
> 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
__
f.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 been pretty clear on
|> this topic.
|
>> |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.
One thing I've learned
Feb 2011, Randy Bush wrote:
|Date: Tue, 22 Feb 2011 08:30:01 +0800
|From: Randy Bush
|To: Jason Schiller
|Cc: Russ White , sidr@ietf.org
|Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work
|
|> |So the only security problem anyone faces, currently, is people cheat
> |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
_
> 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
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
> In your example where AS_A buys transit from AS_B and AS_B buy transit /
> Peers with AS_X, AS)Y, and AS_Z...
>
> When AS_B announces AS_A's prefix to its upstreams, it is asserting two
> things:
>
> 1. AS_B learned the prefix from AS_A, choose it as best, and does not have
> policy to limit
> 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 cau
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.
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
routes on to
>> other peer's ...
>
> Sharing: Author's permission required.
> donald.sm...@qwest.com
>
>
>> -Original Message-
>> From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of
>> Shane Amante
>> Sent: Monday, February
Jason,
On Feb 21, 2011, at 12:01 MST, Jason Schiller wrote:
> On Mon, 21 Feb 2011, Shane Amante wrote:
> When AS_B announces AS_A's prefix to its upstreams, it is asserting two
> things:
>
> 1. AS_B learned the prefix from AS_A, choose it as best, and does not have
> policy to limit the distrib
dr-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 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
Jason, All,
On Feb 21, 2011, at 09:02 MST, Jason Schiller 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 to
On Mon, Feb 21, 2011 at 11:02 AM, Jason Schiller 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 topic. The Ka
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 A
> 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
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 bee
> 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 che
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
> > "... 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
> "... 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
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
At 11:35 AM -0500 2/18/11, Russ White wrote:
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="enigEEE752FC731D9F82CF768B1F"
* Is an Autonomous System (AS) authorized to originate an IP prefix
>* Is the AS-Path represented
Russ 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 good
> goal
Russ White wrote:
> [Christopher Morrow 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 more time around the mul
>> 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 --f
On Fri, Feb 18, 2011 at 3:14 PM, 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 more time around the mulberry bush?
>
> It's no
> 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
On Fri, Feb 18, 2011 at 2:21 PM, Russ White wrote:
>
>> what matters: AS-PATH
>> how it looks: every AS which sees this route, and propogates it to
>> external peers, attests to that fact.
>
> Wrong. As someone who has been long involved in the writing of BGP
> specs, and someone who has worked, f
> I think the short name of the 2nd bullet is simply "authenticity of the AS
> path
> attribute". Having authentic AS path information seems to provide everybody
> with a sound base to do whatever they want to do as their policies - and
> certainly also general use rules.
1. That's not what th
> what matters: AS-PATH
> how it looks: every AS which sees this route, and propogates it to
> external peers, attests to that fact.
Wrong. As someone who has been long involved in the writing of BGP
specs, and someone who has worked, for a long time, on BGP, I can tell
you that the "semantic of
On Fri, Feb 18, 2011 at 1:31 PM, Russ White wrote:
> If you're going to say, "secure the semantics," then secure all of them.
> If you're going to say, "secure the data," then figure out what matters
> in terms of how the data looks, and secure that.
what matters: AS-PATH
how it looks: every AS
> 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, commun
>> Suppose someone invented a way to prevent all of that without trying to
>> verify what path an update followed?
>
> As I said, one could try to list all the ways of making bad things
> happen by exploiting the vulnerability (munging the semantics), but it
> would be hopeless.
Suppose you list
On Fri, Feb 18, 2011 at 1:06 PM, 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 p
On Fri, 18 Feb 2011, Russ White wrote:
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
> 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.
rrow
|To: Russ White
|Cc: sidr-cha...@ietf.org, Adrian Farrel ,
| 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 wrote:
|>
|>> * Is an Autonomous System (AS) authorized to originate an IP pr
1 - 100 of 107 matches
Mail list logo
