Subject: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation]

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 12 Feb 2002 11:16:44 -0800

Hello folks,

I have a lot of comments on the piggybacking recommendation.

Phil Roberts wrote:

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

That is a very important point.  Regarding the "asserted"
benefits, I think it can be shown that piggybacking _always_
offers performance benefits to a compliant IPv6 implementation,
and that sometimes the benefits would enable important
applications (like voice) to work better.

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

DISAGREE.

> Pros:
>         - puts no constraints on using IPSEC to protect
>           binding updates when possible

With authentication data as part of the Binding Update, this
is not an issue.

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

AGREE.

Notably, for any IPv6 extension header, IPv6 is designed
to allow payload.  Thus, we would have to explicitly break
this part of the IPv6 design in order to disable the
inclusion of payload.

Also, please note that I do not suggest that payload MUST
accompany the Binding Update!  I only suggest that we have
to make room for implementations that wish to make use of
the additional performance improvement that is available
by this technique.  It does not make sense to me, to penalize
all future implementations, just because there are some
layer 2s for which the performance improvement is not large.

> 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

The first clause is also true for fragmentation, jumbo payload
option, and probably others which clearly do belong at layer 3.
Thus, the second clause is not a valid inference.

>         - in cases where the functionality is detrimental
>           on certain kinds of links, the receiver may be
>           victimized when sent a piggybacked BU

There are not any such links that correctly implement IPv6
MTU.  In fact, for any link that somehow has used up the
entire capacity of the link, the issue is transmission of
the Binding Update in any form, not along with payload.
Otherwise, what kind of "victimization" was intended to be
suggested here?

>         - need policy extensions to IPSEC (and
>           corresponding implementation modifications) for
>           those cases in which IPSEC is used to protect
>           BUs.

The complete answer about how to use IPsec is going to take more
effort than we can muster in the near term.  Such effort SHOULD
take into account the particular needs of Mobile IPv6 BSAs,
anyway.  I think that we should NOT go back to using only AH,
especially because AH itself is likely to be deprecated in
the future.  This is not to say that AH should be disallowed --
indeed, it SHOULD be allowed!  Indeed, any source node that
wants to use AH should be encouraged to do so, and right now
that would mean not including payload data to avoid selector
problems.  This would be easiest when we put the Binding Update
into a new extension header type.

> 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

I think there is little to be gained by negotiation.
Any relevant negotiation should probably be done by
particular applications -- or, perhaps as part of specific
QoS negotiations.  For such applications, we could
indicate that payloads should not be accompanied by
Binding Updates, but that would amount to some higher-level
protocol negotiation at the node, and API controlling the
operation of the Binding Cache.  It does not mean a layer-3
negotiation.

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

AGREE.

I think we should not focus on IPsec problems at this time.

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

If there is a way to pre-recognize IPsec support between MN and CN
that is useful for authenticating Binding Updates, then there is no
point to do RR.  I think we should keep IPsec as a future option,
but with the intention of revisiting it after the future of AH is
better known, and after we get finished with the base Mobile IPv6
specification.

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

DISAGREE.

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

Typically, the home agent doesn't have any data to send to the
mobile node.  If this is a problem, then we can make the appropriate
restriction!

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

I do not think there is any need for the HA to insert such options.
The HA can use ESP on packets sent to the mobile node, whether or
not they have Binding Updates.  If it is desired to have ESP only
for packets that have Binding Updates, then we can have a different
extension type (not Destination Option), as has been suggested
already for Binding Updates, and which I think is a good idea.

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

This is not at all a problem, since the authentication data is
available in a suboption to the Binding Update itself.  Furthermore,
I am mainly concerned about using Binding Update with data.  If
a return routability test enables creation of a Binding Cache entry,
and if we can use Binding Updates to update existing Binding Cache
entries, then only the initial creation and periodic update will
be affected.  These particular packets may not have such a strong
need for timeliness as a generic Binding Update that would be sent
along with streaming or real-time data.

I can certainly imagine that a mobile node will have pre-established
(even manual) security associations with certain correspondent nodes
for which it does not want to undergo RR establishment of the
relevant Binding Security Association.  We have to make Mobile IPv6
work well in this case too, in addition to making the scalable
solution (e.g., RR) work well.

>       - Some BU authorization mechanisms, namely those based
>         on Diffie-Hellman and/or CGA, may not fit IPv6 DOs.

As noted, I agree that we should have a different extension header
type; however, this is not at all a determining factor about whether
we should allow payload along with the new header type.  Besides
offering easier selection of security policy, a new header type
will allow longer data, perhaps including certificates, to be carried.

