Subject: [netlmm] review of draft-giaretta, version -01

From: Jari Arkko <[email-masked]>
Date: Mon, 25 Sep 2006 17:28:43 +0300

This is an early review of the design team's spec.
Overall, the spec is well written and easy to read,
and I'm mostly happy with the protocol design.

My main concerns at this time are related to how
this is integrated to the mobile node - access
router interface, and whether all the pieces fit
together when the entire system is considered.
There are also a number of other issues that
still need work.

Detailed comments below:

Technical issues:
============
>    If the MAG
>    obtains the NetLMM subnet prefix for the MN first, the MAG transfers
>    this prefix to the LMA via the Location Registration message.  On the
>    other hand, if the LMA obtains the NetLMM subnet prefix for the MN,
>    the LMA transfers the prefix to the MAG via the Location Registration
>    Ack.
I did not understand this. Why would the MAG obtain a
prefix by itself?

>    When a mobile node then leaves the NetLMM infrastructure, the MAG
>    sends a Location Deregistration message to the LMA including the
>    Mobile Node's ID and the MAG's ID.  The LMA cleans up all state for
>    the mobile node identified in the message and sends an
>    acknowledgement.
>
>    ...
>
>    When a mobile node moves from one MAG to another MAG (see Figure 3),
>    the new MAG (nMAG) sends a Location Registration message to the LMA
>    with the MAG ID and the MN ID.  The LMA responds by sending an
>    acknowledgement to the nMAG that includes the MN ID, the MAG ID, the
>    LMA ID, and prefix information that the nMAG uses in the router
>    advertisement for the MN.
This seems wrong. We cannot generally assume too much about
the sequence of events involving mobile node movements and
layer 2 reg/dereg a the various MAGs. If the mobile node happens
to disconnect from layer 2 to pMAG and only then contacts the nMAG,
the entire context from the LMA has just disappeared.

Section 7.1.3.6 did not explain this any better either.

>    Any implementation of the NetLMM protocol MUST include support for
>    IPsec protected transport, using Encapsulating Security Payload
>    [RFC4303] in transport mode.  IPsec SHOULD be used unless other means
>    of protecting the NetLMM control signalling provide enough security
>    within the NETLMM domain.  If IPsec is used, it MUST use a non-NULL
>    authentication algorithm to provide data origin authentication.
This is a good start, but inadequate as such. If you employ
IPsec as the security mechanism, you also need to explain
everything that is listed in draft-bellovin-useipsec-05.txt,
Section 8. For instance, details about expected key
management operation.
> 5.2.  LMA Allocation Request
>       ...
>       Required options: Sender ID, LMA ID, MN ID
What's the Sender ID? I cannot find its definition
elsewhere in the document. If its the ID option,
which option sub type should be used?

>    ID-Type
>       This field indicates the type of ID carried in the remainder of
>       the option.
>       *** Note: Check whether there already exists an applicable IANA
>       registry for ID types which we could use here ***
>
>       0: 128-bit opaque cryptographically generated identifier (such as
>          proposed ORCHID IDs)
I understood that one solution that the WG will document
on the MN - MAG interface is based on SEND. Where would
such identifiers be placed in this option? Also, it may be
inappropriate to use the derived identity such as a HIT,
ORCHID or CGA address without the corresponding public
key -- but I'm not sure there is a problem until I've read
the other document.

In the same option, there's also a possibility to use
an IPv6 address as an identifier. I'm curious where
this would be used, and why.
>    This option defines the address or prefix which has been allocated or
>    delegated to a mobile node.  If the address prefix length is the same
>    as the full address length, it describes a single address, otherwise
>    it describes a prefix delegated to the MN.  The NetLMM address can be
>    both IPv4 and IPv6.
Prefixes intended to be advertised to the mobile node are quite
different from prefixes intended to be delegated to the mobile
node. I think we need to be clear what we mean here.

Also, in the same option, the language about the length of the
address needs to be clearer. Presumably it is exactly 4 or 16
bytes, depending on the value of the option subtype.
>    LMA and MAG nodes SHOULD support and MAY use message timestamps.  To
>    resolve race conditions, in particular during handover, and for
>    message synchronization beyond the scope of a particular MAG, the
>    timestamp option may be attached to the following messages:
I did not find any statement in the draft about dealing with
message synchronization within the scope of a particular MAG.
The obvious answer is that the next request may not be sent
before the previous one has not been acked. Is this so? If
yes, you need to state that. If not, we need something else.

