John,
See below.
On Apr 2, 2013, at 8:26 AM, John Curran jcur...@arin.net wrote:
On Apr 2, 2013, at 9:53 AM, Danny McPherson da...@tcb.net wrote:
[--snip--]
Yeah, they were nonsensical in the past and present role of ARIN, not in an
RPKI-enabled world where revocation or transfer or
On Apr 2, 2013, at 9:58 AM, Danny McPherson da...@tcb.net wrote:
On 2013-04-02 09:30, John Curran wrote:
Indeed. Of course, that same outcome can effectively be had today (for any
given IP address block) via one handful of court orders directed to the
larger
ISP backbones.
Assuming
John,
On Apr 2, 2013, at 11:22 AM, John Curran jcur...@arin.net wrote:
On Apr 2, 2013, at 12:27 PM, Shane Amante sh...@castlepoint.net wrote:
IMO, there is still one key difference. ISP's are _directly_ involved in
receiving such orders, evaluating them for validity, applicability
On Apr 1, 2013, at 10:17 AM, Sharon Goldberg gol...@cs.bu.edu wrote:
[--snip--]
As above, the actions described in these sections are all easily detectable
by the targeted entity. So, the question is what that entity would/could do
if
it detects this sort of activity by its parent (or
On Mar 22, 2013, at 9:08 AM, Osterweil, Eric eosterw...@verisign.com wrote:
On Mar 22, 2013, at 9:57 AM, Randy Bush ra...@psg.com wrote:
past experience points to the hosted model eventually looking like
distinct repositories per customer, which looks like 'number of
repositories == number
On Mar 20, 2013, at 2:35 PM, Murphy, Sandra sandra.mur...@sparta.com wrote:
Speaking as regular ol' member
That all depends on the policy undertaken by each specific provider,
doesn't it? How can you tell the difference between a route with no ROA
because the registry has decertified, and a
On Mar 21, 2013, at 8:36 AM, Randy Bush ra...@psg.com wrote:
randy, who is not learning anything else new from this rinse repeat
So, you're stating that operator input wrt impacts the RPKI will have on their
networks is not useful to SIDR? OK, got it.
-shane
On Jan 23, 2013, at 7:41 AM, Russ White ru...@riw.us wrote:
Indeed. My point was not to draw RPKI into the solution space, or claim
something about its goals. I was just trying to illustrate that the wg has
already invested (heavily) in systems and designs that are not semantically
part
On Dec 20, 2012, at 8:39 AM, Sriram, Kotikalapudi
kotikalapudi.sri...@nist.gov wrote:
FWIW, I disagree with your assertions, but am cutting to the chase, because
I think you're still failing to understand why/when it's not possible to
spoof the Victim's AS.
Sorry, I tried my best to
Sriram,
On Dec 19, 2012, at 8:25 AM, Sriram, Kotikalapudi
kotikalapudi.sri...@nist.gov wrote:
Whichever prefix (or more specific of it) that the mitigator and the victim
decide to
propagate (via the mitigator) for DDoS mitigation today in BGP, the same
prefix can also
be propagated with
On Dec 19, 2012, at 2:12 PM, Sriram, Kotikalapudi
kotikalapudi.sri...@nist.gov wrote:
[--snip--]
FWIW, I disagree with your assertions, but am cutting to the chase, because I
think you're still failing to understand why/when it's not possible to spoof
the Victim's AS.
2) I'm sure you
On Dec 18, 2012, at 3:03 PM, Sriram, Kotikalapudi
kotikalapudi.sri...@nist.gov wrote:
Adding to Oliver's suggestion, it will be even more effective if, in the
origin only case,
the mitigator announces a slightly more specific (e.g., two /17s for a /16)
if the maxlength of the victim's
On Dec 18, 2012, at 12:48 PM, Randy Bush ra...@psg.com wrote:
I am trying to understand why our fellow engineers at Verisign are
obsessed with global propagation of RPKI data on the order of a few
minutes. Then a friend hit me with the clue by four. It's about third
party DDoS (and other
Sandy,
On Nov 8, 2012, at 6:25 AM, Murphy, Sandra sandra.mur...@sparta.com wrote:
Speaking as regular ol' member
On Wednesday, November 07, 2012 10:48 PM, Shane Amante
[sh...@castlepoint.net] said:
Commercial operators, in particular, should carefully evaluate the risks
posed
Chris,
On Nov 7, 2012, at 11:11 AM, Christopher Morrow morrowc.li...@gmail.com wrote:
there isn't data in bgp today data which tells you 'this path is a
leak'. Even at the immediately-leaked-to peer there isn't data in the
message that's helpful for this problem.
Why isn't the above
On Nov 7, 2012, at 1:48 PM, Christopher Morrow morrowc.li...@gmail.com wrote:
On Wed, Nov 7, 2012 at 1:39 PM, Shane Amante sh...@castlepoint.net wrote:
Chris,
On Nov 7, 2012, at 11:11 AM, Christopher Morrow morrowc.li...@gmail.com
wrote:
there isn't data in bgp today data which tells you
Michael,
On Nov 7, 2012, at 7:48 PM, Michael Sinatra mich...@burnttofu.net wrote:
On 11/07/2012 10:29, Danny McPherson wrote:
Sandy, Can you elaborate what your concerns about this agreement's
impact on the envisioned RPKI architecture and dominant use are? Do
you have a reference or
On Nov 7, 2012, at 9:34 PM, Christopher Morrow morrowc.li...@gmail.com wrote:
http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-threats-03#section-5
---snip---
o Route leaks are viewed as a routing security problem by many
operators, even though there is no IETF-codified definition of
Danny,
On Oct 23, 2012, at 3:25 PM, Danny McPherson da...@tcb.net wrote:
On Oct 23, 2012, at 5:05 PM, John G. Scudder wrote:
BGPSec protecting Origin would stomp on current operational practice, so it
would need to be justified more strongly than seemed like a good idea at
the time.
What
Sandy,
Adding IDR to response, since draft-ga-idr-as-migration-00 was submitted to
IDR. Trimming down to parts only relevant to draft-ga-idr-as-migration-00.
Please see below.
On Sep 27, 2012, at 7:40 AM, Murphy, Sandra sandra.mur...@sparta.com wrote:
Speaking as regular ol' member.
Some
On May 23, 2012, at 6:55 PM, Randy Bush wrote:
there have been no comments on list to confed and aliasing. may we
call them done?
Can you expound more what you mean by aliasing above? Do you mean
local-as, etc.
yep
That's strange. Why doesn't the following comment to the list back in
On May 23, 2012, at 7:08 PM, Randy Bush wrote:
Can you expound more what you mean by aliasing above? Do you mean
local-as, etc.
yep
That's strange. Why doesn't the following comment to the list back in
March of this year count as no comments on list to ... aliasing?
On Apr 6, 2012, at 8:26 AM, Andrew Chi wrote:
On 3/29/2012 9:04 AM, Shane Amante wrote:
Regardless, I think
that its best to acknowledge, in this draft, that there is a threat of
DoS to the availability of the BGP control plane
Maybe I'm missing something.
Intermediate routers or MITM
On Apr 6, 2012, at 10:20 AM, Andrew Chi wrote:
On 4/6/2012 11:21 AM, Shane Amante wrote:
a) BGP performs loop detection on the AS_PATH attribute *before* verifying
any BGPSEC_Path_Signature, in which case you drop the UPDATE, thus causing a
DoS because you're not propagating what *may
Steve,
Thanks for the response. First, a high-level comment before more specific
responses below.
The challenge I'm having is trying to reconcile threats against the existing
AS4_PATH attribute vs. threats against the BGP_Path_Signature attribute. More
specifically, the AS4_PATH attribute
To expand on my comments at the mic earlier today on this draft, I think there
is universal acknowledgment that there should be statements that attacks
involving path shortening should be acknowledged as a threat in this document.
OTOH, with respect to path-lengthening, my comment was NOT aimed
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
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 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
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
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,
Hi,
May I kindly request the SIDR WG update the aforementioned WG draft to state
whether ASN Migration scenarios, specifically those that manipulate the AS_PATH
attribute to support seamless migration from one globally unique ASN to a
second globally unique ASN, are included in the
Hi Chris,
On Nov 20, 2011, at 10:35 PM, Christopher Morrow wrote:
On Wed, Nov 16, 2011 at 11:23 PM, Danny McPherson da...@tcb.net wrote:
Team,
I've updated this draft based on some feedback received already. Given
the discussion at the WG session, and the list discussion as of late, I'd
Hi Randy,
Thanks for the response. I think we're getting closer. See below.
On Nov 14, 2011, at 2:45 PM, Randy Bush wrote:
1) From Section 3:
---snip---
A local valid cache containing all RPKI data may be gathered from the
global distributed database using the rsync protocol,
Hi Chris, Randy,
On Nov 14, 2011, at 12:03 PM, Christopher Morrow wrote:
Checking back on this... I see that Randy had rev'd the document since
this last conversation-set ... Danny has 2 editorial changes and 1
'large' comment... I don't yet see any feedback on those, but the
previous set of
Hi Chris,
On Nov 4, 2011, at 3:07 PM, Christopher Morrow wrote:
On Fri, Nov 4, 2011 at 3:05 PM, Eric Osterweil eosterw...@verisign.com
wrote:
This is a list of three questions. Until there is discussion of the first,
it is premature to address the second two. Therefore, how about we
On Nov 3, 2011, at 11:33 AM, George, Wes wrote:
From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of
Paul Hoffman
the charter limits the topics that are meant to be
fully covered by the protocols.
Personally, I would prefer to see the threat model document say in the
Hi Randy,
On Oct 30, 2011, at 4:57 AM, Randy Bush wrote:
[--snip--]
1) From Section 3:
---snip---
A local valid cache containing all RPKI data may be gathered from the
global distributed database using the rsync protocol, [RFC5781], and
a validation tool such as rcynic [rcynic].
I have some questions that pertain to this document, specifically around:
- whether it's intended or 'safe' to use BGP Attributes, (MED, communities), to
convey validity of prefixes from one ASN to another ASN
- better guidance/recommendations around the number, placement and
synchronization
Support.
-shane
On Oct 14, 2011, at 8:07 AM, Sandra Murphy wrote:
The draft draft-ietf-sidr-rpsl-sig has been expired for awhile. The editor
indicates that he is willing to continue progressing this work as long as the
wg is still interested. This work was first submitted as a wg draft
Wes,
Excellent points, which I agree with. One additional point below.
On Sep 7, 2011, at 12:57 PM, George, Wesley wrote:
-Original Message-
From: Randy Bush [mailto:ra...@psg.com]
Sent: Wednesday, September 07, 2011 9:37 AM
Subject: Re: [sidr] BGPSec scaling (was RE: beacons and
Hi,
I have a question for the WG. In a series of e-mail exchanges earlier this
year, I had thought it was concluded that BGPSEC was merely being used as a
means to express that a BGP UPDATE had passed through a series of ASN's, i.e.:
it's an expression of a breadcrumbs, if you will, that can
/
Information Technology Laboratory / NIST
From: sidr-boun...@ietf.org [sidr-boun...@ietf.org] On Behalf Of Shane Amante
[sh...@castlepoint.net]
Sent: Thursday, July 28, 2011 3:00 PM
To: sidr@ietf.org
Subject: [sidr] pCNT (AS_PATH) prepending
On Apr 3, 2011, at 18:17 MDT, George, Wes E [NTK] wrote:
While we have an operational considerations document that covers origin
validation, it focuses mainly on policy and implementation
details of the validation machinery. We don't have anything that covers the
back-end of implementing a
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
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
-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
Randy,
On Jan 30, 2011, at 20:40 MST, Randy Bush wrote:
3.3 As cryptographic payloads and loading on routers are likely to
seriously increase, a BGPsec design may require use of new hardware.
It must be possible to build routers that do BGPsec with within
acceptable (to operators) bounds of
Sandy,
Sandra Murphy wrote:
On Tue, 11 Mar 2008, Danny McPherson wrote:
On Mar 11, 2008, at 9:07 AM, Stephen Kent wrote:
The proposal for dealing with stale data (as reflected in the
manifest I-D) is to continue to use what you have. Thus the concerns
you cite about what happens if
49 matches
Mail list logo
