Re: [manet] DLEP unspecified handling behavior

Rick Taylor <rick@tropicalstormsoftware.com> Thu, 10 November 2022 16:11 UTC

Return-Path: <rick@tropicalstormsoftware.com>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6761BC1522C1 for <manet@ietfa.amsl.com>; Thu, 10 Nov 2022 08:11:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWqDZz_akill for <manet@ietfa.amsl.com>; Thu, 10 Nov 2022 08:11:18 -0800 (PST)
Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B639C1524A8 for <manet@ietf.org>; Thu, 10 Nov 2022 08:11:18 -0800 (PST)
Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::48e4:acbb:6065:8168]) by tss-server1.home.tropicalstormsoftware.com ([fe80::48e4:acbb:6065:8168%16]) with mapi id 14.03.0513.000; Thu, 10 Nov 2022 16:11:15 +0000
From: Rick Taylor <rick@tropicalstormsoftware.com>
To: "manet@ietf.org" <manet@ietf.org>, "Brian.Sipos@jhuapl.edu" <Brian.Sipos@jhuapl.edu>
Thread-Topic: [manet] DLEP unspecified handling behavior
Thread-Index: AdiygQ0GHmfIujp6Rj6cKmzngMu+fBCngAQA
Date: Thu, 10 Nov 2022 16:11:15 +0000
Message-ID: <6b4348e0c656184669b29d274128ffc92c758595.camel@tropicalstormsoftware.com>
References: <14dba05a30954e208cb6b55d8cdee712@jhuapl.edu>
In-Reply-To: <14dba05a30954e208cb6b55d8cdee712@jhuapl.edu>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Evolution 3.44.4-0ubuntu1
x-originating-ip: [2a02:1648:4000:120::5]
Content-Type: text/plain; charset="utf-8"
Content-ID: <B2E99EA988F2E6449D1695B8F132AF98@home.tropicalstormsoftware.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/sl3EYtJyl4OkcsLGZTVDEkpMVm8>
Subject: Re: [manet] DLEP unspecified handling behavior
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/manet/>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Nov 2022 16:11:22 -0000

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
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet