Subject: [mobile-ip] Piggybacking - DT recommendation

From: Phil Roberts <[email-masked]>
Date: Tue, 12 Feb 2002 11:52:08 -0500

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: "Jean-Michel COMBES" <[email-masked]>
Date: Tue, 12 Feb 2002 18:28:19 +0100

Hi,

- conclusion (a)
AGREE
- conclusion (b)
DISAGREE : why do we need to add an other type of security (eg. RR, CGA)
when IPsec (which is a stronger security) is used ?
- conclusion (c)
CAN LIVE WITH

Comments are welcome (especially concerning conclusion (b) :-)

Regards

France Telecom R&D - DTL/SSR
Jean-Michel COMBES, Internet/Intranet Security
E-Mail : [email-masked]
Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19
PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214

[snip]

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 12 Feb 2002 11:17:35 -0800

Hi Phil,

>     protect MN - CN Route optimization procedures even when IPsec

DISAGREE strongly with this. In the first place, I dont 
understand why this is there in the Piggybacking 
recommendation. When there is an IPSec SA  between
an MN and CN (could have been created statically for 
all you know), there is no need to run either RR or
RR+CGA.

regards
Vijay

ps: When would I have static IPSec SA between MN and CN?
When I have download something from the PC sitting at my
home onto my laptop. (the laptop being my MN, Home PC 
being my CN with the Home Agent in my corporate network)

---

From: Michael Thomas <[email-masked]>
Date: Tue, 12 Feb 2002 11:30:29 -0800 (PST)

> all you know), there is no need to run either RR or

   This is not correct. Authentication != Authorization.
   Being able to positively identify an entity does
   not authorize use of a particular IP address unless
   there is explicit linkage between the security policy
   between the IP address and the identity. In
   general, there is no such linkage, nor should
   we expect any between MN and CN. HA/MN is a
   different story.

		Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 12 Feb 2002 11:35:02 -0800 (PST)

AGREE
 
 > 2. Specify that piggybacking always be an option.

   DISAGREE

 >    negotiation between the two communicating nodes.

   DISAGREE

   AGREE
 
 >     protect MN - CN Route optimization procedures even when IPsec

   AGREE except this is not necessary between MN/HA, IMO

   AGREE

			Mike

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 12 Feb 2002 11:45:00 -0800

>    we expect any between MN and CN. HA/MN is a

You took out the example I gave. In the example I gave, the
fact that I manually created the IPSec CA between my home
PC and my laptop is authorization enough. 

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 12 Feb 2002 12:05:15 -0800

> fact that I manually created the IPSec CA between my home
                                   ~~~~~~~~
> PC and my laptop is authorization enough.                                

IPSec SA.

sorry about that.

Vijay

---

From: "James Kempf" <[email-masked]>
Date: Tue, 12 Feb 2002 11:18:36 -0800

FWIW, DoCoMo uses signaling piggybacking on its current
i-mode network, for spectral efficiency on the radio link.
I don't know the particulars of how, but it is a data
point.

            jak

----- Original Message -----
From: "Phil Roberts" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, February 12, 2002 8:52 AM
Subject: [mobile-ip] Piggybacking - DT recommendation

>     Jari documented the tradeoffs of using piggybacking
http://search.ietf.org/internet-drafts/draft-arkko-mipv6-bu-security-01.
txt

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 12 Feb 2002 16:57:35 -0600

Hi Phil,
  Looking at the replies to this thread reminds me what happened last 
year, was it November?. Exactly the same set of people are for and 
against the conclusion of DT (BTW it goes without saying that I also AGREE).
  However the point is that Charlie's opinion is an important factor in 
this and I would have thought that DT first got his consent on it. So I 
respect Charlie's opinion and hereby ask the DT to consult with him and 
get him agree first.

Regards,

-- 
Behcet

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 12 Feb 2002 15:46:10 -0800

Hello Behcet,

Thanks for your consideration of my message about piggybacking,
and I appreciate that you want my opinion to be taken into account.
I see that you disagree with the conclusions I have tried to support
in my message, but I don't see where I have gone wrong.  Can you
say what it is that I have written that you disagree with?

Regards,
Charlie P.

---

From: "Jari Arkko" <[email-masked]>
Date: Wed, 13 Feb 2002 19:07:46 +0200

