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

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Fri, 18 Jul 2003 14:30:08 -0500

Hello Vijay,
Please find my inline comments.
regards,
ajoy

-----Original Message-----
From: Vijay Devarapalli [mailto:[email-masked]]
Sent: Friday, July 18, 2003 1:12 PM
To: Pat R. Calhoun; [email-masked]
Cc: [email-masked]
Subject: Re: [Seamoby] (virtual) hum on CARD open issues

"Pat R. Calhoun" wrote:
> 
> Following today's meeeting in Vienna, we've been able to get consensus on most issues. However, we need to get consensus on the mailing list. Please send your opinion to both myself and James on each of the issues below (in a single e-mail, please), and I will tabulate the responses and send a resume to the list.
> 
> 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. 

 the MN has to
send one request per second upto a maximum of 3 requests. or
it can exponentially backoff. if the MN sends requests more
frequent than this, they are dropped by the AR. I even sent
some text for this, when I reviewed the CARD protocol.

> 
> 2. Issue #4: Drop CARD protocol message piggybacking with FMIPv6? Meeting consensus is to keep the current text for CARD protocol operation with FMIPv6.
> 
> 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.
BTW, why are you in favor of 
using ICMP for AR-AR interface? 

from a recent discussion on the IPsec mailing list, it
looks like we might get the ICMP type as an IPsec selector.
then you would be able to distinguish between different
ICMP messages. ofcourse I dont when it might be 
standardized.

> 
> 4. Issue #5: Static vs. dynamic capability attributes. The editor recommends that we keep the S-bit and use the 32-bit lifetime only when really required for dynamic capabilities. This saves bandwidth, but does complicate processing. Meeting consensus is to keep S-bit.

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. 

> 
> 5. Issue #6: Unsolicited CARD Reply message broadcast/multicast. Proposal by the editor is to use broadcast for IPv4 and multicast for IPv6. Add an unsolicited CARD reply unicast. Broadcast on wireless links can generate heavy traffic. James Kempf proposes that we drop this for now as we enter experimental. Alternative proposal is to mimic router advertisements, send when changes occur and send when new mobile shows up. Meeting consensus is to add a statement in the document that we considered multicast and leave it for future.

I am not sure I understood. is the unsolicited CARD Reply
message being dropped from the spec, because it cant be
protected?

> 
> 7. Issue #7. Preferences/Requirements sub-option. We should only use one of the two methods. Meeting consensus is to keep both the sub-option and the preference.

I believe combining these two will go a long way in 
simplifying the CARD protocol. I looked up the meeting
minutes, which said there were no comments on this at
all. I strongly suggest combining the two.

>
> 8. Issue #18. Requesting ARs to perform ONLY reverse address translation. This is an essential feature for the MN to indicate reverse translation. Ultimately, this could become obsolete since the Proxy message does this too. Meeting consensus is to specify a R-flag in the CARD request message.

great. I like this.

Vijay

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

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 18 Jul 2003 15:39:12 -0700

> issue but I am not convinced why using R bit is worse than

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.

> 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.

> 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.

> 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

---

From: Marco Liebsch <[email-masked]>
Date: Mon, 21 Jul 2003 14:58:28 +0200

Hi Vijay,

please see below for comments.
marco

>the receiving node). nothing new here. you dont need a new
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.

>avoid. I want a protocol that I can use. :)
 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.

Any other comments?

marco

---

From: Marco Liebsch <[email-masked]>
Date: Mon, 21 Jul 2003 17:41:09 +0200

Hi Vijay,

please find another comment below.

marco

>CARD messages on HI/HACK messages of FMIPv6.
I see the point and that's why we addressed this issue during the meeting.
According to some feedback (also before the meeting), not everybody sees
a problem with changing transport characteristics between MN-AR
and inter-AR interfaces.
Also not sure if piggybacking of CARD messages with HI/HACK
makes sense, since inter-AR CARD is in most cases required before
FastMIPv6 HI/HACK is performed. And HI/HACK is performed only with
the selected target AR. Of course, current AR could use this sequence
to update its own and target AR's CAR table entries, but I guess this
would make the "one time inter-AR CARD piggybacking, another time
stand-alone inter-AR CARD"-thing much more complicated.
What do you think?

---

From: "Eunsoo Shim" <[email-masked]>
Date: Mon, 21 Jul 2003 12:10:14 -0400

Hi, Marco and Vijay,

My comments are inline.

-----

> >>>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?)
> >the receiving node). nothing new here. you dont need a new

[eunsoo] Already it was pointed out that the ECN bit of TCP (RFC 3168) was
another example of this kind of flag. So using a flag is not a very new
invention.

We considered specifying a fixed minimum inter-message interval but we did
not like it because of inflexibility. As the MN roams around, it will
encounter ARs with different requrements and thus a fixed value may not
work. So we looked for a dynamic mechanism. One way is having the AR send
the rate information to all the MNs. It is not good in terms of bandwidth
efficiency.

What mechanism are you suggesting, Vijay?

> >>>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.
> >CARD messages on HI/HACK messages of FMIPv6.
[eunsoo] There was discussion about this in the meeting. It was pointed out
that it was difficult to protect ICMP messages using IP Sec and thus people
preferred keeing UDP for AR-AR communication. BTW, piggybacking is a good
point. A new IRTF effort started to integrate many mobility management
related protocols such as FMIP, CT and CARD. A good way of integration
should be found.

> indicating a static capability, hence, no lifetime field is present but

[eunsoo] I don't understand either that the bit is more complex than the
null lifetime. Also the bandwidth overhead of sending null lifetime value
can be significant when multiple (or many) static attributes are contained
in the CARD Reply. Bandwidth efficiency for the air interface is always a
very important requirement. As you know, people are talking about IP head
compression which is much more complex than using a bit to save bandwidth.

Regards,

Eunsoo

---

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

Marco Liebsch wrote:

> first CARD Reply. This keeps individual request rates flexible and avoids

see my reply to Hemant.

> But if there are any further argumements and concerns, we can again

:) 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

>avoid. I want a protocol that I can use. :)

was a specific reply to Ajoy's

>>procedure for saving 4 bits per frame

Vijay

---

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

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-masked]>
To: "Marco Liebsch" <[email-masked]>
Cc: "Singh Ajoy-ASINGH1" <[email-masked]>; "Pat R. Calhoun"
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, July 21, 2003 6:49 PM
Subject: Re: [Seamoby] (virtual) hum on CARD open issues