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

From: "Michael A. Ramalho" <[email-masked]>
Date: Fri, 19 Oct 2001 10:45:40 -0400

Charlie,

I agree with Hesham's bottom line - that a decision to piggyback
at the sender has implications on the receiver (or the link to the
receiver is on if it too is on a weird L2).

In my email volleys to Rajeev last week ... I demonstrated that
if the other end was also a MN on a similarly constrained
L2 ... that it would be a bad practice to piggyback
*AT LAYER 3* onto a (real-time) media packet.

It seemed like most of the justification (by Rajeev anyway) was
the he wanted the piggyback to "fit" on the (cellular-like,
TDM structured) MAC layer during opportunistic times
(e.g., where ROHC gave significant compression and he
could fit a BU with the media packets). There is probably
a worst-case delay advantage for the BU for doing this in
comparison to the non-media IP traffic on the L2 link.

But this piggybacking is not persuasive for many reasons
(please read the archive .. but it comes down to Hesham's
bottom line that the far-end receiver and other L2s can have
problems with it)

Fundamentally - a BU is end-to-end signalling. Thus, an
ideal packet to piggyback onto is one that has similar
QoS characteristics.

Thus, the ideal piggyback would be to something like a session
signalling packet -  probably characterized by an assured
forwarding type PHB - where you generally desire low
loss and reasonable delay through the network hops. Someone
mentioned a piggyback onto a RSVP packet ... but those
packets undergo additional delay by QoS processing on the
hops (intserv) or COPS queries (diffserv) or both (for mixed
environments) .. so although RSVP is end-to-end signalling,
it can undergo additional delays so as to make it unattractive.

A "bad packet" to piggyback onto would be a media
packet  - probably characterized by an expedited forwarding
type PHB - where you tolerate an occasional loss ( 1 ~ 5%,
but I don't want to get into that debate) but you need *really
low* delay through the hops. This is the type of packet
that some have petitioned for the piggyback - I think
this is a really bad idea and not a healthy L3 argument
for piggybacking.

Thus ... choosing a packet to piggyback onto can be
difficult ... and I have argued is not worth the effort
(again, see the archive).

Besides, if you really desire piggybacking for your L2
link ... there is an opportunity to have your cake and eat
it too. Design a L2 piggyback of the non-piggybacked L3 BU
for your link ... and specify it in L2 bodies (e.g., IEEE,
3GPP, 3GPP2, ETSI/Hyperlan, Bluetooth ... ).

That is ... specify that if you are queuing a real-time
packet and you have room for the BU on your L2
timeslot (perhaps due to ROHC compressing of
a real-time packet) ... fit the BU and the media
packet on the L2 link timeslot! But be sure to
de-piggyback the L3 BU at the other end of your
L2 link!

By doing this you de-couple the piggyback debate out of
the IETF ... yet still accomplish your ends (efficiency
and delay on the L2 link). And it works for both sides ... if
the other end has a similarly constrained link. Please
comment if you (or anyone on the list) can think of a
reason why this is not a good approach (other than
efficiency arguments on the non-access links - given
average BU frequencies the gain is not significant).

Additionally, Mike Thomas (and others) have argued for
not piggybacking for security related reasons. These
arguments effectively plea for de-coupling of the problems
(a non-piggybacked L3 BU).

In closing, I'd say that the mobile-ip list debates of the last
week or so have effectively argued that the end-link efficiencies
gained by piggybacking are at worst harmful and at
best gain the QoS characteristics of the packet piggybacked
onto (which is not  what you want for some potential
piggybacks). Thus, I'd say the "best IP definition" (your
words) would argue for *not* piggybacking. The arguments
are technical ... but not the complexity-related, as your
previous email seemed to infer.

As I stated in my previous email, I think I am being a
realist here ... and I do not especially care to be
argumentative or divisive ... and have stated my
technical objections to L3 piggybacking.

And unlike those who only complain on the list,  provided
a way for those who desire piggybacking on arbitrary
L2s a way to accomplish the efficiency or delay advantage
(on the L2 link) they desire ... in a way that is not harmful
to the packets that would have been piggybacked onto.