Regards,
Charlie P.

---

From: "Glenn Morrow"<[email-masked]>
Date: Wed, 13 Feb 2002 11:09:41 -0600

Charlie,

I agree with your TECHNICAL statement below; furthermore, I see conclusions
as being invalidated based upon your reasoning. 

regards,

Glenn

DISAGREE.

---

From: "Glenn Morrow"<[email-masked]>
Date: Wed, 13 Feb 2002 11:41:12 -0600

Sorry about jumping in but..

> 1. Since the current recommendation seems to be:
>    Mandate RR and optionally CGA on top later. 
>    And since it is recommended that RR does not
>    setup a BSA, where is the issue of piggybacking
>    if you use RR only? 
>    Something like BU3WAY runs the entire protocol
>    on ICMP, so you can't piggyback these meesages
>    anyway. Where is the issue?

Perhaps the no BSA thinking and under what exact circumstances needs to be
revisited or clarified as the exact scenario in terms of what the CN
supports and doesn't support. 

I personally see the work progressing towards the creation of another
"firewalls might or might not do filtering  poriah" which will lead to RO'd
MIP being blocked everywhere. Just as RPF checks are often turned on today
at places that are not the most optimal.

You certainly do point out the folly of trying to deal with each issue as a
separate task and you do show how they are sometimes related with your
reasoning, though.

> 
> 2. So far we've seen a concrete paper from Cedric
>    and yourself which upon discussion didn't not 
>    result in any significant advantage of piggybacking
>    the BU (please refer to the archives, thread:
>    'more on piggybacking'). So I really don't see 
>    why you're against this decision.
>    

It would certainly be beneficial to update the binding and send a TCP SYN at
the same time - perhaps during a handoff.  What more do you need? I fail to
see how someone could not see this advantage.

---

From: "Glenn Morrow"<[email-masked]>
Date: Wed, 13 Feb 2002 13:11:04 -0600

Again, people seem to be leading to another pariah and the BSA needs to at
least be clarified if not revisited entirely by both of the DTs, IMO. The
little blurbs given by the design teams aren't telling the whole story and
the ramifications of their conclusions.

> But again I fail to see why this is an 
> issue considering point 1 that I sent 
> earlier. This _is_ the current working 
> assumption that people agreed with. And it's
> a good one IMHO.
>

---

From: "Glenn Morrow"<[email-masked]>
Date: Thu, 14 Feb 2002 11:50:20 -0600

Erik,

We are human and I admit that this was not exactly politically correct but I
do think it was constructive criticism.

I do agree that we need to focus on the technical aspects at this point and
I have certainly tried to in my subsequent contributions to the list.

Thanks,

Glenn

> -----Original Message-----
> From: Erik Nordmark [mailto:[email-masked]]
> Sent: Thursday, February 14, 2002 11:17 AM
> To: Morrow, Glenn [RICH2:C330:EXCH]
> Cc: [email-masked]
> Subject: RE: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation]
> 
> 
> > 
> > I disagree with this conclusion and I find it very sad 
> indeed that the IETF
> > has knelt before the link layers. Especially when the link 
> layers won't even
> > do the route optimization as a mandate.  You might was well 
> move the MIP
> > work to one of the other SDO's if this kind of decision 
> making continues.
> > 
> > Very very sad indeed. Shame on the DT, IMHO.
> 
> > There is no technical merit to the DT's conclusion. As such 
> they need to
> > find some before a vote is done.
> 
> Glenn,
> 
> I think the above statements are neither fair, productive, 
> nor get us any
> closer to getting to rough consensus.
> 
> That said, the design team is trying to untangle the 
> relationships that
> involve at least the following factors:
>  - piggybacking or not
>  - how are BU/RR related message carried (using DOs or something else)
>  - using IPsec or something else to secure home registrations
>  - using IPsec (we don't know an alternative) to be able to 
> selectively
>    secure BU/RR messages between the HA and MN
>  - optional use of IPsec between MNs and CNs
> 
> We were hoping we could try to untangle the above by first 
> asking the chairs
> to see if there is any WG consensus around piggybacking.
> So far not many WG participants have commented on the issue 
> (but there is
> a fair amount of heat and no light).
> 
> So perhaps we need to tack the whole tangled mess above in 
> one fell swoop.
> Would that make more sense to you?
> 
>   Erik
> 
>

---

From: "Glenn Morrow"<[email-masked]>
Date: Thu, 14 Feb 2002 14:10:53 -0600

My comments on the DT should not be constued as personal attacks on the
members. They should be constued as constructive criticism to the pressures
of external SDOs on them. 
 
I can't see how someone could not see the advantages of bundling at all
irrespective of the access and particular form of communication going on.

-----Original Message-----
From: Phil Roberts [mailto:[email-masked]]
Sent: Thursday, February 14, 2002 1:45 PM
To: [email-masked]'; Erik Nordmark; Charles E. Perkins
Subject: RE: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation]

