Subject: Re: [Seamoby] (virtual) hum on CARD open issues

From: "Hemant Chaskar" <[email-masked]>
Date: Mon, 21 Jul 2003 16:12:56 +0000

Dear Vijay,

Could you provide a text to be included in the draft on rate limiting. We 
can include it in the draft after discussing it over mailing list. It 
probably wont suffice to say that rate limiting is in lot of protocols and 
hence not needed here. Different protocols use different rate limiting. E.g. 
TCP uses rate limiting, but it wont be appropriate for CARD.

If you are proposing to limit the rate by simply enforcing limit on 
aggregate rate of requests, I can easily argue that it is ineffective. So 
the question is: Wheater WG wants per MN rate limiting? If so, does it have 
to be using R flag or using limit on per-MN rate of request? And then, you 
can refer us to protocol that uses that type of rate limiting and we will 
simply refer to it - will save lot of writing.

Hemant

>From: Vijay Devarapalli <[email-masked]>
>To: Singh Ajoy-ASINGH1 <[email-masked]>
>CC: "Pat R. Calhoun" <[email-masked]>, [email-masked],    
>     [email-masked]
>Subject: Re: [Seamoby] (virtual) hum on CARD open issues
>Date: Fri, 18 Jul 2003 15:39:12 -0700
>
>Singh Ajoy-ASINGH1 wrote:
> >
> > > 1. Issue #2: R-flag for CARD Request rate limiting. What to do about 
>potential Dos issues? WG consensus is to Keep the R-flag approach. Meeting 
>consensus is to add clarifying text to section 4.2 (4.3?)
> >
> > this is wrong, IMHO. rate limiting is a well known mechanism.
> > introducing a new flag is not a bright idea.
> >
> > ajoy-> Why it is a bad idea?  Well, I am neutral in this
> > issue but I am not convinced why using R bit is worse than
> > your proposed solution.
>
>simple. rate-limiting is implemented in a wide variety of
>protocols (infact for any message that creates state at
>the receiving node). nothing new here. you dont need a new
>mechanism for this.
>
> > > 3. Issue #33: Inter-AR CARD protocol transport from UDP to ICMP. The 
>editor recommends the use of ICMP to make it consistent with the mobile 
>interface. Potential downsides: ICMP has potential security implications. 
>ICMP message types on binding is also very implementation specific. Also, 
>securing ICMP would require that all ICMP packets be secured. Meeting 
>consensus is to keep UDP.
> >
> > 2 and 3 dont go togetheer. defining CARD messages as ICMP
> > options lets you piggyback these options on FMIPv6 messages.
> > I am not sure how you can achieve piggybacking if the MN-AR
> > signaling becomes UDP. ICMP was the right choice between
> > the MN and the AR.
> >
> > AJOY-> Well I did not attend IETF meeting, but I guess this means ICMP 
>for
> > MN-AR and UDP for AR-AR interface. Others' please correct me.
>
>oops... I misunderstood. I thought the concensus at the
>meeting was to use UDP for both.
>
> > BTW, why are you in favor of
> > using ICMP for AR-AR interface?
>
>otherwise you need seperate code for processing an ICMP
>CARD Request (from the MN) and UDP CARD Request (from
>the PAR). also, if it is an ICMP message, I can piggyback
>CARD messages on HI/HACK messages of FMIPv6.
>
>
> > unbelievable. the CARD protocol is already complicated (IMO).
> > the emphasis should be on reducing the complexity. just use
> > a value of infinity for the lifetime field to indicate a
> > static capability. any other value for the lifetime indicates
> > dynamic capability. I think for the CARD protocol, emphasis
> > should be on making it a simpler protocol than saving 4 bytes
> > over the air. :)
> >
> > if you are concerned about an overhead of 4 bytes, make the
> > lifetime field 2 bytes. a 2 byte lifetime field gives you
> > 65536 seconds which should be enough. do you need a 4 byte
> > lifetime field?
> >
> > AJOY-> I disagree here. Saving even 2 bytes per capability is
> > huge saving for bandwidth constraint network. I am not sure
> > processing one flag will make CARD protocol any more complicated.
> > Btw, in cellular standard I have seen even more complicated
> > procedure for saving 4 bits per frame. Please note that
> > the CARD protocol is being proposed as an experimental
> > protocol so we will have opportunity to make such
> > changes in future if required.
>
>but in the current form not many people are going to use
>it. it might remain forever as an experimental, untouched,
>ignored, just another RFC.... that is something we should
>avoid. I want a protocol that I can use. :)
>
>Vijay
>
>_______________________________________________
>Seamoby mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/seamoby

_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*.  
http://join.msn.com/?page=features/featuredemail

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 21 Jul 2003 09:37:26 -0700

I already provided the text when I reviewed the CARD protocol.

  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.

and add to the constants section

  CARD_RETRANSMISSION_INTERVAL  1 second
  CARD_MAX_RETRIES              3

this is similar to ICMP rate limiting.

TCP rate limiting is different, not applicable here. in general
in any protocol where there is a request and a reply (and no
more messages), ICMP rate limiting is best suited. you dont have
to "source-quench" the Mobile Node. :)

Vijay

---

From: "Eunsoo Shim" <[email-masked]>
Date: Mon, 21 Jul 2003 16:30:15 -0400

Vijay,

Please see my comments below.

> to "source-quench" the Mobile Node. :)

What's going to happen if the AR should deal with a large number of MNs?
Also what if the network operator wants to use a different value for the
inter-message interval limit? How does the MN know the value?

You might think "source-quench" is significant additional complexity but
actually the AR must calculate the message rate of each MN to do policing
(that is, dropping messages over the rate limit) and thus doing
"source-quench" adds little additional complexity.

Eunsoo

---

From: "James Kempf" <[email-masked]>
Date: Sat, 26 Jul 2003 14:46:05 +0200

Hi Vijay,

I think the router needs to rate limit too, don't you think? To prevent a
DoS attack?

            jak

----- Original Message ----- 
From: "Vijay Devarapalli" <[email-masked]>
To: "Hemant Chaskar" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Monday, July 21, 2003 6:37 PM
Subject: Re: [Seamoby] (virtual) hum on CARD open issues

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 28 Jul 2003 09:58:09 -0700

> I think the router needs to rate limit too, don't you think? To prevent a

I am not too worried about rate-limiting AR-AR signaling
since the signaling has to be authenticated by IPsec. also
the ARs dont have to process requests from arbitrary access
routers.

Vijay

---

From: "James Kempf" <[email-masked]>
Date: Tue, 29 Jul 2003 10:52:21 +0200

I meant that the router needs to rate limit the mobile's traffic. That is,
if it starts getting too many CARD requests, it starts selectively dropping.
Sorry.

            jak