Subject: Second shot on message formatting.

From: <[email-masked]>
Date: Wed, 7 May 2003 12:32:02 +0300

Hi,

Since there is not much progress, let me give you the second shot for the message formatting :).

Changes:
 - Removed Application-Id field from the header for 
   now (not enough support for this or Diameter compatibility).
 - Added PANA-Failure-Request/Answer messages (was missing 
   in the previous version).
 - Merged PANA-Disconnect-Request/Answer and 
   PANA-Revocation-Request/Answer messages to 
   PANA-Termination-Request/Answer messages. This is because
   the messages were similar to each other and contain the 
   Result-Code AVP, which can be used to differentiate 
   disconnect and revocation.

Br,
- Dan
 <<draft-ietf-pana-pana-00-sec9b.txt>>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 8 May 2003 13:47:42 -0700

Hi Dan,

Removing Application-Id works fine with me.

Please see my further comments in line.

>  <<draft-ietf-pana-pana-00-sec9b.txt>> 

Content-Description: draft-ietf-pana-pana-00-sec9b.txt
> 9  Message Format
> 
>    This section defines message formats for PANA protocol.  
> 
> 
> 9.1  PANA Header
> 
>    A summary of the PANA header format is shown below.  The fields are
>    transmitted in network byte order.
> 
>        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                  |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                 Transmitted Sequence Number                   |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                 Received Sequence Number                      |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |  AVPs ...
>       +-+-+-+-+-+-+-+-+-+-+-+-+-
> 
>    Version
> 
>       This Version field MUST be set to 1 to indicate PANA Version 1.
> 
>    Message Length
> 
>       The Message Length field is three octets and indicates the
>       length of the PANA message including the header fields.
> 
>    Flags
> 
>       The Flags field is eight bits.  The following bits are assigned:
> 
>        0 1 2 3 4 5 6 7
>       +-+-+-+-+-+-+-+-+
>       |R r r r F r r r|
>       +-+-+-+-+-+-+-+-+

As we are going to deviate from using the exact Diameter message format, 
there might be no reason to reserve  bits 1-3.  So I'd suggest:

        0 1 2 3 4 5 6 7
       +-+-+-+-+-+-+-+-+
       |R F r r r r r r|
       +-+-+-+-+-+-+-+-+

