From nobody Wed Dec 1 10:14:40 2021 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F363A08A4; Wed, 1 Dec 2021 10:14:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: John Scudder via Datatracker To: "The IESG" Cc: draft-ietf-roll-aodv-rpl@ietf.org, roll-chairs@ietf.org, roll@ietf.org, Ines Robles , aretana.ietf@gmail.com, mariainesrobles@googlemail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.40.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: John Scudder Message-ID: <163838247770.1773.7120568405483258765@ietfa.amsl.com> Date: Wed, 01 Dec 2021 10:14:37 -0800 Archived-At: Subject: [Roll] John Scudder's No Objection on draft-ietf-roll-aodv-rpl-11: (with COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2021 18:14:38 -0000 John Scudder has entered the following ballot position for draft-ietf-roll-aodv-rpl-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-roll-aodv-rpl/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the discussion and updates, I'm clearing my discuss. I trust we'll separately come to a conclusion on the remaining topic Alvaro and I have been discussing in email. ---previous DISCUSS for posterity: A lot of effort has clearly gone into this work, thank you. I do have one topic I want to DISCUSS, as it seriously impacted the readability of the document from my point of view. I don’t anticipate that it will be very difficult to resolve this DISCUSS as it relates to clarity and not to anything fundamental. My chief difficulty with the document is placing it in context. No hints are given to the reader as to what the expected network environment is. I think it would be almost sufficient to say, for example “the network environment is assumed to be the same as described in RFC 6550, Section 1” for example, but without that hint and without a strong background in ROLL, I found myself struggling. Figures 4 and 5 in particular lead me to believe the expected environment looks similar to a classic ISP network — a collection of nodes connected by point-to-point links. If this isn’t correct (and I bet it’s not) that may have led me into incorrect assumptions, which may be reflected in my other comments below. Further, it’s not stated anywhere whether AODV-RPL is intended to stand alone as its own routing protocol, or to be viewed as an extension of RPL. In the former case, it seems the document is lacking details that are present in RFC 6550. I’m assuming the latter is the case, but a clear statement to that effect seems indicated. ---previous comments: (Note, added point 19.5.) I support Éric's DISCUSS. 1. Section 1: Reply. AODV-RPL currently omits some features compared to AODV -- in particular, flagging Route Errors, blacklisting unidirectional links, multihoming, and handling unnumbered interfaces. Your use of language is entirely up to you, but I feel obliged to point out that there’s been a lot of discussion in the IETF community recently about use of language that raises sensitive points, and about the term “blacklisting” in particular. I understand that this is the only place in the document the term appears, and since it refers to AODV you can’t just use another term, but placing it in quotation marks might make it clear that it’s referring verbatim to the language of RFC 3561. 2. Section 1: support for storing and non-storing modes. AODV adds basic messages RREQ and RREP as part of RPL DIO (DODAG Information Object) control Did you mean “AODV-RPL adds”? 3. Section 2: Symmetric route The upstream and downstream routes traverse the same routers. Same routers? Or same links? (Or both, if multi-access links are part of the mix, as I imagine they may be?) 4. Section 4.1: OrigNode sets its IPv6 address in the DODAGID field of the RREQ-DIO message. A RREQ-DIO message MUST carry exactly one RREQ option, Should that say “one of its IPv6 addresses"? Is it even necessary to restate this? RFC 6550 §6.3.1 already has a clearer requirement: DODAGID: 128-bit IPv6 address set by a DODAG root that uniquely identifies a DODAG. The DODAGID MUST be a routable IPv6 address belonging to the DODAG root. 5. Section S4.1: TargNode can join the RREQ instance at a Rank whose integer portion is equal to the MaxRank. Not less than or equal, right? Strict equality to MaxRank is required? 6. Section 4.2: TargNode sets its IPv6 address in the DODAGID field of the RREP-DIO message. A RREP-DIO message MUST carry exactly one RREP option, Same as #4. 7. Section 4.2: Address Vector Only present when the H bit is set to 0. For an asymmetric route, the Address Vector represents the IPv6 addresses of the route that the RREP-DIO has passed. The first time I read through this, I didn’t understand it at all. On re-reading, I think you’re using the word “route” in two different ways in the same sentence, the first time to mean “route” in the sense of an object in the protocol, the second time in the more casual sense of “a path through the network”. If that’s right, I suggest rewriting the second instance, as in “… represents the IPv6 addresses of the path through the network the RREP-DIO has traversed.” Also, as in point #4, is it right to say *the* IPv6 addresses? Couldn’t any given node have various IPv6 addresses? So maybe just lose the definite article, as in “… represents IPv6 addresses of the path…”? 8. Section 4.3: r A one-bit reserved field. This field MUST be initialized to zero by the sender and MUST be ignored by the receiver. The figure doesn’t show an “r” field. I assume the field labeled “X” should be relabeled as “r”? 9. Section 5: Figure 4. If an intermediate router sends out RREQ-DIO with the S bit set to 1, then all the one-hop links on the route from the OrigNode O to this router meet the requirements of route discovery, On first reading I didn’t understand this. Having read the whole document, I now get it (I think!). Possibly changing “meet” to “have met” would have been enough to get me past my initial befuddlement. 10. Section 5: The criteria used to determine whether or not each link is symmetric is beyond the scope of the document. For instance, intermediate Should be “criterion … is beyond", or "criteria … are beyond", depending on whether you want singular or plural. 11. Section 5: routers can use local information (e.g., bit rate, bandwidth, number of cells used in 6tisch) I wouldn’t have minded a reference for 6tisch. 12. Section 5: Upon receiving a RREQ-DIO with the S bit set to 1, a node determines whether this one-hop link can be used symmetrically, i.e., both the two directions meet the requirements of data transmission. If the RREQ-DIO arrives over an interface that is not known to be symmetric, or is known to be asymmetric, the S bit is set to 0. If the S bit arrives already set to be '0', it is set to be '0' on retransmission The term “retransmission” seems misused here. I guess you mean something like “when the RREQ-DIO is propagated”. 13. Section 5: Appendix A describes an example method using the upstream Expected Number of Transmissions" (ETX) and downstream Received Signal Strength Indicator (RSSI) to estimate whether the link is symmetric in terms of link quality is given in using an averaging technique. This sentence needs a rewrite to make it grammatical. It works up until "is given in using an averaging technique”. 14. Section 6.2.1: If the S bit in the received RREQ-DIO is set to 1, the router MUST determine whether each direction of the link (by which the RREQ- DIO is received) satisfies the Objective Function. In case that the downward (i.e. towards the TargNode) direction of the link does not satisfy the Objective Function, the link can't be used symmetrically, thus the S bit of the RREQ-DIO to be sent out MUST be set as 0. If the S bit in the received RREQ-DIO is set to 0, the router MUST determine into the upward direction (towards the OrigNode) of the link. The last sentence doesn’t make sense. 15. Section 6.2.1: If the router is an intermediate router, then it transmits a RREQ- DIO via link-local multicast; On what interface? Routers generally can have multiple interfaces. Again, this is a place a clear description of the network environment might have helped. 16. Section 6.2.2: If the OrigNode tries to reach multiple TargNodes in a single RREQ- Instance, one of the TargNodes can be an intermediate router to the others, therefore it MUST continue sending RREQ-DIO to reach other targets. In this case, before rebroadcasting the RREQ-DIO The use of the term “broadcast” here confuses me. Is this “broadcast” in the RF sense? Again, this is a place a clear description of the network environment might have helped. 17. Section 6.2.2: send out any RREQ-DIO. For the purposes of determining the intersection with previous incoming RREQ-DIOs, the intermediate router maintains a record of the targets that have been requested associated with the RREQ-Instance. Any RREQ-DIO message with different ART Options coming from a router with higher Rank is ignored. It’s not clear to me if the last sentence goes with the previous and if so, how. Does it even relate to multiple targets? Also, different from what? If it has the same ART Options (same as what?) is it *not* ignored? 18. Section 6.3.1: implementation-specific and out of scope. If the implementation selects the symmetric route, and the L bit is not 0, the TargNode MAY delay transmitting the RREP-DIO for duration RREP_WAIT_TIME to await a symmetric route with a lower Rank. The value of RREP_WAIT_TIME is set by default to 1/4 of the time duration determined by the L bit. It’s not an L bit though, it’s an L field. 19. Section 6.3.2: multicast until the OrigNode is reached or MaxRank is exceeded. The TargNode MAY delay transmitting the RREP-DIO for duration RREP_WAIT_TIME to await a route with a lower Rank. The value of RREP_WAIT_TIME is set by default to 1/4 of the time duration determined by the L bit. Again, it’s an L field. Also, what if L is zero? Is RREP_WAIT_TIME set to infinity, as the text implies? Please do a global search for “L bit”, as there are additional instances I haven’t called out. 19.5 Section 6.3.2: (Adding one I missed earlier.) When a RREQ-DIO arrives at a TargNode with the S bit set to 0, the TargNode MUST build a DODAG in the RREP-Instance rooted at itself in order to discover the downstream route from the OrigNode to the TargNode. The RREP-DIO message MUST be re-transmitted via link-local multicast until the OrigNode is reached or MaxRank is exceeded. The As in comment 12, the use of the term "re-transmitted" is a little weird here. Do you mean TargNode sends the RREP-DIO again and again, as the text seems to say? (And as with some of my other comments, it's not obvious to me what interface(s) the link-local multicast takes place on.) 20. Section 6.4: Step 4: If the receiver is the OrigNode, it can start transmitting the application data to TargNode along the path as provided in RREP- Instance, and processing for the RREP-DIO is complete. Otherwise, in case of an asymmetric route, the intermediate router MUST include the address of the interface receiving the RREP-DIO into the address vector, and then transmit the RREP-DIO via link-local multicast. In case of a symmetric route, the RREP-DIO message is As with #15: on what interface(s)? 21. Section 10: fake AODV-RPL route discoveries. In this type of scenario, RPL's preinstalled mode of operation, where the key to use for a P2P-RPL route discovery is preinstalled, SHOULD be used. What type of scenario is that? 22. Appendix A: s/pakcet/packet/ 23. General remark: Although “acknowledgements” isn’t a required section I was a little surprised not to encounter it, as it’s usually present. Your call of course. From nobody Wed Dec 1 10:43:11 2021 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85ED13A0930 for ; Wed, 1 Dec 2021 10:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ihfGSxXP92-G for ; Wed, 1 Dec 2021 10:43:04 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9488D3A092F for ; Wed, 1 Dec 2021 10:43:04 -0800 (PST) Received: from dooku.sandelman.ca (cpef81d0f835a73-cmf81d0f835a70.sdns.net.rogers.com [174.115.215.42]) by relay.sandelman.ca (Postfix) with ESMTPS id 32D821F4A8; Wed, 1 Dec 2021 18:43:02 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 51A751A01F9; Wed, 1 Dec 2021 13:42:59 -0500 (EST) From: Michael Richardson To: "Pascal Thubert \(pthubert\)" cc: "Routing Over Low power and Lossy networks" In-reply-to: References: <1193.1637193313@localhost> <28122.1637664352@localhost> Comments: In-reply-to "Pascal Thubert (pthubert)" message dated "Thu, 25 Nov 2021 14:10:33 +0000." X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.3 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Date: Wed, 01 Dec 2021 13:42:59 -0500 Message-ID: <664027.1638384179@dooku> Archived-At: Subject: Re: [Roll] review of dao-projection -21 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2021 18:43:10 -0000 --=-=-= Content-Type: text/plain Pascal Thubert (pthubert) wrote: >> > Look at https://www.ietf.org/archive/id/draft-ietf-rift-rift-13.pdf; >> good yes, perfect, no. Worth the effort ? >> >> Yes, worth the effort. >> Goat lets you write ASCII art in a slightly restricted way, and it upgrades >> it to SVG. The reason to use kramdown here is only because it manages that >> for you. > There's still the process of uploading all the files etc. I keep that > for later in the process, maybe RFC editor time. yes, that's why kramdown is so nice that way, as it arranges all of that for you. >> I'm okay that the PCE/Root interface is outside RPL, and even that it's >> non-standard. Some roots could include the PCE internally, I think. > Yes, that's function placement. We now have: > " > With this specification, an abstract routing function called a Path > Computation Element [PCE] (e.g., located in an central controller or > collocated with the Root) interacts with the RPL Root to compute Peer > to Peer (P2P) paths within a pre-existing RPL Main DODAG. > " > This seems to cover it? Yes. >> That's okay with me, if they need to be easily referenced. >> As, it, "Hey other implementer, you didn't do 4.5.6.7 correctly!" > That's a fine argument. I looked at the draft again ad find it hard to > implement, but OK. Let's list that one as to be decided by the group > during WGLC. okay. I have been advised that integers are plentiful and mostly free. >> I'm okay if we say that only the root (identified by IP address) can send >> them. > Good. I'm adding text for that. In particular in the security section > " > With this specification, only the Root may generate P-DAO messages. PDR > messages may only be sent to the Root. This specification expects that the > communication with the Root is authenticated but does enforce which method > is used. > " So I was trying to say that they should be accepted from the root only, and that we do this by IP address. We are going to get some Sec-Review push back here, so let's get ahead of it. I know that we have effectively, no BCP38 filtering within the DODAG, so any node can impersonate the root, but at least we make it a bit harder, remove attacks from outside the LLN, and we guard against some minor bits of misconfiguration. I think that all nodes know this because DODAGID, but I was always a bit fuzzy whether that value was arbitrary or not. >> Well, if we had the 6LR changes with state machine, then all the MUSTs >> would migrate to that section. > Yes the state machine is always a debate. Some want it some not. Some > want it in the main text some in appendix. > When in main text it becomes normative and a bad companion for BCP14, > because it's like saying things twice with a risk of discord. I wouldn't be able to code this without documenting a state machine. I will then wind up asking questions from the state machine after the document is published. > Let's make this your point 4 for the review. > For your other point I added a picture in the terminology, as follows: > A ==> B ==> C -=- F ==> G ==> H T1 I: Ingress > / \ / \ / E: Egress > I O E -=- T2 T1, T2, T3: > \ / \ / \ External > P ==> Q ==> R -=- T ==> U ==> V T3 Targets > I ==> A ==> B ==> C : a segment with Targets F and O > I --> F --> E : a leg with Targets T1, T2, T3 > I, A, B, C, F, G, H, E : a path to T1, T2, T3 > Figure 1: A Track and its Components > Take care, I have to put that onto paper and then re-read things. Unfortunately, I won't get to implement before WGLC. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAmGnwjIACgkQlUzhVv38 QpALzwf/fOC3YoeDtoLWSlLm/5EpL94i12dk6eXb4j5O3SyLGhmG6hRH0nP8i6Rj 0O2B40ranEG5rk6A+uC0zkesKtFlHr3R4i5PXXob57NI6K/+mXQmMGW04jTa4teW qByft/xOuz5bB/QTGOIucy2VFfWnTzj7NL4PBhHr/b4G33QM3KImGnDmHutetCKj ONxdcaC2rsVPj+p62JIBIJr3n4bHZFBK2hp9lE/y0HU3A63c8Nhai1qTIqD4rkxW tiuSpFp8+PtZTbK5w+DTBDD7g8j3qL8uW+IYSURQbKLOZ0GiU+oomjq4yDvl2FzG 1QcKPB/zn2p0mFbSPPIj92PU3TXrag== =0Yz/ -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Dec 2 06:44:16 2021 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 983F33A1144 for ; Thu, 2 Dec 2021 06:44:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.596 X-Spam-Level: X-Spam-Status: No, score=-9.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=iGf+XtjU; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ISMxfeH6 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 CoDiAr0pgNmX for ; Thu, 2 Dec 2021 06:44:10 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C3623A1147 for ; Thu, 2 Dec 2021 06:44:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1711; q=dns/txt; s=iport; t=1638456250; x=1639665850; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=j+SuwOMv6RvhF11PGoiuYvCaI2BT+/iDftFBNN3FZUw=; b=iGf+XtjULgRFTpe4k9Ou75aLEBPO8BRS9mT/2fS+8KMjoQyuD4n/8uQs Hv8Ovbg8unziNN0P2evbbad8fnqxBvMkrRzR1a3ZyBFInkGrAl/GQ90BV 1JnXOJ7gWb4T1ME2HFL+F1358ZBuhM8Yqta9ovIfg3vg3Mo2qPWAQjIQN A=; IronPort-PHdr: =?us-ascii?q?A9a23=3Ao7SPgBR5sGH/9zBhnWhxnBHnUtpso7vLVj580?= =?us-ascii?q?XJvo75Nc6H2+ZPkMQSf4Ph2l1bGUM3d7O4MkOvZta3sGAliqZaMuXwPatpAA?= =?us-ascii?q?hkCj8hFkwkpGsXQD0r9IbbjZDA7G8IXUlhj8jm7PEFZFdy4aUfVpyi57CUZH?= =?us-ascii?q?VP0Mg8mTtk=3D?= IronPort-Data: =?us-ascii?q?A9a23=3AujUiaK1ERNn8g1PE0PbD5flzkn2cJEfYwER7X?= =?us-ascii?q?KvMYLTBsI5bpzMAymoaCjqEPPqPYGT8c4sgaYrj8hgP6J7Qn4BkSVdr3Hw8F?= =?us-ascii?q?HgiRegpqji6wuYcB84ZRyH6ZBoPA/42N5+Qc6jYcleG/k30a+K59yEmvU21b?= =?us-ascii?q?uOU5NDsa3gZqTBMEE/NuTo78wIIqtYAbeqRWmthivuqyyHrA2JJ7hYvWo4iB?= =?us-ascii?q?w1vnzs01Bj6kGtwUlXT/pmntneG/5UeJMp3ya1csxLFrodo8u6SH44vzZmw+?= =?us-ascii?q?mffuhwqEN7gy+69eUwRSbmUNg+L4pZUc/H92V4Z+GprieBib6B0hUR/011lm?= =?us-ascii?q?/hp1NVQv5GqVS8iP7bHn6IWVBww/yRWbPMXo+CceyTv2SCU5wicG5f2+N10C?= =?us-ascii?q?0UyFYwV5ugxBntBndQdIypObx2ficqtybS3R+1pj8JlJ8CDAW+1khmM1hnQC?= =?us-ascii?q?fIgBJvEWaiPvIce1zYrjccIFvHbD/f1oAFHNHzoCyCj8H9NYH7moNqVuw=3D?= =?us-ascii?q?=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3Ag06sq65Z1DMP0H3frAPXwZGCI+orL9Y04l?= =?us-ascii?q?Q7vn2ZFiY1TiXIra6TdaoguiMc0AxhJk3Jmbi7Sc69qADnhO9ICO4qTPeftW?= =?us-ascii?q?jdySqVxeRZjbcKrAeQYBEXeIRmpN1dmsRFebjN5B1B/LnHCWqDYpUdKbu8gd?= =?us-ascii?q?2VbI7lph8HJ2wHGsIQjTuRSDzrbnGeLzM2Y6bRYaDsnvav0ADQAEj/AP7LYk?= =?us-ascii?q?UtbqzmnZnmhZjmaRkJC1oM8w+Vlw6l77b8Dlyxwgoeeykn+8ZhzUH11yjCoo?= =?us-ascii?q?mzufCyzRHRk0XJ6Y5NpdfnwtxfQOSRl8kuLCn2gArAXvUlZ1TChkFwnAic0i?= =?us-ascii?q?dtrDD+mWZ4Ay210QKIQoiBm2qr5+An6kd015at8y7DvZKpm72IeNtzMbszuW?= =?us-ascii?q?seSGqF16Ll1+sMj56iGAmixsZq5Fr77VbAzsmNWBdwmkWup30+1eYVknxESI?= =?us-ascii?q?MbLKRctIoF4SpuYds99Q/Bmcoa+dNVfYzhDTdtACWnRmGcunMqzM2nX3w1EB?= =?us-ascii?q?vDSk8eutaN2zwTmHxi1UMXyMEWg39FrfsGOtd5zvWBNr4tmKBFT8cQY644DO?= =?us-ascii?q?AdQdGvAmiIRR7XKmqdLVnuCalCMXPQrJz85qkz+YiRCdM15Yp3nI6EXEJTtG?= =?us-ascii?q?Y0dU6rAcqS3IdT+hSIW2m5VSSF8LAU23G4gMy1eFPGC1z2dLkeqbronxxEOL?= =?us-ascii?q?yvZx+aAuMgP8Pe?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AsBgCs2qhh/4QNJK1agQmBWYFSUQe?= =?us-ascii?q?BUjcxiA4DhTmFDoMCA5sQgS6BJQNUCwEBAQ0BAUEEAQGBTIM5AoMMAiU0CQ4?= =?us-ascii?q?BAgQBAQESAQEFAQEBAgEGBIEJE4VoDYZCAQEBAQIBEigGAQE3AQ8CAQg2EDI?= =?us-ascii?q?lAgQODRqFNQMOIQGlCwGBOgKKH3iBM4EBgggBAQYEBIULGII1CYE6gw6CflS?= =?us-ascii?q?HUiccgUlEgRQBQ4JnPoRHg02CLpBTgVVbgVseFr9BCoM9nycVpzaWHqEICBi?= =?us-ascii?q?EagIEAgQFAg4BAQaBYTuBWXAVgyRRGQ+SEopedDgCBgsBAQMJklEBAQ?= X-IronPort-AV: E=Sophos;i="5.87,282,1631577600"; d="scan'208";a="969373248" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Dec 2021 14:44:09 +0000 Received: from mail.cisco.com (xbe-aln-004.cisco.com [173.36.7.19]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 1B2Ei8cj008591 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Thu, 2 Dec 2021 14:44:09 GMT Received: from xfe-aln-004.cisco.com (173.37.135.124) by xbe-aln-004.cisco.com (173.36.7.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Thu, 2 Dec 2021 08:44:08 -0600 Received: from xfe-aln-001.cisco.com (173.37.135.121) by xfe-aln-004.cisco.com (173.37.135.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Thu, 2 Dec 2021 08:44:08 -0600 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-001.cisco.com (173.37.135.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Thu, 2 Dec 2021 08:44:07 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AuzpHfJ1/3R0W5mZDJ6lsJAeB5Q6SWWsy+Fve0nhM/wK69eiY1AGXNAjlMziI7vc5ZTdU7GT+uGyB095uuRwaSjTNvjx8cZP6NgnyTgE2fDEn+Vegg5HtkVcMTHuVBLjlU9pwRnT/gTFUtUmJQ8k/BCsAExaDe4PMai+afHJd1ETHAYPleh1tJDT06u0GG2jEyzEIbv1xDGB21Nr9S6Xug1SieTEAAQBHLWVF0QZlBT8x4iaZ7s3+o63tEL4oL0nVgGpfdwRh/pgj9rN29EMu2VwQy2J8ACmlg5V8o5syW12bdGtEGO4wgIjc+sBVz5fUw/NVyK8BbTt68rWYJ/gNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=G6zbO+JdsOqSC8UEDTVKvM2dmPaCxrYTAUfgKDdkT8I=; b=drXzDqH9Q9LQZ8v/4i2HWs9uDyt0HDZAY7kOzVAHHdwB5WAG5LNCNUArGjsF4Ei196AWQshdKVhVAkr5PMkXG2vGCqWBxf41BsG9D9oBUAEAwabHxtZwsr/ijhZbb12T5OWWscv5XuPV1w78dX94LfV/p885GLWquZ32ISmY7831RGwi7ERNc1kSeEyZSSVwXRKmeUtwJfwNNtyFnmYqJUxdTt6/142nkKy/D4BvE+kCyp6q6KKm29XBOp8sZQzqCMDj6IZm0AIi7J3j2AY/1QoI5vQT/iNyhG8h7BdHyj7sTDNTFHCs3rclSzm8a0bCUXPqeOIYw1o8HwJR8Y1rNw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=G6zbO+JdsOqSC8UEDTVKvM2dmPaCxrYTAUfgKDdkT8I=; b=ISMxfeH6bvEctrvnfs1XbNuaj4dWJD5aqO+g0oLb5qnuZqPP9Pq66BgLOqsWR/IElbjN5mJMYowBG451flyadGNsdZzqMEHyzZpEovTT2yevqk3F92Npny/7odgRdEaNaVGSfEgJxoW1nSCw891glThxFRODn8IM9a37MvbjFpc= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MW5PR11MB5859.namprd11.prod.outlook.com (2603:10b6:303:19e::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4734.23; Thu, 2 Dec 2021 14:44:01 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::1022:cca:7c3a:66d0]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::1022:cca:7c3a:66d0%5]) with mapi id 15.20.4755.016; Thu, 2 Dec 2021 14:44:01 +0000 From: "Pascal Thubert (pthubert)" To: Michael Richardson CC: Routing Over Low power and Lossy networks Thread-Topic: [Roll] review of dao-projection -21 Thread-Index: AQHX3A6hba1WVAMvpEydUyu6mrOqB6wJbO5wgAeJhgCAAgIjEIALFdKAgADU6EA= Date: Thu, 2 Dec 2021 14:43:39 +0000 Deferred-Delivery: Thu, 2 Dec 2021 14:42:53 +0000 Message-ID: References: <1193.1637193313@localhost> <28122.1637664352@localhost> <664027.1638384179@dooku> In-Reply-To: <664027.1638384179@dooku> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d8887e84-4d62-40c8-72a1-08d9b5a22e64 x-ms-traffictypediagnostic: MW5PR11MB5859: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: SG0aqZuksRbKAkKy+CPHhb649xYLTIMFizF2eee+UgY2386w3e4Yv5N6XaZw7bANIiV3GPSE4PDZhLuQuUPl7dXz36iMaiO9jnDiEyTXNiuJD17R3rPTXWkwvG5xsRcBiYpIakt/gzIKV6nBK3rUkBvidAV5m2URSeTsYMQI9RXp7i1L72fDQTkinazOjqKwT0MPYUAxNbr9ndw9Kma2bM7RKQ6+qVhY4ZSwOYbhioQbqAU6A+w3qsZLR7QtyMw4+9KEvkdDcGFFN1ZrnoqlBaBSq7pT/sHA1SyfvzdFlPIgapHQn0FdAfVTn/soMlw0dF9q2l07TewU7z0Oe5goNZ/AiMidQkE18GScOIBZrX66gk32UIhMr5R5fnvrf7+ddCvWQqgnLU341q6xeot713goufVpp77Cs+lmNpe2GWDfxE8pxyu5G/tSpxetywnrT25V/bKV6tRA9LbSOmngmLOvNBsrGbzj/0etfV7O+31++9Bd5mM3elffZVgkCzV2pjlfWOLNNRi/AKe2QcQnrXmJ2u2aRQmZq+uMVg5Qi8mpkBvwK8VG4y0BUqsVvDSHexp/JV0vRCbcO6M7Ft0nLALEDty+yYDQ0gMzCg8DDd9Mmr76EHUkgMAIncCTJwU/4b4MxeolsMUsH1xrNsuxpfB8VSPny+ZDs/M69L10BDP6Mh3o/GX4CjOdRGWB1Jj3pUfrwtZx/7DIylF/Muq7rg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB4881.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(5660300002)(83380400001)(71200400001)(55016003)(2906002)(38070700005)(33656002)(26005)(38100700002)(6506007)(122000001)(66946007)(66476007)(508600001)(66446008)(76116006)(7696005)(66556008)(64756008)(52536014)(186003)(316002)(8676002)(9686003)(6666004)(8936002)(4326008)(86362001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?mZ7f+0R8x2pifvqNPdWRqKS02Rx4YEPYRv1SZ4aGH0y1Xd6I3Mvdr32vbCn2?= =?us-ascii?Q?EDD08wbzkVUFZQBiBmCKmsvBD7V8rFtgYjKHG4Tvec48iIYiblPutqeIvDRw?= =?us-ascii?Q?AZgEEQcdcnXQwHvbHszuNvymuvxfhwcj8LbXbbLblEbfQiA2fYs0Wzcpk7ki?= =?us-ascii?Q?AfG0lShz9lUam0EJwO4sLJJmfcEnsW3wp7Gg8sZ3pYo43FBkkCD4KGkNkDdh?= =?us-ascii?Q?+wmpkExWYFZ7zJbRgNSWtmga1j6Vb3Si9j/kR6rhgTvZ8FmzqRNg6kZOr1kK?= =?us-ascii?Q?BDo9CAPRkOJa0qT0xaqd6wvumBnqiQYErVu+YLcuKk7JY9BFgRyhEnBjFumL?= =?us-ascii?Q?mnafo7qymfA6QuNAc96hJCSdTTp6LHYT9tFCy7njQbB2eUm1pgRg2ZtIxQ2w?= =?us-ascii?Q?vQRhNqWVY7FYHAF3zW4Jpc/n4KKvh6jDzeI6T/Q8emD2SPGLAs5TUBl29LF5?= =?us-ascii?Q?JsEXyFbxpfK2jpe3G5EUvj5Zv/FBoYP39nhf1MvA996oyWaGn/YZtqDDG2/0?= =?us-ascii?Q?zAOMkZdpbdBlG/G5pC36Mcu3F1m7T8Jed3LMM4MBXd6nAYHCO596RKBDIebw?= =?us-ascii?Q?JvAxk8bCYm6CM72u0GZEFfjK+HD+OY2zwYEUt9Jh7DuWwIWcROsd59blNDA6?= =?us-ascii?Q?LiHGbmhf4WMcmajtuttgp02qxvdxcLvkMSTWZb9o6RTwu3Odshw3hOxGWKjy?= =?us-ascii?Q?OZvQhZTaFq2rtvQx9u5P/Tv5GKihBKmXYrHfTt0y79AJ4Qi8/LKLLSTYyt1t?= =?us-ascii?Q?otWye6Qnnb+62BNekDyO8Oc61x9fiBiL8OFzHqvbP1pGuNj5kgdxHra8lV1n?= =?us-ascii?Q?9Dmsh4nhlfkhU7fhd14VRQkbcEQyX0y863lgjRpkbWmUxpZzhLWyRBLFnQC3?= =?us-ascii?Q?f5B0Wm1BEz7jXrasWt2I14T3si29JnnH0lFy0RGiwE+SxdGmSZu+XYbSmgau?= =?us-ascii?Q?oCfWDgwirGwxNP58S7b7cd2hyyRDy0eB08+iUn5znHd+zBHJxwmuAF70OYGs?= =?us-ascii?Q?fs+iF3hqkdaAvSZ76Vw+wXz+ZaSJRmVfJIzqTNSkd34PdPm67VsRP5sfvhnb?= =?us-ascii?Q?bq8CrMZ7e1li6pI01c893aoZ9gkkZ+MY7IEZnNyE8MzJrKWFGDMKieilBe8d?= =?us-ascii?Q?cRU1GbNY98N2CThtI4RaaSZsurgt/NxGIhb2nzdwN9c7nhIppAd1OjDMW3xN?= =?us-ascii?Q?BaFrLZSgY3GSfyD1aewiph5GgKGS0hIBf+F/kDxlUEC0I0PLE+YWes0UPstO?= =?us-ascii?Q?OzTqcKyNw9WcXbJG+H+5xChb6Gv5hp46GWgpfy9lU4VXYmQN3gfIe3cl0nTz?= =?us-ascii?Q?OEoaPtj23J4LgvKKUHG038BdMT5AmG8hTQGnlb4PKIY8W6aroUAl9DJklMpq?= =?us-ascii?Q?ipXG8vMpmfN/35vwIiQsR0NFX7FIIEv1Xht9xmoeb0KEjWuiwTRXjA8r+Lxo?= =?us-ascii?Q?sbIu1xSSllREPCMojONi0cbDfpK0RZFMgUq6WU+dRXEi+AvL61p+MZXKr44u?= =?us-ascii?Q?kVXeJJ1jWwRYQlMI6YaExcoCnqrpuoDPrVA6VihuANSnZo78rqw5bYdpKEvy?= =?us-ascii?Q?QksJ8/OgwPsenXqfMdCKceDsU4ZU1pDVESnizC/BczGq6B4EQgGfEP2j9hNv?= =?us-ascii?Q?L7Ke5aemHmAj1ZSQ6mXIIp0=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4881.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d8887e84-4d62-40c8-72a1-08d9b5a22e64 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2021 14:44:01.6050 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: d9IRYUtV3rpS9OciqLpjvvgAeHJi/S247FOZ66xfID8JBtGBWIJM5XYUL5ynkTAJ+T607EJssna9TStMnmVO7A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW5PR11MB5859 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.19, xbe-aln-004.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: Re: [Roll] review of dao-projection -21 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2021 14:44:15 -0000 Hello Michael: >=20 > So I was trying to say that they should be accepted from the root only, a= nd > that we do this by IP address. We are going to get some Sec-Review push > back here, so let's get ahead of it. > I know that we have effectively, no BCP38 filtering within the DODAG, so = any > node can impersonate the root, but at least we make it a bit harder, remo= ve > attacks from outside the LLN, and we guard against some minor bits of > misconfiguration. >=20 > I think that all nodes know this because DODAGID, but I was always a bit > fuzzy whether that value was arbitrary or not. >=20 OK, will not hurt to be very clear. I'm adding text to "5.1. New P-DAO Request Control Message" as follows: " The Root MUST source the P-DAO message with its address that serves as DODAGID for the main DODAG. The recipient MUST NOT accept a P-DAO messag= e that is not sent by the Root of its DODAG and MUST ignore such message silent= ly. " > >> Well, if we had the 6LR changes with state machine, then all the M= USTs > >> would migrate to that section. >=20 > > Yes the state machine is always a debate. Some want it some not. So= me > > want it in the main text some in appendix. >=20 > > When in main text it becomes normative and a bad companion for BCP= 14, > > because it's like saying things twice with a risk of discord. >=20 > I wouldn't be able to code this without documenting a state machine. > I will then wind up asking questions from the state machine after the > document is published. >=20 OK, I can think of how to make that clear. It's not that different of a nor= mal DAO. Keep safe; Pascal From nobody Thu Dec 23 08:54:40 2021 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCA83A074E; Thu, 23 Dec 2021 08:54:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.852, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lupinlodge.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 spKlVjN4l8zs; Thu, 23 Dec 2021 08:54:13 -0800 (PST) Received: from delivery.mailspamprotection.com (delivery.mailspamprotection.com [185.56.85.138]) (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 AEC613A074D; Thu, 23 Dec 2021 08:54:12 -0800 (PST) Received: from 246.206.208.35.bc.googleusercontent.com ([35.208.206.246] helo=giowm1055.siteground.biz) by se19.mailspamprotection.com with esmtps (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1n0RLz-0004z1-TG; Thu, 23 Dec 2021 10:54:10 -0600 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lupinlodge.com; s=default; h=In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=5IvaYPwZY8D6kjtKpv97vv64Jq0k9BHzfq08oGcFmok=; b=CJm8c0YcXt7S+HXQ3suS4Ouhh5 O84grdQ7gyGT5z4M4SuqeRECTj2/vjbE8DF6WZmvDSpzkF/tFC5XmGW+kwC1tndqBckKHoE270qlQ 61KzOqOoKPnUIyQ/qj8/bSlupLygSHxmG0siJOV3OK8rh8a1Ek3EVwGrqrfQfNCh/O8s=; Received: from [99.51.72.196] (port=49292 helo=[192.168.1.72]) by giowm1055.siteground.biz with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.90-.1) (envelope-from ) id 1n0RLz-000L3b-5P; Thu, 23 Dec 2021 16:54:07 +0000 Content-Type: multipart/alternative; boundary="------------2EHMiEQSbBt2RihUk6rvQ70x" Message-ID: Date: Thu, 23 Dec 2021 08:54:04 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Content-Language: en-US To: Benjamin Kaduk , The IESG Cc: draft-ietf-roll-aodv-rpl@ietf.org, roll-chairs@ietf.org, roll@ietf.org, Ines Robles , aretana.ietf@gmail.com References: <163554851494.11244.14085107396965188459@ietfa.amsl.com> From: Charles Perkins In-Reply-To: <163554851494.11244.14085107396965188459@ietfa.amsl.com> X-Originating-IP: 35.208.206.246 X-SpamExperts-Domain: giowm1055.siteground.biz X-SpamExperts-Username: 35.208.206.246 Authentication-Results: mailspamprotection.com; auth=pass smtp.auth=35.208.206.246@giowm1055.siteground.biz X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.22) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT+/DC9OvQa027oQAXzPNUNCPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5y2xZ3bXw4/iS3jSedLFfB4je+/oqGsl7PQVQA3pojt2sLv 55K1GIS9uV45zLu2Bi6YKe1cgh+rKXFGPIDhQPnY+NY4uI7RgQq7IkZkLeGF+LvDKRSeOy6sWF/5 dB1Kd4iRqGxVhzECIAn1s+S+NgCpoX4pDujRivi71nURJlNlmui7uTlIwZUZ68sOsegNqlvxvB0o OlpRE8PZuZSD8RaYE+qybeUxf9SRIhKRsNdoQreveBiglwHfnV8fPmF8u8S6e0lI0VnllOQn8BY8 7ubR6B+Fp5Qk5cmyfx8/DavLNzJUAjbIHZDvRcJdgnZDB+dJL3BNFShe/fgcjZBeVTjxiL9zfkEh WUUSbBfNEBYlUYXyhM71Tf4sEJbTH6WJIqd0TdPv5v0wHDAKkoUi1h4zRhsGFALI8EH5dzP0VURJ 0jjKxTNoMwlRMVTliNKob5qAKjlCJkitMlF2bi7EOXIK4cicYF9uPcHhJH8r0ngKsiuQW3c6bXX7 k8uCnNwITeJSWnLjPk7HtIF+PkUkIPkt2S9lxf1W0a5eEMc7eunFGjRotk+i4Didqu3qVccu2IJA GOchbrUSCaP8sqAF59+SaQqrghTclj6QYZTZzeBjsnjYEopWhd/73L4UFof3//2xw1QvBkz1Ucpi 8zZtpJaP+AglUZ3cPOlANMIbXMFEG8MR6jngU+K/iyWLV8VgtNSIzdXSTcg+/rB2mqPWXcDww9Ah IJZICvIdy8UT6SKyn5lQuz/H/CJjhs5BUf8fRBA8F/IJRA8ZF8C5AnJBxSFDyTlKwizxuV2v1rcb taLAuItfLNy/Y3G/cM6xYjDbI4nzKVmDzqLtN+iGvK4YPoOczcm5eerMmtE/cRM1WN+t8r5Y6a6/ 7pznSvgrF2/Tutxig5tPvU5YG16t+wExEEGmwDgI8cryi7LJykiVcwYY1KvOT7D5V3XVGXcWA7yd Gd9/tORp8Nh3kLDgks7S91VjGMV2nb7BQnXXli6Ficmobb6ye4k4LUFa2LnXMHOkVut2x2Jg1ZAF QcjTIYZ0GiRgicRNxE8lHVRedXHzx9B23yvfKFSvxE62l2VNaiwedqYzdDVUNlt291H3qDIb1TAl nPp+is8ywRcvPnY/8YGEFDvxRxZKWB54sBj4a/GDDBhlVICUKMcLV0Gc3UrlAQPT9R/2gMGq0KWA zmMf+ibVDvFoeN3jACcf2sdZZ2j9JGsGUgYNdgoqnDAHqoE3GAj2vjDKmWdAh+liXkZcVqv3YlfR AiMiMKfXO9C5TEIHDglVUaCAVXgAip3FVy8Y6mfzKuPAvG8HjzezKKCTvAvoiiOzb7uzTnBxt3nH lPEKJbWZBIunO04jDfKa/ntcguS5 X-Report-Abuse-To: spam@quarantine1.mailspamprotection.com Archived-At: Subject: Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf-roll-aodv-rpl-11: (with DISCUSS and COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2021 16:54:19 -0000 This is a multi-part message in MIME format. --------------2EHMiEQSbBt2RihUk6rvQ70x Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hello Benjamin, Thank you for your detailed review.  It is very much appreciated, and is helping us to make some significant improvements in the document.  Please see our follow-up and proposed resolutions below. On 10/29/2021 4:01 PM, Benjamin Kaduk via Datatracker wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-roll-aodv-rpl-11: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer tohttps://www.ietf.org/blog/handling-iesg-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-roll-aodv-rpl/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thanks for the updates in the -11, they are a bit improvement. > > (1) I did make a point of looking into the procedures for determining > whether a route will be symmetric or asymmetric, and I'm running into > trouble for the case where an intermediate router determines that a link > cannot work as part of a symmetric route. > > For concreteness, let's consider the following snippet of topology: > > +-------+ +-------+ +-------+ > | | asymmetric | | | | > | A +-------------------+ B +===================+ C | > | | L1 | | L2 | | > +-------+ +-------+ +-------+ > > Suppose that an RREQ-DIO arrives at A with S=1 and H=0. Per step 3 of > §6.2.1, if the link the RREQ-DIO arrived on satisfies the objective > function, the outgoing RREQ-DIO is also transmitted with S=1. > A also associates state with its RREQ-Instance the value of the S bit > from the transmitted RREQ-DIO, i.e., 1. Check. > That RREQ-DIO arrives at B, who performs the same check and determines > that the L1 cannot satisfy the objective function. Accordingly, B sends > out a RREQ-DIO to C with S=0 and stores the state S=0. If the route to OrigNode from B via L1 cannot satisfy the objective function, B drops the RREQ-DIO.  Otherwise, if L1 is asymmetric but still provides a usable path towards OrigNode, B takes the action you describe. > The RREQ-DIO > continues to through C to TargNode (or maybe C is TargNode; it may not > matter), and TargNode proceeds to follow asymmetric procedures, > initiating an RREP-DIO with an initially empty address vector. That > RREP-DIO arrives at C, who has stored state S=0, so C joins the DODAG of > the RREP-Instance, adds its address to the address vector (per step 4 of > §6.4), and sends an RREP-DIO to B. B likewise has stored state S=0, > adds its address to the address vector, and sends an RREP-DIO to A. But > A has stored state S=1, so in step 4 of §6.4, A is looking for an > address in the address vector to use as the unicast target for A's > outgoing RREP-DIO. But there is no such entry in the address vector, > becuase up to now the RREP-DIO has been using asymmetric procedures, and > has no data on how to get from A to OrigNode! As the RREQ-DIO propagates with H=0, every node that transmits the RREQ-DIO can be used in a source route to OrigNode.  So, when the RREQ is received by B, B has an address vector utilizing A as the next hop for a route to OrigNode. If the RREQ-Instance at B has S=1, B should optionally be allowed to associate that address vector with the RREQ-Instance.  For S=1, the address vector B-->...->OrigNode is symmetric; if B maintains that information, it could unicast an incoming RREP towards OrigNode. We will add an appendix with some examples to make this more clear. > > Now, it's certainly possible that I've made an error in the above. But > even if I have, it still seems suggestive that this boundary behavior is > pretty complicated and hard to get right. It seems like we should have > some similar discussion in the document to cover how this case does > actually work. > > (And if I didn't make an error in the above, it seems to still be > salvageable, with B storing a sentinel value of "I changed from S=1 to > S=0" instead of just 1 or 0, and holding on to the (symmetric) address > vector from OrigNode to B. Then B could perform translation from the > asymmetric to symmetric regime for the RREP and all routers on the path > would be able to install useful route entries. But there's not anything > in the current text to suggest that B should be doing that.) As described above, I agree about the usefulness of allowing an intermediate node to store a symmetric address vector.  This will be specified as an optional behavior in the revised document. > > (2) I'm putting this in the Discuss section because I think it's > important for the authors/WG to produce an answer. Since I've been > wrong about it at least once, I do not claim to know the correct answer, > and thus the Discuss point ought to be easy to resolve. > > Section 6.3.3 says: > > Instead, the RPLInstanceID MUST be replaced by > another value so that the two RREP-instances can be distinguished. > In RREP-DIO option, the Shift field of the RREP-DIO message(Figure 2) > indicates the shift to be applied to original RPLInstanceID to obtain > the replacement RPLInstanceID. When the new RPLInstanceID after > shifting exceeds 255, it rolls over starting at 0. For example, if > the original RPLInstanceID is 252, and shifted by 6, the new > RPLInstanceID will be 2. [...] > > I know that the use of 255 as the largest value here comes as a result > of my earlier review, but wanted to note that the resulting discussion > thread may not have fully concluded. > In particular, I now see > https://datatracker.ietf.org/doc/html/rfc6550#section-5.1 that does > indicate that only 6 bits of "usable" ID are present for local > RPLInstanceIDs, which seem to be the ones in use here. Sorry to have > missed that in my initial review; I hope that we can figure out what the > actual correct boundary value is. All 8 bits of the ID are usable.  The design allows for 64 possible alternative choices in the case of a collision.  Collisions are rare, so that should be plenty.  Providing a "shift" operation does not place any restriction on use of all 8 bits for choice of ID.  It just enables the elimination of ID collisions for all foreseeable cases. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Some of the text I comment on below is new in the -11, and I would have > hoped that WG review of the changes would have detected more of this > type of thing. This leaves me uncertain what level of review the WG > actually performed, and I am considering balloting Abstain once my > discuss points are resolved. > > Section 3 > > to TargNode, and another from TargNode to OrigNode. When possible, > AODV-RPL also enables symmetric route discovery along Paired DODAGs > (see Section 5). > > (Modifying a comment I made on the -10) Perhaps we could say "AODV-RPL > also enables discvoery of symmetric routes along Paired DODAGs when > symmetric routes are possible (see Section 5)"? We can use the suggested wording. > > Section 4.2 > > L > 2-bit unsigned integer defined as in RREQ option. > > Per the discussion on my previous ballot thread, I suggest adding "The > lifetime of the RREP-Instance MUST be shorter than the lifetime of the > RREQ-Instance it is paired to" (or similar). We can use the suggested wording. > > Section 4.3 > > Target Prefix / Address > (variable-length field) An IPv6 destination address or prefix. > The Prefix Length field contains the number of valid leading bits > in the prefix. The Target Prefix / Address field contains the > least number of octets that can represent all of the bits of the > Prefix, in other words Ceil(Prefix Length/8) octets. The initial > bits in the Target Prefix / Address field preceding the prefix > length (if any) MUST be set to zero on transmission and MUST be > ignored on receipt. If Prefix Length is zero, the Address field > is 128 bits for IPv6 addresses. > > This is a change from the -10 about where the target prefix is aligned > for prefix lengths that are not a multiple of 8. > I have no stance on which formulation is best, but it seems very > surprising to change the wire encoding in this manner at such a late > stage in the document lifecycle, without specific compelling reasoning. It is still allowable to have Prefixes that are not multiples of 8. It's just that representing those prefixes still takes an integral number of bytes in the message field.  For prefixes that are not multiples of 8, some of the bits in the message field are ignored. > > Section 6.2.1 > > Step 1: > > The router MUST first determine whether to propagate the RREQ-DIO. > It does this by determining whether or not the downstream > direction of the incoming link satisfies the Objective Function > (OF). If not the RREQ-DIO MUST be dropped, and the following > steps are not processed. Otherwise, the router MUST join the > RREQ-Instance and prepare to propagate the RREQ-DIO. The upstream > neighbor router that transmitted the received RREQ-DIO is selected > as the preferred parent. In the second sentence above, s/downstream/upstream/ .  By propagating the RREQ-DIO, a router indicates that it has a route to OrigNode.  Please excuse this confusing typo. > [...] > Step 3: > > If the S bit of the incoming RREQ-DIO is 0, then the route cannot > be symmetric, and the S bit of the RREQ-DIO to be transmitted is > set to 0. Otherwise, the router MUST determine whether the > downward (i.e., towards the TargNode) direction of the incoming > link satisfies the OF. If so, the S bit of the RREQ-DIO to be > transmitted is set to 1. Otherwise the S bit of the RREQ-DIO to > be transmitted is set to 0. > > The step 1 procedure checks the downstream direction of the incoming > link, and the step 3 procedure also checks the dosntream direction of > the incoming link. In order to assess whether the link works as a > symmetric link, I think that these checks need to be on different > directions of that link, but am not confident about which step should > check which direction. As indicated above, Step 1 verifies the upstream direction.   Here is a restatement of the processing that is specified for handling the RREQ-DIO.  The revised document will reorganize the procedure to emphasize these points. * A RREQ-DIO arrives at intermediate node J from neighbor N across the incoming link. * If the incoming link J->N causes the OF to be unsatisfiable for a route to OrigNode, drop and do not continue these steps. * Otherwise the path J->OrigNode satisfies the OF.  In other words, J verifies that neighbor N is a usable next hop for a route to OrigNode.  In this case, node J prepares to advertise the availability of a route to OrigNode, by propagating the RREQ-DIO. * If 'S' bit is NOT set, there is nothing more to do.  Transmit the RREQ-DIO. * If, on the other hand, the 'S' bit is set, check whether or not the downstream direction of the incoming link still allows a usable path for OrigNode to send packets to TargNode.     Since the 'S' bit was set, the OF for the path Orig-->N is advertised to be (roughly) the same as the OF for the path N-->Orig.  From the above, the OF is satisfied for the path J --> Orig.  If J sets the 'S' bit in the outgoing RREQ-DIO, that means that the OF for the path J-->Orig is the same as the OF for the path Orig-->J.  Because the incoming RREQ-DIO had the 'S' bit set, this can be done by ascertaining that the OF for J-->N is the same as the OF for the N-->J. > > section 6.3 > > If the > implementation selects the symmetric route, and the L field is not 0, > the TargNode MAY delay transmitting the RREP-DIO for duration > RREP_WAIT_TIME to await a route with a lower Rank. The value of > > In the -10 the text allowing waiting was present in both the section for > the symmetric case and the section for the asymmetric case; is the > conditional "if the implementation selects the symmetric route" correct? We intend to allow waiting for both symmetric and asymmetric cases. > > Section 6.3.2 > > When a RREQ-DIO arrives at a TargNode with the S bit set to 0, the > TargNode MUST build a DODAG in the RREP-Instance corresponding to the > RREQ-DIO, rooted at itself in order to discover the downstream route > > nit: this comma is misplaced (and may not be needed at all). "RREQ-DIO, rooted at itself"   -->  "RREQ-DIO rooted at itself," > > Section 6.4 > > Upon receiving a RREP-DIO, a router performs the following steps: > > Step 1: > > If the Objective Function is not satisfied, the router MUST NOT > join the DODAG; the router MUST discard the RREQ-DIO, and does not > > s/RREQ/RREP/? Yes, indeed, you are correct. > > If the S-bit of the RREQ-Instance is set to 0, the router MUST > determine whether the downward direction of the link (towards the > TargNode) over which the RREP-DIO is received satisfies the > Objective Function, and the router's Rank would not exceed the > MaxRank limit. If so, the router joins the DODAG of the RREP- > Instance. The router that transmitted the received RREP-DIO is > selected as the preferred parent. Afterwards, other RREP-DIO > messages can be received. > > Please confirm whether "downward direction" is correct. If intermediate node 'J' propagated a RREQ-DIO, J has a route to OrigNode. If the intermediate node 'J' retransmits the RREP-DIO, it is advertising a route to TargNode.  If the S-bit of the RREQ-Instance is zero, the RREP-DIO (i.e., route advertisement) is multicast.  If 'S'=1, and H=1, J unicasts the RREP-DIO is unicast to the next hop of the route that J has available towards OrigNode.  For H=1, this route is available from the stored route that J has for OrigNode (if H=1).  If H=0, the behavior depends on whether or not J has stored the address vector to OrigNode which was included with the RREQ-DIO.  In that case, J MAY append the Address Vector to the address vector in the RREP-DIO, providing a complete address vector OrigNode --> TargNode.  In this case J SHOULD unicast the RREP to the next hop along the way to OrigNode. In other words, "downward direction" is correct.  The clause preceding it can be omitted. An interesting case occurs when an RREP arrives at an intermediate node J that has not received the corresponding RREQ.  In this case, assuming that the OF is satisfied towards TargNode, J multicasts the RREP and the protocol proceeds exactly as before, except that the RREP-instance is not paired with a RREQ-instance.  If the RREP-DIO propagated by J arrives at OrigNode, then OrigNode will have a route to TargNode.  OrigNode will also be able to associate the RREP-DIO with the RREQ-DIO which initiated the route discovery.  We will make this refinement for the notion of paired instances. > It seems to me > that in determining whether to join the RREP-Instance, we need to check > whether the "reply path" (from TargNode to OrigNode) is feasible, and > skip joining the instance if it's not a feasible path. But the text > written here seem to be checking the feasibility of the "request path", > the same direction that was checked in §6.2.1 when deciding whether to > join the RREQ-Instance. From the above, if B joins the RREP-Instance and propagates the RREP with H=1, it is advertising a route to TargNode.  Analogously, for H=0, B is providing an address vector B --> TargNode which upstream nodes can extend.  When the RREP arrives at OrigNode, the RREP has an address vector usable by OrigNode to transmit data to TargNode. > > Section 10 > > Thanks for acting on my previous comment and moving the normative > requirements on nodes to not emit RREPs if they have an address in the > address vector already! I still think it would be worth some text here > in the security considerations about what goes wrong if those checks are > skipped (I think, a routing loop occurs, but that's something of a > guess). I also think a routing loop is the main concern here. > > It seems that if Compr is set too large, there is some risk of a node > failing to check that it shares that many bits of address prefix with > the address in the DODAGID and thus decompression would produce an > incorrect route. We could provide additional specification, but I am not sure it is needed. Old:    Compr       4-bit unsigned integer.  Number of prefix octets that are elided       from the Address Vector.  The octets elided are shared with the       IPv6 address in the DODAGID.  This field is only used in source       routing mode (H=0).  In hop-by-hop mode (H=1), this field MUST be       set to zero and ignored upon reception. New:    Compr       4-bit unsigned integer.    When Compr is nonzero, exactly that       number of prefix octets MUST be elided from each address in       the Address Vector.  The octets elided are shared with the       IPv6 address in the DODAGID.  This field is only used in source       routing mode (H=0).  In hop-by-hop mode (H=1), this field MUST be       set to zero and ignored upon reception. Does this resolve the problem? > > If a rogue router is able to forge a gratuitous RREP, significant > damage might result. > > Would this damage be in the form of traffic amplification, routing loop, > DoS of certain (key) nodes, ...? > > I think the main danger is from disrupting the route discovery, and so DoS.  Or, if the rogue router knows more about the topology, it could maliciously direct traffic to an unwilling recipient, providing another kind of DoS. Regards, Charlie P. --------------2EHMiEQSbBt2RihUk6rvQ70x Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hello Benjamin,

