Subject: Re: [mobile-ip] (CONCLUSION/DISAGREE) Design team recommendation: New recommendation on piggybacking

From: Francis Dupont <[email-masked]>
Date: Fri, 01 Mar 2002 11:07:50 +0100

2. DISCUSSION
   
   Message  Sndr Rcvr ViaHA AddIPscOK RepIPscOK  HAprot  Pig
   
   RR 3/BU   MN   CN    No    Yes       Yes        No    Yes
   RR 4/BA   CN   MN    No    Yes       Yes        No    Yes

=> can one interpret this as a possibility to protect by IPsec
(with all the RepIPscOk considerations about authorization, ...)
a BU/BA exchange between a MN and a CN without RR?

   2) RepIPsecOK=Yes for all the BU/BA messages means that they
       too should be protocols or ports.

=> CLARIFICATION: protocols == final next headers?

       This check has to be done by the MIPv6 code, as the
       IPsec layers on both ends can't consider a protocol to be
       both final and non-final.
   
=> I don't understand what can be a non-final protocol
(or does protocol stand for next header value)?
BTW to be final or non-final is an essential property, i.e.
a "protocol" can not be both.

   - RR and BR/BU/BA is implemented using a separate IP protocol
      type value.
   
=> ISSUE: is this protocol final or non-final.
I DISAGREE if this protocol is non-final (this doesn't work for
IPsec selectors).

   3. RECOMMENDATIONS
   
   The design team recommends the following:
   
   R1. A Separate protocol and/or port should be used for the BR
        message, all RR messages, BU message and BA message.  This
        will allow - but not mandate - the use of current IPsec
        selectors in protecting BUs to the CN and HA, and RR
        messages via the HA. The value of next protocol = none
        must be supported by all MIPv6 compliant nodes in these
        messages.
   
=> CONCLUSION/DISAGREE: this recommendation is too ambiguous
about the nature of the "protocol": final or non-final.

        There is also other potential use of the bits, e.g.
        selecting some variants of stronger BU authorization
        methods, but these are not discussed here.
   
=> ISSUE: where/when variants of stronger BU authorization methods
will be allowed (note that all the examples I know don't need
the bits)

   R3. The above two recommendations should be placed in the
        MIPv6 RFC. This would allow us to quickly proceed to RFC
        status by bypassing controversial content, have as simple
        RFC and implementations as possible, but still allow
        functionality like piggybacking to be specified without
        interoperability concerns, and used by all nodes who
        support it.
   
=> ISSUE: what will be the level of "requirement" for piggy-backing?
(AGREE with a MAY (and any NOT :-), DISAGREE with SHOULD/MUST)

        We recommend that such as an RFC for piggybacking be
        produced immediately.

=> I can propose the IPv6 payload header document (:-).
                                                  ^^^^

   R5. At a future time, IF IPsec selectors can be extended in
        some manner

=> I've noted the IF is BIG. Don't expect to see multi-protocol
IPsec (and what ever) selectors soon.
   
Regards

[email-masked]

---

From: Jari Arkko <[email-masked]>
Date: Fri, 01 Mar 2002 12:43:49 +0200

> a BU/BA exchange between a MN and a CN without RR?

Indeed, RepIPsecOK=Yes means that in theory you could
use only Ipsec for that purpose without RR. We actually
didn't take much stand on whether we should allow that
or, just analyzed the requirements for BU/BA formats
based on the possibility of doing so.

Actually, I think we should make the RR mandatory in the
base RFC and postpone the IPsec-only discussion to another
RFC just to save time.

> => CLARIFICATION: protocols == final next headers?

Well... I was thinking that the regular (base RFC)
case would be that they'd have a next hdr field but
that would be set to NO_NXTHDR. In my understanding
of RFC 2401 this would classify it as a final
for purposes of IPsec processing.

> (AGREE with a MAY (and any NOT :-), DISAGREE with SHOULD/MUST)

MAY.

> IPsec (and what ever) selectors soon.

I agree. 

Jari

---

From: Francis Dupont <[email-masked]>
Date: Fri, 01 Mar 2002 13:33:53 +0100

Indeed, RepIPsecOK=Yes means that in theory you could
   use only Ipsec for that purpose without RR.

=> this is why I've cited this part of the table and used the
term "interpret".

   We actually
   
=> so you have no official answer to my question nor to a similar
issue about BU/BA with the HA (aka Home Registration).

   base RFC

=> you shan't save time this way because you shall get strong objections...

   and postpone the IPsec-only discussion to another
   RFC just to save time.
   
=> to save time you need something with the good level of specifications
(too much (i.e. make RR mandatory) shall waste time, not enough (i.e.
ambiguous RR recommendations which are not interoperable) shan't help).

   
=> For IPsec selector stuffs only the final "protocol" matters and
in this case it is "NO_NXTHDR". This was discussed in many mails
in the last two years...

   I agree. 
   
=> so you should understand that you can't get both IPsec and
piggy-backing!

Thanks

PS: to leave the door open for alternative (to RR) highly secured
modes for BU/BA exchanges solves both the issue for anybody who
wants to use IPsec/AAA/... and the issue of the protection
of HRs (they will be magically (i.e. by an unspecified way) protected,
of course this works only if the magic is allowed).
And this is easy to do: specify the security requirements and
make RR mandatory when nothing else provides the required security.
You only need a statement beginning with an uppercase IF...