Subject: [Ipsec] handling of inbound SA payloads

From: <[email-masked]>
Date: Wed, 23 May 2007 15:34:48 +0200

Assume an inbound CREATE_CHILD_SA for creating a new IPsec ESP SA
contains an SA payload with three proposals:
 
SA payload
    #1
    ENCR=DES
    INTEG=AUTH_HMAC_SHA1_96
    DH=1024MODP
    ESN=0
    #2
    ENCR=3DES
    PRF=HMAC_SHA1
    INTEG=AUTH_HMAC_SHA1_96
    DH=1024MODP
    ESN=0
    #3
    ENCR=3DES
    INTEG=AUTH_HMAC_SHA1_96
    DH=768MODP
 
Proposal #1 is built correctly
Proposal #2 contains the neither mandatory nor optional PRF
transformation.
Proposal #3 misses the mandatory ESN transformation.
 
What is the appropriate answer to the peer?  The answer could be
an INVALID_SYNTAX notification because proposals #2 and #3 are
malformed.  Or the answer could be a CREATE_CHILD_SA response packet
because proposal #1 is OK to the receiver.
 
Is the simple answer, that local policy decides?
 
Christian

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

---

From: <[email-masked]>
Date: Wed, 23 May 2007 16:58:02 +0300

In my opinion, INVALID_SYNTAX is the best choice. The other end
is broken, and accepting proposal #1 would make it less likely
that the bug gets found and fixed.

Best regards,
Pasi 

> -----Original Message-----
> From: ext [email-masked] [mailto:[email-masked]] 
> Sent: 23 May, 2007 16:35
> To: [email-masked]
> Subject: [Ipsec] handling of inbound SA payloads
>

---

From: Yoav Nir <[email-masked]>
Date: Thu, 24 May 2007 10:05:59 +0300

I'm not sure.  This conflicts with the "liberal in what you accept"  
rule.

I would probably return an INVALID_SYNTAX because of #2 - PRF has no  
business being in a phase 2 proposal, but a lot of people thought  
that not including ESN is the same as not supporting ESN.

What do we do if we get some unknown parameter in #2 instead of the  
PRF?  In the transform type values table, IANA lists 6-240 as  
reserved for IANA, and 241-255 as private use. What do we do if we  
get an attribute from this range? If we drop the whole proposal (even  
thought #1 is acceptable), it would make it very hard to propose  
extensions.

---

From: <[email-masked]>
Date: Thu, 24 May 2007 14:46:42 +0300

Thet ESN confusion was in ikev2-17 draft; there's no ambiguity in
RFC 4306 (which was published already in 2005). So any
implementations based on ikev2-17 ought to be fixed by now...

But you do have a point about unknown parameters. "Private use"
range is always negotiated with Vendor ID payloads, but
presumably, some future version of ESP could need a new 
negotiable parameter.

If the new parameter was largely orthogonal to the existing ones,
we could use notifications (e.g. IPCOMP_SUPPORTED,
USE_TRANSPORT_MODE, ESP_TFC_PADDING_NOT_SUPPORTED and
NON_FIRST_FRAGMENTS_ALSO could have been transform types, but were
added as notifications instead).  Or if this happened as part of
some bigger change, we could increment the IKE version number to
2.1... or we could add a notification saying "I support this
new transform type in the 6..240 range".

But yes, ignoring proposals (but not whole SA payload) that
contains unknown transform types is also one option. What do
other folks think? Should we say something about this in IKEv2bis?
Would it be backwards-compatible with existing implementations?

Best regards,
Pasi 

> From: ext Yoav Nir [mailto:[email-masked]] 
> Sent: 24 May, 2007 10:06
> To: Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: [email-masked]
> Subject: Re: [Ipsec] handling of inbound SA payloads
> 
> get an attribute from this range? If we drop the whole proposal
> (even thought #1 is acceptable), it would make it very hard to
> propose extensions.
> 
<snip>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 24 May 2007 10:40:56 -0400

Yoav Nir wrote:
> I'm not sure.  This conflicts with the "liberal in what you accept" rule.
> 
> business being in a phase 2 proposal, but a lot of people thought that 
> not including ESN is the same as not supporting ESN.

I disagree.
You should definitely log it.
I would agree to defining a notification that tells the peer something that 
it can log.

However, it seems to me that if you require implementations to always 
understand all proposals, then we can never augment/innovate in proposals.

You have a valid proposal. You should use it.

The things you don't understand simply do not exist.

---

From: Yoav Nir <[email-masked]>
Date: Sun, 27 May 2007 11:14:09 +0300

As of the IKEv2 interoperability workshop in March of this year,  
several vendors who shall remain nameless still make proposals with  
missing ESN attributes.

I think the best practice is to ignore proposals I don't understand,  
and not drop the entire payload.

---

From: Yoav Nir <[email-masked]>
Date: Sun, 27 May 2007 11:15:54 +0300

I think both solutions are OK, although I think if we ever find a  
reason to add a PRF to phase 2, we should use a new attribute, like  
CHILD_SA_PRF, rather than overloading the semantics of PRF.

On May 24, 2007, at 5:40 PM, Michael Richardson wrote:

>> I would probably return an INVALID_SYNTAX because of #2 - PRF has  
>> no business being in a phase 2 proposal, but a lot of people  
>> thought that not including ESN is the same as not supporting ESN.
>
> I disagree.
> I would agree to defining a notification that tells the peer  
> something that it can log.
>
> However, it seems to me that if you require implementations to  
> always understand all proposals, then we can never augment/innovate  
> in proposals.
>