Subject: [nemo] your comments on NEMO and routing protocools

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 23 Apr 2004 16:07:12 -0700

Hi Alex,

thanks for some very good comments.

> Alex Zinin:
> 
>   There are several things that concern me when I think about scaling
>   an implementation of a HA to support a large number of MRs.
> 
>   1. Tunnel interface flapping
> 
>      If the tunnel interface goes up and down every time a MR moves to a new
>      visited network, with high level of mobility and sufficient number of MRs,
>      the amount of interface state changes well result in CPU overloading on
>      the HA, as well as high level of instability in the rest of the network
>      if e.g. a link-state protocol is deployed.
> 
>      I understand that the document cannot mandate the way tunnel interfaces
>      are implemented, but it would be really useful if it provided some
>      recommendations along the following lines:
> 
>       - a tunnel interface is consistently assigned to each remote MR
> 
>       - the state of the interface at the IP layer is not changed if
>         the MR moves from one visited network to another "smoothly",
>         i.e., does not lose connectivity for too long. This would
>         probably mean providing some grace period before taking the
>         interface down when the MR is temporarily unreachable, and
>         changing the tunnel's tail-end (MR's CoA) address without
>         flapping the interface.

this is a good suggestion. we actually did want something
like this, but didnt specify it in the spec. I will add
some text on this.

however, what do you mean by "consistently assigned"? If
the MR is shut off for an extended period of time, the
Home Agent should delete any state associated with an MR.
or did you mean

   A tunnel interface is consistently assigned to each
   remote MR as long as the MR has a valid binding cache
   entry at the HA.

> 
>   2. Hello packet processing
> 
>      The lessons we've learned with FR and ATM clouds suggest that with a large
>      number of interfaces, Hello packet processing may become a burden. It could
>      be useful if the document recommended to treat the Tunnel interfaces as
>      On-Demand circuits in OSPF per RFC 1793.

okay.

> 
>   3. Amount of information exchanged between HA and MR
> 
>      One disadvantage of using a link-state routing protocol like OSPF in the
>      NEMO case is that there is a possibility that MRs and mobile networks
>      will be told the topology of the whole area, or even the domain (if no
>      areas are used in the network), while the only thing MRs really need
>      is a default through the HA.
> 
>      The same argument works the other way per my comment 1 above.
> 
>      At the very minimum, there should be a recommendation that Tunnel
>      interfaces to MRs are NOT put in the same area as e.g. the backbone links.
> 
>      Separating Tunnel interfaces to MRs from the backbone and aggregating
>      prefix info from mobile networks should prevent potential instabilities
>      related to MR relocations from destabilizing the rest of the network.

again, we will add this to the spec.

> 
>      Making the area to which a tunnel interface belongs Stub should save
>      the RM from too much info sent by the HA.
> 
>      To save different RMs from knowing too much about each other, the only
>      method currently available is to place them each in a separate stub
>      area, but this may stretch certain implementations.

I guess we wont be able decide between making the home link
a single area or making each tunnel interface a sub-area
without some experimentation. we could point out the pros
and cons of each approach and let the admin for the home
link decide. we have another draft which talks about how an
home link for NEMO can be designed.
http://www.ietf.org/internet-drafts/draft-ietf-nemo-home-network-models-00.txt
this will be an informational document. not a proposed
standard.

>   
> More specific comments inline below:
> 
>> 3. Overview of the NEMO Protocol
> 
> ...
>>    It is also possible for the Mobile Router and the Home Agent to run
>>    a routing protocol through the bi-directional tunnel.  In that case,
>>    the Mobile Router need not include prefix information in the Binding
>>    Update.  Instead the Home Agent uses the routing protocol updates to
>>    setup forwarding for the mobile network.  When running the routing
>>    protocol it is required that the bi-directional tunnel be treated as
>>    a tunnel interface.  The tunnel interface is included as the list of
>>    interfaces on which routing protocol is active.
> 
> "included AS the list of" or "included IN the list of"?

