Subject: RE: [Pana] PANA WG last call: draft-ietf-pana-pana-06.txt

From: Giaretta Gerardo <[email-masked]>
Date: Wed, 03 Nov 2004 14:25:01 +0100

> > 4) Section 4.3 Authorization phase :
> >         I am confused by the usage of word "Authorization". In the
> > "Authentication phase",
> >         the PaC is in the process of getting authenticated. 
> Similarly
> does
> > it mean that the PaC
> >         is in the process of getting authorized ? So, if i send a
> > PANA_SUCCESS at the end
> >         of authentication phase, by definition the node is both
> > authenticated and authorized. So,
> >         i don't know what authorization phase means.
> 
> Hmmmm. Maybe we should call this "authorized phase". There is 
> really no
> PANA "action" that changes the session in this phase. Does this make
> sense, or does anyone have another suggestion? 
> ...
>

I agree with Alper: "authorized phase" sounds good.

--Gerardo

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to 
[email-masked]. Thank you
====================================================================

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

---

From: [email-masked]
Date: Fri, 5 Nov 2004 16:17:18 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of ext Rafa Marin Lopez
> Sent: 04 November, 2004 19:10
> To: Yoshihiro Ohba
> Cc: [email-masked]
> Subject: Re: [Pana] PANA WG last call: draft-ietf-pana-pana-06.txt
>

<klip>

> >>Reading this section I have a doubt taking into account
> this exchange:
> >>
> >>PaC PAA
> >><-----req(x)------------
> >>x+1 (...incremented by 1 as new requests are generated and
> received..)
> >>------ans(x)--(losted)-->
> >>
> >><------req(x)------------
> >>"When a request message is received, it is considered valid
> in terms of
> >>sequence numbers if and only if its sequence number matches
> the expected
> >>value." ---> Taking into account this text, second req(x)
> would not be
> >>considered valid though maybe I am missing something.
> >>
> >>I know it should be retransmitted but maybe this text is
> bit confused...
> >>  
> >>
> >
> >Just be aware that the above text does not say anything
> about what the
> >receiver should do if the messesage is considered invalid.
> >
> >The second req(x) is invalid by definition in terms of sequence
> >number.  And we have explicit text in the same section on how to
> >deal with the dup:
> >
> >"
> >   PaC and PAA MUST respond to duplicate requests.  Last transmitted
> >   PANA answer MAY be cached in case it is not received by
> the peer and
> >   that generates a retransmission of the last request.
> When available,
> >   a cached answer can be used instead of fully processing the
> >   retransmitted request and forming a new answer from scratch.
> >"
> >
> >So I think the current text is clear enough.
> >
> I was thinking in the process: second request(x) arrives then :
>
> -- first look into my cache in order to know sequence number of second
> request(x) if this request has a sequence number equal than my cached
> answer then it is retransmission. ---> Could we say that it is a
> retransmission if sequence number that is expected to receive - 1 is
> equal than received request's sequence number?

Yes, but the text should be more clear.

>
> -- If no retransmission then sequence number verification.
>
> is that correct?

I think so. Peer can not answer to a request that is old (i.e. no
caching answer available anymore).

I hope this picture is ok.

                PaC                      PAA
                 |                        |
                 |<-----req(x)------------|
                 |                   1. Keep cached
                 |                      copy of req(x)
                 |------ans(x)----X       |
     A. Save cached                       |
        copy of ans(x)                    |
                 |                   2. Retransmit
                 |                      timeout
                 |<-----req(x)------------| RETRANSMIT
                 |------ans(x)----------->|
                 |                   3. Remove cached
                 |                      copy of req(x)
                 |  X---req(x+1)----------|
                 |                   4. Keep cached
                 |                      copy of req(x+1)
                 |                   5. Retransmit
                 |                      timeout
                 |<-----req(x+1)----------| RETRANSMIT
     B. Remove cached                     |
        copy of ans(x)                    |
                 |                        |
                 |------ans(x+1)--X       |
                 |                   6. Retransmit
                 |                      timeout
                 |[<-----req(x)-----------| THIS IS AGAINST THE SPEC!]
                 |<-----req(x+1)----------| RETRANSMIT
                 |------ans(x+1)--------->|
                 |                   7. Remove cached
                 |                      copy of req(x+1)
     C. PaC still has cached              |
        copy of ans(x+1)                  |
                 |                        |
                 ...                      ...

Br,
- Dan

---

From: [email-masked]
Date: Mon, 8 Nov 2004 12:50:07 +0200

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Alper Yegin
> Sent: 06 November, 2004 01:34
> To: [email-masked]
> Cc: 'Avi Lior'
> Subject: RE: [Pana] PANA WG last call: draft-ietf-pana-pana-06.txt
> 
> 
> Let me take a stab at Avi's comments.
> I'll just respond to those that require an answer or discussion. 
> 
...
<klip>
...

> > 8.2 Message Specfication
> > ========================
> > 
> >  Every PANA message MUST include a corresponding ABNF [RFC2234]
> >    specification found in [RFC3588].
> > 
> > So they are not the same right? Diameter starts with Diameter-Header
> > and there are other differences.  We should state the differences.
> > Present the ABNF for PANA and dont leave it up to deduction.
> 
> We shall ask Dan Forsberg to take a look at this.
> 