> all you know), there is no need to run either RR or

Apparently we disagree about the likelihood of having the kind
of private manual SAs that - I agree - would be sufficient for
authorization.

But let  me ask you a question to clarify your position.
Let's *not* discuss for the moment if SAs are sufficient.
But why do are you opposed to the in-addition recommendation?
Is it because of additional signaling or some other reason?
Implementation-wise, I would have thought it'd be easier if
you didn't need to know if you had IPsec at the bottom.

Jari

---

From: Cedric Westphal <[email-masked]>
Date: Wed, 13 Feb 2002 09:53:42 -0800

Phil,

>1. Specify that piggybacking of binding update messages not
DISAGREE.

I participated in a little analytical study that shows there is always a 
benefit to
piggybacking, especially with respect to jitter, it would be a shame to 
lose this
benefit.

CAN LIVE WITH

>          victimized when sent a piggybacked BU
This last point is not a fair characterization: I can come up with many 
links that
would be abused if piggybacking was NOT used, and the receiver severely 
bruised.
Such a statement can be written for any functionality, replace 
'piggybacked BU' with
your least favorite functionality. I hope this does not show a bias of 
the DT.

>   negotiation between the two communicating nodes.
CAN LIVE WITH, but seems convoluted and impractical to me.

>    to piggyback data packets on those messages
DISAGREE.  I think Charlie provided some good technical points wrt this.

Cheers,

Cedric.

>        the disadvantages of sending separate packets, to
AGREE with the benefits part. Parenthesis sounds speculative.

>        those introduced in draft 14 would have to be employed.
MN-HA piggybacking sounds like a strange idea to me.

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 13 Feb 2002 10:56:36 -0800

hi Jari,

> Is it because of additional signaling or some other reason?

Additional signaling, of course. If an IPSec SA were enough,
I wouldnt want to do RR messages, especially during a handoff.
This is a big gain (not having to do RR, whenever possible).

Also another reason why I objected was, this is a piggybacking
recommendation. Why does a piggybacking recommendation have
to say that IPSec SA would never be enough and should be used
always in addition to RR. Shouldnt we take that up separately?

Now something about the IPSec SA itself.

If the IPSec SA were created by AAA, PKI or some future
infrastructure method, I think it would be enough for
securing the BUs without having to do RR. And I also see
a static SA created between my MN and my friend's MN very
realistic and possible.

regards
Vijay

---

From: "James Kempf" <[email-masked]>
Date: Wed, 13 Feb 2002 11:52:37 -0800

DISAGREE. 

>           those cases in which IPSEC is used to protect

AGREE.

DISAGREE

>     granularity should not be considered.

DISAGREE. The tendency in the MIP group in the past 
has been to avoid facing up to cases where the properties of
wired networks and wireless networks are different enough
that changes are required to efficiently support  IP on 
wireless networks. I think this is another such case.

As I mentioned previously, DoCoMo uses piggybacking
to good effect in i-mode, that indicates to me that it
is likely to be useful. Without further analysis, of course,
it is hard to say how useful and whether the tradeoff
is worth it, but it is one implementation data point. It has 
been mentioned  before that Cedric and Charlie's draft 
(which I admit to not having read) also lists some possible 
benefits of piggypacking. Therefore, I think there is
enough uncertainty about this point to not take the
drastic action of prohibiting piggybacking.

If changes are required in IPsec, then I think we ought
to ask for them.

>     protect MN - CN Route optimization procedures even when IPsec

DISAGREE. Requring RR for BU security if the BU is between
the MN and an AR or LMM agent in the local foreign network
will have serious performance impact. Requiring just CGA or
something similar would probably have less impact. In any
case, the MN should be able to establish a BSA when it
enters the foreign network and use that to secure any routing
update signaling with entities in the foreign network.

>     acks, 

DISAGREE

> RR messaging, and 

CAN LIVE WITH. Since I think there is no other choice.

> CGA messaging are to be

DISAGREE. 

I believe a through study is needed of CGA or CGA-like
solution before we jump into standardizing anything here.

            jak

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 13 Feb 2002 15:55:23 -0600

Hello James,
  Sorry but I could not get the relationship between i-mode and BU 
