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

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 10 Oct 2001 09:28:43 -0700

> 
> >Uhh.. Am I missing something that should be painfully obvious, but
isn't
> >Path MTU Discovery supposed to detect this?  Or just have MTU 1280 if
in
> >doubt.
> 
> No, the issue was what happens if you reserve a "tight" channel for
> e.g. a multimedia stream and then you get randomly hit by extra ~ 20
> bytes in the packets. What if the bytes don't fit the channel? The

I don't understand why this problem is specific to binding updates.
Are you saying that under such a reservation, the packet size can't
vary at all ? If I have been sending 1000 bytes, which is way less
than 1280, if I send 1020 bytes, will it be dropped ? Then when such
a tight channel is reserved there should be indication to IP to
change its MTU value so that path mtu discovery can kick in. 

-mohan

> channel was allocated based on the assumption that you will only
> be sending the particular stream packets. Packet-Too-Big would
> be inappropriate, particularly when you'd have to complain about
> a size < 1280...
> 
> This is an interesting problem, and it also has variations: a
> node that itself is attached to the tight channel would be able
> to avoid piggybacking in its own messages, but the node on the
> other end might not know this is necessary.
> 
> There might be solutions to this, but at least I'm not aware
> of them. Any suggestions?
> 
> Jari

---

From: Michael Thomas <[email-masked]>
Date: Wed, 10 Oct 2001 10:14:31 -0700 (PDT)

> change its MTU value so that path mtu discovery can kick in. 

   Yup, that's the problem. It really has nothing to do
   with MTU; it's about keeping within the constraint of
   a reservation. MTU is link based, not flow based afterall.

	Mike

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 10 Oct 2001 11:02:36 -0700

>    a reservation. MTU is link based, not flow based afterall.

