Tim.
I'm happy to hear that you liked the revisions I made, several of which
were suggested by Chris.
However, I maintain that the term "adverse" has connotations that you
may not intend, but a significant proportion of readers will pick up
on. The first synonym on dictionary.com is
"anomaly" is better than "unwanted" in some respects, but it too fails
to convey the fact that the anomaly has an adverse impact on the INR
holder. It would be anomalous if a CA changed a cert to contain more
resources than were supposed to be allocated to the INR holder, but if
these
Randy
Tim offered no suggestion for a different term, which is not helpful.
the suggestion was "unwanted".
I reread Tim's message; I don't interpret it as having suggested
"unwanted" as an alternative.
that is clear. others, such as matthias and i, did. but this is not
productive.
to be
Tim,
I agree that the preferred approach is to persuade law enforcement folks
to not view the RPKI as a new tool for taking down sites. However, I
have already encountered folks in the law enforcement community who
viewed it as such. I have argued that this wold be bad, but ...
Given the
Matthias,
Hi Steve,
On Wed, 27 Jul 2016, Stephen Kent wrote:
Tim offered no suggestion for a different term, which is not helpful.
the suggestion was "unwanted".
I reread Tim's message; I don't interpret it as having suggested
"unwanted" as an alternative. What
Randy,
I read your comments carefully, and I'm puzzled by several of them.
Your said, for example:
and what tim, and others, are trying to say is that exactly those
meanings are inappropriate. we do not really know intent, contracts,
and business/social context.
the introduction says:
Tim,
Hi Steve, list,
I still have an issue with the word "adverse" used in this document, and
especially the first line in the introduction:
In the context of this document, any change to the Resource Public
Key Infrastructure (RPKI) [RFC6480] that results in a diminution of
the
Folks,
I have just posted the -01 version of the adverse actions document. It
contains the edits I noted in my response to Tim on 7/19, as well as the
revisions to the intro in response to feedback from Sandy and Randy.
Please send any comments on the revised version to the list.
I want to
Chris,
Here is my message to the SIDR list from 6/16:
I read the latest version of this document and have a few comments,
some of which I have made before, to no avail ;-).
I still find the wording of the three examples in Section 4 to be
unnecessarily informal. I’ve provided
Sandy & Chris,
I believe Chris' declaration is premature.
I anticipate that Dr. Ma may want to take over slurm, with David's
permission.
With a few minor tweaks the use cases doc can be done.
Steve
___
sidr mailing list
sidr@ietf.org
Oleg,
Thanks for the feedback on our doc.
Well, actually there is normative language:
you're right. those instances of MUST will be changed to lowercase,
since the intent is that this doc be informational.
And there are several other places where the normative language is not used,
but
Tim,
Hi,
So, to be clear I think this is the related text in section 9 of RFC 6487:
A new document will be issued as an update to this RFC. The CP for
the RPKI [RFC6484] will be updated to reference the new certificate
profile. The new CP will define a new policy OID for
Sandy,
I can’t parse “but using the constraints applied come from this specification”.
Can you clarify?
The text I supplied for the replacement validation alg were based on the
original text, whenever possible. Unfortunately, the original text
refers to sections of 6487 implicitly as "this
Rob,
I agree with your suggestion to create a new OID for this purpose. This
can be noted in the document under discussion.
I also agree with Russ's comment that the cert policy needs to be
updated to reflect the fact that use either OID is OK (if we stick with
one policy OID).
Steve
Tim,
Thanks for taking the time to read and comment on the document.
I will change CA certificate analysis to be section 2.1, and make the
CRL section b 2.3, as per your request. The Manifest section will remain
2.2, ROAs will become 2.4, GB will become 2.5, and Router Certificates
will
Sriram,
>A newer ROA competes with an older ROA if the newer ROA points to a
different ASN, contains the same or a more specific prefix, and is
issued by a different CA.
For DDoS mitigation service, (as an example) a /16 prefix owner may
create (well in advance)
two new ROAs for
Sandy,
I don’t see that there’s a requirement that a router have only one certificate,
either. A router that was configured to speak as two different ASs might have
one key certified by both ASs and might have two different keys, one for each
AS.
There was no intent to suggest that a
Randy,
Thanks for providing additional examples to clarify your concerns.
I'll revise the intro text accordingly.
Steve
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
Randy,
I presume you are referring to the text that describes ROA competition,
although you didn't cite specific text in your message (too much typing?).
I'll revise that text to note the case of a resource transfer appears to
be competition, absent any additional info labeling it as such.
Although I was not present at the BA SIDR meeting, I did participate
remotely for one of the sessions. I recall the discussion of the I-D
that tries to collect all of the RP requirements in one place, with
cites to the sources of these requirements. It part, I recall folks at
the mic arguing
Geoff,
Thanks for reviewing the text.
I modified the text to change "current VRS-IP" to be "... the value of
the VRS-IP computed for certificate x-1" as per your suggestion. I also
made this change for the corresponding VRS-AS text.
I don't think we need to add a note about validation being
I've been discussing details of text in the "validation revisited" I-D
with Tim, now that he has become the primary editor. I believe a
description of a new validation algorithm will be cleaner and easier to
understand if we replace all of section 7.2 in 6487, rather than trying
to change
I read the latest version of this document and have a few comments, some
of which I have made before, to no avail ;-).
I still find the wording of the three examples in Section 4 to be
unnecessarily informal. I’ve provided suggested text for previous
versions of this document that probably is
Tim,
Sorry to have not replied sooner.
Hi all,
I promised to take this to list.
So, as presented today, the volume of updates of MFTs and CRLs in the RIPE NCC
repository vs updates of ROAs is about 1000:1. This is a bad signal -to-noise
ratio that causes waste of cycles and bandwidth.
I realize that this is just a -00 draft, but we had a moderate amount of
discussion before it became a WG document, and after the requested
changes were made, many people expressed a support for its adoption.
Thus, I am requesting that the chairs initiate WGLC, to encourage
additional review
Alvaro,
...
It means that most of the code one needs to deal with version one is
the same as the code one needs to deal with version zero. Feel free
to suggest better text.
When I think about protocol compatibility I think about on-the-wire
behavior and packets, not about the implementation
Stephen, et al.,
A couple of observations about the topic of certs used to verify RPSL sigs:
- the title of the I-D says that it relies upon the RPKI, and, as
currently
written, it mandates use of RPKI certs. So, using certs from a different PKI
would require a re-write. Also, the
George,
I agree that it's more convenient to have the EE cert close to the
RPSL data being verified. Just so long as RPs use the RPKI to acquire
the cert path info, revocation status info, etc.
Steve
___
sidr mailing list
sidr@ietf.org
I didn't attend the IETF meeting, but I did listen to the Wednesday SIDR
session, at
which the issue was raised as to whether the BGPSec RFC should be
standards track
or experimental.
I believe standards track is the right approach here. This document has been
viewed as standards track since
Sandy,
Keeping the original notBefore date/time isn't "wrong" but I agree that
it would be preferable to change the value to the re-issue date/time, as
per Doug's suggestion.
Steve
___
sidr mailing list
sidr@ietf.org
To address the topic Tim B. raised wrt the IRR system, and n light of
the comments
provided by the cognizant routing AD, I propose adding the following
text as a
second paragraph in the Security Considerations section.
Unless I hear suggestions otherwise, I'll add this text before we submit
Tim,
That's a fair point. Are you suggesting that we create a separate doc to
enumerate
vulnerabilities in the IRR context, or that we add a section to this doc
to describe,
in less detail, such vulnerabilities?
Steve
Dear working group,
I support adopting this work. I believe it's useful
Sean,
Thanks for catching this omission.
I think option C is OK, if the text explains the rationale, as you have.
Steve
Off-list, Rob correctly pointed out that there are two PKCS#10-related issues
that are not describedt; both arise from requirements for BGPsec certificate
extensions:
1)
I concur with David's observation. The reference has a typo and is fixed
by his suggested change.
Steve
The following errata report has been held for document update
for RFC7132, "Threat Model for BGP Path Security".
--
You may review the report below and
Geoff,
Happy new year.
...
Consider a cert path from a trust anchor TA, to CA1 to CA2 to an EE cert for a
ROA.
TA->CA 1->CA 2->ROA
Assume the TA cert contains address space T, U, V, W, X, Y and Z.
Assume the CA 1 cert contains address space T, U, V, and W.
Assume the CA 2 cert
Tim,
...
I believe the draft is being precise, but in the process has become difficult
to parse. Let me attempt once more to explain the proposal in a different way:
"When doing top-down validation of resource certificates in the RPKI we propose
that rather than rejecting a certificate that
Tim,
Since, as you reminded me, this is Informational, I agree that this
doc need not be co-authored as I had suggested. But the intro must
emphasize that it just documenting what RIPE has chosen to do, and
that it does not claim to be a set of recommended local cache management
design notes.
I think we ought to have a document that describes how an RP can manage
a local
cache, since we usually say that we expect RPs to do so. However, this
document
seems to be a description of only one implementation's approach to local
cache
management. I'd be more comfortable with a document
None of those who believe that this draft is a good thing seem to have
addressed
an issue I raised a while ago; the proposed solution is ill-defined and,
the most
likely interpretation doesn't seem to work, in general. I'll try to
explain this
reasoning, again, and provide an example.
Section
Sam,
On Fri, 6 Nov 2015, Stephen Kent wrote:
So, unless the folks who volunteered to assume responsibility for the
doc (all of whom were already listed as co-authors) are prepared to
do a much better job in addressing these shortcomings, I object to
continuing with this work.
It sounds
Tim,
The second point I tried to make is that if it is already clear that consensus
will never be reached on this, then spending more effort on it is a waste of
everyone's time. I understand that there are no guarantees that consensus will
be reached, but if there is a guarantee that
Carlos,
Karen/Steve,
Sorry for getting back to this late.
Andy is right on the money: the text validation-reconsidered has
possible 'things that can go wrong' could be removed but the main idea,
as Andy says, is to engineer robustness into the system in a way that
the system will be more
Please take 2 weeks time to consider:
"This document was adopted as a WG work item, should we accept this
change and complete the work or not?"
Adopting a doc as a WG item does not mean that it is acceptable
"as is" at the time it was adopted. The intent is that the author(s)
will cooperate
Sandy,
I think "draft-ietf-sidr-rpki-validation-reconsidered served a valuable
purpose,
highlighting valid concerns about potential fragility in the RPKI, in
the face of
errors by CAs and in the context of INR transfers. However, I feel that
this I-D
should not progress.
The topic of INR
I reviewed this doc and sent a few editorial changes to Sean.
With those changes, I think it's ready to go.
Steve
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
I reviewed this document and suggested a number of editorial changes to the
authors. Other than these changes, I think this document is ready.
Steve
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
This version has two major changes:
- it includes text that describes the impact of each of the adverse
actions,
in the context of each RPKI repository object type. This text was
added in
response to a request fro Andrei.
- the subsections have been re-ordered to be
Sandy,
I provided detailed comments on this document on June 2.
Randy later said he didn't see them, so I resent (just to Randy) on July 7.
Steve
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
David,
...
What does the guarantee about signature order provide? I don't see how
it's useful, but I could be missing something.
At least initially, sig order was required to match the AS transit
order, to ensure that the
AS transit order is accurately represented. Is that no longer true?
Not surprisingly, I support adoption and will participate in the discussion.
Steve
The authors of draft-dseomn-sidr-slurm adoption have requested working group
adoption.
A working group adoption call starts now and will end 14 days from now on 10
September.
Please respond on the list to say
yes, I concur as well.
Steve
This seems correct to me (the proposed change I mean)
At Tue, 25 Aug 2015 15:45:52 -0700 (PDT),
RFC Errata System wrote:
The following errata report has been submitted for RFC7132,
Threat Model for BGP Path Security.
--
You
Richard,
no problem.
anyway, my comments may have been too strongly worded. If we feel that
it's important
for router certs to use a different hash alg, then the router cert
profile can
define which alg to use, as an explicit, profiled deviation from the
RPKI cert
profile. We can also
Sean,
...
Okay so I want to agree. But, I’m still trying to grok something you sent in
an earlier msg
(https://mailarchive.ietf.org/arch/msg/sidr/9vVsAheeeZMj7GI00nyGBDHBqPI) that I
think is related when you said:
RPs would not have to calculate/validate the SKI value; they would only
Andy,
...
Steve,
Given what I said initially in this thread, I thought we were talking
about the same thing. I guess not. We could tease this apart, but is
it worth it if “Randy’s view” covers all situations?
-andy
Randy's approach covers both cases, at the cost of some added complexity
Andy,
The context for the discussion is address space transfer in the RPKI
context.
We don't have an RFC describing how to do that, AFAIK. So, when you say that
this is the scenario we have today, to what are you referring?
Steve
On Jul 15, 2015, at 4:41 PM, Stephen Kent k...@bbn.com
Sandy,
On Jul 7, 2015, at 11:41 AM, Stephen Kent k...@bbn.com wrote:
- I think the doc should distinguish between transfers of live
address space vs. transfers of space that is not currently in
use. The former are more complex tan the latter and thus merit a
different discussion
Andrei,
Thanks for taking the time to read the adverse actions doc. I realize that
it's dense in places, and appreciate feedback to improve it.
In my opinion it'd be useful to have an analysis of implications of
adverse actions with respect to Internet Number Resources (INRs). I
understand
Randy,
What I meant to imply is that:
- because the entity transferring the space knows whether it is is use
- and because asserting that it isn't, when it is, will adversely
affect users
affiliated with that entity
- therefore the entity in question is motivated to get
So, your argument is that because a mis-declaration of space as unused vs.
can by an ISP cause harm, we should engineer a transfer model that imposes
additional complexity on what seems likely to be the most common case.
(I assume transfer of unused space is or will be the most common case
I disagree.
In this context the entity relinquishing the address space should
know whether the space is in use or not. We ought to be able to
take advantage of this knowledge to simplify the transfer process,
when applicable.
Steve
On 7/10/15 5:14 PM, Randy Bush wrote:
making assumptions if
Carlos,
As Arturo mentions, defining 'actual use' of number resources has proved
quite tricky.
to an outsider maybe, but the entity initiating the transfer presumably
knows,
right?
There's not need to infer this status from externally observable info.
Steve
In the TAO proposal the entity relinquishing the address space is
presumed to know,
and to declare the transfer accordingly. That seems to be the simplest
approach,
and if that entity screws up, its users are impacted.
Steve
___
sidr mailing list
Andy,
In this context live refers to address space in use as opposed to
allocated
but not in use. So your reply doesn't address the question.
Steve
On Jul 8, 2015, at 1:30 PM, Sandra Murphy sa...@tislabs.com
mailto:sa...@tislabs.com wrote:
I think it would be interesting to hear from
Randy,
really do appreciate review.
you're welcome.
do not appreciate pdfs of word docs; makes copy paste and commenting
back a major pain. though i have come to suspect that is one of your
goals. so i will not comment on your comments in that pdf, though i
adopted/adapted the majority,
Three observations:
- the briefing you cited was a high level discussion that did not
make a strong
case for the validation revisited I-D.
- I submitted comments on the list about Randy's transfer I-D.
- draft-kent-sidr-adverse-actions-00 documents a range of potential
problems
Sandy,
Perhaps you are reading too much into the use of conforming to?
Perhaps saying aligning with would make it more clear to you? I do
not know what current CMS implementations would do if they were
presented with a RFC6485 compliant RPKI signed object. They may indeed
report the signed
Chris,
I already said that (as a co-author) I support killing off LTAM at this
time.
I also should note that I support adoption of SLURM as a way to replace
several
of the critical capabilities that LTAM offered, in a much simpler fashion.
Steve
Sandy,
No I had not noticed that the doc completed WGLC, but I guess I was on
vacation at
that time.
If my co-authors and you and Chirs, and Alvaro agree, I'll suggest that
Richard raise the issue during IETF last call as a way to letting
everyone know that we plan to make this
change
Di Ma and I, with help from several folks at BBN, have generated this
document to try to characterize the set of attacks/errors that might
adversely impact INR holders in the RPKI context. As we discuss topics
like RPKI path validation, the Suspenders ideas, and Slurm, it seems
appropriate to
Richard,
Thanks for thinking (in great depth) about the potential security
implications of
SKI collisions in BGPsec.
In the general case of a PKI, collisions of SKI values are not security
relevant.
The SKI MAY be used in path discovery, but the intent was to limit its
use to
quickly
yes, please put a stake in it!
Steve
Howdy SIDR folks,
This draft expired:
http://tools.ietf.org/wg/sidr/draft-ietf-sidr-ltamgmt/
I think this is proper, given the discussion on-list and in-person, we
seem to have moved away from the world of LTA management and on to:
slurm:
George Michaelson
Stephen Kent
Filename: draft-ietf-sidr-rfc6490-bis-04.txt
Pages : 9
Date: 2015-05-14
Abstract:
This document defines a Trust Anchor Locator (TAL) for the Resource
Public Key Infrastructure
Iljitsch,
The topic of partial path signing was explored in detail and rejected
for a couple
of reasons. It was way too complex to figure out how an AS could rely
on partial path
sig info, and there appeared to be a lot of ways to exploit the new
attack surfaces
created by partially signed
John,
Looking at the ARIN xfer stats a few additional questions come to mind:
- are most/all of the ARIN - APNIC transfers sales of unused
address space?
- are many/most of the internal transfers the result of
organizational changes
and thus involve live address space?
-
John,
Thanks for the timely reply and the informative responses.
Steve
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
John,
Steve - That information might indeed be useful in understanding the
potential importance of the issue historically, but would not be an
indication of the need going forward unless one presumes that the
demands in the past for transfers reflects the future rate of
transfers - this
The text needs a lot of work, i.e., odd English constructs are very
common, and there are a number of typos, some of which I have noted
below. I thought the current acronym is BGPsec. not BGPSEC. Also the
document has too many instances of “could” and “would” where more
normative statements
Sandy,
I reviewed the doc with David M., since he is a co-author and because his
office is down the hall :-).
As a result of our discussion he has a number of comments to be addressed in
the next version.
Steve
So after all the anguish about the rsync protocol, we now have a suggested
Brian,
I apologize for this very, very late comment. Your message from late
November
got lost in my inbox.
I worry that accommodating multiple signatures will cause confusion for
RPs. One would need to specify what to do if one sig fails, but other
succeed,
for example.
Steve
All,
Terry + Leo,
Sorry I didn't around to reviewing your doc sooner.
here are some comments:
4.1: The suggestion that the RPKI needs to support different
algorithms in different jurisdictions conflicts with RFC 6485.
It is not consistent with the algorithm agility design in RFC 6916
(BCP 182),
Wes,
To first order I agree with your concern of this DoS vulnerability,
but with some minor clarifications.
1. BGPsec-signed updates are sent only between ASes that agree to
send and receive (separate choices) this signed data. So, an
attack of this sort is perpetrated only against an
Sandy,
The minutes note consensus in the meeting on several topics. I'm attempting to
capture them here.
The mailing list is always the final word on consensus. If you object to any
of the following, you should speak on list now!
If I've missed something noted in the minutes, you should
Carlos,
...
Given that S-BGP failed to gain any traction and most people outside the
IETF have never heard of it, I don´t think it sets a particularly
encouraging precedent.
You asked why 3779. I explained. The were many reasons why S-BGP
didn't succeed, but use of 3779 is not likely one of
Carlos,
Hello,
I think what we need to discuss is which certificate validation rules
apply to our problem domain, basically securing origin and/or securing path.
Current specs refer that RFC 3779 validation rules should be applied to
SIDR's problem domain. I couldn´t find any justification
Carlos,
It is weird that we even need to state here that we the five RIRs are
not going to break things intentionally, but, yeah, LACNIC will not
break things intentionally either.
I don't think anyone requested that each RIR pledge to not try to break
the RPKI.
I did ask that RIRs describe
Byron,
Thanks for providing the details of what APNIC does. Those are
precisely the sort of
checks I would hope for.
I agree that if APNIC had IANA as its parent, then the issue you cited
would be relevant, i.e.,
you can't know if IANA issued a new cert that removed an INR from your
cert,
Sandy,
Speaking as regular ol' member
The bgpsec-protocol draft has the following text:
Next, the BGPSEC speaker verifies that the origin AS is authorized to
advertise the prefix in question. To do this, consult the valid ROA
data to obtain a list of AS numbers that are
Sandy,
...
When this working group was developing the RPKI specifications, the RIRs essentially
asked us not to specify how the movement of resources across registries would
take place. I for one accepted this at the time because it looked like an issue between
RIRs. This document is
Tim,
Thanks for providing the description of the processing you employ in
your RP software.
...
Okay, let me elaborate a bit on how we do this..
We don't use openssl for this. We have our own implementation and the way we do
this is fully top-down. We don't pass the content of the ROA we
Sandy,
speaking as regular ol' member
On Jul 24, 2014, at 12:09 PM, Tim Bruijnzeels t...@ripe.net wrote:
On Jul 24, 2014, at 11:30 AM, Sandra Murphy sa...@tislabs.com wrote:
On Jul 24, 2014, at 10:37 AM, Russ Housley hous...@vigilsec.com wrote:
…
RFC 3779 has been implemented. For
Tim,
...
The first approach has my strong preference. I believe it's simple
to explain and implement, effective against both concerns, and I do
not see any security issues with it. The change boils down to this:
when doing top-down validation, just accept the *intersection* of
resources
Tim,
I think I was not clear in requesting clarification for your tests. I
didn't mean to
ask what your RP code does. I was asking what your CA code does to
detect and reject
over-claiming, and what it will do under relaxed validation rules. I ask
because it
may be harder to perform such
Tim,
Hi,
As you may have noticed my name was added to the author list, so it
will come as no surprise that I read this document and agree with its
content.
I believe that all RIRs share both operational concerns outlined in
section 3: (1) Operational fragility, and (2) resource transfers.
Carols,
As newly-added co-author of this document, I obviously share the
concerns expressed in Section 3.
Although it can be argued that these issues could be worked around by
careful coordination among all involved CAs when any change is to be
performed on resource sets included in CA
Chris,
1) Validation Algorithm Document/process - We've talked about this
on-list a bit, and in at least 3 face-to-face meetings, the document was:
http://tools.ietf.org/html/draft-huston-rpki-validation-01
and recently became this:
Rob,
At Mon, 30 Jun 2014 11:27:03 -0400, Stephen Kent wrote:
I did suggest we might use other cert request mechanisms. EST is the
obvious, current, standards-based option for this, if folks want to
consider alternatives to PKCS#10. Since it was authored by a Cisco
guy, there is some chance
Sandy,
On Jun 30, 2014, at 6:09 PM, Sandra Murphy sa...@tislabs.com wrote:
So we need to come up with a way to get the AS number to the CA, also.
To continue this thought…
There's a list in RFC6487 of the certificate extensions that are allowed in the
PKCS#10 request.
Is there any reason
Sandy,
On Jun 27, 2014, at 8:53 PM, Randy Bush ra...@psg.com wrote:
[ you omitted the as number in your discussion, but ca needs a so it
knows which AS signs. luckily bgpsec-pki-profiles does have it in the
pkcs#10 subject ]
That's a good point.
Actually, bgpsec-pki-profiles does NOT
I appreciate the changes Randy made to the -00 version of this doc.
However, I have a few concerns about the current version.
The end of Section 3 states:
For the purposes of this exploration, we refer to this localized view
as a 'Local Trust Anchor', mostly for historical reasons, but
Sandy,
Thanks for continuing to pursue this issue.
If we go with #4 below, I think your proposed revision makes sense.
I've seen Randy's comments on the other 3 options, so #4 seems to be at
the top of that list, now.
I did suggest we might use other cert request mechanisms. EST is the
1 - 100 of 379 matches
Mail list logo
