[Chapter-delegates] Statement on Open Internet proposal fromGoogle and Verizon

[Christian de Larrinaga]

On 23 Aug 2010, at 19:17, Fred Baker wrote:

> 
> On Aug 23, 2010, at 10:36 AM, Christian de Larrinaga wrote:
> 
>> Fred, 
>> 
>> My comment is that as we get Edge drift (by which I mean power drifts out of the edge) so demand for regulatory input increases to control what goes on in the network. Another way to balance this is for the protocols to do some of that rebalancing work. 
>> 
>> [As you ask. Edge is the bit where the user sits or the user device. It can also be a proxy for the user so your corporate network as an End user Network (EUN) would be the Edge and might require you as the ultimate user to delegate some of your user power to a shared company network policy. But see my point about Goolge as a typical user below]
> 
> My thumbnail definition of "edge" is "not transit". That does leave a question mark around access, aka mobile telephone and residential broadband - is it a transit network for residential/soho edge networks, or is it itself an edge network? It has aspects of each. But I tend to think of it as more transity than edgy :-)

I suspect that the fuzziness in your definition is increasing as a function of Edge drift as that increases. i.e., the more interference or opacity the user faces from the access network the more difficult it is to come up with a clean definition of the edge for regulatory purposes. 
 
The more this is not a clean demarcation the more it suits those who want the edge to be somewhere within the access network rather than at the user. Personally I think that would be a very bad idea. However it does look as if some are willing to sacrifice this point for wireless networks which they call "mobile". 

I personally think that the term "mobile" in this context is disingenuous and should be resisted.


> 
>> To give an example. 
>> 
>> IETF seems to be fixated on various tunnelling mechanisms to rebalance problems where stuff in the network gets in the way or can't cope with what the edge wants to do. 
>> 
>> An interesting if extreme example is IRON by Fred Templin out of the IRTF. http://tools.ietf.org/html/draft-templin-iron-10 . Ostensibly to protect routing table expansion where massive increases in multi-homing occurs it proposes tunnelling mechanisms with formation of a structured OverNet infrastructure. 
>> 
>> But I am mindful of http://tools.ietf.org/html/draft-ietf-intarea-tunnels-00 which makes it clear that tunnels are not really an architectural feature of the Internet but rather an ad hoc implementation. Albeit one that could and needs to be formalised. 
> 
> Fred will disagree with me, but I tend to think he's building another network that isn't the Internet. And by the way, if not managed (think 6rd and ds-lite as examples of managed tunnel infrastructure), it has issues. You may find
> 

I see what you are saying. My first thought is "well it is not the vanilla Internet is it?" But it does seem to be part of the reaction to the reality of network deployments in the wild. 

What we seem to be witnessing is a shift from both ends. First the demand of users for an Internet that differs from the design preconditions (by pushing for multi-homing and the consequent implications for the routing table) and network providers desire to use their topological position to extract value. 

Fred's draft does seem to sit on the space that describes this combination. 

> http://datatracker.ietf.org/doc/draft-ietf-v6ops-tunnel-security-concerns
> http://tools.ietf.org/html/draft-ietf-v6ops-tunnel-security-concerns
>  "Security Concerns With IP Tunneling", James Hoagland, Suresh Krishnan,
>  Dave Thaler, 8-Mar-10,
>  <draft-ietf-v6ops-tunnel-security-concerns-02.txt>
> 
> http://tools.ietf.org/html/draft-nakibly-v6ops-tunnel-loops
>  "Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and
>  Proposed Mitigations", Gabi Nakibly, Fred Templin, 18-Aug-10,
>  <draft-nakibly-v6ops-tunnel-loops-03.txt>
> 
> interesting reading.
> 

Thanks that is VERY interesting. I will have to look at these carefully this weekend. But I suspect that I may find they will be dealing with the problems that arise from tunnelling being an adhoc implementation to get around problems in IP networks rather than being architecturally implicit. 

In part that is my concern that IETF is defining tunnelling mechanisms but is not defining the ground upon which tunnels sit. i.e., it is hoping that the architecture will emerge from the usage but is finding that these designs needs an architecture to ensure implementations are robust and workable. It is a dangerous catch 22. If networks start to interfere with tunnels then there is a significant issue ahead. 

If we cannot deal with networks on a vanilla basis. i.e, cannot depend on them negotiating with our deployment of protocols at the edge (the user edge) then the solution from IETF is to tunnel. Increasingly as we find networks will not negotiate with us at the edge we are using tunnels. 

But tunnels are tricky. This suggests that the future edge controls of the Internet are .... well going to be tricky too unless something gets done at the Protocol architectural design level to fix this. This seems to be IETF territory? 


Christian