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

Hi Dirk,

On Thu, 17 Jul 2003 [email protected] wrote:

> Hi Henrik,
>
> I must strongly agree with Eunsoo here. The reason to tranfer the
> retransmission functionality to the AR is a matter of failure handling
> and air bandwidth reduction.

I will clarify further my view on this. The main source for protocol
failures should in properly designed networks be the air interface.
Failure of the wired part of the access network should be a rare
occurrence and the over the air bandwidth reduction achieved with AR doing
resending should therefore be marginal. In the end this is a tradeoff
between a IMO marginal optimization and reducing the complexity of the
protocol. It would make sense to me to simplify the protocol by removing
the per-session state in AR and having the resending responsibility solely
in MN.

>
> However, Hemant's proposal of MAY for the AR implementing
> retransmission, could be one way to go in order to remove the issue,
> even though I would prefer a SHOULD in this place.

MAY would fit well with the other optional features which benefit from the
per-session state in AR, i.e. filtering of capabilities. I would prefer
either MAY or removing the feature.

Henrik

>
> Dirk
>
> >-----Original Message-----
> >From: ext Eunsoo Shim [mailto:[email protected]]
> >Sent: Wednesday, July 16, 2003 1:52 PM
> >To: Henrik Petander; Hemant Chaskar
> >Cc: [email protected]
> >Subject: Re: [Seamoby] 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
> >>
> >
> >_______________________________________________
> >Seamoby mailing list
> >[email protected]
> >https://www1.ietf.org/mailman/listinfo/seamoby
> >
>
> _______________________________________________
> Seamoby mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/seamoby
>

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