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

2018-08-02 Thread Ted Lemon 
On Aug 2, 2018, at 9:31 PM, Benjamin Kaduk  wrote:
> That does clean up quite a few things; thank you for putting in the effort
> to makme the broader change!  (Do we care that we no longer talk about SRV
> discovery?  I don't think I do, just wanted to check...)

I don't think we care, but we're going to do a team review since the changes 
prior to the telechat were a bit fast and loose, and we'll come to a consensus 
one way or another.   :)

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2018-08-02 Thread Benjamin Kaduk 
On Thu, Aug 02, 2018 at 10:53:57AM -0400, Ted Lemon wrote:
> On Thu, Aug 2, 2018 at 9:54 AM, Benjamin Kaduk  wrote:
> 
> > > We specifically didn’t want to reference DoH since HTTP is unsuitable
> > for long lived connections and DSO wouldn’t apply here. We didn’t want to
> > imply that DoH was suitable by referencing it.
> >
> > Hmm.  I think DoH is clearly a non-UDP transport for DNS, and it is hard to
> > argue that it is not being specified.  My parenthetical suggestion was
> > probably a bit unclear -- I was proposing to add DNS over HTTP to the list
> > in the first sentence, and change the second sentence to start as "Some
> > such transports can offer persistent[...]".  Does that still seem like it
> > runs the risk of implying that DoH is suitable, to you?
> >
> 
> Rr.   Okay, I agree with you and when I went to do this, it occurred to me
> that we are being silly here—this document has no applicability section.
>  Adding one will really clean this up a lot.   So I've done that:
> 
[diff trimmed]

That does clean up quite a few things; thank you for putting in the effort
to makme the broader change!  (Do we care that we no longer talk about SRV
discovery?  I don't think I do, just wanted to check...)

> 
> > > How about:
> > >
> > > When a new TLV is defined, the specification MUST include whether the
> > DSO-TYPE can be used as the Primary TLV, used as an Additional TLV, or used
> > in either context for both requests and responses.
> >
> > That's probably better (but maybe another comma before "for both requests
> > and responses"?  OTOH, the RFC Editor has a consistent style book to
> > apply...)
> >
> 
> I updated the text to make it more generally imperative, and to be really
> explicit about the point you're making rather than just hoping the comma
> will be enough.  :)
> 
> Specifications that define new TLVs must specify whether the DSO-TYPE
> can be used as the Primary TLV, used as an Additional TLV, or used in either
> context, both in the case of requests and of responses.
> The specification for a TLV must also state whether,
> when used as the Primary (i.e., first) TLV in a DNS request message (i.e.,
> QR=0),
> that DSO message is to be acknowledged.
> If the DSO message is to be acknowledged, the specification
> must also state which TLVs, if any, are to be included in the response.
> The Primary TLV may or may not be contained in the response,
> depending on what is specified for that TLV.

The epitome of clarity :)

Thanks again,

Benjamin

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2018-08-02 Thread Tom Pusateri 
Ted,
Those clarifications look good.

Thanks,
Tom


