Subject: RE: [Ipsec] Questions about internal address

From: "Timothy Liu" <[email-masked]>
Date: Mon, 11 Apr 2005 16:13:15 -0700

Tero,

Forgive me to butt in. This was not my interpretation when reading
the draft. On page 4:

   ... In all cases,
   all IKE_SA_INIT exchanges MUST complete before any other exchange
   type, then all IKE_AUTH exchanges MUST complete, and following that
   any number of CREATE_CHILD_SA and INFORMATIONAL exchanges may occur
   in any order. 

My take was the IKE_AUTH has to be completed successfully and a child sa

created. I can see it is possible to interpret 'complete' as long as
the ceritificate and AUTH payload checked out to be OK. And rest of it
can fail because of a) proposal mismatch b) traffic selector c) CP
payload d) other(?). Is it too much to call IKE_AUTH complete 
when these other payload process fail?

Tim

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> Tero Kivinen
> Sent: Thursday, April 07, 2005 6:39 AM
> To: Yoav Nir
> Cc: IPsec WG
> Subject: Re: [Ipsec] Questions about internal address
> 
> 
> Yoav Nir writes:
> > On Apr 7, 2005, at 2:25 PM, Tero Kivinen wrote:
> 
> > This says that no CHILD_SA is created, but it does not say that no 
> > IKE_SA is created.
> 
> Yes, that is right. If there is any problems with the IPsec SA if the
> IKE_AUTH, you still do create the IKE SA, but simply fail the IPsec SA
> with error code. This applies to the NO_PROSAL_CHOSEN,
> SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE, FAILED_CP_REQUIRED,
> and TS_UNACCEPTALBE.
> 
> The idea is that we have all the information needed to create the IKE
> SA, and we have already done the Diffie-Hellman, signature
> verification etc, so it would be wasting resources to throw all that
> away, just because there was something wrong with the IPsec SA. If the
> initiator knows how to fix the situation (add CP, change traffic
> selectors, modify algorithms etc) he can do that and initiate
> CREATE_CHILD_SA to create new SAs.
> 
> If he cannot do anything, he can simply delete the IKE SA if he does
> not wnat to have it. 
> 
> > Does this mean that we have an exchange that creates an IKE_SA but
> > not a CHILD_SA?
> 
> Yes.
> 
> > If I understand this correctly, at this point the client is supposed
> > to start a new CCSA exchange with its own IP address.
> -- 
> [email-masked]
> 
> _______________________________________________
> Ipsec mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ipsec
> 

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

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 12 Apr 2005 12:05:40 +0300

Timothy Liu writes:
> My take was the IKE_AUTH has to be completed successfully and a
> child sa created.

IKE_AUTH creates the IKE SA, so that must succeed and be finished
before we can have any other exchanges. That does not say anything
about the initial child SA created inside the IKE_AUTH.

> I can see it is possible to interpret 'complete' as long as the
> ceritificate and AUTH payload checked out to be OK.

There is some text in the draft that indicates that you could do that,
i.e. IKE_AUTH can succeed without creating the child SA in case there
was error while creating it. It would be also pointless to destroy the
IKE SA just because the first IPsec SA could not be created, as the
initiator could try next soem other IPsec SA which can be created. 

> And rest of it can fail because of a) proposal mismatch b) traffic
> selector c) CP payload d) other(?).

Yes. At least NO_PROPOSAL_CHOSEN, SINGLE_PAIR_REQUIRED,
INTERNAL_ADDRESS_FAILURE, FAILED_CP_REQUIRED, TS_UNACCEPTABLE are such
error messages.

The text in the INTERNAL_ADDRESS_FAILURE says: "If this error is
generated within an IKE_AUTH exchange no CHILD_SA will be created.",
i.e. it does not say that the whole negotiation fails, but only that
no CHILD_SA will be created.

I do remember there was other text in the draft indicating same thing,
but I cannot find it now or it might be that it was the discussion on
the list.         

> Is it too much to call IKE_AUTH complete when these other payload
> process fail?

I think the IKE_AUTH succeeded, the CREATE_CHILD_SA included in the
same packet did fail. 
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Wed, 13 Apr 2005 07:16:37 +0300

> but I cannot find it now or it might be that it was the discussion on

This is an interesting point, and I think it should be described in the 
clarifications draft.  Until now I assumed that since the child-SA and 
IKE-SA are negotiated in the same exchange, they either succeed 
together or fail together.  So is this a valid exchange?

        Initiator                          Responder
       -----------                        -----------
        HDR, SAi1, KEi, Ni   -->

                             <--    HDR, SAr1, KEr, Nr, [CERTREQ]

        HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,]
                   AUTH, SAi2, TSi, TSr}     -->

                             <--    HDR, SK {IDr, [CERT,] AUTH,
                                          N(NO_PROPOSAL_CHOSEN)}

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 13 Apr 2005 14:24:42 +0300

> together or fail together.  So is this a valid exchange?

I didn't implement this first, and then someone pointed out me that
this should be accepted (don't remember who, where and how), so I
added this feature just before interop meeting to our code...

I do remember that I did check that myself from the draft and found
out some text there that indicated that it would be acceptable, and
that was the reason I added that code. I couldn't find the text now
when I was searching for it...

This needs to be addressed in the clarifications draft, and I think as
there is cases where the first exchange fails, but later ones can
succeed, it would be waste of resources to do diffie-hellman and
authentication again after each failed negotiation.

Valid cases could be like, the other end has policy from IP1 to IP2,
and the other end has policy of TCP from IP1 to TCP from IP2. Now if
the initiator initiates with the ICMP packet the responder cannot
narrow down the traffic selectors, but he can create IKE SA. When the
initiator tries again with some tcp traffic that will succeed (I used
this as an example as this happend to be exactly the case I was
checking few hours ago in our test lab).
-- 
[email-masked]