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

From: "Glenn Morrow" <[email-masked]>
Date: Fri, 19 Oct 2001 13:06:39 -0500

Michael and All,

I suggest an unencumbered compromise to the wierd L2 issues and respond to
the arguments below:

> -----Original Message-----
> From: Michael A. Ramalho [mailto:[email-masked]]
> Sent: Friday, October 19, 2001 9:46 AM
> To: [email-masked]'
> Cc: Morrow, Glenn [RICH2:C330:EXCH]; [email-masked]
> Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion
> 
> 
> 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).

GM] This is true that both sides are affected; however, the weird L2 should
be adapted to handle the piggybacking in its weird way for downstream
traffic. Just as it does other weird things for certain downstream traffic
such as layer 5 signaling. 

If we start worrying about weird L2's in the IETF definition of L3
protocols, we will have to change almost every piece of signaling there is.
Trying to remove something from MIP, using as the argument, some wierd L2,
sets a horrible precedence. Don't you agree?

To see this point - let's take HTTP. Now if I had to worry about these wierd
L2's, then the IETF would have made HTTP more like WAP. Is that the
precedence you want to set? I don't think so. We should also note that the
L2's adapted by inventing WAP to deal with the wierd L2 problems. I am
perfectly confident that these L2's can be adapted to handle piggybacking
for downstream traffic coupled with anything.

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

GM] O.K. Here's a compromise. How about we say that binding updates SHOULD
NOT ever be piggybacked with unencrypted RTP packets because there are some
wierd L2s? 

This would allow the quite useful piggybacking to be used with the medias
transported with TCP and UDP. I think this would fix the issue for these
wierd L2s that do optimization for voice and perhaps other media. I also
don't see a big problem with implement complexity. 

I am really hoping this compromise works for everyone.

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

The ROHC is sniffiing the packets and doing all sorts of stripping etc..
Because the sniffer is present, special L2 things can be done. There are
other channels across the L2 that these packets can be delivered on. The
delay induced by this would probably not be that significant. The
specification of this does not belong in the IETF. It belongs in the wierd
L2 standards groups; however, the compromise above should negate the work
from having to be done; however, I still think it is wrong to have the IETF
L3 protocols worry about wierd L2s.

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

GM] Well one could argue that a layer 5 packet goes though proxies and
registars that also do authorization checks and lookups, perhaps MIDCOM
interactions which have significant delay as well. It should also be noted
that session messages and session servers don't typically have routing
topology information which would be needed to enforce QoS at the bearer
stream for the flows which are being operated on. Dispersion and maintenance
of routing topology information to layer 5 proxies would be a nightmare,
IMHO.

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

GM] I'm hoping the SHOULD NOT compromise above to not piggyback with
unencrypted RTP packets will settle this once and for all.

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

GM] And others are also argued that it is worth it.

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

I think the work to do this is the same as handling it at L2 using the L3
BU. Because of this I think your point is not valid and is not an excuse to
change the L3 protocol; however, the compromise above should alleviate your
concerns.

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

GM] Again, the work is the same - point fails.

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

GM] The work and gain is the same to interwork the L2 with the L3 BU

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

GM] The current security mechanisms in the MIP draft alleviate the problems
that were used to warrant Mike Thomas' claims. In short, the current
definition of the spec fixes the problem. It just doesn't do it with only
IPSEC and IKE. This argument was simply - I want to use IPSEC only. There
were choices on trying to fullfill this:

1> Change IPSEC to do some new things
2> Get rid of piggybacking

My take is that <1> was rejected at this time because people want to
progress the draft without the delay induced via inter-WG politics and
operations. 

And <2> was rejected because I think people have some forsight that
piggybacking is needed if you ever want to get the bearer path sensitive
IETF protocols to work together synergistically.

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

GM] Due my arguments above, I do not agree with your technical assessment;
however, I have offered a compromise that hopefully all can agree with. It
only requires a simple check to see if an un-encrypted packet contains RTP. 

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

I think we are all trying to be realistic and respectfull of others
concerns, desires, backgrounds and current resources. I offer an
unencumbered compromise that hopefully all can agree with and we can move
forward on.

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

GM] I agree you have been logical in your arguments.

Highest regards to all,

Glenn

---- Glenn DONE ----

---

From: Michael Thomas <[email-masked]>
Date: Fri, 19 Oct 2001 11:31:03 -0700 (PDT)

> such as layer 5 signaling. 

   Can you point out a non-weird L2 which would 
   substantially benefit from piggybacking? I'm
   pretty sure that my decidedly non-weird ethernet
   at home wouldn't realize any substantial benefit.

	   Mike

---

From: "Jari T. Malinen" <[email-masked]>
Date: Fri, 19 Oct 2001 11:53:10 -0700