Thank you for your detailed review.  It is very much appreciated, and is helping us to make some significant improvements in the document.  Please see our follow-up and proposed resolutions below.



On 10/29/2021 4:01 PM, Benjamin Kaduk via Datatracker wrote:
Benjamin Kaduk has entered the following ballot position for
draft-ietf-roll-aodv-rpl-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-roll-aodv-rpl/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for the updates in the -11, they are a bit improvement.

(1) I did make a point of looking into the procedures for determining
whether a route will be symmetric or asymmetric, and I'm running into
trouble for the case where an intermediate router determines that a link
cannot work as part of a symmetric route.

For concreteness, let's consider the following snippet of topology:

  +-------+                   +-------+                   +-------+
  |       |    asymmetric     |       |                   |       |
  |   A   +-------------------+   B   +===================+   C   |
  |       |       L1          |       |       L2          |       |
  +-------+                   +-------+                   +-------+

Suppose that an RREQ-DIO arrives at A with S=1 and H=0.  Per step 3 of
§6.2.1, if the link the RREQ-DIO arrived on satisfies the objective
function, the outgoing RREQ-DIO is also transmitted with S=1.
A also associates state with its RREQ-Instance the value of the S bit
from the transmitted RREQ-DIO, i.e., 1.
Check. 
That RREQ-DIO arrives at B, who performs the same check and determines
that the L1 cannot satisfy the objective function.  Accordingly, B sends
out a RREQ-DIO to C with S=0 and stores the state S=0.

