Subject: [nemo] Unmodified CN? (Was: Launching Requirement Discussion)

From: Alexandru Petrescu<[email-masked]>
Date: 02 Nov 2002 15:33:14 +0100

Thierry Ernst <[email-masked]> writes:
> Anyway, may I ask all people interested in clearing up the
> requirements to read the drafts and to figure out what are their
> commonalities and divergences and comment on what is new, what is
> still not clear, and what is missing ?

There are indeed many commonalities, and there are also many
divergences.  I've been trying to compile a list of requirements by
eliminating the commonalities, or grouping them.  The list is attached
but I have no pretension with this list, I do not pretend it to be
neither complete nor correct.  Everything is copied from drafts, and
the idea to introduce non-goals is also from a draft.

There's much text about CN not being modified.  What is the considered
CN that shouldn't be modified?  A non-Mobile IPv6 CN?  An
RO-supporting CN?  The same questions about LFN.

Alex

General Requirements
--------------------
   Unified and unique NEMO protocol v4 and v6.

   Migration Transparency: unicast and multicast session continuity,
   no interruption to TCP after IP address change of MR.

   Reachability at permanent home address.  Must work as if the mobile
   network were at home.  Rely on the MRHA bidir tunnel of Mobile IP
   and Mobile IPv6.

   Internet-WIDE mobility, heterogeneous first hop L2s, inter-domain.
   No impact on the routing fabric neither on the Internet addressing
   architecture.  At IP layer, handover at IP layer, no impact on TCP.

   Seamless mobility, low latency, as seamless as host mobility,
   co-existence with fast handoffs.  Support vertical, horizontal and
   diagonal handoffs.

   Minimum signalling overload: number of new NEMO messages kept
   minimal.

   No impact on CN

   Mobile CN, MNN

   Must work with non-Mobile IPv6 LFNs.

   All mobile network topologies from small to large, from single to
   nested.  Large number of mobile networks.  Large number of CNs.

   Comply to IPv6 node requirements

   Multi-homing: the NEMO protocol supports multi-homed mobile
   networks.

   Architectural considerations: there's an MR.  IPv4 co-localization
   or separation of MR and FA.  Leaf mobile networks and not transit
   networks.

   Standardization and implementation-oriented focus.

Security requirements
---------------------
   Co-existence with AAA.  Detailed AAA requirements in draft-ng.

   Security: NEMO should not introduce more security threats than
   Mobile IPv6.

   Securing the route-updates when changing CoAs.

   Confidentiality: MNNs confidentiality.

   Authentication: control messages must be authenticated.

   Authorization: sender is authorized.

   Location privacy: MNNs hide their location to third parties.

   Access control: VMNs are access controlled.  Access control MR-AR.

Non-goals
---------
    Host mobility.  This is the problem domain of Mobile IP.

    Administration of the network

    Address assignment of hosts and links

    Network architectures

    Solutions for service discovery.  These should be handled by
    traditional service discovery mechanisms

---

From: Alexandru Petrescu<[email-masked]>
Date: 02 Nov 2002 15:25:13 +0100

Thierry Ernst <[email-masked]> writes:
> It seems that we have a couple of new/updated drafts to discuss the
> requirements, but I haven't seen an announcement from all the authors,
> so I'm not sure about what is on the table.
> 
> So far, I have seen:
>       draft-ernst-nemo-requirements-00.txt 
>       draft-ng-nemo-aaa-use-00.txt 
>       draft-janneteau-nemo-requirements-00.txt 
>       draft-sarikaya-nemo-archreqs-00.txt 

I've been compiling recently the following drafts:

  draft-ernst-nemo-requirements-00.txt:
  draft-janneteau-nemo-requirements-00.txt:
  draft-kniveton-monet-requirements-00.txt:
  draft-soliman-monet-statement-00.txt:
  draft-sarikaya-nemo-archreqs-00.txt:
  draft-ng-nemo-aaa-use-00.txt:

Here's the copy paste list I've been working with.

