Subject: RE: [Ipsec] Proposal and Transform Payloads

From: Joern Sierwald <[email-masked]>
Date: Wed, 20 Oct 2004 09:02:55 +0200

At 16:19 19.10.2004 +0100, Case Richard A wrote:
>Thanks to Jörn for his comments. I've now read the dictionary definition of
>"monotonically" and the RFC makes a bit more sense.

The RFC is a victim of poor writing in this case. It should have said "use 
1,2,3...".

>However, this does raise other questions:
>
> >>    * Does the order of preference decrease with increasing
> >> Proposal/Transform numbers? i.e. 1 is most preferred, 2 is next most
> >> preferred, etc...
> >No, the order does not mean anything. While there are implementation who
> >treat the list like that,
> >this is not a universally valid logic
>
>If this is the case, are there implementations that ignore RFC 2408, section
>4.2 ("The multiple transforms MUST be presented with monotonically
>increasing numbers in the initiator's preference order.") ?
>
>In which case how does the responder know in which order to process the
>transforms?
>Presumably by making a note of all Transforms, discarding incompatible
>options and selecting from the remaining Transforms in its own preference
>order?
>
>Thanks again,
>Richard

The point I was trying to make (but failed) was that while the initiator
can put things in a certain order, the initiator has no say at all which one
will be picked. The responder will choose. And the thing that matters is the
(internal) list in the responder's policy. Most implementations will do
exactly what you write in your last sentence.

So even if the initiator sends a list (3des, sha-1; 3des, md5) and the
responder allows both, it does not mean that the 1st one (3des, sha-1) will
be picked.

Jörn

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

---

From: Paul Koning <[email-masked]>
Date: Wed, 20 Oct 2004 09:42:07 -0400

>>>>> "Joern" == Joern Sierwald <[email-masked]> writes:

 Joern> At 16:19 19.10.2004 +0100, Case Richard A wrote:
 >> Thanks to Jörn for his comments. I've now read the dictionary
 >> definition of "monotonically" and the RFC makes a bit more sense.

 Joern> The RFC is a victim of poor writing in this case. It should
 Joern> have said "use 1,2,3...".

"monotonically increasing" allows 3,8,2000 (but not 8,3,2000).
Certainly 1,2,3 meets the requirement but so do other sequences.

Are you saying that implementers should just use 1,2,3?  That's fine.
Or did you mean that any sequence OTHER than 1,2,3 should be
prohibited?  That would be a change to the spec.

       paul

---

From: Joern Sierwald <[email-masked]>
Date: Wed, 20 Oct 2004 16:42:51 +0200

>prohibited?  That would be a change to the spec.

Ever since I have read the specs I had the feeling that the writer
_intended_ to specify numbers increasing by one (like, 1,2,3,4...) but
chose the term "monotonically" instead, without really understanding
what that meant. I might be wrong.

Now, I think everybody should send 1,2,3,4. We (and other people using
SSH code, I presume) used to send 0,1,2,3... but icsa kindly asked
us to change that some years ago.
On the other hand, Tero Kivinen has tested lists with
odd numbering (such as 3,8m32000) and some
implementations did not quite like them.

So, here again the very old guideline: Send out very nice, well-mannered
data but expect the worst in your input buffer.

Jörn