I agree on the principle of not re-designing IP too much to weird
behavior in the middle, in addition to NAT-like boxes, this should
also cover weird links. Should QoS negotiations and link characteristics
not allow for piggybacking, and this re-design of IP is really desired,
how about a negotiation in MIPv6:

Add a "don't piggyback" bit in BAck. MN closer to the weird link when
receiving a BU would know when to discourage piggybacking. If the first
piggybacked BU packet would be so unfortunate as to be dropped at
the entrance to the weird link, the sending MN would then not
piggyback on resends and then get the BAck with "don't piggyback".
Special devices using e.g. RTP over some cellular links would also
know to add this bit to BAcks.

This should address Hesham's note on the far end not knowing when
to not piggyback?

-Jari

> Glenn Morrow wrote:
> 
> Michael and All,
> 
> I suggest an unencumbered compromise to the wierd L2 issues and respond to the arguments below:
> 
> GM] This is true that both sides are affected; however, the weird L2 should be adapted to handle the piggybacking in its weird way for downstream traffic. Just as it does other weird things for certain downstream traffic such as layer 5 signaling.
> 
> If we start worrying about weird L2's in the IETF definition of L3 protocols, we will have to change almost every piece of signaling there is. Trying to remove something from MIP, using as the argument, some wierd L2, sets a horrible precedence. Don't you agree?
> 
> To see this point - let's take HTTP. Now if I had to worry about these wierd L2's, then the IETF would have made HTTP more like WAP. Is that the precedence you want to set? I don't think so. We should also note that the L2's adapted by inventing WAP to deal with the wierd L2 problems. I am perfectly confident that these L2's can be adapted to handle piggybacking for downstream traffic coupled with anything.
> 
> >
> GM] O.K. Here's a compromise. How about we say that binding updates SHOULD NOT ever be piggybacked with unencrypted RTP packets because there are some wierd L2s?
> 
> This would allow the quite useful piggybacking to be used with the medias transported with TCP and UDP. I think this would fix the issue for these wierd L2s that do optimization for voice and perhaps other media. I also don't see a big problem with implement complexity.
> 
> The ROHC is sniffiing the packets and doing all sorts of stripping etc.. Because the sniffer is present, special L2 things can be done. There are other channels across the L2 that these packets can be delivered on. The delay induced by this would probably not be that significant. The specification of this does not belong in the IETF. It belongs in the wierd L2 standards groups; however, the compromise above should negate the work from having to be done; however, I still think it is wrong to have the IETF L3 protocols worry about wierd L2s.
> 
> >
> GM] Well one could argue that a layer 5 packet goes though proxies and registars that also do authorization checks and lookups, perhaps MIDCOM interactions which have significant delay as well. It should also be noted that session messages and session servers don't typically have routing topology information which would be needed to enforce QoS at the bearer stream for the flows which are being operated on. Dispersion and maintenance of routing topology information to layer 5 proxies would be a nightmare, IMHO.
> 
> >
> GM] I'm hoping the SHOULD NOT compromise above to not piggyback with unencrypted RTP packets will settle this once and for all.
> 
> >
> I think the work to do this is the same as handling it at L2 using the L3 BU. Because of this I think your point is not valid and is not an excuse to change the L3 protocol; however, the compromise above should alleviate your concerns.
> 
> >
> GM] The current security mechanisms in the MIP draft alleviate the problems that were used to warrant Mike Thomas' claims. In short, the current definition of the spec fixes the problem. It just doesn't do it with only IPSEC and IKE. This argument was simply - I want to use IPSEC only. There were choices on trying to fullfill this:
> 
> My take is that <1> was rejected at this time because people want to progress the draft without the delay induced via inter-WG politics and operations.
> 
> And <2> was rejected because I think people have some forsight that piggybacking is needed if you ever want to get the bearer path sensitive IETF protocols to work together synergistically.
> 
> >
> GM] Due my arguments above, I do not agree with your technical assessment; however, I have offered a compromise that hopefully all can agree with. It only requires a simple check to see if an un-encrypted packet contains RTP.
> 
> >
> I think we are all trying to be realistic and respectfull of others concerns, desires, backgrounds and current resources. I offer an unencumbered compromise that hopefully all can agree with and we can move forward on.
>

---

From: "Jari T. Malinen" <[email-masked]>
Date: Fri, 19 Oct 2001 12:02:17 -0700

>    at home wouldn't realize any substantial benefit.

Any narrow-band link where there is substantial overhead in separating
one packet into two would potentially benefit from piggybacking. This
overhead can include channel reservation, L2 framing, etc. The overhead
can be both bandwidth and time.

For example, consider some old technologies, like (A)X.25. 
If you have 300-1200 bps link you'd like to avoid sending any extra
packet. Especially when having multiple receivers over
variable-characteristics band (short-wave 300bps AX-25).

