Subject: PAA-EP protocol candidates

From: [email-masked]
Date: Tue, 01 Jul 2003 14:03:08 +0200

hello,

below is a list of protocols that could potentially be used for the 
PAA-EP interface in the PANA framework. does the working group find this 
is a good start before discussing the way each one supports the 
PANA-specific requirements ?

[http://yacine.free.fr/ietf/draft-yacine-pana-paa-ep-reqs.txt :]

4.9 Re-use of an existing protocol

    This work hopefully will not involve any new protocol design, it may
    involve definition of new AVPs for existing protocols. The PANA
    working group should try to re-use one of the many protocols around
    to do this. The following protocols were mentioned for consideration:

      . SNMP [SNMP]
      . COPS-PR [COPS-PR]
      . DIAMETER [DIAMETER]
      . RADIUS [RADIUS]
      . ForCES [ForCES]

thanks,
yacine

---

From: Alper Yegin <[email-masked]>
Date: Tue, 01 Jul 2003 19:48:05 -0700

Folks,

At this point, we'd like people who are familiar with these protocols to
talk about if and how they can satisfy the PAA-to-EP protocol requirements.
Feel free to add more to the candidate list.

For each candidate, we need to understand if they are generally suitable for
this provisioning task, if they already support the required data types, if
there needs to be additional development (e.g., creating new AVPs).

The end result of this exercise would be something like this: Protocol X, Y,
Z can readily be used for this, P and Q require new AVPs, R and S do not
help this at all.

Let's use draft-ietf-pana-requirements-07.txt as the baseline for the
requirements.

Cheers,

Alper

---

From: [email-masked]
Date: Wed, 02 Jul 2003 11:48:41 +0200

> Let's use draft-ietf-pana-requirements-07.txt as the baseline for the

FYI, the corresponding section within this I-D says:
- the protocol must carry DI and keys
- there might be multiple EPs per PAA
- the protocol must be secured
- whether it must support push, pull, or both, depends on the PANA design.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 3 Jul 2003 19:45:55 -0700

First of all, I think this is a good document to understand the issues
related to PAA-EP communication.  Please see specific comments below.

   "4.3 One-to-many PAA-EP relation
                                                                                
   One PAA have to communicate with several Eps once a PaC is
   authenticated. The PAA-EP protocol must be able to handle this 1:n
   communication."

I think there is some case in which one-to-many PAA-EP relation may
not be necessary.  For example, if EP and PAA are co-located with
802.11 APs and the APs are in the same LAN, the PAA on one AP does not
need to communicate with EPs on another AP, since a PaC (or a 802.11
station with a specific MAC address) is always associated with a
single AP at a time.  If the PaC switches to a new AP, it might just
perform PANA (re-)authentication with the PAA on the new AP which will
then install filters on the co-located EP.
                                                                                
   "4.8 Accounting/Feedback from the EPs
                                                                                
   The PAA must have an efficient way to to get the accounting
   information of PaC from EP since the PAA may be a client of the AAA
   backend infrastructure."

I think the PAA does not always need to get the accounting information
of PaC from EP.  For example, Diameter allows separation of accounting
from authentication/authorization.  EP can be a Diameter accounting
application client while PAA can be a Diameter
authentication/authorization application client.

   "4.9 Re-use of an existing protocol

     . SNMP [SNMP]
     . COPS-PR [COPS-PR]
     . DIAMETER [DIAMETER]
     . RADIUS [RADIUS]
     . ForCES [ForCES]"

The reference to ForCES seems to be missing in the draft.  

"DIAMETER" should be "Diameter".  

I think we can simply drop RADIUS from the list (perhaps with a short note),
since Diameter covers all what RADIUS can do.

Thanks,
Yoshihiro Ohba

---

From: [email-masked]
Date: Fri, 04 Jul 2003 11:47:54 +0200

hi yoshihiro,

> related to PAA-EP communication.  Please see specific comments below.

thx

> then install filters on the co-located EP.

1) one-to-many includes one-to-one, this req is just to say a PAA may
deal with several EPs.
2) if PAA and EP are co-located, there's no protocol at all.

> authentication/authorization application client.

agree this is not a hard requirement and agree also on the separation
auth/acc. I guess it's only a nice-to-have functionality on this
interface...

FYI, at the origin of this req was:
ftp://ftp.research.telcordia.com/pub/Group.archive/pana/webview/msg01664.html

> The reference to ForCES seems to be missing in the draft.  

The protocol is under construction in the forces wg, but the frwk is
available (see below). it deals with control/forwarding separation and
forces is the protocol for the interface between the two.

http://www.ietf.org/internet-drafts/draft-ietf-forces-framework-06.txt

> "DIAMETER" should be "Diameter".  

ok.

> since Diameter covers all what RADIUS can do.

agree.

---

From: [email-masked]
Date: Fri, 04 Jul 2003 16:36:26 +0200

below is a brief comparison of SNMP, COPS-PR and Diameter protocols 
against the requirements in draft-ietf-pana-requirements-07.txt, please 
see inline:

conclusion:
BASED ON THESE REQUIREMENTS ONLY, all three protocols are nearly 
equivalent winners. SNMP and COPS -- explicit management protocols -- 
fits better (especially for the data contained: DI-rules, keys, etc.) 
the provioning context of the PAA-EP interface.

now all depends on the PANA protocol design and working group 
expectations in term of functionalities on such a provisioning interface.

thanks,
yacine

 > - the protocol must carry DI and keys