If the route to OrigNode from B via L1 cannot satisfy the objective function, B drops the RREQ-DIO.  Otherwise, if L1 is asymmetric but still provides a usable path towards OrigNode, B takes the action you describe.

  The RREQ-DIO
continues to through C to TargNode (or maybe C is TargNode; it may not
matter), and TargNode proceeds to follow asymmetric procedures,
initiating an RREP-DIO with an initially empty address vector.  That
RREP-DIO arrives at C, who has stored state S=0, so C joins the DODAG of
the RREP-Instance, adds its address to the address vector (per step 4 of
§6.4), and sends an RREP-DIO to B.  B likewise has stored state S=0,
adds its address to the address vector, and sends an RREP-DIO to A.  But
A has stored state S=1, so in step 4 of §6.4, A is looking for an
address in the address vector to use as the unicast target for A's
outgoing RREP-DIO.  But there is no such entry in the address vector,
becuase up to now the RREP-DIO has been using asymmetric procedures, and
has no data on how to get from A to OrigNode!

As the RREQ-DIO propagates with H=0, every node that transmits the RREQ-DIO can be used in a source route to OrigNode.  So, when the RREQ is received by B, B has an address vector utilizing A as the next hop for a route to OrigNode.

If the RREQ-Instance at B has S=1, B should optionally be allowed to associate that address vector with the RREQ-Instance.  For S=1, the address vector B-->...->OrigNode is symmetric; if B maintains that information, it could unicast an incoming RREP towards OrigNode.