Please respond to the technical issues before further
pursuing the pro-piggybacking case.

Regards,

Michael Ramalho

At 12:07 PM 10/19/2001 +1000, Hesham Soliman (EPA) wrote:
>Hello Charlie,
>
>Glenn Morrow said something which has resonated with me during  the last 
>week.
>
> > I guess people just don't agree on the value of piggybacking, the 
> affect of  > delays incurred by segmentation and whether the access 
> network should drive  > the IP definitions or the access networks should 
> adapt to the IP definitions.
>
>This seems to hit the spot exactly.  We have disagreements, but I 
>would  like to suggest that we should make the IP definitions based on 
>what's  good for IP instead of the restrictions imposed by the unadapted 
>access  networks (or, worse yet, the least common denominator of all 
>access  networks!).
>
>Applied to the discussion about whether Binding Update should be 
>carried  along with payload, this would mean that we should have the 
>feature if  it fits naturally in IP, and if there are going to be networks 
>which can  use the feature to good advantage.  The reasons why this 
>feature are  advantageous are outlined in the draft from Jari Arkko, along 
>with the  costs of the feature.  Some networks will gladly pay the cost, 
>and some  won't, for a myriad of reasons.
>
>I am very much in favor of making the best IP definition, and along 
>the  way making sure that it can be used to fit well with existing 
>access  networks.
>
>=> Sounds good. but below is where the problems begin IMHO.   The current 
>proposal with Destination Options does do that.  There is no requirement 
>that any implementation MUST supply payload  in packets that contain a 
>Binding Update, and almost all of the  complication from processing 
>payload with a Destination Option comes  on the sending side.  So I don't 
>agree with arguments based on the  extra complexity.  If some 
>implementations don't want to undertake  the extra complexity, that is 
>fine, but those groups should not be  allowed to penalize the 
>implementations that wish to offer the better  performance by the magic of 
>making it illegal to do so.  That is not  fair in my book.
>
>=> Well the problem is that IP is access independant :)  So while my IPv6 
>MN may refuse to piggyback, my HA  or CN might decide that piggybacking is 
>a good idea  and by that decision it is harming me.  This is despite the 
>fact that my MN does not piggyback.  So the problem can not be solved 
>based on a decision  made by one side.  This is the main problem, keeping 
>/removing piggybacking  is an issue that will affect the sender and the 
>receiver,  regardless of the design choices that each node may  make.
The key point is *the receiver* can be adversely affected by the decision.
>   Hesham

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 19 Oct 2001 11:09:58 -0500

Agreed almost entirely.
IMHO piggpacking on RSVP is another issue, yes there might be advantages of
doing it, so it is dealt with separately, as in
draft-ietf-aaa-diameter-mobileip-07.txt.

Regards,

"Michael A. Ramalho" wrote:

> --

Behcet

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 19 Oct 2001 09:40:55 -0700

Hello Michael,

Thanks for your note.

> receiver is on if it too is on a weird L2).

I want to characterize this as the result of another decision.

Forget piggybacking for a moment.  What if someone sends an
ICMP message to the receiver?  What if another application sends
a TCP SYN to the receiver?

In the scenarios you refer to, the decision has been taken to design
the bandwith-constained link to only handle connection-oriented
traffic.  One could argue that this goes against some basic
Internet principle or another, but instead I would just like to
emphasize that we shouldn't be pushed to shoehorn IP for _all_
links into restrictions that are motivated by _some_ links.
Furthermore, it is my belief that future links with the same
bandwidth constraints as are driving the current discussion will
still beneficially allow IP traffic without such heavy penalties
against non-uniform higher-level protocol packetization.

> comparison to the non-media IP traffic on the L2 link.

I read this as a particular response to the suggestion that
highly structured MACs couldn't handle the Binding Update.
I found his response to be reasonable, which is to say that
reasonable engineers could make it work.

> bottom line that the far-end receiver and other L2s can have