> 
>          R(equest)   
> 
>                      - If set, the message is a request. If cleared,
>                        the message is an answer.
> 
>          F(inish)    
>                      - F-flag in the PANA header indicates if this was
>                        the final authentication from sender's
>                        perspective.  If PAA enables two separate
>                        authentication, it should not set F-flag in the
>                        PANA_success or PANA_failure message after the
>                        first EAP method.
> 
>          r(eserved)  
> 
>                      - these flag bits are reserved for future use,
>                        and MUST be set to zero, and ignored by the
>                        receiver.
> 
> 
>    Message Type
> 
>       The Message Type field is three octets, and is used in order to
>       communicate the message type with the message.  The 24-bit
>       address space is managed by IANA.
> 
>    Transmitted Sequence Number
> 
>       The Transmitted Sequence Number field contains the monotonically
>       increasing 32 bit sequence number that the message sender
>       increments every time a new packet is sent.
> 
>    Received Sequence Number
> 
>       The Received Sequence Number field contains the 32 bit
>       transmitted sequence number that the peer has last received.
> 
>    AVPs
> 
>       AVPs are a method of encapsulating information relevant to the
>       PANA message.  See section <TBD> for more information on 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                   |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                         Vendor-Id (opt)                       |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |    Data ...
>       +-+-+-+-+-+-+-+-+
> 
> 
>    AVP Code
> 
>       The AVP Code, combined with the Vendor-Id field, identifies the
>       attribute uniquely. AVP numbers are allocated by IANA.
> 
>    AVP Flags
> 
>       The AVP Flags field is eight bits.  The following bits are
>       assigned:
> 
>        0 1 2 3 4 5 6 7
>       +-+-+-+-+-+-+-+-+
>       |V M r r r r r r|
>       +-+-+-+-+-+-+-+-+
> 
>          M(andatory) 
> 
>                      - The 'M' Bit, known as the Mandatory bit,
> 	               indicates whether support of the AVP is
> 	               required.
> 
>          V(endor)    
> 
>                      - The 'V' bit, known as the Vendor-Specific bit,
>                        indicates whether the optional Vendor-ID field
>                        is present in the AVP header.
> 
>          r(eserved)  
> 
>                      - these flag bits are reserved for future use,
>                        and MUST be set to zero, and ignored by the
>                        receiver.
> 
>    AVP Length
> 
>       The AVP Length field is three octets, and indicates the number
>       of octets in this AVP including the AVP Code, AVP Length, AVP
>       Flags, and the AVP data.
> 
>    Vendor-Id
> 
>       The Vendor-ID field is present if the 'V' bit is set in the AVP
>       Flags field. The optional four-octet Vendor-ID field contains
>       the uniquely assigned <TBD> id value, encoded in network byte
>       order.  Any vendor wishing to implement a vendor-specific PANA
>       AVP MUST use their own Vendor-ID along with their privately
>       managed AVP address space, guaranteeing that they will not
>       collide with any other vendor's vendor-specific AVP(s), nor with
>       future IETF applications.
> 
>    Data
> 
>       The Data field is zero or more octets and contains information
>       specific to the Attribute. The format and length of the Data
>       field is determined by the AVP Code and AVP Length fields.
> 
> 
> 9.3  PANA Messages
> 
>    The following figure X lists all PANA messages defined in this
>    draft with the sender and receiver illustrated.
> 
>       Message       Direction: PaC---PAA
>       ----------------------------------
>       PANA-Discover            -------->  
> 
>       PANA-Start-Request       <--------
>       PANA-Start-Answer        -------->
> 
>       PANA-Auth-Request        <--------
>       PANA-Auth-Answer         -------->
> 
>       PANA-Success-Request     <--------
>       PANA-Success-Answer      -------->
> 
>       PANA-Failure-Request     <--------
>       PANA-Failure-Answer      -------->
> 
>       PANA-Reauth-Request      <------->
>       PANA-Reauth-Answer       <------->
> 
>       PANA-Termination-Request <------->
>       PANA-Termination-Answer  <------->
>   
>             Figure X.
> 
> 
> 9.3.1  Message specifications
> 
>    Every PANA Message defined MUST include a corresponding ABNF
>    [RFC2234] specification found in the [DIAMETER] spec.  PANA
>    Messages have different header format compared to Diameter.
>    Explain.. <TBD>.
> 
>    Example_message ::= < PANA-Header: <Message type>, 
>                                       [ACK], [FIN] >
>                   * [ AVP ]
> 
> 
> 9.3.2  PANA-Discover
> 
>    PANA-Discover message is used to discover the address of
>    PAA(s). Both sequence numbers in this message are set to zero
>    (0). If EP detects a new PaC and sends the PANA-Discover to PAA, it
>    MUST include the Device-ID of the PaC.
> 
>       PANA-PAA-Discover ::= < PANA-Header: <TBD> >
>                 0*1 < Device-ID >	
>                   * [ AVP ]

I'm not sure what the consensus on EP-PAA messaging in PANA draft.  If
PANA just specifies the required functionality for EP-PAA message
exchange instead of mandating the specific message format for the
exchange, specifying the use of PANA-Discover messages sent from PaC
to PAA is enough and the format can be:

        PANA-PAA-Discover ::= < PANA-Header: <TBD> >
                  * [ AVP ]

