Subject: [Seamoby] Review of draft-ietf-seamoby-card-protocol-01.txt

From: "James Kempf" <[email-masked]>
Date: Wed, 5 Mar 2003 17:01:01 -0800

Finally had time to complete a review of the latest CARD draft. In general, the
design team seems to be making good progress on getting the details of the
protocol design filled in.

My comments break down into 3 areas: meta-issues involving contents of the
draft, specific technical issues with the contents, and editorial comments.

Meta-issues
------------

I found the draft somewhat confusing as there seem to be really four protocols
defined here. They are:

1) A collection of options for RFC 2461 and FMIP to provide a mobile node with
information about wireless handover connectivity to different subnets.

2) An RFC 2461 extension message for transmitting 1) between a mobile node and
access router in the absence of FMIP.

3) An interrouter protocol that uses 1) to exchange the same sort of information
between routers instead of between the mobile node and its access router.

4) An (underspecified) protocol between an access router and a server that lets
the access router authenticate CARD information and, optionally, pre-populate
its cache so that there is no learning period involved before the access router
can provide CARD information to the mobile node.

I think it would be really helpful to separate out these four areas and drill
down on them to get the details.

Specifically, I would like to suggest the following:

1) &2) As some of you may know, the Mobile IP group is currently undergoing
rechartering and there will be a BOF in SFO to discuss this. I have proposed as
part of the recharter that parts of the CARD work that have overlap with or have
relevance to FMIP be moved into a separate, spinoff MIP group. In the latest
FMIP draft, the proxy router advertisement signaling has been moved away  from
handover and now has no function other than to inform the mobile node about
wireless subnet connectivity. Since that is also what 1) and 2) are doing, I
would propose that the good work done in this document be sectioned off into a
separate document and introduced into the spinoff WG, should the IESG agree to
form such a group. If the ISEG doesn't, then I think the design team should
section the document and put this protocol into a separate document, dropping 2)
and making this signaling a collection of options on FMIP. In addition, I would
suggest that the CARD design team co-ordinate this with the current editor of
the FMIP draft. There is no point in having 2) if FMIP provides the
functionality.

3) I can't really see the point of introducing a new inter-router protocol of
this sort. I believe this would be better handled by defining some kind of
OSPF/IS-IS extension. I am not sure how the Routing Area would react to such a
proposal, however. In any case, it needs investigation and should be moved into
a separate document if it proves to be of interest.

4) I disagree with the contention of some that this protocol is introducing a
new network element. Any large scale enterprise or ISP network is going to have
configuration in it, and this protocol is essentially defining a way to do
configuration. For small, home networks, this might not be required, because it
might be done using a Web interface to the firewall/access point. The proposed
solution in this draft is fairly vague, but I can see a couple of possible
dispositions:
    a) Define a RADIUS extension like that used by IAPP.
    b) Define an LDAP schema for access point configuration information.
    c) Define an SNMP MIB that allows a router to obtain this information from
another router.
I believe 802.11 has its own MIB, but we are talking about something that is
more generic. I've got no opinion about which of these would be better, and
there could be other possibilities. We should decide fairly quickly which we
want to pursue.

Technical Comments
---------------------

Section 3.2: Highly dynamic capabilites should be out of scope. Also, in
paragraph 2, what are downlink channels? Not all wireless protocols will have
these.

Section 4.1: I can't see how an MN could possibly perform CARD with an AR that
is not currently on its subnet. How does the MN discover such an AR in the first
place except by performing CARD with its exisitng AR (in which case, it doesn't
need to perform it with the other one)? If you assume that the MN has brought up
a separate interface with the other AR, then the other AR is on a subnet that
the MN is using on that interface. RA/RS can't be sent to any off link node, as
they are limited by the security measures in RFC 2461. Also, I don't think that
we should be considering L2 specific measures here (like including the other
router's IP address in the L2 beacon).

Throughout the draft, the notes on TAR selection and prefiltering should be
moved to an appendix. This includes the part in Section 4.2. The discussion of
TAR in the Requirements suboption and the node types in the Address suboption
need to be removed. From the MN's point of view, it doesn't matter whether the
returned address was prefiltered by the router or not. TAR selection on the
router should be completely invisible as far at the MN is concerned, and
selection on the MN is out of scope for this draft.

Section 5.1.3 Option formats need to be aligned with FMIP to avoid duplication.
For example, the MN may want to know the subnet prefix on the new subnet, but
that is not defined here.

Section 5.1.3.4 Why is the 'P' flag necessary? I think we need to align with
FMIP and remove this.

Section 5.1.4: What function does the lifetime flag perform? Either the returned
information is valid or not. If there's a lifetime associated with it, that
should be in the returned information.

Section 6.2 & 6.3: The scope-id solution presented here is awkward, and is,
itself, subject to DOS attacks. The solutions presented in Section 6.3 for
handling these problems are much more streamlined and align with IP network
softstate approach:
    1) The protocol specifies a minimum interarrival time for sending requests.
    2) The protocol specifies a minimum reply time for routers replying. If too
many requests arrive, the router begins to selectively drop so hosts have to
retransmit.
    3) A default cache lifetime is defined. After this time, the router times
out the cache entry.
   4) An entry presented by the MN gets a preference level. The more times it is
reported by another MN, the less likely it is to time out. This needs to be
quantified and described as an algorthm.
These elements need to be added to the protocol draft for 1) in the meta-issues
section.

Editorial Comments
-------------------

Abbreviations that are defined in Section 2 should not be used until after they
are defined.

Section 2, CAR definition: the wording here is awkward. It needs clarification.

Section 3.1, paragraph 1, line 2: CAR that connects -> CAR that is connected

Section 3.1, paragraph 3, line 5: reverse address translation before -> reverse
address translation

Section 3.1, paragraph 4: These comments seem somewhat out of place. The new AR
isn't of interest to the MN for mobility purposes unless it is in a new subnet,
and, anyway, ARs in the current subnet will be obtained by RFC 2461 router
discovery. I also don't understand what the last sentence has to do with
anything.

Section 4.2 paragraph 9: the link layer ID of nearby AP -> the link layer ID of
a new AP. There are also a couple of other awkwardly phrased places in this
paragraph.

            jak

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