Re: Re: CARD: Storing sequence numbers in ARs' CAR table?

Henrik and Marco,

My comments are inline.

>
> > "...Should the sequence number be stored in CAR table to enforce
ordering
> > of CARD replies ?"
> >
> > In my opinion, an AR needs to remember the sequence number
> > of a request only until the associated reply can be sent.
> > What could be the advantage of maintaining the sequence
> > number in an AR's CAR table for a longer time? Info flow
> > is from AR->MN, so it's the MN's responsibility to choose
> > sequence numbers appropriately for correlating replies
> > with requests and possibly to counteract replay attacks.
> > In case there is a positive offset in sequence numbers between
> > two consecutive Requests, this should not matter, or?
>
[eunsoo] I agree with Marco that any gap between sequence numbers of two
consecutive Requests is not a problem. The CARD protocol does not have to
guarantee the order of the received Requests.

> AR also receives piggybacked and other unsolicited AR-AR replies from
> other ARs. For these to have ordering, AR should IMO store the sequence
> number from the AR-AR CARD message header it receives.

[eunsoo] Right. MN or AR should remember the sequence number of the latest
unsolicited message from any (other) AR so that it can figure out the newer
information.

Then the sequence
> number in CARD request and reply could be used just for matching the
> messages.
>
[eunsoo] Right. I think we all agree to this.

> There is a similar problem is in the MN-AR protocol, with the ordering of
> solicited and unsolicited replies. A new field in the MN-AR CARD message
> header is _probably_ needed for sequence number, if strict ordering is a
> requirement.
>
[eunsoo] There is already the sequence number field in the headers of CARD
Request and Reply. Do you suggest any other field?

Eunsoo