IETF57 Network Mobility (NEMO) Working Group Minutes - July 16, 2003
Working Group Chairs: Thierry Ernst, T.J. Kniveton
Minutes by T.J. Kniveton <email@example.com>
Thanks to note-taker Karim El-Malki.
Wednesday July 16th 13:00-15:00; Vienna, Austria.
1) Brief intro and Agenda Bashing - TJ
- No comments on agenda.
2) NEMO status and milestones - TJ
- Charter updated at beginning of year
- Review - do some milestones need updates?
- Will wait until terminology, requirements, and basic solution are done
and submit all three together
- More discussion necessary on security analysis after basic support
- Need to identify someone who can work on MIB for basic support
3) NEMO Basic Support - Ryuji Wakikawa
- Design team formed at last IETF
- Initial draft has been submitted
- Issue list home page at
- Ryuji explains slides of how basic support draft works
Comments on issues raised:
* Issue 6
- How does HA distinguish between implicit mode and dynamic routing
- Add an explicit flag to the binding update?
- Do we need to check the consistency of prefixes between routing
protocol and BU signaling?
Pascal Thubert: It's quite common to have a route advertised from
different sources; e.g. OSPF and RIP at the same time. They don't have to
talk to each other and check consistency. The router has to decide which
route is used.
- We may be able to accept prefix information by binding update and by
Erik Nordmark: If MR is allowed to inject any prefix into routing
system, no problem. But if it is authorized to only inject certain
prefixes, you need to check, i.e. as part of binding update or rt proto, if
it is authorized.
Ryuji: Do we need to say something in base spec?
Erik: You might want to point out authorization issue, but not
necessarily say how it can be solved.
Felix Wu: In 6.1, you have a prefix table. The check for the table does the
authorization check. So you might want to be more explicit about doing the
Pascal: We mentioned that we could use prefix table to check BUs in
explicit mode. For routing protocol, OSPF has its own way of
authorizing. We don't expect to change the routing protocols. Is this if we
have to introduce a new rt proto
Felix: If you receive BU from MR, you need to do authorization check to see
if the MR really owns this prefix.
Pascal: Question is if you want to run rt protocol as it exists today. If
you have concern, just don't configure routing protocol on the tunnel.
Erik: If that's the approach the WG wants to take, you should document it,
i.e. if you want to run a routing protocol over this, it will inject
routes for any prefix. In multihoming case, if you have 2 tunnels in a
single routing domain, you only inject one prefix.
* Issue 3
- Should HA forward packets for the MNNs to the MR if the R flag was set to
- Resolution: no, if R is 0, the MR is only a mobile host.
- Should HA store prefix info in BCE?
- Resolution: Yes, in explicit case, useful for deleting prefix route when
Chan-wah Ng: In implicit mode, how does the home agent generate the
prefix to be stored in bindiing cache?
Ryuji: In proposed text, we didn't say anything about implicit case. It
might limit the implementation too much.
Pascal: This is being debated now on the mailing list. It's not
important what caused MR to inject route, but you must be able to clean it
up. In implicit, the MR is not injecting routes, so you don't need this
* Issue 5 - presented by Pascal Thubert
- Chapter 7 needs to be made clearer.
- We would like to have aggregation of mobile networks that can be
advertised without injecting individual prefixes, called Extended Homne
- Considered like a pie cut into pieces, with each piece given to a MR
- EHN can be "the" home network, or you can have it in a virtual
- Figure shown on how to bring mobile network home in EHN
Erik: picture shows /48 assigned to a wire.
Pascal: This is just an example. You can make home network <=> EHN
Erik: I don't understand problem. Config you described falls out of how
basic support works. If running rt proto, when you move home, run it where
Pascal: Want to avoid encapsulation.
Erik: Assuming you're not running IGP. OK I understand problem.
- Also intended to keep things open, not to prevent multihoming
Greg Daley: Arrival home (w/o rt proto) is less likely to occur in most
cases. Maybe this could be a separate draft, with options available in base
Pascal: Wanted basic to be small, and write side draft if needed. So
nothing about multihoming, route optimization, multicast.
TJ: Design team will issue -01 draft before next IETF, already in
4) Multihoming - Chan-Wah Ng
- Multihoming issues draft: last IETF suggested more clearly
organized multihoming taxonomy, hence the new draft.
- Julian Charbon and Chan-Wah evaluated basic support for
- But it missed draft deadline. URL published on mailing list.
- 4 Problem categories identified on on mailing list.
- They have been renamed according to (x,y,z).
- x is single MR vs. multiple MRs.
- y is single HA vs. multiple HAs.
- z is single MNP vs. multiple MNPs.
* Issue: registration of multiple CoAs
- More of a MIPv6 problem
- Addressed by Ryuji's multiple CoA draft in MIP WG
* Issue: registration of multiple MNPs
- Support already available in the basic support draft (issue can be
Pascal: There is no equivalent of DAD test for MNPs in base draft.
I.e. two links can believe they're the same prefix. So we have to test
regs so we don't have a double registration. With multihoming you want to
accept the second registration. So we have to be able to detect the
Erik: Desire to have same prefix advertised (explicit or through BUs) at
different places, to allow redundancy. But that doesn't mean address of
router has to appear in multiple places. HoA -> CoA is 1:1 mapping, but MNP
can show up in multiple places.
* Issue: BU registration to different HAs with same HoA
- Also MIPv6 specific. Can HA be in different domains?
- Suggestion on ML not to support case when HAs are in different
John _: What happens if home network is multihomed? Does it support HA in
Chan-Wah: When home net is multihomed, it is not a NEMO concern.
Pascal: If you have prefix 1 registered to HA1, you can have prefix2 to
register with HA2, so you can stay available.
John: Connection to prefix1 is broken. Better to have connection
Pascal: Just a matter of trust; it's hard to sign a BU for a prefix.
* Issue: Need for MR to indicate policy preference for different
Felix: If I have 2 MNPs belonging to 2 admin domains (2 HAs), will
packet with SRC in MNP1 be sent through HA2?
Pascal: We should add something about source address selection.
Interface selection should choose the address corresponding to that HA.
Felix: Within mobile net, we use ad-hoc protocol with 2 MRs. The proto has
to be defined carefully, or it would go to the wrong MR. Routing would have
to consider source address, not just destination addr.
Erik: Interaction between source addr selection, multihoming not
NEMO-specific Outer address has to be topologically significant for
ingress, and inner address has to be topologically significant for HA.
Chan-Wah: Can this be handled by multi6 WG? We can restrict each MNP so it
can only be registered to one HA.
* Issue: Fault Tolerance
- When egress interface of MR fails, we should have alternate path. But
this could be a problem with ingress filtering in the other domain.
* Eliminating Scenarios
- (See slides for summary of each case)
Ryuji: Question on 3rd and 4th case. I gave presentation at MIP WG
today. I would like to know if there is functionality missing from our
draft for NEMO
Erik: There is a way of simplifying two bottom ones. Such a MR with
multiple tunnels, if it has 2 HoAs, you don't need to do multiple CoA
registrations. You can just use two HoAs that are for the same MNP.
Ryuji: Idea to register multiple CoAs proposed by Pascal first. If MR must
have multiple HoAs, for each interface I need different HoAs. If all
interf bound to same HoA, we can hide the number of interfaces on MR.
Erik: If you want to test whether tunnel/interface working, can't use HoA in
that case. Not unique.
- This scenario can be supported by basic NEMO solution be
restricting interface to a single HoA, or by using Ryuji's multiple CoA
- Conclusion: Basic NEMO support can support these scenarios.
- Next 4 involve multiple HAs. Can HAs be in different domains?
- Suggestion to restrict basic NEMO support on multihoming to HAs in same
Felix: Another question for (1,1,0). Assuming they belong to same
domain, can I announce one prefix to one HA, and a sub-portion of that
prefix to another HA?
Chan-wah: might still have problem of ingress filtering. Let's move it to
Pascal: With basic, it will be difficult. The EHN is the only thing that
leaks out of HAs. It could be configured, but that's not what we had in
- Moving forward, question about introducing text for Multiple CoAs and
- Preference Indication in BU? MNP preference in RA?
- Fault Tolerance - devise solution to enable fault tolerance
- Is WG interested in these?
Karim: Didn't you say multiple CoAs would be solved in MIPv6?
Chan-Wah: Multiple prefix registration could cause problem with
_: We are working on this problem in the multi6 WG.
TJ: Consensus sounds like this will be solved in multi6 /other groups
_: Multi6 has taken years to get to nowhere. If you want a solution, move
forward. But don't just toss it to multi6 now
- Preference Indication:
Erik: Prefixes are tricky because you don't know how to interpret them. You
might be able to convey some info, like you have a primary and backup
tunnel, i.e. on 802.11 and GPRS. But you have to be careful how it is
- We are running out of time, so the rest will be on the list.
Thierry: Status of multihoming documents: should they be a working group
For: approx. 14. Against: 0.
5) IPR Issues - T.J. Kniveton
- Companies participating in IETF process are required to inform WGs
- Status of IPR on basic draft: Nokia and Cisco have said there may be IPR
related to basic draft.
- TJ has attempted to clear up licensing position on these
- Within the last couple of weeks, Nokia has posted an IPR
licensing statement for the basic draft on the IETF IPR web page, as has
- Nokia has arranged Royalty Free (RF) license for open-source
- Cisco has granted Reasonable and Non-Discriminatory (RAND) license,
based on reciprocity.
* Does WG feel that RF is necessary, or is RAND ok?
- If RF desired, we need to get more information
George Tsirtis: RF (Nokia) is for open source only. So not even RAND
TJ: For non open-source, general patent license applies (RAND)
conforming to IETF requirements, as stated in the licensing
- Not clear whether Cisco does RF licensing. What does WG wish to do?
Kent Leung: Nokia and Cisco both have RAND at this point, for
Erik: Another possibility is to find out more about Nokia IPR, if people
are interested in non-open source implementations. I can also answer
general questions. But this is up to the WG to decide how to proceed. Once we
know something about the claims from patent published or application or
another way, then we have more info about how to proceed. But we have to
have well-informed opinions on how to proceed.
Greg Daley: I had some experience with non-RF licenses in GPL
development, and it really stops the development dead for Linux. So
further info from Cisco would be good; Nokia is cleared up for GPL.
Chan-Wah: Important thing is to know which portion of NEMO basic
support the IPR covers. Can we have scaled-down version not covered by IPR?
Erik: If people want to try to find out more, they could ask
companies which have submitted notices for more info. But you might not get a
response from the lawyers. If people are willing to provide more info, that
might be useful for WG. If WG believes RF for open source, or RF in
general is critical, then we can send that message to the people holding the
IPR, and they might come up with better terms. That has happened in the
past in other working groups.
- Since we are running over time, let's continue this discussion on the
6) Threat Analysis - Souhwan Jung
- Three-layer threat model
- Generic threats to NEMO
- Discussion: What are threats specific to NEMO basic draft?
- provides a generic approach to protocol threat analysis
- Example NEMO configuration shown in figure
- Threats to signaling and data path: MR-HA, MR-MNN, MNN-CN
- Compromise of MR or HA
- DoS, Traffic Analysis
- What are the threat issues to NEMO basic support draft?
- This draft was written before the basic support draft. Still in
* Issue 1: Threat to MR
- MR is most important entity in NEMO. IPsec protects signaling b/t MR & HA
- Compromise of MR can cause serious problems in NEMO operation.
- Correctness of BU is critical. HA must double-check
John: MN is as important as MR. Is there a serious difference?
Souhwan: compromise of single node might not be problem, but MR causes
problem for every MNN. MN has same problem, but we don't need
mechanism for MN.
Alper Yegin: I agree there is a threat, but in context of NEMO, what
should we be looking at? Should we be detecting when MR is
compromised? We might be trying to do things not doable with NEMO
Souhwan: We did not come up with solution, but maybe something like RR in
MIPv6 can show if MR not working correctly.
Felix: One of the problems with MR being compromised is that he can
announce any BU, and suck in other address traffic to this mobile net, if HA
does not perform prefix table check as performed in basic solution.
Alper: Compromise of MR in NEMO is same as compromise of access router in
Hesham Soliman: How are these threats different than threats to any
generic host on the Internet? Why is IPsec not enough? Associating HoA with
SA is enough. Why is this specific to mobility?
Souhwan: MR is so important for NEMO operations, we need to
doublecheck whether packet is delivered to correct node
Hesham: Same problem for nodes in Mobile IPv6. Not specific to NEMO.
* Issue 2: Threat to HA
* Issue 3: Threat related to multi-homing
- (This is basically the same issue with address selection and
multiple HAs discussed earlier -- see figure in slides)
- DoS attack may be related to this phenomenon
- Comments? None.
* Issue 4: Traffic Analysis
- Traffic from mobile networks go through bi-directional tunnel. So it is
the same as in Mobile IP, but more severe because traffic goes through
Hesham: So where is the threat in this?
Souhwan: DoS attack can be connected to this, if we change the routing
mechanism. So routing to MR2 can cause packets to be blocked.
Hesham: Again, this is not NEMO-specific. In any multihomed site, you need
to route things so that packets won't be blocked. There's no NEMO
protocol inside the yellow cloud [Mobile Network].
Pascal: Key thing here is that we wanted NEMO to be a stub network. So we
cut routing paths that would end up having HA2's routes to be
advertised at HA1.
Hesham: OK, but we don't do any routing inside mobile network cloud. It's
Alper: I agree with Hesham here. What we are looking at are not
NEMO-specific threats, they are general Internet architecture issues with
security. What we should be addressing are threats specifically created by
- Location information of MR may be extracted by traffic analysis.
- This is also arguable whether this is a specific problem to NEMO.
Felix: I would like to comment about some of the questions asked
earlier regarding what we are doing here is generic to all protocols. It was
mentioned that IPsec can be broken or compromised. When we say IPsec is
insufficient, it is because it provides confidentiality and
authenticity. But it does not provide authorization. But in NEMO, the
requirement is for a relationship between MR and HA allowing
authorization. So the protocol has to handle this issue in some way. So
that particular problem is very NEMO-specific. As for multihoming, it is
probably going to be dealt with by Multi6.
7) Updates of Terminology and Requirements Drafts - Thierry Ernst
- Was personal submission first; is now a WG document.
- General terminology has been moved to SeaMoby terminology draft.
- May be useful to add new terms related to multihoming. Already a
section on multihoming and nested mobile networks.
- Terms specific to NEMO Basic Support should be defined in Basic
Support draft. Perhaps we need to remove/add new terms.
Pascal: We are using "top-level mobile router". Could you bring the term
back from the dead?
Thierry: Synonym is "root MR". You can use it as well.
- Would be best to submit this draft at the same time as NEMO Basic
- Title has been slightly changed from NEMO Requirements to NEMO Goals and
Requirements, because some sections are not mandatory.
- Section 4 renamed to NEMO Design Goals.
- Removed MAY and MUST.
- Section 5 contains the actual requirements for basic support.
- [Various changes to requirements reviewed; see slides for exact
Pascal: on R02, it seems all tunnels must be active at any point in time,
which is not really what we want. Maybe the second MR can be a backup.
Thierry: When we say must set up a bi-directional tunnel, probably
doesn't have to be set up all the time. It's tricky.
- Should we put reference to MIPv6 (R09)under 17? Who doesn't want to
- Take it to the list
- Multihoming (R12) - changed from MUST to SHOULD. 12.1,.2,.3 may not be
necessary, because they are contained in terminology. (No comments).
- NEMO support signaling over tunnel must be minimized - should we bring
this requirement back?
TJ: It's hard to tell what criteria are and whether the requirement has
been met, when you say signaling must be minimized.
- R17 - Please state what protocols are important to be backward
compatible with. Please send this information to the mailing list so we
know what is important.
- R18 - Should we put this into the requirements as well?
Pascal: It seems fair if one egress interface fails, and MR has 2nd
interface, that it carries on with that one. Now with two mobile
routers, it's hard to detect; it's the same multihoming problem again.
Thierry: Doesn't mean NEMO basic support must support it, but if we agree
it's important, we can work on it. I put it as a SHOULD so if someone
wants to work on it.
Greg Daley: It's a little unclear, because it's talking about "should
preserve sessions" as if it's participating in the sessions or has some
state. So we should change wording to reflect "should allow sessions to
continue uninterrupted" so it's not misleading.
Thierry: Please propose on mailing list.
8) Conclusions and Next Steps
- Basic support draft - we had some good input today
- There are some remaining issues to resolve
- -01 draft alpha version is already complete; based on today's issue
discussion and mailing list discussion, it will be finished before next
- Threats analaysis and security considerations discussion needs
- i.e. which threats are specific to NEMO; guarding against
NEMO-specific vs. Mobile IP threats.
- Identify parties to work on MIB milestone
- Gather information and get clarification on IPR
- Develop WG consensus on how to proceed with IPR stakeholders
- WG meeting today identified multihoming as a working group topic
- Perhaps add this as a milestone to charter
Erik: In terms of getting documents finished, it might make sense to be
more structured to track issues on mailing list, propose text, and close
issues to get them finished