I agree that they _can_ have problems with it.  I also believe
that these problems will be overcome, and that some L2s do
not have the same problems.

> ideal packet to piggyback onto is one that has similar

But we aren't supposed to be designing purely for the QoS case.
Furthermore, I think that the QoS story for radio access networks
still has a few unwritten chapters.  When they're written, I also
think that including a Binding Update along with the payload will
be considered a very useful feature.  In face, we're trying to
draft out some ideas for those unwritten chapters in our group
already, and we do see the benefits.  For instance, it matters
for context transfer whether we can use Destination Options
or not.
            ...........

> (again, see the archive).

Maybe it's not so hard, if the correspondent node provides a
hint.  For instance, this could be done as part of the setup
for the Mobility Security Association.  If the correspondent
node is communicating over a link that has the constraints you
have described, then it can request that the mobile node should
send Binding Updates in separate packets.  If the correspondent
node _begins_, at some point during its communication (*), to
encounter link constaints that disfavor any destination
options along with data (notice this is a more general problem
anyway, regardless of Binding Updates), then we could arrange
for this information to come back as a status for the Binding
Acknowledgement.

(*) -- we should keep in mind that IP-level solutions SHOULD
       (MUST, even?) allow for changing care-of addresses between
       different media, not just the same medium at a different
       point of attachment.  And, that correspondent nodes are
       also likely to be mobile nodes.

The point is not to design the solution here, but to point out
that it's a more general problem, and that solutions are at hand.

> 3GPP, 3GPP2, ETSI/Hyperlan, Bluetooth ... ).

             ...........

Your suggestion implies that there are no benefits at the
receiving end, but I think that the benefits at the receiving
end pretty much mirror those at the sender -- as long as we
can protect against disadvantages as have been pointed out.

> previous email seemed to infer.

Some people have made arguments from complexity.  My arguments
are in favor of using Destination Options as designed -- as
information useful for the receiver that belongs in packets
with payload.  All of the arguments so far on this subject are
really arguments against Destination Options, motivated by the
constraints placed by links designed for connection-oriented
operation quite some years ago.  I don't suggest we should ignore
such links -- far from it!!  I am naturally very responsive to
the needs to have excellent performance across such links.

I think it is obvious that for bandwidth-constrained,
RTS/CTS-style links, that we should minimize the number
of times that each mobile node (among possibly many thousands)
has to acquire the media.  Plus we should remain sensitive to
minimizing the total data volume and the additional overheads
for extra packets (retuning, etc.).  There has been a marked
tendency to disregard these details in many IETF protocols,
and each bit of overhead does add up, eventually to a significant
performance loss.

> technical objections to L3 piggybacking.

Yes, I find that your notes are eminently reasonable, and I will
try to live up to the same standards.  I have tried to do so
in my discussion about the benefits for using Destination Options.

> pursuing the pro-piggybacking case.

I hope this counts!

Regards,
Charlie P.

---

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

> against non-uniform higher-level protocol packetization.

   This is, in fact, a good reason to keep things
   modular. The fact that piggybacking is problematic
   for many extant links, and not especially useful
   for others (ie, 802.11) says to me that the KISS
   principle probably applies.
  
   Also: I've asked Rajeev several times for an 
   example of a L2 on a shared media which delivers
   different QoS than BE which doesn't suffer from
   either excessive bandwidth utilization or undue
   latency/jitter for real time traffic, and thus
   far he hasn't provided me a pointer. Maybe he
   just can't talk about it, but if there exists
   such a beast I'd _love_ to hear about it (seriously).

 > reasonable engineers could make it work.

   Uh, how? Until details are provided, I remain
   skeptical.

 > has to acquire the media.  

   RTS/CTS-style links produce unacceptible latency
   and jitter for real time traffic, especially at
   slow link speeds.

 > Plus we should remain sensitive to

   A custom engineered, single application network
   is always going to be far more bit-efficient than
   a general purpose network. It has its cost though:
   it's single purpose. At some level that price must
   be paid; trying to have the best of both worlds
   is very likely to yield the worst of both worlds.

	   Mike