piggbacking. i-mode is a technology implemented and deployed by DoCoMo 
in Japan where DoCoMo has market domination on circuit-switched 2G cell 
phone system called PDC and using IPv4. MIPv4 does have BU piggbacking.
  The term piggbacking is used in other contexts such as in TCP, TCP 
piggbacks data with ACKs, so that should also provide some justification 
for BU piggbacking in MIPv6?

Regards,

Behcet

---

From: "James Kempf" <[email-masked]>
Date: Wed, 13 Feb 2002 14:44:29 -0800

The i-mode network piggybacks signalling with data traffic,
specifically with HTTP. What I intended to say is that
this is one data point that piggybacking is useful for radio
networks. That's all I intended to say.

        jak

---

From: Francis Dupont <[email-masked]>
Date: Thu, 14 Feb 2002 01:05:28 +0100

We need to get closure on the Working Group's stance on
   piggybacking of binding update messages.

=> for quick comments before reading the 35 other messages of the thread!

       Jari documented the tradeoffs of using piggybacking with IPsec...
   
=> I wrote and presented at the last IETF a generalize multi-payload
proposal for IPv6 (draft-dupont-ipv6-payload-00.txt) in order to
get opinions from the IPv6 folk (they were no, kill that, I become sick,
etc). BTW I still wait for some help in order to produce a second version
of this draft. Jari's draft was written a week before so has still
Robert Elz' proposal in reference [13].

=> AGREE (you may not put two things in the same packet when policies
for the two things can be different. IPsec is just an example
of this basic problem).

=> DISAGREE

   Pros: 

=> DISAGREE: this argument only proves the piggy-backing "optimization"
should be done by the link-layer.

   Cons: 
             
=> AGREE

=> AGREE but this is true for any kind of policies, not only IPsec.

=> DISAGREE: this assumes the peers has the full knowledge of
applied policies to traffic between them.

   Cons:
   
=> AGREE (please apply KISS principle).

   
=> AGREE

=> note the BU recommendations are "RR" or "RR + CGA", not "RR" or "CGA".

=> 100% DISAGREE: IPsec protection with proper policies can provide
far better security than any RR/CGA mechanism.
(now I understand why I can smell of smoke :-)

