Subject: [nemo] Editorial comments from Jari Arkko

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 01 Dec 2003 18:07:26 -0800

hi Jari,

thanks for the detailed review.

>              Network Mobility (NEMO) Basic Support Protocol
> 
> JARI: Why "Basic Support"? Wouldn't Network Mobility Base
>       Protocol be a sufficient name for this?
> 

well, the term was in use before this draft was written. infact
it is used in the charter. "Extended Support" talks about route
optimization for the nodes in the mobile network. the WG has a
charter item to look into Extended Support and define
requirements.

> JARI: I think LFNs can be complete mobility-unaware, I think you
>       should mention this upfront as one of the benefits.

LFNs by definition are nodes which are not mobility aware. they
are fixed nodes. we already mention this once in the abstract
itself.

    The protocol is designed
    in such a way that network mobility is transparent to the nodes
    inside the mobile network.

> JARI:  Hmm... there might be value in defining the terms in a self-contained
>        manner here. I'm pretty sure you only use a subset of [8] terms,
>        so it wouldn't be that long.

I also believe in a document being self contained when it comes
to terminology. but there is a separate WG document on NEMO
terminology that is being advanced as an informational RFC. so
I am not sure.

>       Prefix Table
> 
>               It is a list of a Mobile Network Prefixes indexed
>               by the Home Address of a Mobile Router.  The prefix table
>               is managed by the Home Agent and is used by the Home Agent
>               to determine which Mobile Network Prefixes are owned
>               a particular Mobile Router.  This is an optional data
>               structure.
> 
> JARI: Really? Why is it optional? Sounds mandatory to me...

well, there could be scenarios where the mobile routers are not
expected to misbehave. and there could be other ways for verifying
this. so we left it optional. I dont mind making it mandatory.

>    A Mobile Network is a network segment or subnet which can move
>    and attach to arbitrary points in the Internet.  A Mobile Network
>    does not allow any transit traffic and can only be accessed via
>    specific gateways called Mobile Routers that manage its movement.
> 
> JARI: The above is a bit unclear. I think you mean that the
>       nodes behind the MR can't access the internet directly, they
>       have to go through the MR and the HA.

actually no. it means traffic to the Mobile Network can reach
the Mobile Network only through mobile routers. it also says
mobile networks are not transit networks. always stub networks.

> JARI: Question: is the prefix for a MR always unique? This seems unclear.
>       Can other MRs have the same prefix, can the HA have the same
>       prefix as the MR?
> 

more than one MR can be assigned a prefix. one can imagine having
two routers for the same mobile network. the HA will probably not
have the same prefix as the MR.

> JARI: Come to think of it, both the MR and the HA must know the
>       assigned prefixes beforehand in any case, so I wonder if we
>       need to communicate the prefixes at all?!? Can you cite an
>       example where the HA would give a prefix to the MR without
>       knowing it belongs to it? Or is the idea to prepare for the
>       eventual bootstrapping support in MIPv6?

well, we still havent figured out how to do prefix delegation
to a mobile router. there is a draft by Ralph Droms on extending
DHCPv6 prefix delegation for NEMO. not a WG draft yet.

and there is this scenario, where the mobile router is delegated
more than prefix, but it could decide to setup forwarding for just
one prefix instead of all prefixes. this cant be dont without
carrying prefix information in the Binding Update.

> JARI: So, presumably this includes forwarding of packets to
>       the MR's own home address under all these prefixes, no?
>       If so, I think we have the S=0 bit functionality when you
>       set R=1 ;-)

:) only if the mobile router has configured all its home addresses
from its MNPs.

> JARI: Is there something that you would perhaps like to 
>       reference from MIPv6 regarding this tunneling, or is [3] enough?
> 

why? are we missing something.

>    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.
> 
> 
> JARI: This is only a drawback if the routes would be reachable somewhere
>       else. Given the desire to keep the Internet routing pretty
>       stable, I would argue that we shouldn't be moving routes all
>       over the place. Hence it would be sufficient if the routes
>       were on one place only.

well, its a drawback in the sense, the Home Agent has routing table
entries even though the mobile router is currently dormant or just
disconnected.

> JARI: What happens in the statically configured route case if R=0?
>       Reading on...

there are two static cases.

1. implicit mode
2. dynamic routing protocol updates