> On Aug 2, 2018, at 10:53 AM, Ted Lemon  wrote:
> 
> On Thu, Aug 2, 2018 at 9:54 AM, Benjamin Kaduk  > wrote:
> > We specifically didn’t want to reference DoH since HTTP is unsuitable for 
> > long lived connections and DSO wouldn’t apply here. We didn’t want to imply 
> > that DoH was suitable by referencing it.
> 
> Hmm.  I think DoH is clearly a non-UDP transport for DNS, and it is hard to
> argue that it is not being specified.  My parenthetical suggestion was
> probably a bit unclear -- I was proposing to add DNS over HTTP to the list
> in the first sentence, and change the second sentence to start as "Some
> such transports can offer persistent[...]".  Does that still seem like it
> runs the risk of implying that DoH is suitable, to you?
> 
> Rr.   Okay, I agree with you and when I went to do this, it occurred to me 
> that we are being silly here—this document has no applicability section.   
> Adding one will really clean this up a lot.   So I've done that:
> 
> @@ -106,9 +106,11 @@ This document updates RFC 1035 by adding a new DNS 
> header opcode and result code
>  
>  # 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
> +This document specifies a mechanism for managing stateful DNS connections.
> +DNS most commonly operates over a UDP transport, but can also operate over
> +streaming transports; the original DNS RFC specifies DNS over TCP 
> {{!RFC1035}}
> +and a profile for DNS over TLS {{?RFC7858}} has been specified.
> +These 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
> @@ -399,43 +401,40 @@ and to assure client and server that they still have 
> connectivity to each other.
>  
>  ***
>  
> +# Applicability {#applicability}
> +
> +DNS Stateful Operations are applicable in cases where it is useful to 
> maintain an open session
> +between a DNS client and server, where the transport allows such a session 
> to be maintained, and
> +where the transport guarantees in-order delivery of messages, on which DSO 
> depends.  Examples of
> +transports that can support session signaling are DNS-over-TCP {{?RFC1035}} 
> {{?RFC7766}} and
> +DNS-over-TLS {{?RFC7858}}.
> +
> +Note that in the case of DNS over TLS, there is no mechanism for upgrading 
> from DNS-over-TCP
> +to DNS-over-TLS (see {{?RFC7858}} section 7).
> +
> +DNS Stateful Operations are not applicable for transports that cannot 
> support clean session
> +semantics, or that do not guarantee in-order delivery.   While in principle 
> such a transport
> +could be constructed over UDP, the current DNS specification over UDP 
> transport {{RFC1035}}
> +does not provide in-order delivery or session semantics, and hence cannot be 
> used..  Similarly,
> +DNS-over-HTTP {{?I-D.ietf-doh-dns-over-https}} cannot be used because HTTP 
> has its own
> +mechanism for managing sessions, and this is incompatible with the mechanism 
> specified here.
> +
> +No other transports are currently defined for use with DNS Stateful 
> Operations.  Such transports
> +can be added in the future, if they meet the requirements set out in the 
> first paragraph of this
> +section.
> +
>  # Protocol Details {#details}
>  
>  ## DSO Session Establishment {#establishment}
>  
> -DSO messages MUST NOT be carried in protocols and
> -environments where a session can't be established.   For example,
> -DNS over plain UDP {{?RFC0768}} is not appropriate since it does not provide
> -in-order message delivery, and, in the presence of NAT gateways and firewalls
> -with short UDP timeouts, it cannot provide a persistent bi-directional
> -communication channel unless an excessive amount of DSO keepalive traffic is 
> used.
> -UDP also doesn't provide a way to mark the start of a session and the end
> -of a session.
> -
> -At the time of publication, DSO is specified only
> -for DNS over TCP {{!RFC1035}} {{!RFC7766}}, and
> -for DNS over TLS over TCP {{?RFC7858}}.
> -Any use of DSO over some other connection technology needs to be
> -specified in an appropriate future document.
> -
> -Determining whether a given connection is using DNS over TCP, or DNS
> -over TLS over TCP, is outside the scope of this specification, and
> -must be determined using some out-of-band configuration information.
> -There is no provision within the DSO specification to
> -turn TLS on or off during the lifetime of a connection.
> -For service types where the service instance is discovered
> -using a DNS SRV record {{?RFC2782}},
>

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

2018-08-02 Thread Ted Lemon 
On Thu, Aug 2, 2018 at 9:54 AM, Benjamin Kaduk  wrote:

> > We specifically didn’t want to reference DoH since HTTP is unsuitable
> for long lived connections and DSO wouldn’t apply here. We didn’t want to
> imply that DoH was suitable by referencing it.
>
> Hmm.  I think DoH is clearly a non-UDP transport for DNS, and it is hard to
> argue that it is not being specified.  My parenthetical suggestion was
> probably a bit unclear -- I was proposing to add DNS over HTTP to the list
> in the first sentence, and change the second sentence to start as "Some
> such transports can offer persistent[...]".  Does that still seem like it
> runs the risk of implying that DoH is suitable, to you?
>

