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

[Christian de Larrinaga]

I like your definition "edge" is "not transit". Thanks for pointing to those interesting drafts. 

I think we are still left with tunnelling as the only mechanism for an "edge" service to transit in the face of hostile or potentially "transit" policies. 

One can look at the security issue from the perspective of the corporate trying to secure the boundaries of their "edge". Or you can look at it from the perspective of the edge trying to "transit" effectively.  What would not be nice is throwing the ability to transit baby out with the security agenda bathwater. 

There does not seem to be a mechanism to ensure that a tunnelled transit packet is just routed and not mucked about with. Time for a tBGP?


Christian



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 :-)
> 
>> 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
> 
> 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.
>