> 
> 
> 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 ]
> 
> 
> 9.3.4  PANA-Start-Answer
> 
>    PANA-Start-Answer (PSA) is sent by PaC to PAA in response to
>    PANA_start message.  The PANA_start message transmission sequence
>    number field is copied to the received sequence number field.  The
>    transmission sequence number is set to initial random value.
> 
>       PANA-Start-Answer ::= < PANA-Header: <TBD> >
>                     < Session-ID >
>                     < Cookie >
>                   * [ AVP ]
> 
> 
> 9.3.5  PANA-Auth-Request
> 
>    PANA-Auth-Request is sent by PAA to PaC.
> 
>       PANA-Auth-Request ::= < PANA-Header: <TBD> >
>                     < Session-ID >
>                     < EAP-Payload >
>                   * [ AVP ]
>                 0*1 < MAC >
> 
> 
> 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 >
> 
> 
> 9.3.7  PANA-Success-Request
> 
>    PANA-Success-Request is sent by PAA to PaC when PAA receives EAP
>    Success.
> 
>       PANA-Success-Request ::= < PANA-Header: <TBD>, [FIN] >
>                     < Session-ID >
>                     < Device-ID >
>                     < EAP-Payload >
>                     < Protection-Capability >
>                   * [ AVP ]
>                 0*1 < MAC >

Device-ID can be omitted when PANA runs over physically secure link.
On the oher hand, it is possible to use both L2 and L3 addresses as
device identifier when both L2 and L3 ciphers are required.  So I'd
suggest:

       PANA-Success-Request ::= < PANA-Header: <TBD>, ACK, [FIN] >
                     < Session-ID >
                 0*2 < Device-ID >
                   * [ AVP ]
                 0*1 < MAC >

> 
> 
> 9.3.8  PANA-Success-Answer
> 
>    PANA-Success-Answer is sent by PaC to PAA in response to
>    PANA-Success-Request.
> 
>       PANA-Success-Answer ::= < PANA-Header: <TBD>, ACK, [FIN] >
>                     < Session-ID >
>                     < Device-ID >
>                   * [ AVP ]
>                 0*1 < MAC >

For the same reason as for Success-Request, I'd suggest:

       PANA-Success-Answer ::= < PANA-Header: <TBD>, ACK, [FIN] >
                     < Session-ID >
                 0*2 < Device-ID >
                   * [ AVP ]
                 0*1 < MAC >

> 
> 
> 9.3.9  PANA-Failure-Request
> 
>    PANA-Failure-Request is sent by PAA to PaC when PAA receives EAP
>    Failure.
> 
>       PANA-Failure-Request ::= < PANA-Header: <TBD> >
>                     < Session-ID >
>                     < Device-ID >
>                     < EAP-Payload >
>                   * [ AVP ]
>                 0*1 < MAC >

I'm not sure why Device-ID is needed for this message.

> 
> 
> 9.3.10  PANA-Failure-Answer
> 
>    PANA-Failure-Answer is sent by PaC to PAA in response to
>    PANA-Failure-Request.
> 
>       PANA-Failure-Answer ::= < PANA-Header: <TBD>, ACK >
>                     < Session-ID >
>                     < Device-ID >
>                   * [ AVP ]
>                 0*1 < MAC >
> 

I'm not sure why Device-ID is needed for this message.

> 
> 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 >
> 
> 
> 9.3.12  PANA-Reauth-Answer
> 
>    PANA-Reauth-Answer is sent in response to PANA-Reauth-Request.
> 
>       PANA-Reauth-Answer ::= < PANA-Header: <TBD>, ACK >
>                     < Session-ID >
>                     < Device-ID >
>                   * [ AVP ]
>                 0*1 < MAC >
> 

I'm not sure why Device-ID is needed for this message.

> 
> 9.3.13  PANA-Termination-Request
> 
>    PANA-Termination-Request is sent by PaC to PAA.
> 
>       PANA-Disconnect-Request ::= < PANA-Header: <TBD> >
>                     < Session-ID >
>                     < Termination-Cause >
>                   * [ AVP ]
>                 0*1 < MAC >
> 
> 
> 9.3.14  PANA-Termination-Answer
> 
>    PANA-Termination-Answer is sent by PAA to PaC in response to
>    PANA-Termination-Request.
> 
>       PANA-Disconnect-Answer ::= < PANA-Header: <TBD>, ACK >
>                     < Session-ID >
>                   * [ AVP ]
>                 0*1 < MAC >
> 
> 
> 9.4  AVPs in PANA
> 
>    Some of the used AVPs are defined in this document and some of them
>    are defined in other documents like [DIAMETER].
> 
> 
> 9.4.1  Cookie-AVP
> 
>    The Cookie AVP (Code <TBD>) is of type OctetString.
> 
> 
> 9.4.2  MAC AVP
> 
>    The MAC AVP (Code <TBD>) is of type OctetString.
> 
> 
> 9.4.3  Device-ID AVP  
> 
>    The Device-ID AVP (Code <TBD>) is of type Grouped.
> 
>       Device-ID ::= < AVP Header: <TBD> >
>                     < Device-Iype >
>                     < Device-Data >