It is not entirely accurate to say that you cannot piggyback when using a
dedicated channel. For instance, it is well-known that header compression
gain can vary from packet to packet, thus affecting the compressor states.
In a dedicated channel, which is what this thread is focussing on
I assume, in order to accommodate `header bursts', you need to reserve for
the worst-case. Now, IF that's the case, piggybacking a BU does not
necessarily violate the reservation, since, I could piggyback a BU on  FO
or SO packets (which have better compression gain compared to a packet
with no compression gain). The BU length, assuming 12 bytes for
Authentication Data, is 26 bytes compared to 40 bytes for IPv6 header
alone. So, when IPv6 header is not present, as would be the case in a SO
or FO packet, you _can_ piggyback, even in the so-called dedicated
channels.

Regards,

-Rajeev

---

From: Michael Thomas <[email-masked]>
Date: Wed, 10 Oct 2001 11:24:32 -0700 (PDT)

Rajeev Koodli writes:
 > the worst-case. 

   If you have to allocate for the worst case,
   why run header compression at all for those
   L2's?

   Serious question. I truly don't understand how
   folks expect ROHC will be helpful for voip
   traffic in cellular/wireless environments. This
   is the reason that the DOCSIS cable MAC uses the
   more predictable, but less bandwidth efficient
   payload header suppression (PHS).

		  Mike

---

From: "Michael A. Ramalho" <[email-masked]>
Date: Wed, 10 Oct 2001 14:47:20 -0400

>or FO packet, you _can_ piggyback, even in the so-called dedicated

Rajeev,

Sounds like you are only considering one side here - the MN sending.

Assuming you are using link-by-link compression ... consider the
case where the "other end" is also a MN that can receive and send
"piggybacked" BUs AND is using a similar header compression scheme.
This is a legitimate, if not increasingly prevalent, case.

Unfortunately ... you won't know (on the sending link) which packets
will have headers compressed on the "far-end" link ... as each link
can compress headers independently.

Thus, although you know when it is "safe" to piggyback on the
sending MN link ... you won't know whether the resulting packet
will fit into the "far end" MN link.

So ... I strongly disagree ... you really don't know when it is safe to
add a BU to the (real-time, TDM constrained) flow!

Seems to me that you really should not be piggybacking BUs
without BOTH ENDS agreeing that this is OK.

Not piggybacking is OK as long as you have something like BETH
anyway. If the BU takes a little longer to get where it is going, BETH
should take care of the problem.

Additionally you probably desire some form of over-the-air persistence
on the (non ultra-delay-sensitive) BU (i.e., a re-transmission) ... and
probably don't desire the re-transmission of the real-time packet.

So ... my vote would be for allowing piggybacked BUs only when
both ends say OK. OK?

Comments?

Michael Ramalho

> >         Mike

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

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 10 Oct 2001 12:12:00 -0700

>    why run header compression at all for those

worst-case allocation does not imply CBR-only. A VBR channel (with CIR, PIR,
MBS) would work.

>    traffic in cellular/wireless environments. This

Enlightenment elsewhere!

Regards,

-Rajeev

---

From: Michael Thomas <[email-masked]>
Date: Wed, 10 Oct 2001 12:40:29 -0700 (PDT)

> worst-case allocation does not imply CBR-only. A VBR channel (with CIR, PIR,

   If they are available. I'm under the impression
   that cellular doesn't have those available, nor
   am I all that hopeful that a VBR-like service is
   going to have enough of the desirable characteristics
   (upstream latency in particular) that a voip service
   would like.

   I've been through this many, many times with cable.
   If you have references to a shared media VBR scheme
   which has the proper latency characteristics which
   isn't at the expense of bandwidth, I'd be very 
   interested to read about it.

	      Mike

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 11 Oct 2001 10:44:49 -0700

Hello Michael,

interesting point. However, even with link-by-link compression I think it will
still work.

Here is your scenario:

1) MN1 sends a compressed packet with piggybacked BU to AR. The AR
decompresses the packet on the received link.

2) AR sends compressed packet with piggybacked BU to MN2 on another link.

Your point is you may not have enough capacity to do 2) above, right ?

Well, I think header compression has this predictability property. If you
compress a packet, decompress it and compress it again, the compression gain
should be the same! In other words,

let H be the total header size.
   1.   X = compress[H]
   2.   H = decompress[X]
          goto 1.

In the second iteration, value of X should be the same as in the first
iteration.

Regarding your other comment concerning BU persistence, you can re-transmit a
BU on a fresh real-time packet. You don't need to re-transmit the original
real-time packet itself.

Regards,

-Rajeev

ps. no comments regarding BETH.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 11 Oct 2001 21:24:49 +0300

> should be the same! In other words,

Yes, but I think the scenario was that the sender
was e.g. a multimedia server on www.cnn.com, completely
unaware of the fact that the other end is on a tight
channel, and uncompressed. Then it happens to piggyback
a Binding Ack on the multimedia stream. Or a WLAN MN
capable of using a lot of bandwidth compared to the
cellular MN on the other side.

Jari

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 11 Oct 2001 11:49:51 -0700

> cellular MN on the other side.

There are ways to handle the scenario you describe. That's the purpose of this
note.

Regards,

-Rajeev

---

From: "Michael A. Ramalho" <[email-masked]>
Date: Thu, 11 Oct 2001 15:21:32 -0400

Rajeev,

Another volley to make myself more clear. You have my point
*almost* correct.

Comments in line.

Michael Ramalho

>Your point is you may not have enough capacity to do 2) above, right ?

Yes ... I'll explain in line below.

>In the second iteration, value of X should be the same as in the first

One hopes that the "predictability property" is always true.

But ... links make the compression decision independently
(as I previously stated).

Consider three links (to make it simple), L1 -> L2 -> L3.

Lets say, without loss of generality, that L1 and L3 are the
links to the mobile nodes AND lets say that L2 *does not
use compression*.

That is the compression state of L1 is *INDEPENDENT OF
THE COMPRESSION STATE* of link 3.

Specifically ... your compressed BU sent on L1 (w/ FO or
SO state on compressed link L1) is decompressed
for transmission on L2.

But how do you know a priori that L3 is *NOT IN IR STATE*
when L3 gets it.

The point is that you don't know this a priori - and therefore
do not know if the BU will fit onto L3.

It usually will ... as L3 hopes to be in FO or S0 state and
obtaining compression ... but my point is that it is not
guaranteed.

Ordinarily I like it when the odds are with me in probabilistic sense,
but this isn't an ordinary UDP voice packet (where I wouldn't
mind an isolated loss) ... it has a BU piggybacked to it.

So ... you need another email volley to convince me.

>BU on a fresh real-time packet. You don't need to re-transmit the original

Interesting proposal ... and it is doable ... and it raises an interesting
tradeoff and a question or two.

Your proposal assumes that the link layer knew that there was an
error ... and that it was smart enough to know that the packet was
a real-time packet (and not attempt to retransmit it) AND smart enough
to know that the BU it had piggybacked could be delayed until the
next real-time packet (i.e., not immediately sent).

Does the link layer always know when the next packet is supposed to
arrive (for example, VoIP with VAD ... you don't know!)? I guess you
could simply transmit the BU if the "expected packet" doesn't arrive
in time (a timeout based on the expected interpacket arrival time of
the real-time flow).

But ... I hope this is moot ... since I had hoped to convince you that
piggybacking on L1 may not be a good idea.

If you are into building specialized link layers for outgoing BU's, I
*could* be convinced that building a specialized link layer at the
L1 decompressor that ALWAYS de-biggybacked a BU which was
sent over L1 could be designed. This would localize the effect of
the piggybacking only to a given link. But since I have not given the
idea full thought ... you would need to work on me a little more :-).

Regards,

Michael Ramalho

>ps. no comments regarding BETH.

opps .. :-)

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 11 Oct 2001 19:06:25 -0700

Hello Michael,

thanks for clarifying. I have some clarifications as well.

- a *compressor* resides in IR/FO/SO states, not a *link*.
- similarly, a decompressor has either no context, static context or full context.

- compression is limited to IP and transport protocol headers. So, once you do
ip_output, the HC engine works on IP and transport headers before the device
driver output occurs. Nowhere in this *compression process*, the link layer itself
comes into play.

It turns out that Compressor-1 (on L1) need not know in which state Compressor-2
(on L3) is before sending a piggybacked BU. Consider the following two cases.
First, the compressor on L3 would be in an IR state if it has never initialized a
context for this stream or there has been a pathological failure of an existing
context. Note that once a compressor determines that the decompressor has Full
Context, it must not transition to the IR state unless there is an irrepairable
context. It should be in FO, SO, or IR-DYN states, all of which have enough room
to include additional bytes the size of a BU.

Second, if Compressor-2 _is in_ IR state when it receives a piggybacked BU, it
would have to be able to include the BU as part of initialization, just as it
should be able to handle any IPv6 extension header. I believe 3095 specifies how
to handle the extension headers.

So, in summary, the chances of Compressor-2 being in the IR state when a
piggybacked BU is received should be small. However, if it is indeed in the
IR state, it should not matter.

Regards,

-Rajeev

---

From: "Michael A. Ramalho" <[email-masked]>
Date: Fri, 12 Oct 2001 08:26:03 -0400

Rajeev,

One more time for further clarity. I think the discussion
moved off the original point. Comments in line.

Regards,

Michael Ramalho

>to handle the extension headers.

I have no doubt that the Compressor-2 knows how to do its job - it would
do it as you have said. That was never my point (hopefully I have proved that
I am cluefull on this issue and move on).

The issue that triggered this thread was that the outgoing packet with the
piggybacked BU could only fit on the outgoing link (L1) if ROHC was in
FO or SO - for the case of a QoS constrained, DOCSYS-like output link
(which effectively has packet length limitations due to the QoS granting
mechanisms used on the link).

I agreed with that ... but said you were forgetting about the link on the
other side.

On the other side ... you do *not* know the compression state ... and
do not know if the packet with the piggybacked BU will fit into the QoS
channel.

I have *no doubt* that ROHC knows what to do with a packet with
a piggybacked BU. My point is not about compression; but rather
on the point (Mike Thomas' actually) that the piggybacked packet
may be too large for other links as well.

>IR state, it should not matter.

Again, I have little doubt that the ROHC folks know how to handle this
case. The issue is whether a QoS link can handle the larger packet
created by a piggybacked BU.

>-Rajeev

Think for a moment what one is saving via a piggybacked BU.

One argument is that it is saving precious bandwidth - so piggybacking
is good.

However, this *ignores* the way QoS flows are provisioned. One
example - the one above with a QoS grant mechanism on a link - shows
that piggybacking can be detrimental. But it is far from the only example.

Most QoS provisioned flows are policed at the edge of a network to
fit within a certain TSPEC/RSPEC. Given the expected frequency of
BUs ... to all but the most tight policers (in time constant or in strict
bandwidth), this increase would be negligible. This is effectively your
"wiggle room" argument. But one could imagine some policers would
actually mark the packet for discard eligibility (the new DE bit) or drop
it if the packet was too long. This is exactly the *wrong* thing to happen
to the BU (and to the QoS flow, which did nothing wrong!).

If I (and people like Mike Thomas) have not convinced the group that
BU piggybacking has more downsides than are worth it ... we may
be forced into a bigger debate on the interaction of QoS and mobileip.

[do you really want to go here ...]

To give an example of the proposed further debate .... suppose that
a pair of hosts have a "session" between them with a multiplicity of
QoS flows associated with this session (e.g., a videoconference with
QoS only provisioned on the voice). Now you want to send a BU.
Which "QoS type" packet do you piggyback onto. If the link layer
is dumb (the usual case) ... choosing the next packet is the easiest
choice. But you don't know the next packet's QoS treatment. In this
scenario, I'd choose one of the "reliable, delay insensitive" channels
if I had a choice. I would *not* choose the voice QoS channel.

In general, choosing "what type" of packet to piggyback onto is
hard. If you simply choose the "next or present" packet - at best
you get the QoS of this flow - and at worst you effectively harm
the packet/flow (e.g., marking it DE) for the flow that wanted
premium treatment.

Until convinced otherwise ... I am not persuaded that BU piggybacking
benefits outweigh the potential downsides. And I have not even
exhausted thinking about the downside arguments yet.

Remember ... one can make the following argument as
well ... "given the expected frequency of the BUs, that the
bandwidth saved by piggybacking is also negligible".

I am attempting to be a realist here. Bandwidth savings (piggybacking)
is usually good ... unless it causes more pain than the savings is worth.

Best Regards,

Michael Ramalho

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 12 Oct 2001 10:01:07 -0700

Hello Michael,

> moved off the original point. Comments in line.

I believe it did with your following e-mail in which QoS replaced header
compression as the topic of discussion :-)

In my e-mail exchange with _yours_, I saw no reference to QoS earlier. It was
limited to how header compression would work, with piggybacking, when it is done
on a "link-by-link" basis as you called it. From your reply below, seems like you
agree that piggybacking would still work even if the far end compressor was in
IR state. In fact, it should work regardless of in which state the compressor is.
If the far end channel knows how to support ROHC at all, piggybacking should work.
So, good; I would like to move on as well.

Regards,

-Rajeev

---

From: "Michael A. Ramalho" <[email-masked]>
Date: Fri, 12 Oct 2001 14:22:00 -0400

>So, good; I would like to move on as well.

I'll reiterate what Mike Thomas said about 5 emails back:
"This has nothing to do with ROHC implementations."

As far as the compression technique was concerned, ROHC
works at the far end. But that was not the issue.

The piggybacked packet *would not fit* on a similarly QoS
constrained link at the far end. Additionally, it might ruin
existing QoS flows to the mobile endpoint. This was the
point of my earlier email.

Thus ... don't piggyback to begin with (i.e., do NOT put it
in the L3 standard).

Now ... if you build L2 links specific to a technology (i.e.,
digital cable TV/DOCSYS links ... or special cellular links)
please feel free to specify special "L2 link specific" technology
that ... on that particular link type .... can piggyback the
BU to save bandwidth if you desire. But be sure to
"de-piggyback" the BU upon egress from your link.
That way, L3 never knew about the piggybacking.

Thus, if you absolutely need to piggyback a BU for a
particular L2 technology .... specify it at L2 in 3GPP
type bodies. Specifying BU piggybacking at L3 in the
IETF has the detriments of my earlier email (and others
that I have not thought of yet).

Besides, there are enough cross L2/L3 issues in
mobility to begin with :-).

Regards,

Michael Ramalho