Subject: [Monami6] New layout for BID option

From: Martti Kuparinen <[email-masked]>
Date: Fri, 17 Mar 2006 13:29:12 +0200

Hi,

Currently (in MCoA rev 05) BUs sent to CNs can't contain multiple CoAs because
the CN can't authenticate all the CoAs. Therefore I'd like to propose changes to
the BID option. Here's the new layout:

===============================================================================

                      1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |   Type = TBD  |     Length    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Binding Unique ID (BID)   |  Priority     |B|  Reserved   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
       |         Home Nonce Index      |     Care-of Nonce Index       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                         Authenticator                         |
       +                                                               +
       |                                                               |
       +---------------------------------------------------------------+

   Figure 1: BID Sub-Option

   Type

      Type value for Binding Unique Identifier will be assigned later.

   Length

      The Length field defines the total length of the Binding Unique
      Identifier sub-option.

      When the mobile node is sending the Binding Update to its home agent
      the nonce indices and the authenticator MUST NOT be included and the
      length field is set to 4.

      When the Mobile Node is sending the Binding Update to a correspondent
      node the nonce indices and the authenticator MUST be included and the
      length field is set to 16.

...

   Home Nonce Index

      The Home Nonce Index field tells the correspondent node which nonce
      value to use when producing the home keygen token.

   Care-of Nonce Index

      The Care-of Nonce Index field is ignored in requests to delete a
      binding.  Otherwise, it tells the correspondent node which nonce
      value to use when producing the care-of keygen token.

   Authenticator

      The Authenticator is calculated as the Binding Authorization Data
      option's Authenticator field as specified in Mobile IPv6 [2] chapter
      6.2.7.

===============================================================================

With this new layout we can send the following packets and the receiver is still
able to check the security settings even if we send multiple CoA inside a single BU:

+----------+-------------+------+-------------+------+
| BU (H=1) | BID (LEN=4) | ACoA | BID (LEN=4) | ACoA |
+----------+-------------+------+-------------+------+

+----------+--------------+--------+--------------+-------+----------------+
| BU (H=0) | BID (LEN=16) | ACoA | | BID (LEN=16) | Nonce | Bind Auth Data |
+----------+--------------+--------+--------------+-------+----------------+

Comments/opinions please...

Martti

_______________________________________________
Monami6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/monami6

---

From: Martti Kuparinen <[email-masked]>
Date: Fri, 17 Mar 2006 13:39:49 +0200

> the BID option. Here's the new layout:

The previous example was wrong (missing ACoA). It should have been:

+----------+--------------+------+--------------+------+-------+-----------+
| BU (H=0) | BID (LEN=16) | ACoA | BID (LEN=16) | ACoA | Nonce | Auth Data |
+----------+--------------+------+--------------+------+-------+-----------+

Martti

---

From: Martti Kuparinen <[email-masked]>
Date: Fri, 17 Mar 2006 15:02:33 +0200

> the BID option. Here's the new layout:

Some background and motivation for my proposal...

Problems with the current draft
-------------------------------
1. The current draft is suitable for home registration with multiple CoAs.
   The Binding Authorization Data is not used with home registration so
   there's no need to validate each CoA.

2. The current draft is not suitable for correspondent registration when
   multiple CoAs need to be registered in a single BU.

   - The nonce indices and authentization data is needed by the CN to verify
     each CoA.

   - One option could be to include Binding Authorization Data option for
     for each CoA included in the BU. However, legacy MIPv6 CN supports only
     one Binding Authorization Data per IP packet and it must be the last
     option (as defined in RFC 3775). Multiple Binding Authorization Data
     options will trigger the packet to be silently discarded by the CN.

   - The MN needs to carry authorization data for each CoA but it can't be
     included as multiple authorization data options because this is not
     supported by RFC 3775 CNs.

Solution
--------
- We must carry authorization data for each CoA in the BU.

- The authorization data is included inside BID option itself as proposed
  in the original mail.