We will add an appendix with some examples to make this more clear.


Now, it's certainly possible that I've made an error in the above.  But
even if I have, it still seems suggestive that this boundary behavior is
pretty complicated and hard to get right.  It seems like we should have
some similar discussion in the document to cover how this case does
actually work.

(And if I didn't make an error in the above, it seems to still be
salvageable, with B storing a sentinel value of "I changed from S=1 to
S=0" instead of just 1 or 0, and holding on to the (symmetric) address
vector from OrigNode to B.  Then B could perform translation from the
asymmetric to symmetric regime for the RREP and all routers on the path
would be able to install useful route entries.  But there's not anything
in the current text to suggest that B should be doing that.)

As described above, I agree about the usefulness of allowing an intermediate node to store a symmetric address vector.  This will be specified as an optional behavior in the revised document.


(2) I'm putting this in the Discuss section because I think it's
important for the authors/WG to produce an answer.  Since I've been
wrong about it at least once, I do not claim to know the correct answer,
and thus the Discuss point ought to be easy to resolve.

Section 6.3.3 says:

                          Instead, the RPLInstanceID MUST be replaced by
   another value so that the two RREP-instances can be distinguished.
   In RREP-DIO option, the Shift field of the RREP-DIO message(Figure 2)
   indicates the shift to be applied to original RPLInstanceID to obtain
   the replacement RPLInstanceID.  When the new RPLInstanceID after
   shifting exceeds 255, it rolls over starting at 0.  For example, if
   the original RPLInstanceID is 252, and shifted by 6, the new
   RPLInstanceID will be 2. [...]