Rr.   Okay, I agree with you and when I went to do this, it occurred to me
that we are being silly here—this document has no applicability section.
 Adding one will really clean this up a lot.   So I've done that:

@@ -106,9 +106,11 @@ This document updates RFC 1035 by adding a new DNS
header opcode and result code

 # 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
+This document specifies a mechanism for managing stateful DNS connections.
+DNS most commonly operates over a UDP transport, but can also operate over
+streaming transports; the original DNS RFC specifies DNS over TCP
{{!RFC1035}}
+and a profile for DNS over TLS {{?RFC7858}} has been specified.
+These 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
@@ -399,43 +401,40 @@ and to assure client and server that they still have
connectivity to each other.

 ***

+# Applicability {#applicability}
+
+DNS Stateful Operations are applicable in cases where it is useful to
maintain an open session
+between a DNS client and server, where the transport allows such a session
to be maintained, and
+where the transport guarantees in-order delivery of messages, on which DSO
depends.  Examples of
+transports that can support session signaling are DNS-over-TCP
{{?RFC1035}} {{?RFC7766}} and
+DNS-over-TLS {{?RFC7858}}.
+
+Note that in the case of DNS over TLS, there is no mechanism for upgrading
from DNS-over-TCP
+to DNS-over-TLS (see {{?RFC7858}} section 7).
+
+DNS Stateful Operations are not applicable for transports that cannot
support clean session
+semantics, or that do not guarantee in-order delivery.   While in
principle such a transport
+could be constructed over UDP, the current DNS specification over UDP
transport {{RFC1035}}
+does not provide in-order delivery or session semantics, and hence cannot
be used.  Similarly,
+DNS-over-HTTP {{?I-D.ietf-doh-dns-over-https}} cannot be used because HTTP
has its own
+mechanism for managing sessions, and this is incompatible with the
mechanism specified here.
+
+No other transports are currently defined for use with DNS Stateful
Operations.  Such transports
+can be added in the future, if they meet the requirements set out in the
first paragraph of this
+section.
+
 # Protocol Details {#details}

 ## DSO Session Establishment {#establishment}

-DSO messages MUST NOT be carried in protocols and
-environments where a session can't be established.   For example,
-DNS over plain UDP {{?RFC0768}} is not appropriate since it does not
provide
-in-order message delivery, and, in the presence of NAT gateways and
firewalls
-with short UDP timeouts, it cannot provide a persistent bi-directional
-communication channel unless an excessive amount of DSO keepalive traffic
is used.
-UDP also doesn't provide a way to mark the start of a session and the end
-of a session.
-
-At the time of publication, DSO is specified only
-for DNS over TCP {{!RFC1035}} {{!RFC7766}}, and
-for DNS over TLS over TCP {{?RFC7858}}.
-Any use of DSO over some other connection technology needs to be
-specified in an appropriate future document.
-
-Determining whether a given connection is using DNS over TCP, or DNS
-over TLS over TCP, is outside the scope of this specification, and
-must be determined using some out-of-band configuration information.
-There is no provision within the DSO specification to
-turn TLS on or off during the lifetime of a connection.
-For service types where the service instance is discovered
-using a DNS SRV record {{?RFC2782}},
-the specification for that service type SRV name {{?RFC6335}}
-will state whether the connection uses plain TCP, or TLS over TCP.
-For example, the specification for the
-"_dns‑push‑tls._tcp" service {{?I-D.ietf-dnssd-push}},
-states that it uses TLS.
-It is a common convention that protocols specified to run over TLS
-are given IANA service type names

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

