#68 Transform comparison fails RFC-2048

closed
nobody
None
5
2009-01-16
2008-02-27
Anonymous
No

(This is in reference to the Sidewinder v7 VPN interoperability thread on the mailing list.)

I have racoon set up on a Mac OS X machine and during phase 2 it emits a single proposal with eight transforms numbered 1 through 8. The Sidewinder it is connecting to selects a single transform, returns a proposal numbered 1 but the transform is numbered 0, so racoon decides the proposal comparison fails (despite the Sidewinder selecting one of the proposals the Mac presents it with.)

From RFC 2048, section 4.2:

"When responding to a Security Association payload, the responder MUST send a Security Association payload with the selected proposal, which may consist of multiple Proposal payloads and their associated Transform payloads. Each of the Proposal payloads MUST contain a single Transform payload associated with the Protocol. The responder SHOULD retain the Proposal # field in the Proposal payload and the Transform # field in each Transform payload of the selected Proposal. Retention of Proposal and Transform numbers should speed the initiator's protocol processing by negating the need to compare the respondor's selection with every offered option. These values enable the initiator to perform the comparison directly and quickly."

Note "SHOULD" - this means that the transform comparison, done by index matching in ipsec_doi.c, is incorrect; the transform comparison should be done based on the enclosed transform properties against the selected transforms that were sent out instead of the index number returned by the remote end.

Alternatively, perhaps the transform comparison by property values should be performed as a last resort in the case the transform indexes fail to compare properly?

Discussion

  • Logged In: NO

    I *believe* that a potential fix to this problem (as alluded to in the last part of my last comment), at line 1041 of ipsec_doi.c in cmp_aproppair_i():

    for (p = a, q = b; p && q; p = p->next, q = q->next) {
    for (r = q; r; r = r->tnext) {
    /* compare trns number */
    if (p->trns->t_no == r->trns->t_no)
    break;
    /* XXX FALLBACK HERE */
    /* compare attribute */
    len = ntohs(r->trns->h.len) - sizeof(*p->trns);
    if (memcmp(p->trns + 1, r->trns + 1, len) == 0 && p->trns->t_id = r->trns->t_id)
    break;
    /* XXX END FALLBACK */
    }

    If I'm reading the code correctly the memcmp() should compare the transform payload parameters and the additional check will check the transform ID.

     
  • Logged In: NO

    Yeah, I meant RFC-2408. Whoops.

     
  • Timo Teras
    Timo Teras
    2009-01-16

    Closing all sourceforge.net bugs. If this issue has not been cared for please submit a new bug report to https://trac.ipsec-tools.net/ issue tracker. Thank you.

     
  • Timo Teras
    Timo Teras
    2009-01-16

    • status: open --> closed