Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion

From: "Michael A. Ramalho" <[email-masked]>
Date: Wed, 24 Oct 2001 09:32:46 -0400

At 04:23 PM 10/24/2001 +1000, Hesham Soliman (EPA) wrote:
>Rajeev,  I don't know where I poorly explained my point, but  let me see 
>if this works.  Let's assume we have a tight channel with a large  RTT 
>delay and was designed with the assumption that HC  is used. Hence, there 
>is no 40 byte slack in the channel  because the assumption was always that 
>HC exists  and the IP header was not accounted for. This is  obviously for 
>the case where this channel is "tight"  due the low BW requirement of the 
>service running on it.
>
>When a device starts sending an occasional (additional) ext header  that 
>causes the payload to be split across more than  one radio frame, then 
>significant delays will be encountered  for that payload. If this is a 
>real time payload (like voice)  then the delays makes this datagram 
>useless when it  arrives at the other end. Hence service disruption 
>has  already taken place.  Note that I didn't say anything about the 
>packet being  dropped above. I will assume that the implementation  of 
>this channel will not drop the packet. So the packet  will still 
>(eventually) be delivered to the other end where  the BU is processed.
>
>Now In the above (_realistic_) scenario,  was the service disrupted due to 
>the piggybacking ? Yes  Will the BU be delivered to the other end ? Based 
>on the  assumption above: Yes  Is this radio link breaking RFC2460 ? No 
>because the  packet was not dropped.  Did the user gain anything from 
>piggybacking ? No.

I think Hesham hit the nail on the head here.

Rajeev/Charlie/(other proponents of mandatory piggybacking) - please
re-read this and comment what is wrong with Hesham's explanation.

Note that this occurs on Hesham's so-called "tight channel" - where a
low latency hop is provided over the air via a TDM-like "slotting" of a
channel for the real-time information. When these real-time packets
(typically of the expedited forwarding class) obtain bandwidth on this
channel - they get that much and no more. In fact, if you desire to
encrypt the RTP stream - the application must request the added
bandwidth for the encryption overhead (if any) - otherwise it will suffer
the same fate as the "overly large" piggybacked BU packet.

Now note that a signalling packet (a best effort or assured forwarding
type) being conveyed typically does not have this MAC layer constraint.
I am not too worried about piggybacking BUs on these packets and the
effect on the MAC layer - although piggybacking here can cause
QoS degradation due to L3 policing/scheduling/queuing (see my
posts of last week).

Now to address a concern that Charlie made ... there are some
MAC layer wireless accesses that once you "seize" you want to
hold onto and piggyback as much as you can onto them. I think
that most people on this list understand this concern - and agree
that piggybacking *can* have some merit for this case *assuming
that the piggybacked packet is of an appropriate type* (i.e., not
a media packet). However, one must argue is the extra effort
worth the effort - given average BU frequencies, the gains are
minuscule. The small (lower) delay benefit (of the piggybacked BU)
is even more dubious if you have BET capability (no flames
please ... seamoby cannot count on speedy BU updates).

Thus if piggybacking becomes an option via a destination
option - the default behavior *for media packets* must be no
piggybacking. I (and others) have argued that the default
behavior should be no piggybacking (for any packet type).
Specifying otherwise limits applicability on many known
MAC-layer schedulers (many I would think would be of
interest to Nokia - many are cellular-based, fixed bandwidth
slotted channels!).

Lastly - I think a case should be made that the destination
option is not an appropriate option. It assumes that the
real-time constrained link is at one of the (MN) ends ... and
that the MN knows about it. In general, the (bothered by the
piggybacked BU) link *could* be in a middle hop. Thus
the endpoint cannot, in general, make a piggyback BU
decision correctly for the end-to-end flow. It will not know
the constraints of any particular hop on the expedited
forwarding path!

Thus, the case has not been made IMHO that piggybacking
BUs are worth the effort and that an intelligent decision
regarding piggybacking could be made by the end node.

Can we please move on.

Michael Ramalho

Michael A. Ramalho, Ph.D.
Office email: [email-masked]
Personal email: [email-masked]
Office: +1.732.449.5762
Cell: +1.732.809.0188

---

From: Cedric Westphal <[email-masked]>
Date: Wed, 24 Oct 2001 09:07:42 -0700

Michael,

3 comments in line.

> >the case where this channel is "tight"  due the low BW requirement of the

This is a somewhat dubious set up. Hesham seems to forget that you have to
establish HC or re-establish it if you lose some packets and the compression
state due to fading in the air interface. Meaning that:
if you use HC on such a channel (and you would because of scarce bandwidth),
then you automatically have some slack in the channel.

> I think Hesham hit the nail on the head here.

Well, you did not read all of Rajeev and Hesham's exchange. Had you kept going,

you would have notice that this argument (variability in packet sizes in tight
channels)
applies to IPv6 destination options. According to Hesham's assumption, you
cannot add a
destination option to a header to a CN behind such a channel. Destination
options
would be disruptive for the same
reason. For the sake of a connection-oriented channel that is allocated beyond
common
sense (so tight as not to allow HC re-establishment), should we disallow IPv6
in
packet networks?  Fixed packet size networks exist, it is called ATM. It did
not take
over the world because fixed packet size denies flexibility and modularity.

> re-read this and comment what is wrong with Hesham's explanation.

Mandatory piggybacking? I was under the impression that most people in this
exchange where pro-choice. Disallow piggybacking if you have one of these
L2 issues Hesham/you/(other ATM proponents :-) mention, use piggybacking
when you can benefit from it.

As you say, let's please move on with the common sense solution.

Cedric.