Network Mobility (NEMO) Basic Support Protocol
draft-ietf-nemo-basic-support-03

[Ballot comment]
Not all considerations for which I put in a DISCUSS have been fixed.
Version -03 section 8 says (unchanged):

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

But the other comment is, so I'm changing this to a comment.

Further comments from Gen-ART reviewer Michael Patton on this URL:
http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-nemo-basic-support-02-patton.txt

[Ballot discuss]
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.

[Ballot discuss]
From Michael Patton, GEN-ART reviewer, specific technical concerns:

In at least two places they have a requirement that a mobile router
that advertises it's network when at home must never advertise this
prefix on a visited network.  This is a requirement which cannot, in
practice, be met in all cases.  A periodic routing packet could be
sent in the interval between when the connectivity changes and the
router discovers that fact (think atmospheric effects on radio
transmission, or an Ethernet switch having the VLAN allocations
changed).

In section 6.6 under a certain condition (which is independent of
whether implicit or explicit mode is in use) it describes sending error
status code 140.  However, in the description of what a MR does with
responses in explicit mode, error code 140 implies discard response.
If the MR is going to discard it, why send it?  The MR needs to know
there was a problem, so I think the fix is to make it process these.

[Ballot discuss]
Overall, a nice job  I have a few comments.  Most should be very easy to resolve; the one on Section 8, however, may require some discussion in the WG.
But I'm not sure -- I don't know what it actually means.  I should state explicitly that with minor exceptions, I do not see any security problems here.

3:      What good does it to to check the source address of the
        outer IPv6 header?  Spoofing that is far too easy.

5.4:    why is 140 not allowed in explicit mode? 6.6 implies that it should be.

6:      no text in 6 about which modes Home Agents must support, similar to
        the last paragraph of 5.2.

6.1.2:  why is the prefix table check only a SHOULD and not a MUST?

8:      This text is unclear:

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

        Do you mean "be careful to include the same information in
        both places" -- redunancy is sometimes good.  Or do you
        mean "be careful to avoid doing this"?  Personally, I think
        the former is more appropriate, because it allows a check
        on the validity of the routing information.  Note that the
        prefixes announced via binding updates are checked for
        authorization; routing data generally is not.  I would thus
        suggest that routing advertisements MUST NOT contain any
        prefixes not known to the home agent by either implicit
        mode configuration or explicit mode announcement.

9:      When discussing Home Agent routing protocol processing, must
        the HA check the authorization for routing messages in general,
        or for the prefixes actually being announced?

[Ballot discuss]
Overall, a nice job  I have a few comments.  Most should be very easy to resolve; the one on Section 8, however, may require some discussion in the WG.
But I'm not sure -- I don't know what it actually means.

3:      What good does it to to check the source address of the
        outer IPv6 header?  Spoofing that is far too easy.

5.4:    why is 140 not allowed in explicit mode? 6.6 implies that it should be.

6:      no text in 6 about which modes Home Agents must support, similar to
        the last paragraph of 5.2.

6.1.2:  why is the prefix table check only a SHOULD and not a MUST?

8:      This text is unclear:

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

        Do you mean "be careful to include the same information in
        both places" -- redunancy is sometimes good.  Or do you
        mean "be careful to avoid doing this"?  Personally, I think
        the former is more appropriate, because it allows a check
        on the validity of the routing information.  Note that the
        prefixes announced via binding updates are checked for
        authorization; routing data generally is not.  I would thus
        suggest that routing advertisements MUST NOT contain any
        prefixes not known to the home agent by either implicit
        mode configuration or explicit mode announcement.

9:      When discussing Home Agent routing protocol processing, must
        the HA check the authorization for routing messages in general,
        or for the prefixes actually being announced?

[Ballot comment]
I'm a bit confused by this text in section 5.6:

  When the Mobile Router is at home, it MAY be configured to send
  Router Advertisements and reply to Router Solicitations on the
  interface attached to the home link.  The value of the Router
  Lifetime field MUST be set to zero to prevent other nodes from
  configuring the Mobile Router as the default router.

I don't see cases where the mobile router would have a different
upstream link in its home link than a non-mobile router on this
link.  Is there a use case where it is expected that all the routers
on the home link might be mobile routers (so only mobile routers
are replying to RSs?)

Not a blocking comment, obviously; I'm just curious about the use
case that drives this.

[Ballot discuss]
From Michael Patton, GEN-ART reviewer, specific technical concerns:

In at least two places they have a requirement that a mobile router
that advertises it's network when at home must never advertise this
prefix on a visited network.  This is a requirement which cannot, in
practice, be met in all cases.  A periodic routing packet could be
sent in the interval between when the connectivity changes and the
router discovers that fact (think atmospheric effects on radio
transmission, or an Ethernet switch having the VLAN allocations
changed).

In section 6.6 under a certain condition (which is independent of
whether implicit or explicit mode is in use) it describes sending error
status code 140.  However, in the description of what a MR does with
responses in explicit mode, error code 140 implies discard response.
If the MR is going to discard it, why send it?  The MR needs to know
there was a problem, so I think the fix is to make it process these.

Further comments on this URL:
http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-nemo-basic-support-02-patton.txt

[Ballot discuss]
From Michael Patton, GEN-ART reviewer, specific technical concerns:

In at least two places they have a requirement that a mobile router
that advertises it's network when at home must never advertise this
prefix on a visited network.  This is a requirement which cannot, in
practice, be met in all cases.  A periodic routing packet could be
sent in the interval between when the connectivity changes and the
router discovers that fact (think atmospheric effects on radio
transmission, or an Ethernet switch having the VLAN allocations
changed).

In section 6.6 under a certain condition (which is independent of
whether implicit or explicit mode is in use) it describes sending error
status code 140.  However, in the description of what a MR does with
responses in explicit mode, error code 140 implies discard response.
If the MR is going to discard it, why send it?  The MR needs to know
there was a problem, so I think the fix is to make it process these.

Further comments on this URL:
http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-nemo-basic-support-02-patton.txt

[Ballot discuss]
From Michael Patton, GEN-ART reviewer, specific technical concerns:

In at least two places they have a requirement that a mobile router
that advertises it's network when at home must never advertise this
prefix on a visited network.  This is a requirement which cannot, in
practice, be met in all cases.  A periodic routing packet could be
sent in the interval between when the connectivity changes and the
router discovers that fact (think atmospheric effects on radio
transmission, or an Ethernet switch having the VLAN allocations
changed).

In section 6.6 under a certain condition (which is independent of
whether implicit or explicit mode is in use) it describes sending error
status code 140.  However, in the description of what a MR does with
responses in explicit mode, error code 140 implies discard response.
If the MR is going to discard it, why send it?  The MR needs to know
there was a problem, so I think the fix is to make it process these.

Further comments on this URL:
http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-nemo-basic-support-02-patton.txt

[Ballot comment]
Editorial nits:

The NEMO acronym should be spelled out as "Network Mobility" in the abstract.

Section 2: RFC 2119 is cited as reference #2, but it's not listed among the references.

Section 4.2 (first instance): I noticed that all of the numeric values used in the document for things like status values aren't clearly identified as being represented in decimal format.  With values like "128" it's obvious, but at a quick glance values like "140" aren't so clear.  draft-ietf-mobileip-ipv6-24.txt, which is being expanded upon, does the same thing so I can understand continuing the convention.  I think it would be a good idea, though, to clearly note that these are decimal values and not octal values.