Subject: Fwd: DISCUSS: draft-ietf-nemo-basic-support

From: Alex Zinin <[email-masked]>
Date: Thu, 18 Mar 2004 01:51:27 -0800

fyi
-- 
Alex
http://www.psg.com/~zinin/

This is a forwarded message
From: Alex Zinin <[email-masked]>
To: [email-masked]
Cc: 
Date: Thursday, March 18, 2004, 1:39:29 AM
Subject: DISCUSS: draft-ietf-nemo-basic-support

===8<==============Original message text===============
Logged in the tracker:

Truly wonderful document. I really enjoyed reading it.

I have one longish and more generic concern and a set of more
specific issues.

Meta-comment: on using dynamic routing protocols over the HA-MR
tunnel interface.

  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.

  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.

  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.

     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.
  
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"?

> 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"?

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

> 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? this may become handy when
  a prefix is removed from one mobile network and placed to another.

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

BTW, "sent only on the Home link"--is this a requirement or an 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..."

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

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

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

> 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. 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?

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

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

> 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?

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

"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?
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.

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

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

Alex

===8<===========End of original message text===========