2018-08-02 Thread Benjamin Kaduk 
On Tue, Jul 31, 2018 at 03:53:57PM -0400, Tom Pusateri wrote:
> 
> 
> > On Jul 27, 2018, at 11:24 AM, Benjamin Kaduk  wrote:
> > 
> > 
> > --
> > DISCUSS:
> > --
> > 
> > Hopefully this first point is simple to resolve (whether by changing text 
> > or merely
> > un-confusing me).  The other ones may require some actual discussion,
> > though.
> > 
> > Section 6.6.1.2 has:
> > 
> >   After a DSO Session is ended by the server (either by sending the
> >   client a Retry Delay message, or by forcibly aborting the underlying
> >   transport connection) the client SHOULD try to reconnect, to that
> >   service instance, or to another suitable service instance, if more
> >   than one is available.
> > 
> > which seems to contradict the text from Section 3:
> > 
> > %  [...] Given that these fatal error
> > %  conditions signify defective software, and given that defective
> > %  software is likely to remain defective for some time until it is
> > %  fixed, after forcibly aborting a connection, a client SHOULD refrain
> > %  from automatically reconnecting to that same service instance for at
> > %  least one hour.
> > 
> > Given some other mentions in the document about aborting the connection, it
> > may be that I am just reading the "refrain from reconnecting for an hour"
> > more strongly than I should be.
> 
> Section 3 discusses fatal errors on the server side that aren’t likely to 
> change until the software is modified so there’s no use having the client 
> retry quickly (hence the one hour). Section 6.6.1.2 is about receiving a 
> Retry Delay message and the server having the close the connection because 
> the client didn’t follow the spec and close the connection when asked.
> 
> I think the difference can be described as Section 3 talks about how the 
> client deals with server bugs and Section 6.6.1.2 describes how the server 
> deals with client bugs.
> 
> Does that help?

That helps with the intent; I'll need some time to go through the document
and see whether the document text matches the intent and I was just
confused, or if I should suggest some text changes.

