Subject: [Roll] Comments about the NEMO-related text in draft-ietf-roll-protocols-survey-03.txt, and security

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 16 Jan 2009 18:57:47 +0100

It's true: I'd like NEMOv6 extensions to Mobile IPv6 to be used
everywhere, it can do everything.

But it's also true that some other times the tunnelling of Mobile IPv6
and triangular routing through HA may prove unnecessary constraints 
when its requirements (permanent unique globally reachable Home Address 
and session continuity without app changes) are not valid, for example 
in ROLL WG.

That said, I have comments on the following paragraph:
> We do not examine the Network Mobility Basic Support Protocol (NEMO 
> RFC 3963 [RFC3963]) because it is not a routing protocol.  We do not 
> examine hierarchical NEMO [I-D.thubert-tree-discovery] as a candidate
>  because it only maintains a default route and so is insufficient for
>  general routing.  Although NEMO itself is not a suitable routing 
> solution to LLNs, some of its mechanisms, such as loop-free tree 
> formation, might be useful in an LLN routing protocol.

IT is difficult to agree that NEMOv6 rfc3963 is _not_ a routing 
protocol, as long as we don't know the definition of a routing protocol. 
   NEMOv6 has prefixes in the exchanged messages, affects routing tables 
and binding caches, spans wide Internet areas, decrements TTL, etc.

As opposed to the entrenched Hierarchical Mobile IP term the 
Hierarchical NEMO is not used in the common NEMO parlance, never heard 
of it.

Loop-free formation is not a characteristic of the NEMOv6 protocol.  It 
is a characteristic of the concept of moving networks represented by one 
Mobile Router moving with them.  It is very well possible to demonstrate 
how two Mobile Routers serving two different moving networks move in 
such a way that a deadlock situation is created because a loop of paths 
is formed ("Stalemate" in Appendix B of RFC4888 "Network Mobility Route 
Optimization Problem Statement").

Despite the numerous individual proposals for Route Optimzation 
techniques for NEMOv6 protocol, none is currently commonly agreed, no WG 
document on that.  The Route Optimization problem is hard to solve for 
NEMOv6, especially because of security constraints of 
across-the-Internet communications.

Which leads to the last question of this table:
>     Protocol      Table   Loss  Control   Link Cost  Node Cost
>      OSPF/IS-IS    fail    fail    fail      pass       fail
>      OLSRv2        fail    fail     ?        pass       pass
>      TBRPF         fail    pass    fail      pass        ?
>      RIP           pass    fail    pass       ?         fail
>      AODV          pass    fail    pass      fail       fail
>      DYMO[-low]    pass    fail    pass       ?         fail
>      DSR           fail    pass    pass      fail       fail

Why there's no Security column?  Something suggesting that some protocol 
is more advantageous because it addresses some security requirements 
while others don't.

Alex

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Philip Levis <[email-masked]>
Date: Fri, 16 Jan 2009 10:10:01 -0800

On Jan 16, 2009, at 9:57 AM, Alexandru Petrescu wrote:

> when its requirements (permanent unique globally reachable Home  
> Address and session continuity without app changes) are not valid,  
> for example in ROLL WG.
>
>> RFC 3963 [RFC3963]) because it is not a routing protocol.  We do  
>> not examine hierarchical NEMO [I-D.thubert-tree-discovery] as a  
>> candidate
> protocol, as long as we don't know the definition of a routing  
> protocol.   NEMOv6 has prefixes in the exchanged messages, affects  
> routing tables and binding caches, spans wide Internet areas,  
> decrements TTL, etc.

I guess we're getting a bit sophistic here. NEMO does not qualify  
because it tunnels on top of an underlying routing protocol. So while  
it might be a routing protocol in the way that you describe, it is  
routing on top of routing topology, and we first need that underlying  
topology. RFC 3963:

Section 1:

"The solution described in this document proposes a bi-directional
tunnel between the Mobile Router and its Home Agent.  This tunnel is
set up when the Mobile Router sends a successful Binding Update to
its Home Agent, informing the Home Agent of its current point of
attachment."

Section 3:

"A Mobile Network is a network segment or subnet that can move and
attach to arbitrary points in the routing infrastructure."

"When a Correspondent Node sends a data packet to a node in the Mobile
Network, the packet is routed to the Home Agent that currently has
the binding for the Mobile Router."

> Why there's no Security column?  Something suggesting that some  
> protocol is more advantageous because it addresses some security  
> requirements while others don't.

Have you read the full document? "Necessary but not sufficient" is the  
phrase to keep in mind. We've gone over this at least a half dozen  
times now.

Phil

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 16 Jan 2009 19:30:19 +0100

Philip Levis a écrit :
>> But it's also true that some other times the tunnelling of Mobile
>> IPv6 and triangular routing through HA may prove unnecessary
>> constraints when its requirements (permanent unique globally
>> reachable Home Address and session continuity without app changes)
>> are not valid, for example in ROLL WG.
>> 
>>> We do not examine the Network Mobility Basic Support Protocol
>>> (NEMO RFC 3963 [RFC3963]) because it is not a routing protocol.
>>> We do not examine hierarchical NEMO [I-D.thubert-tree-discovery]
>>> as a candidate because it only maintains a default route and so
>>> is insufficient for general routing.  Although NEMO itself is not
>>> a suitable routing solution to LLNs, some of its mechanisms, such
>>> as loop-free tree formation, might be useful in an LLN routing
>>> protocol.
>> 
> because it tunnels on top of an underlying routing protocol.

OSPF tunnels on top of a routing Bluetooth MAC protocol - why does it
qualify instead?

> So while it might be a routing protocol in the way that you describe,
> it is routing on top of routing topology, and we first need that
> underlying topology.

Some link-layers 'route'.  Are the link-layer methods of routing out of 
scope for ROLL?  Just for my clarification.

Alex

---

From: Philip Levis <[email-masked]>
Date: Fri, 16 Jan 2009 10:43:18 -0800

> OSPF tunnels on top of a routing Bluetooth MAC protocol - why does it

OSPF does a lot more than that... points below.

> Some link-layers 'route'.  Are the link-layer methods of routing out  
> of scope for ROLL?  Just for my clarification.

Do you mean switching? Sure, all routing layers can work on top of  
switching, as multiple link hops look like a single IP hop. The fact  
that OSPF can work on top of a bluetooth switching network doesn't  
mean that it's not a routing protocol, any more than the fact that an  
end-host's default route goes through several switches means that it's  
not routing based on a netmask.

This discussion went on when ROLL chartered. The terms used were "mesh  
under" for layer 2 switching and "route over" for IP routing. The  
IETF's purview (a few aberrant exceptions aside) is layer 3 and above,  
so mesh under is not within the scope of ROLL.

Phil