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

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Wed, 10 Oct 2001 15:55:49 +1000

Hello Charlie, 

> >      the minor changes involve throwing out piggybacking (which
> >      in my opinion is a nice feature).
> >
> >      => This was discussed in detail, it's nice but not practical.
> >      BW-constrained links (like cellular links) allocate set
> >      channels based on the service, piggybacking the
> >      BU _will_not_fit_ in the channel and the packet will
> >      dropped ! That's not nice is it.
> >      Non-BW-constrained links could not care less if
> >      we piggyback or not.
> >
> 
> First, it was discussed in detail.  It's nice.  For some applications
> on some links, it's not practical.  For other applications on other
> links, it is practical.  It's been implemented, tested, and it works.
> 
	=> I realise it was implemented and tested. My issue here 
	is that how does a MN know whether the CN receiving 
	the piggybacked BU will be negatively impacted by piggybacking ?

	Jari has mentioned this in a previous email but I'll quickly mention
	it again. A MN on a WLAN could be sending a BU to a CN
	connected to a cellular link which was assigned a fixed channel
	size. Because the BU was piggybacked, the entire packet
	is dropped as it doesn't fit in the allocated channel. 
	Is there any solution to avoid this scenario ? 
	This is only one of the issues that were mentioned
	against piggybacking. 

	Hesham

---

From: Pekka Savola <[email-masked]>
Date: Wed, 10 Oct 2001 10:13:58 +0300 (EEST)

> 	This is only one of the issues that were mentioned

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.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Jari Arkko <[email-masked]>
Date: Wed, 10 Oct 2001 10:40:24 +0300

>Path MTU Discovery supposed to detect this?  Or just have MTU 1280 if in

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
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: Pekka Savola <[email-masked]>
Date: Wed, 10 Oct 2001 10:53:25 +0300 (EEST)

> of them. Any suggestions?

Link layer should fragment the IP datagram.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 10 Oct 2001 10:58:06 +0300

>Link layer should fragment the IP datagram.

Yes, but then the whole stream of packets is
"moved forward" in terms of delay. Delay
might be bad enough already for this to not
be possible without loss of quality. Could
be better to throw away the whole packet.

Jari

---

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

> Path MTU Discovery supposed to detect this?  Or just have MTU 1280 if in

Pekka,

The details are pretty krufty, but when you have a
shared media (air, cable, real ethernet), there
are just a few choices if you want to give
preferential treatment of some flows over other
flows. The most common is to appoint a scheduler
(the AP, the CMTS, etc...) who allocates time on
the upstream to the attached units, and completely
manages the downstream traffic.

While it's possible to have contention mode
upstream scheduling, (pseudo-cs/cdma) it generally
results in either additional latency, unreliable
delivery, or both. One solution to these problems
is to prearrange periodic transmission 
opportunities of a fixed length. For example, I
might at the start of a call request 40+8+12+20
(ip, udp,rtp,g.729) sized slots every 10ms to
carry voice data. The scheduler books this
resource, and the TDM-like slots are always
allocated regardless of use.

This is a simplified version as there are many
things that you can do to soak of some of the slop
inherent with TDM-like slots, but they all suffer
from a common problem: you need to allocate slots
to the roof of your sent data. For piggybacked
BU's, that means that you'd conceivably need to
also account for their size if you wanted to
piggyback them on the fixed slot channel (ie,
80+~40, eg 50% more bandwidth). Unfortunately,
that would be a huge waste of bandwidth since the
rate that you send BU's is (hopefully) miniscule
compared to the voice traffic. As such, you will
almost certainly never piggyback BU's in that sort
of environment.

       Mike, and I don't understand how ROHC
        will deal with this either...