- SNMP: already defined MIBs (for filters, ipsec policy, etc.) can be 
re-used. if not sufficient, PANA-specific MIBs can be designed.
- COPS-PR: already defined PIBs (for filters, ipsec policy, etc.) can be 
re-used. if not sufficient, PANA-specific PIBs can be designed.
- Diameter: IPfilterRule data type available, but a new PANA application 
extension of Diameter would certainly have to be defined.

 > - there might be multiple EPs per PAA

- SNMP: An SNMP manager (PAA) can communicate simultaneously with 
several agents (EPs).
- COPS-PR: COPS-PR PDPs (PAAs) are designed to communicate with several 
PEPs (EPs).
- Diameter: Diameter allows connection to more than one peer (and 
encourages this for improved reliability).  Whether the Diameter 
connection state machine is too heavy to support the number of 
connections needed is a matter for discussion.

 > - the protocol must be secured

- SNMP:  SNMPv3 includes the User-based Security Model (USM, [RFC2574]), 
which defines three standardized methods for providing authentication, 
confidentiality, and integrity.  Additionally, USM has specific built-in 
mechanisms for preventing replay attacks including unique protocol 
engine IDs, timers and counters per engine and time windows for the 
validity of messages.
- COPS-PR: COPS-PR has built-in message level security for 
authentication, replay protection, and message integrity. COPS-PR can 
also use TLS or IPSec, thus reusing existing security mechanisms that 
have interoperated in the markets.
- Diameter: Diameter relies on either IPSEC or TLS for these functions.

 > - whether it must support push, pull, or both, depends on the PANA

- SNMP: push model with bottom-up notifications.
- COPS-PR: push, pull or both models supported.
- Diameter: The Diameter protocol permits either peer in a connection to 
originate transactions. Thus the protocol supports EP-originated messages.

---

From: [email-masked]
Date: Fri, 04 Jul 2003 16:54:15 +0200

the draft below about COPS-PR applicability:
http://ietf.org/internet-drafts/draft-yacine-pana-cops-ep-00.txt

it needs to be updated for taking into account the explicit PANA 
requirements.

thanks,
yacine

---

From: Reinaldo Penno <[email-masked]>
Date: Mon, 14 Jul 2003 09:30:05 -0700 (PDT)

Hello,

here it goes some comments on pana-01. I've been away
for a while so please discard any issues that have
already been discussed in the list.

1) There is a typo in Page 8, first phrase. It reads
"...it is considered as valid..."

I suggest "it is considered valid"

2) In the end of section 4.1.7 there is a TBD
regarding non-acknowledgement error notification
message MAY being returned to the sender.

IMO such messages help quite a lot during
troubleshooting in deployments and interoperability.
 
If there is a concern of DoS attacks we could use a
timer so that we return 1 error notification to each
different sender each N seconds.

3) In section 4.2, paragraph 3 it is mentioned that
"The result does not depend on which PAA PaC chooses.
By default PaC chooses the PAA that sent the first
reponse"

This is the DHCP approach. Where all servers are
equally good. 

I would propose that we think about incorporating
something of the PPPoE protocol that is widespread,
since PANA is more related to the PPPoE model.

In the response of the Discovery message each PPPoE
server include all the Service Profile (names) it
supports (the definition is loose on purpose).
Nowadays it is usually a list of ISPs or bandwidth
packages a user can choose.

I would argue that in the case of PANA (and specially
in the case of NAP vs ISP authentication), PAA servers
might support a very different set of attributes and a
PaC might prefer one over the other if it new of each
choices.

We could have a AVP in PANA for that purpose in the
answer to the Discovery message. it seems very simple,
could be optional and will provide a crucial
functionality for people that use PPPoE to migrate to
PANA.

4) In page1, end of first paragraph there is a typo.
It reads "...PAA MUST be protected by using.

using what?

5) In page 13 the first two phrases of the second
paragraph seem unrelated. The phrases are "...MUST
contain a MAC AVP. The PANA-Bind-Request..."

I guess what you are trying to say is that
PANA-Bind-Request/Answer messages will be protected by
the MAC AVP?? Maybe it's the timezone, but I feel the
phrases are disconnected.

6) In section 4.7, the third paragraph has a lot of
strong statements regarding what should be used as the
device ID without any MUST ot SHOULD. If we want to
make such a case we should capitalize the should(s) in
the paragraph. 

regards,

Reinaldo

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 16 Jul 2003 08:33:41 -0700

Hi Reinaldo,

Thanks for sending the comments.  Please see my comments in line.

> I suggest "it is considered valid"

OK.

> troubleshooting in deployments and interoperability.

I agree to define some informational exchange for error reporting.

> different sender each N seconds.

Yes, the rate of such informational message exchanges should be
limited in implementations.

We can discuss these things in issue 17 "Error handling".

> functionality for people that use PPPoE to migrate to

When we dicussed NAP and ISP separate authentication, I think the
assumption is that there is a single PAA the PaC sees, and the NAI is
used to choose a particular ISP.  Why do you need multiple PAAs to
support NAP and ISP separate authentication?

> It reads "...PAA MUST be protected by using.

In the previous version, it said "... by using, e.g., IPsec."  I think the text 
was accidentally cut during the editing process of the current version.

> phrases are disconnected.

The two sentenses are unrelated but not written well.  We will revise
the text.  Note that the first sentense is trying to say that
PANA-Bind-Request/Answer messages and subsequent messages will be
protected by MAC AVP.

> make such a case we should capitalize the should(s) in

I agree.

Thanks,

Yoshihiro Ohba