=> AGREE (note I don't understand why there are other recommendations).

=> why manual keying?

=> AGREE: BUs, BAs, RR, etc, should be "IPsec selectable" so
have to be payloads (in the common IPv6 packet meaning).

I'll come back tomorrow on (b) in order to understand.

Regards

[email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 14 Feb 2002 18:28:48 +0100 (CET)

Jim,

> If changes are required in IPsec, then I think we ought

How long do you suggest we should delay MIPv6 while waiting for such changes
to IPsec specifications?

I think Jeff Schiller already pointed out (but I could misremember)
that MIPv6 BUs don't fit with the available IPsec selectors which would seem
like a hint that we shouldn't expect IPsec to change.
So I'm having a hard time seeing how to move forward at the moment.

> update signaling with entities in the foreign network.

I don't think the DT intended to make a statement about how LMM should
be secured but instead focus on how MIPv6 should be secured.
It might very well be that LMM has both different performance constraints
as well as the ability to rely on some infrastructure local to
an operator. So apart from the LMM concerns, do you still disagree with
the above?

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 14 Feb 2002 19:00:06 +0100 (CET)

Jim,

Do you know if this piggybacking is end-to-end in the i-mode network
i.e. the signalling is delivered to the http server?
Or do they just share the same packet over the radio link with
the signalling message being delivered to some other entity?

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 14 Feb 2002 19:42:59 +0100 (CET)

> always in addition to RR. Shouldnt we take that up separately?

I agree it would have been better to keep that separately.

> a static SA created between my MN and my friend's MN very

It depends on what authority you associate with the IPsec SA i.e.
the policy associated with it.

If your are associated with some certificate authority that you trust
and that CA signs a certificate for 
	attacks-r-us.example.com
(after verifying that such an entity in fact exists and is legit)
does that mean that a CN should accept BUs arriving over a SA
that was created using the above certificate?
Does it mean that the CN should accept it for the Home Address of my laptop?

Of course not.

So the HA-MN use of IPsec is easy because part of the configuration
on the HA (when using IKE a certificates in this example, which isn't required
in general) could be to associate the home address with a certificate.
This could be done by as part of the configuration of the relationship on the
HA i.e. 
certificate name [email-masked] can do BUs for 1:2:3::220:afff:fe8d:b2d6

And the same relationship can be manually created on a few select CNs,
but it doesn't scale doing this for a large number of CNs.

So this is the motivation for saying that in general IPsec need to be used
in addition to RR.

  Erik

---

From: "James Kempf" <[email-masked]>
Date: Thu, 14 Feb 2002 10:58:42 -0800

Erik,

> How long do you suggest we should delay MIPv6 while waiting for such
changes

If we don't start now, it will take even longer to get the change. I
don't
understand why we couldn't simply allow piggybacking
with the caveat that you shouldn't use it with IPSec, then start
working with the IPSec group to come up with a solution that will work.
The MN doesn't have to send the BU as part of an IPSec secured
TCP stream, it could send it separately.

> So I'm having a hard time seeing how to move forward at the moment.

Sorry, since I wasn't part of the DT, I'm not up on the specifics of
this. What is the problem with simply specifying that the BU header
is within the authenticated or encrypted part of the packet covered
by the AH or ESP header?

> an operator. So apart from the LMM concerns, do you still disagree
with

I can't see any problem with it in general, just with respect to LMM
solutions that depend on route optimization.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Thu, 14 Feb 2002 11:08:47 -0800

> the signalling message being delivered to some other entity?

The signaling is delivered to the i-mode server which is a proxy
that converts the HTTP message from the proprietary
TCP-like protocol that is optimized for PDC into
regular TCP. I don't know if the signaling is used by
the i-mode server or not, but it is certainly not used
by the IP network.

If you want, I can try to find out more details.

            jak

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 14 Feb 2002 11:30:56 -0800

Hello folks,

> TCP stream, it could send it separately.

I think this is a very realistic answer, which I fully support.
Since it provides what everyone wants, I think it is the
consensus-building approach, and should be endorsed by the
design team.

> is within the authenticated or encrypted part of the packet covered

If the payload requires a different security policy than the
Binding Update authentication, then the BU can include the
Binding Authentication Data suboption, and all is well.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 14 Feb 2002 11:46:17 -0800

Hello Francis,

First, I would like to see if you have responses to the
discussion points I raised on this recommendation.

> => for quick comments before reading the 35 other messages of the thread!

I am also stumbling under this burden.

> etc). 

There are crucial differences between the generalized approach,
and the existing approach:

- The existing approach does not introduce any new IPv6 features
  other than what is needed to process the specific Destination
  Option.  Approaches using IPv6 extension headers that specifically
  prevent piggybacking will, essentially, have to block this
  generally useful feature.

- Your point here is not against Binding Update + payload specifically,
  but against generalized multi-payloads.  The problems with multi-payloads
  are not particularly applicable to Binding Update + payload.  Thus,
  I think this counts as a straw-man argument.  However, I do agree
  that your points are valid otherwise, and that there is work that
  should eventually be done in order to have a multi-payload option.

- Binding Updates are NOT just any old piece of packet data.  They are
  crucial for correct operation of Mobile IPv6, which is a network-layer
  protocol.  Thus, they belong to be as part of IP processing, and that
  makes them into IP options, which by IPv6 design are quite amenable
  to being sent along with payload.

> for the two things can be different. IPsec is just an example

This really amounts to a statement that the security policies
may be different.  That problem is already solved by use of
the Binding Authentication Data suboption.

> should be done by the link-layer.

Since the nature of the improvements do not depend on the link-layer
(only the percentage improvement), I do not think this is a fair
characterization.

I hope this is enough to begin a small dialogue with you on the
mailing list.  Perhaps we can come to agreement.  Perhaps you will
agree that it is O.K. to allow some senders to do the piggybacking,
as long as we don't mandate it for all senders!  I will be interested
to also see your comments on my previous mail, if you have time to
make comments.

Regards,
Charlie P.

---

From: "Jean-Michel COMBES" <[email-masked]>
Date: Fri, 15 Feb 2002 12:22:26 +0100

Erik,

> -----Message d'origine-----
> De : [email-masked]
> [mailto:[email-masked]]De la part de Erik Nordmark
> Envoye : jeudi 14 fevrier 2002 18:29
> A : [email-masked]
> Cc : [email-masked]
> Objet : Re: [mobile-ip] Piggybacking - DT recommendation
>
>
> Jim,
>

JMC : just allocate a specific Header type value for BU/BAck and the IPsec
selector problem is solved (that will allow a more precise firewall policy
too) without changes in IPsec.

> an operator. So apart from the LMM concerns, do you still disagree with

Regards.

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Fri, 15 Feb 2002 12:43:49 +0100

AGREE

DISAGREE

CAN LIVE WITH

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Fri, 15 Feb 2002 18:37:39 +0100

> TCP stream, it could send it separately.

	To me, this seems to offer a workable compromise. If the major
trouble with piggybacking BU's is in the granularity of IPsec selectors,
so piggybacking when IPsec's in use gives trouble, -- why, let us allow 
optional piggybacking where there is no problem, and disallow them (for now) 
where we have no clear way forward?

	Best,
		Henrik

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 15 Feb 2002 09:52:08 -0800

Hello Henrik,

> where we have no clear way forward?

I basically agree with both of you, with the proviso that even with
an IPsec-secured TCP stream, one could include a Binding Update
by using the Binding Authentication Data suboption.

Regards,
Charlie P.

---

From: "Jari T. Malinen" <[email-masked]>
Date: Fri, 15 Feb 2002 17:46:46 -0800

Henrik Levkowetz wrote:
> > .. I don't

I would like to second this simple compromise. It would
solve the IPsec issue short term with no change requirement
to protocol specs other than possibly an implementation
note to MIPv6.

Once a policy rule is inserted for BUs, don't piggyback.
Existence of the rule can, e.g., be a per-HoA BCE
flag set when inserting the IPsec policy. It is then known
to the part of code deciding on piggybacking. This is one
of the simplest way, other ways exist, too.

BUs have a new extension header number to solve the
orthogonal-to-piggybacking problem of distinguishing
from non-MIPv6 DstHdr traffic.

There seem to be two threads on piggybacking, IPsec and L2.
I see above some first signs of progress towards a compromise
in the former. To me this is a new development compared to
discussions last fall.

BR,

-Jari M.

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 18 Feb 2002 14:09:57 +0100 (CET)

> TCP stream, it could send it separately.

I don't want to replay the arguments that have been made on the mailing
list on the subject of piggybacking, but I'm pretty sure this was discussed
in the past.

> this.

This was done in the MIP working group as part Jeff's concerns.
Either in his presentation or in email clarifying things later.

> What is the problem with simply specifying that the BU header

Even if you don't do piggybacking you still have an issue of selector
granularity - IPsec selectors don't operate on the content of
destination option headers (i.e. on what options are present).
Thus you couldn't express
	if this is a BU apply this IPsec processing
	if this is TCP to port 22 apply this IPsec processing
	etc
since the first rule, without any piggybacking, can't be expressed given
the selectors in RFC 2401.

> solutions that depend on route optimization.

OK

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 18 Feb 2002 14:11:19 +0100 (CET)

> If you want, I can try to find out more details.

If you have additional details you can share I'd be interested.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 18 Feb 2002 18:23:40 +0100 (CET)

> from non-MIPv6 DstHdr traffic.

Jari,

A clarifying question.
Are you assuming that the BU packets will use a new extension
header type (so that IPsec policies can tell them apart from other packets)
and that new extension header has the ability to also carry another
packet payload (such as a TCP packet)?

   Erik

---

From: "Jari T. Malinen" <[email-masked]>
Date: Mon, 18 Feb 2002 10:06:30 -0800

Erik,

> packet payload (such as a TCP packet)?

Yes. But with the strict restriction that use of such
extension header with a subsequent (e.g. final) header
could happen only if sender of BU/BAck/BR does not use
IPsec for protecting mobility signaling, i.e., there is
no policy for that. In all other cases this new protocol
would be the final one available as a selector component.

In the future, when selectors get extended to support
extensions with subsequent packet, minimal or no protocol
change would be needed, only relaxation of the above rule.
At least this is how I understood James's compromise
could be applied.

BR,

-Jari M

---

From: "David R. Oran" <[email-masked]>
Date: Mon, 18 Feb 2002 13:41:26 -0500

Please excuse this message from left field.

I've been reading all the email of people talking past each other, and
looked at some of the quantitative results posted on the benefits of
piggybacking.

It seems to me that you can have all the benefits, with none of the
tricky tradeoffs with security and processing semantics of piggybacked
BUs if instead of doing intra-packet piggybacking, we simply defined a
simple way to put two or more IP packets into one L2 frame, and hence
one radio frame transmission.

My reading of why piggybacking wins is because you avoid re-arbitrating
and re-scheduling the radio channel, not because one packet is all that
much smaller than two (with header compression and the two packets going
between the same pair of addresses, the two-packet header scheme might
be even shorter)!

The blocking approach is clearly MUCH more general, and even allows the
blocked packets to go to different places. I think it can be done
without even having an extra encapsulation header, as long as the L2
explicitly signals frame length to the IP layer, and there is a way to
let the peer know you are doing this at link establishment time. 

The only downside I can think of is if there is a requirement that the
two packets be received and processed together (i.e. they have semantic
or timing interdependencies). In some cases, at least in theory, I can
see that, but is this true for Binding Updates? I don't think so (but am
happy to be corrected).

