On Fri, Dec 27, 2024 at 1:11 PM Jeffrey Haas <[email protected]> wrote:
> Joe, > > > > On Dec 27, 2024, at 3:25 PM, Joseph Salowey <[email protected]> wrote: > > My concern is that the change to dynamic size could cause problems in > the implementation if all of the recommendations are not followed. > > Then the implementation would be non-conformant. When the normative > procedures aren't followed, the ones with consequences are detailed. > > > 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. > > Avoiding leak was one consideration for zeroing the contents of the > padding. > > We also discussed requests to put test patterns into the padding. > However, validating even simple test patterns may negatively impact line > rate processing for this trivial protocol and we decided we weren't going > to do it today. This impacted the text to be MUST for the set operation. > > The third consideration ended up being the more important detail, which > was that paying attention to the payload not only didn't help the use case, > but lead to hardware based implementations burning precious internal > buffers for empty data. > > It doesn't serve the interests of future implementors in providing deep > advice about the contents of the field beyond telling them what we expect > to be inside. And if, in the future, we decide to leverage the padding for > other purposes like test pattern generation, the MUST be zero provides the > necessary springboard of a baseline expectation for the existing > implementation being extended. > > > > 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. > > The intention of the feature is to permit dynamic updates to it, both as > increases and decreases in padding. The move to zero padding is > effectively such a use case. The procedures describe the appropriate > minimum PDU sizes required for executing the protocol. In circumstances > where the implementation truncates the payload into the PDU existing > procedure happily terminates the session. > > [Joe] Thanks for the explanation and background. I'm happy that the document has the requirement that it does. I can see that checking this value would be problematic for implementations, I was more thinking that the security considerations would mention what could happen if the recommendation was not followed. >From my point of view it's up to the authors whether the consideration should be included or if it is better not to include it as it may cause more confusion. > -- Jeff > >