See issue148 (http://danforsberg.info:8080/pana-issues/issue148) for
proposed text.

Br,
- Dan

---

From: [email-masked]
Date: Mon, 8 Nov 2004 13:08:56 +0200

> > The design has messages to convey failed authentication, or 
> asynchronous
> > termination, but not a general purpose "notification". I 
> see this can be
> > useful. What do others think?
> 
> I think having information exchange specialized for notification is
> useful.

--> issue149
 
> > 
> > 
> > > Can the PAA refuse to authenticate if the PaC sets S-Flag to 0 in
> > > the answer message?  If yes, there should be a way to 
> indicate this
> > > decision by the PAA to the PaC.
> > 
> > Hmmm. I never thought that the PAA may want to mandate separate
> > authentication. What do you/others think? If this is a 
> useful/practical
> > scenario, we may need to add one more bit (like Mandatory/Optional).
> > 
> 
> I don't know whether this is useful/practical, but it would be easy to
> modify the specification to support the case.  I don't mind adding
> such functionality.

--> issue150

Br,
- Dan

---

From: Avi Lior <[email-masked]>
Date: Tue, 9 Nov 2004 11:09:20 -0500

Hi

See inline.

> From: Yoshihiro Ohba [mailto:[email-masked]] 
> Sent: Tuesday, November 09, 2004 10:08 AM
> To: Avi Lior
> Cc: 'Alper Yegin'; [email-masked]
> Hi Avi, 
> I have just a few comments.
> 
> On Mon, Nov 08, 2004 at 01:43:28PM -0500, Avi Lior wrote:
> > 
> > > > Notification:
> > > > 
> > > > It seems to me that it would be useful to use PANA as a
> > > means to send
> > > > notification to the PAC. So for example, if authentication
> > > failed then
> > > > we ought to be able to send information to the PAC as to the 
> > > > reason
> > > > why notification has failed.  RADIUS has a 
> Reply-Message attribute.
> > > > 
> > > > But even more importantly, as is being done in 3GPP2
> > > hot-line feature.
> > > > It is possible that the network operator may restrict
> > > network access
> > > > to
> > > the
> > > > user-device because of lack of payment or fraud.  Along
> > > with that, we
> > > > need a notification mechanism to indicate to the
> > > user-device that we
> > > > want it
> > > to
> > > > take some action such as browse to a particular web site.
> > > PANA can be
> > > > used as this out-of-band communication channel.
> > > 
> > > asynchronous termination, but not a general purpose 
> > > "notification". I see this can be useful. What do others think?
> > 
> > Okay.
> 
> You mentioned about PAA-to-PaC notification.  But I think 
> PaC-to-PAA notification could also be defined.  What do you think?

Sure. There is something wonderful to be said about symmetry.

> > > > <><><>
> > > > Cookie AVP is a bad name for what PANA uses it for.  
> Normally, one
> > > > thinks of a Cookie AVP as something opaque that the Server 
> > > can pass to
> > > > a client such that it is delivered back to the Server
> > > unmodified. But
> > > > more importantly, the server can put what it wants in 
> the cookie.
> > > > 
> > > > Interestingly enough, in the Cookie-AVP definition the cookie is
> > > defined
> > > > exactly like an opaque value.
> > > 
> > > Sorry, I didn't quite understand the difference. Are you
> > > suggesting we rename the AVP to something like 
> > > Cookie-Carrying-AVP and keep the same format? Yes, the data 
> > > field carries the "cookie value".
> > 
> > Sorry for not being clear.
> > There are several issues with this attribute.
> > 
> > First, the definition of the Cookie-AVP and the earlier 
> description of 
> > what is in the cookie are not in synch in PANA-06. Section 
> 4.1 defines 
> > that this cookie is used for prevention of DoS attacks. And it 
> > suggests what should go in the cookie.
> > 
> > In section 5.1 It states
> > " Cookie AVP: contains a random value that is used for making
> >       handshake robust against blind resource consumption DoS 
> > attacks."
> > 
> > In section 8.3.4 It states,
> > The Cookie AVP (AVP Code 4) is of type OctetString.  The data is
> >    opaque and the exact content is outside the scope of 
> this protocol.
> > 
> > I think that section 8.3.4 should be more descriptive about the 
> > purpose of this attribute so that it lines up with the real 
> intent as 
> > described in section 4.1 and 5.1.
> 
> I agree.  Section 8.3.4 shoule be more descriptive as such.
Okay.
> > 
> > Second, cookies usually refers to something that a server (PAA) can 
> > put in the client (PaC) that the server wishes to receive back in 
> > subsequent interactions. They are very generic. But in PANA 
> they use 
> > of a cookie plays a very distictive role.  Why not give that AVP a 
> > better name.
> 
> Note that IKEv2 also uses the term "cookie" for the exchange used 
> for the same purpose as PANA cookie.  

Well two wrongs don't make a right.

But no big deal.  Just polling around here, the first thing that comes to
mind when one comes across of the term cookie is actually the definition in
section 8.3.4.  But perhaps because folks are used to HTTP cookies.  So its
up to you guys.

> Yoshihiro Ohba