From: SourceForge.net <no...@so...> - 2008-02-27 19:14:05
|
Bugs item #1903332, was opened at 2008-02-27 11:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541482&aid=1903332&group_id=74601 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Transform comparison fails RFC-2048 Initial Comment: (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? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541482&aid=1903332&group_id=74601 |
From: SourceForge.net <no...@so...> - 2008-02-27 20:30:31
|
Bugs item #1903332, was opened at 2008-02-27 11:14 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541482&aid=1903332&group_id=74601 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Transform comparison fails RFC-2048 Initial Comment: (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? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-02-27 12:30 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541482&aid=1903332&group_id=74601 |
From: SourceForge.net <no...@so...> - 2008-02-27 22:32:49
|
Bugs item #1903332, was opened at 2008-02-27 11:14 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541482&aid=1903332&group_id=74601 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Transform comparison fails RFC-2048 Initial Comment: (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? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-02-27 14:32 Message: Logged In: NO Yeah, I meant RFC-2408. Whoops. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-02-27 12:30 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541482&aid=1903332&group_id=74601 |
From: SourceForge.net <no...@so...> - 2009-01-16 11:04:11
|
Bugs item #1903332, was opened at 2008-02-27 21:14 Message generated for change (Comment added) made by fabled80 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541482&aid=1903332&group_id=74601 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Transform comparison fails RFC-2048 Initial Comment: (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? ---------------------------------------------------------------------- Comment By: Timo Teräs (fabled80) Date: 2009-01-16 13:04 Message: 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. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-02-28 00:32 Message: Logged In: NO Yeah, I meant RFC-2408. Whoops. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-02-27 22:30 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541482&aid=1903332&group_id=74601 |