Subject: Issues Tracker for PANA WG drafts

From: <[email-masked]>
Date: Fri, 18 Apr 2003 12:51:01 -0500

Hello,

In order to better track issues w.r.t the PANA WG drafts
we have decided to use an issue tracking solution. Thanks
to Dan Forsberg for maintaining the issues web site.

The URL for this is:

	http://danforsberg.info:8080/pana-issues/

In the future if you would like to raise an issue with any
of the PANA WG drafts in progress, please mention if it is a
new issue or it is something that is already recognized and is
being tracked.

-Basavaraj

---

From: Reinaldo Penno <[email-masked]>
Date: Sun, 20 Apr 2003 08:14:49 -0700 (PDT)

My comments on some of these issues...

Device-Identifier:

The Device Identifier originally could be anything,
not necessarily a IP address(es) or link layer. It
could be a group-name, user-name, NAI, etc, etc

What was the reason for change? IN the beggining it
was only link layer or IP addresses. Then we discussed
this ad nauseum and concluded that it could be
anything, so it seems we are changing it again.

Capability negotiation:

Capabilty negotiation is a powerful tool. Today I
guess thre are two approaches. The offer/answer model
(used by SIP/SDP), BGP and some others. You might
cvall it capability advertisement, since if the peer
does not agree, everything starts over.

The other is the PPP/LCP approach, where you have
configure-ack, nak, rej, etc.

The second one is more flexible but my take more RTTs.
The first one needs that the initiator puts all
acceptable capabilities and its respective values on
the <offer> message.

regards,

Reinaldo

> new issue or it is something that is already

__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sun, 20 Apr 2003 22:23:01 +0200

hi reinaldo,

please see my comment inline:

> -----Original Message-----
> From: Reinaldo Penno [mailto:[email-masked]]
> Sent: Sonntag, 20. April 2003 17:15
> To: [email-masked]; [email-masked]
> Subject: Re: Issues Tracker for PANA WG drafts
>
>

the device identitifier is directly used as an input for a packet filter
"tool".
a nai, username, groupname etc. are concepts which are unknown to these
tools in a pana environment.

the username, however, appears in other places (eap) since it is required
for
a) routing
b) authorization/authentication

> acceptable capabilities and its respective values on

which model would you suggest for pana?
in particular it would be good to have the functionality:

A)

Pac <-- Paa: i support x,y and z
Pac --> Paa: i would like to use y

B)
Pac --> Paa: enable x
Pac <-- Paa: status (ok, failed)

C)
Pac <-- Paa: you must use y
Pac --> Paa: status (ok, failed)

D)
Pac --> Paa: what do you support?
Pac <-- Paa: i support x,y and z

thanks for addressing open issues.

ciao
hannes

---

From: Reinaldo Penno <[email-masked]>
Date: Mon, 21 Apr 2003 10:43:40 -0700 (PDT)

Hello Hannes,

comments inline...

> tools in a pana environment.

well, then I guess the problem is the restriction of
the device identifier use.  Early in the game device
identifier was flexible because people could use data
in there to cater to their needs (accounting,
filtering, etc, etc).

The early proposal was to be able to put anything in
there, I'm (still) not convinced why this is an issue.
If I put something that is not acceptable by the PAA
(or backend AAA), I get an error...Or maybe I could
put my IP/MAC address AND something else. Why I cannot
stack information so that is more flexible?

If, for example, I put that my IP address is a.b.c.d
and I'm located at first floor.

> b) authorization/authentication

see above. The information in the device identifier
can be used in different ways by different people. If
you tell me that being flexible in this case is bad
because it would mean big changes in the
protocol..well, then that's a different story. But I
haven't seen that.
> which model would you suggest for pana?

well, it depends, if D) happens followed by B), do you
want them to be part of the same negotiation, or each
one individually self contained transactions? 

For example, in PPP/LCP all the configure messages,
are part of one big negotiation (which means that the
state machine is more elaborate), i.e, the negotiation
process is a protocol on its own (LCP). I guess the
PPP experts on the list can elaborate lenghtly on the
pros/cons of this model.

