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

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 10 Oct 2003 10:53:12 -0700

o When MSK is updated as a result of EAP re-authentication, what IKE
  should do?  There would be several alternatives:

  - Immediately update the ISAKMP SA by performing IKE phase 1
    negotiation with using a fresh IKE pre-shared key derived from the
    new MSK.

  - The ISAKMP SA is not immediately updated when the MSK is updated.
    In a future IKE phase 1 negotiation performed due to e.g.,
    expiration of the ISAKMP SA lifetime, the IKE pre-shared key is
    derived from the latest MSK available at the time of the
    negotiation.

  - The ISAKMP SA is not immediately updated when the MSK is updated.
    In a future IKE phase 1 negotiation performed due to e.g.,
    expiration of the ISAKMP SA lifetime, the IKE pre-shared key is
    derived from the initially derived MSK, not a new one.

I'm not sure which alternative is appropriate.

o In Sections 6 and 7.2, link-local address is used in outer headers
  in IPv6.  Should link-local address is also used in the case where
  PAA and EP are co-located and PANA runs over an IP-in-IP link (i.e.,
  PaC and PAA/EP are logically one IP-hop away but may be several IP
  hops away at a lower level)?  In such a case, I think using global
  IP address in outer headers of the IPsec tunnel makes sense.  Or
  should the IP-in-IP case be out of the scope of the document?

o In Section 5, replace "phase I" with "phase 1."

o In Section 9,

change:

   "If the PAA does not verify whether PaC is authorized to use an IP
   address, it is possible for the PaC to steal the traffic destined to
   some other PaC. The use of IPsec does not prevent this attack. PAA
   may use other mechanisms to prevent this attack."

to:
   
   "If the PAA does not verify whether PaC is authorized to use an IP
   address, it is possible for the PaC to steal the traffic destined to
   some other PaC. The use of IPsec does not prevent this attack. PAA
   may use other mechanisms such as SEND [SEND] to prevent this attack."
                                                                                
   Where [SEND] refers to draft-ietf-send-ipsec-01.txt.

o In Section 9,

   "When IPv6 is used, the SPD entries bypass all link-local traffic
   without applying IPsec. This should not be a limitation as the link-
   local address is used only by link-local services e.g.
   neighbor/router discovery, which uses a different mechanism to
   protect their traffic. Moreover, this limitation may not be there in
   the future if IPsec extends the SPD selectors to specify ICMP types."

The last sentence seems to imply that PANA can also be used for
bootstrapping IPsec for protecting IPv6 Router Discovery, which could
provide a method to securely performing IPv6 address autoconfiguration
without modifying the existing ESP or AH at all (just a modification
to SPD selectors).  I think it is worth mentioning that.

Yoshihiro Ohba

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