Re: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
I am wondering about the proposals made during this discussion. 1) It appears that some of the suggestions in this thread are about not using the existing Internet infrastructure to route packets but rather to either use local communication technology (e.g., short range radio) or adhoc networks. I am not sure how practical this is given how the majority of the applications on the Internet work today. This would obviously have severe impacts on these applications. 2) Regarding the delegation of encryption to network nodes: Are talking about an approach similar to Onion routing here? While I agree that it would be good to provide protection at various layers I wonder whether you are trying to find solutions at the wrong layer in the protocol stack. Ciao Hannes On 07.09.2013 15:20, Noel Chiappa wrote: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?=rog...@gmail.com The userbase and deployment are relative small atm so it's doable to get fast deployment to. Alas, now that I think about the practicalities I don't think the average router has enough spare computing power to completely encrypt all the traffic. Whether or not encrypting just the source+dest addresses, and the sort+dest port (conviently next to each other in one block) is enough to do much good, and if the average router has enough spare crunch to do even that, is a good question. Noel
Re: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= rog...@gmail.com Isn't the payload the important part to protect? Ecrypting only the headers was a suggestion for the case where the routers don't have enough spare crunch to encrypt the entire payload of every packet. Whether that would do anything useful, or whether analysis of the payload could bypass that, making that limited step useless, I don't know. Noel
Re: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
On 7 Sep 2013, at 04:05, j...@mercury.lcs.mit.edu (Noel Chiappa) wrote: From: Scott Brim scott.b...@gmail.com The encapsulation is not much of an obstacle to packet examination. There was actually a proposal a couple of weeks back in the WG to encrypt all traffic on the inter-xTR stage. The win in doing it in the xTRs, of course, is that you don't have to go change all the hosts, application by application: _all_ traffic, of any kind, from that site to any/all other sites which are encryption-enabled, will get a certain degree of confidentiality. Does this count as something the IETF can do reasonably quickly that will help somewhat? :-) It certainly wouldn't hurt :) Tim
Re: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
On Sat, Sep 7, 2013 at 5:05 AM, Noel Chiappa j...@mercury.lcs.mit.edu wrote: From: Scott Brim scott.b...@gmail.com The encapsulation is not much of an obstacle to packet examination. There was actually a proposal a couple of weeks back in the WG to encrypt all traffic on the inter-xTR stage. The win in doing it in the xTRs, of course, is that you don't have to go change all the hosts, application by application: _all_ traffic, of any kind, from that site to any/all other sites which are encryption-enabled, will get a certain degree of confidentiality. Does this count as something the IETF can do reasonably quickly that will help somewhat? :-) One easy fix then would be to have a MUST encrypt traffic between xTRs, and that the encryption used MUST be strong. Are LISP@WG up for the challenge? :-) The userbase and deployment are relative small atm so it's doable to get fast deployment to. -- Roger Jorgensen | ROJO9-RIPE rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no
Re: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= rog...@gmail.com The userbase and deployment are relative small atm so it's doable to get fast deployment to. Alas, now that I think about the practicalities I don't think the average router has enough spare computing power to completely encrypt all the traffic. Whether or not encrypting just the source+dest addresses, and the sort+dest port (conviently next to each other in one block) is enough to do much good, and if the average router has enough spare crunch to do even that, is a good question. Noel
Re: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
On Sat, Sep 7, 2013 at 2:20 PM, Noel Chiappa j...@mercury.lcs.mit.edu wrote: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= rog...@gmail.com The userbase and deployment are relative small atm so it's doable to get fast deployment to. Alas, now that I think about the practicalities I don't think the average router has enough spare computing power to completely encrypt all the traffic. I don't really see that as an issue, it's just a matter of engineering and building the router in a way that they can do it. AFAIK I think most routers have the options of being extended by dedicated encrypt-all-traffic tasks? Probably some changes needed on the software layer to use the extension but that's doable. It is also just the situation right now on the router side. In general should our current technology and processing power be up for the job if needed. Whether or not encrypting just the source+dest addresses, and the sort+dest port (conviently next to each other in one block) is enough to do much good, and if the average router has enough spare crunch to do even that, is a good question. Isn't the payload the important part to protect? the content of the package? -- Roger Jorgensen | ROJO9-RIPE rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no
Re: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
Noel Chiappa wrote: There was actually a proposal a couple of weeks back in the WG to encrypt all traffic on the inter-xTR stage. Making intermediate systems more intelligent is against the end to end principle and assured to fail. Considering that google, facebook, yahoo, etc., which are end systems that many victims are relying upon, are socially compromised by USG, it can not protect the victims. Worse, considering that services of Microsoft, Apple, etc. are socially compromised by USG, end systems manufactured by Microsoft, Apple, etc. are totally unsafe. As for secure end systems, PCs with open source UNIX are much safer, even though USG can still use a lot of approaches to compromise them. Masataka Ohta
Re: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
On 6 Sep 2013, at 21:32, Roger Jørgensen rog...@gmail.com wrote: On Fri, Sep 6, 2013 at 9:47 AM, Adam Novak interf...@gmail.com wrote: The IETF focused on developing protocols (and reserving the necessary network numbers) to facilitate direct network peering between private individuals, it could make it much more expensive to mount large-scale traffic interception attacks. Think there are work being done on the topic? However, how are you going to interconnect all of this private peerings? It sort of imply that everyone need to have their own netblock they can exchange with others. Mobile IPv6 gives one way to run multiple devices in one subnet. Someone needs to be the HA though. And/or if future homes have multiple /64's, it's not infeasible to dedicate one or more to virtual/overlay LANs. Tim
Re: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
On 07/09/2013 08:55, Tim Chown wrote: On 6 Sep 2013, at 21:32, Roger Jørgensen rog...@gmail.com wrote: On Fri, Sep 6, 2013 at 9:47 AM, Adam Novak interf...@gmail.com wrote: The IETF focused on developing protocols (and reserving the necessary network numbers) to facilitate direct network peering between private individuals, it could make it much more expensive to mount large-scale traffic interception attacks. Think there are work being done on the topic? However, how are you going to interconnect all of this private peerings? It sort of imply that everyone need to have their own netblock they can exchange with others. Mobile IPv6 gives one way to run multiple devices in one subnet. Someone needs to be the HA though. And/or if future homes have multiple /64's, it's not infeasible to dedicate one or more to virtual/overlay LANs. It serves no purpose as long as there's an underlying customer/provider relationship, because it's the provider that is suborned by the government agency. Brian
Re: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
hum… i did work on a DNS architecture that can be fully disconnected from the Internet and still work with nodes within the visible topology. Needs serious rework of DNSSEC and has some assumptions about topology discovery - but it might be a basis for starting some discussion on decentralization of that part of the centralized DNS. /bill
Re: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
On Sep 6, 2013 4:33 PM, Roger Jørgensen rog...@gmail.com wrote: On Fri, Sep 6, 2013 at 9:47 AM, Adam Novak interf...@gmail.com wrote: snip One way to frustrate this sort of dragnet surveillance would be to reduce centralization in the Internet's architecture. Right now, the way the Internet works in practice for private individuals, all your traffic goes up one pipe to your ISP. It's trivial to tap, since the tapping can be centralized at the ISP end. excellent idea... any suggestion on how that should be done? Only one I can remember right now are LISP which sort of create a new network on top of our current network, and the EID-block drafts being worked on by some people (including me) tries to address how the IP-space of this new network can be done. LISP does nothing for decentralization. Traffic still flows hierarchically, encapsulated or not, and you add the mapping system which is naturally hierarchical and another vulnerability. The diameter of the Internet has not increased much despite its growth, due to both cross-connects and hubs. I don't think there is much more that can be done practically to decentralize traffic flow. Scott
Re: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
From: Scott Brim scott.b...@gmail.com LISP does nothing for decentralization. Traffic still flows hierarchically Umm, no. In fact, one of LISP's architectural scaling issues is that it's non-hierarchical, so xTRs have neighbour fanouts that are much larger than typical packet switches. In basic unicast mode, any xTR is always a direct neighbour to any other xTR; no xTR (in basic unicast mode, at least) ever goes _through_ another xTR to get to a third xTR. All LISP basic unicast paths always include exactly two xTRs. The actual detailed paths do mimic the underlying network, of course: if the network is hierarchical, the paths will be hierarchical, but if the network were flat, the paths would be flat. (Or is that what you meant?) you add the mapping system which is naturally hierarchical and another vulnerability. No more so than DNS; they are exactly parallel in their functional design. Noel
Re: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
On Sep 6, 2013 10:06 PM, Noel Chiappa j...@mercury.lcs.mit.edu wrote: From: Scott Brim scott.b...@gmail.com LISP does nothing for decentralization. Traffic still flows hierarchically Umm, no. In fact, one of LISP's architectural scaling issues is that it's non-hierarchical, so xTRs have neighbour fanouts that are much larger than typical packet switches. In basic unicast mode, any xTR is always a direct neighbour to any other xTR; no xTR (in basic unicast mode, at least) ever goes _through_ another xTR to get to a third xTR. All LISP basic unicast paths always include exactly two xTRs. The actual detailed paths do mimic the underlying network, of course: if the network is hierarchical, the paths will be hierarchical, but if the network were flat, the paths would be flat. (Or is that what you meant?) Yup. The encapsulation is not much of an obstacle to packet examination. you add the mapping system which is naturally hierarchical and another vulnerability. No more so than DNS; they are exactly parallel in their functional design. Yes but DNS vulnerabilities have been covered elsewhere. Cheers... Scott
Re: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
From: Scott Brim scott.b...@gmail.com The encapsulation is not much of an obstacle to packet examination. There was actually a proposal a couple of weeks back in the WG to encrypt all traffic on the inter-xTR stage. The win in doing it in the xTRs, of course, is that you don't have to go change all the hosts, application by application: _all_ traffic, of any kind, from that site to any/all other sites which are encryption-enabled, will get a certain degree of confidentiality. Does this count as something the IETF can do reasonably quickly that will help somewhat? :-) Noel