> > 
> > Is Section 5.1.2 expected to be considered an "application protocol
> > profile" that defines the use of TLS 1.3 0-RTT data for DSO?  (If so, I do
> > not personally feel that it provides adequate treatment to be considered as
> > such.)
> > 
> > 
> > I should probably leave this to my (transport-area?) colleagues to discuss
> > further, but I'm not sure that the interaction of this mechanism with
> > high-RTT connections is fully covered -- for example, the inactivity
> > timeout in Section 6.4(.x) could behave poorly when the timeout is set to a
> > smaller value than the RTT, as the server would potentially end up starting
> > the "forcibly abort" process (and potentially causing the client to lose
> > for an hour) because the server's timer starts when it sends the DSO
> > response that initiates its idea of the session, and would not recieve
> > graceful shutdown messages from a properly-behaving client in time.
> > 
> 
> The 0 RTT discussion is also happening in another thread so I will not 
> address it here.
> 
> > 
> > I'm not sure that the behavior specified in Section 7.1.2 is entirely safe.
> > Consider when a client sends a DSO keepalive to try to request a DSO
> > session, but subsequently sends EDNS(0) TCP Keepalive (whether "just in
> > case" or for some other reason).  The Server will receive the DSO keepalive
> > and respond, creating a session, but the EDNS(0) TCP Keepalive is already
> > in flight.  I don't remember seeing any text that prevents this client
> > behavior explicitly, but that seems like the right sort of thing to do.
> 
> Ok, is this more clear?
> 
> The inactivity timeout value in the Keepalive TLV (DSO-TYPE=1) has similar 
> intent to the edns-tcp-keepalive EDNS0 Option [RFC7828] 
> .
>  A client/server pair that supports DSO MUST NOT use the edns-tcp-keepalive 
> EDNS0 Option within any message after a DSO Session has been established. A 
> client that has sent a DSO message to establish a session MUST NOT send an 
> edns-tcp-keepalive EDNS0 Option from this point on. Once a DSO Session has 
> been established, if either client or server receives a DNS message over the 
> DSO Session that contains an edns-tcp-keepalive EDNS0 Option, this is a fatal 
> error and the receiver of the edns-tcp-keepalive EDNS0 Option MUST forcibly 
> abort the connection immediately.

I think that addresses my concern, thanks.  (I know it does seem a little
silly to worry about, but part of what I do as SEC AD is look for edge
cases...)

> > 
> > 
> > --
> > COMMENT:
> > --
> > 
> > Six authors exceeds five, so "there is likely to be

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

2018-08-01 Thread Ted Lemon 
On Aug 1, 2018, at 7:17 AM, Mirja Kuehlewind (IETF)  wrote:
> Might not hurt to also just mention this in the doc as a reminder for the 
> reader...

Good point.  I have made the following change:

 The format for DSO messages
 ({{format}}) differs somewhat from the traditional DNS message
 format used for standard queries and responses.
 The standard twelve-byte header is used, but the four count fields
 (QDCOUNT, ANCOUNT, NSCOUNT, ARCOUNT) are set to zero and accordingly their
 corresponding sections are not present.
+
 The actual data pertaining to DNS Stateful Operations
 (expressed in TLV syntax) is appended to the end of the DNS message header.
+The stream protocol carrying the DSO message frames it with 16-bit message 
length, so
+the length of the DSO data is determined from that length, rather than from 
any of
+the DNS header counts.
+
 When displayed using packet analyzer tools that have not been
 updated to recognize the DSO format, this
 will result in the DSO data being displayed

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2018-08-01 Thread Mirja Kuehlewind (IETF) 
Might not hurt to also just mention this in the doc as a reminder for the 
reader...

> Am 31.07.2018 um 22:25 schrieb Benjamin Kaduk :
> 
> On Tue, Jul 31, 2018 at 04:14:41PM -0400, Tom Pusateri wrote:
>> 
>> 
>>> On Jul 31, 2018, at 3:53 PM, Tom Pusateri  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.
> 
> Ah, that would do the trick.  It looks like I only chased up through the
> header format in 1035 and didn't scroll down to the "TCP usage" section.
> Sorry for the noise.
> 
> -Benjamin
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2018-07-31 Thread Benjamin Kaduk 
On Tue, Jul 31, 2018 at 04:14:41PM -0400, Tom Pusateri wrote:
> 
> 
> > On Jul 31, 2018, at 3:53 PM, Tom Pusateri  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.

Ah, that would do the trick.  It looks like I only chased up through the
header format in 1035 and didn't scroll down to the "TCP usage" section.
Sorry for the noise.

-Benjamin

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2018-07-31 Thread Ted Lemon 
On Jul 31, 2018, at 4:14 PM, Tom Pusateri  wrote:
> 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.

And just as an additional data point, I just now pointed my DNSSD Discovery 
Relay implementation at BIND 9, and BIND 9 returned "Not Implemented" as 
expected, and did not drop the connection.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2018-07-31 Thread Tom Pusateri 


> On Jul 31, 2018, at 3:53 PM, Tom Pusateri  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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2018-07-31 Thread Tom Pusateri 


> On Jul 27, 2018, at 11:24 AM, Benjamin Kaduk  wrote:
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-dnsop-session-signal-12: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> Hopefully this first point is simple to resolve (whether by changing text or 
> merely
> un-confusing me).  The other ones may require some actual discussion,
> though.
> 
> Section 6.6.1.2 has:
> 
>   After a DSO Session is ended by the server (either by sending the
>   client a Retry Delay message, or by forcibly aborting the underlying
>   transport connection) the client SHOULD try to reconnect, to that
>   service instance, or to another suitable service instance, if more
>   than one is available.
> 
> which seems to contradict the text from Section 3:
> 
> %  [...] Given that these fatal error
> %  conditions signify defective software, and given that defective
> %  software is likely to remain defective for some time until it is
> %  fixed, after forcibly aborting a connection, a client SHOULD refrain
> %  from automatically reconnecting to that same service instance for at
> %  least one hour.
> 
> Given some other mentions in the document about aborting the connection, it
> may be that I am just reading the "refrain from reconnecting for an hour"
> more strongly than I should be.

Section 3 discusses fatal errors on the server side that aren’t likely to 
change until the software is modified so there’s no use having the client retry 
quickly (hence the one hour). Section 6.6.1.2 is about receiving a Retry Delay 
message and the server having the close the connection because the client 
didn’t follow the spec and close the connection when asked.

I think the difference can be described as Section 3 talks about how the client 
deals with server bugs and Section 6.6.1.2 describes how the server deals with 
client bugs.

Does that help?

> 
> Is Section 5.1.2 expected to be considered an "application protocol
> profile" that defines the use of TLS 1.3 0-RTT data for DSO?  (If so, I do
> not personally feel that it provides adequate treatment to be considered as
> such.)
> 
> 
> I should probably leave this to my (transport-area?) colleagues to discuss
> further, but I'm not sure that the interaction of this mechanism with
> high-RTT connections is fully covered -- for example, the inactivity
> timeout in Section 6.4(.x) could behave poorly when the timeout is set to a
> smaller value than the RTT, as the server would potentially end up starting
> the "forcibly abort" process (and potentially causing the client to lose
> for an hour) because the server's timer starts when it sends the DSO
> response that initiates its idea of the session, and would not recieve
> graceful shutdown messages from a properly-behaving client in time.
> 

