Subject: RE: [mobile-ip] Piggybacking - DT recommendation

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 12 Feb 2002 18:11:01 +0100

Phil, 

AGREE with the conclusion, DISAGREE with some 
of the earlier analysis but since I agree
with the conclusion there is no point in getting
into the analysis :) 

Hesham

  > -----Original Message-----
  > From: Phil Roberts [mailto:[email-masked]]
  > Sent: Tuesday, February 12, 2002 5:52 PM
  > To: [email-masked]'
  > Subject: [mobile-ip] Piggybacking - DT recommendation
  > 
  > 
  > 
  > Hello folks,
  > 
  >     We need to get closure on the Working Group's stance on
  > piggybacking of binding update messages.  Much of the
  > discussion last year was around the issue that doing so
  > generally meant that IPsec specifications and implementations
  > needed some modifications in order to protect BU messages that
  > were piggybacked in other messages.  Other discussions were
  > around the relative merits of piggybacking in terms of
  > performance of particular kinds of link layers, whether
  > beneficial or harmful.  Still other discussions were around
  > the complexity of implementing it in the receiver.
  > 
  >     This note is an attempt to summarize the pros and cons
  > of the various approaches and to give a design team
  > recommendation.  The summary is more difficult because
  > there was little agreement in the earlier discussions on
  > whether the asserted benefits were real.  In fact, it
  > doesn't seem there was agreement on ANY of the asserted
  > pros and cons below, except that it would be difficult to
  > add the function later.
  > 
  >     Jari documented the tradeoffs of using piggybacking
  > with IPSEC well in:
  > 
  > http://search.ietf.org/internet-drafts/draft-arkko-mipv6-bu-
  > security-01.txt
  > 
  > In Salt Lake City a set of options was put before the
  > working group.  The option to leave piggybacking in the
  > draft without comment on its merits was favored by no one.
  > The other options were as listed below.
  > 
  > I would like you to comment on each whether you AGREE,
  > DISAGREE, or CAN LIVE WITH the option.
  > 
  > 1. Specify that piggybacking of binding update messages not
  >    be used with MIP v6.
  > 
  > Pros: 
  >         - puts no constraints on using IPSEC to protect
  >           binding updates when possible
  > Cons: 
  >         - if the function is added later, some negotiation
  >           would be needed between the sender and receiver
  >           since all receivers would not be able to support
  >           it
  > 
  > 2. Specify that piggybacking always be an option.
  > 
  > Pros: 
  >         - allows some improvement in terms of throughput
  >           and latency that may be relevant on certain types
  >           of links
  > Cons: 
  >         - the improvements are only relevant on certain
  >           types of links and thus this is inclusion of
  >           functionality at layer 3 that is useful only for
  >           certain layer 2s
  >           
  >         - in cases where the functionality is detrimental
  >           on certain kinds of links, the receiver may be
  >           victimized when sent a piggybacked BU
  >           
  >         - need policy extensions to IPSEC (and
  >           corresponding implementation modifications) for
  >           those cases in which IPSEC is used to protect
  >           BUs.
  > 
  > 3. Specify that piggybacking is an option, but subject to
  >    negotiation between the two communicating nodes.
  > 
  > Pros:
  >         - may be able to eliminate the detrimental effects
  >           on stations on certain kinds of links
  > Cons:
  >         - requires some more specification of signalling on
  >           whether or not to use piggybacking and
  >           additional behavior in the mobile node
  > 
  > The DT has come to the following conclusions:
  > 
  > (a) For reasons of timing, we do not recommend extending
  >     IPsec specifications in any manner.  Therefore, we feel
  >     that approaches that rely on better IPsec policy
  >     granularity should not be considered.
  > 
  > (b) We recommend that when IPsec protection is used, it is
  >     always used in *addition* to RR (or CGA) methods, not as
  >     a replacement. Thus RR (or CGA) methods would be used to
  >     protect MN - CN Route optimization procedures even when IPsec
  >     is used.
  > 
  > (c) Binding update messages for both HAs and CNs, binding
  >     acks, RR messaging, and CGA messaging are to be
  >     implemented as a new message set without the ability
  >     to piggyback data packets on those messages
  > 
  >     The basis on this recommendation is as follows:
  > 
  >       - The DT recognizes the potential benefits of piggybacking.
  >         (However, link layer techniques may exist to migitate
  >         the disadvantages of sending separate packets, to
  >         some extent.)
  > 
  >       - MIPv6 control packets are needed between MN - HA,
  >         MN - CN, and CN - HA - MN. There is no piggybacking
  >         policy granularity problem in the MN - CN case, due
  >         to recommendation (b). However, if piggybacking is
  >         used for the MN - HA case either IPsec specifications
  >         would have to be extended, or mechanisms similar to
  >         those introduced in draft 14 would have to be employed.
  > 
  >       - The deciding factor, however, seems to be the protection
  >         we need for RR (or to a smaller extent CGA) messages
  >         on the CN - HA - MN path. Given that the HA is acting
  >         only as a router in this case, it can not insert DOs
  >         in the RR packets since that violates fundamental
  >         assumptions needed e.g. for Path MTU discovery, and
  >         draft 14 mechanisms wouldn't be able to provide the
  >         necessary encryption anyway. Therefore, it seems necessary
  >         to provide ESP-like functionality in any case for the MNs
  >         and HAs. Based on this, it would make sense to use the same
  >         mechanism also for BU protection.
  > 
  >       - It seems very useful to be able to use IPsec ESP (with
  >         manual keying) for protecting the RR control packets
  >         on the HA-MN path. If the IPsec selectors can't be used
  >         to distinguish those packets from data traffic the effect
  >         might be that lots of data packets (all that are tunneled
  >         through the HA) also become encrypted which would be a 
  >         source of performance concerns for limited MN devices.
  > 
  >       - Some BU authorization mechanisms, namely those based
  >         on Diffie-Hellman and/or CGA, may not fit IPv6 DOs.
  > 
  > 
  > Phil
  >

---

From: Vladislav Yasevich <[email-masked]>
Date: Thu, 21 Feb 2002 13:23:24 -0500

Hello

I've been trying to catch up with the flurry of
mail on this and other threads so forgive me if
this was asked and answered already...

From what I've see and read about MIPv6, it was
never designed to cater to any specifc link layer.
It made some optional privisions that would work
more optimally with some link layers.  So my question
is why are we trying to cater to specific link
layers that don't like piggibacking?

Did I misunderstand something???

Thanks
-vlad
++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		IPv6 Project Lead
Compaq Computer Corp.		
110 Spit Brook Rd ZK03-3/T07	Tel: (603) 884-1079
Nashua, NH 03062		Fax: (435) 514-6884