Subject: [Pana] Defining Session-Id in PANA header

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 19 Oct 2006 00:06:02 -0400

If we are agreeing on 4-octet session identifier, I think it is much
better to define it in the PANA header than defining it as an AVP.
This will save 8-octet consumed by an AVP header for messages except
for those that are not supposed to carry a session identifier.

Also, it would not be a burden to assign a session identifier in
PSR/PSA exchange any more.  By carrying a session identifier in
PSR/PSA, we can also use the session identifier for the purpose of
stateless handshake instead of using Cookie AVP, because the PaC needs
to receive and parse the PSR to generate a PSA with the session
identifier that was newly generated by the PAA.  This will also 
eliminate the neccesity of defining L-flag.

To summarize, I propose to:

[1] Remove Session-Id AVP from the specification.

[2] Add 4-octet Session-Id field to PANA header.  Usage: A new
Session-Id is assigned by PAA and carried in PSR/PSA exchange.  The
assigned Session-Id value MUST be used for subsequent messages
throughout the session.

[3] Remove Cookie AVP and L-flag from the specification.

I think this would simply the protocol to some extent.

Yoshihiro Ohba

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

---

From: "Alper Yegin" <[email-masked]>
Date: Sat, 21 Oct 2006 17:50:41 +0300

Yoshi,

> for those that are not supposed to carry a session identifier.

That sounds good.

> PSR/PSA exchange any more.  

How does it make a difference whether the session-id is carried in the
header vs. in an AVP? I wonder if I'm missing an implication here.

> By carrying a session identifier in

If that is true, we could also use the session-id AVP in that way too. What
am I missing? How is this new container making such a difference?

My understanding is, with the AVP we were carrying the session-id after the
PSR/PSA -- hence PSR/PSA was stateless. Now if we always carry the
session-id with PSR/PSA, that exchange cannot be stateless. Right? Are we
not concerned about this because this is just 4 octets, or because an
implementation can have a way to verify the echoed id without holding
per-PaC state, or something else?

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 21 Oct 2006 14:34:04 -0400

Hi Alper,

> header vs. in an AVP? I wonder if I'm missing an implication here.

This is related to stateless handshake.  Please my comment below.

> am I missing? How is this new container making such a difference?

The current Session-Id AVP value is FQDN + (8 or more)-octets 
which is not as compact as a 4-octet integer (FQDN part is static
information, though).  I think requiring PAA to remember 4-octet
session-identifier is less burden for stateless handshake than the
current Session-Id AVP.  

> per-PaC state, or something else?

Because this is just 4 octets (just like 4-octet initial sequence
number which needs to be hold in stateless handshake).  Or we could
also use ISN in place of Cookie AVP, in which case session identifier
assignment can be done in the first PAR as in the current
specification.  Either way is fine with me.

Yoshihiro Ohba

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 23 Oct 2006 10:58:16 +0300

I'm fine with:
- removing the text about stateless discovery (L-bit, and any mention of its
optionality),
- making the session-ID always carried with the PSR.

I acknowledge that storing 4-octets may be viewed as a DoS opportunity, but
implementations can be smart about the ID assignment to circumvent the
threats.

I think this is also aligned with what Jari was suggesting a while ago. I
hope he can comment on this.

Alper

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:[email-masked]]
> Sent: Saturday, October 21, 2006 9:34 PM
> To: Alper Yegin
> Cc: 'Yoshihiro Ohba'; [email-masked]
> Subject: Re: [Pana] Defining Session-Id in PANA header
> 
> Hi Alper,
>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 24 Oct 2006 11:08:15 -0400

I have an additional comment.

If we agree on removing L-bit, then we need to revisit the retransmission 
issue in handshake phase.  Currently the text says:

"
   A PANA-Start-Request message in stateless handshake MUST NOT be
   retransmitted as this voids the statelessness on the PAA.  Instead,
   the PaC MUST retransmit the PANA-Client-Initiation message until it
   receives a PANA-Start-Request message, and retransmit the PANA-Start-
   Answer message until it receives a PANA-Auth-Request message.  The
   PaC can determine whether the PAA is using stateless handshake by
   looking at the L-flag in the PANA header.  The PANA-Start-Request
   message MUST be retransmitted instead of the PANA-Start-Answer
   message when stateful handshake is used (L-flag is not set).
"

I think we can simplify the rule such that PAA is always responsible
PSR retranmission.  This is because now we assume PAA to hold minimum
session state (e.g., ISN and Sessin-Id) for a certain amount of time,
it might make sense to have PAA retransmit PSR during that time even
when the PAA is operating in stateless mode.  With this, there will be
no exception for retransmission rule of any request message.

BTW, all those changes seem to indicate that stateless handshake means
stateless in terms of "EAP layer", which would be easier to
understand.  The PAA may not include EAP in PSR if it does not want to
start EAP before it makes sure that the PaC is reachable and agrees to
run EAP with a certain set of PANA parameters (e.g., Algorithm AVP)
carried in PSR.

Yoshihiro Ohba

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 27 Oct 2006 14:09:08 +0300