..included in the list of... fixed.

> 
>> The Mobile Router
>>    should be configured not to run the routing protocol on its egress
>>    interface when it is away from the home link.
> 
> Simply "should not run"?

what it means is that the MR should not send any routing
protocol messages on its egress interface when it attached
to a visited link. modified the text as follows.

    The Mobile Router
    should be configured not to send any routing protocol messages on its
    egress interface when it is away from the home link and connected to
    a visited link.

> 
>>    Finally, the Home Agent may be configured with static routes to the
>>    Mobile Network Prefix via the Mobile Router's Home Address.  In that
>>    case, the routes are set independently of the binding flows and the
>>    returning Home of a Mobile Router.  The benefit is that such movement
>>    does not induce any additional signalling in the form of routing
>>    updates in the Home Network.  The drawback of that model is that the
>>    routes are present even if the related Mobile Routers that are not
>>    reachable (at Home or bound) at a given point of time.
> 
> remove "that" in the last sentence?
> 
> In fact the statement in the last sentence is not necessarily true. If the HA
> always associates a stable tunnel interface with each MR and simply changes the
> interface state up/down depending on MR's reachability, then modern router
> SW already will remove and install those static routes correctly.

I am not sure we want to keep a stable tunnel interface to
each MR all the time. as along as the MR has a binding cache
entry at the HA, we can have a stable tunnel inteface for
each MR. the tunnel is created when the MR sends a binding
update to the HA.

> 
> 
>> 4.3. Mobile Network Prefix Option
> 
> A question that should probably be clarified in section 6:
> 
> - can a single prefix previously communicated in a BU be deregistered from the
>   HA without flapping the whole set of prefixes? 

it is hard for the HA to figure what has changed in the BU
without including a lot of information in the BU. and we
dont expect a lot of prefixes to be assigned to a MR.

> this may become handy when
>   a prefix is removed from one mobile network and placed to another.

I am not sure this is going to be common.

> 
> 
>> 6.3. Advertising Mobile Network Reachability
>> 
>>    In order to be able to receive packets meant for the mobile network,
>>    the Home Agent advertises reachability to the mobile network.  If the
>>    Home Link is configured with a prefix that is an aggregation and if
>>    the Mobile Network Prefix is aggregated under that prefix, then the
>>    routing updates advertising reachability to the mobile network are
>>    sent only on the Home Link.
> 
> The last sentences presupposes a distance-vector routing protocol (RIPng).
> Link-state RPs (OSPFv3) do not support per-interface discrimination of
> routing info.

is the following better?

    If the
    Home Link is configured with a prefix that is an aggregation and if
    the Mobile Network Prefix is aggregated under that prefix, then the
    routing changes related to the Mobile Network are restricted to the
    Home Link.

this does not assume a distance vector or link state routing
protocol.

> 
> BTW, "sent only on the Home link"--is this a requirement or an observation?

observation. :)

> 
>> If the Home Agent is the only default
>>    router on the Home Link, routes to the Mobile Network Prefix get
>>    aggregated naturally under the Home Agent and the Home Agent does not
>>    have to do anything special.
>> 
>>    If the Home Agent receives routing updates through a dynamic routing
>>    protocol from the Mobile Router, those routes are propagated by
>>    the routing protocol running on the Home Agent on the relevant
>>    interfaces.
> 
> I suggest the above is changed to "Home Agent can be configured to propagate..."

okay.

> 
>> 6.4. Establishment of Bi-directional Tunnel
> 
> Should the document say that the Tunnel interfaces should be unnumbered?
> There is really no need to assign prefixes to them.

right. there is no need to assign prefixes.

