[Pana] comments on draft-ietf-pana-ipsec-00.txt

[Jari Arkko <[e-mail]>]

I have read draft-ietf-pana-ipsec-00.txt, and I have a few
comments. Apologies if this has been discussed before, I was
unable to participate the WG session due to other commitments.

Here are the comments:

- Section 3.0, bullet 3. This document appears to assume
   that the IPv6 node has a single address. What about RFC 3041
   etc?

- Section 4.0, Session ID. I'm glad that the document uses
   a session ID -- those are indeed needed, as it is possible
   that more than one EAP session was run, and we need to know
   where to refer to.

   However, I still have one problem with this. The problem
   is that it is not enough to use the Session ID as a part
   of the IKE pre-shared secret. It is also necessary to
   carry the session id information in IKE so that the
   two peers know which key to use.

   How do you intend to do that? The usual IKE payloads don't
   appear to carry this information, though it might be that
   ID_KEY_ID identity type might be usable. (The IKEv1 documents
   appear to imply that this type is normally used for vendor
   specific identification.) Or perhaps a new IKE identity type
   is needed.

- Section 5.0, manual keying comment. It seems inappropriate.
   The purpose of PANA is to do an auth and then use those keys
   to protect traffic. If manual keys were used in IPsec, those
   would not be linked to the authentication, so it does not seem like
   a valid combination.

- Section 5.0, main mode. I think the IP addresses are apparent
   from the packets themselves, but the session ID would have to
   be transported (perhaps in the identity payload) to distinguish
   possibly different EAP runs that you had done before. However,
   this seems problematic, as IKEv1 pre-shared secret mode does
   not allow the transport of the identity before the identity
   needs to be known. Are you relying on IKEv2, or would you have
   to resort to the use of aggressive mode only?

- Section 5.0, aggressive mode. I don't understand what the
   issue with link-locals is. If the link-local addresses were
   not unique, how would the client - EP communication succeed
   in the first place? Anyway, as I said above I think the ID_KEY_ID
   may be needed just to differentiate EAP runs.

- Section 6.0, I wish there was some notation to show that the
   inner and outer addresses are different. They are, right?
   The text is vague since it only talks about the outer addresses
   being link-local, but does not say anything about the inner
   addresses.

- Section 7.2, ICMP type selectors. I believe this was added
   to the IPsec documents a couple of months ago. They are not
   RFCs yet, but neither is PANA, so maybe you could refer to them.

   And if you do that, you could use more specific SPD entries,
   as suggested by draft-arkko-icmpv6-ike-effects-01.txt. Its
   expired, but you can find it here:
   http://www.arkko.com/publications/draft-arkko-icmpv6-ike-effects-01.txt

- Section 9.0, stealing another PaC's traffic. This is interesting.
   I believe you are talking about the *inner* addresses in the packets,
   right?

   Note that if the PAA were responsible for inner IP address assignment,
   this would not be a problem. But I'm not sure how. Perhaps you could
   use IKEv2 and its address assignment function, then the EC and PAA
   would communicate via a AAA protocol to get the address. But this
   needs more thought. Bernard, do you know what 802.11i says about
   this subject? It seems that its a similar issue in there.

   Or is there a need to do some SEND-like address ownership
   verification? I'm not sure how all the pieces fit together.
   Is there a PANA document somewhere that describes what the
   other mechanisms are that you say the PAA can use?

Editorial:

- I don't see how the NC-DC-PL-DRL discussion fits section 7.2.
   Move it elsewhere?

- s/TUNEL/TUNNEL/g

--Jari



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