Subject: [nemo] Draft NEMO Agenda

From: Thierry Ernst <[email-masked]>
Date: Wed, 06 Nov 2002 02:05:02 +0900 (JST)

Dear all, 

Here is a tentative agenda for our meeting. We have 2 hours, and we
would like to make a good use of that to progress forward the
requirements. 

WEDNESDAY, November 20, 2002
1530-1730 Afternoon Sessions II

o NEMO WG tentative agenda - length 2h.

- 05min Agenda Bashing (Chairs)
- 15min Charter review 
- 40min Requirements for Basic Support
          Report of analysis and comparison
          (commonalities and divergences)
      	  draft-ernst-nemo-requirements-00.txt 
          draft-kniveton-monet-requirements-00.txt 
      	  draft-ng-nemo-aaa-use-00.txt 
      	  draft-janneteau-nemo-requirements-00.txt 
      	  draft-sarikaya-nemo-archreqs-00.txt 
- 15min Terminology Update
	draft-ernst-nemo-terminology-00.txt 
- 15min Threat Analysis ?
- 15min Basic support issues
- 15min Future Steps and Milestones

We don't already have input for the Threat Analysis not for the Basic
Support issues, so if any one has something to say about this, that
would be the right moment to start.

For Basic Support, we know that we are going to set up a biderectional
tunnel. So, I wonder if anyone of you had already some thoughts about
the potential issues it may cause ?

Thierry.

---

From: Christophe Janneteau <[email-masked]>
Date: Tue, 05 Nov 2002 18:57:43 +0100

Hi Thierry and all,

> the potential issues it may cause ?

Our draft <draft-petrescu-nemo-mrha-01.txt> do attempts to list some
issues around the bidirectional tunnel approach. Especially it discusses
the following issues:
- auto-configuration of CoA by MR
- use of Link-local addresses for regular routing versus the need of a
globally routable Home Address
- ICMP redirect mechanism from BR to HA
- and some others...

Christophe.

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 05 Nov 2002 10:25:40 -0800

Hi all,

> the potential issues it may cause ?

three issues that we need to consider. we came across them when
we implemented draft-kniveton-mobrtr-02.txt.

1. there is no way for the Home Agent to figure out which mobile 
router is allowed which mobile prefix. when it receives a binding 
update with the 'R' bit set, it creats a static route for the 
prefix to point to the home address of the MN. one solution is to 
have a mapping (created manually at the home agent) between mobile 
routers and their prefixes. the Home Agent checks this mapping 
before accepting the binding updates from the mobile router. we 
have implemented this currently.

in base MIPv6, the security association between the HA and the MN 
is tied to the home address of the MN. if the MN configures a new 
home address, it has to create a new security association for that 
home address. if we can somehow associate the prefix and the home
address of the mobile router with the security association, we can 
easily solve this. otherwise we have to come up with something new.

2. the packet format (if we assume the bidirectional tunnel is
protected by IPsec). we werent sure which one to follow.

IPv6 hdr (src=MR_CoA, dst=HA)
Dst Opts hdr (MR_HoA)
IPsec hdr
IPv6 hdr (src=X, dst=CN)
Payload

or

IPv6 hdr (src=MR_CoA, dst=HA)
IPsec hdr
IPv6 hdr (src=X, dst=CN)
Payload

where X is a node in the mobile network. MR_HoA and MR_CoA are the
home address and care-of address of the mobile router respectively.

if we go with the concepts described in 
draft-ietf-mobileip-mipv6-ha-ipsec-01.txt, which assumes we can
change the tunnel gateway address (MR_CoA) as the MR moves, we
can have the second format (which eliminates the extra destination
options header).

3. what is the next hop to be used for the static route for the
mobile network's prefix created on the home agent? the choices
are 
   a. the tunnel interface (MR_CoA, HA)
   b. MR_HoA. 

in (b), the binding cache entry for MR_HoA tells the HA where 
to send the packet. both (a) and (b) work. for (a), we need
to delete/create a static route whenever the MR moves and
changes its CoA. (b) results in a larger packet (the extra
destination options header), unless you resort to some ugly
code which keeps the packet format same.

regards
Vijay

ps: I apologize for not using the terminology from
draft-ernst-nemo-terminology-01.txt. I havent read that draft 
recently.

---

From: Christophe Janneteau<[email-masked]>
Date: Wed, 06 Nov 2002 10:24:54 +0100

Hi Vijay,

Thanks for raising these very good points...we also have identified some
of them when discussing the bidirectionnal tunnel approach for NEMO.

> have implemented this currently.

