Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region)
Hello WG, I asked the RIPE NCC to get legal counsel on the possibilities of a court ordering the RIPE NCC to revoke or confiscate RPKI certificates. Here is the full answer we received: ========== The RIPE NCC is an association under Dutch law and therefore subject to the Dutch legislation. RIPE NCC has consulted several external lawyers, and has obtained an analysis of the legal situation based on current, existing Dutch legislation. This analysis takes into account Dutch Criminal, Civil and Administrative law. Certificates are directly linked to the registration of the Internet number resources. There is no specific Dutch legislation that can be used to order the deregistration of Internet number resources or change the registration details of Internet number resources. Nor is there any legislation that applies to the revocation of certificates over Internet number resources. In the absence of such legislation, a court cannot order the revocation of certificates. It is the RIPE NCC’s view, based on this analysis, that the RIPE NCC cannot be ordered to revoke resource certificates. ========== Of course laws can change, but the advice above may address some of the concerns raised about the RPKI infrastructure. Sander Steffann APWG co-chair
On Fri, 6 May 2011, Sander Steffann wrote:
In the absence of such legislation, a court cannot order the revocation of certificates.
In several countries, we've seen courts ordering ISPs to block accessibility to certain sites involving not using DNS names (denmark and thepiratebay.org for instance, or the domain names transferred to US authorities just a few months ago) or block access IP-wise (Black Internet in Sweden). I am sure there was no specific law handling this, but the laws at least in these countries are flexible enough that other laws can be used to order things around.
Of course laws can change, but the advice above may address some of the concerns raised about the RPKI infrastructure.
It's good that it has been answered for dutch law, I wonder what equivalent question would have been answered in Sweden and Denmark or the US 5 years ago. -- Mikael Abrahamsson email: swmike@swm.pp.se
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/05/2011 07:43, Sander Steffann wrote:
There is no specific Dutch legislation that can be used to order the deregistration of Internet number resources or change the registration details of Internet number resources. Nor is there any legislation that applies to the revocation of certificates over Internet number resources.
In the absence of such legislation, a court cannot order the revocation of certificates.
It is the RIPE NCC’s view, based on this analysis, that the RIPE NCC cannot be ordered to revoke resource certificates.
There are a couple of other possible current vectors, as well as the question of future legislation. 1. Legal counsel referred to the lack of legislation that specifically mentioned revocation of certificates. Most of the existing and draft legislation I know of (not Dutch, but some EU) refers instead to "preventing access to Internet [locations/sites/content]". As a generalisation, courts will not normally order someone to do something utterly outside their power, but may order someone to take such steps as they are able to achieve an end if they are seen as being able to make a significant contribution, even if that contribution won't be wholly successful. For example, courts sometimes order newspapers and broadcasters not to publish information, even though they know the information may end up being published online. Right now it is commonly said that RIPE NCC does not have control over routing, so a court would be unlikely to order the RIPE NCC to prevent access to an Internet location. If, as a result of this policy, RIPE NCC is seen to have the capability to significantly reduce the reachability of an Internet location, a court might be willing to order it to "prevent access to the location" to the extent that it is able. No explicit mention need be made of certificate revocation. 2. Within some jurisdictions LEAs argue that Internet intermediaries are themselves criminally liable if they "facilitate" criminal activity by refusing to prevent access to an Internet location where criminal activity is ongoing, once they have been informed of the criminal activity. Intermediaries are thus induced to block access without a court order being necessary. Within the EU, network operators have special protection against this threat from the E-Commerce Directive as "mere conduits", but unfortunately registries like the RIPE NCC probably do not fit the definition of "mere conduit". In the UK, Nominet (the .uk ccTLD registry) has been induced to suspend domain registrations using this argument. RIPE NCC might in future be exposed to the same pressure. 3. Finally, new legislation not only /could/ be created, but most certainly will. The Netherlands is subject to EU law. Whether such new law would affect the RIPE NCC we cannot be certain, but I am certain that the only thing restraining lobbyists is a lack of awareness of the existence of RIPE NCC (and awareness is increasing), and a belief that the RIPE NCC has no relevant technical capability, which this policy would change. - -- 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/ iEYEARECAAYFAk3DoywACgkQJiK3ugcyKhSlSACdGyEFtxJUai+xrWtGB/vwZjoJ VnUAoLpgRXaghPiUTTDwF3SIoQxgCEa+ =eFIF -----END PGP SIGNATURE-----
On 6 May 2011 08:43, Sander Steffann <sander@steffann.nl> wrote:
Of course laws can change, but the advice above may address some of the concerns raised about the RPKI infrastructure.
This is indeed true but misses the point that laws tend to exist either when there is an actual 'thing' to make laws about or are framed in such a way to allow the courts the latitude to include 'new things' in the same piece of legislation. Since RPKI is not currently a 'thing' but rather a 'new thing' I would be wary of relying on legal opinion that says: "There is no specific Dutch legislation that can be used to order the deregistration of Internet number resources or change the registration details of Internet number resources. Nor is there any legislation that applies to the revocation of certificates over Internet number resources." What you are looking for is legislation (as pointed out by Malcom) that can be used to restrict/control access to the internet which appears to exist at least at a European level J -- James Blessing 07989 039 476
At least for me, part of my worries is this "awareness thing" and the use of terms - both within the framework of the discussion and in the tools, UIs, plus documentation: ROA: Route Origin Authorization. What is the message, that this sends out to the various lobbying and other "pressure groups"? In particular, when the RIPE NCC is offering the creation of ROAs as a hosted service by way of the LIR Portal.... Folks (like me) who have seen things and threats happening in the past, in real life, without *any* regard to "legislation" being there or not, or being seen as applicable, tend to be just a tad more paranoid than some others ;-) Wilfried boggits wrote:
On 6 May 2011 08:43, Sander Steffann <sander@steffann.nl> wrote:
Of course laws can change, but the advice above may address some of the concerns raised about the RPKI infrastructure.
This is indeed true but misses the point that laws tend to exist either when there is an actual 'thing' to make laws about or are framed in such a way to allow the courts the latitude to include 'new things' in the same piece of legislation. Since RPKI is not currently a 'thing' but rather a 'new thing' I would be wary of relying on legal opinion that says:
"There is no specific Dutch legislation that can be used to order the deregistration of Internet number resources or change the registration details of Internet number resources. Nor is there any legislation that applies to the revocation of certificates over Internet number resources."
What you are looking for is legislation (as pointed out by Malcom) that can be used to restrict/control access to the internet which appears to exist at least at a European level
J
On Fri, May 06, 2011 at 11:06:44AM +0200, boggits wrote:
"There is no specific Dutch legislation that can be used to order the deregistration of Internet number resources or change the registration details of Internet number resources. Nor is there any legislation that applies to the revocation of certificates over Internet number resources."
What you are looking for is legislation (as pointed out by Malcom) that can be used to restrict/control access to the internet which appears to exist at least at a European level
There is an unfortunate tendency in lawmaking these days towards formulating legislation is such a broad way that it includes "use cases" they may have forgotten about or not thought of when writing it. Not the word "specific" in the above, this does not mean that applicable legislation does not exist! rgds, Sascha Luck
Sascha,
"There is no specific Dutch legislation that can be used to order the deregistration of Internet number resources or change the registration details of Internet number resources. Nor is there any legislation that applies to the revocation of certificates over Internet number resources."
What you are looking for is legislation (as pointed out by Malcom) that can be used to restrict/control access to the internet which appears to exist at least at a European level
There is an unfortunate tendency in lawmaking these days towards formulating legislation is such a broad way that it includes "use cases" they may have forgotten about or not thought of when writing it. Not the word "specific" in the above, this does not mean that applicable legislation does not exist!
You miss the next sentence of the legal advise: "In the absence of such legislation, a court cannot order the revocation of certificates." I think the legal statement (when read as a whole, not cherry-picking the parts you like) was clear enough. Sander
On Mon, May 9, 2011 at 3:34 PM, Sander Steffann <sander@steffann.nl> wrote:
Sascha,
"There is no specific Dutch legislation that can be used to order the deregistration of Internet number resources or change the registration details of Internet number resources. Nor is there any legislation that applies to the revocation of certificates over Internet number resources."
What you are looking for is legislation (as pointed out by Malcom) that can be used to restrict/control access to the internet which appears to exist at least at a European level
There is an unfortunate tendency in lawmaking these days towards formulating legislation is such a broad way that it includes "use cases" they may have forgotten about or not thought of when writing it. Not the word "specific" in the above, this does not mean that applicable legislation does not exist!
You miss the next sentence of the legal advise: "In the absence of such legislation, a court cannot order the revocation of certificates."
I think the legal statement (when read as a whole, not cherry-picking the parts you like) was clear enough. Sander
Now if the statement could only guarantee for the future that it no court could do anything of the sort, it'd actually be useful. Since it doesn't, I think the sensible thing to do is to account for the fact that laws can change (and that lawyers are... highly creative, and can launch attacks that force you to prove them wrong just to get back to status quo) when choosing what model to use for securing the internet. I remember Gordon Brown of the UK used then-recent British anti-terror laws to cease Icelandic money, btw. I wonder how many legal counsels could foresee that. :) Kind Regards, Martin
Hi Martin,
You miss the next sentence of the legal advise: "In the absence of such legislation, a court cannot order the revocation of certificates."
I think the legal statement (when read as a whole, not cherry-picking the parts you like) was clear enough. Sander
Now if the statement could only guarantee for the future that it no court could do anything of the sort, it'd actually be useful. Since it doesn't, I think the sensible thing to do is to account for the fact that laws can change
I fully agree. Mind you, they could just as well just make a law that says "You may not route any packets to/from addresses that appear on list X" and we would have exactly the situation everyone seems to be afraid of, and it doesn't need RPKI. As soon as laws don't allow 'your network, your rules' anymore then anything can happen... But that is something that we'll have to steer through voting, not address policy :) - Sander
On Mon, May 09, 2011 at 10:01:14PM +0200, Sander Steffann wrote:
I fully agree. Mind you, they could just as well just make a law that says "You may not route any packets to/from addresses that appear on list X" and we would have exactly the situation everyone seems to be afraid of, and it doesn't need RPKI. As soon as laws don't allow 'your network, your rules' anymore then anything can happen... But that is something that we'll have to steer through voting, not address policy :) > >- Sander >
Right now, this does *not* work effectively because the internet routes around such censorship attempts and there is no LEA that can reach *everyone* in the world. This policy proposal changes that. rgds, Sascha Luck
Hi,
Right now, this does *not* work effectively because the internet routes around such censorship attempts and there is no LEA that can reach *everyone* in the world. This policy proposal changes that.
Not really. You would also need laws in each country that force network operators to use RPKI evaluation without applying any whitelisting or exceptions. If such laws can exist, laws that do the same according to a government-defined blacklist can also exist. - Sander
On Mon, May 9, 2011 at 4:20 PM, Sander Steffann <sander@steffann.nl> wrote:
Hi,
Right now, this does *not* work effectively because the internet routes around such censorship attempts and there is no LEA that can reach *everyone* in the world. This policy proposal changes that.
Not really. You would also need laws in each country that force network operators to use RPKI evaluation without applying any whitelisting or exceptions.
If the technology is seen as feasible for legislators (where feasible means: control the Internet from one point (for your own safety, of course).), it's not a very distant thought that they'd go for their own list of bad prefixes that you should/could/MUST drop.
If such laws can exist, laws that do the same according to a government-defined blacklist can also exist.
(Feels like I'm repeating myself here) Such laws *do* exists. Denmark, Italy, from the top of my head, and I'm not even an activist in this matter. Kind Regards, Martin
On 9 May 2011, at 22:06, Sascha Luck wrote:
On Mon, May 09, 2011 at 10:01:14PM +0200, Sander Steffann wrote:
I fully agree. Mind you, they could just as well just make a law that says "You may not route any packets to/from addresses that appear on list X" and we would have exactly the situation everyone seems to be afraid of, and it doesn't need RPKI. As soon as laws don't allow 'your network, your rules' anymore then anything can happen... But that is something that we'll have to steer through voting, not address policy :) > >- Sander >
Right now, this does *not* work effectively because the internet routes around such censorship attempts and there is no LEA that can reach *everyone* in the world. This policy proposal changes that.
Again, it doesn't change that. Yes, it could potentially change that in some future where laws are changed, but right now revoking a certificate has no effect on routing whatsoever. In the way the system is designed, everything revolves around preferences. At the end of the day, it it up to the network operator to base a decision on the information that is available to him/her. Accepting an invalid prefix because of a revoked certificate is always an option, unless the law is changed in *every* country where this system is used. Reread Randy's post from just now where draft-ietf-sidr-origin-ops-07 is quoted. -Alex
On Mon, May 9, 2011 at 4:21 PM, Alex Band <alexb@ripe.net> wrote:
On 9 May 2011, at 22:06, Sascha Luck wrote:
On Mon, May 09, 2011 at 10:01:14PM +0200, Sander Steffann wrote:
I fully agree. Mind you, they could just as well just make a law that says "You may not route any packets to/from addresses that appear on list X" and we would have exactly the situation everyone seems to be afraid of, and it doesn't need RPKI. As soon as laws don't allow 'your network, your rules' anymore then anything can happen... But that is something that we'll have to steer through voting, not address policy :) > >- Sander >
Right now, this does *not* work effectively because the internet routes around such censorship attempts and there is no LEA that can reach *everyone* in the world. This policy proposal changes that.
Again, it doesn't change that.
Yes, it could potentially change that in some future where laws are changed, but right now revoking a certificate has no effect on routing whatsoever. In the way the system is designed, everything revolves around preferences. At the end of the day, it it up to the network operator to base a decision on the information that is available to him/her. Accepting an invalid prefix because of a revoked certificate is always an option, unless the law is changed in *every* country where this system is used.
Yeah, new laws, and regarding the Internet, has that ever happened? Oh wait. See block-lists in various countries.
Reread Randy's post from just now where draft-ietf-sidr-origin-ops-07 is quoted.
-Alex
RIPE NCC re-assigns resource R from ISP A to LEA L, and issues it a new resource certificate. A does not use RPKI. LEA L creates a ROA and starts announcing R. In accordance with Randy's post, this means the *minimum* RPKI policy will impose the DDoS. Kind Regards, Martin
Alex, On May 9, 2011, at 10:21 AM, Alex Band wrote:
On 9 May 2011, at 22:06, Sascha Luck wrote:
Right now, this does *not* work effectively because the internet routes around such censorship attempts and there is no LEA that can reach *everyone* in the world. This policy proposal changes that. Again, it doesn't change that. Yes, it could potentially change that in some future where laws are changed, but right now revoking a certificate has no effect on routing whatsoever.
Of course, because no one is using it right now. Presumably, the point of deploying RPKI is that people are going to use it. My understanding is that once people start using it, ISPs, under their own free will, will presumably implement routing policy based on certification status. At that point, revoking a certification would have an effect on routing. That effect can be anything from dropping de-certified objects on the floor to making them last resort to not doing anything special. Yes, it is my decision as a network operator what I choose. However, if "most" ISPs make the decision that a de-certified resource should be dropped on the floor, then the result is that every entity in the resource certification chain above that resource (LIR, {NIR,} RIR, IANA/ICANN) has the ability to cause that resource to be ignored for "most" ISPs. Is my understanding wrong?
In the way the system is designed, everything revolves around preferences. At the end of the day, it it up to the network operator to base a decision on the information that is available to him/her.
Of course. And RPKI is providing a hierarchical system to provide information regarding resource certification. The implication of the hierarchical authorization model chosen by the RIRs for RPKI is that parents (and grandparents, etc) can impose policy on their children. Or do I misunderstand the technology here (entirely possible -- been buried under other things and have lost track of RPKI/SIDR developments)? Thanks, -drc
On 9 May 2011, at 23:03, David Conrad wrote:
Alex,
On May 9, 2011, at 10:21 AM, Alex Band wrote:
On 9 May 2011, at 22:06, Sascha Luck wrote:
Right now, this does *not* work effectively because the internet routes around such censorship attempts and there is no LEA that can reach *everyone* in the world. This policy proposal changes that. Again, it doesn't change that. Yes, it could potentially change that in some future where laws are changed, but right now revoking a certificate has no effect on routing whatsoever.
Of course, because no one is using it right now. Presumably, the point of deploying RPKI is that people are going to use it.
I meant now in legislative terms, not in adoption terms. :) Even with 100% adoption today, every network operator still has a *choice*. Only legislation can change that. It's just like basing routing decisions on 'route' objects in the IRR, but just more reliable because of the design of RPKI.
My understanding is that once people start using it, ISPs, under their own free will, will presumably implement routing policy based on certification status. At that point, revoking a certification would have an effect on routing. That effect can be anything from dropping de-certified objects on the floor to making them last resort to not doing anything special. Yes, it is my decision as a network operator what I choose. However, if "most" ISPs make the decision that a de-certified resource should be dropped on the floor, then the result is that every entity in the resource certification chain above that resource (LIR, {NIR,} RIR, IANA/ICANN) has the ability to cause that resource to be ignored for "most" ISPs.
Is my understanding wrong?
No. But if I look at this from an RIR perspective, it would of course never be in their interest to do so or play a part in that process. Our goal is to provide an infrastructure and make sure only the registered holder of an Internet resource can create a valid attestation. Other than that, network operators are free to add any routing policy they like, and other network operators are free to base any decision on the available information. Also, you have to realise that we've been working on this since 2006, by our Community's request. The system is based on open IETF standards in the SIDR working group which has been active even longer. All of this has been done in a completely open and transparent way. Now that we've finally launched this as a usable, tangible service, this discussion erupts. I'll leave it up to you to to draw a conclusion from that.
In the way the system is designed, everything revolves around preferences. At the end of the day, it it up to the network operator to base a decision on the information that is available to him/her.
Of course. And RPKI is providing a hierarchical system to provide information regarding resource certification. The implication of the hierarchical authorization model chosen by the RIRs for RPKI is that parents (and grandparents, etc) can impose policy on their children. Or do I misunderstand the technology here (entirely possible -- been buried under other things and have lost track of RPKI/SIDR developments)?
Allocating resources and registering them in the Registry is a function the RIRs have been fulfilling for years already. The same goes for IANA allocations. We've been using that information to for example lock down the creation of route objects in the RIPE Database. But by no means is the Internet Routing Registry system as a whole water tight. The power of it being a distributed system with more than 34 databases is its weakness at the same time. With RPKI, the only thing the RIR locks down is that only the registered holder of an Internet resource can create a valid Route Origin Authorisation. Yes, this is hierarchical in nature, but there is really no other way to make sure only the *legitimate holder* can make a *valid* attestation. This information is validatable by anyone on the Internet using public, open source tools from various parties. In this respect, RPKI makes the routing decision making process more robust. -Alex
Alex, On May 9, 2011, at 11:57 AM, Alex Band wrote:
Even with 100% adoption today, every network operator still has a *choice*.
I remember similar arguments being made about DNSSEC in the context of the NTIA/ICANN/VeriSign signing of the root: resolver operators always have the option of not using the trust anchor published by IANA. This argument generally isn't very realistic.
But if I look at this from an RIR perspective, it would of course never be in their interest to do so or play a part in that process.
Of course. However, realistically, it would be in the RIRs' (or at least their staff's) interests to abide by lawful requests of law enforcement in the venues in which they are incorporated. Folks at the RIRs might not be happy about it, but you will play a part in that process or get fined/go to jail.
Our goal is to provide an infrastructure and make sure only the registered holder of an Internet resource can create a valid attestation.
If this was the extent of what was possible, I doubt anyone would have significant worries. I believe the concern is more that once that infrastructure is built, it will be used for additional, less desirable purposes.
Now that we've finally launched this as a usable, tangible service, this discussion erupts. I'll leave it up to you to to draw a conclusion from that.
That people don't deal with stuff until they're forced to?
With RPKI, the only thing the RIR locks down is that only the registered holder of an Internet resource can create a valid Route Origin Authorisation.
Having a bit of (excruciatingly painful) personal experience at the other end of this in a past life, why were (are?) the RIRs so reticent about being under the IANA in the RPKI hierarchy? Would not the same arguments apply to RIPE from the LIR's perspective?
Yes, this is hierarchical in nature, but there is really no other way to make sure only the *legitimate holder* can make a *valid* attestation.
I would agree that a hierarchical trust model is the simplest and easiest implemented. I'm unclear as to whether no other models exist. However, more concretely, I question whether regardless of whether other trust models exist, it is politically feasible to impose the hierarchical allocation model onto the more peer-to-peer relationships found in the routing system. Personally, I've always been a bit skeptical of the idea that (even theoretically) an RIR could impose a direct and immediate impact on the routability of operational networks relating to sovereign interest (e.g., UK MoD networks), even if that impact would be merely to de-pref their routes in the routers of cooperating ISPs.
This information is validatable by anyone on the Internet using public, open source tools from various parties. In this respect, RPKI makes the routing decision making process more robust.
Yes. There is no doubt (at least in my mind) that RPKI could provide benefits. I think what some are saying is that this comes at a risk/cost and some are not confident either that the risk/cost is justified or that there might not be other ways of gaining similar benefit without that risk/cost. Regards, -drc
Hi Alex, On Mon, May 9, 2011 at 5:57 PM, Alex Band <alexb@ripe.net> wrote:
Also, you have to realise that we've been working on this since 2006, by our Community's request. The system is based on open IETF standards in the SIDR working group which has been active even longer. All of this has been done in a completely open and transparent way.
Purely out of curiosity here, does the complete openness and transparency of the process so far include the code that the RIPE NCC has developed together with external consultants? I've been looking around at http://www.ripe.net/ but I couldn't find an URL to the subversion repository mentioned in the CPS [1]. I do remember hearing from the meeting that some code was planned to be released. Are you going to be releasing all of the code, or will some be kept for obscurity or other reasons? Kind Regards, Martin [1] http://www.ripe.net/lir-services/resource-management/certification/cps/view
Hi Martin, On May 10, 2011, at 2:37 PM, Martin Millnert wrote:
I do remember hearing from the meeting that some code was planned to be released. Are you going to be releasing all of the code, or will some be kept for obscurity or other reasons?
The validation tool is available in both binary form and as open source (bsd), here: http://www.ripe.net/lir-services/resource-management/certification/validatio... The plan is to start a pilot in a few weeks where members can run their own local CA instead of the hosted service that is offered now. When this pilot starts it is planned to release an initial standalone CA, again under a BSD license, with limited functionality (eg not able to issue certificates to child CAs of its own). In the long term nothing has been decided yet. This depends on feedback from the community as well of course. We could extend the features of this standalone CA, or when we are sure that interoperability with the ISC 'rpkid' works, members can use that.. Regards, Tim Bruijnzeels Senior Software Engineer RIPE NCC
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/05/2011 15:51, Tim Bruijnzeels wrote:
The plan is to start a pilot in a few weeks where members can run their own local CA instead of the hosted service that is offered now.
Will that only occur if rough consensus in favour of the policy is achieved in this Working Group? Or will it proceed even if not/in advance of such consensus being achieved? What will happen to the existing hosted solution if this policy does not achieve consensus during this Last Call? Is there another policy that has already been approved that authorises the RIPE NCC hosted RKPI? 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/ iEYEARECAAYFAk3JZbQACgkQJiK3ugcyKhRq/QCgkqdosdSYfVloDTtn78ZY08iW nagAnRRXNEKS6g6lXAkPTS42h8b98CQR =Ro8E -----END PGP SIGNATURE-----
Martin, On Tue, 2011-05-10 at 08:37 -0400, Martin Millnert wrote:
Hi Alex,
On Mon, May 9, 2011 at 5:57 PM, Alex Band <alexb@ripe.net> wrote:
Also, you have to realise that we've been working on this since 2006, by our Community's request. The system is based on open IETF standards in the SIDR working group which has been active even longer. All of this has been done in a completely open and transparent way.
Purely out of curiosity here, does the complete openness and transparency of the process so far include the code that the RIPE NCC has developed together with external consultants? I've been looking around at http://www.ripe.net/ but I couldn't find an URL to the subversion repository mentioned in the CPS [1].
I do remember hearing from the meeting that some code was planned to be released. Are you going to be releasing all of the code, or will some be kept for obscurity or other reasons?
Speaking of openness... :) It would be nice if the RIPE NCC could commit to something like the Google Transparency Report, where all government requests for legal action are published openly: http://www.google.com/transparencyreport/ Looking at those numbers makes it pretty clear to me that governments will be mucking around with routing policy eventually, whether or not we have certificates. It might be nice to have something like this independent of any eventual certification policy. -- Shane
On 11 May 2011, at 09:32, Shane Kerr wrote:
It would be nice if the RIPE NCC could commit to something like the Google Transparency Report, where all government requests for legal action are published openly
Shane, it doesn't work like that. There will be occasions when the existence of a government (or law enforcement) request cannot be mentioned. BTW, google and transparency: that's an interesting combination.
At 10:32 11/05/2011 +0200, Shane Kerr wrote:
Content-Transfer-Encoding: 7bit
Martin,
On Tue, 2011-05-10 at 08:37 -0400, Martin Millnert wrote:
Hi Alex,
On Mon, May 9, 2011 at 5:57 PM, Alex Band <alexb@ripe.net> wrote:
Also, you have to realise that we've been working on this since 2006, by our Community's request. The system is based on open IETF standards in the SIDR working group which has been active even longer. All of this has been done in a completely open and transparent way.
Purely out of curiosity here, does the complete openness and transparency of the process so far include the code that the RIPE NCC has developed together with external consultants? I've been looking around at http://www.ripe.net/ but I couldn't find an URL to the subversion repository mentioned in the CPS [1].
I do remember hearing from the meeting that some code was planned to be released. Are you going to be releasing all of the code, or will some be kept for obscurity or other reasons?
Speaking of openness... :)
It would be nice if the RIPE NCC could commit to something like the Google Transparency Report, where all government requests for legal action are published openly:
+1. -Hank
http://www.google.com/transparencyreport/
Looking at those numbers makes it pretty clear to me that governments will be mucking around with routing policy eventually, whether or not we have certificates.
It might be nice to have something like this independent of any eventual certification policy.
-- Shane
Hi Alex, Alex Band wrote: [...]
Also, you have to realise that we've been working on this since 2006, by our Community's request. The system is based on open IETF standards in the SIDR working group which has been active even longer. All of this has been done in a completely open and transparent way. Now that we've finally launched this as a usable, tangible service, this discussion erupts. I'll leave it up to you to to draw a conclusion from that.
Neither trying to make a statement in favour or against, just as an observation. 2011 - 2006 = 5 years = an awefully long period of time in NetLand. In 2006 "nobody" was interested in taking control of the 'net or the information accessible over this tech. Since then the world has moved on and we can now observe many attempts, by many different parties (not exlusively governments!), to get a "better grip" on the Internet. Things have changed a bit since 2006, I'm afraid... Wilfried.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sascha Luck wrote on 5/9/11 22:06 :
On Mon, May 09, 2011 at 10:01:14PM +0200, Sander Steffann wrote:
I fully agree. Mind you, they could just as well just make a law that says "You may not route any packets to/from addresses that appear on list X" and we would have exactly the situation everyone seems to be afraid of, and it doesn't need RPKI. As soon as laws don't allow 'your network, your rules' anymore then anything can happen... But that is something that we'll have to steer through voting, not address policy :) > >- Sander >
Right now, this does *not* work effectively because the internet routes around such censorship attempts and there is no LEA that can reach *everyone* in the world. This policy proposal changes that.
I am a bit surprised that the whole discussion is around only this part of the equation. What about the added benefit of the routing security this policy and subsequently deployed and adopted system can add? Today, your network can be taken down by a simple misconfiguration or malicious attack without any court order. Andrei -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3IcWcACgkQljz5tZmtij80NACeICSLzqpBW+jzWsh7AYzlRGP3 tqIAn1Gu5vkMDXJYmMyOnZvEVMGcWKuw =SOQ/ -----END PGP SIGNATURE-----
I am a bit surprised that the whole discussion is around only this part of the equation. What about the added benefit of the routing security this policy and subsequently deployed and adopted system can add?
Today, your network can be taken down by a simple misconfiguration or malicious attack without any court order.
not "can be." essentially, every day someone's prefix is mis-announced by someone else. some have been bad enough to make the press or nanog. most are unintentional. some are malicious. you don't have to swollow the pill that lets you see black helicopters to see this problem. you just have to be a network operator, not a wannabe net lawyer. randy
Sander, thank you for your reply. On Mon, May 9, 2011 at 4:01 PM, Sander Steffann <sander@steffann.nl> wrote:
Hi Martin,
You miss the next sentence of the legal advise: "In the absence of such legislation, a court cannot order the revocation of certificates."
I think the legal statement (when read as a whole, not cherry-picking the parts you like) was clear enough. Sander
Now if the statement could only guarantee for the future that it no court could do anything of the sort, it'd actually be useful. Since it doesn't, I think the sensible thing to do is to account for the fact that laws can change
I fully agree. Mind you, they could just as well just make a law that says "You may not route any packets to/from addresses that appear on list X" and we would have exactly the situation everyone seems to be afraid of, and it doesn't need RPKI. As soon as laws don't allow 'your network, your rules' anymore then anything can happen... But that is something that we'll have to steer through voting, not address policy :)
Now we're getting to a useful point in the discussion I think. :) See, I've come to learn so far in life that whenever something "becomes possible", lawyers, eavesdroppers and other state machinery wants to do it, and it's a very rough machine. How well does that "You may not route any packets to/from addresses that appear on list X" thing scale today? Is it technologically feasible? Does it stretch outside of judicial boundaries? And, the slippery slope has already been started upon, some nations have decayed further than others: See various block lists, DNS and other. "Your network, your rules", you said? I agree with what you said earlier about how LEA's ought to go for the source if they want to shut something done, and that is not a power I think it is reasonable to campaign for having taken from them. I did read http://www.intgovforum.org/cms/component/content/article/102-transcripts2010... , where Andrew isn't all too happy about RPKI by the looks of it. One thing he says, is: "So my question is, are we sure that RPKI would not produce the same problems? I'm very happy to be convinced to the contrary, but please do not -- more technology, because very frankly I cannot go back and tell that to the powers that be and (off microphone) the next three years hoping that nothing will happen, because something that will happen, then I will have to pay the price. I will go back to you and tell you, why didn't you tell me the truth? What were the risks? And we can discuss and try to find a solution." in reference to a technology that gave more power to one government than others. You can sort of conclude from this that the EU will want EU to have equal access to this new technology, and I can only infer/guess to their actual motives. Furthermore I do see relevance between the citation above and the discussion we're having, but it's possible me and Andrew are coming from two 180 degree separated vectors on this question. :) Sander, I remain fully unconvinced that lowering the effort for censoring the internet will make no or negative effect on the amount of censorship done. If you really think different, perhaps we should make a bet. :) Kind Regards, Martin
Hi Martin,
Sander, I remain fully unconvinced that lowering the effort for censoring the internet will make no or negative effect on the amount of censorship done. If you really think different, perhaps we should make a bet. :)
I personally think that law enforcement will find a way to do whatever it needs/wants/etc to do. With or without RPKI. I don't think RPKI makes a big difference in that in the long run. What is more important I think is what can be done when things go terribly wrong in some way (intentionally leaving the meaning of 'wrong' and 'some way' undefined here). If the NCC revokes all certificates and destroys the private key we will have the same internet as we have now: no validated routes, all routes are equal. Sounds like a possible emergency exit strategy... - Sander
Hi Sander, On Tue, May 10, 2011 at 3:44 AM, Sander Steffann <sander@steffann.nl> wrote:
Hi Martin,
Sander, I remain fully unconvinced that lowering the effort for censoring the internet will make no or negative effect on the amount of censorship done. If you really think different, perhaps we should make a bet. :)
I personally think that law enforcement will find a way to do whatever it needs/wants/etc to do. With or without RPKI. I don't think RPKI makes a big difference in that in the long run.
I still hold that availability of technology is an enabler for policies, and free-will implementation removes the need to make laws, which may or may not be subject to public scrutiny/affecting election outcomes, etc.
What is more important I think is what can be done when things go terribly wrong in some way (intentionally leaving the meaning of 'wrong' and 'some way' undefined here). If the NCC revokes all certificates and destroys the private key we will have the same internet as we have now: no validated routes, all routes are equal. Sounds like a possible emergency exit strategy...
It does, for RPKI, and it would be extremely useful if it was written in ink and published in very public places under under what circumstances it will be enacted. But it still does leave unhandled possible recourses or exit strategies for when things go terribly wrong in some way with the registry itself. What are our options in this case? Kind Regards, Martin
Hi,
But it still does leave unhandled possible recourses or exit strategies for when things go terribly wrong in some way with the registry itself. What are our options in this case?
Stop using them :) If it's not an LEA forcing you to do something then you always have this choice. Sander
Stop using them :) If it's not an LEA forcing you to do something then you always have this choice.
...and this is a point worth stressing. If things do "go bad," it isn't the end of the Internet, but we can bail on using the RPKI as it is implemented at the time. It's all about co-operation. :-) Rob
Hi, On Tue, May 10, 2011 at 9:20 AM, Rob Evans <rhe@nosc.ja.net> wrote:
Stop using them :) If it's not an LEA forcing you to do something then you always have this choice.
...and this is a point worth stressing. If things do "go bad," it isn't the end of the Internet, but we can bail on using the RPKI as it is implemented at the time. It's all about co-operation. :-)
What's the required escape velocity for the world to bail on RPKI if it is universally deployed? DNSSEC? A significant hurdle I believe, meaning not just a little but a substantial abuse must be on-going to reach that point. It's the inverse network effect. To me it seems you are both suggesting that we should start developing an alternative that we can bail to already, so that there is an actual meaningful exit strategy. What I'm wondering is, if the alternative is better than the original, why not go to it directly? Enabling a technology that enables an unfortunate legal lock-down, for example, is a grave error. At least in my book. Kind Regards, Martin
Hello WG, I am RIPE NCC staff, but having worked on this subject for some time now I have some technical input to the discussion that I would really like to share: On May 10, 2011, at 3:20 PM, Rob Evans wrote:
Stop using them :) If it's not an LEA forcing you to do something then you always have this choice.
...and this is a point worth stressing. If things do "go bad," it isn't the end of the Internet, but we can bail on using the RPKI as it is implemented at the time. It's all about co-operation. :-)
The 'risk' of the RIPE NCC going rogue under legal coercion could be modeled as the product of the (1) 'likelihood' and the (2) 'impact' (1) Regarding likelihood: - revoking certs is not enough - a top entity in the pki chain like the ripe ncc would also have to reallocate resources so that a new valid roa may be made for a different as and that network be announced This is both against all current ripe policies and several people have pointed out that legal feasibility is very low at this time. However I understand from the thread that not everyone is convinced. So that leaves: (2) Regarding impact (i.e. affecting real routing) The RPKI is not enabled automatically in routers. In fact if it is enabled the *information* is available in routers, but decisions are up to local policy. There are at least three layers where local policy may be enforced: 1) ROUTER ...by having additional configuration that overrides the rpki governed local preferences you just added yourself. Essentially this is not so different from what's going on now. People use many rules, some are maintained manually, others are scripted eg based on IRR. The rpki adds a powerful default rule set that people can use, but it is not the end of all configuration. Just don't think that one should just set up the default 'prefer certified routes' rules and forget about all other rules and exceptions... 2) VALIDATION TOOLS If people express the demand it's fairly easy to add whitelisting functionality to validation tools. This would mean that the router would not know the difference between an AS-Prefix tuple coming from a ROA in the RPKI or an entry on the whitelist. The same router config could be used in both cases. Having said that, please realise that the whitelist (presumably maintained by a 'trusted' third party), is in itself an attack vector. But the choice is yours... 3) LOCAL TRUST ANCHOR (LTA) See here: http://tools.ietf.org/wg/sidr/draft-ietf-sidr-ltamgmt/ This draft explains a method that allows a 'relying party' to take information from one (or more) source RPKI trees and build up a locally consistent tree. The party doing this will essentially copy data and use his own keys. This allows the party to be *more* restrictive, or *less* restrictive with regards to ROAs, certificates, validity times etc. (many more details in the draft) BBN has a reference implementation for this Local Trust Anchor handling. Note that existing validation tools can use this new Trust Anchor as a starting point without any modification needed to the tools. This technique can be used in two ways: a) more restrictive This technique enables LEA to set up their own TA tree under their own control. This can easily be done in the absence of a community run repository. In fact it's easiest on LEAs if the techniques are available (and they are coming out of the IETF now), and there are no disturbing other versions of the truth out there.. a whole lot less to delete.. b) less restrictive Third parties (many in theory) can set up and maintain public LTAs for others. If the RIPE NCC or any other player in the rpki is found to have inappropriately done something like revoking a certificate and re-allocating to someone else (as determined by the maintainer of the local trust anchor), then the maintainer can choose to keep using the old stuff. Please note that if you trust someone else to maintain such an LTA for you, they may also be susceptible to LEAs, bribes, threats, mistakes etc. But the choice is yours... and if in fact more than one party is doing this it will be fairly easy to switch. You will have to ask yourself who *you* trust most. Regards, Tim Bruijnzeels Senior Software Engineer RIPE NCC
Hi Tim, thank you for bringing forth clarity on LTA and answering the question of the availability of the code. On Tue, May 10, 2011 at 10:06 AM, Tim Bruijnzeels <tim@ripe.net> wrote:
Hello WG,
I am RIPE NCC staff, but having worked on this subject for some time now I have some technical input to the discussion that I would really like to share:
On May 10, 2011, at 3:20 PM, Rob Evans wrote:
Stop using them :) If it's not an LEA forcing you to do something then you always have this choice.
...and this is a point worth stressing. If things do "go bad," it isn't the end of the Internet, but we can bail on using the RPKI as it is implemented at the time. It's all about co-operation. :-)
The 'risk' of the RIPE NCC going rogue under legal coercion could be modeled as the product of the (1) 'likelihood' and the (2) 'impact'
(1) Regarding likelihood:
- revoking certs is not enough - a top entity in the pki chain like the ripe ncc would also have to reallocate resources so that a new valid roa may be made for a different as and that network be announced
(snip)
3) LOCAL TRUST ANCHOR (LTA) http://tools.ietf.org/wg/sidr/draft-ietf-sidr-ltamgmt/ This technique can be used in two ways:
a) more restrictive
This technique enables LEA to set up their own TA tree under their own control. This can easily be done in the absence of a community run repository. In fact it's easiest on LEAs if the techniques are available (and they are coming out of the IETF now), and there are no disturbing other versions of the truth out there.. a whole lot less to delete..
Excellent argument against hierarchical policy on the Internet, from my point of view.
b) less restrictive
Third parties (many in theory) can set up and maintain public LTAs for others. (threats to hierarchical systems removed) But the choice is yours... and if in fact more than one party is doing this it will be fairly easy to switch. You will have to ask yourself who *you* trust most.
What I trust *the most* is for the proper holders of a resource to attest to their own resource(s) *themselves*. If we allow ourselves the thought exercise to design a (BGP) routing security system without constraints and from scratch, would you agree the base model is something along the lines of the following? - "I can prove I have resource X and the right to originate it [into the network]", for origination, which may be a subset of: - "I can prove I have the right to announce resource X", for propagation/paths (which may or may not scale badly -- for example, the right or endorsement to re-announce a resource could be conceived as transferable from A to B, (!= NO_EXPORT, but related), possibly with transferability of the right to transfer the right to announce, as well :) (and if we get real picky A may steer the endorsement to only certain peers of B) ), in combination with, - a method for B to verify A:s proof of right to announce X, and, - for C (a peer of B), a method to verify B's right-to-announce X (functioning as endorsements). The gravest failure mode in this model I can think of is that A may lose its X against its will. Kind Regards, Martin
Hi, On Tue, May 10, 2011 at 11:38:46AM -0400, Martin Millnert wrote:
What I trust *the most* is for the proper holders of a resource to attest to their own resource(s) *themselves*.
So how do you determine which of the following attestations is true? "I permit 195.30.0.0/16 to be announced by AS5539" "I permit 80.81.192.0/22 to be announced by AS5539" AS5539 is my AS number, and one of those netblocks is mine, while the other one isn't. If I were trustworthy, and wouldn't make typing mistakes, you just would believe me that I'll only ever announce my netblocks - but reality shows that mis-announcements do happen, so the attestations are only useful if there is an authority that tells you that I'm indeed the holder of one of those blocks, and can do attestations about them... ... and that would be a hierarchical attestation following the allocation/assignment hierarchy. (Of course, my friends would know that I'm to be trusted, and could point a local trust anchor my way, but how would a network on the other end of the world know that?) Gert Doering -- 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 Doering wrote:
... and that would be a hierarchical attestation following the allocation/assignment hierarchy.
So we need an hierarchical certification system ... Welcome to DNSSEC. http://tools.ietf.org/html/draft-donnerhacke-sidr-bgp-verification-dnssec
So we need an hierarchical certification system ... Welcome to DNSSEC. http://tools.ietf.org/html/draft-donnerhacke-sidr-bgp-verification-dnssec
you are over a decade too late draft-bates-bgp4-nlri-orig-verif-00.txt randy
So we need an hierarchical certification system ... Welcome to DNSSEC. http://tools.ietf.org/html/draft-donnerhacke-sidr-bgp-verification-dnssec
you are over a decade too late. see draft-bates-bgp4-nlri-orig-verif-00.txt randy
Hi Gert, On Tue, May 10, 2011 at 11:47 AM, Gert Doering <gert@space.net> wrote:
Hi,
On Tue, May 10, 2011 at 11:38:46AM -0400, Martin Millnert wrote:
What I trust *the most* is for the proper holders of a resource to attest to their own resource(s) *themselves*.
So how do you determine which of the following attestations is true?
"I permit 195.30.0.0/16 to be announced by AS5539" "I permit 80.81.192.0/22 to be announced by AS5539"
AS5539 is my AS number, and one of those netblocks is mine, while the other one isn't.
If I were trustworthy, and wouldn't make typing mistakes, you just would believe me that I'll only ever announce my netblocks - but reality shows that mis-announcements do happen, so the attestations are only useful if there is an authority that tells you that I'm indeed the holder of one of those blocks, and can do attestations about them...
Yes, this is indeed the key issue. I'd like to single out the registry function you mention above, and separate it from that authority also having the power to lease out resources under some kind of notion that they can be called back. Clearly, as long as [people are in agreement that] resources are leased, the lessor will remain the single dominant authority over said resources, but this only works if there is also agreement that resources have been called back. This is quite different from stating that the only solution to my base routing security model is to lease out resources. So, are there other ways to organize a registry? (I don't want you to get stuck at too specific details since the following suggestion would need development work no doubt, but) the general idea is something along the lines of: Imagine you have a data file, let's say XML since it allows types and is reasonably clear-text, which states: <xml> <holder number=1> <asn>5539</asn> <contact-data>... ... </holder number=1> </xml> Now imagine you sign this file with a PKI crypt-system, using your private key. Following this you send this signed object to the RIPE NCC, because they're your current RIR. RIPE signs this blob irrevocably, with their own private key and may attach some other useful data, like perhaps a time stamp. You can now show up a signed object, signed *irrevocably* by the RIPE NCC (set validity=inf, /etc/init.d/crl-server stop), which now for all intents and purposes has become your ASN - it's come to life in this file and in doing so you can now do what you want with it, including sending out copies of it anyway you wish or running it through /usr/bin/shred . When the RIPE NCC signs this object, they in effect sign it over to you and should update their records accordingly. Repeat the same process for the netblock which is yours. The RIPE NCC won't sign the one which isn't registered to you over to you, though. There are issues with the RIPE NCC losing their key(s), signing away a previously un-signed-away resource to the wrong recipient, and also, later signing someone else's XML file signed with their private key, stating your ASN. A possible and interesting mitigation to part of the above may be to include your blob into a distributed database system, which perhaps use some time windowing to the effect that, at T=435 , there were 25644 incorporated objects, yours not included. Then, when you add one of your own, it will eventually after some form of system agreement get rolled into the ddb, which then rolls over to T=436 where it now has 25645 objects and yours is one of them. Doing something similar to this, I imagine you can be able to trace the existence of your resource or any later duplicates of your object in this system, which presumably would not get accepted into the system since they previously already exists. How to organize transfer of resources between parties is another chapter, but soluble no doubt. There are likely attacks possible against this system, both known and unforeseeable, and hopefully known ones can be mitigated (reaching agreement in rolling forward and ensuring correctness of data that is entered are the two single biggest issue I can think of right now). For correctness, there is probably no way to remove an object from the ddb without organizing sufficient a-prior agreement amongst the participants. It does not have any removeObject() calls. As always, you have to be careful with your private key. I guess it is free for people to organize their private keys best they wish. Perhaps some put a backup at the RIPE NCC? (Or under their pillow?) It's worthwhile to note that this ddb does not care whether or not the RIPE NCC did mark their records correctly (and that they stay that way) after they signed away a resource which then got incorporated into the ddb. The real remaining issue with the above is the RIPE NCC "signing away a previously un-signed-away resource", a problem it shares with RPKI, for which it was proposed there would be sanity checks in place. In the above, more than sanity checks are required to keep the ddb correct, however. Interesting topic that. If anything similar has been proposed before, I must have missed it.
... and that would be a hierarchical attestation following the allocation/assignment hierarchy.
(Of course, my friends would know that I'm to be trusted, and could point a local trust anchor my way, but how would a network on the other end of the world know that?)
See ddb above. Kind Regards, Martin
Hi, On Tue, May 10, 2011 at 01:25:21PM -0400, Martin Millnert wrote:
"I permit 195.30.0.0/16 to be announced by AS5539" "I permit 80.81.192.0/22 to be announced by AS5539"
[and needing some sort of document from RIPE NCC to say which one is true]
Yes, this is indeed the key issue. I'd like to single out the registry function you mention above, and separate it from that authority also having the power to lease out resources under some kind of notion that they can be called back.
Well, that's the IP resource assignment framework we have today: numbers are given out as long as they are needed, and given back when they are no longer needed (or under special circumstances, e.g. fraud involved). If you change that model to something where number blocks are actually traded ("Sold by the NCC to entity A, which can do then with the numbers whatever it want, e.g. sell to entity B without registering with the RIPE NCC"), the model would look different - and a trade could, for example, be done in your model by adding an "eternal signature" to the hand-over XML blob. So, assuming we want to keep the existing model of number resource allocations from the RIRs (and giving them *back* to the RIRs eventually), what can we do to have that reflected in whatever attestation system? It should be pointed out that the nice folks over at the anti-abuse WG would scream bloody murder if they hear about the notion of resources being given to spammers, scammers, phishers and whatnot, with no way to take them back... (and that's not "LEA type" anti-abuse folks, but "netizen" anti-abuse folks). Gert Doering -- 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
Hi Gert, On Tue, May 10, 2011 at 4:54 PM, Gert Doering <gert@space.net> wrote:
Hi,
On Tue, May 10, 2011 at 01:25:21PM -0400, Martin Millnert wrote:
"I permit 195.30.0.0/16 to be announced by AS5539" "I permit 80.81.192.0/22 to be announced by AS5539"
[and needing some sort of document from RIPE NCC to say which one is true]
Yes, this is indeed the key issue. I'd like to single out the registry function you mention above, and separate it from that authority also having the power to lease out resources under some kind of notion that they can be called back.
Well, that's the IP resource assignment framework we have today: numbers are given out as long as they are needed, and given back when they are no longer needed (or under special circumstances, e.g. fraud involved).
Yes, I agree with your description of the current model. And maybe it can be an healthy exercise to consider alternative solutions, if only to broaden the horizon a little on threats / possible mitigations, or, to reinforce the perception that what we do have is the best of what we can accomplish. There will soon be virtually no IPv4 for the RIRs to give out, despite need. And if we please may save ourselves from a "Internet Fairness Re-appropriation and Re-assignment Committe", clearly money will play a role in assessing IPv4 holders relative needs of address blocks in the future. Considering legacy resources, these may well trade hands without the involvement of a RIR if it is seen as too complex/expensive/pointless. So even if RIR transfer policy is infinitely simple and free, we still have to worry about how to keep transferred resources up-to-date in the registry. I understand that resource certification may come to play a role in this too. (The ddb solves this aspect too.)
If you change that model to something where number blocks are actually traded ("Sold by the NCC to entity A, which can do then with the numbers whatever it want, e.g. sell to entity B without registering with the RIPE NCC"), the model would look different - and a trade could, for example, be done in your model by adding an "eternal signature" to the hand-over XML blob.
I imagine something like that could be done, yes.
So, assuming we want to keep the existing model of number resource allocations from the RIRs (and giving them *back* to the RIRs eventually), what can we do to have that reflected in whatever attestation system?
First, I think it is quite hard to combine the goals of having the ability to revoke resources, with a fault-tolerant hierarchical routing registry/security system. Second, yes, we can polish up copies of resource certifications, even have lots of independent copies of them, and even the RIR data, but as long as resource registrations may be changed in the original registry without a method of rejecting unfortunate changes, we're left with copies of the duplicated data that over time increasingly will be disagreeing with the registry data. Thus, if ever so slowly, we will move towards a somewhat ad-hoc ("distributed") chaos model. ("with t->\inf, quality(rir data) -> 0" points to a flaw in the model IMHO.) I think Sander and Rob started up on a good trail, when working within the current model of number resource allocations, by having emergency exit-strategies. But it's hard to see how this can work in practice without some effective method to implement them. I do like the LTA magic of rewriting the root (or somewhere else) of a hierarchical system onto yourself. As I've expressed before, if the community does end up going for RPKI, I'd seriously like to see more software which can cook up alternative trees, ignoring certain changes, comparing source data trees and so on and so forth. (diluting accuracy of RIR data)
It should be pointed out that the nice folks over at the anti-abuse WG would scream bloody murder if they hear about the notion of resources being given to spammers, scammers, phishers and whatnot, with no way to take them back... (and that's not "LEA type" anti-abuse folks, but "netizen" anti-abuse folks).
If a network wants to filter out certain prefixes they have the choice of doing so, right? Not sure how this is at all relevant in an automated filtering world of free choice. Kind Regards, Martin
Gert Doering wrote: [...]
... and that would be a hierarchical attestation following the allocation/assignment hierarchy.
An attempt to KISS: What we (at least some of us) want to avoid is a single-point-of-failure. Looking back in history, I can remember discussions to find ways around the (then perceived) SPoF of ICANN + US.fed.law, regarding management of the DNS Root. What some of us pondered was to get the whole system easily replicated. Thus - how about leveraging the fact that we do have *5* such entities, around the world, both geographically as well as jurisdiction-wise well- distributed. What prevents us from obtaining *more than one* attestation proving proper resource holdership? I'd assume that any single pressure or interst group would then not consider it easy - and thus useful - to try to cripple all of those valid copies at the same time.
(Of course, my friends would know that I'm to be trusted, and could point a local trust anchor my way, but how would a network on the other end of the world know that?)
Gert Doering
Wilfried.
thank you for bringing forth clarity on LTA and answering the question of the availability of the code.
to repeat what i said at the mic. the lta doc merely describes how the existing specs can be used in a twisted manner to let a part have their special view of reality. it is inherent in *all* relying party code. randy
Sander, On Mon, May 9, 2011 at 4:01 PM, Sander Steffann <sander@steffann.nl> wrote:
As soon as laws don't allow 'your network, your rules' anymore then anything can happen...
A follow-up: http://www.govtrack.us/congress/bill.xpd?bill=s112-968 A response: http://www.redbarn.org/files_redbarn/PROTECT-IP-Technical-Whitepaper-Final.p... Regards, Martin
As soon as laws don't allow 'your network, your rules' anymore then anything can happen...
if you think that laws have allowed 'your network, your rules' any time in the last couple of decades, you should share what you are smoking. randy
if you think that laws have allowed 'your network, your rules' any time in the last couple of decades, you should share what you are smoking.
Point taken :) Sander Co-chair of the RIPE APWG / ALPG
Randy, On Sat, May 28, 2011 at 4:52 AM, Randy Bush <randy@psg.com> wrote:
As soon as laws don't allow 'your network, your rules' anymore then anything can happen...
if you think that laws have allowed 'your network, your rules' any time in the last couple of decades, you should share what you are smoking.
This is certainly true. The internet is part of our society much like a public square is (borrowed expression). It's important to point out that the recent eG8 debates[1] on strict Internet regulation and a "civilized Internet", championed by Nicolas Sarkozy, is a view not shared by all governments, and any take-away from that get-together *must not* assume so. (It's not clear exactly what was proposed anyway, and consensus was not really there.) Certainly, a lot of people, as evident in the debate, do not wish to see more of the Sarkozy regulation. It's noteworthy that at the same time Sarkozy and a few other speak of decreasing Internet freedoms, Iran is moving forward with its closed-off Halal Internet (where are the, morally just, trade embargoes on selling Internet censorship equipment to certain countries, I wonder?). The Swedish foreign minister, Carl Bildt, had this opening announcement to the session "Internet for Democracy, a tool, a trap, or what?" at the EuroDIG 2011 which opened today: http://www.youtube.com/patrikhson#p/a/u/0/GLLpW4s7WTo Additionally, the Special Rapporteur to the UN on Freedom of Expression, Frank la Rue has this to say recently [2]: D. Disconnecting users from Internet access, including on the basis of violations of intellectual property rights law 49. While blocking and filtering measures deny access to certain content on the Internet, States have also taken measures to cut off access to the Internet entirely. The Special Rapporteur is deeply concerned by discussions regarding a centralized “on/off” control over Internet traffic. All is not lost. And right now is a *particularly* bad time to make any hasted moves in the wrong direction, I would say. Regards, Martin [1] http://stupid.domain.name/node/1348 [2] http://stupid.domain.name/node/1341
As soon as laws don't allow 'your network, your rules' anymore then anything can happen... if you think that laws have allowed 'your network, your rules' any time in the last couple of decades, you should share what you are smoking.
This is certainly true. The internet is part of our society much like a public square is (borrowed expression).
It's important to point out that the recent eG8 debates[1]
warning: you are leaving the real internet and entering a large, possibly infinite, gas cloud of political bullshit. tinfoil hats, kevlar undies, and nose plugs must be worn at all times. please report any signs of reality to the flight crew in case there could be a small chance of finding our way back to earth. thank you, and thanks for flying layer ten space lines. randy
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 31/05/2011 06:50, Randy Bush wrote:
warning: you are leaving the real internet and entering a large, possibly infinite, gas cloud of political bullshit.
Sarkozy has clearly described the political imperative. 2008-08 provides (some of) the tools to carry it out. You call Sarkozy's vision "political bullshit"? Tough. He's in charge, you're not. If you build the tools, political leaders like Sarkozy will ensure they get used. Do you really think you can hold off this outcome by calling politicians rude names? - -- 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/ iEYEARECAAYFAk3kn40ACgkQJiK3ugcyKhRONgCgs3MxpktJwqetiOcLBqdSjkoB uv0An188b+bg9WYcYyh0i4d8W/jWs7+7 =oSfv -----END PGP SIGNATURE-----
Hi, On Tue, May 31, 2011 at 08:58:05AM +0100, Malcolm Hutty wrote:
You call Sarkozy's vision "political bullshit"? Tough. He's in charge, you're not. If you build the tools, political leaders like Sarkozy will ensure they get used.
Sarkozy is not in charge in Holland, and his visions are not *that* popular outside France. RIPE policy is not the ideal place to fix broken political approaches - they have their own processes for that, and it works (look at what we did in DE with the internet access denial law that *did* get removed after enough political work in the proper channels). Gert Doering -- APWG chairs -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 31/05/2011 09:06, Gert Doering wrote:
RIPE policy is not the ideal place to fix broken political approaches
If after all this discussion you still think those criticising 2008-08 are the ones trying to "fix broken political approaches" through RIPE policy I don't see how we're ever going to agree. - -- 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/ iEYEARECAAYFAk3kqigACgkQJiK3ugcyKhTDlwCfQOSSH6875UQ3w12dIuPfNs0/ vH8Anj/IKMp4iiwd83AQsu3SOSB/1D9W =+Cbx -----END PGP SIGNATURE-----
Hi Malcolm,
If after all this discussion you still think those criticising 2008-08 are the ones trying to "fix broken political approaches" through RIPE policy I don't see how we're ever going to agree.
It's not about agreeing at this point in time, it's about moving forward: at the last RIPE meeting you said that RPKI has risks what we shouldn't take without thinking about them and without looking for alternatives. In the hallway after the discussion you promised me to do research. As far as I can remember you would: 1) study the discussions in the IETF and other places to see why RPKI design decisions were made the way they are 2) see if there is a better way to secure routing that provides (90%-100%) the same benefits without the major risks as you see them 3) of course taking 1 into account while doing 2 Can you give us a status update on this? Thanks, Sander
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 31/05/2011 09:54, Sander Steffann wrote:
It's not about agreeing at this point in time, it's about moving forward: at the last RIPE meeting you said that RPKI has risks what we shouldn't take without thinking about them and without looking for alternatives. In the hallway after the discussion you promised me to do research. As far as I can remember you would: 1) study the discussions in the IETF and other places to see why RPKI design decisions were made the way they are 2) see if there is a better way to secure routing that provides (90%-100%) the same benefits without the major risks as you see them 3) of course taking 1 into account while doing 2
Can you give us a status update on this?
You make it sound like I agreed to single-handedly solve the problem in all its various aspects. Not so. The only pointer anyone has given me to explain why 2008-08 incorporates the RPKI architecture that it does is "Go read the SIDR mailing list archive". So I had a look at that, but as far as I can understand they took the RPKI architecture as an input from previous work. So the reasons why this was picked seem to lie elsewhere, although I'm not sure where that is. Any better pointers to the actual discussion and decision-making would be welcome. What worries me about the questions you set me above is that it reads as though you expect me to single-handedly design an alternative solution that meets 2008-08's goals while also satisfying the criticisms. As I said in the hallway, the technical work on producing an alternative approach would have to be led by someone expert in that area, which I am not. If such work is done, I believe I can contribute usefully by helping to identify whether an alternative does indeed reduce the risk of the foreseeable consequences I've identified with 2008-08. For example, in the hallway we discussed a couple of ideas for variations on 2008-08 (distributed certification and decentralised CAs). These did seem to tackle the problems of centralisation with 2008-08, and so seem to me to be worthy of investigation, but developing the idea into an approvable policy proposal should be done by someone else. To reiterate: I am happy to contribute. However, if the design of this is in the hands of the IETF not RIPE, then I have to ask whether there any point in us designing an alternative? Or is the only decision for this WG a simple YES/NO on whether the community wants RIPE NCC to implement the IETF work? If the latter, what I have already said is probably sufficient. I must confess my ignorance on the scope available to us, and ask for your guidance. In any case, my own core relevant expertise lies in correcting some of the misinformation propagated here about "black helicopters" and so forth, by providing concrete information on public policy developments in progress, and filling in the information gap left by the RIPE NCC's legal advice, which disclaims advising upon the likelihood and likely consequences of future changes in the law (I'm not criticising the lawyer for leaving this gap: that area is essentially Public Affairs advice not legal advice). I suggest that this is important input to this WG's decision as to whether it believes 2008-08 (or any successor proposal) is in fact useful, i.e. whether it is likely to do more good than harm. 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/ iEYEARECAAYFAk3kxDQACgkQJiK3ugcyKhS9uwCgrl/fYP62Y/tMwCGfOy9h1Xh5 CVoAoMmztYz0XGVIyW6XXRK5RDa6dciR =Thdg -----END PGP SIGNATURE-----
Hi Malcolm,
You make it sound like I agreed to single-handedly solve the problem in all its various aspects.
Not so.
Certainly not single-handedly, but I though you would take the initiative and gather input from experts.
[...]
However, if the design of this is in the hands of the IETF not RIPE, then I have to ask whether there any point in us designing an alternative?
If the alternative fits in the framework that the IETF has designed: yes
Or is the only decision for this WG a simple YES/NO on whether the community wants RIPE NCC to implement the IETF work?
If the latter, what I have already said is probably sufficient.
I must confess my ignorance on the scope available to us, and ask for your guidance.
I think the current scope should be: can we find a way that satisfies your concerns while staying within the RPKI framework that the IETF has designed. Once we have the answer to that question we can look at the next step.
In any case, my own core relevant expertise lies in correcting some of the misinformation propagated here about "black helicopters" and so forth, by providing concrete information on public policy developments in progress, and filling in the information gap left by the RIPE NCC's legal advice, which disclaims advising upon the likelihood and likely consequences of future changes in the law (I'm not criticising the lawyer for leaving this gap: that area is essentially Public Affairs advice not legal advice).
I don't think this is the place for discussions about possible future law changes. *anything* can be changed in the law, and the usual way to influence that is through voting. We deal with the current situation, and if the landscape changes we can always start a new policy proposal.
I suggest that this is important input to this WG's decision as to whether it believes 2008-08 (or any successor proposal) is in fact useful, i.e. whether it is likely to do more good than harm.
I was just thinking: are these problems really about the RIPE NCC providing certification services for the resources they hand out, or is this about big router vendors implementing route-origin-code in their OS? I mean: that is the part that actually influences routing, and the data used there can come from RPKI but also from other sources. You seem to be concerned that governments can force ISPs to use RIPE NCC issued ROAs for this, and then force the RIPE NCC to revoke/reissue ROAs. Why would governments take this legally difficult path and not just force ISPs to use government-supplied data as input for their routers? The more I think about it the more I feel that governments have *many* easier ways to influence routing than the ways you are worried about... Sander
Hi Sander, On Tue, May 31, 2011 at 11:16 AM, Sander Steffann <sander@steffann.nl> wrote:
I don't think this is the place for discussions about possible future law changes. *anything* can be changed in the law, and the usual way to influence that is through voting. We deal with the current situation, and if the landscape changes we can always start a new policy proposal.
One guy makes some gunpowder. Another a shell casing. A third puts some of the former in the latter. A fourth makes a chamber. A fifth makes a coil. .... Eventually there's a gun. For good or bad. We're kind of saying, let's not make the shell casing if it is likely that the gun will be used for more bad than good.
You seem to be concerned that governments can force ISPs to use RIPE NCC issued ROAs for this, and then force the RIPE NCC to revoke/reissue ROAs. Why would governments take this legally difficult path and not just force ISPs to use government-supplied data as input for their routers?
Governments tend to be good at legal work and not so much routing infrastructure (though they're trying in Iran). If they have one interfacing point, the RIPE NCC, which they and LEAs are already familiar with, why not use it? If ISPs as a result of their use of RIPE NCC to protect citizens from harmful ideas and information decide to not use the RIPE NCC trust anchor, they tend to remedy that with laws. In my view, the risks are certainly not solely with the RIPE NCC certifying resources according to IETF and SIDR-compatible ways, but it's a key piece.
The more I think about it the more I feel that governments have *many* easier ways to influence routing than the ways you are worried about...
Assuming there is a ripencc.LEAandGovAPI.makePrefixGoAway(prefix) API, do you still think there are easier ways for one EU member state to make a route go away in a vast area? That seems pretty easy to me. Best, Martin
One guy makes some gunpowder. Another a shell casing. A third puts some of the former in the latter. A fourth makes a chamber. A fifth makes a coil. .... Eventually there's a gun. For good or bad.
let's outlaw metal. it will also solve the knife problem. guns can not be used for good. knives can be used for good and bad, and are mostly used for good. perhaps we should treat knives and guns differently. and, perhaps, the root problem lies in we silly humans and intent. which was the point of my preso, ripe should signal as constructive intent as reasonably possible. randy
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Malcolm Hutty wrote on 5/31/11 12:34 PM: [...]
I suggest that this is important input to this WG's decision as to whether it believes 2008-08 (or any successor proposal) is in fact useful, i.e. whether it is likely to do more good than harm.
I'd like to note that RPKI is essentially an opt-in technology. Without issuing a ROA, which is an ISP decision, not much changes compared to how things are today. We are not switching on secure routing with adopting this policy, the ISPs will have plenty of time to decide for themselves what the fear more - route hijacking or some crazy law wiping their network out. Andrei -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3lCjQACgkQljz5tZmtij8yFQCgpUZ36e+d8LhoyB0T7HixR6Lg +KcAoLtclX30uvfUCC+DCPRySFFTXnSj =o0N4 -----END PGP SIGNATURE-----
On 31 May 2011, at 16:33, Andrei Robachevsky wrote:
I'd like to note that RPKI is essentially an opt-in technology.
Depends on your definition Andrei. Once upstream ISPs insist on ROAs, the choice of opting in (or out) is made for you.
On 31 mei 2011, at 17:44, Jim Reid <jim@rfc1035.com> wrote:
On 31 May 2011, at 16:33, Andrei Robachevsky wrote:
I'd like to note that RPKI is essentially an opt-in technology.
Depends on your definition Andrei. Once upstream ISPs insist on ROAs, the choice of opting in (or out) is made for you.
True, for those who borrow address space from their upstreams, but many other choices are made for them anyway. I meant more than 7000 holders of PA allocations, and many more PI holders in the future. Andrei
On 31/05/2011 18:19, Andrei Robachevsky wrote:
I meant more than 7000 holders of PA allocations, and many more PI holders in the future.
I think these were the address holders that Jim was referring to. Nick
On 05/31/2011 05:44 PM, Jim Reid wrote:
On 31 May 2011, at 16:33, Andrei Robachevsky wrote:
I'd like to note that RPKI is essentially an opt-in technology.
Depends on your definition Andrei. Once upstream ISPs insist on ROAs, the choice of opting in (or out) is made for you.
I don't think they'll adopt this quickly. It's a new technology, not widely supported by vendors yet (on all platforms used for routing, that means not only "flag ships"), some large operators are also conservative in terms of any changes, even in running software... It's also a bussines case - upstream ISPs will not force their customers to RPKI. They'll loose their money, if they will... Even I'm supporting this technology, I don't make illusions here. Lessons learned from "speed" of IPv6 adoption should be taken in account. So this technology should be handled as opt-in... - Daniel
Hi, On Tue, May 31, 2011 at 09:43:20AM +0100, Malcolm Hutty wrote:
On 31/05/2011 09:06, Gert Doering wrote:
RIPE policy is not the ideal place to fix broken political approaches
If after all this discussion you still think those criticising 2008-08 are the ones trying to "fix broken political approaches" through RIPE policy I don't see how we're ever going to agree.
Well, *I* don't have to agree with anyone. I'm here to steer the process. I just hope that the community will eventually agree on something. (And no, as far as things go, it does not look like the community will agree on anything here - one side sees real problems in the addressing hijack realm and considers that important to have spend a number of years in building a technical solution to that, while the other side sees that as a minor nuisance compared to the percieved dangers of a government doing bad things. How can you ever agree?) 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 Tue, May 31, 2011 at 10:57 AM, Gert Doering <gert@space.net> wrote: <snip>
I just hope that the community will eventually agree on something.
(And no, as far as things go, it does not look like the community will agree on anything here - one side sees real problems in the addressing hijack realm and considers that important to have spend a number of years in building a technical solution to that, while the other side sees that as a minor nuisance compared to the percieved dangers of a government doing bad things. How can you ever agree?)
How can the "risk" of the government being minimized or limited? Or maybe being build in such a way that its not easy/possible for government to do damange? (quite impossible task since the government pretty much can do whatever they want when they are in power... and the power are giving to them by the people in most countries) ... and yes, the problem are there on the hijack side, don't think many disagree on that.. -- Roger Jorgensen | rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no
Hi,
How can the "risk" of the government being minimized or limited? Or maybe being build in such a way that its not easy/possible for government to do damange? (quite impossible task since the government pretty much can do whatever they want when they are in power... and the power are giving to them by the people in most countries)
My personal opinion is that the best way to stop any abuse in the future is to leave open the possibility of reverting 2008-08 in the future when such abuse becomes a reality. And we already have that possibility already: a proposal to withdraw or change a policy will always be handled according to the PDP (Policy Development Process). If things go really bad we can change the policy, the NCC can shut down the CA and all certificates can be withdrawn. The end result will be the same internet as we have today: one without (valid) certificates for resources. As long as the certificate system doesn't get abused we get to enjoy the benefits... It will take some time (it can be done in about 10 weeks) to do this should the need ever occur, but as this is a last-resort exit strategy I think this is acceptable. Is this an acceptable solution for everybody?
... and yes, the problem are there on the hijack side, don't think many disagree on that..
And I would really like to get a solution for this problem, because I am much more afraid of IPv4 address space hijacks once the NCC IPv4 pool runs out... Thanks, Sander Explicitly not speaking as WG chair!
On Wed, Jun 01, 2011 at 11:04:05PM +0200, Sander Steffann wrote:
It will take some time (it can be done in about 10 weeks) to do this should the need ever occur, but as this is a last-resort exit strategy I think this is acceptable. Is this an acceptable solution for everybody?
the absolute minimum I would accept is a sunset clause (ie the policy will run to a fixed date (say 2 years away) and will not be in force unless explicitly prorogued thereafter)
And I would really like to get a solution for this problem, because I am much more afraid of IPv4 address space hijacks once the NCC IPv4 pool runs out...
In my book that is an argument against it. Anything that prolongs the IPv4 pain, especially at the cost of having a censorship infrastructure imposed on *all* internet routing (not just v4) can't be good... rgds, s.
In my book that is an argument against it. Anything that prolongs the IPv4 pain, especially at the cost of having a censorship infrastructure imposed on *all* internet routing (not just v4) can't be good...
Sorry, you lost me there... I was talking about preventing IPv4 pain. IPv4 will still be important for many years. I wish there was enough IPv6 deployed to avoid this, but there isn't. A year from now the NCC won't have any new IPv4 addresses to hand out, while the majority of communication on the internet will still use IPv4. Our task is to keep the internet running as smoothly as possible. (Unfortunately) this still includes IPv4. Sander
Hi, On Wed, Jun 1, 2011 at 5:04 PM, Sander Steffann <sander@steffann.nl> wrote:
Hi,
How can the "risk" of the government being minimized or limited? Or maybe being build in such a way that its not easy/possible for government to do damange? (quite impossible task since the government pretty much can do whatever they want when they are in power... and the power are giving to them by the people in most countries)
My personal opinion is that the best way to stop any abuse in the future is to leave open the possibility of reverting 2008-08 in the future when such abuse becomes a reality. And we already have that possibility already: a proposal to withdraw or change a policy will always be handled according to the PDP (Policy Development Process). If things go really bad we can change the policy, the NCC can shut down the CA and all certificates can be withdrawn. The end result will be the same internet as we have today: one without (valid) certificates for resources. As long as the certificate system doesn't get abused we get to enjoy the benefits...
It will take some time (it can be done in about 10 weeks) to do this should the need ever occur, but as this is a last-resort exit strategy I think this is acceptable. Is this an acceptable solution for everybody?
No. First and foremost I do not want a hierarchical, centralized routing control infrastructure on the Internet. I think the bad outweigh the good by far. I do not oppose a fully decentralized secure/trusted routing, but by design, my peers should provide me this information. No single authority should be allowed to speak on behalf of others, unless *they* grant that power to it. And for this, the core issue to solve is resource holder/ownership identification -- which seems to me to contradict the current RIR model. And this tells me that we have a much, much larger problem at our hands for the future, made blatantly evident by these debates. By extension, this means that the RIPE NCC cannot run a trust anchor in the intended way, and there should be no deployed technology in routers supporting a trust anchor such as the proposals today in the first place, since it invites abuse and censorship even if the RIPE NCC itself does not run one, because someone else could. If, for argument's sake, doing the right thing is impossible, and consensus really is that doing something is better than doing nothing in this matter, the RIPE NCC should have very clearly defined (but not limited-to) set of rules for when the hierarchical, centralized routing control infrastructure self-destructs *up front*, such that it would be pointless to attempt to abuse it in this way. This suggests that the "self-regulation" we perform, overrules law, since abusive laws is what we fear. Additionally, since the attack will be on the integrity of registry itself, this essentially means we need a complete fail-over registry... If you think this can work, then this may be a useful approach. :)
... and yes, the problem are there on the hijack side, don't think many disagree on that..
And I would really like to get a solution for this problem, because I am much more afraid of IPv4 address space hijacks once the NCC IPv4 pool runs out...
I'm not afraid at all. It's quite easy to detect incorrect origins today, not sure why that would change. Run-out suggests further incentives to ramp up the traditional IRR filtering. (I'm not suggesting IRR filtering is the optimal solution to securing routing on the Internet, but that should be pretty obvious given what I wrote above.) Increased censorship is a clear and present danger. It's our duty to confront this danger wherever we can. Best, Martin
First and foremost I do not want a hierarchical, centralized routing control infrastructure on the Internet.
nice words, but let's see the reality. when will you be closing the IRR? and how will you decentralize address allocation so the hierarchy can not revoke your addresses? randy
On 02/06/11 00:01, Martin Millnert wrote:
Increased censorship is a clear and present danger. It's our duty to confront this danger wherever we can.
I agree, but don't forget that trust goes both ways. In that sense it is essential to note that the RIR's registrants are not isolated to one particular jurisdiction. Your worry would be valid for any national IP resource registry, but not for any of today's regional registries. Several countries already operate a centrally managed list of prefixes which all ISP's who operate within the country are required to block (in practise peer with a BGP-box and null-route any pfx it announces). Yet more governments are considering/planning such activities. Lawyers and politicians involved with such schemes may initially be excited by the idea of using centralised/international registers, but quickly realise that an attempt to corner the operator of a central registry may destroy its authority outside the jurisdiction within which the particular registry operates. Not only would it undermine their filtering/censoring efforts, but it would also ruin the technical/operational value of the registry's certificates. The big threat to freedom of speech through censorship would come via global or regional treaties in which case all bets are off. The existence of a central registry might simplify censoring efforts initially, while the absence of such is no long term guarantee against it. //per
How can the "risk" of the government being minimized or limited?
i think the belgians are the only ones to successfully deal with this problem at the root. if society allows people who have guns, bombs, or a lot of trademark lawyers, playing junior lawyer with silly policies is pretty irrelevant. as we are seeing time and time again in egypt, the united states, the uk, france, ... randy
* Malcolm Hutty:
Sarkozy has clearly described the political imperative. 2008-08 provides (some of) the tools to carry it out.
The difference between 2008-08 and the current situation is that once 2008-08 is widely implemented, withdrawing someone's Internet access at the BGP level requires some sort of court or law enforcement action (the latter under public order legislation). Right now, nearly anybody can play with announcements, with potentially global impact. -- 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
The difference between 2008-08 and the current situation is that once 2008-08 is widely implemented, withdrawing someone's Internet access at the BGP level requires some sort of court or law enforcement action (the latter under public order legislation). Right now, nearly anybody can play with announcements, with potentially global impact.
s/can/does/. happens daily. though almost all are accidents. randy
On Wed, Jun 01, 2011 at 12:02:25PM +0300, Randy Bush wrote:
anybody can play with announcements, with potentially global impact.
s/can/does/. happens daily. though almost all are accidents.
So, a few accidents with rarely any noticeable impact (At least I don't notice any major connectivity issues every day) Yet, also daily, I read about an attempt by $someone to censor, cut off or otherwise regulate somebody else's internet access. You have to excuse me for not quite believing that this attempt to impose a centralised structure upon internet routing has anything to do with preventing someone from fat-fingering a prefix advertisement... rgds, s.
Hi,
So, a few accidents with rarely any noticeable impact (At least I don't notice any major connectivity issues every day)
That you haven't noticed any impact doesn't mean it does not happen. That is a rather selfish attitude... Think of what will happen when someone else starts announcing *your* prefix.
Yet, also daily, I read about an attempt by $someone to censor, cut off or otherwise regulate somebody else's internet access.
Well, I can't deny this. Governments regulate. That is their job... If you don't agree with what they choose to do I think voting for a different party is a good way to start.
You have to excuse me for not quite believing that this attempt to impose a centralised structure upon internet routing has anything to do with preventing someone from fat-fingering a prefix advertisement...
Fat-fingering, intentionally mis-announcing (hijacking address space, announcing address space of a customer after they left, ...), etc. But let's stick to facts instead of belief... :-) Sander
On Wed, Jun 01, 2011 at 11:29:22PM +0200, Sander Steffann wrote:
Hi,
That you haven't noticed any impact doesn't mean it does not happen. That is a rather selfish attitude... Think of what will happen when someone else starts announcing *your* prefix.
That has already happened (due to a misunderstanding). The world didn't end. Didn't end when .pk announced youtube either. The internet has survived for 40 years without such an infrastructure , in fact probably *because* there was no such infrastructure.
Well, I can't deny this. Governments regulate. That is their job... If you don't agree with what they choose to do I think voting for a different party is a good way to start.
LOL, tell that to the people in Syria, Belorus, Iran... Once upon a time I, too, was naive enough to think the "other party" isn't being paid by the exact same people... cheers, s.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somewhat inevitably, starting a discussion about how 2008-08 would be received by those with legal power (not just governments), led us if not off-topic then at least into a broad discussion that confuses the real issue before us. I believe the question that this WG has to answer is "Do we believe that, on balance, adopting this policy will do more harm than good?". I suggested that adopting and deploying 2008-08 might over time result in more route hijacking rather than less, when you include the risk of hijacks conducted under legal compulsion. If I may summarise the answers I've heard by way of caricature, they are: - - "you're imagining things you silly conspiracy theorist" - - "if you don't like what the government does vote for someone else" - - "this will help prevent hijack attempts by criminals, which is our responsibility; preventing hijack attempts by lawyers is not our responsibility". (There was also "we've been working on this for years and spent loads of money, we can't stop now" and "do you have a better idea?", but neither of these address the question of whether this does more harm than good). Like most people, I don't want to continue reciting the arguments indefinitely. Nonetheless, I should say clearly that I don't find that any of the arguments that fall within the categories caricatured above make me feel any more comfortable that 2008-08 is a good and necessary proposal or that the world will be a better place if it is adopted. It seems that a number of other people also believe 2008-08 is negative on balance. Presumably the WG chairs will therefore conclude there is no consensus in its favour. I remain interested to hear the answer to my question about what the RIPE NCC intends to do if there is no consensus to approve 2008-08. 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/ iEYEARECAAYFAk3nXUQACgkQJiK3ugcyKhT7vwCgu6AnSQzUUcvMV9gw8OYNLEog Fi8AoN1miGAlveZObNsUkFGlPcPNURD8 =SI5N -----END PGP SIGNATURE-----
Hi Malcolm,
It seems that a number of other people also believe 2008-08 is negative on balance. Presumably the WG chairs will therefore conclude there is no consensus in its favour.
Correct. Based on the current input we can definitely not declare consensus.
I remain interested to hear the answer to my question about what the RIPE NCC intends to do if there is no consensus to approve 2008-08.
So am I. Sander
On 02/06/2011 11:52, Malcolm Hutty wrote:
I remain interested to hear the answer to my question about what the RIPE NCC intends to do if there is no consensus to approve 2008-08.
Malcolm, all, This issue will be on the agenda for the next Executive board meeting, during the second week of June. You are asking an interesting question. We have been doing the development work on the basis of our Activity Plan, which in turn is based on community requests to implement the RPKI system. How and in which direction do we progress with hundreds of members showing active interest in using the system, while others are debating the dangers? The policy you are discussing is needed to regulate operations of the system. Until we have an agreed policy in place, we can only operate a sandbox system that should not be relied upon. The ongoing discussion is crucial, I am actually very happy that it happens. Those present at the Lisbon meeting will remember that we tried to stimulate exactly what is happening now. Having talked to Rob recently, we agree that making RPKI / resource certification a programmatic focus throughout the Vienna meeting might be a good idea. cheers, Axel
Sascha, On Jun 1, 2011, at 11:11 AM, Sascha Luck wrote:
On Wed, Jun 01, 2011 at 12:02:25PM +0300, Randy Bush wrote:
anybody can play with announcements, with potentially global impact.
s/can/does/. happens daily. though almost all are accidents.
So, a few accidents with rarely any noticeable impact (At least I don't notice any major connectivity issues every day)
This could either mean your prefix isn't getting hijacked (others are) or the hijacking is being done in such a way that you don't notice. It doesn't mean that hijacking doesn't occur and isn't a significant problem. RPKI provides an infrastructure that would allow for tools to be built that could address this problem.
Yet, also daily, I read about an attempt by $someone to censor, cut off or otherwise regulate somebody else's internet access.
Not sure about daily, but yes, this is a problem. I have absolutely no doubt that if a tool exists that allows politicians to claim they're doing something to solve "a problem", they'll use it.
You have to excuse me for not quite believing that this attempt to impose a centralised structure upon internet routing has anything to do with preventing someone from fat-fingering a prefix advertisement...
It really does have something to do with preventing fat-fingering (or perhaps more accurately, reduces the impact of that fat-fingering). The main arguments I've heard (some cynical, some not) for RPKI have been: - allow for SIDR deployment - allow for the RIRs to enforce their policies - allow for the RIRs to have a viable business model after IPv4 is exhausted - allow the existing address hierarchy model to be enforced (disallow 'alternative address registries') Other folks might have heard other arguments. Regards, -drc
On Wed, Jun 01, 2011 at 11:49:04AM -1000, David Conrad wrote:
- allow for SIDR deployment - allow for the RIRs to enforce their policies - allow for the RIRs to have a viable business model after IPv4 is exhausted - allow the existing address hierarchy model to be enforced (disallow 'alternative address registries')
Well, probably time someone actually said it. It makes more sense than some global government conspiracy, however: the fact that NCC had a happy-clappy "very cordial" meeting with SOCA (yes, the Internet is Serious and Organised Crime in the UK) makes me wonder. rgds, s.
Hi, On Wed, Jun 01, 2011 at 10:11:10PM +0000, Sascha Luck wrote:
Well, probably time someone actually said it. It makes more sense than some global government conspiracy, however: the fact that NCC had a happy-clappy "very cordial" meeting with SOCA (yes, the Internet is Serious and Organised Crime in the UK) makes me wonder.
One of the tasks the NCC is mandated by the NCC members to do is "make sure that the governments of our region understands how the Internet works, how Internet self-regulation works, and that it's better to leave us alone". This is why those good people attend ITU meetings, meet with LEAs, etc. - to make sure those "political accidents" that everybody is afraid of do *not* happen. There's serious dangers here, like "why should a private entity be allowed to rule address governance in Europe? The european commission and the national governments are much better suited to do that!" - and the NCC works togethe with these folks to make them see that our way *works* and we need no extra regulation... 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 2 Jun 2011, at 10:20, Gert Doering wrote:
On Wed, Jun 01, 2011 at 10:11:10PM +0000, Sascha Luck wrote:
the fact that NCC had a happy-clappy "very cordial" meeting with SOCA (yes, the Internet is Serious and Organised Crime in the UK) makes me wonder.
About what Sacha? Do you think it's a Bad Idea for the NCC to engage with law enforcement and have a good relationship with them? If so, why? FYI SOCA currently has responsibility for dealing with computer crime in the UK. From a practical point of view, this is very helpful. For example, there's a single point of contact and a clear process to follow, both for the NCC and the cops. The NCC doesn't have to deal with local UK law enforcement or figure out if a request from Detective Sherlock Holmes of Strathclyde Police is genuine or not. We've also had SOCA come to the co-op WG at RIPE meetings a few times, something we should welcome and encourage because that helps develop mutual understanding. I wish other LEAs would do this too.
One of the tasks the NCC is mandated by the NCC members to do is "make sure that the governments of our region understands how the Internet works, how Internet self-regulation works, and that it's better to leave us alone". This is why those good people attend ITU meetings, meet with LEAs, etc. - to make sure those "political accidents" that everybody is afraid of do *not* happen.
Exactly!
There's serious dangers here, like "why should a private entity be allowed to rule address governance in Europe? The european commission and the national governments are much better suited to do that!" - and the NCC works togethe with these folks to make them see that our way *works* and we need no extra regulation...
I'd express this a little more diplomatically Gert. [What?! Me diplomatic?! :-)] By engaging with governments, regulators and LEAs, we can show how their concerns about the usual public interest things -- fairness, transparency, consumer confidence, monopoly considerations, etc -- are being addressed and that the mechanisms which are in place are satisfactory to deal with those issues. Followups on this thread probably should move to the co-op WG list.
I've lately been more and more convinced that the basic idea, technical, is good. But it miss on two quite important points so I can not support it in its current form as stated earlier. However, more comments inline: On Wed, Jun 1, 2011 at 11:49 PM, David Conrad <drc@virtualized.org> wrote:
Sascha, On Jun 1, 2011, at 11:11 AM, Sascha Luck wrote: <snip>
Yet, also daily, I read about an attempt by $someone to censor, cut off or otherwise regulate somebody else's internet access.
Not sure about daily, but yes, this is a problem. I have absolutely no doubt that if a tool exists that allows politicians to claim they're doing something to solve "a problem", they'll use it.
I am quite sure this is one of the bigger issue with this policy. How can it be made clear for everyone that this is not a tool for that area? It should not be any opening for it being used for that really. (... and it's not that long ago an entire /16 or something I think, was used solely by a company to host every form of malware, abuse source, control centers for trojans etc... this tool would be excellent for removing That from Internet as it really was hurting almost everyone. But not sure it would be the Right tool for it.....)
You have to excuse me for not quite believing that this attempt to impose a centralised structure upon internet routing has anything to do with preventing someone from fat-fingering a prefix advertisement...
It really does have something to do with preventing fat-fingering (or perhaps more accurately, reduces the impact of that fat-fingering). The main arguments I've heard (some cynical, some not) for RPKI have been:
- allow for SIDR deployment - allow for the RIRs to enforce their policies - allow for the RIRs to have a viable business model after IPv4 is exhausted - allow the existing address hierarchy model to be enforced (disallow 'alternative address registries')
Excellent, this is probably the "other" side of the problem with this policy, the more technical side that we should spend most of our time solving:) I do not believe it is a good idea at all to start building one central that can control who can, who can not be seen on Internet. What happen when the people running this registry/central database are being fat-fingered? It did happen not that long ago with .se, they went offline even with lost of procedures and routines in place to make sure it never happen. It's not possible to guard against human mistakes really, atleast very very difficult. I rather see someone at an ISP make a mistake once in a while, even often than even make it possible for someone central make a fat-fingered mistake. The difference and the effect on _everyone_ are order of magnitude different. I think both issues I see, the government one, and the technical one, can be solved but this policy do not address these two issues good enough. Both Martin Miller and Sascha Luck have in their last emails listed more reasons why this policy is not good enough on the technical side, that is, central control on what can and can not be used on Internet. Especial Martin's mail on the hierarchical control... -- Roger Jorgensen | rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no
On 31 May 2011, at 06:50, Randy Bush wrote:
warning: you are leaving the real internet and entering a large, possibly infinite, gas cloud of political bullshit. tinfoil hats, kevlar undies, and nose plugs must be worn at all times. please report any signs of reality to the flight crew in case there could be a small chance of finding our way back to earth. thank you, and thanks for flying layer ten space lines.
Aw come on Randy! Stop pussyfooting around. Tell us what you *really* think. :-)
On Mon, May 09, 2011 at 09:34:21PM +0200, Sander Steffann wrote:
You miss the next sentence of the legal advise: "In the absence of such legislation, a court cannot order the revocation of certificates."
I think the legal statement (when read as a whole, not cherry- picking the parts you like) was clear enough.
Hmmm, do you have much experience with lawyer-speak? This means that a court cannot order the revocation of a ROA cert *specifically* as there is no legislation covering that. What it *can* do, is order the NCC to do everything possible to stop this prefix from being announced. o I know nothing about Dutch law but I would be highly surprised if that wasn't possible in .nl. rgds, Sascha
participants (24)
-
Alex Band -
Andrei Robachevsky -
Axel Pawlik -
boggits -
Daniel Suchy -
David Conrad -
Florian Weimer -
Gert Doering -
Hank Nussbacher -
Jim Reid -
Lutz Donnerhacke -
Malcolm Hutty -
Martin Millnert -
Mikael Abrahamsson -
Nick Hilliard -
Per Heldal -
Randy Bush -
Rob Evans -
Roger Jørgensen -
Sander Steffann -
Sascha Luck -
Shane Kerr -
Tim Bruijnzeels -
Wilfried Woeber, UniVie/ACOnet