which one are you referring to?

>    This document introduces a new Prefix Information field in the
>    Binding Update list structure.  This field is used to store any
>    prefix information that the Mobile Router includes in the Binding
>    Update.  If the Mobile Router sets the Mobile Router flag 'R' in the
>    Binding Update, but does not include any prefix information in it
>    (implicit mode), this field is set to null.
> 
> JARI: So, if you run a routing protocol over the tunnel, will this
>       information be updated in the BUL as well?

I think its not needed when a routing protocol is being run.

>    If the Binding Acknowlegement status is set to '0' (Binding Update
> 
> JARI: I don't understand this vs. what you are saying above in Section
>       5.3. What is the issue? Is it perhaps that due to your rules,
>       you can do an R registration without a single moboption and
>       hence the HA does not recognize that it doesn't support R? If
>       so, you should require your moboptions to be always present...
> 
>    accepted), the Mobile Router concludes that the Home Agent which
>    processed the Binding Update is a MIPv6 Home Agent that has not
>    implemented support for Mobile Routers.  It should send a similar
>    Binding Update to another Home Agent on the link.  If no Home Agent
>    replies positively then the Mobile Router MUST refrain from sending
>    any Binding Update with the Mobile Router flag set to any home agent
>    on the home link and log the information.
> 
> JARI: Hmm... forever?

actually this whole paragraph needs to be removed. it is left over
text from previous edits. my mistake.

>    A Mobile Router MAY limit the number of mobile routers that attach to
>    its mobile network (the number of levels in the nested aggregation)
>    by means of setting the Tunnel Encapsulation Limit field of the
>    Tunnel Encapsulation option.
> 
> JARI: So what happens if there is a loop? A packet that you send
>       travels through the loop until the encapsulation limit
>       is reached? Or is there some other defense?
> 

I guess this is related to your issue on loop detection. I will add
this to issue 24.

>    A Mobile Router MUST NOT ignore Router Advertisements received on
>    the egress interface.  The received Router Advertisements MAY be
>    used for address configuration, default router selection or movement
>    detection.
> 
> JARI: I wonder if the above paragraph could be replaced with
>       some reference to ND specs. As far as I can see, an MR should
>       follow ND rules on its egress interface when on a visited
>       network. 
> 

if you go by ND specs, routers ignore router advertisements. we are
infact saying router advertisements MUST NOT be ignored.

>    In some deployment scenarios it may be necessary for the Home Agent
>    to prevent a misbehaving Mobile Router from claiming mobile network
>    prefixes belonging to another Mobile Router.  The Home Agent can
>    prevent such attacks if it maintains a Prefix Table and verifies the
>    Prefix Information provided by the Mobile Router against the entries
>    in the Prefix Table.  However, this verification is done only if the
>    Binding Update contained explicit prefix information in the form of
>    either the Mobile Network Prefix Option or the Mobile Network Prefix
>    Length Option.
> 
> JARI: I think that verification could also be done at the routing
>       protocol case, assuming the HA can link the virtual interface
>       and the corresponding MR together.
> 

we assume routing protocols have their own mechanism for verifying
the routing information sent by a router. so we did not recommend
anything in the routing protocol case.

>     -  The Home Registration (H) flag MUST be set.  If not, the
> 
> JARI: Use 'H' instead of (H)

MIPv6 spec uses (H). :)

> JARI: Is it possible to go from a "R=1" BCE to an "R=0" BCE in
>       some manner? Or only deleting the BCE and registering
>       again?

the mobile router has to de-register and then register again.

>    The establishment and operation of the bi-directional tunnel is
>    implementation specific.  However, all implementations MUST be
>    capable of the following operations.
> 
> JARI: What does it mean that its implementation specific? What
>       specifically would you have to do to establish the tunnel
>       in the first place? Why can't this be specified?

setting up and using tunnels is implementation specific. some
people like to set them up as virtual interfaces. sometimes it
is just code in the IP stack.

> The Home Agent either uses only the routing
>    table, only the Binding Cache or a combination of routing table
>    and Binding Cache to route packets to the mobile network.  This is
>    implementation specific.  Two examples are shown below.
> 
> JARI: You are presenting the rules in a too implementation-near
>       form. Perhaps you could formulate something general
>       that has a MUST.
> 

