[ since my last message on this subject was not approved for posting to
this list, i am inflicting myself directly on you. apologies. ]
i am told that multiply signed roas are reappearing like whack-a-mole.
they are as operationally useful as gears on a fish, and serve only to
make it harder
As I understand the substance of this post, the comment has been
raised (again) that this is an unlikely situation and there is no
need to make the specification more complex for unlikely cases.
In response I would argue (again) that the specification should be
complete and provide
it is not necessary. it is not operationally useful. it adds
complexity to a security application.
is there a netowrk operator here who really needs it?
and we have already heard from the major open source full system
implementor, who does not plan to add it.
randy
In response I would argue (again) that the specification should be
complete and provide appropriate guidance to implementors for all
situations where interoperability is required,
boiling the ocean.
and this case, although not common, has been visible in the routing
table already
oh?
A source of a relatively complete set of individual allocations can be
retrieved from http://bgp.potaroo.net/stats/nro/delegated
then take a large set of updates and examine each prefix - the Route
views update archive is a good source
and then perform a lookup into the individual
the data are broken in the first place. there are duplicate entries!
% grep ipv4 delegated | awk 'BEGIN {FS=|;} {print $4}' | sort | uniq
-c | grep -v ' 1 '
2 132.11.0.0
2 132.17.0.0
2 156.112.0.0
2 156.113.0.0
2 192.52.232.0
2 192.94.234.0
2 193.194.128.0
2
That being said, this draft does not appear to be revised with feedback from
the last IETF. Without clarification and modification, the algorithm
specified in this draft would have serious performance issues with HTTPS.
So, when are we expecting a draft revision that addresses this issue and
Andy Newton wrote:
I also see the benefits of heterogeneity.
Well, unless one method clearly has a trade-off the other method does
not, I see no reason for having two. Do you see any?
i am still completely stunned and confused by this. i have been unable
to understand hetrogeneity as other
The authors of these two drafts now believe that all SIDR WG comments
have been integrated into these documents
only withdrawal of the bogons draft would address my comments
randy
___
sidr mailing list
sidr@ietf.org
My understanding of the discussion at the meeting was that the proposed
prohibition would cover all three cases that you list below.
yep. i would just say prohibit please except ...
ruediger was the only user/rp to express concerns. so i would like to
have a chance to discuss further with
- there should no standard for the interpretation of ROAs and its up to
each relying party to figure out what they want to do
...
and a lot of other argument by extreme
perhaps you could look at draft-pmohapat-sidr-pfx-validate-00.txt. i do
not buy it entirely, and have sent edits to the
George Michaelson wrote:
On 26/11/2008, at 2:43 PM, Randy Bush wrote:
1, 2, and 4 are uninteresting to me, not worth the additional complexity.
3. I have been allocated 203.10.60.0/22. I wish to ensure that any more
specific advertisement of this prefix is unauthorized. If I generate
Knowing that ROA's can only be issued based on the AS and IP resources
allocated by the parent.
whoops! no. the asn in the roa is not signed or otherwise authorized.
if the prefix owner chooses to issue a road for P to A, that does not
mean A must announce it or A agrees.
randy
ie, if you dislike these words, please instead of just knocking down,
can you help construct?
see wrestling with pigs. and this is my last go on this for today.
noting netmask, maxlen, which clearly removed the 'rigorous' -what else
is wrong with the text?
it does not even say that if
ATT understand the RPKI and uses certs and ROAs, but their multihomed
customer in Bolivia, to whom they have sub-allocated some of their
space, does not. Just exactly what can ATT do (what gets signed by
whom and what gets checked by whom) that will prevent a more-specific
prefix
[EMAIL PROTECTED] wrote:
if indeed there is agreement on one and only one RPKI, then
one of the primary advantages of using the IP protocols will
be lost.
there is -zero- requirement for full, continious interconnectivity
in the base IP protocol. creation of a mandate for a single, one
and
I don't understand *why* the resource would move from region B to
region A in the given example?
the buyer and seller prefer doing business in their 'home' regions.
figuring out one rir's bureacrazy is hard enough, and does not
contribute to the bottom line.
randy
EngulfAndDevour acquires MomAndPopISP.
EngulfAndDevour advises both RIRs of the purchase
EngulfAndDevour advises that at 0100hrs UTC on a future date all
resources (ROAs et al) are transferred to RIR 1.
RIR 1 advises RIR 2 to reissue all of MomAndPopISP resources (ROAs et
al) with a
Right, not a last minute activity.. cert issue events need to happen
in advance for propagation.
which we have been caling make before break. but we have assumed a
lot of user control so the blame is on them when their routing breaks as
opposed to automating and finding we need to apologize
To something like, maybe, mandatory to implement? I'm guessing.
that addresses the reader. but how does this help when the writer
uses an 'optional' one?
randy
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
Parallel certs.
gag me with a spoon
AFAIK, that's pretty typical if you're aiming for real agility. Do
you know of another way?
nope, though i am not well versed in this end of the swamp. but there
is a non-trivial difference between having two equivalent blobs and two
equivalent/parallel
Wondering if anyone has given thought to how exchange
point prefixes will be handled in the RPKI model?
i must be missing something.
the exchange operator issues a roa for all asns they wish to allow to
announce the prefix.
randy
___
sidr mailing
- the resulting requirement is that every LIR's customers MUST
participate in RPKI else the issuance of the LIR's ROA will
invalidate all customer announcements in the examples provided by
Geoff.
The customers do not have to participate in the RPKI. The LIR can
issue the ROA on their behalf,
No, the LIR just has to issue ROAs for any of its customers that are
Not just has to, MUST issue.
big deal. and we must connect wires to them. the list of musts to
provision a customer is rather large. this one will go with the ones
having to do with accepting their bgp announcement in the
Does the LIR (ISP) need to know if any of his (RPKI_incapable)
customers are multi-homed and, if so, to whom they are connected, in
order to generate ROAs for those paths?
no. roas do not have paths.
randy
___
sidr mailing list
sidr@ietf.org
Can you say how it will work during initical deployment in an ISP
who has many customers? Go through the list of all customers, asking
this question? Go through the list of all mulit-homed customers,
asking this question? Do you have a record of those who are multi-homed
or would you
I think this might help clarify what Steve's concern is, which I think
several others here also share. Consider the subnet 198.32.176.0/24
and take a look at their connectivity graph:
http://www.robtex.com/route/198.32.176.0-24.html From this graph,
four different ASes seem to originate this
if folks think this is poorly managed ... they are entitled to their
opinions. If you would like Randy to step in here, i'd be pleased to
hear the offer.
i do not take on tasks i do not have the time to do well.
ep.net reverse delegations have been problematic for years for
The audo recordings of the meeting provide a good record of what was
said, so it might make sense for the minutes to attempt to provide a
summary of discussion and note actions and outcomes.
i object
traditional minutes are worthwhile, and roque's work was good. folk who
want to listen
geoff,
since you bring up the subject, which is conflict of interest, not
specifically chair affiliation, excuse me for being my normal tactful
self :).
in the ivtf, many folk do work that concerns their employer, someone has
to pay the costs [0]. it is not whether the emoloyer gets their
Free cert with your address would be nice. A reasonable price would
be acceptable.
expiration and revocation are serious issues and, as the rirs' claws
continue to uncloak, a very serious worry.
randy
___
sidr mailing list
sidr@ietf.org
You've been making cryptic comments like this, about RIR misfeasance/
malfeasance, for over two years now (or at least that's when I first
noticed them).
excuse. please show where i have alledged malfeasance. otherwise, do
not put words in my keyboard.
randy
draft-ietf-sidr-roa-validation-03.txt
i object to last call on this. there is a conflicting draft, and one
not by a wg co-chair.
randy
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
Sandy, with your WG chair hat on, could you please issue a WG Last
Call on the following document:
draft-ietf-sidr-rescerts-provisioning-05.txt
still reading, but ...
naming of actors in this document still assumes that ISPs are the
children. children might be RIRs (parent IANA), or end
i object to last call on this. there is a conflicting draft, and one
not by a wg co-chair.
The conflicting draft has an outstanding IPR claim, which has not been
discussed or addressed by the authors (which includes yourself Randy)
this is just part of normal life in the ietf. you might
naming of actors in this document still assumes that ISPs are the
children. children might be RIRs (parent IANA), or end sites (parent
ISPs or owning non-end user sites (e.g. business subsidiaries or govt
structures)).
again, i suggest something like 'parent' and 'child', though i am not
the particular wg co-chair is a co-author on both drafts.
Wrong. go re-read the authors section of 03. The same edit which added
you as an author removed Geoff.
whoops! well, at least i did contribute to it.
Shame on you Randy, for hijacking WG process for a personal agenda.
even if
folk going down this rathole might consider two things
rpki-rtr suggests that the number of global fetchers will be radically
lest than the number of global asns
there might be ca chain depth of 3-6 for which a 24 hour cycle would
mean a three day delay, making operators remember curtis
naming of actors in this document still assumes that ISPs are the
children. children might be RIRs (parent IANA), or end sites (parent
ISPs or owning non-end user sites (e.g. business subsidiaries or govt
structures)).
I believe section 1.1 entirely addresses this point. The definition
sorry. late here.
as ggm said, probably better than i can, a week or two after philly.
if we have a parent-child chain of length L and each runs as a batch at
some time interval T, then the mean time to propagate is (T/2)*(N-1)
s/N/L/
randy
___
That is only true if the thing you're propagating has to travel hop by
hop to the bottom of the hierarchy. So the question still stands: what
is this thing that you think propagates slowly, and why does it have
to propagate hop by hop?
incorrect or missing cert high in chain which needs
Would a global replace of ISP with subject and IR with issuer
be a sufficient resolution of this discussion?
makes sense to me, especially in the two level case. when you get to
three or more, you may want grandchild/grandparent etc.
the key point is that it is turtles all the way down.
Perhaps Names for IANA and RIRs will be meaningless directory
distinguished .
We can add some more text to make such this is unambiguous.
we are consciously not proscribing 'meaningful' names for other IRs?
randy
___
sidr mailing list
In general, these changes are fine, and address the naming parent/
child/IANA/RIR/ISP name game issue.
yep, all good
One issue which is raised is that a RPKI service provider now may
be made subject (with one month's notice) to changes to the CP made by
the IETF. As the CP specifies
i am confused. i do not understand the relationship of a parent going
out of business (irrespective of reason) with the time for an rpki
instance to meet a new cp.
seems to me thatm if my parent goes out of business, the scramble is to
build the peerings with the parent(s) to which my
You can't invest in the deployment of some types of requirements
(liability, costs) until the need is certain, i.e. post approval.
so we have noticed :(
Can you explain the concerns with having a longer time period in the
document?
as we deploy, if we find a serious ops problem that means
You've got the time left over, after the RPKI service provider exits
the field, to scramble with the grandparent to select new service
providers...
if someone mid-chain turns off, certs/roas below will no longer
validate. so swinging from the grandparent must be make before break.
following
george,
if you think that the two drafts cover much the same technology, and you
accept the sad reality that sometimes technologies in the ietf suffer
ipr attacks, can you explain why are you angry that the same ipr attack
is directed at the two drafts you think are similar?
randy
I agree that the manifest structure is more general than the RPKI
context.
is that a problem for this wg? i.e. should this, rather narrowly
focused wg, be doing this work. we could miss a lot and step on others'
toes.
randy
___
sidr mailing list
I agree that the manifest structure is more general than the RPKI
context.
is that a problem for this wg? i.e. should this, rather narrowly
focused wg, be doing this work. we could miss a lot and step on
others' toes.
In principle I agree, but since the toes in question would be in PKIX,
Comment(by g...@…):
The combination of TLS and CMS was the result of advice the design
group got from Steve Bellovin, Steve Kent, and Russ Housley when Randy
and I asked them to review this protocol, back in 2007. The two
mechanisms serve different purposes.
and mis-attributed copies
and mis-attributed copies of email we have already read helps the
technical work how?
I'm sorry if this caused any confusion to WG members. I copied a
message in to the issues tracker to ensure that it was captured in the
tracker, and the notification of the action is sent to the WG
mailer.
before i put this tracker thing in my .procmailrc, where's the win? the
mailing list archive is broken?
The issue tracker was set up in response to requests on the WG mailer:
now that we have assigned the blame (and my memory is not that sandy was
the one who pushed it), can we answer my
I note that it does say the ISP assumes the role of the client, and the ISP
is the subject of a resource certificate.
what is the client is not an isp, e.g. an RIR, NIR, end site, ...?
randy
___
sidr mailing list
sidr@ietf.org
This provides the scheme for the rsync URIs in the RPKI certificates.
thank you, sam, and dave.
randy
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
Suspect folks here might be interested in this..
Subject: IAB statement on the RPKI.
deep thanks to you and the many others who moved this forward
randy
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
I suggest to the working group that we could proceed with the current
draft as the abstract model for route validation, and leave open the
potential for other drafts that bring proposals for implementation
specifics for route validation. (And that we should begin working on
such
max-len is at the choice of the issuer of the roa. it is a macro so
they do not have to issue all the smaller roas. if they don't want the
longer prefixes announced, then they should not issue the roas, whether
as individual roas or in the equivalent max-len macro.
and the pakistan telkom
The lesson was about the danger of more specifics.
Would the attack had been as successful if had
announced a matching /22 instead of a /24? Imagine
a ROA future where Pakistan Telkom replays the attack
and inserts the correct origin in the path to match the
Youtube ROA. The attack
we would like to sumbit draft-ymbk-rpki-rtr-protocol-05.txt as a sidr wg
draft on standards track. it needs to be standards track as it is a
normative reference from draft-pmohapat-sidr-pfx-validate-04.txt.
randy
___
sidr mailing list
sidr@ietf.org
Given that it's a corner case, you could also cut right to the chase
and just call it undetermined if the path starts (or ends, in your
parlance) with an AS_SET, period.
if the originating asn is a set, the prefix is 'matched' by a roa, yet
there is no aggregator, i might consider it invalid.
Today:
o 61 prefixes with AS_SETS
o 50 only include a single AS in the set
o only 48 different sets appear
o 1 includes only 4 occurrences of the same AS
o 1 includes 4 occurrences of the same AS and an IANA DSU AS
o 5 of those have an origin code of incomplete
In 2005:
o 45
as i said last week, though a bit more tersely :)
would folk please look at rfc 4271 section 5.1.7. this specifies the
optional attribute AGGREGATOR, which should be the as number of the
aggregating as. you will see that this is the asn used to validate
against the roa in
i like good, bad, and ugly
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
Subject: I-D Action:draft-weiler-sidr-trust-anchor-format-00.txt
i support this becoming a sidr wg document
i also like the format
randy
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
hmmm - I'm not sure that there was any clarity of resolution so far in
terms of the traffic on the mailing list.
hmmm. then maybe we should discuss it in maastricht, which, i believe
was the original subject.
randy
___
sidr mailing list
want knob to just not bother with aggs. they are a teensie weensie bit
of the routes, often bizarre (have only self, have three copies of self,
private asns, ...), why should i pay with complexity (== fragility) to
accommodate them?
randy
___
sidr
IMO that's not the problem. The problem is that we don't want to have
special mechanisms for cases that occur 0.0007% (or is 0.02%?) of the
time.
bingo!
It's like creating a special shampoo product line for albinos.
no. it is like changing your main product line.
randy
Speaking as one of the guys that would have to add the few dozen lines
of code to figure out the origin AS when sets are present, this is
*not* a big deal.
that is one small part of the job. glad you find it easy.
___
sidr mailing list
sidr@ietf.org
The issue is less a matter of being in lock-step between a pair of
caches. My concern is that if a cache is out of step with the policy
server that is used to populate that cache.
i have no idea what a policy server is.
What I had in mind was a simple message from the cache server noting
The use-case I have in mind is that a given provider may have a number of
cache servers deployed within their network. A given router may wish to
have a session with two servers for redundancy purposes.
do not do it
It seems odd for you of all people, Randy, to want a feature that can so
givem the rpki operational structure, it would be deliciously wonderful
if you could describe how multiple gathered caches thereof can be
consistent.
consistent with what exactly?
as no other entities were mentioned, it would be safe to assume
eachother.
i would hope/expect that the caches
if border router A fetches the origin validation database from RPKI
and another border router B fetches the origin validation database
from IRR, the third router receiving IBGP updates may want to know the
source to be able to make a better decision. However this use case is
extremely rare;
draft-achi-rpki-signed-object is a generic template designed to simplify
the specification of RPKI signed objects.
Note that to instantiate the template and create a new type of RPKI
signed object all you have to do is:
1. Get an OID to identify the ContentType for the new type of
The working group chairs have received a request from the authors of
draft-achi-rpki-signed-object-00.txt that the working group adopt this
internet draft as a work item.
support
randy
___
sidr mailing list
sidr@ietf.org
Generally I support this too, but have a specific question: what's the
intended future relation between this would-be-draft and the existing ROA
draft? I mean, once we have a template, we should use that, even for the
ROAs, right?
i have been told that is the plan. i certainly hope so.
I am asking for comment on the list as to whether there is wg consensus
that draft-ietf-sidr-ta-04 should use the alternative format.
yes, please.
randy
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
I am calling for wg consensus on the question. Should the authors of
draft-ietf-sidr-rescerts-provisioning-06 revise that draft to remove TLS
from the protocol?
yes, please
___
sidr mailing list
sidr@ietf.org
Also, I would not characterize the question as you did above. Isn't
the proposal for a (hopefully revised) version of Sam's draft to
replace sidr-ta-04?
indeed. sam's draft should replace.
randy
___
sidr mailing list
sidr@ietf.org
To: The structure of the RPKI is modeled on the existing organizational
structure that is already responsible for IP address and AS number
resource allocation. In this allocation hierarchy, IANA allocates
resources to five Regional Internet Registries (RIRs), each of
which
1.4.1. Certification authorities -- 2nd paragraph
From: Organizations that do not distribute INRs, but hold such resources
also act as CAs when they create EE certificates.
To: Organizations that do not distribute INRs, but hold such resources
also act as CAs when they create EE
I would like to see the CP accommodate an operating practice where the
issued certificate has a lifetime that reflects the nature of the
business relationship between the INR distributor and the INR
recipient.
i suggest not getting into business relationships. surely we can deal
with
saturday november 6, we will be doing an rpki testbed workshop and
hackathon in the ietf terminal room. bring unix/macosx/linux laptop,
or access to a system on which you can do the install and configure.
randy
___
sidr mailing list
sidr@ietf.org
saturday november 6, we will be doing an rpki testbed workshop and
hackathon in the ietf terminal room. bring unix/macosx/linux laptop,
or access to a system on which you can do the install and configure.
For public information, what code will you be using for this?
the open source full
Pradosh has asked that we consider:
http://tools.ietf.org/html/draft-pmohapat-sidr-origin-validation-signaling-00
for adoption in SIDR, could we hear back before 10/22/2010 pls?
yes
___
sidr mailing list
sidr@ietf.org
---BeginMessage---
A new version of I-D, draft-ymbk-rpki-origin-ops-00.txt has been successfully
submitted by Randy Bush and posted to the IETF repository.
Filename:draft-ymbk-rpki-origin-ops
Revision:00
Title: RPKI-Based Origin Validation Operations
Creation_date
---BeginMessage---
A new version of I-D, draft-ymbk-ghostbusters-01.txt has been successfully
submitted by Randy Bush and posted to the IETF repository.
Filename:draft-ymbk-ghostbusters
Revision:01
Title: The RPKI Ghostbusters Record
Creation_date: 2010-11-08
WG ID
1) The startup cost of downloading and processing all RPKI data needs
to be on the order of hours and not days.
no, it has to be minutes not hours
As for the 300K estimate, I'm happy to be corrected, but the order of
magnitude ought to be similar to:
(# AS's participating in BGP
It would be worthy to write a note warning that invalid announcements
which are more specific that an existing valid announcement SHOULD be
discarded
could you give an example in real cisco ios or junos cli?
randy
___
sidr mailing list
sidr@ietf.org
It would be worthy to write a note warning that invalid announcements
which are more specific that an existing valid announcement SHOULD be
discarded
could you give an example in real cisco ios or junos cli?
not yet. stay tuned.
my point was that lengh comparison is not supported in cli,
WG Adoption for draft-ymbk-rpki-origin-ops-00
WG Adoption for draft-ymbk-ghostbusters-01
WGLC for draft-ietf-sidr-rpki-manifests-09
WGLC for draft-ietf-sidr-rpki-algs-04
WGLC for draft-ietf-sidr-rescerts-provisioning-09
WGLC for draft-ietf-sidr-repos-struct-06
WGLC for
Randy Bush has requested a WG LC for draft BGP Prefix Origin
Validation
The document and the draft version history are available at
http://tools.ietf.org/wg/sidr/draft-ietf-sidr-pfx-validate.
strangely enough, i support this one too
randy
This draft is not ready for last call: draft-ietf-sidr-pfx-validate
Please see comments:
http://www.ietf.org/mail-archive/web/sidr/current/msg02204.html
authors are looking at this
I also request that it be an Informational RFC (rather than a
standards track RFC) just as
let's be old fashioned
option 1: add to repos-struct
creates iana registry
option 2: add to roa-format (and other signed object docs)
each doc adding requests an entry in registry
randy
___
sidr mailing list
sidr@ietf.org
I believe these changes have not been incorporated in the I-D yet. Could
this be done and a WGLC requested please?
Karen sent the revised text to the list a while ago, showing what it
replaced. Our plan is to publish the revised CP after WGLC has been
declared over (finally!), not to
Andrew suggests that the new naming schemes should be added to the
repos-struct draft.
Tim's message implies that the naming scheme would be added to the
roa-format draft (by extension, to whatever draft creates a new
repository structure element, like the ghostbusters draft).
I'd
Interested in knowing what the PDU formats will be if the 2 fields are
removed...
RPKI-RTR Protocol by Randy Bush
-- Newest version removed the fields Color and Source
-- This draft has running code (both client and server)
-- This draft is ready to move forward to WGLC
the pdus
I have a question about the interpretation of the history, the cache
should keep. Does the draft explicitely or implicitely say, that there
is a minimum time, the cache have to keep its prefix entries.
from 5.1
To limit the length of time a cache must keep the data necessary to
generate
Title : The RPKI/Router Protocol
Author(s) : R. Bush, R. Austein
Filename: draft-ietf-sidr-rpki-rtr-06.txt
Pages : 21
Date: 2011-01-05
- A router establishes and keeps open an authenticated connection to a
-
thank you, thank you, thank you, for your review.
Comment 1) The validation state terminology used in this draft is not
consistent with the terminology of draft-sidr-pfx-validate. That
draft uses states: valid, invalid, not found, whereas this draft uses
states: valid, invalid, unknown. Do
1 - 100 of 633 matches
Mail list logo
