Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt

[Petr Špaček <[e-mail]>]

Hello Ted and Tom,

I'm going to reply to both of you at once.

First of all, I'm not going to push for wire format change any longer.

Your replies show that there is a lot of thoughts behind the document
*but* these are not captured in the document itself nor dnsop mailing
list. (Maybe I'm just incompetent when it comes to searching archives.)

I believe that our disagreement partially comes from misunderstanding
each other, partially from missing information, and of course there is
some true disagreement, but that is a matter of taste :-)

Here I propose explanatory version of Introduction chapter for your
draft. Goal of the proposal is to document why SS deviates from rest of
DNS protocol so we have something to reference when new proposal for
OPCODE=666 comes up (and thus do not need to go though this again).

The text is based on my understanding to Ted and Tom's comments and
might be wrong, feel free to modify it as needed.

------------------
1.  Introduction

|  The use of transports for DNS other than UDP is being increasingly
|  specified, for example, DNS over TCP [RFC1035][RFC7766] and DNS over
|  TLS [RFC7858].  Such transports can offer persistent, long-lived
|  sessions and therefore when using them for transporting DNS messages
|  it is of benefit to have a mechanism that can establish parameters
|  associated with those sessions, such as timeouts.  In such situations
|  it is also advantageous to support server initiated messages.
|
|  The existing EDNS(0) Extension Mechanism for DNS [RFC6891] is
|  explicitly defined to only have "per-message" semantics.  Whilst
|  EDNS(0) has been used to signal at least one session related
|  parameter (the EDNS(0) TCP Keepalive option [RFC7828]) the result is
|  less than optimal due to the restrictions imposed by the EDNS(0)
|  semantics and the lack of server-initiated signalling.

Extending EDNS(0) with "per-session" semantics is not worth the effort
for several reasons: Most importantly EDNS(0) design is based on
assumption that format similar to ordinary RR would make it more likely
that things would work. Past experience shown us that this assumption is
incorrect and in reality it is causing nightmares with middleboxes being
confused by EDNS(0). Secondly, re-using EDNS(0) for "per-session"
operation would be confusing because current code handling per-message
semantics would have to be extended to deal with session semantics.
Thirdly, adding another EDNS0-style option is deemed to be more complex
than using the new proposed format, it would consume more packet space,
and the actual format of the packet would be less sensible, resulting in
more complex decode/encode logic.

To avoid problems related to EDNS(0) usage, this document defines a new
extension mechanism for the original DNS protocol. The new extension is
based on a new Session Signaling OPCODE used to carry persistent
"per-session" operations, expressed using type-length-value (TLV)
syntax. The new Opcode allows us to change the packet format for the better.

|  It should be noted that the message format for Session Signaling
|  operations (see Section 4.1) differs from the traditional DNS packet
|  format used for standard queries and responses.  The standard twelve-
|  octet header is used, but the four count fields (QDCOUNT, ANCOUNT,
|  NSCOUNT, ARCOUNT) are set to zero and the corresponding sections are
|  not present.  The actual data pertaining to Session Signaling
|  operations is appended to the end of the DNS message header.  When
|  displayed using today's packet analyser tools that have not been
|  updated to recognize the DNS Session Signaling format, this will
|  result in the Session Signaling data being displayed as unknown
|  additional data after the end of the DNS message.

In contrast with EDNS(0), this new extension mechanism has no compelling
motivation to pack multiple operations into a single message for
|  efficiency reasons.  Each Session Signaling operation is communicated
|  in its own separate DNS message, and the transport protocol can take
|  care of packing separate DNS messages into a single IP packet if
|  appropriate.  For example, TCP can pack multiple small DNS messages
|  into a single TCP segment.  The RCODE in each response message
|  indicates the success or failure of the operation in question.


On top of this new extension mechanism, this document defines an initial
set of TLVs used to manage session timeouts and termination.

------------------ End of Introduction ------------------


Can we get something explanatory like this into the document, please?
Thank you!


On 18.8.2017 19:39, Ted Lemon wrote:
> El 18 ag 2017, a les 11:12, Petr Špaček <[e-mail]
> <mailto:[e-mail]>> va escriure:
>> My objections are in the end about engineering costs, which was nicely
>> summarized by Paul Vixie in another thread (about SWILD, but applicable
>> to session signaling as well):
>> https://mailarchive.ietf.org/arch/msg/dnsop/xMvOuQqWCWZtql1gqD0UwH354b8
> 
> Paul's arguments aren't at all applicable here.   He's talking about
> having two different resource records that require detailed special
> handling; adding a new resource record that accomplishes what is
> accomplished by existing code in a different way produces a substantial
> increase in complexity not in the transport part of the DNS protocol,
> but in the semantics engine of your DNS cache.
> 
>> For me the major portion of cost does not come from features (like
>> session management etc.) but from the *framework* needed to build them.
>> This cost increase IMHO stems from fact that the framework (SS aka DNS
>> control plane as you named it) does not build on existing and widely
>> available components.
> 
> It's true, TLVs are quite innovative, and have never been used
> elsewhere.   ;-)
> 
>> I believe that added complexity is one of serious technical parameters
>> and I was objecting to it 4 months ago already:
>> https://mailarchive.ietf.org/arch/msg/dnsop/XjbQlz5dPblzfGr0OBrr5afKBEg
> 
> The problem is that you didn't say then, and you don't say now, why this
> supposed complexity is an important technical consideration.   And it's

I'm confused. Do you really claim
"complexity is not an important technical consideration"
?

Is https://tools.ietf.org/html/rfc3439 applicable only to IP?
(Feel free to interpret this as rhetorical question.)


> hard for me to see what the issue is.   Nobody has to support this; i> you support it, it's because you want the features.   If you want the
> features, the complexity isn't really in the wire format serialization
> and deserialization—this are trivial.   The complexity is in, for
> example, implementing DNS Push through a DNS cache if you want to
> support it in that context.   I admit that this is complex, and I
> suspect that there will be little enthusiasm for doing it.   That's
> okay—it's actually not required that any cache implement DNS push in
> order for us to get the benefit of it.   But this complexity has nothing
> to do with the wire format.

Of course, if you want features you have to code them, agreed. The thing
is that this proposal pushes complexity to places which do not want any
features at all.

We need to consider existence of DNS software which cares only about DNS
wire format and nothing else. Many of these tools do not actively
participate in DNS query-response protocol, they just observe and
analyze what is going on wire. Another category are test tools etc.

Nevermind. It will be good enough if we (we as in dnsop) at least
document why SS is deemend to be the right way to extend DNS.

-- 
Petr Špaček  @  CZ.NIC