Subject: [Pana] pana-pana Issue238: Session-Id AVP

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 27 Dec 2005 12:20:51 -0500

>8.16  Session-Id AVP
>
>   All messages pertaining to a specific PANA session MUST include a
>   Session-Id AVP (AVP Code 16) which carries a PAA-assigned fixed
>   session identifier value throughout the lifetime of a session.  When
>   present, the Session-Id AVP SHOULD appear immediately following the
>   PANA header.
>  
>
Why not make this a MUST?

>   The Session-Id MUST be globally and eternally unique, as it is meant
>  
>
What does globally and eternally mean? Do you mean global within a 
single PAA, or the entire world? And by eternally, do you mean that they

session ID may *never* be reused, or not reused "often"?

>   to identify a PANA session without reference to any other
>   information, and may be needed to correlate historical
authentication
>   information with accounting information.  The PANA Session-Id AVP
has
>   the same format as the Diameter Session-Id AVP [RFC3588].

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

---

From: Jari Arkko <[email-masked]>
Date: Wed, 28 Dec 2005 15:37:24 +0200

>Why not make this a MUST?
Good question. Make it a MUST unless
there some special case where something
else goes there. And if there is, better explain
that special case and make it a MUST rather
than leave the details to figuring out what
the SHOULD means.

>session ID may *never* be reused, or not reused "often"?
Eternally means 'having infinite duration' (from dictionary). I
guess you could interprete 'globally' in different ways, but I
believe this means within the world in this case.

Text from the reference, RFC 3588, Section 8.8, may make
this clearer.

I'm not sure we need text change for this part.

--Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 28 Dec 2005 10:41:44 -0500

> than leave the details to figuring out what

It appears that this text is borrowed from RFC 3588 Session-Id AVP
definition which also say SHOULD.  After inspecting ABNF for all PANA
AVPs and I think we can make it a MUST.

Note that neither PANA nor RFC 3588 specifies an exact behavior in
case an AVP that is defined in ABNF as appearing in a fixed position
(in ABNF, such an AVP is quoted by "<" and ">") appears in a different
position.  The behavior implemented in Diameter and PANA
implementations in Open Diameter for this case is that such an AVP is
considered as if it were missing in the message.  I am not sure if
this is the right behavior or we should specify this level of details.

> I'm not sure we need text change for this part.

I agree.  We might not need text change for this part.

Yoshihiro Ohba

---

From: Jari Arkko <[email-masked]>
Date: Wed, 28 Dec 2005 20:45:14 +0200

>It appears that this text is borrowed from RFC 3588 Session-Id AVP
Heh.

>AVPs and I think we can make it a MUST.
Great!

>this is the right behavior or we should specify this level of details.
I have been assuming that violation of the fixed-position rules is akin
to having another type of formatting problem in the whole message,
i.e., discard the message.

--Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 28 Dec 2005 14:38:20 -0500

> i.e., discard the message.

Somehow your assumption of discarding the message for this case is the
same as Open Diameter!  It may be different in details, though, as to
whether it is silently discarded or discarded with generating an error
message (OD does latter.)

So I think it might be good to be a bit specific about invalidity on
AVP positioning.  How about rewriting the text in Section 5.5 from:

"
5.5  Message Validity Check

   When a PANA message is received, the message is considered to be
   invalid at least when one of the following conditions are not met:

   (snip)

   o  The message payload contains a valid set of AVPs allowed for the
      message type and there is no missing AVP that needs to be included
      in the payload.

   (snip)

   Invalid messages MUST be discarded in order to provide robustness
   against DoS attacks.  In addition, an error notification message MAY
   be returned to the sender.  See Section 5.11 for details.
"

to:

"
5.5  Message Validity Check

   When a PANA message is received, the message is considered to be
   invalid at least when one of the following conditions are not met:

   (snip)

   o  The message payload contains a valid set of AVPs allowed for the
      message type and there is no missing AVP that needs to be included
      in the payload and there is no AVP that needs to be included in
      a fixed position is included in a different position.

   (snip)

   Invalid messages MUST be discarded in order to provide robustness
   against DoS attacks.  In addition, an error notification message MAY
   be returned to the sender.  See Section 5.11 for details.
"

Yoshihiro Ohba

---

From: Jari Arkko <[email-masked]>
Date: Wed, 28 Dec 2005 21:48:36 +0200

Ok.