I know that the use of 255 as the largest value here comes as a result
of my earlier review, but wanted to note that the resulting discussion
thread may not have fully concluded.
In particular, I now see
https://datatracker.ietf.org/doc/html/rfc6550#section-5.1 that does
indicate that only 6 bits of "usable" ID are present for local
RPLInstanceIDs, which seem to be the ones in use here.  Sorry to have
missed that in my initial review; I hope that we can figure out what the
actual correct boundary value is.

All 8 bits of the ID are usable.  The design allows for 64 possible alternative choices in the case of a collision.  Collisions are rare, so that should be plenty.  Providing a "shift" operation does not place any restriction on use of all 8 bits for choice of ID.  It just enables the elimination of ID collisions for all foreseeable cases.




----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Some of the text I comment on below is new in the -11, and I would have
hoped that WG review of the changes would have detected more of this
type of thing.  This leaves me uncertain what level of review the WG
actually performed, and I am considering balloting Abstain once my
discuss points are resolved.

Section 3

   to TargNode, and another from TargNode to OrigNode.  When possible,
   AODV-RPL also enables symmetric route discovery along Paired DODAGs
   (see Section 5).

(Modifying a comment I made on the -10) Perhaps we could say "AODV-RPL
also enables discvoery of symmetric routes along Paired DODAGs when
symmetric routes are possible (see Section 5)"?