Note that, in the special case where the HA is co-located with the
Border Router of the Home link, configuration of such a static route
upon reception of BU from MR is not needed. In fact, BR (i.e. HA) should
already have such a route from MR's prefix (indicating MR_HoA as next
hop) in its local routing table. This is the very same entry used by BR
when it is to forward a packet to a nodes behind the MR while MR is at
home. Note that this entry could have been configured manually on BR (by
netowrk manager) or automatically through a routing protocols such as
RIP or OSPF.

In situations where HA and BR are not co-located, then there is a need
for MR's HA (who will interect packet addressed to LFN while MR is away
from Home) to discover that packet addressed to a LFN should be in some
way forwarded towards MR. Several apporaches are possible:

1- Use of a permanent static route on MR's HA: "permanent" mean
irrespective of the location of the MR, at home or in a visited netowrk.
This is simple, on the other hand it requires the network manager to
take care of this static entry and ensure it is always consistent with
the rest of its routing infrastructure (e.g. in case of renumbering). 
 
2- Use of a static route on MR'HA dynamically configured upon reception
of a BU. As Vijay explained, this imply MR'HA to apriori know the
binding between MR and MR's prefix (in the Mobile Netowrk). Here this
binding would be manually configured by the netowrk manager in a
"mapping table" and included dynamically in the HA's routing table upon
reception of a BU from MR. But again this requires careful management of
this "mapping table" as for the previous approach. Note that in this
approach, a prefix scope binding update is not require since the mapping
between MR and its prefix is available in the "mapping table". Actually,
the PSBU (from MR to HA) does not seems to help here since there is no
way for the HA to verify that the MR is authorized to claim such a
prefix. So, even in the case of PSBU, such a "mapping table" would still
be required for authorization...

3- Extend HA to trigger an ICMP redirect from BR to HA to dynamically
configure a temporary route LFN->MR on MR's Home Agent, upon reception
by HA of a packet addressed to a LFN. (we describe this is
draft-petrescu-nemo-mrha-01.txt). The great advantage here is that the
process is dynamic and relies on existing mechanism (ICMP redirect),
there is no need for the netowrk manager to maintain static
configuration on the Home Agent for MR's prefix. On the other hand, this
create per-host entries (LFN->MR) instead of per prefix entries
(MRprefix->MR).

4- Extend HA to make it aware of the home netowrk routing topology, e.g.
by listening to RIP messages. This is the most dynamic approach.

[...]

> code which keeps the packet format same.

Agreed for these two approaches. I think a third one could be:

c. A tunnel interface (MR_HoA, HA).

But this would result in an extra encapsulation: the first one due to
this tunnel towards MR_HoA, and the second one due to the MIPv6 tunnel
towards MR_CoA (after parsing of HA Binding Cache)....
 
It is not clear to me why b. results in a larger packet that a. In my
understanding, b. will indicate the Home Agent that next hop towards LFN
is MR_HoA upon parsing of its routing table. The HA should then parse
its Binding Cache and recover the current location of this next hop
(i.e. MR_CoA) and send this packet in the MIPv6 tunnel. I should miss
something but I don't see which extra header you refer to?
On the other hand I think a. as the advantage to avoid parsing of the
Binding Cache, the routing table is enough...but this is highly tied to
implementation in my opinion.
 
Thanks again for raising these points,
Christophe

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 06 Nov 2002 16:59:31 -0800

hi Christophe,

> way forwarded towards MR. Several apporaches are possible:

please see my reply to Alex. routes expire (it does not matter 
whether they were on the home agent or the border router). there 
should be a way to create a route when the mobile router sends a 
binding update with 'R' bit set.

> c. A tunnel interface (MR_HoA, HA).

when is this tunnel interface is used?

> towards MR_CoA (after parsing of HA Binding Cache)....

yes. its bad. I think we should avoid (c).

> something but I don't see which extra header you refer to?

option (b) creates the following packet in our implementation

IPv6 hdr (src=HA, dst=MR_CoA)
Routing Hdr (type 2, contains MR_HoA)
IPv6 hdr (src=CN, dst=LFN)
Payload.

but you are right. there is no reason why it should add the 
routing header. I think it is a limitation in our implemenation.
I will fix this.

> implementation in my opinion.

I agree it is tied to the implementation. but packet format on 
the wire has to be standardised. it makes a difference when it 
comes to IPsec.

regards
Vijay

---

From: Mattias Pettersson <[email-masked]>
Date: Thu, 07 Nov 2002 14:05:10 +0100

Hi,

> something but I don't see which extra header you refer to?

We have to be very careful to specify in what order the routing table
and the binding cache are searched. I'm not sure that this is clear to
everyone (at least not to me) and it can cause future problems.

> implementation in my opinion.

Yes, we should avoid searching the binding cache.

/Mattias