Martin Duke has entered the following ballot position for draft-ietf-ipsecme-iptfs-13: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- One point which I think will be simple to address: (6) As malformed packets are sometimes an attack vector, it would be good to specify behavior in response to pathological BlockOffsets, for instance: - What if two BlockOffset fields disagree? e.g., with 500 byte outer packets, what if the sequence of block offsets is {0, 750, 100}? Does the third packet have 250 or 100 bytes of the first data block? Drop the packet, kill the SA, ignore one and accept the other, or something else? - What if a pad block is in a packet with a BlockOffset greater than the packet length? Would the receiver skip over the specified bytes in the subsequent packet, even though padding is supposed to only be at the end of packets? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to Joe Touch for 2 TSVART reviews, and for addressing his comments. Also thanks for the very literate discussion of congestion control. (2.2.3) It would be nice to at least suggest a default number for the reordering window. In TCP, we traditionally use 3, but really any suggestion for the clueless is fine. (3) Please clarify: is TsVal the actual tranmission time, or the time the packet is queued for the next transmission opportunity? (3) This probably just needs a bit more explanation, but reading this document, and not knowing much about ESP, I could not figure out the case where the return path does not support AGGFRAG_PAYLOAD. IIUC, IKEv2 negotiates this for the pair explicitly, so this case cannot arise. Otherwise, how is this negotiated? Why would a tunnel endpoint support just AGGFRAG without payloads but not with? NITS (2.4.1) update the [RFC8229] reference to RFC8229bis? (6.1) "The value 5 was chosen to not conflict with other used values." IIUC the values here are just Protocol numbers from the registry. So maybe it's better to be more explicit and say that this cannot be used with RFC1819 streams? _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