This example just to remind L3 should work also on other links we
do not think of right now..

-Jari

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 19 Oct 2001 12:17:07 -0700

Hello Jari,

> do not think of right now..

Definitely.  Plus we have a lot of ideas about making Mobile IPv6
work with ad hoc wireless networks.  There, it's even more important
to avoid extraneous packets, and synchronizing the whole ad hoc
network to fit into the channelization requirements imposed at the
access router is ... well ... challenging to say the least.  That's
just another example -- I don't claim that we need to design the
ad hoc network before getting Mobile IPv6 finished.

Current cellular networks are not necessarily representative of
future wireless networks, and thus they should to dictate the
requirements for Mobile IPv6 over the expected lifetime of IPv6.
At the same time, we have to view existing wireless systems as
a major immediate customer for our specifications, and thus make
sure things do work well.

Regards,
Charlie P.

---

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

oops... typo below corrected, in case it isn't clear ...  (darn)

"Charles E. Perkins" wrote:

          ............

> future wireless networks, and thus they should to dictate the
         should be  --------------------> ^^^^^^^^^ "should not"

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 19 Oct 2001 14:39:52 -0500

Hi Charlie,

> ad hoc network before getting Mobile IPv6 finished.

Well, mipv6 already allows generating extraneous packets.
I have a feeling that we  are getting into a religious debate
instead of a logical or an engineering one.

> sure things do work well.

Honestly, I think that there is enough and rough consensus already, why don't
we move ahead?
Kind regards,

--
Behcet

---

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

> can be both bandwidth and time.

   I specifically asked for an example on a shared media,
   with better than best effort QoS, and in particular
   suitable for real time traffic. The quoted note was
   an abbreviated form of that question.

   Also: header compression/suppression and layer two
   blocking mitigates many of the bandwidth issues,
   and does it for far more than just binding updates.

	    Mike

---

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

> requirements for Mobile IPv6 over the expected lifetime of IPv6.

   Right. They'll be a lot faster, and thus not care
   very much about piggybacking any more than my home
   802.11 network cares. Yet another reason to not
   engineer unmodular designs into MIPv6.

		      Mike

---

From: "Jari T. Malinen" <[email-masked]>
Date: Fri, 19 Oct 2001 13:49:39 -0700

>    an abbreviated form of that question.

So you are saying best effort shared links should be disregarded?
What if the traffic is mostly control traffic and one wants to
maximize throughput over a narrow-band best effort shared link?

>    and does it for far more than just binding updates.

HC is not going to be available/solve these for legacy L2s and
not necessarily all future L2s either. There are media with collision
detection vs. collision avoidance schemes, too. Also, latency savings
could be of importance, e.g., with high-power links, L1 switching times
may be an issue on some legacy links (non-QSK RF). Just to give
a counter-example that there is variance in design parameters
below L3.

Also, speaking of modularity with piggybacking, the IPv6 extension
header structure seems to be designed to be natural for piggybacking,
in order to run separate protocols in a modular way over the same
packets. To be consistent, disallowing piggybacking has implications
over Mobile IPv6. No variable length packets, extensions, or upper layer,
would be tolerated, since such a link is not a fully-capable IPv6 link
and this has to be communicated to the endpoints, e.g. usin some QoS
signaling. I do not see why just disabling piggybacking over such a
link is not an option.

-Jari

---

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

> So you are saying best effort shared links should be disregarded?

   Where did I imply that? I'd like to see an example
   for a situation that I think we can all agree would
   benefit if it were achievable. Thus far, nobody's 
   come up with a link layer/techology where it actually
   would be useful in that situation.

 > maximize throughput over a narrow-band best effort shared link?

   It should implement L2 header compression.

 > not necessarily all future L2s either. 

   If this is the case, then it obviously doesn't much
   matter for that L2 because binding updates are an
   extremely small percentage of overall traffic. Even
   less when you consider that not all BU's would be
   piggyback candidates.

 > packets.

   I have never claimed that the extension headers
   are modular; some are, some aren't.

	Mike

---

From: "Jari T. Malinen" <[email-masked]>
Date: Fri, 19 Oct 2001 14:47:16 -0700

>    would be useful in that situation.

HC or not, removing piggybacking increases the number of separate
packets sent. If this is a non-issue for all links, narrowband
wireless included, I guess I just must trust you on this :)

-Jari

---

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

Jari T. Malinen writes:
 > packets sent.

   Not necessarily. Use of L2 blocking -- as with
   DOCSIS concatenation -- allows two IP datagrams
   to be sent in one MAC frame.

	 Mike

---

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

>    to be sent in one MAC frame.

See, you agree that concatenation, such as piggybacking, is a good
thing.
Welcome home,

Cedric.