Subject: Re: [Seamoby] Review of draft-ietf-semoby-card-protocol-02.txt

From: "Hemant Chaskar" <[email-masked]>
Date: Mon, 14 Jul 2003 18:55:50 +0000

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.

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-masked]
>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

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

---

From: Henrik Petander <[email-masked]>
Date: Tue, 15 Jul 2003 13:16:17 +0300 (EEST)

Hi Hemant,

> 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

> >Removal of per-session state from ARs

		----------------------------------
		Henrik Petander
		Helsinki University of Technology,
		GO/Core Project
		[email-masked]
		Office: +358 (0)9 451 5846
		GSM: +358 (0)40 741 5248
		----------------------------------

---

From: "Eunsoo Shim" <[email-masked]>
Date: Wed, 16 Jul 2003 13:52:20 -0400

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