The 0 RTT discussion is also happening in another thread so I will not address 
it here.

> 
> I'm not sure that the behavior specified in Section 7.1.2 is entirely safe.
> Consider when a client sends a DSO keepalive to try to request a DSO
> session, but subsequently sends EDNS(0) TCP Keepalive (whether "just in
> case" or for some other reason).  The Server will receive the DSO keepalive
> and respond, creating a session, but the EDNS(0) TCP Keepalive is already
> in flight.  I don't remember seeing any text that prevents this client
> behavior explicitly, but that seems like the right sort of thing to do.

Ok, is this more clear?

The inactivity timeout value in the Keepalive TLV (DSO-TYPE=1) has similar 
intent to the edns-tcp-keepalive EDNS0 Option [RFC7828] 
.
 A client/server pair that supports DSO MUST NOT use the edns-tcp-keepalive 
EDNS0 Option within any message after a DSO Session has been established. A 
client that has sent a DSO message to establish a session MUST NOT send an 
edns-tcp-keepalive EDNS0 Option from this point on. Once a DSO Session has been 
established, if either client or server receives a DNS message over the DSO 
Session that contains an edns-tcp-keepalive EDNS0 Option, this is a fatal error 
and the receiver of the edns-tcp-keepalive EDNS0 Option MUST forcibly abort the 
connection immediately.

> 
> 
> --
> COMMENT:
> --
> 
> Six authors exceeds five, so "there is likely to be discussion" about this
>

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

2018-07-30 Thread Mirja Kuehlewind (IETF) 
Hi Ben, hi all,

as you summoned an TSV AD...

> Am 27.07.2018 um 17:24 schrieb Benjamin Kaduk :
> 
> I should probably leave this to my (transport-area?) colleagues to discuss
> further, but I'm not sure that the interaction of this mechanism with
> high-RTT connections is fully covered -- for example, the inactivity
> timeout in Section 6.4(.x) could behave poorly when the timeout is set to a
> smaller value than the RTT, as the server would potentially end up starting
> the "forcibly abort" process (and potentially causing the client to lose
> for an hour) because the server's timer starts when it sends the DSO
> response that initiates its idea of the session, and would not recieve
> graceful shutdown messages from a properly-behaving client in time.

My understanding is that they require a minimum time-out of 5 second at the 
server side, which seems reasonably safe to me. However, maybe this could be 
further clarified or explained in the doc.

Mirja


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2018-07-30 Thread Benjamin Kaduk 
Hi Mirja,

On Mon, Jul 30, 2018 at 08:11:52PM +0200, Mirja Kuehlewind (IETF) wrote:
> Hi Ben, hi all,
> 
> as you summoned an TSV AD...
> 
> > Am 27.07.2018 um 17:24 schrieb Benjamin Kaduk :
> > 
> > I should probably leave this to my (transport-area?) colleagues to discuss
> > further, but I'm not sure that the interaction of this mechanism with
> > high-RTT connections is fully covered -- for example, the inactivity
> > timeout in Section 6.4(.x) could behave poorly when the timeout is set to a
> > smaller value than the RTT, as the server would potentially end up starting
> > the "forcibly abort" process (and potentially causing the client to lose
> > for an hour) because the server's timer starts when it sends the DSO
> > response that initiates its idea of the session, and would not recieve
> > graceful shutdown messages from a properly-behaving client in time.
> 
> My understanding is that they require a minimum time-out of 5 second at the 
> server side, which seems reasonably safe to me. However, maybe this could be 
> further clarified or explained in the doc.

I'm happy to defer to your expertise -- thanks!

-Benjamin

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2018-07-27 Thread Benjamin Kaduk 
Benjamin Kaduk has entered the following ballot position for
draft-ietf-dnsop-session-signal-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/



--
DISCUSS:
--

Hopefully this first point is simple to resolve (whether by changing text or 
merely
un-confusing me).  The other ones may require some actual discussion,
though.

Section 6.6.1.2 has:

   After a DSO Session is ended by the server (either by sending the
   client a Retry Delay message, or by forcibly aborting the underlying
   transport connection) the client SHOULD try to reconnect, to that
   service instance, or to another suitable service instance, if more
   than one is available.

which seems to contradict the text from Section 3:

%  [...] Given that these fatal error
%  conditions signify defective software, and given that defective
%  software is likely to remain defective for some time until it is
%  fixed, after forcibly aborting a connection, a client SHOULD refrain
%  from automatically reconnecting to that same service instance for at
%  least one hour.

Given some other mentions in the document about aborting the connection, it
may be that I am just reading the "refrain from reconnecting for an hour"
more strongly than I should be.


Is Section 5.1.2 expected to be considered an "application protocol
profile" that defines the use of TLS 1.3 0-RTT data for DSO?  (If so, I do
not personally feel that it provides adequate treatment to be considered as
such.)