---

From: Heikki Mahkonen <[email-masked]>
Date: Fri, 17 Mar 2006 16:23:08 +0200

Hi,

> Problems with the current draft

==> I also want to remind that when the binding authorization data is 
added into the BID option it requires the most minimal changes to the 
MCoA draft. Reqarding to the mail sent by Tero Kauppinen where he raised 
the question about communication with CNs only supporting the RFC 3775 
functionality there might be a reason to add also additionl CoAs into 
the corresponding BID options or specify a new type value for the 
additional ACoA options (as stated by Tero). I think that in the 
implementation point of view, the simplest way is to add CoAs into the 
BID option but this would also require more changes to the MCoA draft. 
Therefore, if it is desired to minimize the changes required to the MCoA 
draft the solution would be to specify a new option type for the 
additional CoAs. Anyway, I think that what is expected is that the MN 
must be able to register atleast one of the CoAs with CNs only 
supporting the RFC 3775 functionality even when it decides to send all 
the CoAs in a single BU message.

Best regards,

Heikki Mahkonen

---

From: Martti Kuparinen <[email-masked]>
Date: Mon, 20 Mar 2006 11:25:22 +0200

Hi again,

After thinking more about this and discussing with my co-workers Heikki and Tero
I think it's best if the care-of address could be specified inside the BID
option so there's no need to use multiple (RFC 3775) Alternate Care-of Address
options which could cause problems with legacy nodes. In other words, with this
new option layout there can be only one legacy ACoA option in the BU.

If the mobile node wants to register multiple CoAs it should include one CoA "in
the old way" (RFC 3775 ACoA or srcaddr) and the additional CoAs (and the
matching nonces and authenticator) within one BID option.

Here's the updated proposal:

                             1                   2                   3
        |     Binding Unique ID (BID)   |  Priority     |C|A| Reserved  |
        +                        Care-of Address                        +

   Length

      The Length field defines the total length of the Binding Unique
      Identifier sub-option. Possible values are 4, 20 and 36 depending
      what parts of the Binding Unique Identifier are included.

      The length field is set to 4 if no Care-of Address nor Authenticator
      fields are included.

      The length field is set to 20 if only the Care-of Address field is
      included.

      The length field is set to 36 if both Care-of Address and Authenticator
      fields are included.

   Alternate Care-of Address (C) flag

      The mobile node sets this flag when it wants to include an alternate
      care-of address to be used together with the given Binding Unique ID.

   Authenticator (A) flag

      The mobile node sets this flag when the nonce indices and the
      authenticator for the care-of address is included.

      When the mobile node is sending the Binding Update to its home agent
      the nonce indices and the authenticator MUST NOT be included and this
      flag MUST NOT be set.

      When the Mobile Node is sending the Binding Update to a correspondent
      node and the Care-of Address field is included, the nonce indices and
      the authenticator MUST be included and this flag MUST be set.

   Reserved

      6 bits Reserved field. Reserved field must be set with all 0.

   Care-of Address

       The care-of address to use instead of the IP packet's source address or
       Alternatate Care-of Address option even if such an option exists. The
       Nonce Indices and the Authenticator are linked to this address.

   Home Nonce Index

   Care-of Nonce Index

   Authenticator

---

From: Martti Kuparinen <[email-masked]>
Date: Mon, 20 Mar 2006 11:26:54 +0200

Here are some possible scenarios and how they're handled with my latest layout
proposal...

BU to HA
========

Multiple BIDs with ACoA (without BID for ACoA)
----------------------------------------------
BU + BID(ID=1, C=1, A=0, CoA=X) + BID(ID=2, C=1, A=0, CoA=Y) + ACoA

The BID-aware HA will create the following bindings:
- HoA, ACoA, BID=0
- HoA, X, BID=1
- HoA, Y, BID=2

The legacy HA simple skips the unknown BIDs and create this binding:
- HoA, ACoA

