HI Jeff,
Thanks for the quick response.
My concern is that the change to dynamic size could cause problems in the implementation if all of the recommendations are not followed.
For example if the expanded packet size is not zeroized then it is possible that information could be leaked in the padded data. The document does require that the padding be zero so the document has appropriate guidance, but there have been problems like this in the past. It's been quite some time since I've been in the transport code, so maybe this concern has been overtaken by events, if not, it might be worth mentioning. It might be possible that there could also be implementation problems introduced if the size was reduced rather than expanded, although it seems like this is something that should already be handled.
I'm not sure that this captures Brian's concerns so he may have additional feedback.
-- Joe
On Fri, Dec 27, 2024 at 11:45 AM Jeffrey Haas <jhaas@xxxxxxxx> wrote:
Joseph,Brian has failed to answer my reply about what I consider to be a non-issue:Please more clearly articulate why you think dynamic packet sizing is problematic. Brian's consideration seemed to be a worry about where in the OSI stack the sizing was going to be.-- JeffOn Dec 27, 2024, at 2:35 PM, Joseph Salowey via Datatracker <noreply@xxxxxxxx> wrote:Reviewer: Joseph Salowey
Review result: Has Nits
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.
The summary of the review is the document has minor issue.
Please see Brian Trammell's review. I think he makes a good point about the
packet sizes changing to be dynamic. I think the authors should consider adding
a sentence about the change to dynamic packet size.
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
