Re: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am afraid I don't believe this policy should be adopted at this time. My reason is that I think it creates a legal and political risk that is substantial and as yet uninvestigated in the PDP, but which may in the long term reduce the overall robustness of Internet infrastructure to an extent that greatly outweigh the security benefits of the policy. This is not a minor, administrative policy. It is (even if not intended as such) the first step in a process the end result of which would be a major change to the Internet architecture. I am afraid that the ultimate outcome could be that the Internet becomes more fragile as a consequence. True, it's only the first step. But if it's a step in the wrong direction, let's not do it. I don't think we should approve this policy until we are certain that this approach is necessary, worth the risk, that no acceptable alternative solutions (or partial solutions) to the problem exist, and that we've also established all appropriate measures to mitigate the foreseeable risks. The complete argument about why I fear a bad outcome will be too long and complex for a first post on this subject, so let me try to give the briefest summary I can manage instead: I believe that if this policy is adopted, and if it is taken up significantly be operators, it will encourage a dramatic increase in the number of demands from law enforcement and private litigants to the RIPE NCC to revoke both allocation of resources and their certificates, without the consent of the person to whom the resource is delegated. Once legislators realise that the NCC has a more effective power to revoke allocations than previously existed, and has become more capable of making networks appear to "go offline" than it currently is able, legislators will likely respond by creating new powers for law enforcement to oblige the NCC to revoke resource allocations as a tool to address undesired behaviour by network users. In short, in a world where reachability is significantly affected by the ability to produce a valid certificate under this policy, the RIPE NCC will be seen as a "one-stop-shop" for knocking networks offline, to control illicit content and online activity. (Perhaps reachability will not be affected because network operators will ignore these certificates, but if we believe that then isn't this policy a waste of time and effort? And operators may not have a free choice: new legal powers were created by the EU last year that could easily be used to compel adoption). Thus, the RIPE NCC would be gradually transformed into a much more political body; indeed, I think at least as political as ICANN currently is. My concerns are not merely academic, they are immediate and practical. We know that many countries, including the EU, have adopted or are actively considering adopting legal requirements for network operators to block packet transit to/from network addresses outside their network in order to inhibit illicit content or activity (e.g. copyright infringement). LEAs already attend RIPE meetings (Co-operation WG) to ask the community to develop policies to transfer allocations of network blocks to the LEA following an allegation by the LEA that the netblock is being used for illicit purposes, the idea being to seize control of routing. Earlier this year the RIPE NCC attended at least one meeting that I know of to discuss this with EU officials. So far the NCC has fended off such requests, I understand, on the grounds that it doesn't have control over routing. If this policy proceeds, is adopted and successful, that argument will be greatly weakened. Would making RIPE NCC such an attractive single point of failure really make the Internet more secure and robust? I believe that before this policy is adopted the community should consider in depth: i) whether these concerns are at least potentially valid (I am convinced they are); ii) If so, whether the problem that this policy addresses is sufficiently serious to warrant accepting these new risks [1]; and iii) Even if the problem is serious enough, whether alternative means to address it could be found that would mitigate these risks [2]. (For example, if the problem could be 80% solved using a model that does not give RIRs a power to revoke and expire certificates "needed" for routing, is the residual 20% of the problem really serious enough to warrant creating the risks I describe). iv) Even if the problem still justifies adopting the approach taken in this policy proposal, what other steps should be taken simultaineously to mitigate these risks. For myself, I am convinced about (i). I have serious doubts about (ii) and (iii) myself, and perhaps more importantly can see no evidence on the list archive that the community has actively assessed whether (ii) is true, and no evidence that other potential architectures or system designs have been considered as a possible alternative that might better mitigate the risks I describe. Nor has there been any visible discussion of (iv). Even if I've missed something, do we really think the community has considered these issues in depth? Or have they been shunted off as a problem to be looked at later, or elsewhere? The presentation at yesterdays RIPE meeting plenary by Randy Bush and the discussion that followed convinced me that there is much more for the community to discuss. I have raised this issue at previous RIPE meetings but only recently become aware that to affect the PDP it was necessary to post on this list, for which my apologies. However I now see such objections are the explicit purpose of the Last Call, so I hope you'll consider this objection carefully. There is much more I could say, but for a first post on the subject I'll leave it at that; I don't want to create a bigger "wall of text" than absolutely necessary. I would be grateful if those who agree with me that this discussion warrants delaying adoption of the proposal would say so now, so that the WG Chair can see whether there is a "serious objection" that prevents a rough consensus being declared at this time. My apologies to those who have worked so long and hard on this, with only the best of motives, on the assumption that there was general support for this approach. But I'm afraid this issue is too important to let this pass without raising my concerns, and asking the community to stand with me. Malcolm. [1] Yes, route hijacking does happen, sometimes by mistake and sometimes by malice. But how often? Are current responses sufficient to deal with it proportionately? Could they be made more effective without any kind of certification scheme? Would something new, that's not a certification scheme suffice? [2] For example, could we creates "webs of trust" rather than a single hierarchy? Would that be "good enough" or is a hierarchy essential? Could a PKI for address allocations work sufficiently well without investing the hierarchy with authority to revoke certificates? Should we consider an architecture with a distributed issuer/revoker, spread across multiple jurisdictions? What other models exist? - -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | http://publicaffairs.linx.net/ London Internet Exchange Ltd Maya House, 134-138 Borough High Street, London SE1 1LB Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2/56YACgkQJiK3ugcyKhTdwgCgp02ZpOj7XhT1TlN5xk7vOF9l ZdAAoIe+LF1Dt70q9Gonk2/CsoLG6N2O =z7io -----END PGP SIGNATURE-----
On 3 May 2011 13:31, Malcolm Hutty <malcolm@linx.net> wrote:
I am afraid I don't believe this policy should be adopted at this time.
I agree that it should at least re-visited as some of the wider implications might have been missed in the process as the focus has been with the technical solution to the 'problem' rather than potential for 'outside influence'. I'm also worried that the discussion seem to have moved to an automated router based implementation rather than an abstracted policy implementation that an operator can make an informed decision on with the ability to override it (in the same way that someone would build per peer filters today). I always understood (possibly wrongly) that this was about improving the quality of the RIPE (and other IRR) dbs rather than automating a DoS/LEA toy that *will* cause problems in the same way fat fingering today causes these issues. J -- James Blessing 07989 039 476
Hi James & Malcolm,
I agree that it should at least re-visited as some of the wider implications might have been missed in the process as the focus has been with the technical solution to the 'problem' rather than potential for 'outside influence'.
The policy by itself doesn't require you to automate the process within your network to accept / deny / discard prefixes. If I speak for myself, I know that I won't be the first to start using in network prefix alterations based on the information within the RPKI db. I will however use the repository to check if what my customers want to start to announce to our network. And when PI is going to be accepted after this policy, also PI. The question is not what you are planning to do within your network with this or how paranoid you plan to be in regards to the tools around this. If you don't want to use the provided tools from RIPE NCC, run your own CA. If you don't want to use RPKI, fine as well, no-body is forcing you. However with the hijacking of (legacy) IP space and ownership of especially pre-rir IP space, we need to get a policy in place that will allow us to do this. Is the current policy perfect ? As in, final and all inclusive etc ? nope.. Is it a good start ? Imho.. a full YES ! I would strongly suggest to get on the RPKI support bandwagon and get the current policy in front of us approved and work together on how we can get the other stuff included in the next version. I'm on the RIPE meeting atm, let's have a cup of coffee if needed on the topic. Regards, Erik Bais
On 3 May 2011 15:42, Erik Bais <ebais@a2b-internet.com> wrote:
Hi James & Malcolm,
I agree that it should at least re-visited as some of the wider implications might have been missed in the process as the focus has been with the technical solution to the 'problem' rather than potential for 'outside influence'.
The policy by itself doesn't require you to automate the process within your network to accept / deny / discard prefixes.
No but listening to people describing it as an automated tool for routers to make decisions really scared me...
I will however use the repository to check if what my customers want to start to announce to our network. And when PI is going to be accepted after this policy, also PI.
This a useful function of the RPKI (and the use that I expected this for, when it moves to automation then I have the fear.
The question is not what you are planning to do within your network with this or how paranoid you plan to be in regards to the tools around this. If you don't want to use the provided tools from RIPE NCC, run your own CA. If you don't want to use RPKI, fine as well, no-body is forcing you.
Actually they way its being described (as a security tool) its being pushed as a "must use" rather than nice tool.
However with the hijacking of (legacy) IP space and ownership of especially pre-rir IP space, we need to get a policy in place that will allow us to do this.
Really? Would a policy to get the legacy space under control and ownership more tightly recorded be more useful for the community as a whole.
Is the current policy perfect ? As in, final and all inclusive etc ? nope..
Agreed
Is it a good start ? Imho.. a full YES !
Er, there is a difference - its a good idea, but I don't think its ready for showtime considering how people are talking about using it... Is bit-torrent a good idea? Is it an efficient way of distributing content for the content owner? Shouldn't all content be distributed using bit-torrent? depending on who you are and where you sit in the value chain you'll give different answers to the above questions but you'll agree that bit-torrent is a really clever solution to the problem of content distribution.
I'm on the RIPE meeting atm, let's have a cup of coffee if needed on the
:) /me sets phaser on lightly disintegrate... J -- James Blessing 07989 039 476
James, Erik, On Tue, May 3, 2011 at 10:59 AM, boggits <boggits@gmail.com> wrote:
On 3 May 2011 15:42, Erik Bais <ebais@a2b-internet.com> wrote:
Hi James & Malcolm, <snip> I will however use the repository to check if what my customers want to start to announce to our network. And when PI is going to be accepted after this policy, also PI.
This a useful function of the RPKI (and the use that I expected this for, when it moves to automation then I have the fear.
This is essentially not a property of RPKI however. It is a property of the RIPE DB itself. Let me quickly illustrate: To check what your customers wants to announce to you -- you talk to *them*. To check if what the customers wants to announce is also listed in $IRROFCHOICE, you check $IRROFCHOICE. I don't see what problem RPKI solves here. Kind Regards, Martin
On Tue, May 03, 2011 at 03:42:04PM +0200, Erik Bais wrote:
The question is not what you are planning to do within your network with this or how paranoid you plan to be in regards to the tools around this. If you don't want to use the provided tools from RIPE NCC, run your own CA. If you don't want to use RPKI, fine as well, no-body is forcing you.
There is no policy that determines that "everything longer than a /24 is not routable" either. If all your transits insist on rpki-signed advertisements, it becomes de-facto mandatory. The fundamental issue with this proposal is that it, like the block-lists that some governemnts dream of, establishes an infrastructure that is open to abuse. Everything that *can* be abused, no matter how well- intentioned it may have been, *will* be abused. And the last thing, in my opinion, that the DFZ needs is *another* attack vector. Kind Regards, Sascha Luck
Sascha, On May 3, 2011, at 8:44 AM, Sascha Luck wrote:
There is no policy that determines that "everything longer than a /24 is not routable" either. If all your transits insist on rpki-signed advertisements, it becomes de-facto mandatory.
Agreed.
The fundamental issue with this proposal is that it, like the block-lists that some governemnts dream of, establishes an infrastructure that is open to abuse. Everything that *can* be abused, no matter how well-intentioned it may have been, *will* be abused. And the last thing, in my opinion, that the DFZ needs is *another* attack vector.
At an abstract level, RPKI merely provides a way of validating the contents of the address registration database(s) that is (more) amenable to automation than current systems. The implication of this is that it will give the signers of resources anywhere in the chain the ability to impose policy on those beneath them in the chain of trust. In theory, that power exists today, e.g., RIPE could revoke an allocation and remove it from the registration database, resulting in an implicit revocation of all addresses assigned with the address space that had been allocated. I'm not aware of any abuse of the current system. Is your concern that the new system will make abuse somehow easier? Regards, -drc
On Tue, May 03, 2011 at 09:38:46AM -0700, David Conrad wrote:
In theory, that power exists today, e.g., RIPE could revoke an allocation and remove it from the registration database, resulting in an implicit revocation of all addresses assigned with the address space that had been allocated.
If the NCC (or even a third party) revoke an allocation, nothing happens automatically and immediately. (there might be some SPs that, periodically, check advertisements against the ripedb, I'm not aware of anything like that.) In an automatic RPKI environment, the cert gets revoked and your routing goes away.
I'm not aware of any abuse of the current system.
It's not efficiently abusable, in my opinion. Too many sanity checks.
Is your concern that the new system will make abuse somehow easier?
Hell yes. It not only makes it easier, it makes it *automatic* Kind Regards, Sascha Luck
APWG, I agree completely with what Malcolm says and wholeheartedly share his concerns in this area. We should all think real long and hard about the possible long-term implications of what this proposal sets the foundation for. In its essence this is a philosophical (which often intersects with political views) question that goes to the roots of each and every one of us. Personally, I firmly believe the strength and resilience of the Internet and the communication it enables (a tremendous asset for humanity in itself) lies in its distributed nature; not just in redundant communication links and routing protocols providing resilient routing, but a diverse political control. BGP hijack *is* a concern, but, it is most definitely a secondary or tertiary problem to the system at large IMNSHO. While I'm by no means suggesting we should not improve ourselves, I do believe we've handled these problems pretty well so far. The Internet *will not* fall over and die if we step back and take a deep breath on this topic. We have our RIS/BGPlay/Cyclops and pretty active BGP operators for the most part - I think we can "hold down the fort" while we convince ourselves that we have covered *all* aspects of this issue, and not mistakenly hasten anything through. I have not seen the concerns that Malcolm raises thoroughly debated or researched anywhere. The only debate I've seen has been a few threads on NANOG... I'd appreciate pointers to more of such research/debates if I have missed it (didn't find it on APWG, for instance.) I've personally initiated some early contact with the Tor community, because they are a very good bunch of people in analyzing Internet security from a privacy/freedom standpoint. I think more and similar contacts should be engaged. Rest assured, the people who have these concerns are *not* trying to stall RPKI just for the sake of stalling it! The concerns Malcom bring up, which I share, are very legitimate and I fully recommend we do not adopt this proposal until these issues have been more thoroughly addressed. And for the record, I do not believe surrendering to bureaucrats/lawmakers' pressure by doing their bidding is a positive evolution of our society. I'm far from any anarchist - I strongly believe in democracy with all its flaws, but a free, open and democratic society is not self-preserving by its own momentum as far as I have learned in life (seems to be quite the contrary). There actually has to be people constantly working to keep it this way, else it wither and rust away. We are those people. Or at least should be, IMO. The Internet is far too important for us not to be. Convince me these concerns are not valid, and this proposal has my support. Kind regards, Martin On Tue, May 3, 2011 at 7:31 AM, Malcolm Hutty <malcolm@linx.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I am afraid I don't believe this policy should be adopted at this time.
My reason is that I think it creates a legal and political risk that is substantial and as yet uninvestigated in the PDP, but which may in the long term reduce the overall robustness of Internet infrastructure to an extent that greatly outweigh the security benefits of the policy.
This is not a minor, administrative policy. It is (even if not intended as such) the first step in a process the end result of which would be a major change to the Internet architecture. I am afraid that the ultimate outcome could be that the Internet becomes more fragile as a consequence. True, it's only the first step. But if it's a step in the wrong direction, let's not do it.
I don't think we should approve this policy until we are certain that this approach is necessary, worth the risk, that no acceptable alternative solutions (or partial solutions) to the problem exist, and that we've also established all appropriate measures to mitigate the foreseeable risks.
The complete argument about why I fear a bad outcome will be too long and complex for a first post on this subject, so let me try to give the briefest summary I can manage instead:
I believe that if this policy is adopted, and if it is taken up significantly be operators, it will encourage a dramatic increase in the number of demands from law enforcement and private litigants to the RIPE NCC to revoke both allocation of resources and their certificates, without the consent of the person to whom the resource is delegated.
Once legislators realise that the NCC has a more effective power to revoke allocations than previously existed, and has become more capable of making networks appear to "go offline" than it currently is able, legislators will likely respond by creating new powers for law enforcement to oblige the NCC to revoke resource allocations as a tool to address undesired behaviour by network users.
In short, in a world where reachability is significantly affected by the ability to produce a valid certificate under this policy, the RIPE NCC will be seen as a "one-stop-shop" for knocking networks offline, to control illicit content and online activity.
(Perhaps reachability will not be affected because network operators will ignore these certificates, but if we believe that then isn't this policy a waste of time and effort? And operators may not have a free choice: new legal powers were created by the EU last year that could easily be used to compel adoption).
Thus, the RIPE NCC would be gradually transformed into a much more political body; indeed, I think at least as political as ICANN currently is.
My concerns are not merely academic, they are immediate and practical. We know that many countries, including the EU, have adopted or are actively considering adopting legal requirements for network operators to block packet transit to/from network addresses outside their network in order to inhibit illicit content or activity (e.g. copyright infringement). LEAs already attend RIPE meetings (Co-operation WG) to ask the community to develop policies to transfer allocations of network blocks to the LEA following an allegation by the LEA that the netblock is being used for illicit purposes, the idea being to seize control of routing. Earlier this year the RIPE NCC attended at least one meeting that I know of to discuss this with EU officials. So far the NCC has fended off such requests, I understand, on the grounds that it doesn't have control over routing. If this policy proceeds, is adopted and successful, that argument will be greatly weakened.
Would making RIPE NCC such an attractive single point of failure really make the Internet more secure and robust?
I believe that before this policy is adopted the community should consider in depth:
i) whether these concerns are at least potentially valid (I am convinced they are);
ii) If so, whether the problem that this policy addresses is sufficiently serious to warrant accepting these new risks [1]; and
iii) Even if the problem is serious enough, whether alternative means to address it could be found that would mitigate these risks [2]. (For example, if the problem could be 80% solved using a model that does not give RIRs a power to revoke and expire certificates "needed" for routing, is the residual 20% of the problem really serious enough to warrant creating the risks I describe).
iv) Even if the problem still justifies adopting the approach taken in this policy proposal, what other steps should be taken simultaineously to mitigate these risks.
For myself, I am convinced about (i). I have serious doubts about (ii) and (iii) myself, and perhaps more importantly can see no evidence on the list archive that the community has actively assessed whether (ii) is true, and no evidence that other potential architectures or system designs have been considered as a possible alternative that might better mitigate the risks I describe. Nor has there been any visible discussion of (iv).
Even if I've missed something, do we really think the community has considered these issues in depth? Or have they been shunted off as a problem to be looked at later, or elsewhere?
The presentation at yesterdays RIPE meeting plenary by Randy Bush and the discussion that followed convinced me that there is much more for the community to discuss.
I have raised this issue at previous RIPE meetings but only recently become aware that to affect the PDP it was necessary to post on this list, for which my apologies. However I now see such objections are the explicit purpose of the Last Call, so I hope you'll consider this objection carefully.
There is much more I could say, but for a first post on the subject I'll leave it at that; I don't want to create a bigger "wall of text" than absolutely necessary.
I would be grateful if those who agree with me that this discussion warrants delaying adoption of the proposal would say so now, so that the WG Chair can see whether there is a "serious objection" that prevents a rough consensus being declared at this time.
My apologies to those who have worked so long and hard on this, with only the best of motives, on the assumption that there was general support for this approach. But I'm afraid this issue is too important to let this pass without raising my concerns, and asking the community to stand with me.
Malcolm.
[1] Yes, route hijacking does happen, sometimes by mistake and sometimes by malice. But how often? Are current responses sufficient to deal with it proportionately? Could they be made more effective without any kind of certification scheme? Would something new, that's not a certification scheme suffice?
[2] For example, could we creates "webs of trust" rather than a single hierarchy? Would that be "good enough" or is a hierarchy essential? Could a PKI for address allocations work sufficiently well without investing the hierarchy with authority to revoke certificates? Should we consider an architecture with a distributed issuer/revoker, spread across multiple jurisdictions? What other models exist?
- -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | http://publicaffairs.linx.net/
London Internet Exchange Ltd Maya House, 134-138 Borough High Street, London SE1 1LB
Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk2/56YACgkQJiK3ugcyKhTdwgCgp02ZpOj7XhT1TlN5xk7vOF9l ZdAAoIe+LF1Dt70q9Gonk2/CsoLG6N2O =z7io -----END PGP SIGNATURE-----
Mrtin, Malcolm On Tue, 2011-05-03 at 09:22 -0400, Martin Millnert wrote:
APWG,
We should all think real long and hard about the possible long-term implications of what this proposal sets the foundation for.
We *have* been thinking long and hard about this. This proposal is nearly three years old. The operational community seems to think it is a good thing (there are over 400 LIRs using it already). Every other RIR has or will introduce it shortly. My knowledge of economics says that if there is a demand then someone will step in to satisfy it. If the community (as evidenced by this WG) tells the RIPE NCC not to implement this (or more precisely to withdraw the service they are already offering) then we simply open the way for private certification companies in the RIPE region. Everyone happy with that? Good.... then let's reject this proposal and continue to gaze at our own navels for the next three years. Nigel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/05/2011 14:04, Nigel Titley wrote:
Mrtin, Malcolm On Tue, 2011-05-03 at 09:22 -0400, Martin Millnert wrote:
APWG,
We should all think real long and hard about the possible long-term implications of what this proposal sets the foundation for.
We *have* been thinking long and hard about this. This proposal is nearly three years old.
Working diligently on one particular solution is not the same thing. If you've investigated other approaches to inhibiting route hijacking and discarded them, please share. If you've merely assumed that this is the only/best/obvious/~ approach, I don't think it's unreasonable to suggest we should pause to see if we can come up with something else that doesn't turn control of routing from a distributed to a hierarchical system. Malcolm. - -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | http://publicaffairs.linx.net/ London Internet Exchange Ltd Maya House, 134-138 Borough High Street, London SE1 1LB Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3BU5cACgkQJiK3ugcyKhS2yQCfZMU0xL1blDWWKcDoKhEWEHHR jWkAoMeV6gW8wdk/Uhnt2s8MrellZTOq =mXh/ -----END PGP SIGNATURE-----
If you've investigated other approaches to inhibiting route hijacking and discarded them, please share.
well, an approach i and some others studied using the reverse dns can be found in draft-bates-bgp4-nlri-orig-verif-00.txt. you might be educated by discovering why it did not fly. randy
On 04/05/2011, at 11:24 PM, Malcolm Hutty wrote:
If you've investigated other approaches to inhibiting route hijacking and discarded them, please share.
http://www.potaroo.net/papers/BGP_Security_Literature_Review.pdf Geoff
If the community (as evidenced by this WG) tells the RIPE NCC not to implement this (or more precisely to withdraw the service they are already offering) then we simply open the way for private certification companies in the RIPE region.
in which case, i would prefer to arrange a pro-bono one. randy
On Wed, 2011-05-04 at 16:02 +0200, Randy Bush wrote:
If the community (as evidenced by this WG) tells the RIPE NCC not to implement this (or more precisely to withdraw the service they are already offering) then we simply open the way for private certification companies in the RIPE region.
in which case, i would prefer to arrange a pro-bono one.
So would I. But I can imagine going to my boss and saying "there are two alternatives for securing my address space: a pro-bono, best effort thing run by Randy or a professional one run on a commercial basis by Mega-Certicates Plc. Which would you like me to use? Nigel
If the community (as evidenced by this WG) tells the RIPE NCC not to implement this (or more precisely to withdraw the service they are already offering) then we simply open the way for private certification companies in the RIPE region.
in which case, i would prefer to arrange a pro-bono one.
So would I. But I can imagine going to my boss and saying "there are two alternatives for securing my address space: a pro-bono, best effort thing run by Randy or a professional one run on a commercial basis by Mega-Certicates Plc. Which would you like me to use?
first, i did not say 'run' i said 'arrange.' my life is already insanely overloaded. second, your boss will get what she deserves randy
Hi Nigel & Randy,
On Wed, 2011-05-04 at 16:02 +0200, Randy Bush wrote:
If the community (as evidenced by this WG) tells the RIPE NCC not to implement this (or more precisely to withdraw the service they are already offering) then we simply open the way for private certification companies in the RIPE region.
in which case, i would prefer to arrange a pro-bono one.
So would I. But I can imagine going to my boss and saying "there are two alternatives for securing my address space: a pro-bono, best effort thing run by Randy or a professional one run on a commercial basis by Mega-Certicates Plc. Which would you like me to use?
And why would that be better than having a not-for-profit org like RIPE NCC that we are all a part of as a member, already doing this ? It's not that RIPE NCC is owned by a government or that ROA's or certificates are something that the Dutch government could seize or that an evil government would/could do so (under Dutch law), in order to shutdown the internet or an ISP.. There are far better (more effective) ways of doing so, if you remember what happened in Egypt / Libya etc.. Power down datacenter (y/n) ... Last time I checked, the NCC is operating on behalf of all of us. There are tools to be released in a couple weeks (according to the preso from Alex this afternoon.) that will allow you to run your own CA. If I would speak for myself, I would not trust any random company doing this, except the RIR's and I'm not planning to run my own CA due to the hassle. Until proven otherwise I don't have a reason to think that RIPE NCC isn't capable of providing this service. I'm not saying that you shouldn't run your own setup if you like, but what I am saying is that I don't like that you are trying to stop a working platform that is already working for me and hundreds of LIR's who have been using the system already since Jan 2011. I'm all pro-choice and that also means that I don't like it if someone is taking my choice away ... Erik Bais
On Wed, May 04, 2011 at 05:50:06PM +0200, Erik Bais wrote:
It's not that RIPE NCC is owned by a government or that ROA's or certificates are something that the Dutch government could seize or that an evil government would/could do so (under Dutch law), in order to shutdown the internet or an ISP.. There are far better (more effective) ways of doing so, if you remember what happened in Egypt / Libya etc.. Power down datacenter (y/n) ...
The egyptian ex-government had to ring each SP and tell them to pull their advertisements. At least one of whom (for a while) appears to have told them to go shite. Having a central authority (especially one that's beholden to 20+ governments via the EU) makes that *much* easier.
I'm all pro-choice and that also means that I don't like it if someone is taking my choice away ...
As long as the choice actually exists - in practice. rgds, Sascha Luck
On 04/05/2011 16:57, Sascha Luck wrote:
On Wed, May 04, 2011 at 05:50:06PM +0200, Erik Bais wrote:
It's not that RIPE NCC is owned by a government or that ROA's or certificates are something that the Dutch government could seize or that an evil government would/could do so (under Dutch law), in order to shutdown the internet or an ISP.. There are far better (more effective) ways of doing so, if you remember what happened in Egypt / Libya etc.. Power down datacenter (y/n) ...
The egyptian ex-government had to ring each SP and tell them to pull their advertisements. At least one of whom (for a while) appears to have told them to go shite.
Having a central authority (especially one that's beholden to 20+ governments via the EU) makes that *much* easier.
I really don't think it does. You seem to be imagining a scenario where a national governement would just ring up the NCC and say, "revoke these certs." I have seen no evidence to suggest this risk is anything close to real. I suspect that a for profit global megacorp running such a certification system would be far more vulnerable to such measures, but even then, I don't see this as a large risk. Brian.
Brian, On Wed, May 4, 2011 at 12:24 PM, Brian Nisbet <brian.nisbet@heanet.ie> wrote:
On 04/05/2011 16:57, Sascha Luck wrote:
On Wed, May 04, 2011 at 05:50:06PM +0200, Erik Bais wrote:
It's not that RIPE NCC is owned by a government or that ROA's or certificates are something that the Dutch government could seize or that an evil government would/could do so (under Dutch law), in order to shutdown the internet or an ISP.. There are far better (more effective) ways of doing so, if you remember what happened in Egypt / Libya etc.. Power down datacenter (y/n) ...
The egyptian ex-government had to ring each SP and tell them to pull their advertisements. At least one of whom (for a while) appears to have told them to go shite.
Having a central authority (especially one that's beholden to 20+ governments via the EU) makes that *much* easier.
I really don't think it does. You seem to be imagining a scenario where a national governement would just ring up the NCC and say, "revoke these certs." I have seen no evidence to suggest this risk is anything close to real. I suspect that a for profit global megacorp running such a certification system would be far more vulnerable to such measures, but even then, I don't see this as a large risk.
It's not about "not seeing a risk" as much as it is about _making sure_, in the very design of the system, that it is *not possible* to abuse. Or at the very least extremely hard (global conspiracy kind of hard), to abuse. That would lend a bit more credit to the system. That would mean, of course, that no revocation of any certificate from any single central authority can affect routing on multiple networks. (This list goes on.) The success of deployment RPKI&siblings is inversely proportional to the amount of abuse it makes possible -- I very much would like a much, much different balance than the proposals as they are. As David suggests, much if not all of this can already be achieved using RPSL - save BGP integration... Kind Regards, Martin
On May 4, 2011, at 1:45 PM, Martin Millnert wrote:
It's not about "not seeing a risk" as much as it is about _making sure_, in the very design of the system, that it is *not possible* to abuse. Or at the very least extremely hard (global conspiracy kind of hard), to abuse.
That would lend a bit more credit to the system.
That would mean, of course, that no revocation of any certificate from any single central authority can affect routing on multiple networks.
Martin - Given the validation that some operators already perform based on information in RIPE Database (including whois and rpsl), doesn't the same potential for network disruption due to misplaced governmental action exist today? I am trying to discern if your concern is regarding the theoretical existence of such risks, or the specifically the addition of RPKI because your view it as a more accessible mechanism for abuse? Thanks! /John
On Wed, May 4, 2011 at 2:10 PM, John Curran <jcurran@arin.net> wrote:
Martin -
Given the validation that some operators already perform based on information in RIPE Database (including whois and rpsl), doesn't the same potential for network disruption due to misplaced governmental action exist today?
I am trying to discern if your concern is regarding the theoretical existence of such risks, or the specifically the addition of RPKI because your view it as a more accessible mechanism for abuse?
Thanks! /John
Hi John, I'm concerned of a proliferation of a hierarchical routing policy structure on the Internet. I believe the RPKI scheme runs a much greater risk of proliferation than traditional RPSL, and this concerns me greatly. At the same time, I think the data already existing in for example RIPE's whois database and present technology is sufficient for the validation of customer and peer route announcements. However, I would much prefer if the power to change the holder of a prefix by design stayed with the current holder of the prefix only. This means of course that there would be no method to enforce a change of status externally. This of course becomes a bit problematic since it depends on the definition of what is a holder of a prefix. A good solution, I believe, to this question lies not in an external party declaring who's the holder or not of a prefix, but the holder of the prefix itself. In the case of the current RIR model, the RIR would transfer the rights of a prefix (by some cryptologic solution, I imagine) to the holder-now-owner of the prefix. An analogy: I pick up a very unique stone from a beach full of very individually unique stones -- I am the holder of this stone, not some other stone, and nobody else holds this stone but me. Or, I trade to myself a stone from another party, in a place where there are no unclaimed stones to be found. Only by holding a stone you have the power to speak. Nobody is able to say, certainly not prove, that I do not have the stone, that I have. Following the analogy, no central authority would be able to take my stone away from me - that would be theft. Also, no central authority is able to take the power to speak away from individuals in a room full of stone-holding people. Similarly, my peer's decision in determining whether or not I am the holder of a resource, and their decision of whether or not they accept my route announcement of said resource (or others) are *separate* issues. Acceptance of my origin route announcements, to me, seems like a decision that can be based on a number of factors, where the fact that I am the holder of the resource is one of them. A direct peer may have more reasons to accept my origin routes or not, such as whether or not I have paid my bill, and more. Another factor in accepting a route from a peer, origin or not, may be the path a route takes: Imagine the AS path contains "_64512 64513_", and for any number of reasons this specific AS hop (perhaps specific to the prefix itself, as well) becomes unfavorable to send your traffic over. It's imaginable that some kind of voting system can exist for AS paths, in addition to origin announcements (fool-proof proof of ownership could suffice here). Similarly, a voting system for AS:es themselves could exist. All this information (and more) could be used by a network to construct a multi-source based policy on what routes to accept, key being that it is the network that makes the decision itself, same as today, but with some key differences as well. Something along the lines of what I described above seems like the natural approach to this issue, to me. Many subsystems of what I mention have already been employed on the Internet to service various needs, and some of the ideas have similarities with RPKI/SIDR. And some of the things I mention are a bit different from what we do today. But an important point is that we *can* manage a system without central points of authority, which is highly desirable and preferable. Thanks, Kind Regards, Martin
On May 4, 2011, at 5:33 PM, Martin Millnert wrote:
At the same time, I think the data already existing in for example RIPE's whois database and present technology is sufficient for the validation of customer and peer route announcements.
It's likely that many feel that way, but there appears that there are also folks who wish to have an additional form of validation via RPKI.
A good solution, I believe, to this question lies not in an external party declaring who's the holder or not of a prefix, but the holder of the prefix itself.
Are you saying that those who wish to make use of RPKI should not be able to, even if that's their choice of technology and yours is a more "multi-source peer based policy" choice?
Following the analogy, no central authority would be able to take my stone away from me - that would be theft. Also, no central authority is able to take the power to speak away from individuals in a room full of stone-holding people.
... but apparently *would* be able to specify that no one may use RPKI even if that is someone else's particular preferred technology for securing their own stones? A statement that an RIR shall not support RPKI for the resources in its database is equivalent to deciding "no" on behalf those who want to make use of the optional service, correct? I understand concerns regarding cost or risk for an RIR considering RPKI (and in the ARIN region these are presently actively under consideration) and questions about return on investment also seem reasonable (since you can't support everything, and need to make sure you prioritize to services that will be actively used by the community), but this is first time I've heard an argument to the effect that simply offering the RPKI service will harm those not using it, and I really want to understand since that's not likely to be an effect specific to any one region. Thanks! /John
Hi John, On Wed, May 4, 2011 at 5:58 PM, John Curran <jcurran@arin.net> wrote:
On May 4, 2011, at 5:33 PM, Martin Millnert wrote:
At the same time, I think the data already existing in for example RIPE's whois database and present technology is sufficient for the validation of customer and peer route announcements.
It's likely that many feel that way, but there appears that there are also folks who wish to have an additional form of validation via RPKI.
That is fine, modulo the implementation of RPKI.
A good solution, I believe, to this question lies not in an external party declaring who's the holder or not of a prefix, but the holder of the prefix itself.
Are you saying that those who wish to make use of RPKI should not be able to, even if that's their choice of technology and yours is a more "multi-source peer based policy" choice?
If the proposal involves a central point of authority with the ability to revoke resources from a holder, or otherwise change, I do not wish this system implemented, no. Especially not if the central authority is a RIR, in this case RIPE. More on why below.
Following the analogy, no central authority would be able to take my stone away from me - that would be theft. Also, no central authority is able to take the power to speak away from individuals in a room full of stone-holding people.
... but apparently *would* be able to specify that no one may use RPKI even if that is someone else's particular preferred technology for securing their own stones?
No, that's not correct. One can not know, but one can imagine that a successful resource registry would be one where *only* the resource owner itself has the rights to register or de-register its resources. This is key, as is the resource-owning concept in this model -- there is no database which can be rewritten, somehow magically taking away someone's stone.
A statement that an RIR shall not support RPKI for the resources in its database is equivalent to deciding "no" on behalf those who want to make use of the optional service, correct?
Yeah, that seems correct.
I understand concerns regarding cost or risk for an RIR considering RPKI (and in the ARIN region these are presently actively under consideration) and questions about return on investment also seem reasonable (since you can't support everything, and need to make sure you prioritize to services that will be actively used by the community),
These are aspects I myself do not consider nearly as important as the greater Internet architecture aspect of these services.
but this is first time I've heard an argument to the effect that simply offering the RPKI service will harm those not using it, and I really want to understand since that's not likely to be an effect specific to any one region.
Right. The proliferation of any system which uses single authorities (the RIR:s databases) to form routing decisions exposes itself for abuse, more so the more it is proliferated. All it does is require a change of the database for the abuse to occur, obviously, which very likely would affect not only the users who have chosen to opt-in to this system, but also those who have not. It's already been said that in order to get the desired use out RPKI in terms of preventing youtube hijacking, a network is required to configure its RPKI-policies strictly. Thus, an abuse of the network's CA will then also possibly affect peers of this network, who may themselves not use RPKI for any number of reasons. If RPKI proliferates significantly, to the point where carriers start requiring signed resources from their customers, the abuse exposure of the single CA increases much, much more. I claim that the abuse risk exposure grows with the number of networks its removal or change of a resource can affect. (Not only revocation is a concern, but rewrite-to-other, for example, as well) Kind Regards, Martin
On May 4, 2011, at 6:40 PM, Martin Millnert wrote:
It's already been said that in order to get the desired use out RPKI in terms of preventing youtube hijacking, a network is required to configure its RPKI-policies strictly.
Thus, an abuse of the network's CA will then also possibly affect peers of this network, who may themselves not use RPKI for any number of reasons.
I understand how it would impact the network which has decided to make use of strict RPKI-based route validation (and therefore the network's customers by extension), but can you explain how it would otherwise effect that network's peers? If a network decides to use any specific technology as the basis of its routing architecture (e.g. route reflectors, an out of band ATM network, etc.) and that technology then fails, is compromised or abused, then the network's peers will be impacted in a very similar manner. I am again left trying to understand how the use of RPKI technology for route assurance affects the networks of those who don't use it (other than in the normal manner that all the routing technology is relied on) Thanks! /John
On May 4, 2011, at 4:19 PM, John Curran wrote:
I am again left trying to understand how the use of RPKI technology for route assurance affects the networks of those who don't use it (other than in the normal manner that all the routing technology is relied on)
This sounds suspiciously like you are saying the goal of RPKI is for it not to be used. Regards, -drc
Hi John, On Wed, May 4, 2011 at 7:19 PM, John Curran <jcurran@arin.net> wrote:
On May 4, 2011, at 6:40 PM, Martin Millnert wrote:
It's already been said that in order to get the desired use out RPKI in terms of preventing youtube hijacking, a network is required to configure its RPKI-policies strictly.
Thus, an abuse of the network's CA will then also possibly affect peers of this network, who may themselves not use RPKI for any number of reasons.
I understand how it would impact the network which has decided to make use of strict RPKI-based route validation (and therefore the network's customers by extension), but can you explain how it would otherwise effect that network's peers?
I'm glad you understand there is a risk an abuse of "RPKI" can have significant effects on the internet, since no doubt you are aware of "Tier 1" internet transit providers. I used the term "peer" in the general meaning, not applying any special significance to what kind of route or monetary exchange occurs using it.
I am again left trying to understand how the use of RPKI technology for route assurance affects the networks of those who don't use it (other than in the normal manner that all the routing technology is relied on)
Nonetheless, I can illustrate it realistically for you, in an example using clear present-day industry terms: Network A is a transit customer of tier-1 network B. Network C and D are transit customers of tier-1 network E. Network C is exchanging full table with A, without any monetary exchange. Network B and E are exchanging full table with each other, also without any monetary exchange (they are tier-1). Network D announces prefix 1 to E. Transit provider E, being a very large company, has after some government pressure decided to enable strict RPKI filtering because of some tax breaks it received for doing so. It did not wish to enable it otherwise, because of some strong internal voices. But money speaks. Network E's CA is called Z. Prefix 1 is now suddenly removed from Z, after pressure on Z from unidentified entity X. Network E consequently ceases to forward prefix 1 to their non-paying peer network, B, and their other customer C. As a result, A, B, C, E all now have no way to reach D's prefix 1: this internet has now been partitioned, by unidentified entity X. Only a single network, E, implemented strict filtering of RPKI, yet A, not being a customer of E, lost access to 1, and all involved hardware is still functional. Unidentified entity X did not have to communicate with E at all. Kind Regards, Martin
On May 4, 2011, at 8:48 PM, Martin Millnert wrote:
... Network C and D are transit customers of tier-1 network E. ... Network D announces prefix 1 to E.
Transit provider E, being a very large company, has after some government pressure decided to enable strict RPKI filtering ... Only a single network, E, implemented strict filtering of RPKI, yet A, not being a customer of E, lost access to 1, and all involved hardware is still functional.
Prefix 1 is for customer D (of network E); ergo, A lost access to D because D's choice of service provider. D voluntarily choose its service provider, and can always choose another. There is no party that was impacted without a choice; D choose A because of their much discussed "route assurance" technology, and that turned out (in your example) to be a bad choice. Another example might have it be a wise choice, but there's still no one impacted who didn't get any choice. How is this different than network D deciding to build a network with with an innovative routing technology, which may serve to distinguish it in a positive (or negative) manner based on actual performance? Back to my original question: "I understand how it would impact the network which has decided to make use of strict RPKI-based route validation (and therefore the network's customers by extension), but can you explain how it would otherwise effect that network's peers?" Thanks, /John
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/05/2011 10:50, John Curran wrote:
How is this different than network D deciding to build a network with with an innovative routing technology, which may serve to distinguish it in a positive (or negative) manner based on actual performance?
This is different because it introduces a new party into the equation, X, who wants to impede reachability rather than improve it, and because X has legal power to supersede E's choices and override their self-interest. In your example, A is affected by the consequences of E trying to build a better network. Maybe E gets it wrong, and A suffers as a result too, but at least E is trying to do better and is likely to correct their behaviour or will gradually decline in influence. In Martin's example A is also affected by the consequences of X forcing E to reduce the connectivity of their network. E no longer has a choice, so he cannot "correct" his behaviour. Nor will E be easily superseded by competitor networks, because all his competitors are also subject to X. This could of course happen now - and I spend a large chunk of my time working to avoid this. In my view, handing X on a plate a mechanism to direct many Es all at once will greatly increase X's propensity to intervene. Political/legal control does make a qualitative difference. - -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | http://publicaffairs.linx.net/ London Internet Exchange Ltd Maya House, 134-138 Borough High Street, London SE1 1LB Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3CdvkACgkQJiK3ugcyKhSjswCff7AGd+KvBUXZASJCK/qMmq6e jM8An0JvaSVih6nIGIp1Cf5F88rsOXna =VTdq -----END PGP SIGNATURE-----
Hi John, On Thu, May 5, 2011 at 5:50 AM, John Curran <jcurran@arin.net> wrote:
On May 4, 2011, at 8:48 PM, Martin Millnert wrote:
... Network C and D are transit customers of tier-1 network E. ... Network D announces prefix 1 to E.
Transit provider E, being a very large company, has after some government pressure decided to enable strict RPKI filtering ... Only a single network, E, implemented strict filtering of RPKI, yet A, not being a customer of E, lost access to 1, and all involved hardware is still functional.
Prefix 1 is for customer D (of network E); ergo, A lost access to D because D's choice of service provider. D voluntarily choose its service provider, and can always choose another.
Can it always choose one which is not using this new "route assurance technology"?
There is no party that was impacted without a choice; D choose A because of their much discussed "route assurance" technology, and that turned out (in your example) to be a bad choice. Another example might have it be a wise choice, but there's still no one impacted who didn't get any choice.
How is this different than network D deciding to build a network with with an innovative routing technology, which may serve to distinguish it in a positive (or negative) manner based on actual performance?
Are you suggesting that the more ways we have to break the internet, the better? You would probably argue that RPKI can improve performance by removing intentional and un-intentional route hijacking. But to this I must ask: Can we quantify how often this happen? It would be a very useful data point going forward. We could also quantify how many jurisdictions have some form of internet filtering legislation in place today. And take a look at what's in the legal pipeline. A well known block list (the existence of it, not its content) was tested at one point: 98% false-positives. (the remaining 2% was permanently fixed via simple email, and a ~3h response time...) Using this metric as the track record for gov internet filtering, and extending it to our discussion, mistakes will frequently happen, and the entire endeavor is flawed to its very bones. But this is not the debate of the specifics of the legal processes in various jurisdictions, I'm merely showing (and #include Malcom's posts) a real big risk of having a larger stream of failures coming from the abuse of a highly proliferated RPKI than the failures it was designed to fix. As Sascha put it earlier in the discussion: "the cure is infinitely worse than the disease" Key in my example is otherwise what was not written out: If you scale the example up, and use of RPKI with strict filtering has proliferated, X has a good vector to negatively and widely affect internet routing via Z, which is a completely new thing on the Internet from today.
Back to my original question: "I understand how it would impact the network which has decided to make use of strict RPKI-based route validation (and therefore the network's customers by extension), but can you explain how it would otherwise effect that network's peers?"
I thought I did explain this in my example: B lost access to D, B *is a peer* of E, who uses strict RPKI-based route validation. This is a technicality in the bigger scheme as described above and by Malcom, however. Kind Regards, Martin
On Wed, May 04, 2011 at 09:58:18PM +0000, John Curran wrote:
... but apparently *would* be able to specify that no one may use RPKI even if that is someone else's particular preferred technology for securing their own stones? A statement that an RIR shall not support RPKI for the resources in its database is equivalent to deciding "no" on behalf those who want to make use of the optional service, correct?
1) If RPKI *is* universally used, there is no choice for those who do not wish the RIRs to be the final arbiters of their ability to speak on the internet. 2) If RPKI *is not* universally used, it doesn't increase security and is therefore a lot of administration effort to absolutely no purpose. 3) Self-signed certificates are most likely a strawman insofar as if an upstream/IXP demands the use of a RIR-signed certificate "for sound security reasons", your self-signed cert isn't worth the paper it's most likely not printed on. 4) What do the holders of legacy space who may not care to enter into a "contractual relationship" with a RIR do? rgds, Sascha
4) What do the holders of legacy space who may not care to enter into a "contractual relationship" with a RIR do?
i try to secure routing as best i can randy
It's not about "not seeing a risk" as much as it is about _making sure_, in the very design of the system, that it is *not possible* to abuse.
after all, we have been so successful with this approach in so many other aspects of the internet technology. </sarcasm> shall we have a policy that covers black helicopters and sci-fi attacks as well as demanding perfection in everything? randy
On Thu, 5 May 2011, Randy Bush wrote:
shall we have a policy that covers black helicopters and sci-fi attacks as well as demanding perfection in everything?
No. Right now it's a bigger problem that people can announce other peoples address space (intentionally or not), so let's get that fixed. Put in a recommendation in the implementation descriptions that there should be the possibility of local policies for whitelisting, meaning it doesn't rely on the central authority for some resources, or we could have parallell authorities in multiple juristictions. -- Mikael Abrahamsson email: swmike@swm.pp.se
shall we have a policy that covers black helicopters and sci-fi attacks as well as demanding perfection in everything? No.
:)
Right now it's a bigger problem that people can announce other peoples address space (intentionally or not), so let's get that fixed.
trying
Put in a recommendation in the implementation descriptions that there should be the possibility of local policies for whitelisting, meaning it doesn't rely on the central authority for some resources, or we could have parallell authorities in multiple juristictions.
i do appreciate contributions to draft-ietf-sidr-origin-ops randy
On 5 May 2011, at 10:04, Randy Bush wrote:
shall we have a policy that covers black helicopters and sci-fi attacks as well as demanding perfection in everything? No.
:)
Right now it's a bigger problem that people can announce other peoples address space (intentionally or not), so let's get that fixed.
trying
Put in a recommendation in the implementation descriptions that there should be the possibility of local policies for whitelisting, meaning it doesn't rely on the central authority for some resources, or we could have parallell authorities in multiple juristictions.
i do appreciate contributions to draft-ietf-sidr-origin-ops
Good point, because the implementation that the RIRs are making is based on the work that is being done here. Some elements of Certification that people are discussing here should actually be held in the IETF SIDR WG. Some of the concerns have actually already been taken into account there. In a nutshell: My take is that Resource Certification drives routing *preferences*. If a network operator sees an expired or invalid prefix, they can investigate and *choose* to take action. This also applies to decisions when using router hardware, as described in section 5 of "BGP Prefix Origin Validation": http://tools.ietf.org/html/draft-ietf-sidr-pfx-validate-01#section-5 "Considering invalid routes for BGP decision process is a pure ***local policy matter*** and should be done with utmost care." (Emphasis mine) -Alex
Alex, On Thu, May 5, 2011 at 4:19 AM, Alex Band <alexb@ripe.net> wrote:
In a nutshell: My take is that Resource Certification drives routing *preferences*. If a network operator sees an expired or invalid prefix, they can investigate and *choose* to take action. This also applies to decisions when using router hardware, as described in section 5 of "BGP Prefix Origin Validation": http://tools.ietf.org/html/draft-ietf-sidr-pfx-validate-01#section-5
"Considering invalid routes for BGP decision process is a pure ***local policy matter*** and should be done with utmost care." (Emphasis mine)
I am hoping you can give some practical examples on how one goes about considering routes invalid with utmost care. Kind Regards, Martin
Hi, On Thu, May 05, 2011 at 05:11:33AM -0400, Martin Millnert wrote:
"Considering invalid routes for BGP decision process is a pure ***local policy matter*** and should be done with utmost care." (Emphasis mine)
I am hoping you can give some practical examples on how one goes about considering routes invalid with utmost care.
You could, for example, adjust routing preference in accordance to the availability of an RPKI signature - prefer routes with a valid RPKI ROA - if no routes with a valid ROA can be found, consider routes with no ROA (neither matching nor invalid) - if no such routes can be found, accept any route, even if the ROA lists a wrong origin AS Randy has demonstrated in the workshop on last Monday morning how to do that in IOS. The implementation is such that the BGP engine doesn't *care* about the validity of a route/ROA, it will just mark the prefix with the result of the validation check - and then you can use the normal local policy language to influence your policy with that result. One *choice* could be "drop all routes that have a ROA mismatch" - or, as outlined above "accept everything, but only use those routes as last-resort". Local policy decision. The workshop was very enlightening, to actually see how the pieces fit together and how local policy is applied to the data coming from the (various) RPKI data stores. Gert Doering -- APWG chair -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
On 9 May 2011 14:02, Gert Doering <gert@space.net> wrote:
Hi,
On Thu, May 05, 2011 at 05:11:33AM -0400, Martin Millnert wrote:
"Considering invalid routes for BGP decision process is a pure ***local policy matter*** and should be done with utmost care." (Emphasis mine)
I am hoping you can give some practical examples on how one goes about considering routes invalid with utmost care.
You could, for example, adjust routing preference in accordance to the availability of an RPKI signature
Yes, this is a good use for RPKI from a technical PoV it means that those routes that are signed are given a better chance of attracting the traffic... ... but some would say that splitting your networking to /24 for traffic management purposes is good from a technical PoV. I like the idea of the contents of the DB being signed so people can check the accuracy (and validity) of the contents - what I don't like is the move to an automated on router solution that checks for validity on the fly (and that seems to be where people want this to go) because that leads to a system where someone controlling the source of the data can then influence my routing decisions. Maybe its the fact that RIPE are providing the full solution as well as the ability to publish the information thats the issue, if rather than the NCC creating a tool for validation it just published the keys and the software tools for people to do the validation themselves then I might be happier. J -- James Blessing 07989 039 476
Hi James,
Maybe its the fact that RIPE are providing the full solution as well as the ability to publish the information thats the issue, if rather than the NCC creating a tool for validation it just published the keys and the software tools for people to do the validation themselves then I might be happier.
Euhm. The NCC *are* publishing the tools to do the validation on your own system. The certificates are currently created and managed in a hosted environment on an NCC server. Once the Up/Down implementation is finished you can also host this part on your own server if you don't want all the private keys to be on an NCC server. Then you install your own validation/cache software on your own server that checks the certificates, and your routers pull their information from that cache. Then the route maps on the router determine what is done with that information. I think that Malcolm is afraid that governments will force ISPs to do this validation and route-mapping in a certain way that takes away freedom-of-choice about what to route and what not to route. Malcolm: please correct me if I am wrong. Sander
Hi, On Mon, May 09, 2011 at 02:24:15PM +0100, boggits wrote:
Maybe its the fact that RIPE are providing the full solution as well as the ability to publish the information thats the issue, if rather than the NCC creating a tool for validation it just published the keys and the software tools for people to do the validation themselves then I might be happier.
Uh. As far as I understand, the validation is always done by your local setup, and various software options(!) exist for that. The NCC provides a trusted data store where it signs which IP resources belong to what certificate (not "entity"). Based on that, the network holder can sign a ROA "I authorize this AS to announce my network" (and of course that would not be overly useful without some who has that authority to actually attest that "my" bit there). That ROA would currently be stored in the RIPE database, but it could be stored anywhere, with a pointer in your certificate "look *there* for my ROAs". Then whoever is interested runs a software that collects the various bits and pieces from whever they are stored - guided by referrals, or (again!) by local policy - "this guys I trust, their networks I always grab from *that* store, authenticated by *this* trust anchor". One such solution is Randy's RCynic, another one would be what BBN (Steve Kent) has developed, and a third one would be the RIPE NCC validator. Google sends me to these links for a list of RPKI validation tools and their interop tests: http://www.ietf.org/proceedings/80/slides/sidr-12.pdf http://www.ietf.org/proceedings/80/slides/sidr-10.pdf This stuff then generates a list of <network|AS> pairs from the data, and sends it to your routers - no crypto involved on the routers, no 10000-lines-prefixlists for peer validation, very lightweight operation - where it is then used for policy decisions. Gert Doering -- Address Policy WG -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Gert, thank you for answering this question. On Mon, May 9, 2011 at 9:02 AM, Gert Doering <gert@space.net> wrote:
Hi,
On Thu, May 05, 2011 at 05:11:33AM -0400, Martin Millnert wrote:
"Considering invalid routes for BGP decision process is a pure ***local policy matter*** and should be done with utmost care." (Emphasis mine)
I am hoping you can give some practical examples on how one goes about considering routes invalid with utmost care.
You could, for example, adjust routing preference in accordance to the availability of an RPKI signature
- prefer routes with a valid RPKI ROA
- if no routes with a valid ROA can be found, consider routes with no ROA (neither matching nor invalid)
- if no such routes can be found, accept any route, even if the ROA lists a wrong origin AS
So if some random LEA convinces the RIPE NCC (via means of legislation already under way according to Malcolm (transfer resources to LEA), or some $lawyer-soup not foreseen today), the abuser could, with the intent of a DDoS of the overtaken resources, start announcing routes of a valid RPKI ROA, and this way steal traffic from anyone implementing at a minimum the above policy. The DDoS is successful and RPKI just censored a network off the Internet from those who implement at a minimum the above policy, which is the minimum you have to, else RPKI is pointless. In other words: influencing route preference from a single point of authority remains an abuse-vector. The only way to completely negate this abuse vector from the relying party's side is to not implement any policy based on any RPKI information. This is obvious since the reverse side of the coin, securing routing, requires automatic policy handling (else why develop RPKI?). Assuming large carriers are compliant to LEAs under nearly all circumstances, this remains a threatening scenario. It clearly suggests that great, great care must go into the choice of sources for the RPKI information. And having just one origin source of data, RIPE's database, should there not be some process of peer-review* before any revocation or re-assignment can go into effect? Not just of resource certifications, but resources over all? Should there not be a public, easily accessible log providing transparency and insight into the motivations of why these changes are done? (*By peer-review I mean per-event-peer review, performed by normal citizens, via more or less direct influence.) In response to a call on the APWG session last Friday to the critics of RPKI to "help out, propose solutions": My preferred way of securing routing relies on heavy decentralization, which by necessity must include that of the RIR's registry function since this is an apparent single point of failure. The most obvious way to me right now to go about this is to transform todays resource allocations to resource ownerships, which can pave the way for a truly decentralized registry function. I'm not convinced that a single point of failure is the most natural way to organize internet uniqueness as we go forward, and I'm not alone in identifying RIR's motivation for RPKI as a way for them to establish ownership of the Internet and secure their future business, and recognize that community opinion on whether this is good or bad differs. I think it is helpful to discuss this in more depth. The future is anything but certain in this area: in particular, it is going to be interesting to see what happens with regards to egistry accuracy and relevance once legacy resources starts to be traded without any RIR involvement. With this I'm passing the ball: I'd appreciate to see more cycles spent on considering plausible recovery-protocols once the first abuse is a fact, in the one-trust-anchor model. There goal ought to be an abuse-resistant system, and in this it must be assumed the RIPE NCC, or any other single trust anchor, will not be able to withstand the abuse previously discussed. A measure of an abuse-resistant system is, obviously, one where an abuse, a DDoS, fails. The bar must be set a bit higher. Going down this route still discomforts me greatly since an absolutely foreseeable problem/flaw is knowingly being designed into the system from scratch. A backup registry (of the RIPE NCC in case it goes bad) was mentioned in the APWG session last Friday. Why stop with 1? Why not 1000s of them, or, say, 1 per ASN? To me it is now clear (since a recent epiphany :) ) that the underlying internet infrastructure wants a distributed registry and I don't think this desire is about to go away as IPv4 starts to be traded, quite the contrary.
Randy has demonstrated in the workshop on last Monday morning how to do that in IOS. The implementation is such that the BGP engine doesn't *care* about the validity of a route/ROA, it will just mark the prefix with the result of the validation check - and then you can use the normal local policy language to influence your policy with that result.
One *choice* could be "drop all routes that have a ROA mismatch" - or, as outlined above "accept everything, but only use those routes as last-resort". Local policy decision.
See above.
The workshop was very enlightening, to actually see how the pieces fit together and how local policy is applied to the data coming from the (various) RPKI data stores.
Can the software handle multiple (not 2, not 3, but n) competing trust anchors, possibly assign weights to them and compare matching resources and produce a resulting set of non-conflicting resources, another set with conflicting resources / odd-cases? Seems called for to answer the above discussion, to me, at least. Kind Regards, Martin
You could, for example, adjust routing preference in accordance to the availability of an RPKI signature
- prefer routes with a valid RPKI ROA
- if no routes with a valid ROA can be found, consider routes with no ROA (neither matching nor invalid)
- if no such routes can be found, accept any route, even if the ROA lists a wrong origin AS
from draft-ietf-sidr-origin-ops-07 Announcements with Valid origins SHOULD be preferred over those with NotFound or Invalid origins, if the latter are accepted at all. Announcements with NotFound origins SHOULD be preferred over those with Invalid origins. Announcements with Invalid origins MAY be used, but SHOULD be less preferred than those with Valid or NotFound. randy
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/05/2011 08:36, Randy Bush wrote:
shall we have a policy that covers black helicopters and sci-fi attacks as well as demanding perfection in everything?
Black helicopters in slides presentations are amusing. But if you seriously think the governments, law enforcement and private litigants won't see this as a new capability to prevent traffic to certain networks you haven't (note to self: be polite, Malcolm) all the facts. Fact 1. In the Co-operation WG where British law enforcement officials have /already/ been asking for procedures to re-assign netblocks to their agency because they think that would help prevent traffic flowing to places where crimes occur. Of course, as a community we could refuse to cooperate, unless/until the NCC is compelled. Nonetheless, this demonstrates LEAs do have both the awareness and the intent; it's not a wild conspiracy theory. Fact 2. There is draft legislation ALREADY going through the EU that if passed would require all EU governments (including the Dutch) to introduce laws to "take the necessary measures to obtain the blocking of access" to certain Internet locations [1]. It could be argued that this would give Dutch LEAs sufficient power to require the RIPE NCC to revoke a certificate - or perhaps not; it probably depends on how the Netherlands chooses to implement this European law if/when it goes through. I would say that this shows that the risk, although not certain, is pressing and immediate, not a vague worry for the distant future. Fact 3. There is continuous lobbying within the EU, to which Dutch law is subject, for greater measures to require Internet intermediaries to prevent the reachability of certain Internet locations. This has mainly focussed on network operators, but more recently EU officials have opened dialogue with ccTLD registries and the RIPE NCC too. There's no end of topics for which some people believe controlling access to Internet locations would be a useful means of fighting some social evil - child pornography and copyright infringement have in my estimation the largest and most organised lobbying in favour of such measures, but there's also active work in the areas of terrorism, "cybercrime" generally, gambling, xenophobia racism and hate-speech, just off the top of my head. In my view the range of actors who would seek to use any new capability is wide, and they are outside our control as a technical community. They operate at the political level, and they have no interest in the technical community's opinions, apart from an answer to the question "What is it technically possible for the RIPE NCC to do to impede reachability to the locations we specify?" Once the RIPE NCC comes to be seen as a "gateway controller" that can significantly impact the reachability of "bad" networks, it will irrevocably become a ongoing target for use as a tool of public policy enforcement. Malcolm [1] I'm referring to Article 21 of the Draft Directive on Child Sexual Exploitation, which is currently in Trialogue negotiations between the European Parliament, Commission, and Council of Ministers. http://bit.ly/9D5cg8 - -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | http://publicaffairs.linx.net/ London Internet Exchange Ltd Maya House, 134-138 Borough High Street, London SE1 1LB Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3CcEIACgkQJiK3ugcyKhQ1TACfW/MetiGeGRB7/vg+59K3JjVS OmsAni1rVleSySJbJ8ZFlviv+tiqTkdL =eYwd -----END PGP SIGNATURE-----
On May 5, 2011, at 5:39 AM, Malcolm Hutty wrote:
... Once the RIPE NCC comes to be seen as a "gateway controller" that can significantly impact the reachability of "bad" networks, it will irrevocably become a ongoing target for use as a tool of public policy enforcement.
Malcolm - Is the existing RIPE Database (both as address and routing registry) seen or not seen as a "gateway controller" per above? I think it would be helpful to the point to outline why the current system has not been an ongoing target, and why one based on RPKI will irrevocably become one. Thanks! /John
On Thu, 5 May 2011, John Curran wrote:
Is the existing RIPE Database (both as address and routing registry) seen or not seen as a "gateway controller" per above?
Not. Right now there is a very low coupling between the contents of the RIPE database and what is actually allowed for routing on the Internet, very few operators actually use RPSL or alike to create filters, thus whatever is in the RIPE database doesn't have an immediate short term operational impact. With a tighter coupling between RIPE database contents and Internet Routing, this changes. -- Mikael Abrahamsson email: swmike@swm.pp.se
Malcolm, There was an IGF workshop in Vilnius last year "Routing and Resource Certification: Self-governance and security at the core of Internet operations" (http://www.intgovforum.org/cms/component/content/article/102-transcripts2010...) I found Paul Vixie's remark he made there very useful in articulating the trade-offs we are facing here. He said: "I'd like to move from the situation we're in now, where the good guys have no recourse against the bad guys, to a new situation where the good guys will have some recourse against other good guys if these powers are misused, and that is the choice I'd rather see discussed [...]" Andrei Malcolm Hutty wrote on 5/5/11 11:39 :
On 05/05/2011 08:36, Randy Bush wrote:
shall we have a policy that covers black helicopters and sci-fi attacks as well as demanding perfection in everything?
Black helicopters in slides presentations are amusing. But if you seriously think the governments, law enforcement and private litigants won't see this as a new capability to prevent traffic to certain networks you haven't (note to self: be polite, Malcolm) all the facts.
Fact 1. In the Co-operation WG where British law enforcement officials have /already/ been asking for procedures to re-assign netblocks to their agency because they think that would help prevent traffic flowing to places where crimes occur. Of course, as a community we could refuse to cooperate, unless/until the NCC is compelled.
Nonetheless, this demonstrates LEAs do have both the awareness and the intent; it's not a wild conspiracy theory.
Fact 2. There is draft legislation ALREADY going through the EU that if passed would require all EU governments (including the Dutch) to introduce laws to "take the necessary measures to obtain the blocking of access" to certain Internet locations [1]. It could be argued that this would give Dutch LEAs sufficient power to require the RIPE NCC to revoke a certificate - or perhaps not; it probably depends on how the Netherlands chooses to implement this European law if/when it goes through.
I would say that this shows that the risk, although not certain, is pressing and immediate, not a vague worry for the distant future.
Fact 3. There is continuous lobbying within the EU, to which Dutch law is subject, for greater measures to require Internet intermediaries to prevent the reachability of certain Internet locations. This has mainly focussed on network operators, but more recently EU officials have opened dialogue with ccTLD registries and the RIPE NCC too.
There's no end of topics for which some people believe controlling access to Internet locations would be a useful means of fighting some social evil - child pornography and copyright infringement have in my estimation the largest and most organised lobbying in favour of such measures, but there's also active work in the areas of terrorism, "cybercrime" generally, gambling, xenophobia racism and hate-speech, just off the top of my head.
In my view the range of actors who would seek to use any new capability is wide, and they are outside our control as a technical community. They operate at the political level, and they have no interest in the technical community's opinions, apart from an answer to the question "What is it technically possible for the RIPE NCC to do to impede reachability to the locations we specify?"
Once the RIPE NCC comes to be seen as a "gateway controller" that can significantly impact the reachability of "bad" networks, it will irrevocably become a ongoing target for use as a tool of public policy enforcement.
Malcolm
[1] I'm referring to Article 21 of the Draft Directive on Child Sexual Exploitation, which is currently in Trialogue negotiations between the European Parliament, Commission, and Council of Ministers. http://bit.ly/9D5cg8
On Wed, May 04, 2011 at 05:24:12PM +0100, Brian Nisbet wrote:
I really don't think it does. You seem to be imagining a scenario where a national governement would just ring up the NCC and say, "revoke these certs." I have seen no evidence to suggest this risk is anything close to real.
This has already happened, not a week ago the DHS (who else?) seized the domains of various online poker sites. TTBOMK similar has happened in the EU as well. I even seem to remember some organisation calling for RIPE to de-register certain resources. (Possibly the NCC care to enlighten us as to whether anything came of that?)
I suspect that a for profit global megacorp running such a certification system would be far more vulnerable to such measures, but even then, I don't see this as a large risk.
Absolutely. Wikileaks <> Visa, Mastercard, Paypal, Verisign, &c? I think that is a *very* large risk indeed and I'd never propose to host the central authority for my routing to $private_corp either. Unless there are a lot of them, preferably in a lot of different countries... rgds, Sascha
On 4 May 2011, at 17:24, Brian Nisbet wrote:
You seem to be imagining a scenario where a national governement would just ring up the NCC and say, "revoke these certs." I have seen no evidence to suggest this risk is anything close to real.
I suppose this depends on the definition of "real" and "evidence" Brian. If the NCC gets told to revoke a cert -- eg via a Dutch court order or equivalent -- it will have to do that. It would be sensible to assume that well-funded and/or litigious organisations might well be minded to pursue that avenue if they think getting a cert revoked will either disrupt or shut down some activities they dislike. Or bury their opponents in legal costs before it gets to the point where a court order gets issued. Certificates for routing will provide another vector for these sorts of layer-9 and up attacks. IMO it's foolish to assume or pretend otherwise. There are parallels with existing "control" mechanisms that governments and others use to restrict access to illegal content (for some definition of illegal content). If another control mechanism is made available, it will be used: that's the nature of the beast. [In this context RPKI has that control property as a side-effect.] Assuming that it won't or suggesting there's no real risk is just not credible, sorry. And from a practical perspective, is there really a material difference between a blacklist of naughty IP address blocks (commonly used today) and address blocks that have revoked certs (probably commonly used tomorrow) as control mechanisms? Personally, I'm not too fussed by this. The bad guys are not likely to be forming an orderly queue to get their certs from the NCC. And I think/hope the Dutch courts would take a robust view when governments or the Scientologists come looking for a court order. But in the final analysis, I struggle to see how an RPKI cert revocation would be any different from adding a prefix to the "official" blacklist that ISPs are encouraged to implement today. PS: Apologies for changing the Subject: header to something meaningful.
On 4 May 2011, at 17:24, Brian Nisbet wrote:
You seem to be imagining a scenario where a national governement would just ring up the NCC and say, "revoke these certs." I have seen no evidence to suggest this risk is anything close to real.
I suppose this depends on the definition of "real" and "evidence" Brian.
If the NCC gets told to revoke a cert -- eg via a Dutch court order or equivalent -- it will have to do that. It would be sensible to assume that well-funded and/or litigious organisations might well be minded to pursue that avenue if they think getting a cert revoked will either disrupt or shut down some activities they dislike. Or bury their opponents in legal costs before it gets to the point where a court order gets issued. Certificates for routing will provide another vector for these sorts of layer-9 and up attacks. IMO it's foolish to assume or pretend otherwise. The question is whether there is some other way of ensuring routing consistency ... But given the current track record of many countries' legislative and legal developments, e.g. "hostage-taking" of domains in
On 05.05.2011 09:45, Jim Reid wrote: the US, internet filters in many European countries, etc., I must concur that the threat to the Internet once RPKI is introduced will be very real ... so, what alternatives can we come up with from a technical standpoint that is not prone to government or legal pressure? -garry
Hi Jim,
Personally, I'm not too fussed by this. The bad guys are not likely to be forming an orderly queue to get their certs from the NCC. And I think/hope the Dutch courts would take a robust view when governments or the Scientologists come looking for a court order. But in the final analysis, I struggle to see how an RPKI cert revocation would be any different from adding a prefix to the "official" blacklist that ISPs are encouraged to implement today.
I have been told that the Dutch law explicitly makes revocation and/or confiscation of 'our type' of certificates impossible, so a law change is necessary it make it possible at all. Not impossible, but it's another hurdle in the path of bad guys. I will try to get a formal statement from a lawyer to confirm this. If for some reason we need to fear intervention from the Dutch government we can look into the suggestion of Mikael about parallel authorities in multiple jurisdictions. And I would like to thank everybody for providing feedback on this proposal. Thank you, Sander Steffann APWG co-chair
On 05/05/2011 08:45, Jim Reid wrote:
On 4 May 2011, at 17:24, Brian Nisbet wrote:
You seem to be imagining a scenario where a national governement would just ring up the NCC and say, "revoke these certs." I have seen no evidence to suggest this risk is anything close to real.
I suppose this depends on the definition of "real" and "evidence" Brian.
If the NCC gets told to revoke a cert -- eg via a Dutch court order or equivalent -- it will have to do that. It would be sensible to assume that well-funded and/or litigious organisations might well be minded to pursue that avenue if they think getting a cert revoked will either disrupt or shut down some activities they dislike. Or bury their opponents in legal costs before it gets to the point where a court order gets issued. Certificates for routing will provide another vector for these sorts of layer-9 and up attacks. IMO it's foolish to assume or pretend otherwise.
My point was not that the cert could not be revoked (although Sander's follow-up post would suggest that might be the case), rather that it would be a long and difficult process. Certainly far, far more difficult than a government picking up the phone and saying "We are in a state of national emergency/rebellion/worried our citizens are learning things, shut down the Internet now." Brian.
On Thu, May 5, 2011 at 4:21 AM, Brian Nisbet <brian.nisbet@heanet.ie> wrote:
On 05/05/2011 08:45, Jim Reid wrote:
On 4 May 2011, at 17:24, Brian Nisbet wrote:
You seem to be imagining a scenario where a national governement would just ring up the NCC and say, "revoke these certs." I have seen no evidence to suggest this risk is anything close to real.
I suppose this depends on the definition of "real" and "evidence" Brian.
If the NCC gets told to revoke a cert -- eg via a Dutch court order or equivalent -- it will have to do that. It would be sensible to assume that well-funded and/or litigious organisations might well be minded to pursue that avenue if they think getting a cert revoked will either disrupt or shut down some activities they dislike. Or bury their opponents in legal costs before it gets to the point where a court order gets issued. Certificates for routing will provide another vector for these sorts of layer-9 and up attacks. IMO it's foolish to assume or pretend otherwise.
My point was not that the cert could not be revoked (although Sander's follow-up post would suggest that might be the case), rather that it would be a long and difficult process. Certainly far, far more difficult than a government picking up the phone and saying "We are in a state of national emergency/rebellion/worried our citizens are learning things, shut down the Internet now."
Simply by having the possibility to revoke certifications or db entries, the RIPE NCC invites gunned madmen, be them from governments or not, to enter their offices and make them make certain unwanted sites/prefixes on the internet disappear. I'd prefer if there was no reason for them to attempt this, since there would be no technical way to do it. Why is revocation of assigned addresses in this manner necessary? Kind Regards, Martin
Jim Reid wrote on 5/5/11 09:45 : [...]
Personally, I'm not too fussed by this. The bad guys are not likely to be forming an orderly queue to get their certs from the NCC. And I think/hope the Dutch courts would take a robust view when governments or the Scientologists come looking for a court order. But in the final analysis, I struggle to see how an RPKI cert revocation would be any different from adding a prefix to the "official" blacklist that ISPs are encouraged to implement today.
Yes. At the end of the day application of RPKI or BGPsec is a local ISP policy decision. If filtering based on the current RIR registry databases were ubiquitous among the ISPs, these databases would have had the same effect as the RPKI. I doubt application of the RPKI will become ubiquitous in the near future. And if a common local policy is that is just increases the preference of the route, absence of a validatable ROA means that the system falls back to insecure, which is what we have now. But it will still protect (modulo no path protection) against address hijacking. Andrei
* Brian Nisbet:
I really don't think it does. You seem to be imagining a scenario where a national governement would just ring up the NCC and say, "revoke these certs." I have seen no evidence to suggest this risk is anything close to real.
It happens with domain names all the time. I don't see what so different about IP addresses. (Neither are content, but means to address content.) But why would this be a bad thing, as long as the required legal process is followed? -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
On Thu, 5 May 2011, Florian Weimer wrote:
But why would this be a bad thing, as long as the required legal process is followed?
The problem here is that all of a sudden dutch courts might have direct operational influence in all of the RIPE region. So basically it might make sense to bake a safety-valve into the system so that it's fairly easy to replace RIPE with something else in case meddling starts to happen. In DNS, one can choose not to use a US based domain name or registrar to avoid what's going on in DNS there, what would the similar action be in case the dutch legal system starts doing things we don't agree with, without turning off RPKI totally? -- Mikael Abrahamsson email: swmike@swm.pp.se
* Mikael Abrahamsson:
On Thu, 5 May 2011, Florian Weimer wrote:
But why would this be a bad thing, as long as the required legal process is followed?
The problem here is that all of a sudden dutch courts might have direct operational influence in all of the RIPE region.
Only indirect influence. Direct influence is when you inject prefixes into the global table, which many of us can do (including RIPE NCC).
In DNS, one can choose not to use a US based domain name or registrar to avoid what's going on in DNS there, what would the similar action be in case the dutch legal system starts doing things we don't agree with, without turning off RPKI totally?
Add additional trust anchors? -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
On 5 May 2011, at 09:21, Mikael Abrahamsson wrote:
The problem here is that all of a sudden dutch courts might have direct operational influence in all of the RIPE region.
You seem surprised that an organisation established in tbe Netherlands is subject to the jurisdiction of the Dutch courts. Perhaps you'd like me to tell you what bears do in the woods?
On 5 May 2011 10:31, Jim Reid <jim@rfc1035.com> wrote:
On 5 May 2011, at 09:21, Mikael Abrahamsson wrote:
The problem here is that all of a sudden dutch courts might have direct operational influence in all of the RIPE region.
You seem surprised that an organisation established in tbe Netherlands is subject to the jurisdiction of the Dutch courts.
Maybe we should start a discussion about alternative (new or old) legal entities (and their locations) that might be more suited to running the RPKI db /me runs J -- James Blessing 07989 039 476
On Thu, 5 May 2011, Jim Reid wrote:
On 5 May 2011, at 09:21, Mikael Abrahamsson wrote:
The problem here is that all of a sudden dutch courts might have direct operational influence in all of the RIPE region.
You seem surprised that an organisation established in tbe Netherlands is subject to the jurisdiction of the Dutch courts.
No I am not, but I am not happy to hand them the power to influence my routing global table without possibility of overriding their decision because what they think is good for .nl doesn't necessarily have to be good for the rest of the countries my employer is active in. -- Mikael Abrahamsson email: swmike@swm.pp.se
Mikael, On Thu, May 5, 2011 at 4:21 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
On Thu, 5 May 2011, Florian Weimer wrote:
But why would this be a bad thing, as long as the required legal process is followed?
The problem here is that all of a sudden dutch courts might have direct operational influence in all of the RIPE region.
So basically it might make sense to bake a safety-valve into the system so that it's fairly easy to replace RIPE with something else in case meddling starts to happen. In DNS, one can choose not to use a US based domain name or registrar to avoid what's going on in DNS there, what would the similar action be in case the dutch legal system starts doing things we don't agree with, without turning off RPKI totally?
While I appreciate the idea of safety-valves and a sort of reactive safety process, is it not inherently better to implement them from the beginning? Ie, your idea about placing multiple trust anchors in multiple jurisdictions from the beginning. But you still have not solved the core of the problem in this way:
From where will they get their prefix information?
Since you're not suggesting any modifications to the current internet numbers role of the RIPE NCC, the information is going to be sourced from RIPE's DB somehow, anyway. Do you suggest independent and open review of all changes of data before installation in the 2nd-tier trust anchors? Essentially a human-involving process will absolutely be required before a revocation, or change to $FOO, of a resource and its resource certificate will be allowed to spread from the source (RIPE's DB) to its 2nd-tier trust anchors. Who will vote on whether a change is OK or not? A pretty decent amount of persons will have to be involved to guard well against abuse (think EU/EC/EG court decisions / laws.) You must assume from the start that the legal process at the source is flawed -- how do you protect the mirrors from abuse? And if the legal process at the source is broken, how do you move the source IRR information away from it? Or, are you suggesting multiple independent IRRs covering the same data, where a user now has to keep individual and separate communications with each and one of them to update the IRR data, negotiate change of ownership of a resource, etc. I do appreciate a very useful discussion on this topic and seeking constructive solutions to the concerns outlined. And for the record I prefer making it completely pointless for someone to even consider sending black helicopters (this can be done), than to consider how to best protect oneself from them. :) Note well that my voting / change process questions raised above apply equally well whether there is only one IRR and one trust-anchor at RIPE NCC, or multiple 2nd-tier ones. Kind Regards, Martin
If the community (as evidenced by this WG) tells the RIPE NCC not to implement this (or more precisely to withdraw the service they are already offering) then we simply open the way for private certification companies in the RIPE region.
in which case, i would prefer to arrange a pro-bono one.
So would I. But I can imagine going to my boss and saying "there are two alternatives for securing my address space: a pro-bono, best effort thing run by Randy or a professional one run on a commercial basis by Mega-Certicates Plc. Which would you like me to use?
And why would that be better than having a not-for-profit org like RIPE NCC that we are all a part of as a member, already doing this ?
no one said otherwise. more careful reading would notice
If the community (as evidenced by this WG) tells the RIPE NCC not to implement this (or more precisely to withdraw the service they are already offering) then we simply open the way for private certification companies in the RIPE region.
randy
Hi ap-wg, I do NOT support this proposal for the very same reasons that Malcolm so eruditely laid out in his post. All that's left for me is to state that, in this case, the cure is infinitely worse than the disease. Kind Regards, Sascha Luck
Malcolm wrote:
I am afraid I don't believe this policy should be adopted at this time.
I agree with that.
This is not a minor, administrative policy. It is (even if not intended as such) the first step in a process the end result of which would be a major change to the Internet architecture. I am afraid that the ultimate outcome could be that the Internet becomes more fragile as a consequence. True, it's only the first step. But if it's a step in the wrong direction, let's not do it.
I'd like to add to the ones argueing that you are not forced to implement a policy based on the rpki: What point does this have if noone implements that? None, right, so all arguing in favour of this policy are convinced that one will imlement something based on that. So concider that: Once a serious amount of ASes (and exspecially carriers) have implemented policies based on RPKI, we will never get rid of that, at least not easyly. Just look at how good IPv6 is beeing adapted and how good we are getting rid of v4. ;) So before we push that huge responsability that comes along with that RPKI certificates (and especially with the power of revocation either by not renewing an expired certificate or by CRL or something like that) into the RIRs, we should double and tripple think wether we are really willing to do that and wether the RIRs are stable and resistable enough to the political preassure that no matter will fall upon them really soon after gouvernments (and lobby groups, ...) notice. [stuff where I pretty much agree with Malcolm deleted]
iii) Even if the problem is serious enough, whether alternative means to address it could be found that would mitigate these risks [2]. (For example, if the problem could be 80% solved using a model that does not give RIRs a power to revoke and expire certificates "needed" for routing, is the residual 20% of the problem really serious enough to warrant creating the risks I describe).
In order to respond to [2] here (and following a short discussion i had with Geoff after his talk yesterday): as the ressources are given out by the by IANA and the RIRs and the LIRs, so introducing an hirarchial approach that shadows the real assigning is a logical and the only usefull approach IMO. In general, both approaches works poorly to say the least and giving away the power to some "trusted third partys" get us the mess we today have with traditional ssl certificates (where we have a system that is seriously broken beyond all repair). However, I'd like to take Randys point from his talk that the validatity of certificates should be long, but would even say that thay should not be only two to five years, but instead at least 20 years and no possible revocation in order to protect the RIRs from being smashed by political preassure. From the security point of view, lang validity times are indeed just a question of chosing reasonable security parameters and there is a good consenseous about that in the security and crypto research about what that should be and these are (with a large safety margin) available in various recommendadiots (for example by NIST[1]). [even more stuff from Malcolm where i generally agree deleted] regards, Immo [1] http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Ma... Page 66 I'd just keep Malcolms [2] here
[2] For example, could we creates "webs of trust" rather than a single hierarchy? Would that be "good enough" or is a hierarchy essential? Could a PKI for address allocations work sufficiently well without investing the hierarchy with authority to revoke certificates? Should we consider an architecture with a distributed issuer/revoker, spread across multiple jurisdictions? What other models exist?
Hi Immo, On Tue, May 3, 2011 at 1:05 PM, Immo 'FaUl' Wehrenberg <immo.ripe@be.free.de> wrote:
Malcolm wrote:
I am afraid I don't believe this policy should be adopted at this time.
I agree with that.
This is not a minor, administrative policy. It is (even if not intended as such) the first step in a process the end result of which would be a major change to the Internet architecture. I am afraid that the ultimate outcome could be that the Internet becomes more fragile as a consequence. True, it's only the first step. But if it's a step in the wrong direction, let's not do it.
I'd like to add to the ones argueing that you are not forced to implement a policy based on the rpki: What point does this have if noone implements that? None, right, so all arguing in favour of this policy are convinced that one will imlement something based on that. So concider that: Once a serious amount of ASes (and exspecially carriers) have implemented policies based on RPKI, we will never get rid of that, at least not easyly. Just look at how good IPv6 is beeing adapted and how good we are getting rid of v4. ;)
So before we push that huge responsability that comes along with that RPKI certificates (and especially with the power of revocation either by not renewing an expired certificate or by CRL or something like that) into the RIRs, we should double and tripple think wether we are really willing to do that and wether the RIRs are stable and resistable enough to the political preassure that no matter will fall upon them really soon after gouvernments (and lobby groups, ...) notice.
[stuff where I pretty much agree with Malcolm deleted]
iii) Even if the problem is serious enough, whether alternative means to address it could be found that would mitigate these risks [2]. (For example, if the problem could be 80% solved using a model that does not give RIRs a power to revoke and expire certificates "needed" for routing, is the residual 20% of the problem really serious enough to warrant creating the risks I describe).
In order to respond to [2] here (and following a short discussion i had with Geoff after his talk yesterday): as the ressources are given out by the by IANA and the RIRs and the LIRs, so introducing an hirarchial approach that shadows the real assigning is a logical and the only usefull approach IMO.
Here I'd like to raise a minor, quite theoretical, objection. The primary purpose of IANA, RIRs and LIRs, when it comes to IPv4/v6 and AS numbers, is to organize resources globally so that there are no collisions (uniqueness). WIth IPv4 and to some extent AS numbers, there's an additional point of rationing them out, but that is mainly a side-effect of them being varying degrees of finite resources. IPv6 however, while not infinite, is certainly sufficient for every person on the planet. And so it is conceivable that another, distributed, system for uniqueness verification could exist. Whether or not any change like what I'm describing has any chance to fly or not, is a slightly different question. That, and what routing it would require. Returning to present day reality, address assignment policy and routing policy has rather successfully been kept apart so far, I think. Joining them up with a glue of censorship, which is what RPKI is (dropping prefix announcements, right?), is not very appealing to me. And what censorship it could become -- internetwide nearly instant censorship.
In general, both approaches works poorly to say the least and giving away the power to some "trusted third partys" get us the mess we today have with traditional ssl certificates (where we have a system that is seriously broken beyond all repair). However, I'd like to take Randys point from his talk that the validatity of certificates should be long, but would even say that thay should not be only two to five years, but instead at least 20 years and no possible revocation in order to protect the RIRs from being smashed by political preassure.
The really-long-term validity is appealing, but nevertheless falls short from personal preference since I don't see the actual need for RPKI to begin with. Thanks, Kind Regards, Martin
From the security point of view, lang validity times are indeed just a question of chosing reasonable security parameters and there is a good consenseous about that in the security and crypto research about what that should be and these are (with a large safety margin) available in various recommendadiots (for example by NIST[1]).
[even more stuff from Malcolm where i generally agree deleted]
regards,
Immo
[1] http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Ma... Page 66
I'd just keep Malcolms [2] here
[2] For example, could we creates "webs of trust" rather than a single hierarchy? Would that be "good enough" or is a hierarchy essential? Could a PKI for address allocations work sufficiently well without investing the hierarchy with authority to revoke certificates? Should we consider an architecture with a distributed issuer/revoker, spread across multiple jurisdictions? What other models exist?
Martin wrote:
In order to respond to [2] here (and following a short discussion i had with Geoff after his talk yesterday): as the ressources are given out by the by IANA and the RIRs and the LIRs, so introducing an hirarchial approach that shadows the real assigning is a logical and the only usefull approach IMO.
Here I'd like to raise a minor, quite theoretical, objection. The primary purpose of IANA, RIRs and LIRs, when it comes to IPv4/v6 and AS numbers, is to organize resources globally so that there are no collisions (uniqueness). WIth IPv4 and to some extent AS numbers, there's an additional point of rationing them out, but that is mainly a side-effect of them being varying degrees of finite resources. IPv6 however, while not infinite, is certainly sufficient for every person on the planet. And so it is conceivable that another, distributed, system for uniqueness verification could exist. Whether or not any change like what I'm describing has any chance to fly or not, is a slightly different question. That, and what routing it would require.
While I agree with you at some point, i don't think we get any further when starting to discuss at this level here.
In general, both approaches works poorly to say the least and giving away the power to some "trusted third partys" get us the mess we today have with traditional ssl certificates (where we have a system that is seriously broken beyond all repair). However, I'd like to take Randys point from his talk that the validatity of certificates should be long, but would even say that thay should not be only two to five years, but instead at least 20 years and no possible revocation in order to protect the RIRs from being smashed by political preassure. The really-long-term validity is appealing, but nevertheless falls short from personal preference since I don't see the actual need for RPKI to begin with.
Well, we had that Youtube incedent and there where a few more, so there are people demanding it. I don't think that denying that fact and just walk away would get us any further here again. In contrary, if people seriously start to demand it and we are going to say "well, we will not do something here" then they will start doing that in some other forum, which i would presume is much worse as we here can discuss and raise our concerns. Regards, Immo
On Tue, May 03, 2011 at 07:47:56PM +0200, Immo 'FaUl' Wehrenberg wrote:
just walk away would get us any further here again. In contrary, if people seriously start to demand it and we are going to say "well, we will not do something here" then they will start doing that in some other forum, which i would presume is much worse as we here can discuss and raise our concerns.
Then that battle will have to be fought elsewhere. While it is good tactics to choose the battleground yourself, it is pointless if you're just going to surrender anyway... rgds, Sascha Luck
On Tue, May 3, 2011 at 1:47 PM, Immo 'FaUl' Wehrenberg <immo.ripe@be.free.de> wrote:
Martin wrote:
In order to respond to [2] here (and following a short discussion i had with Geoff after his talk yesterday): as the ressources are given out by the by IANA and the RIRs and the LIRs, so introducing an hirarchial approach that shadows the real assigning is a logical and the only usefull approach IMO.
Here I'd like to raise a minor, quite theoretical, objection. The primary purpose of IANA, RIRs and LIRs, when it comes to IPv4/v6 and AS numbers, is to organize resources globally so that there are no collisions (uniqueness). WIth IPv4 and to some extent AS numbers, there's an additional point of rationing them out, but that is mainly a side-effect of them being varying degrees of finite resources. IPv6 however, while not infinite, is certainly sufficient for every person on the planet. And so it is conceivable that another, distributed, system for uniqueness verification could exist. Whether or not any change like what I'm describing has any chance to fly or not, is a slightly different question. That, and what routing it would require.
While I agree with you at some point, i don't think we get any further when starting to discuss at this level here.
In general, both approaches works poorly to say the least and giving away the power to some "trusted third partys" get us the mess we today have with traditional ssl certificates (where we have a system that is seriously broken beyond all repair). However, I'd like to take Randys point from his talk that the validatity of certificates should be long, but would even say that thay should not be only two to five years, but instead at least 20 years and no possible revocation in order to protect the RIRs from being smashed by political preassure. The really-long-term validity is appealing, but nevertheless falls short from personal preference since I don't see the actual need for RPKI to begin with.
Immo,
Well, we had that Youtube incedent and there where a few more, so there are people demanding it.
I am well aware that there is a demand by powerful forces for RPKI or something similar. I do not think the youtube incident and a handful other motivate such a drastic system. As you argued, the point of RPKI is to see it spread and implement else it is pointless. We agree here.
I don't think that denying that fact and just walk away would get us any further here again.
I welcome research and debate of this and alternative solutions to achieve the goal of avoiding the Youtube incident or making its impact less hurtful.
In contrary, if people seriously start to demand it and we are going to say "well, we will not do something here" then they will start doing that in some other forum, which i would presume is much worse as we here can discuss and raise our concerns.
Hopefully, the respective WG's at RIPE will remain in charge of the PDP process of their respective areas? I partly understand what you mean and partly don't. So far, I've seen one voice in favor of the proposal in this thread and several against. FWIW, I do not accept the argument "If we don't give up now they'll win somewhere else", it's completely mad IMHO. It would be quite appropriate that the general public became more aware of keeping an open internet anyway. Kind Regards, Martin
Martin wrote:
Well, we had that Youtube incedent and there where a few more, so there are people demanding it. I am well aware that there is a demand by powerful forces for RPKI or something similar. I do not think the youtube incident and a handful other motivate such a drastic system.
I don't see that further. However, engineering tends to overengineer things to not only solve the imminent problems, but also problems that could occure somewhen in the future. I don't see RPKI designed as an evil censorship tool. I'd bet it isn't even bad engineered (eventhough i haven't had a deeper look on the design yet). The only point is that its implementation has implications that from my point of view hasn't been taken into account properly until now.
I don't think that denying that fact and just walk away would get us any further here again. I welcome research and debate of this and alternative solutions to achieve the goal of avoiding the Youtube incident or making its impact less hurtful.
Fine. Thats exactly what I think should be done. Take the concerns mentioned seriously and put further work to resolve the problems.
In contrary, if people seriously start to demand it and we are going to say "well, we will not do something here" then they will start doing that in some other forum, which i would presume is much worse as we here can discuss and raise our concerns. Hopefully, the respective WG's at RIPE will remain in charge of the PDP process of their respective areas?
If the WG is just sticking their head into the sand and just says 'no, we're against it' without supplying any strategy to archive a solution everybody can live with, this may well change. And that was exactly my point here. Work must be going towards that solution and not just discarding the current one. I hope that clarifys things. Immo
Hello Immo,
I don't think that denying that fact and just walk away would get us any further here again. I welcome research and debate of this and alternative solutions to achieve the goal of avoiding the Youtube incident or making its impact less hurtful.
Fine. Thats exactly what I think should be done. Take the concerns mentioned seriously and put further work to resolve the problems.
In contrary, if people seriously start to demand it and we are going to say "well, we will not do something here" then they will start doing that in some other forum, which i would presume is much worse as we here can discuss and raise our concerns. Hopefully, the respective WG's at RIPE will remain in charge of the PDP process of their respective areas?
If the WG is just sticking their head into the sand and just says 'no, we're against it' without supplying any strategy to archive a solution everybody can live with, this may well change.
And that was exactly my point here. Work must be going towards that solution and not just discarding the current one.
I hope that clarifys things.
Thank you for your reply. As co-chair of this working group I can only add extra emphasis here: this is a working group, let's work towards a solution. If you are in favor of this policy proposal or agains it: please provide arguments that we can discuss. Thank you, Sander Steffann APWG co-chair
Martin, On May 3, 2011, at 10:22 AM, Martin Millnert wrote:
The primary purpose of IANA, RIRs and LIRs, when it comes to IPv4/v6 and AS numbers, is to organize resources globally so that there are no collisions (uniqueness).
If uniqueness was the primary role of the IR system, it would be far easier/cheaper/more efficient to have a trivial web service that allocates numbers sequentially on demand. We don't have that because the IR system is also concerned with conservation and routability. Since both of these latter two concerns are subjective, an elaborate (some might even say Byzantine) policy definition structure has evolved to define 'appropriate' (for some value of that variable) levels of both. (One might argue that at least in the context of IPv4, the conservation goal no longer applies since there is no longer anything to conserve, but that's probably a topic for a different thread). Today, since the IR system has little in the way of enforcement capability, this system primarily works via the "consent of the governed" (where 'the governed' tends to be the larger ISPs). RPKI+SIDR potentially provides for a more effective enforcement mechanism than has existed to date. The advantages of this are clear: it would allow for increased security in the routing system, permitting greater control in how numbering resources are interpreted by relying parties. The downsides are that it allows for increased security in the routing system, theoretically permitting the imposition of policies that may be objectionable to some.
WIth IPv4 and to some extent AS numbers, there's an additional point of rationing them out, but that is mainly a side-effect of them being varying degrees of finite resources. IPv6 however, while not infinite, is certainly sufficient for every person on the planet.
There is no finite resource that folks can't come up with policies that result in the resource becoming scarce. Regards, -drc
Dear address-policy-wg, I, too, share many of the concerns Malcolm (and others following on his comments) voiced here. I do not feel that this policy should be adopted. In addition to many of the philosophical and political concerns outlined by Malcolm (whom I would like to thank for putting them down in writing so eloquently) as to why this policy might effectively be a Pandora's box of undesirable outcomes - I also find the resources allocated by the RIPE NCC internally to RPKI efforts would be much better used if applied to furthering the usability, tooling, and user education for RPSL, which, in my opinion offers many of the capabilities the proponents of RPKI expect to see from the implementation of this policy. RPSL as a mechanism is at least partially implemented by many participants in the DFZ today, and it can be reasonably argued that by adding as little as a scalable and SSL/TLS-secured interface to the RIPE whois database, the goal of a single trust anchor containing 'definitive' information on the ownership of each allocated and assigned resource in machine-readable format is already achieved. This information, in turn, can be used both by BSS/OSS systems and, if implemented, directly by network devices to make decisions on the validity of routing information. With all this in mind, I can not support this policy. -- Respectfully yours, David Monosov On 05/03/2011 01:31 PM, Malcolm Hutty wrote:
I am afraid I don't believe this policy should be adopted at this time.
On 3 May 2011, at 12:31, Malcolm Hutty wrote:
[2] For example, could we creates "webs of trust" rather than a single hierarchy? Would that be "good enough" or is a hierarchy essential?
I am strongly in favour of resource certification, but appeared (until RIPE62) to be labouring under the misapprehension that this web (rather than hierarchy) system was the thing that we are building. Thank you for raising the point, Malcolm. The Utopia, for me, is that a certificate would be valid if the NCC, *or* ARIN, *or* APNIC, *or* ..., *or* MOON-NIC, *or* Certs Inc, *or* Randy, or even my private CA had signed it, because no single regulator in any jurisdiction would be able to revoke my certificate and prevent routing. I get the benefits of automation, and the benefits of certification, without having to carry the risk of an 'internet off' switch. Is it too late for this ? Please say not. Andy
Andy, as I seen this process - one have tried to design this tool with secure BGP in mind, second one thought about Certificates as a tool to protect current address management system (aka RIRs), third group - as you - think about it as a tool to protect your resource and make routing for himself more safe. In general all three think about safe routing - but each one has his own special requirements and goals - what is really important for him personally. And practically only today we began public discussion - is it the same for all of us? Can we satisfy all needs by one design? This policy is as a some kind of test for me - can we find a common compromise? Dima On 10.05.2011 16:57, Andy Davidson wrote:
On 3 May 2011, at 12:31, Malcolm Hutty wrote:
[2] For example, could we creates "webs of trust" rather than a single hierarchy? Would that be "good enough" or is a hierarchy essential? I am strongly in favour of resource certification, but appeared (until RIPE62) to be labouring under the misapprehension that this web (rather than hierarchy) system was the thing that we are building. Thank you for raising the point, Malcolm.
The Utopia, for me, is that a certificate would be valid if the NCC, *or* ARIN, *or* APNIC, *or* ..., *or* MOON-NIC, *or* Certs Inc, *or* Randy, or even my private CA had signed it, because no single regulator in any jurisdiction would be able to revoke my certificate and prevent routing. I get the benefits of automation, and the benefits of certification, without having to carry the risk of an 'internet off' switch. Is it too late for this ? Please say not.
Andy
Hi Andy,
I am strongly in favour of resource certification, but appeared (until RIPE62) to be labouring under the misapprehension that this web (rather than hierarchy) system was the thing that we are building. Thank you for raising the point, Malcolm.
The Utopia, for me, is that a certificate would be valid if the NCC, *or* ARIN, *or* APNIC, *or* ..., *or* MOON-NIC, *or* Certs Inc, *or* Randy, or even my private CA had signed it, because no single regulator in any jurisdiction would be able to revoke my certificate and prevent routing. I get the benefits of automation, and the benefits of certification, without having to carry the risk of an 'internet off' switch. Is it too late for this ? Please say not.
I think this presentation of Stephen Kent shows some possibilities: http://meetings.apnic.net/__data/assets/pdf_file/0019/18910/Routing-Security... - Sander
participants (24)
-
Alex Band -
Andrei Robachevsky -
Andy Davidson -
boggits -
Brian Nisbet -
David Conrad -
David Monosov -
Dmitry Burkov -
Erik Bais -
Florian Weimer -
Garry Glendown -
Geoff Huston -
Gert Doering -
Immo 'FaUl' Wehrenberg -
Jim Reid -
John Curran -
Mailing List Account -
Malcolm Hutty -
Martin Millnert -
Mikael Abrahamsson -
Nigel Titley -
Randy Bush -
Sander Steffann -
Sascha Luck