Subject: RE: [issue9] Message format

From: <[email-masked]>
Date: Mon, 9 Jun 2003 16:22:58 +0300

Hi,

Thank you for your comments. See my comments below.

> -----Original Message-----
> From: ext Alper Yegin [mailto:[email-masked]]
> Sent: 07 June, 2003 03:05
> To: Forsberg Dan (NRC/Helsinki); [email-masked]
> Subject: Re: [issue9] Message format
> 
> 
> 
> > 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.

Why do you want to change this? The size of the header is not an issue, but why to make it bigger if there is no reason for that.

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

You mean 32bits for AVP flags and 32bits for AVP Length? The AVP length can't be bigger than the whole message length! Currently both fields are 16bit.

Why do you want to change this? See my comment above.

If we can maintain the compatibility with for example Diameter, let's do so. Otherwise we have to specify all AVPs in the PANA doc. Even if we want to specify them all in the PANA doc, I don't get the point.

Are you against Diameter compatibility? If so, why?

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

The current message formatting section is using R(equest) bit, because it reflects better to the message names and Diameter.

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

How about using Result-Code AVP? In Failure case, more information could be delivered (see Diameter spec.).

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

Ok.

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

What about multihoming, MIP, and site local addresses in IPv6? Does PaC create another session?

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

See my comment above. I see the Session-Id as the static identifier for the PANA session.

> 
> 
> 9.3.13  PANA-Termination-Request
> 
>    PANA-Termination-Request is sent by PaC to PAA.
> 
> Alper:>>> I think both can send this message.

ok, that's true.

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

What's the scope of the number space? I guess it's not good way to specify something and then later change the numbers.. or does other specs do so?

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

OctetString is definition of the type not the content. You think we should change the type?

> 
> 
> 9.4.2  MAC AVP
> 
>    The MAC AVP (Code <TBD>) is of type OctetString.
> 
> Alper:>>> We need to specify the content here.

The content is specified in section 4.1.5 "Message Authentication Code". Do we need something else?

     "The MAC AVP (Code <TBD>) is of type OctetString. The content 
     is specified in section 4.1.5."

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

Can you give me a reference to NDP protocol? I don't remember your comment about it.

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

How about this:

   "Session-Id AVP has an opaque data field, which is assigned by the
   PAA.  The Session-ID AVP MAY use Diameter [DIAMETER] message
   formatting and it MUST be maintained during the lifetime of a PANA
   session."

- Dan

> Alper

---

From: Alper Yegin <[email-masked]>
Date: Mon, 09 Jun 2003 18:22:38 -0700

Hi Dan,

> Why do you want to change this? The size of the header is not an issue, but
> why to make it bigger if there is no reason for that.

I meant to say 16 bits each, not 32. Sorry.

Currently flags have only 8 bits (too few) and message type has 24 bits (too
many, we ar not going to define 2^24 AVPs).I can see us quickly running out
of flags if we keep it 8 bits only.

>> 9.2  AVP Header

Same here, I meant to say 16bits each. Same reasons.

> 
> You mean 32bits for AVP flags and 32bits for AVP Length? The AVP length can't
> be bigger than the whole message length! Currently both fields are 16bit.
> 
> If we can maintain the compatibility with for example Diameter, let's do so.
> Otherwise we have to specify all AVPs in the PANA doc. Even if we want to
> specify them all in the PANA doc, I don't get the point.
> 

> The current message formatting section is using R(equest) bit, because it
> reflects better to the message names and Diameter.

OK, then the ACK bits in other messages should be removed too.
PANA_failure_answer, PANA-reauth_answer, etc. have ACK bits.

> delivered (see Diameter spec.).

OK, that makes sense to me. PANA-result message can carry Result-code AVP.

> What about multihoming, MIP, and site local addresses in IPv6? Does PaC create

What are the issues that we need to handle there? Can we not handle them
with the mechanism I outlined?

> See my comment above. I see the Session-Id as the static identifier for the

OK, I don't think I'm saying anything to conflict with that.

> What's the scope of the number space? I guess it's not good way to specify
> something and then later change the numbers.. or does other specs do so?

The numbers are tentative until they are officially assigned by the IANA.
If you look at other I-Ds, you'll see these type of numbers are set in the
document even before they are officially assigned by IANA.

> OctetString is definition of the type not the content. You think we should

No, I'm not suggesting any change. This is just additional text that does
not conflict with yours.

>    is specified in section 4.1.5."

That still does not provide the (much needed) message format (order and size
of fields).

> Can you give me a reference to NDP protocol? I don't remember your comment

This is in reference to IPv6 Neighbor Discovery Protocol, RFC 2461.

For example:

4.6.1.  Source/Target Link-layer Address

      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      |    Length     |    Link-Layer Address ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Link-Layer Address
                     The variable length link-layer address.

                     The content and format of this field (including
                     byte and bit ordering) is expected to be specified
                     in specific documents that describe how IPv6
                     operates over different link layers.  For instance,
                     [IPv6-ETHER].

>  formatting and it MUST be maintained during the lifetime of a PANA

Looks good to me.

Thanks.

Alper