[Last-Call] Re: Secdir last call review of draft-ietf-bfd-large-packets-14

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Joe,


> On Dec 27, 2024, at 3:25 PM, Joseph Salowey <joe@xxxxxxxxxxx> 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.

-- Jeff

-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux