Note Hugh had one comment regarding the "stop reading when you found an acceptable proposal to return". It could be that the unread remainder of the proposal/transforms are badly formed. It could be argued that we should return NO_PROPOSAL_CHOSEN or INVALID_SYNTAX.
for example, the case where the initiator sends proposals numbered #1, #2, #4. Technically, we should reject everything. Your proposed solution would allow us to use #1. I understood both views. I tempted to lean towards being okay to ignore and have unparsed parts of a proposal tree. But there is some security impact - for example it could allow an attack to insert arbitrary length data into the packet for some cryptographic attack. Limiting the proposals to only valid syntax would prevent that. So perhaps possibly the best solution is to confirm the proposal list as valid, but return the first mutually agreed match? Paul _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
