Re: [pim] draft-ietf-pim-igmp-mld-extension WGLC
"Holland, Jake" <jholland@akamai.com> Thu, 21 January 2021 20:02 UTC
Return-Path: <jholland@akamai.com>
X-Original-To: pim@ietfa.amsl.com
Delivered-To: pim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8D73A0BD9 for <pim@ietfa.amsl.com>; Thu, 21 Jan 2021 12:02:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.349
X-Spam-Level:
X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULDV7Mae6nn4 for <pim@ietfa.amsl.com>; Thu, 21 Jan 2021 12:02:52 -0800 (PST)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E70663A0B8C for <pim@ietf.org>; Thu, 21 Jan 2021 12:02:29 -0800 (PST)
Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.43/8.16.0.43) with SMTP id 10LJtQLN028693; Thu, 21 Jan 2021 20:02:28 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=iwyNG0b5+IR0T05fqRUXWfxyPUPOebez7F6pZMP4Nfc=; b=B+Ni/22jbJwqKSfhJlNCnpSAv3Yxqtisp72pz+vOVCA8x5zv86G7iC/DGofWoTosFsop 3tMKQXTbe29T2ctalMBZ5vqc0lgnuY9Cv7aaxo8MB7d85R7TC++n0zLD7MoBxYM40wsV uUfRAVZXTLqWodihVfd1klSSwwmVhDAjber14OSrC4TWjCdf5VRSfjSF/9QybsMZ/28g 6wxjJ9NaxBHLfUlqG8s8w6j/3OaUXn2/eb3qukfFTKdcaUQYICt39z08Ff30YweUHjfw 1LrhUSxt0I6V15bfsb3oszjo/QYGQRgqzQy3oOjvrj2Ty4Gg+Wp8zef0NLbZ09fh7RXQ eg==
Received: from prod-mail-ppoint8 (a72-247-45-34.deploy.static.akamaitechnologies.com [72.247.45.34] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 3668rch5md-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 Jan 2021 20:02:27 +0000
Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.0.43/8.16.0.43) with SMTP id 10LJZ80Y012283; Thu, 21 Jan 2021 15:02:26 -0500
Received: from email.msg.corp.akamai.com ([172.27.165.112]) by prod-mail-ppoint8.akamai.com with ESMTP id 366969h5n0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 21 Jan 2021 15:02:26 -0500
Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com (172.27.165.122) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.165.123) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 21 Jan 2021 14:02:26 -0600
Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com ([172.27.165.122]) by ustx2ex-dag1mb4.msg.corp.akamai.com ([172.27.165.122]) with mapi id 15.00.1497.010; Thu, 21 Jan 2021 14:02:26 -0600
From: "Holland, Jake" <jholland@akamai.com>
To: Stig Venaas <stig@venaas.com>
CC: "Jeffrey (Zhaohui) Zhang" <zzhang=40juniper.net@dmarc.ietf.org>, Leonard Giuliano <lenny@juniper.net>, "jakeholland.net@gmail.com" <jakeholland.net@gmail.com>, "pim@ietf.org" <pim@ietf.org>
Thread-Topic: [pim] draft-ietf-pim-igmp-mld-extension WGLC
Thread-Index: AdbM9ydl4gZ07lhpQVe0ISlVhcHfugGWSsKAAGt8OIAFssRoAAAmN/SAAJfzfID//5E/gIADrb0A//98IAA=
Date: Thu, 21 Jan 2021 20:02:25 +0000
Message-ID: <C2C28C3B-55F7-44A4-AC33-ADB561726D90@akamai.com>
References: <BYAPR13MB25823AD8346977BC1FDE03BAF4CD0@BYAPR13MB2582.namprd13.prod.outlook.com> <MN2PR05MB598123DADDC8916389A69111D4C50@MN2PR05MB5981.namprd05.prod.outlook.com> <CAHANBtL7FXijAajqmz-vU+vZ_OUZ7XS7wynZgHF-x9TSukRhDA@mail.gmail.com> <CAHANBtLsasH1ZTT4tmLwvLaQ3NE4KuOzrmb_fqOcH3fcapUWkg@mail.gmail.com> <A725AB8B-6F24-45C1-BF44-854DD115EAE4@akamai.com> <CAHANBtJEHOKKYJER7wPPTAjpAb90LC0GiaU1QhE+4-wFeuNupA@mail.gmail.com> <1E3BA012-B836-43E6-92EC-9992531A3813@akamai.com> <CAHANBtKEYwu=f4-JMmT-BA865Ft7H0jo2JX3fQbh+2=KSaDXGQ@mail.gmail.com>
In-Reply-To: <CAHANBtKEYwu=f4-JMmT-BA865Ft7H0jo2JX3fQbh+2=KSaDXGQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.44.20121301
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.27.164.43]
Content-Type: text/plain; charset="utf-8"
Content-ID: <DCE58AF9C6B97A48AD3689F8D74BC9B2@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-21_10:2021-01-21, 2021-01-21 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 bulkscore=0 adultscore=0 mlxscore=0 suspectscore=0 phishscore=0 spamscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101210100
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-21_10:2021-01-21, 2021-01-21 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 phishscore=0 mlxlogscore=999 bulkscore=0 spamscore=0 adultscore=0 suspectscore=0 clxscore=1015 malwarescore=0 priorityscore=1501 impostorscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101210101
X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.34) smtp.mailfrom=jholland@akamai.com smtp.helo=prod-mail-ppoint8
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/9tnMBSJOeous--4Jk-DYyhlDRXY>
Subject: Re: [pim] draft-ietf-pim-igmp-mld-extension WGLC
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim/>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Jan 2021 20:02:54 -0000
Thanks Stig, much appreciated. -04 Looks good to me. Best regards, Jake On 1/21/21, 11:54 AM, "Stig Venaas" <stig@venaas.com> wrote: Hi Jake I just posted revision 04 that I think should address your comments. Agree buffer-overflow is a big concern in general, I'm happy to call it out in the document. Thanks a lot for your time, Stig On Tue, Jan 19, 2021 at 11:43 AM Holland, Jake <jholland@akamai.com> wrote: > > Hi Stig, > > On 1/19/21, 10:21 AM, "Stig Venaas" <stig@venaas.com> wrote: > > I do believe TLVs really is flexible enough for any future extension > > and I mentioned this since people might question why we don't need > > Additional Data when the extension is used. But I can certainly remove > > this. The main point is that there is no data besides the Extension > > TLVs. I'll try to improve this text. Of course we are also able to > > extend IGMP/MLD in other ways when not setting the E-bit if we want. > > I agree it's likely to be flexible enough, but I have minor reservations > about stating it as a known fact (as in -03), because it's hard to be > certain that all future needs will be fully compatible with the semantics > defined for these TLVs. (And I agree if it happens then it can be covered > by using something else other than the E-bit). > > I'm not sure it needs anything pointing out the flexibility to future > needs, but if you think it will help forestall questions to include it, > even just "is flexible enough" -> "is expected to be flexible enough" > would address my reservation. > > >> 1.a. > >> Sorry, I should have noticed this in my first review. But while revisiting > >> this, I noticed that the MLDv2 and IGMPv3 specs call the extra data field > >> "Auxiliary Data", but this spec calls it "Additional Data". > >> > >> This seems like a point of possible confusion, is there a reason not to call > >> it "Auxiliary Data" in this doc as well? > > > > The specs define both Additional Data and Auxiliary Data. The former > > is at the end of the IGMP/MLD messages, which we are using. The latter > > is potentially auxiliary data at the end of a group record. We are not > > using that. > > Ah, thanks, my mistake. I think the reason I missed it in my first review > was because I understood it correctly that time and then forgot. Sorry > about that. > > >> 2. > >> In section 3 the 2nd to last paragraph says there MUST be no data > >> in the message after the last TLV: > >> There MUST be no data in the message after the last TLV. The TLVs > ... > >> This wording I think is confusing on a few points: > >> - "in the message" is sort of unclear (e.g. it could refer to the IP > >> payload length, at least for the last group record). Although the doc > > > > Yes (except additional not auxiliary). Perhaps it is best if I refer > > to bytes remaining in the IP payload. > > Yes, to me something like one of these would be an improvement over "in > the message": > - in the IP payload > - in the Additional Data field > - in the Additional Data field, which extends to the end of the IP payload > > (please disregard the rest of my comment #2, it was based on my mistaken > reading thinking you were using Auxiliary data.) > > >> 3. > ... > > This sounds good. Thanks, I'll use this. It is pretty common to draw > > the figure like this even when no alignment is expected, but I think > > I'll point out that there is no alignment or padding. > > Cool, thanks. I agree the figure seems fine to me. > > >> 4. > >> I find this design a bit troubling: > >> Also if a TLV has a length exceeding the remainder of the > >> message, that TLV is ignored, and further TLV processing stops. > >> > >> As an implementor, if I see this scenario I would tend to assume that > >> I'm talking to an implementation that is using a different non-standard > >> meaning for the E bit and the Auxiliary Data (or perhaps an attack > >> packet), and I would think the better choice is to discard the entire > >> Auxiliary Data and treat it as though the E bit was not set, ignoring > >> all the TLVs. (I assume this should be OK since the Auxiliary Data can > >> be ignored anyway by the devices that don't know about it.) > > > > When the E-bit is set, one should be following this document, but of > > course there may be bugs or attacks. I'm fine with being strict as you > > suggest, the only downside is that one will have to validate this > > before applying any of the TLVs. Since the length does not have to be > > a multiple of 4, I think it might be best then to require that the > > last TLV ends at the end of the IP payload (no trailing bytes). > > Yes, I think that's right. > > I hope that's not too bad a downside, I think it sounds ok to me. And on > the upside it's maybe slightly more likely to get length-checked properly. > > It's a minor point though, if you prefer to leave it alone I won't object. > I maybe sometimes worry more than is necessary about the sad state of > buffer-overflow avoidance strategies in networking. > > > Thanks and regards, > Jake > >
- [pim] draft-ietf-pim-igmp-mld-extension WGLC Michael McBride
- Re: [pim] draft-ietf-pim-igmp-mld-extension WGLC Stig Venaas
- Re: [pim] draft-ietf-pim-igmp-mld-extension WGLC zhang.zheng
- Re: [pim] draft-ietf-pim-igmp-mld-extension WGLC Hitoshi Asaeda
- Re: [pim] draft-ietf-pim-igmp-mld-extension WGLC Leonard Giuliano
- Re: [pim] draft-ietf-pim-igmp-mld-extension WGLC Jeffrey (Zhaohui) Zhang
- Re: [pim] draft-ietf-pim-igmp-mld-extension WGLC Hitoshi Asaeda
- Re: [pim] draft-ietf-pim-igmp-mld-extension WGLC Xiejingrong (Jingrong)
- Re: [pim] draft-ietf-pim-igmp-mld-extension WGLC Duncan, Ian
- Re: [pim] draft-ietf-pim-igmp-mld-extension WGLC Gyan Mishra
- Re: [pim] draft-ietf-pim-igmp-mld-extension WGLC Stig Venaas
- Re: [pim] draft-ietf-pim-igmp-mld-extension WGLC Holland, Jake
- Re: [pim] draft-ietf-pim-igmp-mld-extension WGLC Stig Venaas
- Re: [pim] draft-ietf-pim-igmp-mld-extension WGLC Stig Venaas
- Re: [pim] draft-ietf-pim-igmp-mld-extension WGLC Holland, Jake
- Re: [pim] draft-ietf-pim-igmp-mld-extension WGLC Stig Venaas
- Re: [pim] draft-ietf-pim-igmp-mld-extension WGLC Holland, Jake
- Re: [pim] draft-ietf-pim-igmp-mld-extension WGLC Stig Venaas
- Re: [pim] draft-ietf-pim-igmp-mld-extension WGLC Holland, Jake
- Re: [pim] draft-ietf-pim-igmp-mld-extension WGLC Michael McBride