Subject: [Pana] review of the framework draft

From: Jari Arkko <[email-masked]>
Date: Mon, 30 May 2005 06:13:01 +0300

I have reviewed draft-ietf-pana-framework-04.txt. Here are
my comments:

Technical:

>       The PAA consults an authentication server in order to verify the
>       credentials and rights of a PaC.  If the authentication server
>       resides on the same node as the PAA, an API is sufficient for this
>       interaction.  When they are separated (a much more common case in
>       public access networks), a protocol needs to run between the two.
>       LDAP [RFC3377] and AAA protocols like RADIUS [RFC2865] and
>       Diameter [RFC3588] are commonly used for this purpose.

LDAP is indeed often used like this, but I'm not sure it is
appropriate to refer to it in this context. I believe you are
trying to describe how PANA works, and I don't think EAP
works through LDAP. (But I have often been surprised.)

>    The secure
>    association protocol exchange produces the required security
>    associations between the PaC and the EP to enable cryptographic data
>    traffic protection.  Per-packet cryptographic data traffic protection
>    introduces additional per-packet overhead but the overhead exists
>    only between the PaC and EP and will not affect communications beyond
>    the EP.  In this sense it is important to place the EP as close to
>    the edge of the network as possible.

I would suggest deleting the last sentence. Bandwidth bottlenecks are
often in the last (wireless) hop, so moving the EP closer to the edge may
not help. And for security reasons it might often make sense to have an
EP further towards the center of the network than at the edge.

>       IKEv2 can enable configuration of one IPv4 IPsec-TIA and one IPv6
>       IPsec-TIA for the same IPsec tunnel mode SA.  Therefore, IKEv2 is
>       recommended for handling dual-stacked PaCs where single execution
>       of PANA and IKE is desired.

I understand this, but I started to wonder whether you have described
all possible combinations somewhere. What is the order of events when
you start to see both v4 and v6 pre-pana connectivity? And how does a
client know it needs to do IKEv2 and a single PANA run?

>    Network-layer protection, i.e., IPsec, can be used when data traffic
>    protection is required but link-layer protection is not available.
>    Note that the keying material generated by an EAP method is not
>    readily usable by IPsec AH/ESP or most link layer mechanisms.  A
>    fresh and unique session key derived from the EAP method is still
>    insufficient to produce an IPsec SA since both traffic selectors and
>    other IPsec SA parameters are missing.  The shared secret can be used

Maybe s/is not readily usable/is insufficient to be used alone/ and
s/A fresh and unique session key derived from the EAP method is still
insufficient to produce an IPsec SA since both traffic selectors and
other IPsec SA parameters are missing/In addition to the fresh
and unique session key derived from the EAP method, IPsec also
needs both traffic selectors and .../

>    When a PaC is authenticated and authorized, the PAA should notify
>    EP(s) and ask for installing filtering rules to allow the PaC to send
>    and receive data traffic.  SNMP is used between PAA and EP(s) for
>    this purpose when these entities are not co-located [I-D.ietf-pana-
>    snmp].

It worries me a bit that determining the exact filters to be used is
not easy, given v4/v6, features like RFC 3041, the need to allow
PANA traffic to go through to PAA, the flexibility in the PANA
framework e.g. to allow both no/L2/L3 protection, and error cases.
I'm reviewing all the documents now -- is the set of filters
to be used specified somewhere?

>    In addition to the device
>    identifier and keying material, other filter rules, such as the IP
>    filter rules specified in NAS-Filter-Rule AVPs carried in Diameter
>    EAP application [I-D.ietf-aaa-eap] may be installed on EP.

Presumably the AAA filter rules are applied for inner packets,
whereas PANA filters are applied on the outer packet, if IPsec
is used. Perhaps this should be stated. What if IPsec is not used,
what is the relationship then?

>    The authentication method choice is a function of the underlying
>    security of the network (e.g., physically secured, shared link,
>    etc.).  It is the responsibility of the user and the network operator
>    to pick the right method for authentication.  PANA carries EAP

I agree that individual methods should not be specified in PANA.
But you might still want to describe requirements, as in RFC 4017
for IEEE 802.11 networks. It may well be that you want to describe
two scenarios -- physical security per line, then maybe mutual auth
is enough, in other scenarios you need key-deriving eap methods.

>  There are some EAP-
>    based approaches to achieve this goal (see [I-D.josefsson-pppext-eap-
>    tls-eap],[I-D.ietf-pppext-eap-ttls]
>    ,[I-D.tschofenig-eap-ikev2]).  PANA can carry these EAP encapsulating
>    methods but it does not concern itself with how they achieve
>    protection for the weak methods (i.e., their EAP method payloads).

I would delete this. There's much more to say about specific methods
if you want to start talking about. I don't recommend starting...

Editorial:

>    are not distinguishable until the PaC associates with the AP, get an

s/get/gets/

--Jari

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