Re: Review of draft-ietf-semoby-card-protocol-02.txt

Hi, Henrik,

I think it is preferable to reduce any traffic on the air from the MN. So if
the retransmission by AR can reduce the over-the-air traffic, the cost can
be worthwhile unless it is too big. I am not sure maintaining a state per
request to check reply is too much complex in this case.

Eunsoo

----- Original Message -----
From: "Henrik Petander" <[email protected]>
To: "Hemant Chaskar" <[email protected]>
Cc: <[email protected]>
Sent: Tuesday, July 15, 2003 6:16 AM
Subject: Re: [Seamoby] Review of draft-ietf-semoby-card-protocol-02.txt


> Hi Hemant,
>
> On Mon, 14 Jul 2003, Hemant Chaskar wrote:
>
> > Hi Henrik,
> >
> > Clarification on your comment on per-session state: It is not clear to
us
> > why AR-AR resending requires any additional MN-specific state in AR. For
> > AR-AR interface, in each AR there would be one outgoing queue of queries
and
> > one incoming queue of replies. Replies will be matched to requests and
> > retransmissions will be done if needed. An implementation specific
window
> > (>= 1) could be defined for this similar to ARQ. Do you agree with this
or
> > we are missing something from your comment.
>
> Let me clarify my view of the per-session state and the tradeoffs of using
> it. The queue is one way of implementing the per-session state, since you
> add a new entry to the outgoing queue every time you get a request from
> MN.  You need to manage the queue and specify maximum size for it. When
> the queue becomes full you need to drop some requests, causing MNs to do
> resending. If there is no per-session state, this is not a problem.
>
> IMO removal of the per-session state in AR would make the protocol simpler
> and would reduce its requirements for the memory capacity of the router
> without compromising its reliability and probably with no real negative
> effect on its performance.  Making the protocol lighter for the AR seems
> to me worth MN doing resending in case of problems in the access network,
> which should be rare. Reducing the state in AR would further reduce the
> probability of problems ;-)
>
> Henrik
>
> >
> > Hemant
> >
> >
> > >
> > >Removal of per-session state from ARs
> > >-------------------------------------
> > >
> > >The responsiblity for resends for MN initiated sessions is both in
> > >the MN and the current AR. Since the weakest link in the protocol from
a
> > >reliability POV is probably the air interface, the AR-AR resending in
> > >the MN initiated sessions is probably not worth the extra complexity.
> > >
> > >Removing it would simplify AR a lot, since it would not need to
maintain
> > >any state for CARD in addition to the CAR table. An AR without
per-session
> > >state would be less vulnerable to DoS attacks and would also
> > >scale better.
> > >
> > >(The preferences and requirements should then be appended also to the
> > >current AR - CAR messages, if the current AR lacks knowledge of the
> > >capabilities of CARs.)
> > >
> > >4. CARD PROTOCOL OPERATION
> > >--------------------------
> > >
> > >Is there a specific reason to use the rate limiting flag instead of
> > >normal ICMP rate limiting ?
> > >
> > >Anyways, the rate limiting mechanism, which MN uses after getting a
> > >reply with R-bit set, should be defined. There exist a number of
> > >already defined mechanisms for dealing with resending intervals and
> > >rate limiting. Why not use one of them?
> > >
> > >
> > >
> > >4.1 Data structures
> > >-------------------
> > >
> > >Should there be a recommendation for MN to cache the information about
> > >CARs ?  MN needs a CAR table with cached answers from CARD
> > >replies to avoid asking the same information repeatedly, and for being
> > >able to react to movement as quickly as possible.
> > >
> > >
> > >4.2.2 Current access router operation
> > >-------------------------------------
> > >
> > >If you use IPSec ESP for protecting CARD between MN and AR, you cannot
> > >send multicast CARD replies. IPSec security associations are between
> > >two hosts.
> > >
> > >You need to protect the CARD replies in some other way (for example
> > >with signatures as proposed in the CARD problem statement draft), or
> > >always send them as unicast packets.
> > >
> > >4.3.1 Current access router operation
> > >-------------------------------------
> > >
> > >Is it necessary to include the capabilities of current AR in
> > >AR-AR CARD request message?
> > >
> > >If the data in a current AR for a CAR is not up to date, it still does
> > >not mean that the data for the current AR is not up to date in the
> > >CAR. Including the AR-AR CARD reply automatically in the CARD request
> > >creates unnecessary load in both routers when they authenticate /
> > >encrypt extra data.
> > >
> > >This optimization also adds extra complexity to the protocol, and it is
> > >not clear to me whether it is worth it.
> > >
> > >4.4. CARD Signaling Failure Recovery
> > >------------------------------------
> > >
> > >The draft does not define what an AR sends to MN, when it cannot
> > >resolve a L2 address into an IP address. This should be specified
> > >clearly.
> > >
> > >4.4.2 AR-AR signaling failure
> > >-----------------------------
> > >
> > >What does the CAR send to current AR, if it does not have an interface
> > >/ AP attached to it with the queried L2 id? This should be
> > >defined.
> > >
> > >4.5 Piggybacking
> > >----------------
> > >
> > >In appendix B.2, there is a note that it may not be necessary to use
> > >FMIPv6 PRTSolPr and PrRtAdv, if MN-AR CARD messages are exchanged,
> > >since the CARD messages convey all the necessary information. This
> > >seems to make the piggybacking of CARD on top of the PrRt messages
> > >irrevelant. Is there some reason to do it, which is just missing from
> > >the text?
> > >
> > >If not, this section should be removed and the messages should be
> > >carried on top of UDP as in AR-AR case.
> > >
> > >
> > >4.6 CARD protocol security
> > >---------------------------
> > >
> > >You should move everything about IPSec ESP here and indicate clearly
> > >how it should be used. Now the text about its use is scattered around
> > >section 4. Perhaps the security section should be renamed "Protection
> > >of CARD messages" to make a clear distinction between the
> > >implementation of the protection versus the analysis in section 6.
> > >
> > >The section should say that 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. Definition of the SPD entries
> > >would also be nice.
> > >
> > >5. Protocol messages
> > >--------------------
> > >
> > >Is 8 bits enough for the CARD option length field? This translates to
> > >255 octets, which seems limiting to me, especially since the
> > >capabilities have not been defined. Also the AVP encoding rules in
> > >5.1.4 have a 16-bit length field, which conlicts with the fact that
> > >they still need to fit within the options with 8-bit length fields.
> > >
> > >AR - AR message format in 5.2.2 includes a length field which is
> > >redundant with UDP's length field and should be removed.
> > >
> > >7. Protocol constants
> > >----------------------
> > >
> > >Where are their values defined?
> > >
> > >
> > >Editorial comments
> > >==================
> > >
> > >General
> > >--------
> > >
> > >The term SHALL was used in the section 4 for use of IPSec
> > >ESP. However, in sections 5 and 6 the word SHOULD was used
> > >instead. The use of "SHALL" was new to me so I checked its meaning
> > >from RFC 2119. According to the RFC its use is: "MUST   This word, or
> > >the terms "REQUIRED" or "SHALL", mean that the definition is an
> > >absolute requirement of the specification."
> > >
> > >This should be fixed.  If capabilities such as pricing information are
> > >transferred between ARs and MNs, I would opt for use of SHALL/MUST for
> > >the authentication requirement. Also the card requirements draft uses
> > >the word MUST for authentication and SHOULD for encryption.
> > >
> > >4.3.2 Candidate Access Router Operation
> > >---------------------------------------
> > >
> > >Last sentence: "The CAR SHALL use IPsec ESP for authentication _or_
> > >optionally encryption of the AR-AR CARD Reply message."
> > >
> > >Shouldn't the "or" be "and" instead? The encryption algorithms for ESP
> > >do not provide integrity protection and should not be used without
> > >an authentication & integrity protection algorithm.
> > >
> > >4.4.1 MN-AR Signaling Failure
> > >-----------------------------
> > >
> > >"The _AR_ SHALL start a timer (MN_AR_CARD_TIMER) after sending a MN-AR
> > >  CARD Request message with the given sequence number."
> > >
> > >Shouldn't it be the MN, which starts the timer instead of AR?
> > >
> > >
> > >5.1.1 CARD Main Header Format
> > >-----------------------------
> > >
> > >"Encapsulating Security Payload (ESP) Header:
> > > The sender SHOULD include the Encapsulating
> > > Security Payload (ESP) Header, based on the
> > >         previously established Security Association
> > >         between the sender and the receiver."
> > >
> > >Shouldn't this SHOULD be MUST intead?
> > >
> > >5.2.1 Protocol Transport
> > >------------------------
> > >
> > >"To authenticate protocol messages between ARs, the IPsec ESP SHOULD
> > >    be used [10]."
> > >
> > >Again, SHOULD vs. MUST/SHALL.
> > >
> > >6.1 Assumptions
> > >---------------
> > >Second paragraph, last sentence:
> > >
> > >"The appendices of this draft describe procedures for discovering the
> > >identities of the geographically ARs and APs and relevant security
> > >considerations."
> > >
> > >There seems to be a word missing after "geographically". Adjacent?
> > >
> > >6.2 Security Association between AR and AR
> > >-------------------------------------------
> > >
> > >"To prevent the information from being compromised, the CARD REPLY
> > >  messages between ARs SHOULD be authenticated. The messages also MAY
> > >  be encrypted for privacy of the information."
> > >
> > >Again SHOULD vs. MUST/SHALL.
> > >
> > >6.3 Security Association between AR and MN
> > >
> > >"A malicious node can send bogus CARD REPLY messages to MNs by
> > >masquerading the AR. So the MN SHOULD authenticate the CARD REPLY
> > >messages from the AR."
> > >
> > >Again SHOULD vs. MUST/SHALL.
> > >
> > >6.4 DoS Attack
> > >--------------
> > >
> > >Should it be mentioned here that authenticating CARD requests is
> > >needed to allow ARs to protect themselves against CARD request
> > >flooding with spoofed addresses?
> > >
> > >(Authenticating the requests makes DoS less likely as the attacker's
> > >identity is revealed and her account can be disabled, etc.)
> > >
> > >The meaning of the second paragraph is not clear to me. How can an
> > >attacker masquerade as an AR, if all entities in the protocol are
> > >authenticated? It seems to me that this would be possible only if an
> > >AR is compromised. Should the protocol be secure also against
> > >compromised routers?  This should be specified in the assumptions
> > >section.
> > >
> > >
> > >Appendix A.
> > >----------
> > >
> > >The appendixes form quite a large part of the draft. A.1 and A.2
> > >should be either integrated into the main draft as optional parts or
> > >be separated into their own drafts.
> > >
> > >A.1.4.1 Security Associations
> > >
> > >More details are needed on how IPSec ESP is used.
> > >
> > >A.2
> > >
> > >What does pAR send to current AR to verify that it had or did not have
> > >state for MN?
> > >
> > >
> > >A.2.4
> > >
> > >"should" vs MUST be protected with IPSec ESP.
> > >
> > >Appendix B.
> > >----------
> > >
> > >B.1 should be removed, since it is not needed for implementation of the
> > >protocol. The draft is self explanatory enough to be used with
> > >IEEE 802.11 WLANs without this appendix.
> > >
> > >B.2 raises the question, whether there is a need for an "architecture"
> > >draft instead, which describes how CARD and FMIPv6 or CARD and CTP can
> > >be used together.
> > >
> > >
> > >
> > >_______________________________________________
> > >Seamoby mailing list
> > >[email protected]
> > >https://www1.ietf.org/mailman/listinfo/seamoby
> >
> > _________________________________________________________________
> > Protect your PC - get McAfee.com VirusScan Online
> > http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
> >
>
> ----------------------------------
> Henrik Petander
> Helsinki University of Technology,
> GO/Core Project
> [email protected]
> Office: +358 (0)9 451 5846
> GSM: +358 (0)40 741 5248
> ----------------------------------
>
>
> _______________________________________________
> Seamoby mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/seamoby
>