seems to me that there is no true technical excuse for not allowing
piggybacking and I can only infer logically that some deal making has been
done 
 
Wow.
 
  in order to progress the standard on some sort of deadline self-imposed by
some conflicting external SDOs. This prompted my initial criticism in that I
wanted to remind people that this is the IETF and we are supposed to deal
with the IP problem space - not the least common denominator link layer. 
 
Just to play devil's advocate - isn't the need for piggybacking tied to a
particular kind of link-layer (low bandwidth but with enough
headroom to stick in a few more bytes)?  Just curious.

I hope you see this as constructive and not a bantor.  

That is difficult for some parts of your message. 

Thanks, 

Glenn 

> From: Erik Nordmark [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Thursday, February 14, 2002 11:50 AM 
> To: Charles E. Perkins 
> Cc: Erik Nordmark; [email-masked]; Morrow, Glenn 
> [RICH2:C330:EXCH] 
> Subject: Re: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] 
> 
> 
> 
> > I have tried to be very precise and technical in my discussion about 
> > piggybacking.  I have set out quite a few technical points (and 
> > logical points) that I had hoped would enable further discussion 
> > on the matter.  Maybe you are over-generalizing, but if you truly 
> > feel that my discussion was all heat and no light, then I have to 
> > object, and I very much want to ask you to take another look. 
> 
> Nobody has brought up any new points (well, except perhaps 
> Kempf's point 
> about i-mode using something akin to piggybacking but I don't know 
> if that is a link-layer type thing or an e2e thing) this time around. 
> 
> Thus there is no more light shining on the issue than there was 
> after the last round of discussions. 
> 
>   Erik 
> 
> 
>

---

From: "Glenn Morrow"<[email-masked]>
Date: Fri, 15 Feb 2002 09:40:42 -0600

Hesham,

There is no technical or logical argument to your point given. You are just
saying I think this is bad without giving any meat to the argument. 

I do not agree with you on this view. Network services are network services
and right now MIPv6 is not a network service in that the network does not
participate other than forwarding i.e. there is no LMM and there is no FMIP
in the MIPv6 spec. So since MIPv6 standalone is not a network service right
now, your points are invalid. 

Furthermore when we do get to the network service based forms of MIP
interacting with other network services, I think we will find that the same
security arrangements between the enpoints requesting these services and the
network will be used for all network based services.

Sometimes an endpoint will need just one service and sometimes it will need
more than one. Also sometimes the services need to know about each other and
work together. Bundling of these distinct functional PDUs will give us
modularity,flexibility and optimization.  

With these points in mind, I don't agree with you and it seems you are
trying to use out of scope arguments that may not be correct in order to
influence the current scope of MIPv6. I.e. I think NSIS might be a more
appropriate discussion area for your viewpoint at this time.

Thanks,

Glenn

> From: Hesham Soliman (ERA) [mailto:[email-masked]]
> Sent: Friday, February 15, 2002 5:40 AM
> To: Hesham Soliman (ERA); 'Erik Nordmark'; 'Charles E. Perkins'
> Cc: [email-masked]'; Morrow, Glenn [RICH2:C330:EXCH]
> => Can't disagree with that. I'd like to summarise
> my point(s) in a simple way though: 
> Carrying two different types of information in
> a single IP packet is (architecturally) not a good 
> idea. This is due to the fact that IP packets receive 
> different treatments by link layers, routers and
> end hosts, depending on the content of the packet. 
> Hence placing 2 different sets of information (each 
> requiring a different treatment) in one 
> packet is likely to break some policies. 
> We've seen some examples already: IPsec and 
> L2s with Qos assurances. We could also see
> more in future. So the point is, the foundation 
> for this idea is not correct. 
> 
> RFC2460 doesn't say anything about this, 
> but I wouldn't expect it to. I think it's 
> up to us to realise this. 
> 
> I hope this helps the discussion.
> 
> Hesham
>

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 15 Feb 2002 17:06:16 +0100

There is no technical or logical argument to your point given. You are just saying I think this is bad without giving any meat to the argument. 

