Re: [Pana] review of the framework draft

[Yoshihiro Ohba <[e-mail]>]

Hi Jari,

Thank you very much for the review.  Please see my comments in line.

On Mon, May 30, 2005 at 06:13:01AM +0300, Jari Arkko wrote:
> 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.)

I think we can simply remove "LDAP [RFC3377] and ".

> 
> >   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.

In which case it would make sense for security reasons to have EP
further towards the center of the network?

> 
> >      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?

I agree that we need to describe all possible combinations when the
PaC starts from having both v4 and v6 PRPAs.  I think it is better to
create a new issue on this.

> 
> >   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 .../

I agree.

> 
> >   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?

draft-ietf-pana-snmp specifies filters, but the draft does not specify
which specific filters should be used for each of the above scenarios.
However, I think such detailed choice of filters is better to be left
open to implementations.

> 
> >   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. 

I agree.  

> What if IPsec is not used,
> what is the relationship then?

When IPsec is not used, the filters are applied to the non-protected
IP data packets.

> 
> >   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.

I think describing the generic EAP method choices for the two
scenarios is a good idea.

> 
> > 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...

I agree.

> 
> Editorial:
> 
> >   are not distinguishable until the PaC associates with the AP, get an
> 
> 
> s/get/gets/

OK.

Yoshihiro Ohba


> 
> --Jari
> 
> 
> _______________________________________________
> Pana mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/pana

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