Even if we require ISN and session-ID to be present in the PSR, I think an
implementation can manage to be stateless. But, if we also require PSR
re-transmissions, I think (?) that's no longer possible. 

In order to allow implementations to be PANA spec compliant and stateless at
the same time, can't we get away without mandating PSR to be re-transmitted?
Without any other mentions of "stateless vs. stateful", a simple statement
in one place could capture this: "For implementations seeking to stay
stateless in response to PANA-Client-Initiations, PSR retransmission MAY be
turned off."

Now, what would a PaC do if it faces such a PAA:
- If the PaC does not receive a response to its PCI (imagine the single PSR
transmitted by the PAA was lost), then the PaC will re-transmit the PCI.
- If the PaC receives PSR and responds with a PSA but does not receive the
first PAR (imagine PSA was lost), then the PaC will go back to PCI.

So, PaCs shall be able to deal with such PAAs.

Makes sense?

Alper

> Sent: Tuesday, October 24, 2006 6:08 PM
> To: Alper Yegin
> Cc: 'Yoshihiro Ohba'; 'Jari Arkko'; [email-masked]
> > > > If that is true, we could also use the session-id AVP in that way
> too.
> > > What
> > > > My understanding is, with the AVP we were carrying the session-id
> after
> > > the
> > > > session-id with PSR/PSA, that exchange cannot be stateless. Right?
> Are
> > > we

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 27 Oct 2006 10:52:29 -0400

Alper,

Your suggestion makes sense to me.

We might need text on the PaC behavior, in addition to your suggested
text on the PAA behavior.  The additional text on the PaC bahavior can
be something like:

"
In the case of PaC-initiated handshake, the PaC MUST retransmit the
PANA-Client-Initiation message until it receives a PANA-Auth-Request
message.
"

Yoshihiro Ohba

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 27 Oct 2006 20:45:04 +0300

Yoshi,

I thought about that.
I don't think we need to make such mandate in the protocol spec.
What else would an implementation do anyways?

Alper

> Sent: Friday, October 27, 2006 5:52 PM
> To: Alper Yegin
> > > > - removing the text about stateless discovery (L-bit, and any
> mention of
> > > its
> > > > optionality),
> > > > I acknowledge that storing 4-octets may be viewed as a DoS
> opportunity,
> > > but
> > > > I think this is also aligned with what Jari was suggesting a while
> ago.
> > > I
> > > > > > > If we are agreeing on 4-octet session identifier, I think it
> is
> > > much
> > > > > > How does it make a difference whether the session-id is carried
> in
> > > the
> > > > > > > stateless handshake instead of using Cookie AVP, because the
> PaC
> > > needs
> > > > > > not concerned about this because this is just 4 octets, or
> because
> > > an

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 27 Oct 2006 14:32:24 -0400

If we don't mandate it, we are creting a case in which the protocol
does not work.  So I believe that this is a protocol issue and the
text describing when to stop PCI retransmission would be needed.

Yoshihiro Ohba

---

From: "Alper Yegin" <[email-masked]>
Date: Sun, 29 Oct 2006 00:18:28 +0300

> does not work.  

What is the case that leads to protocol not working? I mean, if we don't
have that "mandate" in the text, what kind of an implementation would yield
an interop problem? My claim is, even without such a text, any clueful
implementation would do the same -- if the session is not going forward, go
back and try again. Am I missing something? 

Alper

> So I believe that this is a protocol issue and the
> > > > Even if we require ISN and session-ID to be present in the PSR, I
> think
> > > an
> > > > stateless in response to PANA-Client-Initiations, PSR retransmission
> MAY
> > > be
> > > > turned off."
> > > >
> > > > - If the PaC does not receive a response to its PCI (imagine the
> single
> > > PSR
> > > > - If the PaC receives PSR and responds with a PSA but does not
> receive
> > > the
> > > > > > implementations can be smart about the ID assignment to
> circumvent
> > > the
> > > > > > threats.
> > > > > >
> > > > > > > > > better to define it in the PANA header than defining it as
> an
> > > AVP.
> > > > > > > > > This will save 8-octet consumed by an AVP header for
> messages
> > > > > except
> > > > > > > > > Also, it would not be a burden to assign a session
> identifier
> > > in
> > > > > > > > If that is true, we could also use the session-id AVP in
> that
> > > way
> > > > > too.
> > > > > > > What
> > > > > > > > My understanding is, with the AVP we were carrying the
> session-
> > > id
> > > > > after
> > > > > > > the
> > > > > > > > PSR/PSA -- hence PSR/PSA was stateless. Now if we always
> carry
> > > the
> > > > > > > > implementation can have a way to verify the echoed id
> without
> > > > > holding
> > > > > > > > > Session-Id is assigned by PAA and carried in PSR/PSA
> exchange.
> > > > > The

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 29 Oct 2006 09:56:34 -0500

The PANA conversation will stall when PAA does not retransmit PSR and
PAN gets lost.  If we can justify this by expecting PaC implementation
to "going back and try again", then perhaps retransmission of any
request could have been optional for the same reason?

Yoshihiro Ohba