> 
>> 8. Support for Dynamic Routing Protocols
>> 
>>    In the solution described so far, forwarding to the mobile network
>>    at the Home Agent is set up when the Home Agent receives a Binding
>>    Update from the Mobile Router.  An alternative to this is for the
>>    Home Agent and the Mobile Router to run an intra-domain routing
>>    protocol like RIPng [11] and OSPF [12] through the bi-directional
>>    tunnel.  The Mobile Router can continue running the same routing
>>    protocol that it was running when it was attached to the home link.
>> 
>>    This feature is very useful when the mobile network is large with
>>    multiple subnets containing different IPv6 prefixes.  Routing changes
>>    in the mobile network are propagated to the Home Agent quickly.
>>    Routing changes in the home link are also propogated to the Mobile
>>    Router very quickly.
> 
> The thing is, however, that both MR and HA do not need to know the
> topologies behind each other, only the reachability info...

it is however restricted to the home link. the intention
really is to enable the MR to receive the same kind of
routing information that it used to receive when attached
to the home link. with your suggestion of treating the
IP-in-IP tunnel as on-demand circuits when the MR is
away from home, we should be able to reduce the amount of
traffic. (?)

> 
>>    When the Mobile Router is attached to the home link, it runs a
>>    routing protocol by sending routing updates through its egress
>>    interface.  When the mobile router moves and attaches to a visited
>>    network, it MUST stop sending routing updates on the interface with
>>    which it attaches to the visited link.
> 
> One potential problem I could see with this is that a MR can send an
> update on its link before it realizes that it is on a visited network.
> The real answer here is enabling authentication in routing protocols
> and proper key management--accidental updates will simply be dropped.

oh.. we wanted to say if the MR realises that it is on a
visited link, it stops sending routing protocol messages
on the egress interface. the MR realizes that it is on
a visited link when it sees different prefix information
in a router advertisement from a router on the visited
link. it is enough if it stops sending routing protocol
messages on the egress interface after that.

> 
>> This is very important so
>>    that IPv6 prefixes specific to the mobile network do not leak into
>>    the visited network.  The Mobile Router then starts sending routing
>>    protocol messages through the bi-directional tunnel towards the Home
>>    Agent.  Most routing protocols use link local addresses as source
>>    addresses for the routing information messages.  The Mobile Router is
>>    allowed to use link local addresses for the inner IPv6 header of an
>>    encapsulated packet.  But these messages after decapsulation MUST NOT
>>    be forwarded to another link by either the Mobile Router or the Home
>>    Agent.
> 
> By "these messages" do you mean the routing protocol messages after they
> are decapsulated or the inner IPv6 packets carrying them. 

the inner IPv6 packets.

> If the former,
> then they won't be forwarded anyways, since they have been received locally
> already. If the latter, then do you mean all inner IPv6 packets or only
> those with link-local addresses?

only those with link-local addresses.

> 
>>    When the Home Agent receives the encapsulated routing protocol
>>    message, it processes the inner packets and updates its routing table
>>    accordingly.
> 
> Should be the other way around:
> 
>     When the Home Agent receives the inner packet, it processes encapsulated
>     routing protocol messages and updates its routing table accordingly.
> 
>> The next hop information in these routing entries is
>>    filled with the Mobile Router's link local address with the outgoing
>>    interface set to the bi-directional tunnel.
> 
> Let's make it "As part of normal routing protocol operation, the next hop
> information..." so that it doesn't sound like a change in RP's operation.

okay.

> 
>>    Similary, the Home Agent also sends routing updates through the
>>    bi-directional tunnel to the Mobile Router.  The Mobile Router
>>    processes these routing protocol messages and updates its routing
>>    table.  For all routes advertised by the Home Agent, the Mobile
>>    Router sets the outgoing interface to the bi-directional tunnel to
>>    the Home Agent.
>> 
>>    When the Mobile Router and the Home Agent exchange routes through
>>    a dynamic routing protocol, the Mobile Router should be careful in
>>    including the same Mobile Network Prefixes in the Binding Update to
>>    the Home Agent and in the routing protocol updates.
> 
> This isn't really a useful suggestion. It is not reasonable to expect
> the MR to keep track of the routes that have been announced through
> the tunnel and somehow make an intelligent decision about the contents
> of the BU message, because e.g. in OSPF, the flooding mechanism that
> performs the transport function has no clue about the semantics of
> the LSA internals it carries.