draft-ernst-nemo-requirements-00.txt:

 3. High Level Requirements

   This section details a number of high level requirements that should
   be met by the solutions.

  3.1. Migration Transparency

      In order to provide migration transparency, a permanent and
      continuous Internet connectivity must be provided to all MNNs,
      without disruption of service. MNNs must always be reachable
      regardless of the point of attachment of the MR, and sessions must
      be maintained after the MR has changed its point of attachment.

  3.2. Operational Transparency

      In order to be transparent to the applications and the users, NEMO
      support must be performed at the network layer.

  3.3. Performance Transparency (Seamless Mobility)

      NEMO support SHOULD exhibit low latency, incur little or no data
      loss, minimum delays, minimum signaling load, and minimum
      bandwidth consumption for packet delivery. It should be performed
      as seamlessly as host mobility is supported (no abrupt degradation
      of service).

  3.4. Layers Independence

      Handover of IP sessions is performed at the network layer. With
      respect to the layer separation of the Internet protocol suite,
      handover MUST be managed at the network layer only and
      transparently to upper layers, despite the migration of the mobile
      network in the network topology. Therefore, a change of
      topological location MUST not have an impact on layers above the
      network layer other than a transient loss of performance, as
      depicted in the above paragraph. If this is respected,
      compatibility with existing transport and application layers is
      maintained. In practice, the identifiers used at the transport
      layer should be independent from the physical IP addresses used at
      the network layer for routing. If upper layer protocols require a
      location independent and invariant identifier, the network layer
      MUST provide it with an identifier irrespective of the actual
      topological location.

  3.5. NEMO Support Transparency for MNNs

      In section "observation O1", we have seen that "MNNs don't change
      their own point of attachment as a result of the mobile network's
      displacement in the Internet topology. NEMO support SHOULD
      therefore be performed transparently to MNNs and keep them away
      from participating in NEMO support. Although MNNs may encounter
      variable delays of transmission and loss with their respective CNs
      as the network is moving. This is not considered a lack of
      transparency.  However, receiving movement information may be
      useful to hosts able to understand it, so this could be allowed as
      an option, and LMNs and VMNs, which are able to change their own
      point of attachment must manage their own mobility.

  3.7. Minimum Signaling Overload

      Mobility management is usually performed at the cost of control
      traffic. In order to be scalable, NEMO support MUST minimize this
      control traffic.

  3.12. No impact on CN or Internet routing

      Session continuity between a MNN and arbitrary CNs anywhere in the
      Internet SHOULD NOT assume any changes to existing CNs or the
      Internet routing architecture. On the other hand, optimizations
      for performance enhancement MAY involve some changes to CNs,
      provided that such optimizations would not cause any disruption to
      ongoing sessions, if not supported by CNs (i.e. backward
      compatible).  [THIS IS TO BE DISCUSSED (in light of the
      observation made in section "Minimum Impact on the Existing
      Protocols and Infrastructure" here above) BECAUSE IT WOULD PREVENT
      POTENTIALLY INTERESTING AND ORTHOGONAL SOLUTIONS TO BE PROPOSED].

  3.13. Security

      NEMO support must comply with usual IPv6 security policies and
      standardized protocols. In addition, and unlike fixed nodes, MNNs
      are more exposed to security threats, particularly identity
      usurpation. NEMO support must provide MNNs and their CNs with at
      least as good security as for fixed nodes and mobile hosts. It
      particularly shouldn't leave more room for intruders to usurp an
      identify nor to perpetrate any kind of attack against the MNNs nor
      the CNs. In practice, all control messages required by NEMO
      support must be exchanged in a secure manner and must ensure the
      following:

   3.13.1. Confidentiality

         All control messages transmitted in the network MUST  ensure
         MNNs' confidentiality. Only the recipient of the control
         message may be able to decrypt the content of the datagram.

   3.13.2. Authentication

         All control messages MUST be authenticated by recipients in
         order to prevent intruders to usurp the identity of a MNN.

   3.13.3. Authorization

         The recipient of a control message MUST ensure that the sender
         is effectively authorized to perform the mobility support
         operation indicated in the control message.

   3.13.4. Location Privacy

         NEMO support may provide means for MNNs to hide their location
         to any third party. It shouldn't be possible to determine the
         succession of topological location of a mobile network or a
         particular MNN by monitoring the exchange of control messages.
         In practice, MNNs may wish to hide their location to some or
         all of their CNs, or anyone else but the CNs. It may also be
         desirable to hide the location of the entire mobile network to
         all CNs without discrimination between MNNs.

  3.14. Access Control

   3.14.1. Access Control for VMNs

      Mobile Networks MUST be able to authenticate and authorize VMNs to
      gain access to the Internet via the mobile network infrastructure
      (MRs).

   3.14.2. Access Control Architecture

      To be able to comply with the current access control mechanisms
      and achieve a scalable solution, the final solution MUST NOT
      assume that the fixed network would authenticate VMNs. VMN
      authentication and authorization MUST be the responsibility of the
      mobile network.

   3.14.3. Access Control in the Fixed Network

      AAA solutions MUST allow for authenticating an entire network.
      This MAY simply be done by ensuring that the Authentication and
      Authorization is not necessarily performed for a single IP
      address. This is particularly important for IPv6 as each node may
      configure multiple addresses.

  3.15. Internet-wide mobility

      In order to ensure permanent and uninterrupted Internet-wide
      mobility, mobile network should be able to roam between access
      networks belonging to distinct ISPs and corporate networks
      (distinct administrative domains, i.e. inter-domain mobility) and
      via any available access technology (distinct technologies:802.11b
      WLAN, Bluetooth, satellite link, GSM, i.e. heterogeneous
      mobility). Indeed, nothing but administrative and security
      policies should prevent a mobile network to attach anywhere in the
      Internet topology. So, the solution must technically allow this
      kind of scenario. In addition, NEMO support must also accommodate
      to CNs deployed in distinct administrative domains.

  3.16. Unified Solution

      Should different schemes be proposed, a unified mobility support
      scheme is required. A situation where distinct NEMO support
      schemes are deployed and unable to inter-operate with each other
      must be avoided.

  3.17. Mobile CNs

      NEMO support MUST be optimized to handle the case where the CN is
      MIPv6-enabled and/or itself located in a mobile network
      (particularly if it is a VMN). It must perform efficiently in both
      cases.

 4. Requirements for Basic Support

   In this section, the high-level requirements are refined in a more
   explicit manner for basic support. This list is not exhaustive and
   should be combined with the requirements found in the other drafts.
   Requirements follow from our observations and high-level requirements
   in section 2 and 3.

   Basic support is to maintain session continuity between nodes in the
   mobile network and nodes in the global Internet. The solution will
   have to meet the following requirements [TO BE DISCUSSED ON THE LIST
   - THIS IS A PROPOSITION - AT THAT POINT DON'T TAKE THINGS FOR
   GRANTED]:

   R1: The solution MUST provide permanent Internet connectivity and
       reachability to all nodes behind the MR

   R2: The solution MUST maintain continuous sessions between nodes
       behind the MR and arbitrary CNs after IP handover of the MR

   R3: All the potential configurations MUST be treated the same way
       (any number of subnets and MNN, nested mobile networks,
   multihomed
       mobile networks)

   R4: The solution MUST support LFNs, VMNs, and LMNs.

   R5: CNs and MNNs must comply with the requirements for IPv6 nodes
       defined in [IPv6-NODE]

   R6: MNNs MUST NOT be NEMO-enabled (i.e. do not impose changes to
       MNNs)

   R7: CNs MUST not be NEMO-enabled (i.e. do not impose changes to CNs)

   R8: A VMN that gets attached to a link within the mobile network
       obtains an address on that link.

   R9: The solution MUST support nested mobile networks with any number
       of mobility levels

   R10: The solution MUST support multi-homed mobile network
        R10.1 : The solution MUST support mobile networks with multiple
        MRs

        R10.2:  The solution MUST support MR with multiple interfaces

   R11: The solution MUST NOT prevent the use of existing protocols

        R11.1: The solution MUST allow MNNs to operate the "CN
        functionality" of Mobile IPv6

        R11.2: The solution MUST support MIPv6-enabled VMNs and LMNs

        R11:3: The solution will ensure that mechanisms related to
        multi-homing
              (defined within other WGs in IETF) will be useful for
        NEMO"

   R12: The solution MUST support a large number of mobile networks

   R12: The solution MUST support a large number of CNs

   R13: The solution MUST support vertical handoff

   R14: The solution MUST support horizontal handoff

   R15: The solution SHOULD support fast handoff

   R16: The solution MUST support inter-domain mobility

   R17: The solution MUST support heterogeneous mobility

   R18: The solution MUST minimize control traffic

draft-janneteau-nemo-requirements-00.txt:

4. General Requirements for Network Mobility Support

   The following requirements define the scope of a network mobility
   solution in NEMO:

     - Permanent connectivity and unicast session continuity: The
       solution MUST allow all nodes in the mobile network to be
       reachable via their permanent IP addresses, as well as
       maintain ongoing sessions as the mobile router changes its
       point of attachement within the topology.

     - Implementation in the IP layer: The solution MUST be
       implemented at the IP layer level. It MUST be transparent to
       any upper layer so that any upper layer protocol can run
       unchanged on top of an IP layer extended with network mobility
       support.

     - Mobile networks of any size: The solution MUST support mobile
       networks of any size. The solution MUST be applicable to small
       networks (e.g. a PAN comprising a few devices attached to a
       single mobile router) and large networks (e.g. several
       subnetworks with a very large numbers of MNNs). It is worth
       mention that NEMO WG will consider only leaf networks, i.e.
       mobile networks (irrespective of their size) that will not
       carry transit traffic.

     - No change to the Internet addressing and routing architecture:
       The solution MUST NOT require changes to the Internet
       addressing nor routing architecture. It MUST be independent of
       any routing protocols and MUST preserve route aggregation in
       the Internet.

     - Home equivalent operations: The solution MUST ensure
       transparent continuition of routing and management operations
       for a mobile router away from home. Especially, a mobile router
       running a routing protocol MUST be able to pursue advertising
       of its routes on its home network. Similarly, management
       operations such as Router Renumbering MUST be possible for a
       roaming mobile router.

     - Nested mobility: The solution MUST support nested mobility. It
       MUST support mobiles nodes visiting and leaving mobile
       networks, as well as mobile networks attaching to other mobile
       networks (nested mobile networks). The solution MUST no
       restrict in any way the number of levels in the hierarchy of
       nested mobile networks.

     - Multihoming: The solution MUST function for multihomed mobile
       networks. Cases of multihomed mobile networks include ones
       with a single mobile router that has multiple attachements to
       the Internet, as well as ones with multiples mobile routers to
       attach to the Internet.

     - Security: The solution MUST have its specific security issues
       fully addressed.

     - Co-existence with others protocols:
       - The solution MUST allow for co-existence with the AAA and
         access control frameworks (e.g. PANA). If extra mobile
         network-specific concerns need to be addressed in these
         frameworks, the NEMO WG will interact with related WGs.
       - The solution MUST allow for co-existence with QoS protocols,
         as well as Mobile IPv4 and Mobile IPv6 protocols.

     - Multicast session continuity: The solution SHOULD maintain
       ongoing multicast sessions of MNNs as the mobile router
       changes its point of attachement within the topology. 

5. Additional Requirements for the Base Network Mobility Support

   The following requirements are placed on the base network mobility
   solution to be specified by the NEMO WG:

     - Base network mobility support for both IPv4 and IPv6: A
       solution MUST be provided for both IPv4 and IPv6
       environments. Each one MUST base on Mobile IPv4 and Mobile
       IPv6 respectivelly. As such two different solutions MAY be
       defined.

     - Based on bi-directional Tunneling between MR and MR's Home
       Agent (MRHA tunnel):
       - The base network mobility solution for IPv6 MUST rely on the
         Mobile IPv6 bi-directional tunnel between the mobile router
         and its Home Agent.
       - The base network mobility solution for IPv4 MUST rely on the
         Mobile IPv4 bi-directional tunnel between the mobile router
         and its Home Agent.

     - No changes to Correspondent Nodes: The base solution for
       network mobility MUST NOT require any modification to MNN's
       Correspondent Nodes.

     - Network Mobility transparency to MNNs: The base solution for
       network mobility MUST NOT require any modification to any
       node in the mobile network (MNNs) but the mobile router.
       Especially, the base solution MUST provide network mobility
       management without the need for nodes behind the mobile
       router to be aware of the network's mobility and take part
       in NEMO Mobility Management. Upon a move, the mobile router
       MUST ensure continuity of the sessions of MNNs transparently
       to them.

draft-kniveton-monet-requirements-00.txt:

   3. Goals and Problem Scope

   The primary goal of the MONET work should be to support a technical
   solution which allows mobile network nodes (MNNs), to remain
   connected to the Internet and continuously reachable at all times
   while the mobile network they are attached to changes point of
   attachment.  MNNs are both fixed (keeping the same address on the
   mobile network at all times), and mobile (entering and leaving the
   mobile network as they roam with respect to it).  Support for both
   fixed and mobile MNNs is within the scope of this work.

   Secondary goals of the work can be to investigate the effects of
   network mobility on various aspects of internet communication such as
   routing protocol changes, implications of realtime traffic and fast
   handovers, optimizations.  These should all support the primary goal
   of reachability for mobile network nodes.

   The MONET group is part of the IETF, and as such should be motivated
   by standardization work.  Although mobile networks bring up many
   interesting research questions, these are only within the scope
   of this group insofar as they lead directly toward implementable
   solutions.  Any further research topics should be offered to the IRTF
   Micromobility Design Team for additional review.

   Security is an important consideration, and efforts should be
   made to use existing solutions if they are appropriate.  Although
   a well-designed solution may include security inherent in other
   protocols, mobile networks also introduce new challenges, such as
   securing route update information when a network changes points of
   attachment.  These can be considered, as long as they do not conflict
   with the prior paragraph about research.

   4. Non-goals and Excluded Scope

   The following goals are excluded:

    -  host mobility.  This is the problem domain of Mobile IP.

    -  administration of the network

    -  address assignment of hosts and links

    -  network architectures

    -  solutions for service discovery.  These should be handled by
       traditional service discovery mechanisms

   5. Protocols

   Internet Protocol

   The mobile networks we discuss are communicating using the Internet
   Protocol.  Due to the advantages for mobility of IP version 6, it is
   desirable to spend most effort initially on an IPv6-based solution.
   However, it is also important to investigate how mobile networks can
   be enabled under IPv4 [8] conditions.

   To address this issue, it is desirable to either create a solution
   that could be utilized by both IPv6 and IPv4 with minimal (or no)
   changes, or subsequently undertake steps to adapt the solution to
   IPv4 or if that is not possible, create a new IPv4-based solution.

   Mobile IP

   The efforts of the Mobile IP working group have resulted in the
   Mobile IPv4 [7] and Mobile IPv6 [6] protocols, which have already
   solved the issue of host mobility.  Since challenges to enabling
   mobile networks are vastly reduced by this work, it is proposed that
   the work in this group will adopt the methods for host mobility used
   in Mobile IP, and extend them in the simplest way possible to achieve
   its goals.

   MONET should be able to co-exist and not interfere with other
   mobility management protocols, such as Mobile IPv4, Mobile IPv6, Fast
   Handovers for Mobile IPv6 [3] and Mobile IPv4.

   Addressing and Configuration

   This topic is central to communication within a mobile network, so
   the changes to addressing models are a top concern for work within
   this group.

   Multicast

   There is some interest in discussing implications to multicast within
   the Monet scope.

   Service Discovery

   It may hold true that service discovery protocols need some
   modification in this type of environment, but at this point it is
   generally believed that existing solutions may be able to run on top
   of a mobile network without change.

   6. Network Architecture

   Nesting

   It should be possible to create topologies within a mobile network
   of smaller subnetworks, and possibly attach other mobile networks
   in that topology.  Although it is not fully clear how many layers
   of topology must be supported, or the complexity requirements of
   those nested networks, the goal is to support arbitrary levels of
   recursive networks, and only in the case where this is impractical
   and protocol concerns preclude this support should the solution
   impose restrictions on nesting.

   Transit Networks

   For the purposes of this work, we make a distinction between Transit
   Networks and Stub Networks.  A transit network is one in which data
   would be forwarded between two endpoints outside of the network, so
   that the network itself simply serves as a transitional conduit for
   packet forwarding.  A stub network, on the other hand, does not serve
   as a data forwarding path.  Data on a stub network is destined for an
   endpoint located on that network.

   In order to keep minimal complexity, transit networks are outside
   of the scope of this group.  Effort will be applied to solving
   communication for MNNs within a stub network only.

   Multi-homing

   Mobile network nodes can have multiple IP interfaces, therefore be
   multi-homed.  On each interface they can have a different role within
   the scope of MONET. A multi-homed node might have a fixed interface
   which is always attached to the same network, and a mobile interface
   which changes its point of attachment.  Such a node would be a
   fixed host on the former interface, and a mobile host on the latter
   interface.  MONET protocol must be able to handle such multi-homing
   (multi-role) cases.

   Route Optimization

   Using overlay networks by using Mobile IP and MONET can create
   sub-optimal routing among communicating entities.  Protocols can
   have route optimizations to remedy this problem by enabling entities
   to communicate their locations to each other for the shortest path.
   Such methods are defined for Mobile IPv4 and Mobile IPv6.  Route
   optimization is an aspect of efficient communication that should be
   taken into consideration within MONET.

   Protocol End-points

   A MONET protocol should be used at least by home agents and mobile
   routers.  This is the minimum set of entities that need to implement
   this protocol to enable mobile networks.

   MONET should be transparent to fixed routers and fixed hosts,
   therefore no implementation on these entities is needed.

   For optional route optimizations, mobile hosts and correspondent
   nodes can implement protocol extensions to utilize shortest paths in
   their communications.

   7. Security Considerations

   The protocol signaling must be secured.  The receiver of the
   protocol signaling must be able to verify the authenticity and the
   authorization of the sender to change routing information for the
   host(s)/network indicated.  Unauthenticated and unauthorized nodes'
   request to change routing should not be permitted by the network.

   This is a very similar to the security requirement of Mobile IP.
   The difference is that when this requirement is not satisfied, the
   consequences would only effect a single mobile node in the case
   of Mobile IP, whereas a whole subnet, of possibly unlimited size,
   would be affected in the case of MONET. As such, stronger security
   mechanisms should be required by MONET.

draft-soliman-monet-statement-00.txt:
 
3.1 Addressing 
 
   The addressing mechanism required for MONETs needs to be carefully 
   considered as it will affect some of the solutions for other issues 
   associated with MONETs. For instance, allowing every MNN to acquire a 
   topologically correct address would imply that the MNNs are aware of 
   their movement within the topology, hence affecting the mechanism 
   chosen for mobility management.  
   Several possibilities exist for address configuration for MRs and the 
   MNNs attached to it: 
    
   - Stateful address autoconfiguration [DHCPv6] 
   - Stateless address autoconfiguration [Multi-link subnets] and  
     [Automatic prefix delegation]  
   - IPv6 Router Renumbering 
    
   The first 2 mechanisms can be used to configure the MRs ONLY or the 
   entire subnet with topologically correct addresses. Such choice will 
   affect the mobility management solution. For instance changing an 
   MNNs address would require updating the CN and the HA. 
    
   The choice of the addressing mechanism will need to be made based on 
   the following factors: 
    
   - Scalability:  
     Can the chosen mechanism support a large number of MINTs ? This may   
     depend on the size of the �fixed� network to which a MINT is   
     attached.  
    
   - Speed:  
     How much time is required for address autoconfiguration to be  
     completed ? Is it quick enough to support fast mobility ? 
    
   - Mobility Frequency 
    
   - Nested Mobility  
    
   - Impacts on the Mobility management model:  
     Does the chosen mechanism support the requirements for a scalable  
     and secure mobility management solution ? 
    
   - Multihoming:  
     Each MR may be connected to multiple ISPs, each potentially 
     providing different paths to the Internet. In addition, there may  
     be multiple MRs in the MINT. 
    
   - MINT definition: 
     How are nodes in the MINT defined to belong to the MINT? In case of 
     a wired MINT, it is physically defined. But a wireless MINT can  
     begin to interfere with other geographically close wireless nodes,  
     thus losing the definition of the MINT. A secure layer 2 is not 
     assumed in this document, however, a secure layer 2 would certainly  
     simplify this problem. 
 
3.2 Mobility management 
    
   This document assumes a MIP-based mobility management solution for 
   MONETs.  
   The current MIPv6 proposals provide limited levels of support for 
   MONETs. Some solutions for the mobility scenarios are proposed in 
   [HMIPv6] and [MONET]. However, some further investigation is needed 
   to see whether these solutions are sufficient for the different MONET 
   scenarios.  
   Specifically, issues related to route optimisation need to be 
   investigated further. [HMIPv6], [MOBRTR] and [MONET] provide 
   different approaches for mobility management. In [HMIPv6] MNNs 
   connected to MRs are aware of the MRs mobility, hence route 
   optimisation is performed by the MNNs. On the other hand, [MONET] 
   provides an extension to MIPv6 to allow MRs to send a prefix scoped 
   BU to re-direct traffic for the entire prefix on behalf of the MNNs. 
   [MOBRTR] assumes a bi-directional tunnel between the mobile router 
   and the HA, over which routing protocols are tunnelled. 
    
   In [HMIPv6], MNNs are aware of their mobility, while [MONET] and 
   [MOBRTR] hide the network�s mobility from the MNNs. 
    
   The choice of the Mobility management mechanism will depend on the 
   following factors: 
    
   - The size of the network vs BW efficiency and speed of mobility:  
     Hiding the network�s mobility from the MNNs can reduce MIP  
     signalling (e.g. one BU from the MR to the HA instead of many).  
     What tradeoffs are needed to decide whether route optimisation   
    (additional signalling) should be used? How does the size of the  
     network in a wireless environment affect this decision? 
     How do we treat a large network on a fast train (frequent handovers  
     for many MNNs) compared to a MINT (eg. a PAN)? 
    
   - Security and authorisation issues: 
     BUs from MRs to CNs can cause some serious security threats for  
     unauthorised MRs. Currently there is no specified solution for this  
     problem. 
    
   - Routing Protocol Issues: 
 
     Shall MR of a MINT run a routing protocol ? What is the impact on 
     the routing protocol running in the visited network ? 
      
     Which protocol shall we run within large MONETs, how it interact 
     with routing protocols running in visited network 
    
3.4 Access control and security 
 
   This chapter discusses the issues associated with access control 
   within the Mobile Network. In this context, the spectrum of access 
   control covers the MR � AR (fixed default router), MN � MR, and MN � 
   MN relationships. Issues related to securing Neighbour Discovery may 
   also be related.  
    
3.4.1 Access control between AR and MR 
 
   The access network at the ISP/operator must allow the connection of 
   not only a single device but also a network behind that device. The  
   access network can perform ingress filtering, access control lists 
   etc. 
 
3.4.2 Access control between MR and VMNs in a large MONET 
 
   In the case of a large MONET providing Internet access for visiting 
   nodes (VMNs) such as the train or ship case, this access will 
   probably be controlled. 
   This problem is very similar to what UNAP is attempting to solve. 

3.4.3 Access control between nodes in a MINT 
 
   Nodes in the MINT must trust each other. At least, MR must know who 
   are the nodes that uses it as access router to the Internet. This is 
   a question of who will pay for the packets. 

draft-sarikaya-nemo-archreqs-00.txt:
    
2.1 Generic architecture 
   A new architectural entity called mobile router (MR) is needed to 
   support network mobility. The mobile router (MR) connects the mobile 
   network to the home link. In order to provide session continuity to 
   the nodes in its network, MR needs a Mobile IP Home Agent (HA) [4]. 
   MR may have several internal links to which local fixed (LFN) and 
   mobile (LMN) nodes are connected (Figure 1). MR and HA together 
   provide support for network mobility. HA MUST know that MR is not a 
   basic mobile node but a router. 
 
                      +----+           
                      |    |           
                      | CN |           
                      |    |           
                      +----+           
                        |                 
                    +------------------------+ 
                    |                        | 
                    |                        | 
                    |       Internet         | 
                    |                        | 
                    |                        | 
                    +------------------------+ 
                         |               | 
                      +----+          +----+       +----+ 
                      |    |  Access  |    |       |    | 
                      | AR |  Router  | AR |       | HA | 
                      |    |          |    |       |    | 
                      +----+          +----+       +----+ 
                foreign | link          | home link  | 
                   -------------     ------------------------- 
                         |                        | 
                      +----+                    +----+ 
                      | MN |                 |  | MR | Mobile Router 
                      +----+                 |--|    | 
                                             |  +----+ 
                                             |     |  internal link 1 
                                             |   -------------------- 
                                             |     |         | 
                                             +  +-----+   +-----+  
                                             |  |     |   |     | 
                                    +-----+  |  |     |   |     | 
                                    |     |  |  | LFN |   | LMN | 
                                    | LFN |--|  |     |   |     | 
                                    |     |  |  +-----+   +-----+ 
                                    +-----+  | 
                                             | internal link 2 
   Figure 1. A Mobile Network at its Home Link 
    
   MR has an egress interface to its home link. MR MAY have several 
   ingress interfaces to its internal links.  
    
   The mobile network MAY move in its entirety and MAY attach itself to 
   another link, e.g. foreign link. This situation is shown in Figure 2. 
   MR MUST provide session continuity to all the nodes in its network. 

   The correspondent node (CN) MAY be communicating with a mobile node 
   (LMN) or with a fixed node (LFN). Base network mobility support MUST 
   not require any changes to the correspondent nodes. 
    
                      +----+          
                      |    |          
                      | CN |          
                      |    |          
                      +----+          
                        |                
                    +------------------------+ 
                    |                        | 
                    |                        | 
                    |       Internet         | 
                    |                        | 
                    |                        | 
                    +------------------------+ 
                         |               | 
                      +----+          +----+    +----+ 
                      |    |  Access  |    |    | HA | 
                      | AR |  Router  | AR |    |    | 
                      |    |          |    |    |    | 
                      +----+          +----+    +----+ 
                foreign | link          |home link | 
             ---------------        ------------------------- 
              |           | 
           +----+       +----+ 
           | MN |    |  | MR | Mobile Router 
           +----+    |--|    | 
                     |  +----+ 
                     |     |  internal link 1 
                     |   -------------------- 
                     |     |         | 
                     +  +-----+   +-----+  
                     |  |     |   |     | 
            +-----+  |  |     |   |     | 
            |     |  |  | LFN |   | LMN | 
            | LFN |--|  |     |   |     | 
            |     |  |  +-----+   +-----+ 
            +-----+  | 
                     | internal link 2 
    
   Figure 2. Mobile Network at a Foreign Link 
    
   A mobile router becomes the visiting mobile router (VMR) if it 
   connects to another network in mobility. This is called nested 
   mobility. An architecture for nested mobility is shown in Figure 3. A 
   visiting mobile router (VMR) connects itself to the network in 
   mobility by attaching to one of the links, e.g. local link 2. The 
   visiting network in mobility may have its own links to which several 
   fixed and mobile nodes are connected. HA1 is the home agent for MR 
   and HA2 is for VMR. 
    
                      +----+          
                      |    |          
                      | CN |          
                      |    |          
                      +----+          
                        |               
         +----+     +------------------------+ 
         | HA |     |                        | 
         |   2|     |                        | 
         +----+     |       Internet         | 
            |       |                        | 
             ------>|                        | 
                    +------------------------+ 
                        |               | 
                      +----+          +----+      +----+ 
                      |    |  Access  |    |      |    | 
                      | AR |  Router  | AR |      | HA | 
                      |    |          |    |      |   1| 
                      +----+          +----+      +----+ 
                foreign | link          |home link  | 
                   -------------     ------------------------- 
                         |                        | 
                      +----+                    +----+ 
                      | MN |                 |  | MR | Mobile Router 
                      +----+                 |--|    | 
                            +---+            |  +----+ 
                            |LFN|    |       |     |  internal link 1 
                            |   |----| +---+ |   -------------------- 
                            +---+    |-|VMR|-|     |         | 
                                     | +---+ +  +-----+   +-----+ 
                                             |  |     |   |     | 
                                    +-----+  |  |     |   |     | 
                                    |     |  |  | LFN |   | LMN | 
                                    | LFN |--|  |     |   |     | 
                                    |     |  |  +-----+   +-----+ 
                                    +-----+  | 
                                             | internal link 2 
    
   Figure 3. Nested Mobility 
    
2.2 Mobile IPv4 Considerations 
    
   In Mobile IPv4, LMNs as well as MR MAY have a Foreign Agent (FA). The 
   FA for LMNs MUST be on the internal link(s). MR MAY act as a FA to 
   LMNs only if one of MR�s interfaces directly connect to the internal 
   links in the mobile network. Figure 4 shows the use of Mobile IPv4 
   when the network in mobility is on a foreign link. MR uses a local FA 
   as its foreign agent while serving as FA to LMNs on the links 
   attached to its interfaces. 
    
                      +----+          
                      |    |          
                      | CN |          
                      |    |          
                      +----+          
                        |                
                    +------------------------+ 
                    |                        | 
                    |                        | 
                    |       Internet         | 
                    |                        | 
                    |                        | 
                    +------------------------+ 
                         |               | 
          +----+      +----+          +----+       +----+ 
          |    |      |    |  Access  |    |       |    | 
          | FA |      | AR |  Router  | AR |       | HA | 
          |  mr|      |    |          |    |       |    | 
          +----+      +----+          +----+       +----+ 
             |  foreign | link          |home link   | 
             ---------------        ------------------------- 
              |           | 
           +----+       +----+ 
           | MN |    |  | MR | Mobile Router 
           +----+    |--|(FA)| 
                     |  +----+ 
                     |     |internal link 1 
                     |   -------------------- 
                     |     |         | 
                     +  +-----+   +-----+  
                     |  |     |   |     | 
            +-----+  |  |     |   |     | 
            |     |  |  | LFN |   | LMN | 
            | LFN |--|  |     |   |     | 
            |     |  |  +-----+   +-----+ 
            +-----+  | 
                     | internal link 2 
   Figure 4. Network mobility and Mobile IPv4 

draft-ng-nemo-aaa-use-00.txt:
    
4.  AAA Requirements 
    
   From the usage scenario, we can identify the set of requirements 
   described below.  It must be noted that the requirements specified 
   are by no means exhaustive.  Since a NEMO solution has yet to be 
   specified, these requirements are merely spelt out to generate 
   further discussion within the NEMO working group.  When a NEMO 
   solution is eventually specified, AAA requirements by NEMO can be 
   rapidly generated by building on top of this document. 

Ng, Tanaka               Expires - April 2003                [Page 14] 
Internet-Draft      Usage Scenario for AAA in NEMO        October 2002 

     (1)The AAA servers MUST be able to share, or dynamically establish 
        security associations with external authorities that are able 
        to verify the credentials provided by the client. 
      
        This requirement is a direct induction from the need for AAA 
        servers of ARs/MRs to consult home AAA servers of mobile 
        network nodes for verifications of client's credentials.  Since 
        these AAA servers usually belong to different administrative 
        domains, it is necessary for AAA operations to provide a 
        mechanism for AAA servers in two different domains to establish 
        a security relationship between each other. 
      
     (2)The VMN or MR MUST be able to provide complete, unforgeable 
        credentials without having to contact its home agent. 
      
        Since VMN or the MR would initiate network connectivity from a 
        foreign domain, it is necessary for it to be able to provide 
        credentials without having first granted access to NEMO 
        resources.  Thus it has to be able to provide credentials 
        sufficient for verifications without the ability to contact any 
        other nodes in its home domain. 
    
     (3)Intermediate nodes MUST not be able to learn any information 
        which may enable them to reconstruct and reuse the credentials. 
    
        This requirement protects the AAA servers from replay attacks.  
        It is necessary for the ARs/MRs to be able to process the 
        credentials provided by the MRs/VMNs and yet unable to 
        reconstruct the credentials independently at a later time, so 
        that malicious AR/MR cannot use the credentials to launch a 
        replay attack against the home AAA server.  It also serves to 
        protect the MRs/VMNs from the visited NEMO. 
      
   In addition, to the above requirements, the following security 
   requirements need to be considered. 
    
     (4)AAA request and response operations between the ARs/MRs and the 
        respective AAA servers MUST prevent eavesdropping. 
    
        Any AAA operations MUST prevent the confidential information 
        passed between the AR/MR and the corresponding AAA server from 
        being known by eavesdroppers in the network.  This is 
        especially needed since NEMO typically operates in a wireless 
        environment. 
      
     (5)AAA request and response operations between the ARs/MRs and the 
        respective AAA servers MUST NOT be vulnerable to denial-of-
        service attack. 

Ng, Tanaka               Expires - April 2003                [Page 15] 
Internet-Draft      Usage Scenario for AAA in NEMO        October 2002 

        Since AAA operations typically entail cryptographic 
        computations in the nodes involved, it is necessary to consider 
        denial of service attacks by consuming CPU and memory resources 
        to process illegitimate AAA requests, thereby preventing 
        authentication of a legitimate mobile network node. 
      
     (6)AAA request and response operations between the ARs/MRs and the 
        respective AAA servers MUST NOT be vulnerable to man-in-the-
        middle attack. 
    
        Since AAA operations may involve more than two nodes and 
        operate over multiple hops, it MUST prevent communications 
        between two legitimate nodes from being spoofed by an attacker 
        in the middle. 
      
   The following are the set of requirements for NEMO in considerations 
   to AAA operations. 
    
     (7)MR that supports attachment of VMN on its internal link SHOULD 
        implement AAA client capability to be able to contact MR's home 
        AAA server to check on credentials provided by the visiting 
        nodes. 
      
        It is generally not expected for MR to implement a full AAA 
        server for scalability reasons.  However, MR should be 
        configured to consult an AAA server (possibly an AAA server 
        from the MR's home domain) for verifications of credentials 
        from the VMN. 
 
     (8)MR that support attachment of VMN on its internal links SHOULD 
        NOT change its AAA policy for the said VMNs during a continuous 
        session, even when the MR has undergone a handover between AR 
        of different administrative domains. 
      
        It is expected for handover of MR should be transparent to VMNs 
        behind the MR. Thus, a change in administrative domain of the 
        AR should not be propagated to nodes behind the MR.

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 04 Nov 2002 08:39:28 -0600

Hello Alex,
  Thanks for compiling the list.
All others except

state requirements for the base nemo solution, however this one does 
not, IMHO. draft-ng-nemo-aaa-use does not either state security 
requirements, it probably deserves to be treated separately on its own, 
much like the case in Mobile IP.

Regards,

>  draft-ng-nemo-aaa-use-00.txt:

--behcet

---

From: "T.J. Kniveton" <[email-masked]>
Date: Mon, 04 Nov 2002 23:21:52 -0800

> draft-ng-nemo-aaa-use-00.txt:

I didn't see any items from the last two drafts on your list. Were they left
off?

> [...]

This list serves as a good union of all the ideas of the different drafts.
Now, we would like to do a bit more detailed analysis. That is to say, what
are the parts of this list that are in common with all, or many drafts, and
what are the parts that only come from one source? In this way, we can
narrow down the points of discussion to only the items which may be
controversial or not widespread. This is a long task, but we can start with
the core of requirements (as you have pretty much done here) that are
commonly understood, and then explore the edges to see what are the more
active discussion points regarding edge subjects in basic support (we have
already had some earlier, on the list).

By the time we are at the IETF in a couple of weeks, we can hopefully
whittle down the topics of conversation to a big list of agreed points, and
some salient points for fine adjustment.

TJ

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 05 Nov 2002 11:28:07 -0600

TJ,

>some salient points for fine adjustment.
Agreed. But the point is that

>draft-ng-nemo-aaa-use-00.txt
is on the AAA aspect not on the solution to the base mobility which is 
expected to be an IP layer solution. I do not think that these two can 
be stated in a single draft. That's why I suggested separating the AAA 
use draft from the others.

Regards,

-- 
Behcet

---

From: Takeshi TANAKA <[email-masked]>
Date: Thu, 07 Nov 2002 09:55:13 +0900

Hi,

We would like to explain about "draft-ng-nemo-aaa-use-00.txt".
Sorry for doing so late.

Since NEMO is largely applicable to commercial use, we think we should
consider about AAA operation from beginning of considering about NEMO 
solutions.

This draft described/categolized NEMO usage scenarios from commercial 
point of view, and listed requirements for AAA functionalities in NEMO.
I.e. this draft describes about requirements for AAA aspect of NEMO, 
so that routing aspect of NEMO does not preclude requirements for AAA side.

Regards,
Takeshi

At 02 Nov 2002 15:25:13 +0100

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 07 Nov 2002 17:52:27 -0600

Hello Takeshi,
  Your draft reads nicely, and it is useful. I think the most important 
message in it is that MR must have an AAA client. Maybe there are 
prospects for more future work in this domain possibly to be pursued in 
AAA WG.
  However as you said the draft does not address any requirements on the 
base NEMO solution.
  My 2 cents.

-- 
Behcet

---

From: Thierry Ernst <[email-masked]>
Date: Wed, 13 Nov 2002 17:14:49 +0900 (JST)

Hi Behcet, all

Sorry, I don't catch what you recommend in your past emails on this
thread (which I have appended in this mail).

I don't think that the AAA draft should be considered separately (at
least not for the reason you state). It states high level
requirements, so do most of the other drafts.

May be at the meeting we can split the requirement discussion into 2
slots:

- 1st to discuss high level requirements (included the AAA and all
  other requirements)

- 2nd to itemize the requirements in the "versets" fashion as proposed
  by Pascal. (which I tried to do in the new section of my own draft,
  but partly only)

Thierry

From: Behcet Sarikaya <[email-masked]>

---

From: ChanWah Ng <[email-masked]>
Date: Wed, 13 Nov 2002 04:15:34 -0800 (PST)

Hi all,

let me just try to clarify things a bit.  The AAA draft was started because we see that
AAA is the important factor in comercial consideration.  We started the draft to explore
any AAA issues that are particular about NEMO.  And indeed we found some.

8 requirements are stated in the draft. Some are geared towards requirements on a AAA
solution, some are requirements on NEMO nodes.  Since they are high-level requirements, I
believe some "basic-nemo-specific" requiremnts can be drawn from them.  The appropriate
approach, IMHO, is to take a look at each high-level requirement and draw specifc
requirements from there.  I think Alex's list is a good summary.

Having said that, I agree that AAA and mobility support should be separate.  Forgive me
if I've mistaken, but I would imagine the AAA/EAP/PANA WG will expect the NEMO WG to come
up with a document on requirements on AAA solution for NEMO.

/rgds
/cwng

> >much like the case in Mobile IP.

__________________________________________________
Do you Yahoo!?
U2 on LAUNCH - Exclusive greatest hits videos
http://launch.yahoo.com/u2

---

From: Takeshi TANAKA <[email-masked]>
Date: Wed, 13 Nov 2002 21:31:46 +0900

Hi, Thierry and all,

Following are comments for draft-ernst-nemo-requirements-00.txt.

R5: CNs and MNNs must comply with the requirements for IPv6 nodes
    defined in [IPv6-NODE]
=>All IPv6 nodes comply with IPv6 node requirements, it is not requirements
  for NEMO.

R6: MNNs MUST NOT be NEMO-enabled (i.e. do not impose changes to
    MNNs)
=>"The solution must support nodes that are not NEMO-enabled" or
  "The solution must not impact on MNNs" is better since MNN may 
  be also MR...as someone said.

R7: CNs MUST not be NEMO-enabled (i.e. do not impose changes to CNs)
=>"The solution must not impact on CNs" is better since CN may be also MR.

R8: A VMN that gets attached to a link within the mobile network
    obtains an address on that link.
=>Which requirements does this imply?

R10: The solution MUST support multi-homed mobile network
     R10.1 : The solution MUST support mobile networks with multiple
     MRs
     R10.2:  The solution MUST support MR with multiple interfaces
=>"The solution must support MR with multiple global addresses on egress 
  interface" should also be added.

=> duplicated number.

R13: The solution MUST support vertical handoff
R14: The solution MUST support horizontal handoff
=> What do "vertical handoff" and "horizonal handoff" mean?

R17: The solution MUST support heterogeneous mobility
=> What does "heterogeneous mobility" mean?

------------
Takeshi

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 13 Nov 2002 09:11:13 -0600

Hi ChanWah,

>up with a document on requirements on AAA solution for NEMO.
Absolutely. If you consider Mobile IP WG example, requirements on the 
AAA solution was done in MIP WG and the solution  in AAA WG.
I think this is the issue: requirements on the AAA solution for NEMO 
should be a separate document or it should be considered part of the 
requirements for NEMO solution.
I argued for the former. However if we combine them we are going to be 
following the charter more closely, this could be an advantage for the 
latter approach.
What do people think?

-- 
Behcet

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 14 Nov 2002 16:13:07 +0900 (JST)

Dear all,

Thanks Takeshi for the comments. Seems the feedback is only
"clarification", no "disagreement", which is good at this stage.

BTW, Is there a way to state the requirements of your own draft in a
similar fashion ?

> =>All IPv6 nodes comply with IPv6 node requirements, it is not requirements

I agree, but may be sometimes it worth to say it again ?

>   be also MR...as someone said.

Agree for the note about the MR. The word "impact" does not sound
good, so your first statement sounds better, but I would like to add
"MNNs":

"The solution must support MNNs that are not NEMO-enabled"

Said like this, no pb with MR.

> =>"The solution must not impact on CNs" is better since CN may be also MR.

Same as above. "impact" must be defined, but the term NEMO-enabled is
defined for this purpose, so ...

"CNs MUST NOT be assumed to be NEMO-enabled" Is that better ?

or "The solution MUST work with non NEMO-enabled CNs" ?

> =>Which requirements does this imply?

Right, not a requirement, but part of the definition for a VMN.
 
>   interface" should also be added.

What's the difference with R10.2 ? 

> => What do "vertical handoff" and "horizonal handoff" mean?

One is handoffs between two APs, while the other is handoff between
two egress interfaces. In the next revision of the terminology, I
should point to draft-ietf-seamoby-mobility-terminology-00.txt for the
definitions.  There was also a proposition to merge NEMO and Seamoby
terminology, we need to examine this.
 
> => What does "heterogeneous mobility" mean?

Will be updated. I meant "inter-domain mobility" (defined as
"macro-mobility in draft-ietf-seamoby-mobility-terminology-00.txt).

Cheers,
Thierry

---

From: ChanWah Ng <[email-masked]>
Date: Thu, 14 Nov 2002 00:48:05 -0800 (PST)

> following the charter more closely, this could be an advantage for the 

Perhaps it is the fault on our part that draft-ng-nemo-aaa-use-00.txt 
specify both (1) AAA requirements on NEMO solution and 
(2) NEMO requirements on AAA solutions.  

I will attempt to classify them into the two different catergories.

>    to verify the credentials provided by the client. 

This is definitely a requirement for AAA solution.

>    credentials without having to contact its home agent. 

This is a bit more complicated.  I will think it contains both types.  
It may place requirements on both NEMO and AAA solution.

>    which may enable them to reconstruct and reuse the credentials. 

Same here.  We can draw at least the requirement for NEMO: eg. MR/AR 
must not be able to snoop into packet sent by MNNs to the HA of MNNs.
It also place requirements for AAA solution in that it requires the 
AAA solution to provide a mechanism to securely transfer the 
credentials.

>    respective AAA servers MUST prevent eavesdropping. 

This is requirement for AAA solution.

>    respective AAA servers MUST NOT be vulnerable to denial-of-

This is requirement for AAA solution.

>    respective AAA servers MUST NOT be vulnerable to man-in-the-

This is requirement for AAA solution.

>    AAA server to check on credentials provided by the visiting 

This will be requirement for NEMO solution/implementation.  For 
example, (just an example!) when designing the mechansim to set-up 
bi-directional tunnel, a way to piggyback secure credentials should 
be considered.

>    of different administrative domains. 

This is a policy requirement, very difficult to classify into AAA or 
NEMO solution.  If I must do it, I will say this will be more of a 
requirments for AAA solution.  But it does place requirements (or 
perhaps non-goals?) on NEMO solution/implementation as well.

/rgds
/cwng

__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - Let the expert host your site
http://webhosting.yahoo.com

---

From: Takeshi TANAKA <[email-masked]>
Date: Thu, 14 Nov 2002 17:59:51 +0900

At Thu, 14 Nov 2002 16:13:07 +0900 (JST) 

> or "The solution MUST work with non NEMO-enabled CNs" ?
I think the former is better.
Or "The solution must not assume CN to be NEMO-enabled".

> What's the difference with R10.2 ? 
I meant "The solution must support MR with multple global addresses on
single egress interface".
Suppse a single link that MR has attached to has multiple global link 
prefixes.

Regards,
Takeshi

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 14 Nov 2002 20:28:22 +0900 (JST)

From: ChanWah Ng <[email-masked]>
> (2) NEMO requirements on AAA solutions.  

I would prefer to see a discussion on this ML about the requirements
themselves rather than whether they should be expressed in a separate
document or not...

I don't see any trouble with your draft mixing the 2, since the
conclusions are based on some usage scenario. It's good to have this
on the table, so that we can discuss the issues and establish
cross-communication with relevant IETF WGs.

So, may be that should be put more in light so that next Wednesday we
make an effective use of our time. If well explained, AAA people in
the room (if any) can understand what are the NEMO issues with respect
to AAA and what we are expecting from them.

Thierry.