=> Good feedback (no I'm not serious).

I do not agree with you on this view. Network services are network services and right now MIPv6 is not a network service in that the network does not participate other than forwarding i.e. there is no LMM and there is no FMIP in the MIPv6 spec. So since MIPv6 standalone is not a network service right now, your points are invalid. 

=>Glenn, What are you talking about ? Did you really
read anything below? I'm talking about this:

- Placing more than one payload in the packet, each
  requiring different level of QoS, security or any
  other handling, is a bad idea.

Who said anything about LMM or FMIP????

Hesham

---

From: "Glenn Morrow"<[email-masked]>
Date: Fri, 15 Feb 2002 11:16:19 -0600

Hesham,

Excuse me for misinterpreting and jumping to conclusions but technically why
is it a bad idea, especially when there is no checksum in the IPv6 header? I
don't see a problem with it.

> Sent: Friday, February 15, 2002 10:06 AM
> To: Morrow, Glenn [RICH2:C330:EXCH]; Hesham Soliman (ERA); 'Erik
> Nordmark'; 'Charles E. Perkins'
> Cc: [email-masked]'
> There is no technical or logical argument to your point 
> given. You are just saying I think this is bad without giving 
> any meat to the argument. 
> 
> I do not agree with you on this view. Network services are 
> network services and right now MIPv6 is not a network service 
> in that the network does not participate other than 
> forwarding i.e. there is no LMM and there is no FMIP in the 
> MIPv6 spec. So since MIPv6 standalone is not a network 
> service right now, your points are invalid. 
>

---

From: "Glenn Morrow"<[email-masked]>
Date: Sat, 16 Feb 2002 15:27:17 -0600

Yes.

---

From: "Glenn Morrow"<[email-masked]>
Date: Mon, 18 Feb 2002 10:18:31 -0600

I guess this was to the whole WG and people such as yourself.

Realistically it seems that existing implementations have a desire to use
IPSEC with the MIP. Also it seems that quite a few implementation actually
did implement piggybacking. 

So why don't we just use IPSEC and restrict the piggybacking. 

This seems like the fastest path to agreement, it also fits in well with the
whole wireline IPSEC story in that code is still reused. It also doesn't
sacrifice the advantages of piggybacking.

I honestly think the MIP option signaling should be protected by ESP
integrity at a minimum instead of the AH and piggybacking disallowed when
the credentials are different. 

This seems like a very reasonable way forward with as Charlie mentions the
caveat that work should continue to do piggybacking even when the
credentials are different. 

I still see or rather hope that the BSA vs RR only question is disjunct.

These are my thoughts on how it should end up at this particular point in
time. This also seems to be the most amicable for the existing
implementations and IPv6 stack size in general.

I am open to other thoughts though but I don't think we need to kill
piggybacking and the solutions should not assume that it is.

Thanks,
Glenn

> Sent: Monday, February 18, 2002 7:16 AM
> Cc: Erik Nordmark; Charles E. Perkins; [email-masked]
> > Actually there is something new - some proposed decisions 
> of the other DTs.
> > Apparently some have found that this proposed decison is 
> somehow being use
> > to say we can't do piggybacking.
> > 
> > I suggest that people may not understand exactly what this 
> reasoning is and
> > that the persons who believe in this excuse not to do 
> piggybacking detail,
> > with a precise and hopefully concise example, the exact 
> scenario they are
> > thinking of. They need to answer the question of "why do 
> you need a BSA to
> > use piggybacking?".
> > 
> > I have also seen euphemisms such as "this makes me sick", 
> etc.. referenced
> > by IPv6 WG members to whom it is well known that they do 
> not see value in
> > MIP anyway much less RO'd MIP. While this could also be 
> seen as constructive
> > criticism, I believe or rather hope, that the persons on 
> this mail list do
> > see value in it and the "sick" reference refers to the 
> persons inability to
> > see value in MIP itself, let alone the piggybacking and 
> Route Optimization.
> > The fact that the security PDU portions of a binding are no longer
> > associated with IPSEC, allows piggybacking to work and 
> makes the technical
> > portion of the arguments against piggybacking false.
> > 
> > So it seems to me that there is no true technical excuse 
> for not allowing
> > done in order to progress the standard on some sort of 
> deadline self-imposed
> > by some conflicting external SDOs. This prompted my initial 
> criticism in
> > that I wanted to remind people that this is the IETF and we 
> are supposed to
> > deal with the IP problem space - not the least common 
> denominator link
> > layer.
> > 
> was the above sentence a question to me and Charlie (the "to" list) or
> to all of the WG?
> 
> I don't see the constructive propopsal you are making for how 
> to move forward.
> Could you clarify what it is?
> 
>   Erik
> 
>