Sorry for the interruption. Back to your regularly scheduled broadcast.

Dave.

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 18 Feb 2002 19:50:46 +0100 (CET)

> would be the final one available as a selector component.

Presumably both the B* part and the piggybacked payload should
be sent in the clear according to IPsec policy in order for
the piggybacking to be applied.

I think such an approach would solve the IPsec interaction issues
related to piggybacking.

The other main arguments against piggybacking seems to be
1. complexity in all the receivers in order to process piggybacked packets.
2. Issues where the receiver of the piggybacked packets might not want 
   piggybacking  e.g. due to channel or QoS concerns on the last few hops
   towards the receiver.

I think #1 can be handled by being able to describe the processing of
the piggybacked packet on the receiver succinctly.
The simplest seems to be that a packet containing
	IPv6 header [+ extension headers] + B* header + piggybacked payload
be effectively fed back into ip_input() as
	IPv6 header [+ extension headers] + piggybacked payload
after the B* part of the packet have been processed.

I don't know if there are any difficult details with such an approach.

But I don't have a good idea how to address #2 short of piggybacking
being negotiable.
I do observe that when using RR to secure the BU the 2a/2b packets sent from
the CN to the MN could contain a "piggybacking ok/notok" flag.

  Erik

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 18 Feb 2002 11:41:38 -0800

