Re: (virtual) hum on CARD open issues

I agree with Vijay on the flag. If the design says that a well behaved
mobile should rate limit sends, and also that a router should rate limit
replies to prevent a DoS attack, there should be no need for the flag.

W.r.t. the interrouter protocol, if the two routers MUST have an IPsec SA,
any DoS packets will get dropped in the IPsec filtering, unless, of course,
the other router is compromised (and then the network operator has a lot
more problems than CARD).

            jak

----- Original Message ----- 
From: "Vijay Devarapalli" <[email protected]>
To: "Marco Liebsch" <[email protected]>
Cc: "Singh Ajoy-ASINGH1" <[email protected]>; "Pat R. Calhoun"
<[email protected]>; <[email protected]>; <[email protected]>
Sent: Monday, July 21, 2003 6:49 PM
Subject: Re: [Seamoby] (virtual) hum on CARD open issues


> Marco Liebsch wrote:
> >
>
> > I see your point. However, I don't see a reason why the flag as
> > flow-control indicator
> > should not work. Maybe there is also a benefit from implementation point
> > of view on
> > the MN. In case of having a flag, MN is notified when exceeding the
> > request rate. Of course,
> > AR has to maintain a per-MN state. Furthermore, rules have to be
> > specified for MNs
> > on how to behave when CARD Reply indicates exceeding rate. But from
> > implementation point
> > of view, this does not look very complicated on the MN side. However,
> > having a
> > "n-requests allowed per second"-rule on the MN, this needs to be
> > controlled and
> > implemented on the MN side, which looks like requiring a bit more effort
> >
> > Alternative proposal was to indicate a maximum rate for a particular AR
> > in the
> > first CARD Reply. This keeps individual request rates flexible and
avoids
> > defining static numbers.
>
> see my reply to Hemant.
>
> >  From complexity and implementation point of view, I don't really
> > understand why
> > the proposed mechanism makes the protocol complex? I don't see
> > any difference between having a check on the lifetime (==0x00000000?)
> > and in case it's
> > zero assume the capability to be static, and having a check on a
> > specific flag (flag == 1?),
> > indicating a static capability, hence, no lifetime field is present but
> > "value" descriptor
> > follows immediately.
> > But if there are any further argumements and concerns, we can again
> > think about it.
>
> :) a new flag means extra fields in the data structure,
> extra code to check the flag, set the flag... you
> already have the lifetime field. and you would be anyway
> checking the value of the lifetime field everytime you
> receive a capability parameter. I would generally avoid
> introducing additional flags.
>
> and this comment
>
> >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. :)
>
> was a specific reply to Ajoy's
>
> >>Btw, in cellular standard I have seen even more complicated
> >>procedure for saving 4 bits per frame
>
> Vijay
>
> _______________________________________________
> Seamoby mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/seamoby
>