Multiple BIDs with ACoA (with BID for ACoA)
-------------------------------------------
BU + BID(ID=1, C=1, A=0, CoA=X) + BID(ID=2, C=1, A=0, CoA=Y) +
     BID(ID=9, C=0, A=0) + ACoA

The BID-aware HA will create the following bindings:
- HoA, ACoA, BID=9
- HoA, X, BID=1
- HoA, Y, BID=2

The legacy HA simple skips the unknown BIDs and create this binding:
- HoA, ACoA

Multiple BIDs without ACoA (without BID for srcaddr)
----------------------------------------------------
BU + BID(ID=1, C=1, A=0, CoA=X) + BID(ID=2, C=1, A=0, CoA=Y)

The BID-aware HA will create the following bindings:
- HoA, srcaddr, BID=0
- HoA, X, BID=1
- HoA, Y, BID=2

The legacy HA simple skips the unknown BIDs and create this binding:
- HoA, srcaddr

Multiple BIDs without ACoA (with BID for srcaddr)
-------------------------------------------------
BU + BID(ID=1, C=1, A=0, CoA=X) + BID(ID=2, C=1, A=0, CoA=Y) +
     BID(ID=9, C=0, A=0)

The BID-aware HA will create the following bindings:
- HoA, srcaddr, BID=9
- HoA, X, BID=1
- HoA, Y, BID=2

The legacy HA simple skips the unknown BIDs and create this binding:
- HoA, srcaddr

*********************************************************************

BU to CN
========
(BAD = RFC 3775's Binding Authorization Data option)

Multiple BIDs with ACoA (without BID for ACoA)
----------------------------------------------
BU + BID(ID=1, C=1, A=1, CoA=X, Auth=XXX) + ... + ACoA + Nonce + BAD

The BID-aware CN will create the following bindings:
- HoA, ACoA, BID=0
- HoA, X, BID=1
- HoA, Y, BID=2

The legacy CN simple skips the unknown BIDs and create this binding:
- HoA, ACoA

Multiple BIDs with ACoA (with BID for ACoA)
--------------------------------------------
BU + BID(ID=1, C=1, A=1, CoA=X, Auth=XXX) + ... +
   + BID(ID=9, C=0, A=0) + ACoA + Nonce + BAD

The BID-aware CN will create the following bindings:
- HoA, ACoA, BID=9
- HoA, X, BID=1
- HoA, Y, BID=2

The legacy CN simple skips the unknown BIDs and create this binding:
- HoA, ACoA

Multiple BIDs without ACoA (without BID for srcaddr)
----------------------------------------------------
BU + BID(ID=1, C=1, A=1, CoA=X, Auth=XXX) + ... + Nonce + BAD

The BID-aware CN will create the following bindings:
- HoA, srcaddr, BID=0
- HoA, X, BID=1
- HoA, Y, BID=2

The legacy CN simple skips the unknown BIDs and create this binding:
- HoA, srcaddr

Multiple BIDs without ACoA (with BID for srcaddr)
-------------------------------------------------
BU + BID(ID=1, C=1, A=1, CoA=X, Auth=XXX) + ... +
   + BID(ID=9, C=0, A=0) + Nonce + BAD

The BID-aware CN will create the following bindings:
- HoA, srcaddr, BID=9
- HoA, X, BID=1
- HoA, Y, BID=2

The legacy CN simple skips the unknown BIDs and create this binding:
- HoA, srcaddr

---

From: Ken Nagami <[email-masked]>
Date: Tue, 21 Mar 2006 03:18:31 +0900

Hi Martti and all,

I think it has two type of procedure to authenticate messages.
1) One CoA has one authenticator (your proposal)
2) One message has one authenticator even if it has multiple CoA.

I think second option is enough and simple.
Second option also authenticate all Mobility Header include multiple CoA.

So, authenticator need not be added to each BID option.

How do you think?

