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

From: "Koodli Rajeev (NRC/MtView)" <[email-masked]>
Date: Fri, 19 Oct 2001 15:13:06 -0400

Hello,

I see my name popped up in the discussion. So, I have some comments
below. 

Regards,

-Rajeev

Michael Ramalho: 
>> 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.

My discussion with you pertained piggybacking and header compression
interworking. Looking at the concluding e-mail from you in that thread,
you admit that header compression would work when piggybacking is used.
More specifically, I showed that the near-end compressor need not know
in which state the far-end compressor is prior to piggybacking. So,
regardless of how you view the problem now, admitting in more positive
terms the outcome of the previous thread would only enhance the
credibility of your current input.

Now, onto Michael Thomas:

>Charles E. Perkins writes:
> > 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.
>
>   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.
>  

I am sorry: I don't see the flow of logic here.. BTW, I would have
agreed to the modularity  principle if you stated that one must not
strike out destination option because a particular link, yet
unspecified, does not know how to handle it.

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

This brings back the question of whether destination option must have
been specified in the first place because some weird link does not know
how to support it! What's the logic in saying IP cannot have
variable-sized packets because a link would have performance issues ?

If you are true to your modularity argument, then you should have not
any problems accepting destination option on any link!

> > > 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.
> > 
> > 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.
>
>   Uh, how? Until details are provided, I remain
>   skeptical.
>

Well, please check the recent archives for header compression and
piggybacking interworking.

> > 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.  
>
>   RTS/CTS-style links produce unacceptible latency
>   and jitter for real time traffic, especially at
>   slow link speeds.
>

So what ? If IP was designed looking into every possible link's
idiosyncrasies, you and I would probably not having this conversation!
hmm..

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

Huh, the same reverse engineering point again.. This is _really_ an
issue of how to carry IPv6 over certain links. I would think that we
would have an RFC similar to 2464, 2467, 2470 for the link you have in
mind. Perhaps you should volunteer to specify that, so that your current
(performance) problem would go away.

>	   Mike

---

From: Michael Thomas <[email-masked]>
Date: Fri, 19 Oct 2001 12:29:35 -0700 (PDT)

> unspecified, does not know how to handle it.

   Modularity would dictate that a packet with two
   separate functions should be divided into two
   packets. It's quite obvious that a great deal of
   the current set of problems with MIPv6 security
   suffers from the law of unintended consequences
   directly related to trying to avoid modularity.

 > variable-sized packets because a link would have performance issues?

   The current BU design is not modular. It claims
   that it did that because of bandwidth/latency
   gains. You have not presented a *single* MAC/PHY 
   where that claim can be tested. Here you dodge 
   my direct question yet again.

 > piggybacking interworking.

   I did. You haven't answered my question.

 > idiosyncrasies, you and I would probably not having this conversation!

   I'm only looking for a single link layer which
   benefits. You haven't provided an example.

		 Mike

---

From: Cedric Westphal <[email-masked]>
Date: Fri, 19 Oct 2001 13:08:30 -0700

Mike,

>    directly related to trying to avoid modularity.

Modularity means flexibility. So any modularity principle would
dictate -dictate is probably a bad choice of word: we would have
a 'flexible dictator'- if anything, that separate functions COULD be divided
into two packets, or COULD be integrated in one. That's modularity for you.

Point is: do not call upon modularity to dismiss a perfectly good idea that
precisely adds modularity to the network.

Cedric.

ps: Your 'modular dictator' is a softy, because it edicts 'should's instead of
'must's,
as any self respecting dictator would.

---

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

> precisely adds modularity to the network.

   Does putting SMTP datagrams into HTTP datagrams
   increase network modularity?

		    Mike

---

From: Cedric Westphal <[email-masked]>
Date: Fri, 19 Oct 2001 14:09:42 -0700

>    increase network modularity?

Don't you think this is beside the point?

Cedric.

---

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

> Don't you think this is beside the point?

   It's exactly the point.

	Mike

---

From: Cedric Westphal <[email-masked]>
Date: Fri, 19 Oct 2001 14:29:38 -0700

>  > Don't you think this is beside the point?

My point was a point of English language. You write:
'Modularity dictates': it's an oxymoron. You write:
'...dictates that it should....'; here's another one. Don't get me wrong,
oxymorons are nice, but when you write poetry. And you draw some
rather firm conclusions based on a sentence that's quite shaky.
Now you can shift the debate and advocate SMTP into HTTP, be
my guest.

