Subject: [nemo] NEMO Meeting minutes

From: "T.J. Kniveton" <[email-masked]>
Date: Mon, 18 Aug 2003 13:07:51 -0700

Here are the IETF57 NEMO meeting minutes that I reconstructed from the video.
They are also posted on the web page.

I have been having some difficulty editing the MPEG1 video of the meeting, but
as soon as that's done, I'll post it as well.

-TJ

IETF57 Network Mobility (NEMO) Working Group Minutes - July 16, 2003

Working Group Chairs: Thierry Ernst, T.J. Kniveton
Minutes by T.J. Kniveton <[email-masked]>
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 draft
   complete
 - Need to identify someone who can work on MIB for basic support

3) NEMO Basic Support - Ryuji Wakikawa
 * draft-ietf-nemo-basic-support-00.txt
 - Design team formed at last IETF
 - Initial draft has been submitted
 - Issue list home page at http://people.nokia.net/vijayd/nemo/issues.html
 - 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 protocol?
   - 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 proto
 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 check there
 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 0?
 - 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 BCE
   deleted.
 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 information.

 * 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 Network
 - 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 network
 - 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
   you attach.
 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 draft.
 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 progress.

4) Multihoming - Chan-Wah Ng
 * draft-ng-nemo-multihoming-issues-01
 * draft-charbon-nemo-multihoming-evaluation-00
 - Multihoming issues draft: last IETF suggested more clearly organized
   multihoming taxonomy, hence the new draft.
 - Julian Charbon and Chan-Wah evaluated basic support for multihoming reqs
 - 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 closed)
 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 difference.
 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 domains
 John _: What happens if home network is multihomed? Does it support HA in
   different domains?
 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 through ISP
 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 MNPs,
   CoAs, HoAs
 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 draft.
 - 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
   domain.
 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 the
   list.
 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 mind.

 - Moving forward, question about introducing text for Multiple CoAs and MNPs
 - 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 multiple CoA
 _: 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 used.
 - 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 item?
   For: approx. 14. Against: 0.

5) IPR Issues - T.J. Kniveton
 - Companies participating in IETF process are required to inform WGs about IPR
 - 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 Cisco.
 - Nokia has arranged Royalty Free (RF) license for open-source implementations
 - 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 otherwise
 TJ: For non open-source, general patent license applies (RAND) conforming
   to IETF requirements, as stated in the licensing statement.
 - 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 non-open-source
 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 list.

6) Threat Analysis - Souhwan Jung
 - Topics:
   - Three-layer threat model
   - Generic threats to NEMO
   - Discussion: What are threats specific to NEMO basic draft?
 * draft-jung-nemo-threat-analysis-00
   - 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 progress.

 * 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 protocol.
 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
   fixed network.
 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 tunnel.
 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
   normal routing.
 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 NEMO scenarios.
 - 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
 * draft-ietf-nemo-terminology-00
 - 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 Support

 * draft-ietf-nemo-requirements-01
 - 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 changes]
 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 change?
   - 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
     IETF meeting
 - Threats analaysis and security considerations discussion needs continued
   work
   - 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 quicker.