Subject: RE: [Ipsec] SPI values for messages outside of an IKE_SA

From: "Lowe Chris" <[email-masked]>
Date: Wed, 29 Jun 2005 14:05:10 -0400

Geoffrey:

You're right, and functionally it will be; but in the interest if good
housekeeping, I would argue to pad the value with zeros.  

Chris

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Geoffrey Huang
Sent: Wednesday, June 29, 2005 1:45 PM
To: Paul Hoffman; IPsec WG
Subject: Re: [Ipsec] SPI values for messages outside of an IKE_SA

Hi Paul,

I prefer to be liberal in what you expect.  That being said, I think the
value should simply be ignored by the recipient.

-g

-----Original Message-----

From:  Paul Hoffman <[email-masked]>
Subj:  [Ipsec] SPI values for messages outside of an IKE_SA
Date:  Mon Jun 27, 2005 8:36 pm
Size:  1K
To:  IPsec WG <[email-masked]>

The current draft of the clarifications document says:

6.9  SPI values for messages outside of an IKE_SA

    The IKEv2 specification does not say what SPI values should be used
    in the IKE header for the small number of notifications that are
    allowed to be sent outside of an IKE_SA.  Note that such
    notifications are explicitly *not* Informational exchanges; Section
    1.5 makes it clear that these are one-way messages that must not be
    responded to.

    There are two cases when such a one-way notification can be sent:
    INVALID_IKE_SPI and INVALID_SPI.  In both cases, there are no IKE
SPI
    values that would be meaningful to the recipient of such a
    notification.

    A strict interpretation of the specification would require the
sender
    to invent garbage values for the SPI fields.  However, we think this
    was not the intention, and using zero values is acceptable.

Can we come to consensus on what to use? If you feel it doesn't matter,
feel free to say that, but if you feel that a particular value is
important, let's try to find it.

--Paul Hoffman, Director
--VPN Consortium

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

_______________________________________________
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: Paul Koning <[email-masked]>
Date: Wed, 29 Jun 2005 14:16:57 -0400

>>>>> "Lowe" == Lowe Chris <[email-masked]> writes:

 Lowe> Geoffrey: You're right, and functionally it will be; but in the
 Lowe> interest if good housekeeping, I would argue to pad the value
 Lowe> with zeros.

Asking for zeroes in the padding rather than arbitrary bytes is fine,
but DON'T require the receiver to check it.  Instead, tell the
receiver to ignore it.

"Be strict in what you send, liberal in what you receive".  Not
checking is more efficient; it also makes future evolution easier.

	 paul

---

From: Henry Spencer <[email-masked]>
Date: Wed, 29 Jun 2005 14:30:04 -0400 (EDT)

> checking is more efficient; it also makes future evolution easier.

On the contrary:  it makes future evolution impossible, because it gives
developers no incentive to fix broken software that sends random non-zero
trash or attempts to misuse those bytes for transmission of private
information. 

                                                          Henry Spencer
                                                       [email-masked]

---

From: Paul Koning <[email-masked]>
Date: Wed, 29 Jun 2005 14:53:54 -0400

>>>>> "Henry" == Henry Spencer <[email-masked]> writes:

 Henry> On Wed, 29 Jun 2005, Paul Koning wrote:
 >> Asking for zeroes in the padding rather than arbitrary bytes is
 >> fine, but DON'T require the receiver to check it.  Instead, tell
 >> the receiver to ignore it.
 >> 

 Henry> On the contrary: it makes future evolution impossible, because
 Henry> it gives developers no incentive to fix broken software that
 Henry> sends random non-zero trash or attempts to misuse those bytes
 Henry> for transmission of private information.

Sure it does.  The next version will break them and they will get NO
sympathy. 

	  paul

---

From: Henry Spencer <[email-masked]>
Date: Wed, 29 Jun 2005 23:36:23 -0400 (EDT)

> Sure it does.  The next version will break them and they will get NO

There can't be a next version if the broken stuff is widely enough used
that breaking it all is judged to be unacceptable. 

See HTML for an example of the nightmares that ensue when receiver
implementers are encouraged to be so liberal that no useful feedback goes
back to sender implementers.

                                                          Henry Spencer
                                                       [email-masked]