We can use the suggested wording. 

Section 4.2

   L
      2-bit unsigned integer defined as in RREQ option.

Per the discussion on my previous ballot thread, I suggest adding "The
lifetime of the RREP-Instance MUST be shorter than the lifetime of the
RREQ-Instance it is paired to" (or similar).

We can use the suggested wording. 

Section 4.3

   Target Prefix / Address
      (variable-length field) An IPv6 destination address or prefix.
      The Prefix Length field contains the number of valid leading bits
      in the prefix.  The Target Prefix / Address field contains the
      least number of octets that can represent all of the bits of the
      Prefix, in other words Ceil(Prefix Length/8) octets.  The initial
      bits in the Target Prefix / Address field preceding the prefix
      length (if any) MUST be set to zero on transmission and MUST be
      ignored on receipt.  If Prefix Length is zero, the Address field
      is 128 bits for IPv6 addresses.

This is a change from the -10 about where the target prefix is aligned
for prefix lengths that are not a multiple of 8.
I have no stance on which formulation is best, but it seems very
surprising to change the wire encoding in this manner at such a late
stage in the document lifecycle, without specific compelling reasoning.

It is still allowable to have Prefixes that are not multiples of 8.  It's just that representing those prefixes still takes an integral number of bytes in the message field.  For prefixes that are not multiples of 8, some of the bits in the message field are ignored. 

