Re: [manet] DLEP unspecified handling behavior

["Sipos, Brian J." <[e-mail]>]

Rick,
I agree that your suggested behavior of treat the entire message as malformed is a reasonable one. I just don't see any guidance to implementers in the RFC 8175 text. If there is a goal to have uniformity of handling failures (which is what the IESG prefers standards documents define) then it would be helpful to have an errata written about these cases. Both for how a receiver should handle these signals/messages directly (i.e. treat them as malformed and use none of the data items contained therein) and how the receiver should react to the peer (i.e. for response-eliciting messages, the response must indicate the invalid data was received and ignored).

Currently, even if a receiver does send an Invalid Data response there's no specified guarantee that the receiver also ignored the other data items in the message. This has implications for things like Destination Update data items because a sender is free to only include the items that have "changed" but that change is relative to the last Update that the receiver has accepted. If the sender has an Dest. Update message dropped by a receiver then it may elide future data items that "have not changed" from its perspective but now it's de-synchronized from the receiver. If implementations have differing behavior like that then there's currently nothing to point to as a benchmark of correctness and no motivation for any change in implementation.


> -----Original Message-----
> From: Rick Taylor <[e-mail]>
> Sent: Thursday, November 10, 2022 11:11 AM
> To: [e-mail]; Sipos, Brian J. <[e-mail]>
> Subject: [EXT] Re: [manet] DLEP unspecified handling behavior
> 
> APL external email warning: Verify sender [e-mail]
> before clicking links or attachments
> 
> Hi Brian,
> 
> I politely disagree.  I think in every Data Item description it is explicitly specified
> what the length of the TLV MUST be.  If the length does not match the
> specification, then the TLV is not valid, and therefore a response with Status
> Code "Invalid Data" should result.
> 
> That said, can you highlight a corner case where this can happen?
> 
> Cheers,
> 
> Rick
> 
> On Wed, 2022-08-17 at 21:46 +0000, Sipos, Brian J. wrote:
> > All,
> > This seems like an errata item for DLEP RFC 8175, but it’s really an
> > omission rather than an error in specific existing text. Currently the
> > text in Section 11.3 “DLEP Generic Data Item” indicates the correct
> > TLV encoding for each Data Item but it doesn’t recommend how a
> > receiver of a DLEP signal or message should handle a case where a data
> > item Value contains either more or fewer octets than expected based on
> > the Data Item Type. Some current implementations ignore too- large
> > Value (i.e. treat it as padding) while others treat the signal/message
> > as being malformed and throw the whole thing away (or, worse,
> > mishandle the Value and desync the decoder from the data item
> > alignment causing later phantom data items).
> > It seems like an issue processing an individual data item Value should
> > not cause the entire signal/message to be discarded, but maybe this is
> > desirable behavior…
> >
> > The same kind of logic seems to also apply to signal Length field vs
> > the actual datagram size. Throw away the entire signal or decode the
> > items you can and process that? Treat any additional datagram octets
> > as padding?
> >
> > Any thoughts from the WG?
> > Thanks,
> > Brian S.
> > _______________________________________________
> > manet mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/manet