there is a problem with it. the binding cache is a conceptual
data structure. sometimes it is just implemented as a routing
table entry. one implementation (of mobile routers), I know,
uses the binding cache for both routing and CoA lookup. so
we left it implementation specific. and we present two ways
of doing it.

we had a long discussion on using the binding cache or routing
table for the HA to forward packets to the mobile network. this
discussion happened before this draft was written up.

>    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 [10] and OSPF [11] 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
> 
> JARI: Can you give a practical example of where this could be the
>       case? I can't think of any, but maybe its just me...

it could happen when there are multiple mobile networks attached
to the mobile router, each one having different prefix, but want
routing enabled for all these prefixes through the Home Agent.
using a routing protocol makes sense here.

>    Since the routing protocol messages from the Home Agent to the Mobile
>    Router could potentically contain information about the internal
>    routing structure of the home network, these messages require
>    authentications and confidentiality protection.  Confidentialy
>    protection using IPsec ESP [4] in tunnel mode MUST be supported and
>    SHOULD be used.
> 
> 
> JARI: It might be necessary to have some more detail about this.
>       What kind of SPD entries are needed etc.

should be straight forward. OSPFv3 and RIPng use specific transport
protocols and ports. for example the SPD entry on the mobile router
would say "if routing protocol message with destination=HA, use a
particular SA which would do tunnel mode ESP".

your other suggestions were accepted.

Vijay

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 2 Dec 2003 10:36:43 -0000

> That would make sense. Imho all nemo-based products
> should support this function.

Yes, and it's very abstract. It can be implemented as a set of static
routes.

> I'm still having some difficulty with the transit network
> part. I looked up one definition of a transit network from RFC
> 1584, which talks about the number of attached routers. However,
> in the nested nemo case you could actually have several attached
> routers, hidden inside tunnels. And would you allow multiple
> MRs per Mobile Network or not? I think not, because then you
> would appear like a transit network, according to the
> RFC 1584 definition. OTOH, I'm not sure why such a limitation
> would be necessary in the technical sense.
> 
> Is it allowed for an MR to have two home agents, home addresses,
> and network prefixes? Is there any case where the Mobile Network
> would become a transit network in such a situation?

Jari:

This is entering the multihoming discussion, again out of scope. We
tried to define formats that would allow for it. But we do not detail
how that works. Like RO, multihoming in Nemo has multiple faces (see
http://www.ietf.org/internet-drafts/draft-charbon-nemo-multihoming-evalu
ation-00.txt)

> How about this:
>     can only be accessed via specific gateways called Mobile Routers
>     that manage its movement. Mobile Networks have (always exactly)|
>     (at least) one Mobile Router serving them.
> 
> Ok.
> If this is the case, perhaps you could remove the static alternative
> then? My concern is mainly the number of alternatives. I'd rather
> have less alternatives, even if the BUs would carry a few more bytes
> in some cases...
> 

Halt! If there's only one thing left, in my mind it's static. The way I
see the original question is more like: why do we need explicit if the
HA has the prefix table anyway for authorization purposes? For the lack
of a better one, my answer is that the authorization may be more global
or turned off by policy.

Having more then one mode opens for different deployments. MRs do not
have to support them all, only the HAs do (we definitely should write
our own version of the MIPv6 8.4 and 8.5 chapters). And static comes
free with the HA. So why remove it?

> Its additional state yes, but packets destined to the prefix will
> be dropped on the floor in any case.

This is why I like static :)

> Either one.

I have trouble to call 2. static... For 1., the spec says not to install
forwarding, but on the other hand it's already installed and can hardly
be removed (should we send an alert and ask the operator to
reconfigure?). So I'm not sure of the value of r=0 in implicit mode. We
discussed that already and I'm still not convinced. 
> 
> I think the key question here is whether running the routing
> protocol makes a difference in the end. Is it used to avoid
> sending useless packets to the MR? Most likely such traffic
> would be minimal, given that there would be no response from
> the networks that are currently disconnected. Or is it used
> to make some real routing changes, such as switching the
> traffic from one HA site to another one? If yes, this needs
> to be supported.
> 
> Like I said above, I'm primarily concerned about the number
> of alternatives and that's why I'm trying to see if we really
> have a true need for all three, i.e. static, BU, and routing
> protocol alternatives.
> 
The routing protocol thing could be considered out of scope. Once the
MRHA tunnel is established, any manual tunnel can be used to carry IPv4,
multicast, or an IGP back home. Do we have to explicitly say all this?
Maybe we could move it to "usages"?

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 3 Dec 2003 08:47:54 -0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Vijay Devarapalli
> Sent: mardi 2 décembre 2003 22:06
> To: Jari Arkko
> Cc: [email-masked]
> Subject: Re: [nemo] Editorial comments from Jari Arkko
> 
> Jari Arkko wrote:
> 
> >> fine with me.
> > Ok, but you still need to pick either "always exactly" or
> > "at least".
> 
> we cannot restrict to one mobile router. so its "at least".
> 
> >
> >>> Would it be useful to follow MIPv6 base Section 5.5 guidelines
> >>> on the use of source addresses?
> >>
> >>
> >>
> >> we already say in the spec (section 5.5), what the source and
> >> destination addresses should be for the inner and outer IPv6
> >> headers when sending packets through the bi-directional tunnel.
> >
> >
> > Yes, but you are not requiring that the source addresses be
> > checked. This opens a reflection attack via home agents that
> > don't get this.
> 
> there is some text in the Security Considerations section.
> 
>     The Home Agent has to verify that packets received through the
>     bi-directional tunnel belong to the Mobile Network.  This check is
>     necessary in order to prevent nodes from using the Home Agent to
>     launch attacks that would have otherwise been prevented by ingress
>     filtering.  The source address of the outer IPv6 header MUST be set
>     to the Mobile Router's current Care-of address.  The source address
>     of the inner IPv6 header MUST belong to the Mobile Network Prefix
>     owned by the Mobile Router.
> 

Note that in the reqs I proposed yesterday, I first thought I would copy that text and then I realized it was a bit restrictive and I replaced by topological correctness for the inner packet. What do you think? I believe this should be changed in the security section as well.

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 3 Dec 2003 10:18:46 -0000

> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: mardi 2 décembre 2003 23:53
> To: Pascal Thubert (pthubert)
> Cc: Jari Arkko; [email-masked]
> Pascal Thubert (pthubert) wrote:
> 
> Pascal,
> the usages document is not the answer to everything. you are
> suggesting using the usages document for everything that is
> thrown out of the basic spec. :)
> 
> you have to keep in midn that it is targeted at informational.
> 
Yes, actually that's the whole point ...

> infact as you say, running a routing protocol over the
> bi-directional tunnel is not very different from say running
> DHCP prefix delegation over the tunnel. it is just some
> traffic. but in this case, traffic which affects routing
> tables on the Home Agent and the mobile router. we need to
> say how it interacts with sending routing information through
> the binding updates. so, I think it should stay in the basic
> spec.
> 
My point is that there not a line of code or a bit in the protocol that is affected by IGPs over the MRHA tunnel. Thus that much is informational. It may contain deployment recommendation and caution and I'm happy that the text exists. But the people interested are not the implementers, it's aimed at the deployers. This is why I proposed the usage draft as a repository.

As of the part of the text that discusses the MR running and IGP only if at home, yes I agree this much is important in basic. Maybe the right place for that text would be close to 5.6, since that's the place where we say that when not at home, the MR acts as a host on the egress link. 

Note that the MR MAY run an IGP when at home. It does not do so in the case of aggregated Home network or in the case of static routes. So the text COULD be revisited a little bit ;)

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 3 Dec 2003 10:18:46 -0000

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 4 Dec 2003 07:27:16 -0000

> Sent: mercredi 3 décembre 2003 19:01
> > Note that in the reqs I proposed yesterday, I first thought I would copy
> > that text and then I realized it was a bit restrictive and I replaced by
> > topological correctness for the inner packet. What do you think? I believe
> > this should be changed in the security section as well.
> 
> hmm.. either way is fine with me. but dont you think "topological
> correctness" is vague compared to what is there currently?
> 
In the simple case it should end up being the same. 

But take the case where you run a tier routing protocol over the tunnel that has its own trust model. You can not refer to the prefixes obtained that way as MNPs.

The routing table can be seen as the repository for all prefixes that are authorized from a direction, whoever installs the routes.

Pascal