Subject: [Seamoby] CARD Review from Henrik Petander

From: "James Kempf" <[email-masked]>
Date: Tue, 7 Oct 2003 09:25:51 -0700

Below is a Last Call review from Henrik Petander. Vijay has requested more
time for his review.

            jak
----------------------------------------------------------------

1. Protocol issues
==================

The handling of sequence numbers in MN and RA for resending is not
defined. Should MN increase the sequence number on resend? Should AR
identify a CARD request similar to an old one, except for the sequence
number, as a resend and set a new timer for AR-AR resending? How does
AR identify a "new" request from MN from resends of an old one?

The timeout values in MN -AR resending and AR-AR resending make AR-AR
resending overlap: If a message is lost between AR and CAR, both MN and
AR will resend it at the same time. Based on the discussion about AR-AR
resending, I understood that its purpose was to decrease the amount
of over-the-air messages, if a message is lost in the fixed
network. Now this does not happen.

To fix this, change the values for resending, so that MN_AR_CARD_TIMEOUT >
AR_AR_CARD_TIMEOUT * MN_AR_CARD_RETRIES. This should IMO be done by
decreasing the AR_AR timeout and amount of retries to avoid problems
with MN noticing messages lost between MN and AR slowly.

Should the sequence number be stored in CAR table to enforce ordering
of CARD replies ?

Now unsolicited CARD replies are to be authenticated with signatures,
which MN can verify with the public key of the AR, that MN has learned
from somewhere. This is very vague. The description of CARD should be
sufficient for two implementations to be interoperable. IMO you should
either remove the whole unsolicited CARD reply functionality, or clarify
the use of signatures so that it will actually work between two
independent implementations.

L2 id suboption should have address length field which MUST be
used at least with with L2 type = 0x00.

2. Editorial issues
===================

4. ...CARD Reply contains one or more L2 ids and IP addresses" Isn't
   this contradictory with the use of context id of L2 IDs from CARD
   Request in CARD reply to avoid including L2 ids? Change this to
   "may contain".

5.1.1

The text in 5.1.1 on including suboptions in CARD MN-AR request is
confusing to me. Which suboptions must be present in all messages? Isn't
it valid to send just a MN-AR CARD request to get all CARs and their
capabilities from AR?

5.1.2 Should maybe have a note that flag combination A= 0 with C=0 is
invalid.

6.3 Second paragraph is repeated from 4.6. Shouldn't this section
analyze the security, whereas section 4.6 should describe the
implementation of the security mechanisms.

6.4 CARD Reply DoS: Is this really a relevant threat, since CAR is
  authenticated with IPSec ESP? It seems to require compromise of CAR,
  so IMO this is out of scope.

7. Protocol constants

What is the purpose of CARD_RETRANSMISSION_INTERVAL and CARD_MAX_RETRIES?

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 09 Oct 2003 17:38:52 -0700

hi Henrik,

>What is the purpose of CARD_RETRANSMISSION_INTERVAL and CARD_MAX_RETRIES?
they are used in rate-limiting MN requests

   the MN MUST send
   only one CARD Request per CARD_RETRANSMISSION_INTERVAL and not more
   than CARD_MAX_RETRIES. If the MN sends requests more frequently, the
   AR SHOULD drop the CARD requests and not process them.

Vijay

---

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

you are right. the names for the protocol constants are confusing.

basically we need to do the following

1. We need to rate-limit requests from the MN.
2. specify retransmission behavior for the MN.
3. specify retransmission behavior for the Current AR.
4. specify sending behavior for unsolicited CARD replies

for (1), we need a protocol constant to say that the MN is not allowed 
to send
more than a certain number of requests per second. if it sends more than 
that,
the current AR just drops the requests. There shouldnt be an upper limit on
the number of requests.

for (2), we need protocol constants. one to say when to retransmit and 
one to
say when to give up.

for (3), same as (2).

(2) and (3) could share the same protocol constants.

(4) is already clearly defined.

Vijay

Henrik Petander wrote:

>Hi Vijay and all,
>
>Vijay, thanks for the clarification.  CARD_MAX_RETRIES is 3 and
>MN_AR_CARD_RETRIES is 5, so MN can try to resend the same query for 5
>times, but can make new queries (for different L2 addresses) only 3 times.
>Did I understand this correctly?
>
>If yes, then this scheme is a little confusing to me and raises some
>questions: Why is the interval called CARD_RETRANSMISSION_INTERVAL, if it
>concerns new requests, which are not resends?
>
>Why is there a fixed ceiling on how many new CARD requests MN can send ?
>Shouldn't there at least be a wait period after which MN can set the
>counter to zero?
>
>Thanks,
>
>Henrik
>
>On Thu, 9 Oct 2003, Vijay Devarapalli wrote:
>
>  
>
>>hi Henrik,
>>
>>    
>>

---

From: Marco Liebsch <[email-masked]>
Date: Fri, 10 Oct 2003 17:58:01 +0200

Hi Henrik,

thanks for the review. Maybe better to discuss individual issues in
separate mails, which will follow this one.

marco

---

From: Marco Liebsch <[email-masked]>
Date: Fri, 17 Oct 2003 15:20:16 +0200

Vijay Devarapalli wrote:

> more than a certain number of requests per second. if it sends more 
> than that,

In the recent draft, we have the following constants specified for that 
purpose:
CARD_RETRANSMISSION_INTERVAL = 1 second
CARD_MAX_RETRIES = 3

As far as I remember, this is the mechanism and values you proposed,
including the upper limit. This mechanism replaced the previous mechanism,
which was based on the more dynamic approach using the rate-limiting flag.
Do you now propose to drop the MAX_RETRIES limitation?

> for (2), we need protocol constants. one to say when to retransmit and 

The current draft specifies the following:
MN_AR_CARD_TIMEOUT = 1 sec
MN_AR_CARD_RETRIES = 5

> for (3), same as (2).

The current draft specifies the following:
AR_AR_CARD_TIMEOUT = 1 sec
AR_AR_CARD_RETRIES = 3

Referring to Henrik's feedback and addressed issue, the proposal was to
keep the MN-AR characteristics and to adjust the AR-AR characteristics 
as follows:
AR_AR_CARD_TIMEOUT: 300 ms
AR_AR_CARD_RETRIES: 2

There was no feedback yet.
Any comments?

> (2) and (3) could share the same protocol constants.

If we modify the AR-AR characteristics to counteract the issue
Henrik referred to, this cannot be done.

> (4) is already clearly defined.

Right.

marco