A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Secure Inter-Domain Routing Working Group of
the IETF.
Title : A Profile for Resource Certificate Repository
Structure
Author(s) : G. Huston, et al.
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Secure Inter-Domain Routing Working Group of
the IETF.
Title : CA Key Rollover in the RPKI
Author(s) : G. Huston, et al.
Filename: draf
> 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
__
Actually, I suspect that there is a useful, but badly articulated,
question underlying Russ' emails.
Yours,
Joel
On 2/21/2011 9:20 PM, Jason Schiller wrote:
ack.
understood.
Was concerned that other observers on SIDR might be buying his crap.
__Jason
===
>> |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
ack.
understood.
Was concerned that other observers on SIDR might be buying his crap.
__Jason
==
Jason Schiller (703)886.6648
Senior Internet Network Engineer
> |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
On Feb 21, 2011, at 1:15 PM, Christopher Morrow wrote:
> (not speaking for the authors, just observing some... also not
> speaking as a co-chair)
>
> On Mon, Feb 21, 2011 at 11:23 AM, t.petch wrote:
>> I find this I-D problematic. The subject matter is of crucial importance,
>> comparable to
Don,
On Feb 21, 2011, at 12:17 MST, Smith, Donald wrote:
> I think your last statement missed the concept of paid peering.
> That is TIER 1 ISPs frequently announce TIER2 routes but consider the TIER2
> "customer" as a "peer".
> Or am I missing something?
I purposefully glanced over paid peering
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
I think your last statement missed the concept of paid peering.
That is TIER 1 ISPs frequently announce TIER2 routes but consider the TIER2
"customer" as a "peer".
Or am I missing something?
> [2] For the more security-oriented folks in the room, at a very high-
> level, peer's only announce the
On Mon, Feb 21, 2011 at 2:15 PM, Christopher Morrow
wrote:
> (not speaking for the authors, just observing some... also not
> speaking as a co-chair)
>
> On Mon, Feb 21, 2011 at 11:23 AM, t.petch wrote:
>> I find this I-D problematic. The subject matter is of crucial importance,
>> comparable to
(not speaking for the authors, just observing some... also not
speaking as a co-chair)
On Mon, Feb 21, 2011 at 11:23 AM, t.petch wrote:
> I find this I-D problematic. The subject matter is of crucial importance,
> comparable to, or perhaps more important than, IPv6, yet this I-D is not
> an easy
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
The -01 version of the draft addresses the comments that were received during
the last call, most notably:
http://www.ietf.org/mail-archive/web/sidr/current/msg02168.html
http://www.ietf.org/mail-archive/web/sidr/current/msg02204.html
Would be great to have a round of review to verify the commen
I find this I-D problematic. The subject matter is of crucial importance,
comparable to, or perhaps more important than, IPv6, yet this I-D is not
an easy read and there should be one such somewhere.
sidr has produced an awesome collection of I-Ds (some now obsolete) but it is
not obvious, short
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
29 matches
Mail list logo