Cedric.

---

From: "T.J. Kniveton" <[email-masked]>
Date: Fri, 19 Oct 2001 14:34:56 -0700

>  > Don't you think this is beside the point?

Then why don't you go post your point in a group that cares about SMTP
and HTTP datagrams?

-- 
        T.J. Kniveton 
  Communications Systems Lab
     Nokia Research Center

---

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

> Then why don't you go post your point in a group that cares about SMTP

   Maybe you and your coworkers should take a deep
   breath and look up what modularity means rather
   than making ad hominem attacks, and claiming
   false oxymorons on my part.

   Modularity is a generally good thing, but it
   has its limits. Piggybacking is expressly making
   a tradeoff against modularity. The only issue is
   whether that tradeoff is a reasonable one. That
   case has yet to be made.

	Mike

---

From: Cedric Westphal <[email-masked]>
Date: Fri, 19 Oct 2001 15:05:38 -0700

Mike,

>    false oxymorons on my part.

please do not disrespect me as an individual and bundle me in your
reply as a somebody's coworker. I did not make any ad hominem statement.
(however, it seems to me that: 'ad hominem attack' is a pleonasm).
Modularity means, 'constructed with standardized units or dimensions for flexibility and
variety in use'. I do not read: do not piggyback, but, quite on the contrary:
think flexible. By the way, telling me I don't know what modularity means,
when I am involved in this exchange, sounds ad hominem to me. I raise my
flag too.
Piggyback would not be modular if you could not switched it off. Turn out, you
can. Thus it is modular, qed.

Cedric.

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 19 Oct 2001 15:12:28 -0700

>    directly related to trying to avoid modularity.

Basically, you are arguing against IPv6 destination option. 2460 allows a
destination option to be sent as long as the destination option is meant for
the node identified in destination address of the base IPv6 header! So, if
there is a _UDP_ payload and a destination option for _IP_ to process at the
receiver, I see no break in modularity. Beyond this, you should really take
this issue with the authors of 2460, who BTW, could already be aware of this
usage (I assume).

>    my direct question yet again.

Actually, I mentioned previously that the use of [rohc] over cellular is one
reference for you. See http://www.ludd.luth.se/users/larsman/rocco and follow
the references.
Note: use of [rohc] would require support for variable packet sizes on the
link (perhaps the same kind of link you are considering).

Any link where media access latency and/or channel interleaving is a
significant portion of the total transmission delay would benefit from the
ability to piggyback.

>    I did. You haven't answered my question.

You were looking at/for something else I guess. Anyway, the essence of _that_
discussion was piggybacking and header compression would work fine.

>    benefits. You haven't provided an example.

Again, any link where channel acquisition and interleaving would be onerous.

I am glad that you have turned your attention towards the benefit of
piggybacking!

Regards,

-Rajeev

---

From: "T.J. Kniveton" <[email-masked]>
Date: Fri, 19 Oct 2001 15:12:50 -0700

>    false oxymorons on my part.

I simply suggested that you take your point which, according to you, was
"exactly," whether "putting SMTP datagrams into HTTP datagrams increases
network modularity" somewhere people care about SMTP and HTTP datagrams.
If, instead, it was supposed to be a simile or illustrate the point you
and Cedric were previously discussing, then my comment wouldn't
apply..nor would yours. 

I'll assume that you are joking when you tell me to look up "modularity"
in the same breath as accusing me of attacking your character (that's
what "ad hominem" means). Believe me, I *do* take a deep breath every
time my inbox fills up with messages like this.

>    whether that tradeoff is a reasonable one. That

The case probably hasn't been made because no one buys your premise..but
yourself.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 19 Oct 2001 15:28:47 -0700 (PDT)

> I'll assume that you are joking when you tell me to look up "modularity"

   No, I wasn't. This point is hardly
   controversial even though it seems to have
   struck a nerve.

 > The case probably hasn't been made because no one buys your premise..but

   I think you should speak for yourself. I'm not
   the only one around here who has serious reservations
   about whether piggybacking is worth the trouble. In
   dismissing my concerns as irrelevant or off-topic, 
   you are also dismissing a lot of people who are
   probably just tired of this merry-go-round.

	    Mike