IETF Logo Mail Archive

Re: [dns-privacy] I-D Action: draft-ietf-dprive-dnsodtls-06.txt

"Prashanth Patil (praspati)" <praspati@cisco.com> Wed, 06 July 2016 13:55 UTC

Return-Path: <praspati@cisco.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C689312B018 for <dns-privacy@ietfa.amsl.com>; Wed, 6 Jul 2016 06:55:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.947
X-Spam-Level:
X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-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
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 3-6sy8SdSKZc for <dns-privacy@ietfa.amsl.com>; Wed, 6 Jul 2016 06:54:59 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0759B12D1E4 for <dns-privacy@ietf.org>; Wed, 6 Jul 2016 06:54:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2532; q=dns/txt; s=iport; t=1467813299; x=1469022899; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ObCjktnCwsZmjeN9FHI0JddFoSBmE8B26bXsb6Ad8pk=; b=nFg+Y6fIPs/rMFi4epyV8gXfiUAgFO6BGWbveX8jRoBTUKkQa57Dscy8 R+qZaq+OjTd/ewE5K0Sk07xjkJqPpOWujLaNkpXoY6zxuv5ofqu17jrsS cJV9poxJJvcEWFx0Jg5x6cJRVOJA1h8BjiUvBcNIin20pLom3Yx1yMMhB k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ABAgBNDX1X/5BdJa1dgz5WfAa5IoF3IoV2AoEpOBQBAQEBAQEBZSeETQEFAQFsCxACAQgOOCcLJQIEAQ0FiDAOvBEBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYYnhE2EKhaFWwWOPIpXAYkChUSPKpAJAR42g3Buh3N/AQEB
X-IronPort-AV: E=Sophos;i="5.28,319,1464652800"; d="scan'208";a="125636904"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jul 2016 13:54:50 +0000
Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u66DsouN025157 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Jul 2016 13:54:50 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 6 Jul 2016 09:54:49 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Wed, 6 Jul 2016 09:54:49 -0400
From: "Prashanth Patil (praspati)" <praspati@cisco.com>
To: Geoff Huston <gih@apnic.net>, "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
Thread-Topic: [dns-privacy] I-D Action: draft-ietf-dprive-dnsodtls-06.txt
Thread-Index: AQHR1432gyf9RfLceka1sFDiaGAhvA==
Date: Wed, 06 Jul 2016 13:54:49 +0000
Message-ID: <D3A25A77.127C8B%praspati@cisco.com>
References: <20160405045114.5783.47505.idtracker@ietfa.amsl.com> <441e3007b75d4145b328000441516253@XCH-RCD-017.cisco.com> <740B865B-FAE8-45FF-B875-37EAE5A43AB7@apnic.net>
In-Reply-To: <740B865B-FAE8-45FF-B875-37EAE5A43AB7@apnic.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.4.160422
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.36.162]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <B8AFADE5B399E1479FF392F794F9D18D@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/389Nq5NjhMc1GCblaosXHnZ6pEs>
Cc: "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Subject: Re: [dns-privacy] I-D Action: draft-ietf-dprive-dnsodtls-06.txt
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Jul 2016 13:55:01 -0000

Hi Geoff,
We¹ve submitted a revision that should address the concern you¹ve rightly
pointed out below. 

-Prashanth

On 5/25/16, 9:24 AM, "dns-privacy on behalf of Geoff Huston"
<dns-privacy-bounces@ietf.org on behalf of gih@apnic.net> wrote:

>Hi 
>
>I have been reading this draft and comparing it to the DTLS RFC (RFC6347)
>
>RFC6347 says:
>
>4.1.1.  Transport Layer Mapping
>
>   Each DTLS record MUST fit within a single datagram.  In order to
>   avoid IP fragmentation, clients of the DTLS record layer SHOULD
>   attempt to size records so that they fit within any PMTU estimates
>   obtained from the record layer.
>
>
>
>
>draft-ietf-dprive-dnsodtls-06.txt says:
>
>   client and server MUST support the EDNS0 option defined in [RFC6891]
>   so that the DNS client can indicate to the DNS server the maximum DNS
>   response size it can handle without IP fragmentation.  If the DNS
>   server's response exceeds the EDNS0 value, the DNS server sets the TC
>   (truncated) bit.  On receiving a response with the TC bit set, the
>   client establishes a DNS-over-TLS connection to the same server, and
>   sends a new DNS request for the same resource record.
>
>These are not precisely consistent. EDNS0 does not specify the maximum
>unfragmented size, of course. It specifies the maximum size that the
>querier is willing to reassemble.
>
>To quote from RFC6891
>
>   The requestor's UDP payload size (encoded in the RR CLASS field) is the
>   number of octets of the largest UDP payload that can be reassembled and
>   delivered in the requestor's network stack.  Note that path MTU, with
>   or without fragmentation, could be smaller than this.
>
>So at this point I'm confused. If the intent is to prevent IP
>fragmentation then the server must sit within the local PMTU estimate, or
>truncate the response to indicate that it could not do so, which means
>that the text in the draft needs revision to reflect this normative
>(MUST) constraint imposed by RFC6347.
>
>Or are these extenuating circumstances in DNS over DTLS that would allow a
>fragmented response that sits within an offerred EDNS0 UDP Buffer size?
>If so, then the draft should clearly document what these circumstances are
>and why the MUST in RFC6347 is not being applied in this case.
>
>thanks,
>
>  Geoff
>
>
>
>
>
>
>_______________________________________________
>dns-privacy mailing list
>dns-privacy@ietf.org
>https://www.ietf.org/mailman/listinfo/dns-privacy

v2.23.0 | Report a Bug | By Email