Section 6.2.1

   Step 1:

      The router MUST first determine whether to propagate the RREQ-DIO.
      It does this by determining whether or not the downstream
      direction of the incoming link satisfies the Objective Function
      (OF).  If not the RREQ-DIO MUST be dropped, and the following
      steps are not processed.  Otherwise, the router MUST join the
      RREQ-Instance and prepare to propagate the RREQ-DIO.  The upstream
      neighbor router that transmitted the received RREQ-DIO is selected
      as the preferred parent.
In the second sentence above, s/downstream/upstream/ .  By propagating the RREQ-DIO, a router indicates that it has a route to OrigNode.  Please excuse this confusing typo.

   [...]
   Step 3:

      If the S bit of the incoming RREQ-DIO is 0, then the route cannot
      be symmetric, and the S bit of the RREQ-DIO to be transmitted is
      set to 0.  Otherwise, the router MUST determine whether the
      downward (i.e., towards the TargNode) direction of the incoming
      link satisfies the OF.  If so, the S bit of the RREQ-DIO to be
      transmitted is set to 1.  Otherwise the S bit of the RREQ-DIO to
      be transmitted is set to 0.

The step 1 procedure checks the downstream direction of the incoming
link, and the step 3 procedure also checks the dosntream direction of
the incoming link.  In order to assess whether the link works as a
symmetric link, I think that these checks need to be on different
directions of that link, but am not confident about which step should
check which direction.