SDP has very limited negotiation capabilities. Only
two messages <offer> and <answer>. In order to convey
that a capability is not acceptable, the value
returned by the peer is often "zero" <0>. There is no
different message for that. 

All the intelligence to figure out if the options are
acceptable, to try again, etc relies on the
application layer. In this case SIP. 

> > > In order to better track issues w.r.t the PANA
> WG
> > > drafts
> > > we have decided to use an issue tracking
> solution.
> > > Thanks
> > > In the future if you would like to raise an
> issue
> > > with any
> > > of the PANA WG drafts in progress, please
> mention if
> > > it is a

---

From: Alper Yegin <[email-masked]>
Date: Mon, 21 Apr 2003 11:09:57 -0700

Hi Reinaldo,

> anything, so it seems we are changing it again.

I couldn't track where this recommendation come from, but I cannot see how
the DI can be user-name, group-name, NAI, etc. DI is used for access
control, and none of these identifiers are carried in the data packets. Only
link-layer addresses and IP addresses.

Alper

---

From: Reinaldo Penno <[email-masked]>
Date: Mon, 21 Apr 2003 11:30:21 -0700 (PDT)

well,

I commented on that in my email to Hannes. Information
on the DI my not be used directly in the access rule,
but can influence which/how to construct the rule.

If, for example, I know that the IP address is a.b.c.d
AND the user-name is Alper AND he is accessing from
his house than the filter rules are going to be X, Y,
Z..., otherwise M, N, O.

I really do not want to drag this much further. I just
want to make the point that it can be very
useful/powerful and the changes in the protocol seem
to be minimum. But if folks feel otherwise, that's
okay.

cheers,

Reinaldo

---

From: Alper Yegin <[email-masked]>
Date: Mon, 21 Apr 2003 11:52:07 -0700

Reinaldo,

> his house than the filter rules are going to be X, Y,

Sure, that makes sense. But you don't need to carry all these in DI.
User-name can be carried inside the client id used during the
authentication. The location information can be inferred from the location
of the PAA. 

Alper

---

From: Reinaldo Penno <[email-masked]>
Date: Mon, 21 Apr 2003 12:03:50 -0700 (PDT)

> inferred from the location

Come on Alper, you know very well that you cannot
infer the user location from the location of the PAA.
You can have a huge layer 2 metro/wireless/whatever
network between PAC and PAA. Not to mention that you
can PAAs distribued across your layer 2
infrastructure, etc, etc, 

Anyway, these where only 2 examples, you can have
thousands of other parameters. As I said it boils down
to the fact if we think it is useful/powerful or not.
I still think it provides for flexibility, will
certainly have uses in the field and the changes in
the protocol are manageable.

regards,

Reinaldo

> >> the DI can be user-name, group-name, NAI, etc. DI
> is
> >> used for access
> >> control, and none of these identifiers are
> carried
> >> in the data packets. Only

---

From: Alper Yegin <[email-masked]>
Date: Mon, 21 Apr 2003 14:27:13 -0700

> infrastructure, etc, etc,

You are right. PAA location by itself does not always give the kind of
information you are looking for. PAA might know where a circuit is coming
from, and provide this auxiliary information to the backend. I'd
preemptively agree that this might not be assumed for all cases :)

I think in general what you are aiming is providing some auxiliary data that
can affect the "authorization". I think DI is used for one purpose, that is
access control, and we should not overload it here.

As for providing the additional data for authorization, one possibility is
to use EAP TLVs:

draft-grayson-eap-authorisation-01.txt

Alper

---

From: [email-masked]
Date: Tue, 22 Apr 2003 16:56:26 +0200

hi all,

