Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-session-signal-12: (with DISCUSS and COMMENT)

Tom Pusateri <pusateri@bangj.com> Tue, 31 July 2018 20:14 UTC

Return-Path: <pusateri@bangj.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E17C5130E80; Tue, 31 Jul 2018 13:14:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[HTML_MESSAGE=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 iMciUqL7p30K; Tue, 31 Jul 2018 13:14:43 -0700 (PDT)
Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3350F130DD6; Tue, 31 Jul 2018 13:14:43 -0700 (PDT)
Received: from butte.attlocal.net (172-125-168-43.lightspeed.rlghnc.sbcglobal.net [172.125.168.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 76A7411D; Tue, 31 Jul 2018 16:12:01 -0400 (EDT)
From: Tom Pusateri <pusateri@bangj.com>
Message-Id: <C2528F63-6B39-4E50-92E6-B089E776BA3F@bangj.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D22AC67C-8DE8-42AB-84AA-FAD7F4BC1AE4"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Tue, 31 Jul 2018 16:14:41 -0400
In-Reply-To: <EFFB4DC5-5A4B-4EAB-8B9F-56229080CDF0@bangj.com>
Cc: tjw.ietf@gmail.com, dnsop@ietf.org, dnsop-chairs@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-dnsop-session-signal@ietf.org
To: Benjamin Kaduk <kaduk@mit.edu>
References: <153270509617.32757.1191915890190419981.idtracker@ietfa.amsl.com> <EFFB4DC5-5A4B-4EAB-8B9F-56229080CDF0@bangj.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/yQu0FYOBgdkAjFrxKdDtyCIfIIs>
Subject: Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-session-signal-12: (with DISCUSS and COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Jul 2018 20:14:45 -0000


> On Jul 31, 2018, at 3:53 PM, Tom Pusateri <pusateri@bangj.com> wrote:
> 
>> 
>>   If the RCODE is set to any value other than NOERROR (0) or DSOTYPENI
>>   ([TBA2] tentatively 11), then the client MUST assume that the server
>>   does not implement DSO at all.  In this case the client is permitted
>>   to continue sending DNS messages on that connection, but the client
>>   SHOULD NOT issue further DSO messages on that connection.
>> 
>> I'm confused how the server would still have proper framing for subsequent
>> DNS messages, since the DSO TLVs would be "spurious extra data" after a
>> request header and potentially subject to misinterpretation as the start of
>> another DNS message header.
> 
> Yes, this is a serious oversight. I think we are going to need to encode differently to make all the TLVs look like an RR externally so the RDLEN can be used to skip them and add a single count or switch the TLV syntax back to RR syntax. The existing DNS header format / RR format is less than ideal...
> 

My co-authors reminded me about the TCP framing for DNS which gives the length of the DNS message so it can easily be skipped so this isn’t a problem.

Thanks,
Tom