As indicated above, Step 1 verifies the upstream direction.   Here is a restatement of the processing that is specified for handling the RREQ-DIO.  The revised document will reorganize the procedure to emphasize these points.

  • A RREQ-DIO arrives at intermediate node J from neighbor N across the incoming link.

  • If the incoming link J->N causes the OF to be unsatisfiable for a route to OrigNode, drop and do not continue these steps.

  • Otherwise the path J->OrigNode satisfies the OF.  In other words, J verifies that neighbor N is a usable next hop for a route to OrigNode.  In this case, node J prepares to advertise the availability of a route to OrigNode, by propagating the RREQ-DIO.

  • If 'S' bit is NOT set, there is nothing more to do.  Transmit the RREQ-DIO.

  • If, on the other hand, the 'S' bit is set, check whether or not the downstream direction of the incoming link still allows a usable path for OrigNode to send packets to TargNode.     Since the 'S' bit was set, the OF for the path Orig-->N is advertised to be (roughly) the same as the OF for the path N-->Orig.  From the above, the OF is satisfied for the path J --> Orig.  If J sets the 'S' bit in the outgoing RREQ-DIO, that means that the OF for the path J-->Orig is the same as the OF for the path Orig-->J.  Because the incoming RREQ-DIO had the 'S' bit set, this can be done by ascertaining that the OF for J-->N is the same as the OF for the N-->J.


section 6.3

                                                              If the
   implementation selects the symmetric route, and the L field is not 0,
   the TargNode MAY delay transmitting the RREP-DIO for duration
   RREP_WAIT_TIME to await a route with a lower Rank.  The value of

In the -10 the text allowing waiting was present in both the section for
the symmetric case and the section for the asymmetric case; is the
conditional "if the implementation selects the symmetric route" correct?

We intend to allow waiting for both symmetric and asymmetric cases. 

Section 6.3.2

   When a RREQ-DIO arrives at a TargNode with the S bit set to 0, the
   TargNode MUST build a DODAG in the RREP-Instance corresponding to the
   RREQ-DIO, rooted at itself in order to discover the downstream route

nit: this comma is misplaced (and may not be needed at all).

"RREQ-DIO, rooted at itself"   -->  "RREQ-DIO rooted at itself,"


Section 6.4

   Upon receiving a RREP-DIO, a router performs the following steps:

   Step 1:

      If the Objective Function is not satisfied, the router MUST NOT
      join the DODAG; the router MUST discard the RREQ-DIO, and does not

s/RREQ/RREP/?

Yes, indeed, you are correct.


      If the S-bit of the RREQ-Instance is set to 0, the router MUST
      determine whether the downward direction of the link (towards the
      TargNode) over which the RREP-DIO is received satisfies the
      Objective Function, and the router's Rank would not exceed the
      MaxRank limit.  If so, the router joins the DODAG of the RREP-
      Instance.  The router that transmitted the received RREP-DIO is
      selected as the preferred parent.  Afterwards, other RREP-DIO
      messages can be received.

Please confirm whether "downward direction" is correct.

If intermediate node 'J' propagated a RREQ-DIO, J has a route to OrigNode.

If the intermediate node 'J' retransmits the RREP-DIO, it is advertising a route to TargNode.  If the S-bit of the RREQ-Instance is zero, the RREP-DIO (i.e., route advertisement) is multicast.  If 'S'=1, and H=1, J unicasts the RREP-DIO is unicast to the next hop of the route that J has available towards OrigNode.  For H=1, this route is available from the stored route that J has for OrigNode (if H=1).  If H=0, the behavior depends on whether or not J has stored the address vector to OrigNode which was included with the RREQ-DIO.  In that case, J MAY append the Address Vector to the address vector in the RREP-DIO, providing a complete address vector OrigNode --> TargNode.  In this case J SHOULD unicast the RREP to the next hop along the way to OrigNode.

In other words, "downward direction" is correct.  The clause preceding it can be omitted.

An interesting case occurs when an RREP arrives at an intermediate node J that has not received the corresponding RREQ.  In this case, assuming that the OF is satisfied towards TargNode, J multicasts the RREP and the protocol proceeds exactly as before, except that the RREP-instance is not paired with a RREQ-instance.  If the RREP-DIO propagated by J arrives at OrigNode, then OrigNode will have a route to TargNode.  OrigNode will also be able to associate the RREP-DIO with the RREQ-DIO which initiated the route discovery.  We will make this refinement for the notion of paired instances.


  It seems to me
that in determining whether to join the RREP-Instance, we need to check
whether the "reply path" (from TargNode to OrigNode) is feasible, and
skip joining the instance if it's not a feasible path.  But the text
written here seem to be checking the feasibility of the "request path",
the same direction that was checked in §6.2.1 when deciding whether to
join the RREQ-Instance.

From the above, if B joins the RREP-Instance and propagates the RREP with H=1, it is advertising a route to TargNode.  Analogously, for H=0, B is providing an address vector B --> TargNode which upstream nodes can extend.  When the RREP arrives at OrigNode, the RREP has an address vector usable by OrigNode to transmit data to TargNode.


Section 10

Thanks for acting on my previous comment and moving the normative
requirements on nodes to not emit RREPs if they have an address in the
address vector already!  I still think it would be worth some text here
in the security considerations about what goes wrong if those checks are
skipped (I think, a routing loop occurs, but that's something of a
guess).

I also think a routing loop is the main concern here. 

It seems that if Compr is set too large, there is some risk of a node
failing to check that it shares that many bits of address prefix with
the address in the DODAGID and thus decompression would produce an
incorrect route.

We could provide additional specification, but I am not sure it is needed.

Old:

   Compr
      4-bit unsigned integer.  Number of prefix octets that are elided
      from the Address Vector.  The octets elided are shared with the
      IPv6 address in the DODAGID.  This field is only used in source
      routing mode (H=0).  In hop-by-hop mode (H=1), this field MUST be
      set to zero and ignored upon reception.

New:

   Compr
      4-bit unsigned integer.    When Compr is nonzero, exactly that
      number of prefix octets MUST be elided from each address in
      the Address Vector.  The octets elided are shared with the
      IPv6 address in the DODAGID.  This field is only used in source
      routing mode (H=0).  In hop-by-hop mode (H=1), this field MUST be
      set to zero and ignored upon reception.

Does this resolve the problem?


   If a rogue router is able to forge a gratuitous RREP, significant
   damage might result.

Would this damage be in the form of traffic amplification, routing loop,
DoS of certain (key) nodes, ...?
I think the main danger is from disrupting the route discovery, and so DoS.  Or, if the rogue router knows more about the topology, it could maliciously direct traffic to an unwilling recipient, providing another kind of DoS.

Regards,
Charlie P.
--------------2EHMiEQSbBt2RihUk6rvQ70x--