Re: [homenet] DNCP/HNCP Revisited
Juliusz Chroboczek <jch@irif.fr> Fri, 20 September 2019 12:23 UTC
Return-Path: <jch@irif.fr>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC02120170 for <homenet@ietfa.amsl.com>; Fri, 20 Sep 2019 05:23:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 KvUQxFYcE4ZA for <homenet@ietfa.amsl.com>; Fri, 20 Sep 2019 05:23:46 -0700 (PDT)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 AC52B120147 for <homenet@ietf.org>; Fri, 20 Sep 2019 05:23:45 -0700 (PDT)
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x8KCNeHK003226; Fri, 20 Sep 2019 14:23:40 +0200
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 6B2785E9AC; Fri, 20 Sep 2019 14:23:43 +0200 (CEST)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id C3SV8gkMnKqS; Fri, 20 Sep 2019 14:23:42 +0200 (CEST)
Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 2F3E25E9A8; Fri, 20 Sep 2019 14:23:42 +0200 (CEST)
Date: Fri, 20 Sep 2019 14:23:42 +0200
Message-ID: <87woe3nokx.wl-jch@irif.fr>
From: Juliusz Chroboczek <jch@irif.fr>
To: "Ray Hunter (v6ops)" <v6ops@globis.net>
Cc: HOMENET <homenet@ietf.org>
In-Reply-To: <27d90625-1a38-3738-d4ce-66bc3ed839b3@globis.net>
References: <87woe3vqbj.wl-jch@irif.fr> <be600313-ed7b-40d5-b44a-92b38f9ada8c@email.android.com> <874l17p7x5.wl-jch@irif.fr> <27d90625-1a38-3738-d4ce-66bc3ed839b3@globis.net>
User-Agent: Wanderlust/2.15.9
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 20 Sep 2019 14:23:40 +0200 (CEST)
X-Miltered: at korolev with ID 5D84C4CC.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 5D84C4CC.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/<jch@irif.fr>
X-j-chkmail-Score: MSGID : 5D84C4CC.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/G1G0LAY_ij2X0t1RUt2FDE8ECDA>
Subject: Re: [homenet] DNCP/HNCP Revisited
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Homenet WG mailing list <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Sep 2019 12:23:48 -0000
>>> 1) DNCP allows an option of whether a network state TLV contains optional >>> nested payload (HNCP) TLV's or not. >> I'm pretty sure that's not the case. RFC 7787 Section 7.2.2. > A OK so you're saying this is already covered in (Section 4.4 of) 7787 [...] > state hash. The Node State TLVs SHOULD NOT contain the optional > node data part to avoid redundant transmission of node data, > unless explicitly specified in the DNCP profile. > So what I was suggesting was merely additional clarification of that. Careful here. There is no optional part in the *network*-state TLV - this TLV's payload is just the network state hash. The optional payload is for the *node*-state TLVs. >> The replying node MUST reply to all node state queries. However, it is up >> to the replying node whether these replies are sent in a single packet or >> split into multiple packets. > So requesting multiple node status TLV's in one packet could lead to an > oversized UDP reply packet. Yes, this was discussed back in July 2015. Here's what I said back then: It should also say that a node MUST NOT send a datagram with a larger payload, and that it MUST silently drop any larger datagrams (optionally log to system management, etc.). If this is not done, persistent state desynchronisation may occur. This is what Markus replied: I am not sure I want to cripple use in non-crippled networks, just provide guaranteed base value which works everywhere and *RED ALERT* light should light up on crippledbox if it encounters this Since nobody supported my position at the time, I had to agree to the following: - Section 3 of RFC 778 says that "Each node MUST be able to receive (and potentially reassemble) UDP datagrams with a payload of at least 4000 bytes." - there is no limit on the size of the packets that a node may send. > So if I understand you correctly, you're saying this is the problem of the > sender of the response to ensure UDP fragmentation doesn't break, I'm not sure what you mean. We certainly assume that the network obeys RFCs 2460 and 4443. > and that multiple long UDP replies can be generated from a single query > packet (potential amplification). Let's please discuss security at some other time, I'd like the current discussion to come to a conclusion first. > If there's multiple UDP replies required for a single query, would you expect > sending of these individual packets to also be rate limited by trickle? Let's please discuss congestion control at some other time, I'd like the current discussion to come to a conclusion first. > What behavior would we expect from the requester during this time? The requester parses each top-level TLV in turn, and acts upon it. > Wait for all outstanding replies to arrive? No. The requester parses each top-level TLV and acts upon it as soon as it arrives. > Re-transmit a node TLV request for missing / dropped replies? How would the receiving node detect missing replies? If some node-state TLVs are missing, then the receiving node's state might not get updated correctly, which will cause the network hash to mismatch, which will be detected when it receives a new network-state TLV (trickle-driven, worst-case 17s). -- Juliusz
- [homenet] DNCP/HNCP Revisited Ray Hunter (v6ops)
- Re: [homenet] DNCP/HNCP Revisited Mark Andrews
- Re: [homenet] DNCP/HNCP Revisited Ray Hunter (v6ops)
- Re: [homenet] DNCP/HNCP Revisited Gert Doering
- Re: [homenet] DNCP/HNCP Revisited Michael Richardson
- Re: [homenet] DNCP/HNCP Revisited Juliusz Chroboczek
- Re: [homenet] DNCP/HNCP Revisited Ted Lemon
- Re: [homenet] DNCP/HNCP Revisited Ted Lemon
- Re: [homenet] DNCP/HNCP Revisited Ted Lemon
- Re: [homenet] DNCP/HNCP Revisited Juliusz Chroboczek
- Re: [homenet] DNCP/HNCP Revisited Juliusz Chroboczek
- Re: [homenet] DNCP/HNCP Revisited Juliusz Chroboczek
- Re: [homenet] DNCP/HNCP Revisited Ted Lemon
- Re: [homenet] DNCP/HNCP Revisited Ray Hunter (v6ops)
- Re: [homenet] DNCP/HNCP Revisited RayH
- Re: [homenet] DNCP/HNCP Revisited Juliusz Chroboczek
- Re: [homenet] DNCP/HNCP Revisited Juliusz Chroboczek
- Re: [homenet] DNCP/HNCP Revisited Juliusz Chroboczek
- Re: [homenet] DNCP/HNCP Revisited Ted Lemon
- Re: [homenet] DNCP/HNCP Revisited RayH
- Re: [homenet] DNCP/HNCP Revisited Juliusz Chroboczek
- Re: [homenet] DNCP/HNCP Revisited Ray Hunter (v6ops)
- Re: [homenet] DNCP/HNCP Revisited Juliusz Chroboczek
- Re: [homenet] DNCP/HNCP Revisited Ray Hunter (v6ops)
- Re: [homenet] DNCP/HNCP Revisited Juliusz Chroboczek