Subject: [Seamoby] CARD review - Minor issues

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 09 Oct 2003 19:26:13 -0700

hi all,

version 04 is a much improved draft. thanks. here are some minor issues 
that
I could spot.

>   If a MN can listen to L2 IDs of new APs prior to making decision
>   about IP-level handover to CARs, a mechanism is needed for reverse
>   address translation. This function of the CARD protocol enables the
>   MN to map the received L2 ID of an AP to the IP address of the
>   associated CAR that connects to the AP. To get the CAR's IP address,
>   the MN sends the L2 ID of the AP to the current AR and the current
>   AR provides the associated CAR's IP address to the MN.
>
>   In cases where the MN can acquire IP connectivity with CARs prior to
>   making handover decisions, this functionality is trivially realized,
>   since the MN can request CARs individually for discovery of
>   capabilities.
>  
>
doesnt the second paragraph belong to section 3.2?

in section 4.2.1, delete

>For example,
>   using the Preferences message parameter, a MN may indicate that it
>   is only interested in these CAR(s) supporting a specific air
>   interface technology. Similarly, using the Requirements message
>   parameter, a MN can indicate the list of capability attributes and
>   associated capabilities' values to its current AR. The Requirements
>   message parameter may be used to indicate the cut off values of the
>   capabilities for the desired CAR(s).
>
the above is a repeat. it is previously described in detail in
section 4.

section 4.3.1

>the MN's current AR
>   SHALL extract the capability information from the payload of the
>   received message and buffer the received capabilities in its local
>   CAR table.
>
s/buffer/store/

section 4.3.2

>AR-AR CARD Request. The CAR SHALL buffer the received capabilities
>
same as above

section 4.4.1

>A MN SHALL detect the loss of a
>   MN-AR CARD Request or MN-AR CARD Reply Message using a timeout
>   mechanism (MN_AR_CARD_TIMEOUT). The MN SHALL start a timer
>   (MN_AR_CARD_TIMER) after sending a MN-AR CARD Request message with
>   the given sequence number. The MN SHALL stop the timer as soon as
>   the reply to the MN-AR CARD Request is received by it. Upon
>   expiration of the MN_AR_CARD_TIMER, the MN SHALL declare the
>   outstanding message as lost, resends the same message and restart
>
>   the MN_AR_CARD_TIMER.
>

replace the above by

A MN SHOULD retransmit the CARD Request, if it does not receive a
CARD Reply within MR_AR_CARD_TIMEOUT seconds.

section 4.4.2

>The MN's current AR MAY detect the loss of an AR-AR CARD
>   Request or an AR-AR CARD Reply message using a timeout mechanism
>   (AR_AR_CARD_TIMEOUT). The current AR MAY start a timer
>   (AR_AR_CARD_TIMER) after sending the AR-AR CARD Request with the
>   given sequence number. The current AR should then stop the timer as
>   soon as the reply to the AR-AR CARD Request is received by it. Upon
>   expiration of the AR_AR_CARD_TIMER, the MN's current AR declares the
>   outstanding AR-AR CARD Request as lost and then resends the same
>   message to the CAR.
>

replace the above by

The MN's current AR SHOULD retransmit the CARD Request, if it does
not receive a CARD Reply within AR_AR_CARD_TIMEOUT seconds.

section 4.5

> To allow MNs and ARs appending the ICMP-option type CARD Request and
>   CARD Reply (Section 5.1.2) to the ICMP-type Fast Mobile IPv6
>   signaling messages
>
I think this is the first time Fast MIPv6 appears. a reference to
the FMIPv6 draft will be useful.

section 4.6

>  The MN-AR and AR-AR messages' authenticity MUST be ensured using
>   IPsec ESP [10]. It is safe to assume that there will be an
>

s/it is safe to assume/The CARD protocol assumes/

>   appropriate SA between a MN and its connected AR, which MAY be used
>

s/appropriate SA/IPsec Security Association/

>   The proposed mechanism for authenticating unsolicited and multicast
>   MN-AR CARD Reply messages at MNs is the use of digital signatures.
>   This assumes that the MN has discovered the respective AR's public
>   key before the received unsolicited CARD Reply messages can be
>   validated.
>

this is too vague. why not just say

  This document does not specify a mechanism for securing
  unsolicted multicast MN-AR CARD Reply messages.

section 5.1.1, delete the following. it is already said in a
couple of places in the draft.

>         Encapsulating Security Payload (ESP) Header:
>                        IPSec ESP MUST be used with a non-null
>                        integrity protection and origin authentication
>                        algorithm and SHOULD be used with a non-null
>                        encryption algorithm for protecting the
>                        confidentiality of the CARD information.
>

section 5.1.3.1

>   L2 type:       Indicates the interface type (optional).
>
>                  If the L2 type indicator is not used, this field MUST
>                  be set to 0x00.
>
>                  The following types are initially defined:
>
>                  Technology    |  L2 type
>                  --------------+---------
>                  IEEE802.11    |   T.B.A.
>                  CDMA2000      |   T.B.A.
>                  WCDMA         |   T.B.A.
>

I think IANA does not have assign the L2 type. it can be done in
this draft itself. I know I was the one who raised this issue
earlier. but now I realise IANA's role is not needed for the L2
type. my mistake.

Vijay

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 09 Oct 2003 19:34:49 -0700

missed this in the earlier mail.

in section 8, delete

>   This document authorizes IANA to assign the new ICMP type to the
>   CARD protocol main header and to the CARD Request and CARD Reply
>   option, as well as to assign the UDP port number for inter-AR
>   protocol operation and an IPv6 link-local and IPv4 well known
>   multicast address for unsolicited CARD Reply message multicast. This
>   document also authorizes IANA to assign fixed L2 Type values for the
>   wireless technologies IEEE802.11, CDMA 2000 and WCDMA. Note that it
>   is not possible to identify all possible access technologies where
>   CARD can be applicable, so we have chosen three access technologies
>   to begin with.
>

it is a repeat of the earlier paragraph in the same section.

Vijay

---

From: Marco Liebsch <[email-masked]>
Date: Mon, 13 Oct 2003 17:44:12 +0200

> earlier. but now I realise IANA's role is not needed for the L2
I am not sure about this. If we want type identifiers to be valid beyond
the scope of a specific operator's domain or a specific implementation,
the control on these numers should be assigned to somebody, ensuring
their use in a unique manner.

Why do you think this is not necessary, or, more precisely, who,
if not IANA, should take over the control function on these identifiers?

marco

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 13 Oct 2003 09:44:45 -0700

> if not IANA, should take over the control function on these identifiers?

define them in the CARD protocol document itself. anybody who implements
CARD will use the same type values from this document. there shouldnt be
any interoperability problems.

Vijay

---

From: Marco Liebsch <[email-masked]>
Date: Mon, 13 Oct 2003 19:39:59 +0200

> any interoperability problems.

This works for some selected access technologies. What about future ones or
some we might forget? Preferably would be to use something existing or
at least something that can be re-used by others when specified once.
Wouldn't be reasonable if every protocol defines its own types, or?

marco