this is restricted to what the MR sends. if the MR knows that
it has includes certain information in the routing protocol
messages, it shouldnt include the same in binding updates.

> 
>> The Home Agent
>>    depending on its configuration might not add routes based on the
>>    prefix information in the Binding Updates at all, and might use only
>>    the routing protocol updates.  Moreover, including the same prefix
>>    information in both the Binding Update and the routing protocol
>>    update is redundant.
> 
> There are also potential cases where the routing protocol has removed
> a prefix and the HA still has it from the BU....
> 
> Should the doc simply suggest that the MR should not be configured
> to announce prefixes in the BU if those prefixes will be delivered
> to the HA by the routing protocol?

people on the mailing list have argued in the past that we
shouldnt have such restrictions in the spec. the only
requirement should be the information should be consistent.
I am fine with making this change, though.

> 
>>    Since the routing protocol messages from the Home Agent to the Mobile
>>    Router could potentially contain information about the internal
>>    routing structure of the home network, these messages require
>>    authentications and confidentiality protection.  Confidentialy
>                                                       Confidentiality
> 
>>    protection using IPsec ESP [4] MUST be supported and SHOULD be
>>    used.
> 
> ESP at what level is meant above? If you mean at the Tunnel level,
> please say so.

draft-ietf-ospf-ospfv3-auth-04.txt requires the use of
ESP in transport mode. with NEMO, tunnel mode should
also be okay. when used in transport mode, the packet
will be as follows

IPv6 hdr (src=HA, dst=MR_CoA)
IPv6 hdr (src=HA, dst=MR_HoA)
ESP hdr
Payload
    OSPFv3 payload

when used in tunnel mode, the packet will be

IPv6 hdr (src=HA, dst=MR_CoA)
ESP hdr
Ipv6 hdr (src=HA, dst=MR_HoA)
Payload
    OSPFv3 payload

in both cases, the address on the inner packet can be
link local address.

so we dont have a strong preference to tunnel or
transport mode.

> 
> "SHOULD be used" seems like a strange requirement that will be impossible to
> check, since it is not for the implementation, but for the used.
> 
>> For protecting routing protocol messages using ESP, the
>>    bi-directional tunnel between the Mobile Router and the Home
>>    Agent should be treated as the outgoing interface, with link local
>>    addresses as source and destination addresses for the messages.
> 
> What is meant by "messages" here? Encapsulating packets or encapsulated packets?

encapsulated packets

> Why do you need to insist on link-local addresses here? OSPF, for example has a
> case (virtual links) where packets are sent over more than one hop.

you are right. global unicast addresses can also be used.
I will remove the part about link local addresses.

> 
>>    IPsec ESP with a non-null encryption algorithm should be used
>>    in transport mode for protecting the routing protocol messages.
>>    Examples of SPD entries for protecting OSPFv3 messages are described
>>    in [13].
> 
> I suggest that the above is reworded to say something like "appropriate
> authentication and confidentiality protection mechanisms defined in [12,13]
> should be configured when necessary", instead of trying to define (again) here
> what they are.

okay.

> 
>> 9. Security Considerations
> ...
>>    When the Mobile Router is running a dynamic routing protocol as
>>    described in Section 8, it injects routing update messages into the
>>    Home Link.  The Home Agent MUST verify that the Mobile Router is
>>    allowed to send routing updates before processing the messages and
>>    propagating the routing information.
> 
> What is meant by "MUST verify" here? If protocol-specific authentication
> mechanisms, then they of course may be configured, but mandating that seems
> strange. If you mean source-address checking, then it is not a strong security
> mechanism.

the routing protocol messages ofcourse should be authenticated.
but I am not sure if thats enough to verify if the mobile router
is allowed to send routing protocol messages in the first place.
the home agent could be serving a bunch of mobile routers, some
of which might be authorized to run a routing protocol and the
others not. so we have the additional check.

Vijay