[magma] IESG Evaluation of draft-ietf-magma-mrdisc-03
Margaret Wasserman <margaret@thingmagic.com> Sun, 05 December 2004 16:24 UTC
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18988; Sun, 5 Dec 2004 11:24:54 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CazI7-0002Eu-TF; Sun, 05 Dec 2004 11:31:20 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Caz9z-0006Qz-Q5; Sun, 05 Dec 2004 11:22:56 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Caz0u-0004VS-Ux for magma@megatron.ietf.org; Sun, 05 Dec 2004 11:13:33 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18279 for <magma@ietf.org>; Sun, 5 Dec 2004 11:13:30 -0500 (EST)
Received: from mail.thingmagic.com ([207.31.248.245] helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Caz76-0001zz-5I for magma@ietf.org; Sun, 05 Dec 2004 11:19:56 -0500
Received: from [24.61.30.237] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 215433; Sun, 05 Dec 2004 11:06:50 -0500
Mime-Version: 1.0
Message-Id: <p06200708bdd8e2333955@[192.168.2.2]>
Date: Sun, 05 Dec 2004 11:13:06 -0500
To: brian@innovationslab.net, jim@netzwert.ag
From: Margaret Wasserman <margaret@thingmagic.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250
Cc: Thomas Narten <narten@us.ibm.com>, Alex Zinin <zinin@psg.com>, magma@ietf.org, Russ Housley <housley@vigilsec.com>
Subject: [magma] IESG Evaluation of draft-ietf-magma-mrdisc-03
X-BeenThere: magma@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multicast and Anycast Group Membership <magma.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/magma>, <mailto:magma-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:magma@ietf.org>
List-Help: <mailto:magma-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/magma>, <mailto:magma-request@ietf.org?subject=subscribe>
Sender: magma-bounces@ietf.org
Errors-To: magma-bounces@ietf.org
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48
Hi Brian and Jim, The IESG reviewed draft-ietf-magma-mrdisc-03 on our most recent telechat (2-Dec), and I have included our review comments below. There were a few blocking issues found (the "discuss" comments from Russ, Thomas and Alex) that will need to be addressed before the document can be approved. These issues seem fairly straightforward to me, so I hope that we can get them addressed quickly and get the document approved. There were also a few non-blocking comments that you may wish to consider while you are editing the document to address the discuss comments. Please let me know if you need any further information to address these issues. Margaret --- Discusses and Comments Harald Alvestrand: Comment: [2004-12-01] Reviewed by Mary Barnes, Gen-ART Her review: Draft is ready for publication as Proposed Standard. Russ Housley: Discuss: [2004-11-30] Section 6 says: > > Another solution which supports both IPv4 and IPv6 is to use IPSec in > Authentication Header mode[11] to protect against attacks by ensuring > that messages came from a system with the proper key. When using > IPSEC, the messages sent to the All-Snoopers address should be > authenticated using AH. For keying, a symmetric signature algorithm > with a single key for routers sending Advertisements. This allows > validation that the MRD message was sent by a system with the key. > It should be noted that this does not prevent a system with the key > from forging a message and it requires the disabling of IPSec's > Replay Protection. > First, AH does not generally employ a signature algorithm. It usually employs a symmetric authentication algorithm, such as HMAC-SHA-1. Second, ESP can be used in environments where AH cannot. This text should point out that ESP with a null encryption algorithm and a symmetric authentication algorithm, such as HMAC-SHA-1, is also viable. This is important because rfc2401bis (which just completed IETF Last Call) requires implementation of ESP, but makes support for AH optional. Third, something needs to be said about the manner in which the key is put in place. It seems that manual configuration of the same key is envisioned. Finally, please change "IPSEC" to "IPsec." Thomas Narten: Discuss: [2004-12-02] Note: some of these are weak discusses, but I'd like to at least hear back from the WG. > 3.1.1 MaxAdertisementInterval typo Also, for 3.1.1, is this for all advertisements, or just unsolicited ones? I assume just the latter... actually, the document would benefit from saying "unsolicited" everywhere advertisement is used but unsolicited is what is intended. > 3.1.5 NeighborDeadInterval > > > The NeighborDeadInterval variable is the maximum time (in seconds) > allowed to elapse (after receipt of the last valid Advertisement) > before a neighboring router is declared unreachable. This variable > is maintained per neighbor. In order for all devices to have a > consistent state, it is necessary for the MaxAdvertisementInterval to > be configured consistently in all devices on the subnet. this seems like a not-so-good requirement. Wouldn't it be better to have the advertiser indicate what interval it is using, so that everything "just works"? This is no more work on a node since they are required to keep per-neighbor state anyway. Actually, such info is available (or is it? see later comment on Query Interval Field) ... Why not just make the default be roughly 3X the advertised interval? > 1. For IPv4 it is the 16-bit one's complement of the one's > complement sum of the IGMP message, starting with the Type field. > For computing the checksum, the checksum field is set to 0. > Checksum does not include any IPv4 header fields. This seems like a bad design choice. Note that in the IPv6 case, the checksum does include a pseudo-header. Why not be consistent? > 3.2.4 Query Interval Field How is this value used? Searching for "Query Interval Field", the document doesn't seem to say... > 3.3.4 IPv4 Protocol > > > The IPv4 Protocol field is set to IGMP (2). But you don't mention the IPv6 case here. Why? > 1. The expiration of the periodic advertisement interval timer. > Note that it this timer is not strictly periodic since it is a > random number between MaxAdvertisementInterval and > MinAdvertisementInterval. this doesn't seem good. The spread between these values can be pretty wide, I think. What you want is an average value with some randomness to prevent syncrhonization. You don't want the value to be completely random between (say) 3 and 180 seconds. Bert Wijnen: Comment: [2004-12-02] !! Missing citation for Informative reference: P016 L030: [14] Bradner, S., "Intellectual Property Rights in IETF Technology", !! Missing citation for Informative reference: P016 L034: [15] Daigle, L. and Internet Architecture Board, "IETF ISOC Board of QUestion: is there a MIB doc (in development) for the management variables listed in the subsections of sect 3? Section "9 Authors" may be a bit confusing with the other heading "Authors' Addresses" further down ----------- Comment from OPSDIR (Pekka) review: Nit: Although MRD messages could be sent as ICMP messages, the group management protocols were chosen since this functionality is multicast specific. Alex Zinin: Discuss: [2004-12-02] Rather minor DISCUSS: > 2. Protocol Overview ... > All MRD messages are sent with an IPv4 TTL or IPv6 Hop Limit of 1 and > contain the Router Alert Option[4][5]. All MRD messages SHOULD be > Advertisement and Termination messages are sent to the All-Snoopers > multicast address. To what rate? Same comment for other instances of rate limiting in the doc. > 3.1.2 MinAdvertisementInterval > Does this section specify intervals for unsolicited Ads only or for solicited as well? _______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma
- [magma] IESG Evaluation of draft-ietf-magma-mrdis… Margaret Wasserman
- Re: [magma] IESG Evaluation of draft-ietf-magma-m… Pekka Savola