I should probably leave this to my (transport-area?) colleagues to discuss
further, but I'm not sure that the interaction of this mechanism with
high-RTT connections is fully covered -- for example, the inactivity
timeout in Section 6.4(.x) could behave poorly when the timeout is set to a
smaller value than the RTT, as the server would potentially end up starting
the "forcibly abort" process (and potentially causing the client to lose
for an hour) because the server's timer starts when it sends the DSO
response that initiates its idea of the session, and would not recieve
graceful shutdown messages from a properly-behaving client in time.


I'm not sure that the behavior specified in Section 7.1.2 is entirely safe.
Consider when a client sends a DSO keepalive to try to request a DSO
session, but subsequently sends EDNS(0) TCP Keepalive (whether "just in
case" or for some other reason).  The Server will receive the DSO keepalive
and respond, creating a session, but the EDNS(0) TCP Keepalive is already
in flight.  I don't remember seeing any text that prevents this client
behavior explicitly, but that seems like the right sort of thing to do.


--
COMMENT:
--

Six authors exceeds five, so "there is likely to be discussion" about this
being too large a number of authors.  What is the justification for the
author count?

Do we need to specify some GREASE (per draft-ietf-tls-grease) for new TLV
types in order to ensure the proper handling of unknown types?

Section-by-section comments follow.

Section 1

A DoH reference seems timely/apt.  (But maybe then it is only "Some such
transports" that can offer persistent sessions.)

Maybe give some examples of advantages of server-initiated messages?  Are
we talking about letting the server push records with larger TTLs or
notifying when the response to a query is changing, or just more mundane
keepalive-type things?

Section 3

   The terms "initiator" and "responder" correspond respectively to the
   initial sender and subsequent receiver of a DSO request message or
   unacknowledged message, regardless of which was the "client" and
   "server" in the usual DNS sense.

We just defined "client" and "server" explictly (without reference to the
"usual DNS sense"), so probably it's best to have this definition refer to
the previous client/server definitions or clarify that the above
definitions match the "usual DNS sense".

   When an anycast service is configured on a particular IP address and
   port, it must be the case that although there is more than one
   physical server responding on that IP address, each such server can
   be treated as equivalent.  If a change in network topology causes
   packets in a particular TCP connection to be sent to an anycast
   server instance that does not know about the connection, the normal
   keepalive and TCP connection