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

From: Francis Dupont <[email-masked]>
Date: Sun, 03 Mar 2002 15:37:17 +0100

Just because you have an IPsec SA, doesn't mean you
   are authorised to send the BU. It's an address
   ownership problem and that's why we need RR. 
   
=> I would not like to go backward in the Mobile IPv6 security issue,
so do you accept an IPsec SA with the proper authorization is
enough to protect the BU, yes or no? (i.e. do you agree with
I-D 00-15 or not about the security constraints?)

Regards

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Sun, 03 Mar 2002 15:52:21 +0100

It depends on what authority you associate with the IPsec SA i.e.
   the policy associated with it.
   
=> this does not justify the "MUST NOT" for IPsec alone which is BTW
a major step backward (Mobile IPv6 I-Ds had a MUST, IESG asked to
change it in a MAY).

   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
   
=> as we definitively disagree about what is a certificate I prefer to
avoid a new boring discussion. You just don't believe in a very common
use of IPsec based VPNs...

   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.
   
=> this scaling issue is true but still doesn't justify the implicit
"MUST NOT" for IPsec alone.

   So this is the motivation for saying that in general IPsec need to be used
   in addition to RR.
   
=> I *strongly* disagree, especially if the "in general" is replaced
by "always".

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sun, 03 Mar 2002 16:09:12 +0100

Francis Dupont wrote:
   
   > => for quick comments before reading the 35 other messages of the thread!
   
   I am also stumbling under this burden.
   
=> argh! The 35 moved in ~100...

   > => 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). 
   
   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.
   
=> this is obviously not true and the large number of answers against
the piggy-backing should show your view is not shared by everybody...

   - Your point here is not against Binding Update + payload specifically,
     but against generalized multi-payloads.

=> yes, if the L2 arguments show piggy-backing is good, they should
show that multi-payloads are good.

     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.
   
=> eventually be done? The strong consensus in the IPv6 WG was clearly
this is a very bad idea.

   - 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.
   
=> as control and data planes are not separated (i.e. signaling is online),
any pros or cons for piggy-backing can be translated in the same argument
for multi-payloads.

   >    1. Specify that piggybacking of binding update messages not
   >       be used with MIP v6.
   > 
   > => 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).
   
   This really amounts to a statement that the security policies
   may be different.

=> I didn't write security policies, but any policies.

   That problem is already solved by use of
   the Binding Authentication Data suboption.
   
=> not if you'd like to keep the possibility to use IPsec
for BU protection. The option to solve the piggy-backing & IPsec
interference by dropping IPsec is *not* admissible.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sun, 03 Mar 2002 16:36:16 +0100

2. IPSec
    > 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.
   
    There seem to be two separate authorization checks that are needed 
    before accepting a binding update:
    (a) Check that the sender is authorized to use the HoA

=> this should be easy.

    (b) Check that the sender is authorized to the the CoA
   
=> I *strongly* disagree because what is needed in (b) is the
authorization to use a CoA, not to use this CoA. BTW strong
authorization to use a transient address is near infeasible
and if we want to mandate your (b) we should before forbid
IPsec based VPNs with mobile nodes (in fact nomadic nodes,
aka "road warriors").

    As far as I can see, an IPsec SA established using, for example,
    X.509 certificates with IP addresses (not DNS names) in them is 
    perfectly adequate for checking HoA authorization.

=> until DNSSEC is widely available, IMHO we should avoid to use
certificates without addresses. BTW for MN-CN SA establishment
there is no reason to use something else than HoA for IKE message
transport, in identities (both phases 1 & 2) and in certificates.

    It's not so good for checking CoA authorization, because at the time
   the certificate is issued you don't know what CoA the node is going
   to be using.
   
=> another reason is you don't want to do the whole thing for each
hand-off. The problem is you ask for the wrong authorization.

    My current view is that:
    - you have to do RR for the CoA in all cases;

=> obviously an overkilling!

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sun, 03 Mar 2002 17:48:10 +0100

> 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)?
   
   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.
   
=> I can see a real problem for the same "protocol" to be
both final and not-final.

   In the future, when selectors get extended to support

=> when == never (IPsec is already too complex).

   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.
   
=> James' compromise is a good idea but this detail has to be fixed.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sun, 03 Mar 2002 17:53:43 +0100

... 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...
   
=> this is explicitely suggested in my IPv6 payload header I-Ds
and the first one was announced in the ROHC list (do you think
I should announce the new version again in the ROHC list?)

Thanks

PS: for me ROHC is the only place at the IETF where this can be done,
link-layers are not in our scope...

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 4 Mar 2002 05:21:19 +0100

=> The main advantage of multi-payload over
piggybacking is that it avoids the IPsec
issues. But it doesn't address any of the QoS
problems. 
My earlier note was misunderstood and
assumed to be only relevant to certain link
layers. Whereas it is relevant for any link along
the way. David Oran has clearly explained
this. 

  > link-layers are not in our scope...

=> It's _not_ just a link layer issue. If you
piggyback a BU (that requires higher priority
forwarding by intermediate routers) over your 
web traffic (low priority), how can we (magically?)
set the TOS field?? 
Not all systems assume e2e QoS signalling (none
is deployed today), and even if e2e signalling
was to be deployed, I don't know if there is 
an e2e protocol that says 'do not piggyback
the BU' to a CN. 

I'm probably answering your email and a few
earlier ones in one email :). I know you agree
with some of these points.

Hesham

PS: Sorry if I don't reply quickly, I'm not reading
email everyday this week.