Hi Erik,

comment on the issue #2. (snipped all other text)

> the CN to the MN could contain a "piggybacking ok/notok" flag.

Piggybacking could be described generically as putting an extension
header 
(routing header, destination options) onto a payload. 

I am not sure what you mean by 'channel or QoS concerns'. I can read it 
two ways. 

a) The piggybacked packet could exceed the maximum MTU on the last few
hops
towards the receiver. 

b) The receiver has negotiated a very tight channel in which it is
allowed 
only a fixed number of bytes per packet/second. and the piggybacked
packet 
results in exceeding the allocated resouces.

For a), it sounds like a Path MTU issue. Basically you assume the sender
does not know a valid Path MTU, otherwise it wouldn't have piggybacked.
There I would say any link should adhere to IPv6 minimum recommendation.

For b), it seems like a special case of a) where QoS negotiation has
established a limit for packet size. In principle, if sender knows
this limit by means of Path MTU, it would not piggyback here either.
I would see these, especially b), to be more generic IPv6 issues.
This concerns all variable-length traffic over such channels or QoS
negotiated last hop(s).

Vijay

---

From: "James Kempf" <[email-masked]>
Date: Mon, 18 Feb 2002 15:52:51 -0800

Hi Dave,

> one radio frame transmission.

I think what you mean is two or more IP packets per scheduled packet
transmission slot. Radio L2 frame sizes vary, of course, but on most
cellular
systems they are on the order of 40 bytes. This would be just enough to
carry one uncompressed IPv6 header with no header options.

> between the same pair of addresses, the two-packet header scheme might