"Iype" -> "Type".

> 
> 
> 9.4.3.1  Device-Type AVP
> 
>    The Device-Type AVP (Code <TBD>) is of type Unsigned32. Below is a
>    list of specified Device-Types:
> 
>       IPV6_ADDRESS                      1
>       IPV4_ADDRESS                      2
>       ETHERNET_ADDRESS                  3
> 
> 
> 9.4.3.2  Device-Data AVP
> 
>    The Device-Data AVP (Code <TBD>) is of type OctetString.  The
>    length depends on the Device-Type AVP.  Below is a list of lengths
>    in octets for specified (See Device-Type AVP definition)
>    Device-Types:
> 
>       IPV6_ADDRESS                      16
>       IPV4_ADDRESS                      4
>       ETHERNET_ADDRESS                  6
> 
> 
> 9.4.4  Protection-Capability AVP
> 
>    The Protection-Capability AVP (Code <TBD>) is of type Unsigned32.
>    The AVP data is used as a collection of flags for different data
>    protection capability indications.  Below is a list of specified
>    data protection capabilities:
> 
>       L2_PROTECTION                     1
>       IPSEC_PROTECTION                  2
> 
> 
> 9.4.5  EAP-Payload AVP
> 
>    The EAP-Payload AVP is defined in [XXX].
> 
> 
> 9.4.6  Termination-Cause AVP
> 
>    The Termination-Cause AVP is defined in [DIAMETER].
> 
> 
> 9.4.7  Add-Device-ID
> 
>    The Add-Device-ID AVP (Code <TBD>) is of type Grouped.
> 
>       Add-Device-ID ::= < AVP Header: <TBD> >
>                  1* [ Device-ID ]
> 
> 
> 9.4.8  Remove-Device-ID
> 
>    The Remove-Device-ID AVP (Code <TBD>) is of type Grouped.
> 
>       Remove-Device-ID ::= < AVP Header: <TBD> >
>                  1* [ Device-ID ]
> 
> 
> 9.4.9  Session-ID
> 
>    The Session-ID AVP is defined in [DIAMETER].

I agree that re-using Diameter Session-ID for PANA Session-ID a good
idea.

Thanks,
Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 8 May 2003 15:57:49 -0700

I have one additional comment.

Sending Session-ID and Cookie together would break the stateless 
nature of PAA when sending cookie.  I'd suggest removing Session-ID 
from PANA-Start-{Request,Answer}.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Thu, 08 May 2003 16:10:41 -0700

> from PANA-Start-{Request,Answer}.

I'd say remove it from PANA_start_request but not from PANA-start_answer.
PaC should be able to present it if it wants to use an existing one. This
won't break the stateless nature of this exchange.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Thu, 08 May 2003 16:27:35 -0700

Hi Dan,

Here are my comments:

- inclusion of session id is discussed on another thread. Once we figure out
how it will be used, we can come back and adjust the message formats.

-add/remove device id: what are the scenarios we'll use these AVPs? We
should discuss them on another thread, and come back and design the message
format. We should identify what we want to do, and what we don't want/mean
to do with these extensions...

-  can we fold device-type and device-data type AVPs into one? This
particular AVP's data part can have a field "address type" which can be: 1-
IPv6 address, 2- IPv4 address, 3- Link-layer address. This is followed by
"address" field. I think we can get away without having to enumerate every
link-layer. Please see section 4.6.1 of rfc2461.

- I'd say we should not mandate DIAMETER style session IDs.
We can recommend it though.

Alper