the following is about the discovery phase in the pana draft:

    PaC may also choose to start sending packets before getting
    authenticated.  In that case, the network should detect this and
    send an unsolicited PANA_start message to PaC.  EP is the node that
    can detect such activity.  If EP and PAA are co-located, then an
    internal mechanism (e.g. API) between the EP module and the PAA
    module on the same host can prompt PAA to start PANA.  In case they
    are separate, there needs to [be] an explicit message to prompt
    PAA.

1/ on the one hand, the current version of the pana protocol quickly 
states [discovery section] that, in case of 'traffic-driven' 
authentication, the EP must send a PANA_start message to the PAA:

    Upon detecting the need to authenticate a client, EP can send a
    PAC_discovery message to the PAA on behalf of the PaC. This
    message carries a device identifier of the PaC in a Device-Id AVP.

2/ on the other hand, the requirements draft [EP-PAA protocol section] 
states that the PAA-EP protocol should support event-notification also:

    Depending on the PANA protocol design, support for either of the push
    model (i.e., EP initiating the PAA-EP protocol exchange per PaC) or
    the pull model (i.e., PAA initiating the PAA-EP protocol exchange per
    PaC), or both might be required.

--> the working group should fix this (not listed on the web site) issue 
also (the PANA protocol OR the PAA-EP protocol supports the EP-triggering)

my personal feeling on this is that the PANA protocol should be 
restricted to PaC-PAA communication and the PAA-EP protocol (whichever 
you finaly choose) should take it as a requirement.

thanks,
yacine

---

From: Alper Yegin <[email-masked]>
Date: Tue, 22 Apr 2003 12:04:32 -0700

Hello Yacine,

I couldn't see an inconsistency here.

The requirements draft says the PAA-EP protocol should support either push
model, or pull model, or both depending on the PANA protocol design.
And the current PANA protocol design lets EP notify the PAA about
unauthenticated PaCs. Hence the only requirement on the PAA-EP protocol is
the support for the "pull model" (as defined below).

Does this make sense?

Alper

---

From: [email-masked]
Date: Wed, 23 Apr 2003 11:48:40 +0200

Hi Alper,

> the support for the "pull model" (as defined below).

yes, this is the current view. did the PANA WG reached a consensus on 
this subject ? I'm curious about the technical motivations of the design 
team for such a choice in the PANA protocol design.

> Alper

thank you,
yacine

NB: terminology question for the req-draft authors:

the PUSH model is defined as follows:
 - "EP initiating the PAA-EP protocol exchange per PaC"
and the PULL model corresponds to:
 - "PAA initiating the PAA-EP protocol exchange per PaC"

is that really what you meant ? isn't it the contrary ? 

usually, the 'PULL model' better corresponds to bottom-up (EP->PAA) 
initiated communication.

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 23 Apr 2003 20:02:10 +0200 (CEST)

Reinaldo,

While I'm not up to spead on the details of this discussion
it seems like you are applying a different criteria than I had in mind.
Useful, powerful, flexible is not good guiding principles to
come up with a protocol which fits the intended purpose - they
look a lot more likely to result in kitchen sink protocols to me.

Criteria like "necessary" in to solve what the WG has set out to solve
(while also thinking carefully which things need to be well-specified 
in order to allow limited future extensibility) is a lot likely to result
in a succesful WG and a succesful protocol.

  Erik

---

From: Alper Yegin <[email-masked]>
Date: Wed, 23 Apr 2003 11:08:43 -0700

> team for such a choice in the PANA protocol design.

Just like any other part of the draft, this is also subject to the WG
discussions. There was no discussion on this after the publication of the
version 00, so it is hard to say whether the WG has reached a consensus or
not. 

I can only speak for myself, as I don't remember detailed discussion on this
matter during its design. We could expect the PAA-EP protocol to provide
this notification, but I don't see why not do it in PANA, and have less
requirements on the PAA-EP protocol.

> usually, the 'PULL model' better corresponds to bottom-up (EP->PAA)

Yes, I caught that too, and this is fixed in the latest version:

http://www.ietf.org/internet-drafts/draft-ietf-pana-requirements-05.txt

Alper