Ken Nagami

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 21 Mar 2006 21:48:32 +0900

Hi Martti

> Problems with the current draft

Ok, i missed to think the RO case for bulk registration.
Thanks for pointing this out.

>      supported by RFC 3775 CNs.

This discussion is valid, however some concern..(see below)

> - The authorization data is included inside BID option itself as  

If a MN stores multiple authenticator for multiple CoAs,
1. the size of BID option gets longer (No fragmentation for MH)..
     The nonce index and authenticator is not needed for home  
registration.
2. I'm not sure whether this can optimize something...

Your proposal can provide bulk-registration to CN.
However, I prefer simple extension for MCoA registration.
We can limit the bulk registration only to home registration and do  
separate registration to CNs.
It depends on how many people is interested in this feature for CN  
registration (by RR).

regards,
ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 21 Mar 2006 21:50:39 +0900

Hi Heikki

On 2006/03/17, at 23:23, Heikki Mahkonen wrote:

> ==> I also want to remind that when the binding authorization data  
> is added into the BID option it requires the most minimal changes  
> to the MCoA draft. Reqarding to the mail sent by Tero Kauppinen  
> where he raised the question about communication with CNs only  
> supporting the RFC 3775 functionality there might be a reason to  
> add also additionl CoAs into the corresponding BID options or  
> specify a new type value for the additional ACoA options (as stated  
> by Tero). I think that in the implementation point of view, the  
> simplest way is to add CoAs into the BID option but this would also  
> require more changes to the MCoA draft. Therefore, if it is desired  
> to minimize the changes required to the MCoA draft the solution  
> would be to specify a new option type for the additional CoAs.  
> Anyway, I think that what is expected is that the MN must be able  
> to register atleast one of the CoAs with CNs only supporting the  
> RFC 3775 functionality even when it decides to send all the CoAs in  
> a single BU message.

agree
A new CoA option for bulk-registration sounds better in terms of  
backward compatibility.

ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 21 Mar 2006 21:52:40 +0900

Hi Martti

Thanks for proposing changes.
One of concern is the size of BID option.
The CoA and RR info are only useful for CN  registration.

I want to keep the size of BID option small and define a new CoA  
option which may store RR info.

what do you think?
ryuji

On 2006/03/20, at 18:25, Martti Kuparinen wrote:

>                                         |   Type = TBD  |      
> Length    |
>         +                        Care-of  
> Address                        +
>         |                          
> Authenticator                         |

---

From: Martti Kuparinen <[email-masked]>
Date: Tue, 21 Mar 2006 15:21:12 +0200

> It depends on how many people is interested in this feature for CN 

We would like to see this as the mobile node can effectively create bindings for
all the CoAs with a single BU. This would minimize the signalling overhead
(possibly on slow links).

Martti

---

From: Martti Kuparinen <[email-masked]>
Date: Tue, 21 Mar 2006 15:21:16 +0200

> The CoA and RR info are only useful for CN  registration.

And that's why the MN can send the BID option in three different sizes (see my
description about the Length field). The BID option would be smaller for home
registration and larger for CN registration.

> I want to keep the size of BID option small and define a new CoA  option
> which may store RR info.

I think we can optimize the packet size carrying the BU if we embed the CoAs
into BID option. In this case the BID would be 16 bytes larger but we can leave
out the ACoA option (and possible padding before it).

Please note that I'm _not_ suggesting we use a fixed size BID option as that
would waste bandwidth with HA registration.

Martti

---

From: Martti Kuparinen <[email-masked]>
Date: Tue, 21 Mar 2006 15:21:20 +0200

> Second option also authenticate all Mobility Header include multiple CoA.

I was exchanging emails with Jari Arkko (one of the RFC 3775 authors) and he
said every CoA should be verified unless they were previously verified (that is,
the CN still has valid nonce indices).

I got the impression that not verifying all CoA would be against design
principles of the original MIPv6 spec...

Martti

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 21 Mar 2006 22:42:07 +0900

Hi Martti

> registration and larger for CN registration.

ah, i missed this point.

> out the ACoA option (and possible padding before it).

:-)
In a separate registration, does BID option get smaller not to  
include CoA?

> would waste bandwidth with HA registration.

ok

ryuji

---

From: Ken Nagami <[email-masked]>
Date: Wed, 22 Mar 2006 01:30:17 +0900

Hi Martti,

>principles of the original MIPv6 spec...

I understand every CoA should be verified.
But the nonces and authenticator in your proposed message format are only used
for CN registration.
So, I think it is better way to separate those infomation from this option.

How do you think?

Ken Nagami

                              1                   2                   3

---

From: Martti Kuparinen <[email-masked]>
Date: Wed, 22 Mar 2006 09:43:35 +0200

Ryuji Wakikawa wrote:

> In a separate registration, does BID option get smaller not to  include
> CoA?

When making a single registration (either home or correspondent) the
BID could be only 6 bytes and it's only used to tell the binding ID for the CoA
(either the srcaddr field or the ACoA option).

Martti

---

From: Martti Kuparinen <[email-masked]>
Date: Wed, 22 Mar 2006 10:43:57 +0200

Ken Nagami wrote:

> But the nonces and authenticator in your proposed message format are
> only used for CN registration.

Could we have two different BID options, one for HA and one for CN?

Home Binding Unique Identifier sub-option (HBID)
------------------------------------------------

                             1                   2                   3
        |     Binding Unique ID (BID)   |  Priority     |C|  Reserved   |

Here the Care-of Address is optional, i.e. Length is either 4 or 20. The
C flags also (in addition to the Length field) identifies existence of the
Care-of Address field.

If C==0 then the Care-of Address to register is taken from srcaddr or ACoA
option is it exists.

If C==1 then the Care-of Address to register is taken from Care-of Address field.

Correspondent Binding Unique Identifier sub-option (CBID)
---------------------------------------------------------

                             1                   2                   3
        |     Binding Unique ID (BID)   |  Priority     |C|  Reserved   |

Here the {Care-of Address, Nonce, Authenticator} fields are optional, i.e. the
Length is either 4 or 36. The C flags also (in addition to the Length field)
identifies the existence of the Care-of Address, Nonces and Authenticator
fields. If the Care-of Address is specified then the Nonce Indices and the
Authenticator are required.

If C==0 then the Care-of Address to register is taken from srcaddr or ACoA
option is it exists. The mandatory Binding Authorization Data is calculated from
the following RFC 3775 Nonce Indices option.

If C==1 then the Care-of Address to register is taken from Care-of Address
field. CoA verification is done with the Nonces and Authenticator found is the
same CBID option. This of course assumes we have already done CoTI/CoT for the
CoA we want to register.

---

From: Martti Kuparinen <[email-masked]>
Date: Wed, 29 Mar 2006 09:58:03 +0300

> Could we have two different BID options, one for HA and one for CN?

Could we also an option for BA which looks like this:

                             1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                        |   Type = TBD  |     Length    |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     Binding Unique ID (BID)   |  Status       |    Reserved   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        ...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     Binding Unique ID (BID)   |  Status       |    Reserved   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

There can be 1-N BIDs and their corresponding status codes embedded inside this
BA option so the HA/CN can acknowledge all BIDs with a single BA.

Purpose of this new BA option is to allow the BU receiver (either HA or CN) to
tell the MN which BIDs were successfully registered and which failed.

In the current draft it's all-or-nothing, that the BA tells everything is okay
or some error happened but there's no way to tell which CoA/BID pair failed.

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 29 Mar 2006 16:10:15 +0900

good point. but I want to think this more, since the error processing  
goes complicated.

ryuji

On 2006/03/29, at 15:58, Martti Kuparinen wrote:

>>                              1                    
>> 2                   3
>>                              1                    
>> 2                   3