Overall, I'm not entirely happy with the timestamp design
for preventing race conditions, but at this point I can't
recommend anything else either. In any case, if timestamps
are our scheme then perhaps they need to be a MUST
implement.
> 8.2.1.  Link Local Multicast
>
>    The scope of link local multicast packets is confined to the link
>    between MNs and the associated MAG node.  MAG nodes process but do
>    not forward link local multicast packets.  To support some functions,
>    such as for Duplicate Address Detection (DAD), MAGs might proxy
>    associated Neighbor Discovery messages to perform DAD procedure with
>    LMA nodes.  (See [I-D.ietf-netlmm-mn-ar-if]).
Really? Does this still hold after you decided to employ the per-mn
prefix model?
>    *  One or more IP address(es) of the LMA.  The LMA's IP address
>       information is acquired through the LMA selection policy, which is
>       out of scope of this specification.  Availability of multiple LMA
>       IP addresses could support operation of multi-homed LMAs.  Details
>       about how to handle multiple LMA IP addresses is out of scope of
>       this specification.
One thing that you should probably state in this specification
is whether the transport and sequence number state is per-LMA
or per-address.
>    The MAG serves as
>    the default gateway for an attached MN and forwards all packets from
>    the MN into the tunnel, which in turn encapsulates the packet towards
>    the LMA.
So, from a mobile node point of view when it moves, the subnet prefix
stays the same but the default router IP and MAC address changes? I'd like
to see the entire sequence of events on the mobile node - MAG interface
to understand if all of this can be achieved. In particular, it needs to
work
with DNAv6 and it must at least not completely fail with classic ND
implementations.

As I said before, I have not read the interface document yet so perhaps
that brings more details.

Smaller technical issues:
================
>    NetLMM Address
>       The invariant IP address on the MN inside the NetLMM domain.  For
>       IPv6 it is assumed that this is an invariant routable IP address
>       with global scope.
Did you mean "of the MN"? In any case, I'm not sure why you
need to define the address of the mobile node if you employ
the per-mn prefix model. And the IP address certainly need not
be invariant.
>    As a result of the mobile node connecting, the MAG sends a Location
>    Registration message to the LMA containing its own ID, the LMA's ID
>    and the Mobile Node's ID.  If no error is found, the LMA responds to
"the LMA" -- previously you talked about multiple LMAs. I'm sure
the rest of the document explains something about the selection.
If so, perhaps you want to say "to an LMA" instead.
> Figure 3
What happens if by some mistake the mobile node is still
connected to the pMAG as well? Are there specific
instructions in the spec for how the pMAG needs to behave?
> The LMA Allocation Request is optional and the LMA may be
> allocated by other means (e.g., static allocation) and can be
> configured to serve the MN without this message.
Earlier you indicated that the LMA can be configured
to serve any MN without this procedure. The last part
of the above sentence may be interpreted in different
ways, e.g., to mean that either this or some static
configuration is needed. Suggested edit: s/the MN/any
MN/.
>    The Disassociation Request message is sent from the MAG to the LMA or
>    vice versa to tear down the control and data plane relationship
>    between them.  This message contains the MAG ID and LMA ID.
>
>    An acknowledgement of the the Disassociate Request message is sent
>    from the LMN to the MAG or vice versa to indicate the status of the
>    request (success or error code).
Presumably all mobile nodes are at the same time deregistered
as the MAG is disassociated, right? Overall, I felt that the
behaviour descriptions need more work. No text about this
in 7.1.3.2 or 7.2.3.2 either.
>    If the MAG can not keep the MN state alive as long
>    as the LMA has requested for some reason, the MAG can indicate the
>    preferred timeout time and return an error code instead of copying
>    the original value.
Be more specific and say which error code is returned.
>    *  One or more global IP addresses or address prefixes of an attached
>       MN.  Each IP address or prefix is acquired from an LMA through the
>       Location Registration Acknowledgement or by means of local
>       operation.  According to the context of the received message or
>       local indication, an IP address is set up, updated or removed from
>       the Routing Cache.
What other local operation? Please explain or remove.
>    If an entry for that MN identifier is not present, the LMA MUST
>    create a new entry with the MN ID, the MAG ID and the MAG IP address.
The IP address seems unnecessary, given that its in the MAG
list.
> 8.1.3.  Future extensions
You have already stated this, and additional complexity in this
specification for explaining potential enhancements is not
warranted.

Editorial:
======
>   * The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. 
>   * The document seems to lack an RFC 3978 Section 5.5 Disclaimer. 
>   * The document seems to lack an RFC 3979 Section 5, para 1 IPR Disclosure
>     Acknowledgement -- however, there's a paragraph with a matching beginning.
>     Boilerplate error?
>   * The document seems to lack an RFC 3979 Section 5, para 2 IPR Disclosure
>     Acknowledgement. 
>   * The document seems to lack an RFC 3979 Section 5, para 3 IPR Disclosure
>     Invitation. 
>   * There is 1 instance of too long lines in the document, the longest one
>     being 1809 characters in excess of 72.
>   * There is 1 instance of lines with non-ascii characters in the document.
>   

Idnits reports the above, please fix.
>    (heartbeats_sent - received_acks) / (hearbeats_sent).  If the ratio
Typo.
>       The number of leadings bits in the Address that are valid as a
s/leadings/leading/
>    The IETF takes no position regarding the validity or scope of any
>    Intellectual Property Rights or other rights that might be claimed to
>    pertain to the implementatio
Interestingly, when I download the file from the IETF side, it ends
abruptly in 13K sequence of ASCII NULs. I wonder if this is my
problem or in the actual file.
> Figure 2
The numbering of the events is weird.

--Jari

_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm