Subject: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-session-signal-00.txt

From: Ray Bellis <[email-masked]>
Date: Wed, 6 Jul 2016 23:24:06 +0100

I've just submitted this draft, which resulted from discussions in
Buenos Aires related to issues with using EDNS for persistent signalling
(c.f. RFC 7828), and also from an overlap with draft-ietf-dnssd-push and
its (mis-)use of the edns-tcp-keepalive option.

The intention here is to split out session-related stateful options from
the dnssd-push draft into a more generic specification.

Please note that the question of whether to use an alternate message
format for this OpCode (as it is currently specified) or whether to
shoe-horn the options into an RR lookalike (per EDNS) is still a matter
of some debate between the authors.  With no consensus amongst us I felt
if important that the WG be able to weigh in on that debate.

Ray

-------- Forwarded Message --------
Subject: New Version Notification for
draft-bellis-dnsop-session-signal-00.txt

A new version of I-D, draft-bellis-dnsop-session-signal-00.txt
has been successfully submitted by Ray Bellis and posted to the
IETF repository.

Name:		draft-bellis-dnsop-session-signal
Revision:	00
Title:		DNS Session Signaling
Document date:	2016-07-06
Group:		Individual Submission
Pages:		10
URL:
https://www.ietf.org/internet-drafts/draft-bellis-dnsop-session-signal-00.txt
Status:
https://datatracker.ietf.org/doc/draft-bellis-dnsop-session-signal/
Htmlized:
https://tools.ietf.org/html/draft-bellis-dnsop-session-signal-00

Abstract:
   The Extension Mechanisms for DNS (EDNS(0)) [RFC6891] is explicitly
   defined to only have "per-message" semantics.  This document defines
   a new Session Signaling OpCode used to carry persistent "per-session"
   type-length-values (TLVs), and defines an initial set of TLVs used to
   handle feature negotiation and to manage session timeouts and
   termination.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 6 Jul 2016 15:28:57 -0700

Hm, you seem to have left out a definition of what a "session" is.   Do you
mean a TCP connection?   Are you referring to something that's already
defined in a document that I have, lamentably, not read?  (In which case, a
reference would be helpful).

On Wed, Jul 6, 2016 at 3:24 PM, Ray Bellis <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Ray Bellis <[email-masked]>
Date: Wed, 6 Jul 2016 23:32:55 +0100

On 06/07/2016 23:28, Ted Lemon wrote:
> Hm, you seem to have left out a definition of what a "session" is.   Do
> you mean a TCP connection?   Are you referring to something that's
> already defined in a document that I have, lamentably, not read?  (In
> which case, a reference would be helpful).

See the editorial note at the end of §3:

  << RB: OSI Layer 5 session analog?  This is obviously intended for
   TCP "sessions" which aren't distinct from Layer 4, but is this also
   applicable to DNS-o-DTLS, or DNS over UDP with an EDNS cookie - I
   think probably "yes" for the former, but "no" for the latter.  I'm
   wondering whether "session" is even the right term to be using
   here >>

So, yes, our start point is TCP, but it might apply to other protocols
that give the effect of a single end-to-end connection.  That's TBD.

Ray

---

From: Ted Lemon <[email-masked]>
Date: Wed, 6 Jul 2016 15:36:41 -0700

I suspected as much, but it would be good to come up with some language
that says what you intend and gives a TCP connection as an example.   I'm
not entirely convinced that DNS cookie is a bad use case for this... :)

---

From: "Jan Komissar (jkomissa)" <[email-masked]>
Date: Fri, 15 Jul 2016 19:17:08 +0000

Hi Ray,

Here¹s some comments on this draft.

1. Introduction
Even if EDNS(0) currently has "per-message² semantics, I¹m not sure that
it would be wrong to extend it to have per-session semantics when used in
a Session Signaling message.

3.1 Message Format
I am not comfortable with a message format that is not backwards
compatible. Current packet logging code expects all DNS data to be in RR
format, even the EDNS(0) OPT RR. Keeping the Session Signaling in RR
format would make it easier to use existing logging and capturing code.
(How would tcpdump handle a DNS packet with the Session Signaling OpCode
in the current format?)

3.2 Message Handling
While it does make sense that Session Signaling requests are processed in
order, I don¹t think it necessarily makes sense for SS messages to be
³sequencing points.² Since DNS queries may take a long time, a SS message
would block the client from performing any other queries while one
outstanding query is very slow. It could be up to the client if it wants
to wait for all outstanding responses before issuing a SS request.

4.2.1 Terminate
I think the reconnect delay makes sense when you don¹t have anycast or
load-balancing, but still have multiple servers identified by multiple SRV
records. The reconnect delay would then force a client to look for another
server. It also makes sense when a server is trying to shed load and wants
to stop terminated clients from reconnecting immediately.

4.2.2 Idle Timeout

There should be a way for a client to reset the server¹s idle timeout
counter by sending a Session Keepalive message indicating that it¹s still
operational. In cases like DNS Push Notification
(draft-ietf-dnssd-push-08.txt) the client isn¹t idle because it has no
work for the server, but it is waiting for an update from the server that
may or may not come.

DNS Push Notification also specifies that a server should wait 1.5 times
the idle timeout before terminating a client to avoid race conditions
around the timeout expiration. It may be useful to adopt the same practice
here.

Regards,

Jan Komissar

---

From: Matthew Pounsett <[email-masked]>
Date: Sun, 17 Jul 2016 01:52:21 -0700

I think this draft is a good candidate for adoption.

I'd like to echo Ted's comment that the draft should explicitly state the
sort of context this is meant to be used in.  Calling out TCP sessions as
an example would be a good start.  I found myself wondering how the server
is meant to initiate SS messages to the client in a UDP context where the
client is behind a NAT, for example.
I'm also wondering if wouldn't be possible to implement this in a more
backward-compatible way.  I anticipate a lot of people who don't even
intend to capture SS messages having to update their code anyway, because
the messages won't be automatically discarded and will confuse parsers that
attempt to analyze them.  On the other hand, I am wiling to discuss the
merits of advancing the expectation that the message format could change
with the opcode.

---

From: Ray Bellis <[email-masked]>
Date: Sun, 17 Jul 2016 11:45:50 +0200

On 17/07/2016 10:52, Matthew Pounsett wrote:
> I'd like to echo Ted's comment that the draft should explicitly
> state the sort of context this is meant to be used in.  Calling out
> TCP sessions as an example would be a good start.

OK, that's worth calling out, and I'll incorporate something in the next
revision.

It's *definitely* intended for TCP.

> I found myself wondering how the server is meant to initiate SS 
> messages to the client in a UDP context where the client is behind a
>  NAT, for example.

On that particular note - see the first paragraph of the "Protocol
Details" section.  Since UDP doesn't provide the required guarantee it's
implicitly not suitable.

For other "session like" protocols, in discussion with Tom and others
last night, I think it should be suitable for DNS-o-TLS, and likely
DNS-o-DTLS but *not* w.r.t a (D)TLS session resumption.  That is to say,
if a new TCP connection uses the same TLS session as a prior one, that
doesn't count as the same "DNS session".

I think it would *not* be suitable for DNS with Cookies, since that has
an expectation that server farms could share cookie state, and I think
it would be onerous to expect any other "session state" to be shared
across farms.

> I'm also wondering if wouldn't be possible to implement this in a 
> more backward-compatible way.  I anticipate a lot of people who don't
> even intend to capture SS messages having to update their code 
> anyway, because the messages won't be automatically discarded and 
> will confuse parsers that attempt to analyze them.  On the other 
> hand, I am wiling to discuss the merits of advancing the expectation
>  that the message format could change with the opcode.

I've had feedback from both ends of the spectrum - some would like to
use an RR, others would like a completely clean break.

Personally, I think the 12-octet header with what should appear as
"trailing garbage" is a fair compromise.  I've written plenty of DNS
packet parsing code myself that I know would do "interesting things" if
the octets used for the section counts had "odd" data in them, but never
any that would reject a packet outright if there was stuff tacked on the
end.

That said, I could live with an RR-based format, but do feel *very*
strongly that if so it must be a new RR, and not an overload of the
already confused and poorly implemented EDNS OPT RR.

Even then, though, I think it would be a mistake to permit this RR to
end up "tagging along" with a query or response - that's what EDNS is
for, and in part why this specifies an OpCode.

Ray

---

From: Matthew Pounsett <[email-masked]>
Date: Sun, 17 Jul 2016 12:36:26 +0200

> Details" section.  Since UDP doesn't provide the required guarantee it's

Fair enough.  On my first read I was thinking that it's a reasonable
interpretation that unicast UDP meets the requirements, as stated in the
first paragraph of §3.  The client couldn't guarantee it, but the server
could have enough information about whether and what type of load balancing
is in use in its environment to make that guarantee.  Thinking about it
further though, I realize that the server wouldn't know for sure whether
the client is behind a NAT, and then the "guarantee" requirement is out the
window.

I still think it would be helpful to be a little more explicit about it.

> it would be onerous to expect any other "session state" to be shared

I agree.  Even if session state could be reliably shared across servers
within a farm, or across multiple farms, you're still looking at setting up
a new session if the individual server the client is in contact with
becomes unavailable.  The client has no way of knowing the architecture
behind the IP address it's reconnecting to, and so shared session state on
the server end would require additional negotiation to make sure that the
new server and the old client still agree on whatever state was shared
previously.   You have similar issues if the client end is also a farm
initiating queries from behind some sort of NAT or load balancer.  It
quickly gets more complex than simply renegotiating session state.

> any that would reject a packet outright if there was stuff tacked on the

Perhaps I'm misreading it, but this sounds like an argument in favour of an
RR-based format. If the packet isn't rejected, and the software does odd
things with unexpected data, then that's a problem that requires recoding
to avoid corrupting or polluting whatever the output of the analysis is.

However, as much as we admonish middleware boxes for thinking they know
what to expect in the DNS, and doing bad things when it no longer looks
that way, perhaps we should learn the same lesson and only select packets
with opcodes that we know we know how to analyze correctly.