Subject: RE: [issue9] Message format

From: <[email-masked]>
Date: Tue, 10 Jun 2003 16:57:13 +0300

Alper,

Here are my comments. 

A new version of message format is available from the issue tracker. I'll forward the notification to this list.

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

So far we have used only two flags (FIN & REQ), six left. I don't see this as a good enaough reason. I think the protocol is way too complicated if we need all the 8 different flags, worse if more than that (16). Btw, AVPs can be used for that purpose too (null data part).

Anyway, if we change this for the AVP header we can't use existing AVPs (Result-Code, Session-Id, Termination-Cause, EAP, etc.).

> 
> >> 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.
> 
> OK, then the ACK bits in other messages should be removed too.
> PANA_failure_answer, PANA-reauth_answer, etc. have ACK bits.

Ok, fixed.

> >> 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?
> 
> What are the issues that we need to handle there? Can we not 
> handle them
> with the mechanism I outlined?

What if the MN wants to access the local network with link local or site local addresses at the same time with a global CoA address?

What if the MN has multiple interfaces (WLAN, Bluetooth, Ethernet, 3G, etc.) that all get a separate IP address from the same NAP through the same PAA? It's better to have one PANA session but add/delete addresses/interfaces.

Another possibility is to use only Device-Id AVP, but to send multiple AVPs (list of currently used Device Ids).

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

Ok. We could propose to use space from 1024 onwards for PANA AVPs and from 1 onwards for message types.

> > 
> >> 
> >> 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?
> 
> No, I'm not suggesting any change. This is just additional 
> text that does
> not conflict with yours.

Ah, ok. Should we make the Cookie AVP optional then? (i.e. no mandatoryy flag in the AVP header).
 
> > 
> >> 
> >> 
> >> 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."
> 
> That still does not provide the (much needed) message format 
> (order and size
> of fields).

Ok. I've tried to catch this now.

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

Sounds good. Fixed this.

> 
> >> 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."
> 
> 
> Looks good to me.

I changed this a bit after the AVP type code allocation proposal.

- Dan

> Thanks.
> Alper
> > - Dan
> >> Alper

---

From: Alper Yegin <[email-masked]>
Date: Tue, 10 Jun 2003 10:57:46 -0700

Hi Dan,

> So far we have used only two flags (FIN & REQ), six left. I don't see this as
> a good enaough reason.

It's safer to allocate the bits while we have spare ones. Maybe we won't
need them, but if we do, we'll have the space. Clearly 24bits for AVP space
won't be utilized. The chances of requiring more than 8 flags is much more
than having nearly 2^24 AVPs.

> I think the protocol is way too complicated if we need
> all the 8 different flags, worse if more than that (16). Btw, AVPs can be used
> for that purpose too (null data part).

This would not be a clean solution, right?

> 
> Anyway, if we change this for the AVP header we can't use existing AVPs
> (Result-Code, Session-Id, Termination-Cause, EAP, etc.).

I see. I understand the desire (not a requirement) to re-use pre-defined
data types, but we need to evaluate pros and cons.

> What if the MN wants to access the local network with link local or site local
> addresses at the same time with a global CoA address?

We have discussed this. Depending on the DI:

- if MAC address: then there is no issue. PaC can configure any
IP address on the specified MAC address. Access control is based on
the MAC address.
- if IP address: This is the case where IPsec is used. For this, PaC
determines one of the IP addresses as DI, most probably a link-local
address. The traffic is tunneled using this DI as the local end point. See
PANA-Ipsec draft. Now, if the PaC wants to use other IP addresses, they
will be used only within the tunnel, hence the access control does not
care about them. 

> 
> What if the MN has multiple interfaces (WLAN, Bluetooth, Ethernet, 3G, etc.)
> that all get a separate IP address from the same NAP through the same PAA?
> It's better to have one PANA session but add/delete addresses/interfaces.

The simple answer is: all physical interfaces should do PANA independently.
Is there a problem with that?

> Ah, ok. Should we make the Cookie AVP optional then? (i.e. no mandatoryy flag

If PAA includes the cookie in the message, PaC MUST copy it back.
But yes, we can say inclusion of cookie by PAA is optional. In some
environments, cookie might not be needed (e.g., over physical links).

Alper