Subject: RE: comments to your pana/ipsec draft

From: "Mohan Parthasarathy" <[email-masked]>
Date: Sun, 18 May 2003 21:22:19 -0700

Hannes,

Thanks for your comments. Here are my responses with "mohanp"

1) 
      The PANA protocol itself stops  

   here and does not discuss any methods for preventing service theft in  
   the access network. The service theft can be prevented by simple IP  
   address and MAC address filters, if the link between PANA client and  
   PANA agent is a n
# actually it does not "stop" since you have the refresh/reauthentication messageson-shared medium.
# With this sentence i would argue that PANA still discusses methods for preventing theft
# service. We "discuss" these mechanisms (such as IPsec) in the PANA draft itself. 
# Furthermore, we have also spoken about link layer security establishment which also 
# prevents threft of service. The PANA draft does not go beyond saying that IPsec SA should
# be established based on a derived key and the IP address of the IPsec end point has to 
# be known.

mohanp> Ok, i will reword it. 

2) 

 Please refer to [PANAREQ] for terminology and definitions of terms  
   used in this document. The following picture illustrates what is  
   being protected with IPsec. In Figure 1, it is assumed that PAA and  
   EP are co-located. It is also possible that they are not co-located. 

# if it does not really matter whether they are co-located or not then the figure 
# might not be too useful. 

mohanp> It is still useful to have a picture for folks not following
mohanp> PANA closely.

3)

4.0  Communication between PAA and EP  
     
   If the network chooses IPsec to secure the link between PaC and EP,  
   PAA should communicate the IKE pre-shared key, the IP address of the  
   PaC and the PANA session ID to EP before the IKE exchange begins.  

# i assume that the pana session id is used for the purpose of accounting and state maintainance

mohanp> The pana session id here is used in agressive mode. 

4) 

 established when PaC and PAA successfully authenticate to each other.  
   Pre-shared key is derived from the PANA SA using a prf (e.g. SHA-1).   

# in a future version of the draft we need to be more concrete about the key derivation. 
# reading [EAP_KEY] i got the impression that pana needs to use its own key derivation function to produce additional keying 
#    material.      
# i would, however, be good to have a unified approach to address key derivation in pana. 
  
mohanp> Agreed.

5) 

.0 IKE and IPsec details  
     
   IKE [IKE] MUST be used for establishing the IPsec SA.

# why ike only? why not ikev2?

mohanp> Not any specific reason. I will mention it in the next revision.

6) 
 Manual keying  
   may not be possible, as the network does not know all the PaCs that  
   will be authenticating to the network, a priori.

# this is actually not the true reason. manually establishing an ipsec security 
# association requires that you agree on the parameters (algorithms, algorithm parameters), 
# SPI and on the Traffic Selector attributes. 
# this would require an additional exchange within pana. 
# the details :http://www.isrc.rhul.ac.uk/shaman/docs/d13a1v1.pdf
# (annex b) 

mohanp> I am not sure i understood the comment. When you start exchanging, things
mohanp> are not manual anymore. And, are you exchanging keys also above ? All
mohanp> i am saying is that it is not possible to pre-configure SAs (which contains
mohanp> keys, algorithms to use, lifetimes, etc.) on EP without knowing the
mohanp> PaC's a priori. Why is this not a true reason ?

7)  

# typically specifications mandate main mode and not aggressive mode. 
# i assume you changed this due to performance reasons.

mohanp> This is really flexible at this stage. We can change it in the
mohanp> next revision.

8)
 PaC and EP  
   SHOULD use its IP address as the client identifier in main mode and  
   PANA session ID [PANA-PROT] as the payload of ID_KEY_ID in aggressive  
   mode for establishing the Phase I SA.  
# why is this necessary? couldn't the ip address also be used as a selector for the key?

mohanp> Sure. Francis had a comment about link-local collision. Not sure i understood
mohanp> about it.

   After Phase I SA is established, quick mode exchange is performed to  
   establish an ESP transport mode IPsec SA for protecting the traffic  
   between PaC and EP. The packets are still tunneled between PaC and EP  
   as described later. But there is just one SA on the PaC for all the  
   traffic flow between PaC and EP.

# there are always two ipsec sas - one for each direction. 

mohanp> Yeah, that was meant to say there are no more SAs.

9) 

In case of IPv6, the outer IP header's addresses SHOULD be the link- 
   local address of PaC and EP.  

# i might not have captured the reason for this. could you explain?

The way it is specified, the only on-link prefix is link-local address.

10)

EP's SPD IN:  
            IF source = PAC-ADDR & destination = EP-ADDR &  
             protocol = IP-in-IP  
             THEN USE ESP TRANSPORT SA  

# isn't this is fairly complicated way to say that you use ipsec in tunnel mode?

No. The real reason is Double IPsec. Please see my other response.

11) I will read the useipsec by S. Bellovin later on to see how it can be applied here.

12)

# i guess that the problem is that ike does not allow identity payloads to contain 
# traffic selectors with such a granularity. 

Even the SPD as defined in RFC2401 does not allow it.

13)

This may  
   be a problem in some cases.

# in which cases is this a problem?

It is a extra hole in EP. An unauthorized PaC can still exchange link-local traffic
on the network using the resources of the network.

-mohan

---

From: Francis Dupont <[email-masked]>
Date: Mon, 19 May 2003 09:49:09 +0200

In your previous mail you wrote:

   
   
=> IKEv2 doesn't exist yet. If your argument is about s/MUST/SHOULD/,
I agree.

   6)  Manual keying  

=> the pana/ipsec document doesn't discuss about the usage of PANA
itself to establish the SAs. Perhaps a comment should put this kind
of solutions outside its scope?
   
   8) PaC and EP  

   # why is this necessary? couldn't the ip address also be used as a
   # selector for the key?
   
   mohanp> Sure. Francis had a comment about link-local collision. Not
           sure i understood about it.
   
=> link-local addresses are not good unique identifiers, so instance
if the EP has multiple interfaces it is possible to get the same
link-local address for more than one PaC which gives hard implementation
problems. In main mode we have no choice because the ID is available
very late, but in aggressive mode we can use the best ID to point to
the right shared secret, and obviously the ID_KEY_ID is this best ID type.

=> there is a trade-off: to be very accurate (i.e., talk about SA pairs)
or to be readable (i.e., assume that expert readers know SAs come by pairs).
   
Regards

[email-masked]

---

From: Alper Yegin <[email-masked]>
Date: Mon, 19 May 2003 13:34:20 -0700

> on the network using the resources of the network.

Can we not force the link-local traffic to use the IPsec tunnel?

Alper

---

From: Francis Dupont <[email-masked]>
Date: Mon, 19 May 2003 23:23:21 +0200

=> by definition link-local traffic can't be forwarded... So
we can't assume this kind of capability from the IPsec implementation.
Note that the IP over IP interface makes this even more impossible
(link-locals are local to a link, the IP over IP is a different link
than the link it runs over).

Regards