Subject: RE: Establishsing an IPsec SA between PaC and EP

From: "Mohan Parthasarathy" <[email-masked]>
Date: Fri, 21 Mar 2003 17:29:24 -0800

Ray,

Some responses below though some others have responded. My responses are tagged
with "mohanp".

[Ray Bell] Some thoughts/response to your questions...

We discussed about creating an IPsec secutity association 
between PaC and EP using PANA SA in the meeting. Following are some first 
thoughts on this topic. 

1) If PAA and EP are not co-located, need to discover the IP address of EP also 
   so that an IPsec SA can be established.
[Ray Bell]  I assume you mean an IPSec SA between the PAA and EP (i.e., PaC<-->EP<-->PAA), which would require a two-step IPSec configuration to be implemented: one SA between the PaC and EP, and one SA between the EP and PAA.  Since IPSec Clients are common on most hosts, it may be more simplistic to allow an IPSec SA between the PaC<-->SAA, where the EP is configured to route IKE & IPSec.
In terms of the either the "two-step" or "one-step" approach, the general method for configuring IPSec on most implementations requires predefined SA Peer relationships (configurations), which contain the IP Address as well as the IKE & IPSec security & encryption configuration settings & key material relevant to the specific peer. Some implementations support a "dynamic" configuration which enables a "peer using a dynamic IP Address" to generate a "run-time" SA Peer configuration.  So, I don't believe there is a discovery issue.  

mohanp> You need to know the address of EP for you to establish an SA. PAA and EP
need not be co located. In that case, you need the ability to discover the IP address
of EP also in addition to PAA.

2) If there are multiple EPs, pick one EP with which you want to establish an 
   IPsec SA. Otherwise becomes a bit messy as you have to establish multiple 
   SAs (implies that you discover all the EPs IP addresses). 
[Ray Bell] Most IPSec implementations support multiple IPSec SA peer relationships, and higher level packet filtering methods (generally based on 5 tuple filters) are used to determine which packet flow either establishes an SA or gets bound to an existing SA.  If we want to look at automatic failover between the EP and SAA, we may want to discuss using GRE/IPSec methods.

mohanp> What is an SAA ?

3) The nodes (PaC and EP) need the ability to dynamically add SPDs ( which is 
   an implementation issue) 
4) If you need to terminate the IPsec SA at the EP, you need two things : 
        1) Use tunnel mode IPsec SA, as the PaC most likely would be sending packets 
               that are destined to some other node in the internet. The outer header's 
              destination address would be EP and inner destination address would be 
           the final destination. 
[Ray Bell] If the PaC has a public IP Address, then you could use transport mode.  Not sure of the issue you are pointing out.  

mohanp> i am talking about the destination address. IPsec SA is looked up using
destination address and SPI. On EP, when you get a packet, you need the
destination address on the IP header to that of EP so that the SA can be looked up.
If the PaC is sending packets else where, you need tunneling.

        2) As all packets are being sent to EP (as an effect of terminating the 
           tunnel at EP), EP should be next hop default router i.e EP is the AR 
           itself. 
[Ray Bell] Not sure of the issue which you are pointing out.

mohanp> see above.

5) We have to do double IPsec if the client is already using IPsec tunnel back to 
   his/her coroporate network. This case may be more interesting and need lot of 
   details on how SPD entries look like, how IKE works etc. 
[Ray Bell] IPSec SAs are flow specific (generally based on five tuple filter methods for dynamically setting-up the SA), so multiple SAs are the norm.  The "Authentication SA" (PaC<-->EP<-->SAA  or PaC<-->SAA) may be different than the "Enterprise VPN SA" (PaC<-->EP<-->Corporate_EP  or  PaC<-->Coroporate_EP). 

mohanp> We have learnt in other working group (Mobile IP) that writing down these
details can make life very interesting.

6) Need some details on what is exactly being passed on to EP. e.g., keys, identity 
   information etc. 
[Ray Bell] Not sure of the issue you are raising (IKE & IPSec materials?). 
mohanp> Yes.

7) More details to think about.. 

-mohan

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 24 Mar 2003 13:51:01 -0800

Alper,

> 
> > 1) If PAA and EP are not co-located, need to discover the 
> IP address 
> > of EP also  so that an IPsec SA can be established.
> > 
> > 2) If there are multiple EPs, pick one EP with which you want to 
> > establish an  IPsec SA. Otherwise becomes a bit messy as 
> you have to 
> > establish multiple  SAs (implies that you discover all the EPs IP 
> > addresses).
> 
> Discovering one or more EPs might not be significantly different.
> 
We have different scenarios where AR and EP may or may not be
colocated. Just want to make sure we address them.
From what I stated later, I think AR and EP have to be
colocated i.e I want to send all my packets to EP (as that's where
Ipsec is terminated) which means your nexthop is EP i.e the access
router.

> If there are multiple ARs on a link, and ARs are used as EPs, 
> then  I think it is reasonable to enable PaC to establish 
> IPsec SA with every one of them. Of course it doesn't have to 
> do that. It can choose to use a subset of them as its default router.
> 
> 
> > 
> > 3) The nodes (PaC and EP) need the ability to dynamically 
> add SPDs ( 
> > which is  an implementation issue)
> > 
> >              that are destined to some other node in the 
> internet. The 
> > outer header's
> > 5) We have to do double IPsec if the client is already using IPsec 
> > tunnel back to  his/her coroporate network. This case may be more 
> > interesting and need lot of  details on how SPD entries 
> look like, how 
> > IKE works etc.
> 
> I heard this before. Are there really issues here with double 
> IPsec tunnels? Is this a protocol issue, or an implementation issue?
> 
It might be more of an implementation issue. But we need to work
out the details so that we understand it better :-)

> 
> > 
> > 6) Need some details on what is exactly being passed on to 
> EP. e.g., 
> > keys, identity  information etc.
> > 
> alper

-mohan