Subject: Re: [issue9] Message format

From: Alper Yegin <[email-masked]>
Date: Fri, 06 Jun 2003 17:04:46 -0700

> Dan Forsberg <[email-masked]> added the comment:
> 
> New version (c).
> Changes:
> - Session ID (sec. 9.4.9): Diameter format is MAY not MUST.
> - Device ID (sec 9.4.3): Device ID contains type field and
> data field in the AVP data part.
> - Unknown type for Device-Id and Protection-Capability AVPs
> (UNKNOWN 0).

Let's start driving these issues to conclusion.

Here are my comments on the message formating.

       0                   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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Version    |                 Message Length                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Flags      |                 Message Type                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Alper>>>: I think we can allocate 32 bits to flags, and another 32 bits to
message type. Even this is too many for message types, but I guess that's
ok.

      |                 Transmitted Sequence Number                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Received Sequence Number                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  AVPs ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-

9.2  AVP Header

       0                   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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   AVP Flags   |                  AVP Length                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Alper>>>: same here. 32 bits to both.

      |                         Vendor-Id (opt)                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Data ...
      +-+-+-+-+-+-+-+-+

9.3.3  PANA-Start-Request

   PANA-Start-Request is sent by PAA to PaC.  PAA sets the
   transmission sequence number to an initial random value.  The
   received sequence number is set to zero (0).

      PANA-Start-Request ::= < PANA-Header: <TBD> >
                    < Session-ID >
                    < Cookie >
                  * [ AVP ]

Alper>>>: I think we can talk about fast re-authentication after movement,
and this would impact the way we exchange session IDs. But we should handle
this under another issue. This is just a note, no feedback here.

9.3.6  PANA-Auth-Answer

   PANA-Auth-Answer is sent by PaC to PAA in response to
   PANA-Auth-Request.

      PANA-Auth-Answer ::= < PANA-Header: <TBD> >
                    < Session-ID >
                    < EAP-Payload >
                  * [ AVP ]
                0*1 < MAC >

Alper>>>: I think ACK bit is missing here.

9.3.7  PANA-Success-Request
9.3.9  PANA-Failure-Request

Alper>>>: I think we can combine these messages as "PANA-Result" and
differentiate using a flag - Success/Failure. How about that?

   PANA-Failure-Request is sent by PAA to PaC when PAA receives EAP
   Failure.

Alper>>> Let's just say "A PANA-Result message that has the F-flag set
indicates the result of the network access authorization request. If the
S-bit is set, it means that the PaC is authorized to access the network. If
the S-bit is not set, that means PaC's request is denied."

Alper>>> There are currently ongoing discussion on the EAP ML regarding how
EAP result and authorization results are tied/related to each other. Let's
keep EAP result and PANA result independent of each other for now, until EAP
WG mandates otherwise.

9.3.11  PANA-Reauth-Request

   PANA-Reauth-Request can be send both by PaC and PAA.

      PANA-Reauth-Request ::= < PANA-Header: <TBD> >
                    < Session-ID >
                0*1 [ Add-Device-ID ]
                0*1 [ Remove-Device-ID ]
                  * [ AVP ]
                0*1 < MAC >

Alper:>>> I don't think we need Add-device-ID and remove-device-ID AVPs in
the design. So far we have identified use for add device ID (when a DHCP
client gets an IP address and wants/needs to use IPsec for access control),
but not for remove-device-id. As for the former necessity, I think we can
just include device-id in the above message.

Alper:>>> We can assume one device ID is associated with one session at a
time. So, when the PaC does PANA with the PAA (before DHCP), the device id
can be set to the mac address. After successful PANA, it is only allowed to
use DHCP, so it does... Now it has an IP address, it can send a re-auth
mesage to change its device-id binding from mac address to its IP address.
Does this make sense?

9.3.13  PANA-Termination-Request

   PANA-Termination-Request is sent by PaC to PAA.

Alper:>>> I think both can send this message.

9.4.1  Cookie-AVP

   The Cookie AVP (Code <TBD>) is of type OctetString.

Alper:>>> Let's tentatively set the Code's here [so that at least
implementors can use them during interop testing...]

Alper:>>> should we say the data is opaque and the exact content is outside
the scope of this protocol.

9.4.2  MAC AVP

   The MAC AVP (Code <TBD>) is of type OctetString.

Alper:>>> We need to specify the content here.

9.4.3  Device-ID AVP

   The Device-ID AVP (Code <TBD>) is of type OctetString.  The first
   octet (8 bits) of the AVP Data contains the device type. Rest
   of the AVP data payload contains the device data. Possible device
   types.

      UNKNOWN                           0
      IPV6_ADDRESS                      1
      IPV4_ADDRESS                      2
      ETHERNET_ADDRESS                  3

       0                   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      |           Data...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Alper:>>> I had suggested following the lead of NDP protocol for specifying
how to represent spefic link-layer addresses. We should capture that in
here.

9.4.7  Add-Device-ID
9.4.8  Remove-Device-ID

Alper:>>>> I think we don't need these add/remove device-id avps.

9.4.9  Session-ID

   The Session-ID AVP MAY use the same format as defined in
   [DIAMETER].PAA chooses the session-id.

Alper:>>> "Session-ID AVP has an opaque data field. DIAMETER Session-ID may
be used in the data field of this AVP. Session-ID is assigned by the PAA .
It must be maintained during the lifetime of a PANA session."

Alper