Don't know about the last point, but I agree that being able to schedule
more than one packet per packet transmission slot could potentially have
the same effect as piggybacking.

The problem is that this falls into the same category as Hesham's
suggestion that IP signaling be done over a separate signaling channel.
I don't believe it works that way today. One argument people have
expressed for
getting rid of piggybacking is: "It interferes with IPSec and Jeff
Schiller
has indicated that we should not expect IPSec to change to accommodate
Mobile IP in the near future (or possibly ever?, that wasn't clear)." If
changing IPSec in the near future is hard, then I'd venture to guess
that
changing the 3GPP or 3GPP2 MAC layers is probably nigh on impossible.

But certainly 3GPP and 3GPP2 are not the last cellular radio protocols
that will ever get designed and if we can ever get together a
comprehensive
set of recommendations to L2 designers about what makes a good radio
L2 for IP, this would be high among the recommendations.

            jak

---

From: "Jari Arkko" <[email-masked]>
Date: Tue, 19 Feb 2002 09:04:24 +0200

> carry one uncompressed IPv6 header with no header options.

Particularly with v6, there *has* to be header compression. I wonder
how many voice packets you could fit on 40 bytes with compression...
As far as changing 3GPP or 3GPP2 goes I too think it's hard but maybe
not *so* hard. There's for instance examples on how fast those folks have
adopted header compression when they have seen the benefits. Come
to think of it, maybe I should I ask my compression colleagues if they
have thought of putting multiple packets on a single frame...

Jari

---

From: Parviz Yegani <[email-masked]>
Date: Mon, 18 Feb 2002 23:56:49 -0800

Hi Jari/Jim,

Comments inline...

>have thought of putting multiple packets on a single frame...

In cellular, you don't want to send any header bytes over the air. It would 
eat up
capacity. For example, for a data rate of 14.4 Kbps a 4-byte header would cost
you slightly more than 11% of radio link capacity. So, the penalty is BIG!!
To avoid this situation you are forced to remove RTP/UDP/IP headers (total 
of 40 bytes)
all together when you send packets over the air. This can be accomplished 
by using
0-byte header compression schemes.

In 3GPP2, for example, there are two 0-byte header compression options: Header
Stripping and Generation or HSG (based on GEHCO) and LLA-ROHC which recently
reached an RFC status. HSG is already been adopted and LLA-ROHC in under 
consideration.
For both of these schemes you need to send update packets (eg, full header 
packets)
once a while when the transmitter and receiver go out of sync. Once both 
ends are in
sync then you can send IP packets over the air with no additional overhead. 
In this case,
the number of packets that can fit in a single L2 radio frame depends only 
on the packet
size. For short packets (less than 20 bytes) you can pack multiple packets 
in a single L2
radio frame.

-Parviz

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 19 Feb 2002 13:30:47 -0800

Hello,

I'll try to write more later.  But, I think that the two arguments as

> 1. complexity in all the receivers in order to process piggybacked packets.

The receivers are already supposed to implement everything that
is needed for this, just because of the way that IPv6 headers are
supposed to be processed.  Thus, this is no impediment, as you point
out later in your note.

>    piggybacking  e.g. due to channel or QoS concerns on the last few hops

QoS concerns should always be resolved by QoS negotiations.
Furthermore, channel reservations such as are envisioned by those
who are not in favor of piggybacking, should properly resolve issues
about assignations of microflows to various bearer channels, and
this would typically trigger the right kind of processing to send
Binding Updates correctly.

Regards,
Charlie P.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 19 Feb 2002 23:25:21 +0100 (CET)

> results in exceeding the allocated resouces.

I meant (b) mostly.

> This concerns all variable-length traffic over such channels or QoS

It's my understanding that the NSIS WG is at least looking into
signalling that isn't end-to-end i.e. the receiver might have done QoS
signalling one or a few hops into the network but not all the way through
the network.
Thus the sender wouldn't necessarily know this as part of some QoS signalling
mechanisms.
But it seems like all it would need to know is "don't piggyback to this 
destination" or perhaps "don't piggyback on packets to this destination
<IP, protocol, port>". The former is just one bit, but the latter requires
more knowledge and signalling.

  Erik

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 19 Feb 2002 16:15:55 -0800

hi Erik,

> more knowledge and signalling.

But isnt this again a generic IPv6 issue? IPv6 extension headers can
never be added onto IPv6 packets on such QoS negotiated links. The 
real issue seems to be the ability of such link layers to handle 
variable length IPv6 packets. Sorry for saying the same thing again 
(or am I missing something very obvious).

regards
Vijay

---

From: "James Kempf" <[email-masked]>
Date: Tue, 19 Feb 2002 17:55:31 -0800

Hi Jari,

Sorry, didn't mean to imply that there should be no header compression.
The point I was trying to make is 40 bytes isn't much. Header
compression is a MUST.

            jak

----- Original Message -----
From: "Jari Arkko" <[email-masked]>
To: "James Kempf" <[email-masked]>;
<[email-masked]>
Sent: Monday, February 18, 2002 11:04 PM
Subject: Re: [mobile-ip] Piggybacking - DT recommendation

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 21 Feb 2002 14:43:32 +0100 (CET)

> (or am I missing something very obvious).

It is generic in the sense that if there was a generic protocol or mechanism
for the IP layer or the applications using it to determine which
extension headers to add then such a generic protocol or mechanism
would need to at least think about this issue.
But there is no such generic protocol or mechanism right now, and
I don't know of any plans for one. SO this is not our problem.

If applications explicitly specify extension headers that cause problems
at the other end the application and/or app protocol would presumably
have a way to deal with that. So this is not our problem.

If somebody has a mechanism that, unknown to the application, causes
the IP packets to have other information piggybacked, then we have
a specific protocol to worry about and the "its the application's problem"
above doesn't apply. This is the case here.

So I don't think saying that the problem in theory exists elsewhere
is a good reason to not consider this particular practical instanciation
of the problem.

  Erik

---

From: Alexandru Petrescu <[email-masked]>
Date: 21 Feb 2002 15:05:54 +0100

Hi Erik,

I don't want to intrude too much into your discussion, but I see the
simple AH usage as a form of piggybacking that might fit your
definition above.  The application (web browser using TCP) is not
aware that someone has manually set an SA between this node and a web
server.

Alex

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 21 Feb 2002 16:11:48 +0100 (CET)

> aware that someone has manually set an SA between this node and a web

Agreed. This means there is another category that is similar to
the one I had about applications.

If the admin on H1 sets up an IPsec policy for packets to H2 it will
effect the size of packets sent to and received from H2 (the policies
better be symmeric).
Thus in this case the admin of H1 has some control and can presumably deal
with problems caused by this.

This is quite different than when H2 decides to use piggybacking for
packets sent to H1 - neither applications nor admin on H1 is aware or
can control this.

  Erik

---

From: Alexandru Petrescu <[email-masked]>
Date: 21 Feb 2002 16:43:59 +0100

> packets sent to H1 - neither applications nor admin on H1 is aware or

In the previous case I described with AH being piggybacked, the SA
could be set dynamically, right?  Using your notation, H2 is a web
client and decides to securely interogate H1 which is a web server.
H1 initially has no knowledge about H2, nor does it trust it.  Then H2
can still securely communicate with H1, relying on IKE.  H2 provokes
the dynamic creation of the SA on H1, in the same way that an MN would
provoke the creation of a binding cache entry on CN.

But, as you said, this only exposes that other mechanisms have the
same issue, and not necessarily that it's good to live with it.  I
don't know.  Or: I know, but I often change my mind.

Alex

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 21 Feb 2002 18:43:25 +0100 (CET)

> client and decides to securely interogate H1 which is a web server.

IPsec isn't guaranteed to work unless the policies are symmetrical
as far as I understand. The SAs can be created dynamically e.g. using IKE
which I think is what you are referring to.
I think implementations of IPsec (as opposed to the spec) allow 
the type of server you talk about where each connection will be
latched to a policy based on whether the SYN was secured or not.

> don't know.  Or: I know, but I often change my mind.

I think in the above case an IPsec aware application running with this
"allow secure or non-secure - latch in each connection" could of course
tell (using some IPsec specific API to ask about the resulting IPsec policy
for the connection). And in general, for security reasons, I think an
app with that policy would like to know.
So it still is a bit different than getting unsuspecting piggybacking.

  Erik