I read this draft and tried to participate in shaping into something I as an
operator believe useful in SIDR WG, but to no avail -- IMO because the protocol
work, and then the requirements work, were largely completed already. I
believe this approach will cause more harm than good and result
On 2013-04-01 20:31, John Curran wrote:
Indeed, there will be some that see RPKI as a possible new approach
for such matters. The registry needs to be consistent (i.e. across
registration data, Whois publication, and RPKI publication) and we'll
certainly seek to prevent RPKI-specific actions
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 those backbones operate within jurisdictional or MLAT reach,
as
On 2013-04-02 08:26, John Curran wrote:
On Apr 2, 2013, at 9:53 AM, Danny McPherson da...@tcb.net wrote:
Speaking of inconsistencies in the RPKI, what's ARIN and the NRO's
status on getting to a single trust anchor?
I believe that ICANN and the RIR technical staffs are busy trying
On 2013-04-01 10:17, Sharon Goldberg wrote:
So, if we suppose that prefixes directly allocated by the RIRs are
given their own resource certs, we see that these resource certs can
whack ROAs for ASes in multiple countries. (Look at 8/8 or 12/8, for
example.) How would takedowns play out if
On 2013-04-01 14:37, John Curran wrote:
The present equivalent for the RIRs would be LEO's engaging in orders
to change the address holder associated with an IP block, and I am
happy to say that (at least in ARIN's case) that we have not seen any
such requests to date.
That's intuitive given
On 2013-03-21 23:50, Randy Bush wrote:
i could conject that ten years from now we will have one repository
run
by itu-i.
Assuming you meant ITU-T, that option isn't looking nearly as bad as it
did a few years ago, at least I'll know what it takes to get operational
requirements considered
On 2013-03-21 10:45, joel jaeggli wrote:
Might work for Joel, not me...
That's entirely possible. I was only filtering through my experience
as one customer.
Yep, I concur, hence my comment :-)
We have _lots of customers with varying requirements and capabilities,
not that that's in scope
true, but the repository conversation stops at: all gatherers in the
system have the data
inside each ASN it's really up to the ASN operator to get from
gatherer - cache - router in a 'timely fashion'.
If you're signing a route with something, and your upstreams are
signing their secure
On 2013-03-18 10:47, Stephen Kent wrote:
There are at least two issue here: how quickly a new/changed ROA is
published
after it is created/modified, and how quickly one should expect all
RPs to have acquired this info. The RPKI propagation model for ROAs
was
based on the observation that,
Interesting presentation here:
http://www.cs.bu.edu/~goldbe/papers/Cooper_RPKI_BFOC.pdf
The RPKI (Resource Public Key Infrastructure) is a new infrastructure
to secure Internet routing
It’s been in deployment since ~2011 But, it also creates new risks
(misconfigurations and takedowns)
that
Danny - Is there really a tight coupling if providers are
following the recommend BGP origin validation best practices?
I said BGPSEC...
-danny
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
Danny - Is there really a tight coupling if providers are
following the recommend BGP origin validation best practices?
I said BGPSEC...
However, my statement does apply to origin validation as well, in some
envisaged deployment models...
-danny
On Mar 20, 2013, at 9:44 AM, Stephen Kent k...@bbn.com
You cite DDoS mitigation as an example, whereas it seems to be more the
example.
Bah.. How many examples do you need?
Also, it's not clear
that asserting a new origin AS for a target of such an attack is the only way
to deal
On 2013-03-20 09:15, Richard Barnes wrote:
One other thing to note is that manipulation is indistinguishable
from legitimate revocation, at a technical level. So the only
solution here is at the human layer, for RPKI relying party software
to have operator overrides. Randy stated this better
On Mar 20, 2013, at 7:23 PM, Sriram, Kotikalapudi
kotikalapudi.sri...@nist.gov wrote:
The DDoS mitigation example was discussed before.
It appeared there was a reasonable solution.
Please see this post:
http://www.ietf.org/mail-archive/web/sidr/current/msg05605.html
Might work for Joel,
On 2013-03-12 07:07, Stephen Kent wrote:
As far as I'm concerned, we're going to follow IETF procedures.
That charter was intentionally worded when it was written so that the
solution envisaged would be the only thing worked on here, absent being
information by any actual threats or
On 2013-03-11 18:33, Matthew Lepinski wrote:
I am sorry.
I do not want to sign ORIGIN if doing so will create a new obstacle
to deploying BGPSEC
And I'm saying that the ability (i.e., option) to protect the ORIGIN as
set by the originating AS is IMO one reason that's a positive to deploy
On 2013-03-11 13:31, Stephen Kent wrote:
Danny,
We have been told by several operators that the values stated in
Section 4.3 of RFC 4271 are not what is used today. We also have been
told that, contrary to the SHOULD NOT in Section 5.1.1 of this RFC,
it is not uncommon for ASes to change this
On 2013-03-08 11:10, Murphy, Sandra wrote:
In reviewing the discussions about the threat document, the wg
eventual consensus wrt one topic was not clear to the chairs.
The ORIGIN attribute was mentioned by some as having the potential to
be used out-of-spec to influence routing through the
On Dec 18, 2012, at 2:48 PM, Randy Bush 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 attack)
Internet-Drafts
directories.
Title : IRR Routing Policy Configuration Considerations
Author(s) : Danny McPherson
Shane Amante
Eric Osterweil
Larry J. Blunk
Filename: draft
Internet-Drafts
directories.
Title : Route Leaks MITM Attacks Against BGPSEC
Author(s) : Danny McPherson
Shane Amante
Eric Osterweil
Filename: draft-grow-simple-leak-attack-bgpsec-no-help-00.txt
On Dec 18, 2012, at 5:03 PM, Sriram, Kotikalapudi 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 existing ROA permits it (of
On Dec 18, 2012, at 4:52 PM, Christopher Morrow wrote:
(to which I would argue the RIRs already has enough
resources to handle it, or some tricks can be perhaps applied to make
do they?
Heh, fine question Chris.. If they don't, they'd better get busy increasing
fees and putting business
On Dec 18, 2012, at 9:35 PM, Shane Amante wrote:
Sound fine in theory, but will not work in practice. *When* the original
announcement is a (IPv4) /24 and all providers filter on announcements /24
... you're, umm, up a creek without a paddle if you don't have an ability to
[immediately]
On Dec 7, 2012, at 2:38 PM, Murphy, Sandra wrote:From comments made at the mike in the last IETG sidr session after the discussion of key rollover techniques, I think there might be a bit of confusion about beaconing.An Expire Time was a feature of the bgpsec protocol in versions 00-01. The
On Dec 10, 2012, at 9:38 AM, Murphy, Sandra wrote:
I still contend that doing anything to introduce periodic updates in the
global inter-domain routing system
is a terrible idea and is something we should avoid altogether. Even
[ripv1-rfc1058] provides some
hints as to why this is a
On Dec 10, 2012, at 12:17 PM, Randy Bush wrote:
reports of current ISP behavior wrt TCP MD5 keys seems to be that they
currently decide never to change keys at all, ironically.
currently, you would have to synch simultaneous config changes at both
ends of the wire, not reasonable. and,
On Dec 10, 2012, at 3:22 PM, Murphy, Sandra wrote:
Keys on routers are not required for origin validation.
They are required for validation of the origin ASes Signature Segment in the
Signature_Block in the BGPSEC_Path attribute, no? I.e., such that the SKI can
be used by the recipients of
On Dec 8, 2012, at 9:25 AM, Sriram, Kotikalapudi wrote:
Periodic key rollover (PKR) is currently recommended in
[draft-ietf-sidr-bgpsec-rollover]
as evident from the following quote (from Section 4.2):
“For this reason, it is recommended that routers in this scenario been
On Dec 7, 2012, at 2:38 PM, Murphy, Sandra wrote:
From comments made at the mike in the last IETG sidr session after the
discussion of key rollover techniques, I think there might be a bit of
confusion about beaconing.
An Expire Time was a feature of the bgpsec protocol in versions
On Dec 1, 2012, at 10:17 AM, Montgomery, Douglas wrote:
It is kind of interesting to think about this requirement - the ability to
need to announce a prefix from a new, previously unseen origin, driven by
a previously non-existant business relationship, anywhere in the world
with a moments
On Dec 1, 2012, at 5:36 PM, Randy Bush wrote:
It is kind of interesting to think about this requirement - the
ability to need to announce a prefix from a new, previously unseen
origin, driven by a previously non-existant business relationship,
anywhere in the world with a moments notice ...
On Nov 30, 2012, at 1:37 PM, Montgomery, Douglas wrote:
The RPKI needs to react in seconds, rather than minutes, hours, or days.
Based upon what analysis or requirement?
Good question Doug.
Today I have a requirement as an operator to mitigate DDoS attacks in seconds
to single digit
On Nov 30, 2012, at 1:10 PM, Montgomery, Douglas wrote:
RPKI does not reflect run-time changes in topology. It is a declarative
system in which one would expect information to typically change with
human driven processes (e.g., allocation of addresses, establishment of
peering
On Nov 30, 2012, at 2:37 PM, Arturo Servin wrote:
If you only have one cache, and this fails, and you need to restore the
whole repository(ies): then yes. You have a problem.
But if you have two cache servers, perhaps you would not even notice
while the second one is getting
On Nov 30, 2012, at 2:52 PM, Montgomery, Douglas wrote:
I for one have long recognized that the current proposed system may have
limits on its reaction time. Certainly from my perspective, more suited
to pre-publishing preventative data, then creating reactionary data.
And the state of
On Nov 30, 2012, at 2:53 PM, Christopher Morrow wrote:
today there's no validation on the origin so if you pick your
upstreams 'right' you can get reach-ability from a large portion of
the network quickly. tomorrow in a 'only validated routes' world, you
have to wait for propagation of the
On Nov 30, 2012, at 4:08 PM, Christopher Morrow wrote:
On Fri, Nov 30, 2012 at 3:11 PM, Danny McPherson da...@tcb.net wrote:
limits on its reaction time. Certainly from my perspective, more suited
to pre-publishing preventative data, then creating reactionary data.
And the state
On Nov 20, 2012, at 3:18 AM, Russ Housley wrote:
At the meeting in Atlanta, we heard some very impressive performance numbers
for the restructured RIPE repository with rsync. While your code is not
feature complete, do you have any expectations of similar performance?
Russ,
Can you
On Nov 9, 2012, at 9:16 PM, Russ White wrote:
2. Providers have said (on this list and otherwise) that they are not
willing to release _any_ policy in _any_ way, _ever_ into the hands of
_anyone_ (even, this peer is not a transit AS).
Actually, some subset of providers allegedly said this.
On Nov 8, 2012, at 6:25 AM, Murphy, Sandra wrote:
I doubt whether any of them have felt the need to carefully evaluate the
risks or consult their legal departments.
And therein lies the disconnect!
I think it'd be extremely naive to think that operators don't know, or care
about, or
On Nov 8, 2012, at 8:21 AM, Murphy, Sandra wrote:
A topic that generates a fire storm of discussion has a good chance. Nothing
like actively working on a topic to demonstrate interest in working on the
topic.
I do NOT support adoption of this. It creates the opportunity for collisions
On Nov 8, 2012, at 8:17 AM, Murphy, Sandra wrote:
Shane's message said that reliance on outside parties was a risk. I was
pointing out that operators already are relying on outside parties. Whatever
means they employ now to evaluate risk or legal impact, they are comfortable
with
:
Begin forwarded message:
From: Danny McPherson da...@tcb.net
Subject: Re: [sidr] additions and changes to agenda on Friday
Date: November 8, 2012 7:40:11 AM EST
To: sidr wg list sidr@ietf.org, Sandra Murphy sandra.mur...@sparta.com
On Nov 8, 2012, at 6:25 AM, Murphy, Sandra wrote:
I doubt
On Nov 8, 2012, at 10:55 AM, Murphy, Sandra wrote:
Sorry, you did not say all you said most
Sandy, could you please not take this out of context? I quoted it below, but
one more time:
I said _many [most] operators DO carefully evaluate the risks and consult
their legal departments.
Do you
On Nov 8, 2012, at 11:14 AM, Murphy, Sandra wrote:
Sorry, I thought your complaint that I was misquoting was that I had said
all when you said most.
So your complaint that I am misquoting is... what did I get wrong?
This:
=
On Nov 8, 2012, at 9:37 AM, Murphy,
On Nov 8, 2012, at 3:02 PM, Murphy, Sandra wrote:
And finally, there is an overlap between the last hour of sidr and grow. One
of the sidr co-chairs is a grow co-chair (yes, grow was on the sidr
do-not-conflict list). There are bgp operationally oriented folk in sidr who
will likely
On Nov 7, 2012, at 10:13 AM, Christopher Morrow wrote:
On Wed, Nov 7, 2012 at 9:11 AM, Dan York dan-i...@danyork.org wrote:
Agreed, sadly... but the good news is that this whole thing did get more
people thinking about the underlying router infrastructure. So if it gets
some people to wake
On Nov 7, 2012, at 11:11 AM, Christopher Morrow wrote:
resource certification, in the form of RPKI, would at least remove a
barrier people put up about using IRR data to make prefix-filters...
so ideally we get some win with just RPKI.
I agree we need resource certification, but if I now
On Nov 6, 2012, at 12:35 PM, Murphy, Sandra wrote:
I would like to open a discussion with the wg concerning the recently
announced ARIN relying party agreement. I have concerns about this
agreement's impact on the envisioned RPKI architecture and dominant use. I
think the wg needs to
On Nov 7, 2012, at 1:37 PM, Christopher Morrow wrote:
where to send comments/questions?
Fine question, apparently out of the scope of _S_I_D_R. Perhaps GROW, we
should ask the chairs :-)
-danny
___
sidr mailing list
sidr@ietf.org
On Nov 7, 2012, at 1:42 PM, Christopher Morrow wrote:
The draft you reference up-thread isn't actually helpful, it doesn't
show how to know that the leak is a leak and not another backup path
coming to light for other reasons in the system.
The fact that even folks here were confused where
On Nov 7, 2012, at 1:49 PM, Christopher Morrow wrote:
frankly I'm happy to add comments on the sidr list, or grow list or
you directly... my question perhaps was mis-phrased, I'll try again:
Where would you like me (or others) to send comments on this draft?
The authors welcome direct
On Nov 7, 2012, at 1:48 PM, Christopher Morrow wrote:
1) show/agree that this is a problem (route leaks)
Do you believe this is a problem? When describing events such as this as of
late, what did you call it?
2) see if bgp data already has the right bits to fix this (idr)
3) slap some
On Nov 7, 2012, at 2:28 PM, Murphy, Sandra wrote:
I think that could impact the envisioned architecture and dominant use cases,
Agreed!
A couple of people have suggested mechanisms that might suit ARIN and
minimize the impact and might be worth exploring.
Can you (or those folks) share
On Nov 7, 2012, at 3:56 PM, Christopher Morrow wrote:
I'm not presupposing, I'm saying that today you CAN do what you want
with IRR data, some folks do this with varying degrees of
success/failure. you could improve this with RPKI (or resource
certification)... you'd still be limited to
On Nov 7, 2012, at 5:43 PM, Randy Bush wrote:
How about this: We need a way to show how to know that the leak is a
leak and not another backup path coming to light for other reasons in
the system (that might sound familiar :-).
yes it does.
Eh?
what i see instead is a bunch of noise
On Nov 7, 2012, at 5:57 PM, Randy Bush wrote:
we agree route leaks are a problem.
Excellent, progress
please do not send me any more email without a proposed solution.
I'll note that this email was NOT to you, Randy, it was to the sidr@ietf.org
mailing list. You are NOT the WG, as
On Nov 7, 2012, at 7:48 PM, Michael Sinatra wrote:
In addition to Sandy's concerns, the agreement contains a third-party
indemnification clause (as do other ARIN RPKI-related agreements) that makes
it difficult for many state and federal government (and large EDUs) to simply
click
On Oct 23, 2012, at 6:03 PM, Shane Amante wrote:
I suspect John is referring to the operational practice employed by some
networks, right now, whereby they overwrite ORIGIN during receipt of an
UPDATE into their network to 'normalize' ORIGIN to a consistent value.
Ironically, if
On Oct 24, 2012, at 12:58 PM, heasley wrote:
its used as a TE knob, whether danny likes it or not.
I didn't say I disliked it. I said that I disliked intermediate ASNs
manipulating the values an originating AS configured, because it has system
wide implications and could impact things
On Oct 23, 2012, at 11:14 AM, Randy Bush wrote:
but it is in the bgp decision process. it is prettly low down, but
could be used for traffic engineering or other, less nice, influencing
of the decision process.
s/could be/is/
hence, bgpsec should probably should protect it.
Agreed.
On Oct 23, 2012, at 5:04 PM, Murphy, Sandra wrote:
Reviewing that was what led to my question to Randy. (something like what
is the reason for having ORIGIN in the first place.)
Nice :-)
The responses when this came up in the past have been that protecting
integrity of ORIGIN might
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 does this mean? What operational practice?
-danny
On Oct 23, 2012, at 4:44 PM, Warren Kumari wrote:
Not sure I agree with this part -- simply because it can be used in the
decision process doesn't automatically mean it needs to be protected. It (and
med and IGP cost and routerID) feel to me like they are low enough down
that they can be
On Oct 9, 2012, at 11:36 PM, Matthew Lepinski wrote:
I would like to confirm on the list that the discussions at the last interim
reflect the consensus of the working group.
In this message, I list for each open issue, my understanding of the sense of
the room in Amsterdam. If you
On Sep 21, 2012, at 7:27 PM, Murphy, Sandra wrote:
er. The three documents have been in the working group for the same length
of time, so you'd think that they, being so tied, would have had equal
attention and be equally mature.
Sandy - The very fact that The three documents have been in
On Aug 28, 2012, at 5:33 AM, Stephen Kent wrote:
Gee, I didn’t mean to sound like an Obama supporter. s/hope/goal/
Hahh, that's pretty funny :-)
Thanks for the thoughtful reply Steve, I'll get back to you in short order on
these responses - but if an updated I-D appears in the interim I'll
Admittedly, I'm not certain what triggered this, but clearly, your email to me
suggests that others have expressed concern of consistency and collisions, a
concern expressed by the IAB as well. As such, I have a question below.
On Aug 10, 2012, at 4:45 PM, Murphy, Sandra wrote:
speaking as
Some comments on this document inline below..
I am surprised that external systems (e.g., NTP) are not mentioned at all in
this document?
Also, this document makes no distinction between eBGP and iBGP speakers, yet
there are certainly places where text and context would suggest it is
On Apr 11, 2012, at 1:35 PM, Christopher Morrow wrote:
From there, we can discuss the issue of, for example, HOW TO onboard and
purge signing and validating certificates to routers from the RPKI -- [I
suspect the intention was to use rpki-rtr protocol for this, but it doesn't
currently
I suppose, to me this looks like any other configuration thing you do
today on routers... beating the vendor over the head to support sane
(netconf? maybe?) methods for provisioning, is already done.
So how we onboard, update, or purge information from RPKI and sign stuff on n
routers in z
On Apr 10, 2012, at 8:56 PM, Christopher Morrow wrote:
yes, my goal was to have updated the wiki today at the office, work
intruded... tomorrow I'll do that with some more content for each
item, and hopefully better coordinates as well for the location.
Thanks.
Also, are we collecting
On Mar 31, 2012, at 12:12 AM, Murphy, Sandra wrote:
Origin validation is strictly and only judging whether the origin has the
authority to originate announcements of the prefix. Origin validation does
not ensure that the authorized AS is actually making the announcement.
Indeed! It's
o but we do not know the long term scaling characteristics of the
current rsync scheme.
While we may not know the scaling characteristics of the solution, do we
at least know what would be a desirable objective target for sustainable
deployment?
o we could get much better rsync
On Mar 28, 2012, at 4:19 AM, Jeffrey Haas wrote:
Per my mic comment at IETF 83:
During the San Diego interim session we had discussed potentially signaling
in BGP the idea that a given AS may have fresher data available in its
repository.
Shouldn't this problem be solved in the resource
Chairs et al.,
Apologies if I've missed the, otherwise, when are these expected to be
available?
Thanks,
-danny
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
If the plan is indeed to employ connection-oriented TCP transport for rpki-rtr
signaling in order to establish prospectively volatile soft-state in router
control planes directly from RPKI-derived blobs -- i.e., beyond {prefix,origin}
bindings to include {ASN, public_key, SKI} for each EE
I've reviewed the -04 version of the draft and have the following
comments (most of which persist from the previous version of the
draft, although many were accommodated - thanks).
-danny
===
Substantial:
---
S 4.4 ( S 4.6):
I remain concerned
On Nov 30, 2011, at 10:38 AM, Andrew Chi wrote:
The specs leave room for the relying party to decide what to do with
imperfect but not completely invalid objects.
Thanks for sharing Andrew. One question and one comment...
Is an expired object completely invalid or just imperfect? Can you
On Nov 29, 2011, at 10:36 AM, Christopher Morrow wrote:
I think this last bit gets at danny's concern (after the 'but every
asn in the path has to agree that the root is wrong' bit)... lots more
complexity here is not helpful :(
Yes.
-danny
___
On Nov 22, 2011, at 1:09 AM, Christopher Morrow wrote:
Probably they are the closest it gets, but a line from the ENISA paper
sticks with me:
Unfortunately, the quality of the IRRs varies, which makes it difficult to
rely on them
Terry: I think this is in large part attributed to lack
On Nov 15, 2011, at 6:39 PM, Pradosh Mohapatra wrote:
Can you describe specific concerns you have with using extended community?
It does work with confederations.
Confederation in this context was referring to the _current inability
of BGPSEC to natively accommodate AS confederations, or
Just a trivial nit:
s/RFC2385/RFC5926/
Was re-reviewing RPKI/RTR Cache Protocol and saw this error, might want to fix:
It is expected that, when TCP-AO [RFC2385]is available on all
platforms deployed by operators, it will become the mandatory to
implement transport.
-danny
Oops, yea, just noticed that -- thanks for [re]clarifying :-)
-danny
On Nov 16, 2011, at 1:23 AM, Joe Touch wrote:
RFC5925 is TCP-AO
5926 is the algorithms used by AO, not the AO mods to TCP
___
sidr mailing list
sidr@ietf.org
Rob/Steve, et al.,
Relative to the SIDR Origin Ops draft and local trust anchor (LTA)
configuration, I'm trying to understand how one would actualize
trust anchor locators (TALs) and LTAs in a deployment scenario and
was hoping you could help me here.
I think it's probably safe to assume
On Nov 14, 2011, at 8:37 AM, Rob Austein wrote:
Ultimately, the problem is the same as distributing DNSSEC TAs, or any
other TA for that matter. Pretty much by definition, these things
have to be configured outside the automated system, because they're
the bootstrap data. Inclusion in
On Nov 14, 2011, at 6:47 PM, Rob Austein wrote:
Danny,
For purposes of this discussion, a LTA is semantically equivalent to a
collection of TAs plus a constraint list. Since LTAs are also a more
general mechanism (they can be shared by a group of like-minded folks
more easily than a
In general, I don't like the idea of using an extcomm community to convey
a prefixes validation state, I think we should deal with this problem natively
(e.g., as BGPSEC inter-domain) if we're going to address the problem, in
particular if we're not going to address the AS Confederations
On Nov 14, 2011, at 10:07 PM, Christopher Morrow wrote:
On top of that if the resource is then re-certified (to the same or
different end entity) how do the intermediate parties know which is
the 'right' thing to do?
Agreed.. It's critical to highlight that LTA doesn't fix anything here
On Nov 13, 2011, at 2:36 AM, Pradosh Mohapatra wrote:
Is there a need to compute validation state of an IBGP path?
I need some way to convey in iBGP it's preference relative to other
BGP-learned paths - how do I do that today under this architecture,
where if it were considered under the
On Nov 13, 2011, at 3:17 AM, John Scudder wrote:
IMO the way to handle this is observe that all routes have a validity state
attribute and that it needs to be settable in policy. I believe the draft
already says this (I will check though) and so it provides the necessary
minimum toolset
On Nov 13, 2011, at 11:30 PM, Randy Bush wrote:
NotFound is a keyword.
I assume it was derived from the normative pfx-validate draft and was
simply hoping for consistent use:
danny@pork% grep -i found draft-ietf-sidr-pfx-validate-03.txt
peer will be found to have one of the following
On Nov 13, 2011, at 11:03 PM, Christopher Morrow wrote:
I suspect some feedback to Danny will come soonish, but can we close
out the other set of requests?
Chris,
I'm not sure I understand the request, can you clarify?
I.e., until I've had adequate time to review updated I-Ds with changes
On Nov 11, 2011, at 12:07 PM, Sriram, Kotikalapudi wrote:
So yes, I did consider the _prefix _ updates as is the case in BGPSEC (not
updates with packing in it).
Sriram,
Yes, I saw this, and it is a useful datapoint.
I was looking for something more quantitative and closer to core
ISPs
On Nov 11, 2011, at 10:40 PM, Randy Bush wrote:
draft-ietf-sidr-bgpsec-ops-02
To prevent exposure of the internals of BGP Confederations [RFC5065],
a BGPsec speaker which is a Member-AS of a Confederation MUST NOT not
sign updates sent to another Member-AS of the same Confederation.
My read of the current draft suggests that if there's a route generated by the
local AS in BGP it could never have a Valid state, and by definition would
either posses a Not found or Invalid state -- even though the local
AS may well have a ROA and reside in the mapping table as well(!).
I do
On Nov 9, 2011, at 1:42 PM, Stephen Kent wrote:
The main reasons have to do with fundamental aspects which at a high
level have been addressed by my colleagues,
so, this is a Verisign critique, provided by you, Eric, and Danny?
Steve,
Not that I need to justify or explain this to you or
1 - 100 of 157 matches
Mail list logo
