Subject: Re: [Ipsec] IPsec Failover Problem Statement

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 16 Jan 2007 19:31:56 -0800

Hi Steve,
Thanks for the review and comments. Sorry for the delay in responding.
It looks like this email never made it on the list - so, I'll try to
summarize your comments and respond to them here. 

1. The term IPsec "server" is not defined in 4301, so why is it used
here? 

This term is used to refer to an application server that uses IPsec to
protect the application signaling. From an IPsec perspective, this is no
different than a host implementation of IPsec. However, availability
becomes important due to the entity functioning as an application
server. But, we don't need to use this term as such - we can stick with
RFC4301 terminology and still clarify this. We'll update the draft
accordingly. 

2. "In the reverse direction, the VPN gateway uses the security policy
database (SPD) or associated caches **[STK_2: as per 4301]** to lookup
the relevant IPsec SA, encapsulates the packets and sends to the
appropriate VPN client."

Okay. 

3. "In the security gateway mode, while there may be multiple security
gateways serving a number of remote endpoints, a given remote endpoint
is typically served by one security gateway." [STK_3: Not typically,
ALWAYS. 4301 notes that an SA terminates at one SG to ensure that
fragments all arrive at the same place for reassembly.]

Will correct the wording. 

4. "In all these cases outlined above, it is feasible to perform secure
IPsec and IKEv2 state transfer across endpoints to provide smoother
failure recovery" [STK_4: Secure relative to what standard? Are these
products evaluated under FIPS 140-2, and if so, at what level of
evaluation?]

The term "secure" is used here in the context of the internet threat
model, as documented by RFC3552. We will reword to clarify that. 

5. "In cases where EAP is used for client authentication, the failover
should not require EAP authentication, to avoid AAA overloading and
possible user interaction." [STK_5: The EAP aspects of this problem seem
somewhat independent of the IPsec aspects, since the two protocols are
largely independent.]

It is true that the EAP aspects are different from the IPsec aspects.
However, IKEv2 does support client authentication via EAP and since one
of the primary goals here is to allow a faster failover, this is a
reasonable goal. As stated, this is particularly referring to the case
where EAP is used for client authentication in IKEv2 - perhaps
clarifying that we are referring to IKEv2 there would help? 

6. "Stateless Gateway Operation: The IPsec failover mechanism should
specify a mode of operation that will allow the backup gateways to
remain stateless until a failover occurs or during a temporary service
interruption.This will allow for better scalability of the solution,
since a given gateway only needs to store state for clients that are
being served by it." [STK_6: If a gateway that fails has not transferred
keys and SA data to another gateway, this suggests that the clients will
have to effect such a transfer. But, there may be adverse security
implications of requiring that a client can effect such transfer.]

The basic thought here is to have a solution that allows a server side
operation analogous to stateless TLS session resumption (RFC4507). There
are definitely more security implications to consider as you say -
especially with respect to revocation of the SA, replays of the tickets
issued, etc. However, one of the major benefits of this is that it
allows for a distributed failover mechanism without the need for storing
unnecessary state. We should discuss this further in the context of the
solution design. 

7. "First, any SA storage and retrieval mechanisms specified between the
backend entities must be protected with a secure channel that has the
following properties: confidentiality, integrity, and replay
protection." [STK_7: How about access control? You need to explain
requirements for sync of the SPD among the primary and alternate SGs,
and how this works given the SPD cache model defined in 4301.] 

Yes, most certainly true. I saw that as an essential component of the
solution and did not think the problem statement needed to get into
that. This particular text is referring to the security considerations
on the state transfer itself - that the gateway to gateway communication
must be protected. 

8. "Subsequently, the client must be able to verify the server's
authorization by verifying the proof of possession of the IKEv2 key
material at the new server" [STK_8: Clients do not verify the authority
of a server based on possession of an IKEv2 key. Authorization for an SG
to serve as a peer is defined in the PAD, e.g., based on certificate
validation relative to a trust anchor configured in the PAD, or based on
a PSK in the PAD. I assume you were not referring to the key bits
produced by an IKE exchange. That would conflict with the stateless
requirement established earlier, since an alternate SG would not possess
the ephemeral D-H key used by the primary SG.] 

I believe the use of the term "authorization" in that statement is
incorrect. It is only intended to refer to verifying the presence of the
IPsec SA in the new server. We will reword to reflect that. 

Thanks,
Vidya

> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]] 
> Sent: Tuesday, January 09, 2007 10:14 AM
> To: Narayanan, Vidya
> Subject: comments on your draft
> 
> I sent this to the ipsec list, but it is held up due to the 
> size of the PDF.
> 
> Steve
> 

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