Re: [DNSOP] Mirja Kühlewind's Discuss on draft-ietf-dnsop-session-signal-12: (with DISCUSS and COMMENT)

[Mirja Kuehlewind (IETF)]

Hi Ted,

see inline.

> Am 26.10.2018 um 16:58 schrieb Ted Lemon :
> 
> Okay, I'm going to update the document to add a clarification about the 
> handling of early data outside of TFO.   I think the keepalive issue is a 
> matter of judgment, and we would almost have to rewrite the document to 
> change how that works now.   Looking at the MacOS documentation, I can see 
> ways that I might be able to get the behavior we want, but I don't know how 
> available this API is, and I think it's reasonable not to assume that it is 
> available in all cases.   So unless you absolutely insist, I am not going to 
> change this.

I don’t insist. My initial comment was actually about the concrete text and the 
example you give (less about the mechanism). The point is that there is a 
dependency on the RTT and in your text you don’t say anything about the RTT 
which makes it hard to follow. I’m still not sure if that example is needed at 
all but if you want to keep it, it should be right. 

Also now that I understood what you do, I don’t think it’s the best choice but 
usually it should be fine.

Still, I would recommend two additional things maybe: 1) Maybe a short 
discussion that tcp keep-alives could be used if available and configurable 
instead. And 2) make very clear that it doesn’t make sense to have a keep alive 
time out that is smaller than the RTT. 

> 
> As for the delayed ack timer implementation, the point of this is to call the 
> implementor's attention to this.   If they are setting values for the delayed 
> ack timer, then they already know about this issue; if not, the default 
> behavior is as described.

Actually different systems have different default values and given this is a 
sysctl not all people deploying this, maybe be the same ones configuring the 
system, or might not even have the right to configure the system.

>   Furthermore, one of the goals of this text is to avoid having the 
> implementor override TCP settings that are actually correct.   For example, 
> we don't want TCP_NODELAY here.   We don't want to disable the delayed ack 
> timer, or to mess with its duration.   What we want is for normal TCP 
> processing to happen, but for the app to signal to the tcp stack that it's 
> not going to send a response.   This is new behavior, which is already 
> available in some commercial stacks, but not in all stacks, and we want the 
> implementor to use it if it's there.   That's why this text is here.

Understood. Still the text should be correct :-)

Mirja



> 
> On Fri, Oct 26, 2018 at 10:32 AM Mirja Kuehlewind (IETF) 
>  wrote:
> Hi Ted,
> 
> please see below.
> 
> > Am 26.10.2018 um 15:59 schrieb Ted Lemon :
> > 
> > On Fri, Oct 26, 2018 at 9:35 AM Mirja Kuehlewind (IETF) 
> >  wrote:
> > I guess you mean RFC8446 :-)
> > Yup, sorry.
> >  
> > The table there on p.18 shows only the TLS handshake, there is a TCP 
> > handshake before that.
> > 
> > I don't believe this is correct, and given your comment at the end maybe 
> > I'm just misunderstanding.   Are you saying that the TLS handshake is never 
> > included in the SYN packet with TFO, or are you saying that it might not be 
> > in the SYN packet?  
> 
> None of both. If TFO is NOT used, there is first a normal TCP handshake and 
> then eventually TLS 0-RTT. TLS 0-RTT only means that you can send data at 
> then same time then the TLS handshake is performed.
> 
> If TFO is used, there can be data in the SYN. If TLS is used usually the TLS 
> initial packet would be in that SYN data, however, there might not be enough 
> space to send any other 0-RTT data in that packet because it is really just 
> one packet.
> 
> So the answer is that I actually don’t how TFO with TLS 0-RTT is implemented 
> in practice. But for sure without TFO there is the TCP handshake first (one 
> RTT) and then any TLS traffic happens.
> 
> Does that help, or was that confusing again?
> 
> > If the TLS handshake doesn't come in the TFO packet, there's a round trip, 
> > so we have some assurance that we are not being flooded with TCP SYN 
> > packets by an off-link spoofer faking its source address.  
> 
> No flooding can happen, however, there are migration techniques. E.g. if you 
> are overloaded, don’t process the data immediately or TCP could even drop the 
> data and it would be retransmitted. Yes, this causes additional latency but 
> you would only do that in an attack situation. I believe this is discussed in 
> the TFO RFC7413.
> 
> > So it's only in the case that TLS 1.3 early data in the TFO packet is an 
> > issue.   I suppose because of the way that early data is handled, if it 
> > were present in the third packet there might be some risk, but to be honest 
>

Re: [DNSOP] Mirja Kühlewind's Discuss on draft-ietf-dnsop-session-signal-12: (with DISCUSS and COMMENT)

[Mirja Kuehlewind (IETF)]

Hi Ted,

please see below.

> Am 26.10.2018 um 15:59 schrieb Ted Lemon :
> 
> On Fri, Oct 26, 2018 at 9:35 AM Mirja Kuehlewind (IETF)  
> wrote:
> I guess you mean RFC8446 :-)
> Yup, sorry.
>  
> The table there on p.18 shows only the TLS handshake, there is a TCP 
> handshake before that.
> 
> I don't believe this is correct, and given your comment at the end maybe I'm 
> just misunderstanding.   Are you saying that the TLS handshake is never 
> included in the SYN packet with TFO, or are you saying that it might not be 
> in the SYN packet?  

None of both. If TFO is NOT used, there is first a normal TCP handshake and 
then eventually TLS 0-RTT. TLS 0-RTT only means that you can send data at then 
same time then the TLS handshake is performed.

If TFO is used, there can be data in the SYN. If TLS is used usually the TLS 
initial packet would be in that SYN data, however, there might not be enough 
space to send any other 0-RTT data in that packet because it is really just one 
packet.

So the answer is that I actually don’t how TFO with TLS 0-RTT is implemented in 
practice. But for sure without TFO there is the TCP handshake first (one RTT) 
and then any TLS traffic happens.

Does that help, or was that confusing again?

> If the TLS handshake doesn't come in the TFO packet, there's a round trip, so 
> we have some assurance that we are not being flooded with TCP SYN packets by 
> an off-link spoofer faking its source address.  

No flooding can happen, however, there are migration techniques. E.g. if you 
are overloaded, don’t process the data immediately or TCP could even drop the 
data and it would be retransmitted. Yes, this causes additional latency but you 
would only do that in an attack situation. I believe this is discussed in the 
TFO RFC7413.

> So it's only in the case that TLS 1.3 early data in the TFO packet is an 
> issue.   I suppose because of the way that early data is handled, if it were 
> present in the third packet there might be some risk, but to be honest I do 
> not know what the risk would be, and that was not part of the threat analysis 
> that Benjamin asked us to do (or at least if it was, I didn't notice, and 
> Benjamin seems okay with the outcome).

There is a replay attack for 0-RTT data in TLS which is independent of use of 
TFO or not. This is why you should not send none idempotent data in 0-RTT. 
However, I think this is correctly addressed in the draft.

>   If you think we've missed something here, it would help to get clarity on 
> that.   I do not claim to be an SME!   If there is an issue, I think the fix 
> would be to just make the text about early data apply whether it's in a TFO 
> or not.

Yes, I think the case with and with TFO must be discussed separately.

>  
> > The phrasing here is a bit confusing, to me at least. It sounds a bit like 
> > there is a special TCP for DSO… maybe the following is a bit better:
> >"With a DSO request message, TCP delayed acknowledge timer will usually
> >make the implementation wait for the
> >application-layer client software to generate the corresponding DSO
> >response message before it sends out an TCP acknowledgment
> >This will generate a 
> >single combined IP packet containing the TCP acknowledgement, the TCP
> >window update, and the application-generated DSO response message and
> >is more efficient than sending three separate IP packets.“
> > 
> > (Note that the deplayed ack timer can be configured to a very small value 
> > as well, and as such it depends on the processing time and the value of the 
> > timer if a TCP implementation will wait or not.)
> > 
> > I think using the passive voice here makes the text harder to follow, but I 
> > see what you are saying.   How about this:
> > 
> > With a bidirectional exchange over TCP, as for example with a DSO request
> > message, the operating system TCP implementation waits for the
> 
> "the operating system’s TCP implementation will usually wait for"
> 
> or even better
> 
> „the deplayed acknowledgments timer in TCP will usually wait for"
> 
> Is there an error in the text as proposed?   I understand that the way the 
> text expresses this point is not how you would express the point, but this 
> feels like a nitpick, not an actual problem in the text.

I think it would be important to add the „usually" because the TCP delayed 
acknowledgement timer is configurable and it depends on it value and the exact 
timing of the application if what you write is true or not. 

>  
> > Remember that keepalives are not synchronous.   That is, if we send a 
> > keepalive, we don't wait for the response.   So it's perfectly possible for 
> > there to be several k

Re: [DNSOP] Mirja Kühlewind's Discuss on draft-ietf-dnsop-session-signal-12: (with DISCUSS and COMMENT)

[Mirja Kuehlewind (IETF)]

Hi Ted,

please see below.

> Am 23.10.2018 um 21:51 schrieb Ted Lemon :
> 
> On Mon, Oct 15, 2018 at 10:02 AM Mirja Kuehlewind (IETF) 
>  wrote:
> sorry for the delay, however, as you performed a couple of changes it took me 
> a while to re-review. I believe I’m unfortunately not fully ready to release 
> my discuss at this point, but close..
> 
> No worries—it's a busy time.
>  
> Regarding my first discuss point (delayed ACKs aso.) I think the text 
> improved and  I would like to seem my minor wording question (comment 2) 
> below addressed before I finally release the discuss here. However, I still 
> think the extensive discussion as provided in section 9.5 now, does not 
> necessarily belong in this document. Therefore I would rather would have 
> preferred to move this text in a real appendix, or removed it completely and 
> maybe document in an own informational RFC (in tcpm).
> 
> Regarding my second discuss point (keep-alives), the text seems still not 
> quite right yet, or I’m really confused. Please also see also further below 
> (comment 3).
> 
> Anyway here are my comments on the edited/new text in the order they appear 
> in the draft:
> 
> 1) I think the following text in section 3 is not fully correct:
> 
> "Fast Open message: A TCP SYN packet that begins a DSO connection and
>contains early data ([RFC8446] section 2.3).  Fast Open is only
>permitted when using TLS encapsulation: a TCP SYN message that does
>not use TLS encapsulation but contains early data is not permitted.“
> If TLS 0-RTT is used this data will not be carried in the TCP SYN, it will 
> „just“ be send at the same time as the TLS handshake is performed (but after 
> the TCP handshake). Only if TCP Fast Open (TFO) (see RFC7413) is used, data 
> can also be sent in the TCP SYN. I guess you mainly need to fix the reference 
> here, or maybe name both mechanisms separately.
> 
> If you look at the table on p. 18 of RFC8447, it shows early data being sent 
> in the first packet.  What am I missing here?

I guess you mean RFC8446 :-)

The table there on p.18 shows only the TLS handshake, there is a TCP handshake 
before that.

>  
> 2) In section 5.5.1:
>"With a DSO request message, the TCP implementation waits for the
>application-layer client software to generate the corresponding DSO
>response message, which enables the TCP implementation to send a
>single combined IP packet containing the TCP acknowledgement, the TCP
>window update, and the application-generated DSO response message.
>This is more efficient than sending three separate IP packets.“
> 
> The phrasing here is a bit confusing, to me at least. It sounds a bit like 
> there is a special TCP for DSO… maybe the following is a bit better:
>"With a DSO request message, TCP delayed acknowledge timer will usually
>make the implementation wait for the
>application-layer client software to generate the corresponding DSO
>response message before it sends out an TCP acknowledgment
>This will generate a 
>single combined IP packet containing the TCP acknowledgement, the TCP
>window update, and the application-generated DSO response message and
>is more efficient than sending three separate IP packets.“
> 
> (Note that the deplayed ack timer can be configured to a very small value as 
> well, and as such it depends on the processing time and the value of the 
> timer if a TCP implementation will wait or not.)
> 
> I think using the passive voice here makes the text harder to follow, but I 
> see what you are saying.   How about this:
> 
> With a bidirectional exchange over TCP, as for example with a DSO request
> message, the operating system TCP implementation waits for the

"the operating system’s TCP implementation will usually wait for"

or even better

„the deplayed acknowledgments timer in TCP will usually wait for"

> application-layer client software to generate the corresponding DSO
> response message.   It can then send a
> single combined packet containing the TCP acknowledgement, the
> TCP window update, and the application-generated DSO response message..
> This is more efficient than sending three separate packets, as would occur if
> the TCP packet containing the DSO request were acknowledged immediately.
> 
> 3) Section 6.5.2
> "For example, a (hypothetical and unrealistic)
>keepalive interval value of 100 ms would result in a continuous
>stream of ten messages per second or more, in both directions, to
>keep the DSO Session alive.  And, in this extreme example, a single
>packet loss and retransmission over a long path could introduce a
>momentary pause in the stream of messages of over 200 m

Re: [DNSOP] Mirja Kühlewind's Discuss on draft-ietf-dnsop-session-signal-12: (with DISCUSS and COMMENT)

[Mirja Kuehlewind (IETF)]

Sorry, one more comment on section 11.1:
"DSO permits zero round-trip operation using TCP Fast Open [RFC7413]
with TLS 1.3 [RFC8446] 0-RTT to reduce or eliminate round trips in  
session establishment.“

This sounds like TCP Fast Open and TLS 0-RTT can only be used together. However 
these are to different mechanism with different properties/problems and I don’t 
think they should be mixed up.

Data that is send with with TLS 0-RTT must be idempotent as for this data an 
reply attack is possible which is not the case for the rest of the TLS data. 
However with TCP without TLS (but maybe TFO) reply attacks are always possible, 
so that’s not an additional problem if TFO.

With TFO however, a server could start processing without having a return 
routability proof, however, such a problem can also be addressed on the 
server-side by simply not stat processing large request before the TCP 
connection is fully established and that is actually safer than leaving the 
decisions to the client.

Please clarify that TLS 0-RTT can be used without TFO (or TFO can be used 
without TLS) and I would also recommend to discuss the respective issue 
separately.

Mirja




> Am 15.10.2018 um 16:02 schrieb Mirja Kuehlewind (IETF) :
> 
> Hi Ted,
> 
> sorry for the delay, however, as you performed a couple of changes it took me 
> a while to re-review. I believe I’m unfortunately not fully ready to release 
> my discuss at this point, but close..
> 
> Regarding my first discuss point (delayed ACKs aso.) I think the text 
> improved and  I would like to seem my minor wording question (comment 2) 
> below addressed before I finally release the discuss here. However, I still 
> think the extensive discussion as provided in section 9.5 now, does not 
> necessarily belong in this document. Therefore I would rather would have 
> preferred to move this text in a real appendix, or removed it completely and 
> maybe document in an own informational RFC (in tcpm).
> 
> Regarding my second discuss point (keep-alives), the text seems still not 
> quite right yet, or I’m really confused. Please also see also further below 
> (comment 3).
> 
> Anyway here are my comments on the edited/new text in the order they appear 
> in the draft:
> 
> 1) I think the following text in section 3 is not fully correct:
> 
> "Fast Open message: A TCP SYN packet that begins a DSO connection and
>   contains early data ([RFC8446] section 2.3).  Fast Open is only
>   permitted when using TLS encapsulation: a TCP SYN message that does
>   not use TLS encapsulation but contains early data is not permitted.“
> If TLS 0-RTT is used this data will not be carried in the TCP SYN, it will 
> „just“ be send at the same time as the TLS handshake is performed (but after 
> the TCP handshake). Only if TCP Fast Open (TFO) (see RFC7413) is used, data 
> can also be sent in the TCP SYN. I guess you mainly need to fix the reference 
> here, or maybe name both mechanisms separately.
> 
> 
> 2) In section 5.5.1:
>   "With a DSO request message, the TCP implementation waits for the
>   application-layer client software to generate the corresponding DSO
>   response message, which enables the TCP implementation to send a
>   single combined IP packet containing the TCP acknowledgement, the TCP
>   window update, and the application-generated DSO response message.
>   This is more efficient than sending three separate IP packets.“
> 
> The phrasing here is a bit confusing, to me at least. It sounds a bit like 
> there is a special TCP for DSO… maybe the following is a bit better:
>   "With a DSO request message, TCP delayed acknowledge timer will usually
>   make the implementation wait for the
>   application-layer client software to generate the corresponding DSO
>   response message before it sends out an TCP acknowledgment
>   This will generate a 
>   single combined IP packet containing the TCP acknowledgement, the TCP
>   window update, and the application-generated DSO response message and
>   is more efficient than sending three separate IP packets.“
> 
> (Note that the deplayed ack timer can be configured to a very small value as 
> well, and as such it depends on the processing time and the value of the 
> timer if a TCP implementation will wait or not.)
> 
> 3) Section 6.5.2
> "For example, a (hypothetical and unrealistic)
>   keepalive interval value of 100 ms would result in a continuous
>   stream of ten messages per second or more, in both directions, to
>   keep the DSO Session alive.  And, in this extreme example, a single
>   packet loss and retransmission over a long path could introduce a
>   momentary pause in the stream of messages of over 200 ms, long enough
>   to cause the server to overzealously abort the connection.“
>

Re: [DNSOP] Mirja Kühlewind's Discuss on draft-ietf-dnsop-session-signal-12: (with DISCUSS and COMMENT)

[Mirja Kuehlewind (IETF)]

Hi Ted,

sorry for the delay, however, as you performed a couple of changes it took me a 
while to re-review. I believe I’m unfortunately not fully ready to release my 
discuss at this point, but close..

Regarding my first discuss point (delayed ACKs aso.) I think the text improved 
and  I would like to seem my minor wording question (comment 2) below addressed 
before I finally release the discuss here. However, I still think the extensive 
discussion as provided in section 9.5 now, does not necessarily belong in this 
document. Therefore I would rather would have preferred to move this text in a 
real appendix, or removed it completely and maybe document in an own 
informational RFC (in tcpm).

Regarding my second discuss point (keep-alives), the text seems still not quite 
right yet, or I’m really confused. Please also see also further below (comment 
3).

Anyway here are my comments on the edited/new text in the order they appear in 
the draft:

1) I think the following text in section 3 is not fully correct:

"Fast Open message: A TCP SYN packet that begins a DSO connection and
   contains early data ([RFC8446] section 2.3).  Fast Open is only
   permitted when using TLS encapsulation: a TCP SYN message that does
   not use TLS encapsulation but contains early data is not permitted.“
If TLS 0-RTT is used this data will not be carried in the TCP SYN, it will 
„just“ be send at the same time as the TLS handshake is performed (but after 
the TCP handshake). Only if TCP Fast Open (TFO) (see RFC7413) is used, data can 
also be sent in the TCP SYN. I guess you mainly need to fix the reference here, 
or maybe name both mechanisms separately.


2) In section 5.5.1:
   "With a DSO request message, the TCP implementation waits for the
   application-layer client software to generate the corresponding DSO
   response message, which enables the TCP implementation to send a
   single combined IP packet containing the TCP acknowledgement, the TCP
   window update, and the application-generated DSO response message.
   This is more efficient than sending three separate IP packets.“

The phrasing here is a bit confusing, to me at least. It sounds a bit like 
there is a special TCP for DSO… maybe the following is a bit better:
   "With a DSO request message, TCP delayed acknowledge timer will usually
   make the implementation wait for the
   application-layer client software to generate the corresponding DSO
   response message before it sends out an TCP acknowledgment
   This will generate a 
   single combined IP packet containing the TCP acknowledgement, the TCP
   window update, and the application-generated DSO response message and
   is more efficient than sending three separate IP packets.“

(Note that the deplayed ack timer can be configured to a very small value as 
well, and as such it depends on the processing time and the value of the timer 
if a TCP implementation will wait or not.)

3) Section 6.5.2
"For example, a (hypothetical and unrealistic)
   keepalive interval value of 100 ms would result in a continuous
   stream of ten messages per second or more, in both directions, to
   keep the DSO Session alive.  And, in this extreme example, a single
   packet loss and retransmission over a long path could introduce a
   momentary pause in the stream of messages of over 200 ms, long enough
   to cause the server to overzealously abort the connection.“
I think this example is still not correct (and the changes might made have it 
worse: how can there be more then 10 messages?)

So the point here is that there is a dependency on the RTT. Only if the RTT is 
smaller than 200ms this can happen, otherwise the connection is closed anyway 
after two keep-alives. However, if the RTT is much smaller than 100ms and e.g. 
TLP is used, it would still work even if one packet is lost.

In any case, I don’t think this example is actually very helpful. The point is 
that the keep-alives interval should always be much larger than the RTT to make 
this work appropriately. However, the point about keeping the network load is, 
is rather independent to the question of when the mechanism actually breaks. I 
would recommend to simply remove this example and just say that the interval 
MUST not be smaller than 10 sec to keep the network load reasonably low.

However, having read this and the previous section again, I think your 
implementation of the keep-alives mechanism could also be improved. Usually, 
there should be two intervals. One defines, how long the connection can be idle 
before an keeps-live is sent and one that defines when a keeper-lives should be 
retransmitted if it is deemed to be lost, where the first one just usually be 
larger than the second one (and both timers should always be larger than the 
RTT). That would enable faster failure if the connection is actually lost. 

4) Section 6.6.2.2. (Reconnecting After an Unexplained Connection Drop)
  "It is also possible for a server to forcibly terminate the
 

Re: [DNSOP] Mirja Kühlewind's Discuss on draft-ietf-dnsop-session-signal-12: (with DISCUSS and COMMENT)

[Mirja Kuehlewind (IETF)]

One minor comment (as I’m reviewing the updated version…)

> Am 02.08.2018 um 08:35 schrieb Ted Lemon :
> 
> 4) sec 5.1 "It is a common
>convention that protocols specified to run over TLS are given IANA
>service type names ending in "-tls"."
> Not sure this is true. Isn't it usually just an "s" at the end? Or with
> registry are you talking about?
> 
> https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml
> 
> I think the "s" suffix is more for URIs and /etc/services (which is 
> informal).   I've added a reference to the registry.

Actually both is commonly used, -tls or just an s at the end… anyway, not 
important I guess.

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

Re: [DNSOP] Mirja Kühlewind's Yes on draft-ietf-dnsop-refuse-any-07: (with COMMENT)

[Mirja Kuehlewind (IETF)]

Hi all,

please see below.

> Am 14.09.2018 um 13:26 schrieb Tony Finch :
> 
> 神明達哉  wrote:
>> 
>> Whether we *SHOULD* (rather than MAY) allow the conventional response
>> in case of TCP is a different question, on which I don't have a strong
>> opinion.

That the question I had. Currently the doc only says 

"A DNS responder MAY behave differently when processing ANY queries
   received over different transport“

which kind of implicitly say, refuse-any is always the right default… I was 
wondering if for the case of TCP a SHOULD would actually be more appropriate. 

> 
> I think at the moment it is mostly harmless and sometimes helpful for
> debugging or inspection - e.g. `dig` switches to TCP by default for ANY
> queries to avoid confusing users with partial answers, so it makes use of
> this SHOULD.

There is no SHOULD right now...

> 
> If I look into my crystal ball at a future where resolvers query auth
> servers over TLS, then the balance might change. Maybe at that point it'll
> be better for resolvers to implement refuse-any rather than relying on
> auth servers to do it for them; or maybe it'll be better to do
> refuse-any over all transports. Dunno :-)

That’s also fine. If it is not clear which recommendation should be given for 
TCP then it does make sense to say anything more than what the doc currently 
says.

Mirja



> 
> Tony.
> -- 
> f.anthony.n.finchhttp://dotat.at/
> North Fitzroy: Variable 3 or 4, becoming southerly or southeasterly 5 or 6 in
> west. Moderate. Occasional rain in west. Good, occasionally moderate in west.

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

Re: [DNSOP] Mirja Kühlewind's Yes on draft-ietf-dnsop-refuse-any-07: (with COMMENT)

[Mirja Kuehlewind (IETF)]

Hi Olafur,

please see below.

> Am 13.09.2018 um 00:02 schrieb Ólafur Guðmundsson :
> 
> 
> 
> On Mon, Sep 10, 2018 at 11:27 PM, Mirja Kühlewind  wrote:
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-dnsop-refuse-any-07: Yes
> 
> 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-refuse-any/
> 
> 
> 
> --
> COMMENT:
> --
> 
> I'm wondering if it would make sense to provide stronger guidance that the
> conventional ANY response SHOULD be provided if TCP is used as TCP already
> provides a retrun routability proof...? Also maybe provide a refernce to
> RFC7766?
> 
> This has nothing to do with "retrun routability"  if big answers are given to 
> resolver via TCP then the resolver can be used as amplifier and there 
> Millions of those on the net. 

With TCP you usually set up a TCP connection (3-way handshake) then send the 
request on that connection and get the reply on that connection. You can not 
change the IP address in the mean time. So there should not be that 
amplification attack anymore. That was what I was saying.

> 
> IMHO the only time big ANY answer CAN be returned is when the connection is 
> authenticated and approved. 

Not sure what you mean by „approved" but I guess that is what TCP gives you. If 
you really need authentication you’d need to use TLS but not sure why that 
would help.
> 
> 
> And one smallish comment: Would it make sense to refer
> draft-ietf-dnsop-terminology-bis-09 (or actually the soon to be new RFC)
> instead of RFC7719?
> 
> 
> Hope this happens by RFC-editor or in AUth48

It will only happen if you replace [RFC7719] which 
[draft-ietf-dnsop-terminology-bis-09] because then the RFC editor knows that 
there is a dependency and will wait with the publication until 
draft-ietf-dnsop-terminology-bis-09 has an RFC number and then replace 
automatically [draft-ietf-dnsop-terminology-bis-09] with the RFC-to-be.

Mirja



> 
> Olafur
>  
> 
> 
> 
> -- 
> Ólafur Gudmundsson | Engineering Director 
> www.cloudflare.com blog.cloudflare.com

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

Re: [DNSOP] Stuart and I had a discussion about the flow control issue in your DISCUSS (Mirja)

[Mirja Kuehlewind (IETF)]

Hi Ted,

thanks for the quick reply and discussion.

> Am 02.08.2018 um 20:03 schrieb Ted Lemon :
> 
> The issue is that turning on TCP_NODELAY doesn't actually do the right thing, 
> nor does removing the delayed ACK timer.   Both of these are heuristic 
> solutions that apply across the entire session, and have negative 
> consequences (which is why they are on by default).
> 
> What we need is actually a very small thing, in a sense: the ability to say 
> "I got the message, and will not be responding to it," so that the existing 
> heuristic is satisfied in exactly the same way that sending a response 
> satisfies it.
> 
> It's true that on a gigabit ethernet, just turning off the heuristics and 
> sending whatever we have whenever we have it isn't likely to cause problems, 
> but this stuff also has to work in home networks and over wide-area links and 
> even low-bandwidth mobile links, where we can't assume that we have as much 
> headroom as we do on a gigabit ethernet link.
> 
> We think that it is probably worth the IETF thinking about this problem, yet 
> at the same time that's out of scope for the current work.   But not talking 
> about the problem at all in the current work means that when the solution to 
> this problem starts appearing in APIs, which seems likely, there will be no 
> advice in the document about what the implementation should do.
> 
> What we propose to do therefore is to put in a paragraph that briefly 
> mentions the issue and says "when unacknowledged messages are received, if an 
> API is present to inform the TCP layer that no response will be sent, the 
> responder SHOULD do so."   And then the text from the section as it was when 
> you put the DISCUSS on it would go in an Appendix, so that it's clear what's 
> going on.   We can then reference this section in the text telling the 
> implementation what to do.
> 
> Will this satisfy your DISCUSS (assuming that we don't make mistakes in how 
> we document this)?

Yes, please proceed and make the changes. I guess we can work on the wording if 
you have text and if needed but moving it to the appendix makes it less 
critical and is probably the right thing to do.

Thanks!
Mirja



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

Re: [DNSOP] Mirja Kühlewind's Discuss on draft-ietf-dnsop-session-signal-12: (with DISCUSS and COMMENT)

[Mirja Kuehlewind (IETF)]

Hi Stuart,

please see below.

> Am 01.08.2018 um 09:48 schrieb Stuart Cheshire :
> 
> On 30 Jul 2018, at 13:19, Mirja Kühlewind  wrote:
> 
>> --
>> DISCUSS:
>> --
> 
> I’m responding to the “DISCUSS” items right now. I’ll get to the “COMMENT” 
> items shortly.
> 
>> 1) In addition to the bullet point in the 6.2 that was flagged by Spencer, I
>> would like to discuss the content of section 5.4.  (DSO Response 
>> Generation). I
>> understand the desire to optimize for the case where the application knows 
>> that
>> no data will be sent as reply to a certain message, however, TCP does not 
>> have
>> a notion of message boundaries and therefore cannot and should not act based 
>> on
>> the reception of a certain message. Indicating to the TCP that an ACK can be
>> set immediately in an specific situation is also problematic as ACK 
>> processing
>> is part of the TCP's internal machinery. However, why it is important at all
>> that an TCP-level ACK is send out fast than the delayed ACK timer? The ACK
>> receiver does not expose the information when an ACK is received to the
>> application and the delayed ACK timer only expires if no further data is
>> received/send by the ACK-receiver, therefore this optimization should not 
>> have
>> any impact in the application performance. I would just recommend to remove
>> this section and any additional discussion about delayed ACKs.
>> 
>> Please note that the problem described in [NagleDA] only occurs for
>> request-response protocols where no further request can be sent before the
>> response is received. This is not the case in this protocol (as pipelining is
>> supported).
> 
> The problem here is not further requests, it’s further responses. Consider a 
> client that subscribes for mDNS relay service 
> .
> 
> If the server gets an mDNS packet and relays it, Nagle blocks relaying of a 
> further mDNS packet until an ack is received. On a campus GigE backbone with 
> sub-millisecond round-trip times, this potentially delays the relaying of a 
> subsequent mDNS packet for up to 200 ms. That’s a long time on a 
> sub-millisecond network. If the client were to send a reply to the first 
> relayed mDNS packet, then TCP would piggyback its ack on that data packet, 
> and Nagle would then free the server to relay the next mDNS packet.
> 
> The optimization advocated here is the observation that if a networking API 
> were to allow the server to explicitly indicate an empty reply, then that 
> lets the TCP stack know that it doesn’t need to wait 200 ms in the hope that 
> it can piggyback its ack on an outbound data packet.

I unterstand the point, I just don’t really think that this is a problem that 
is specific to this use case and therefore should not be necessarily discussed 
in tis document (given the problem is quite complex). However, I guess that 
could be good input to taps, given taps is working on a message-based interface 
on top of TCP.

> 
> Without this, people are tempted to set TCP_NODELAY, which is worse overall 
> for the network.

Not sure. In the described scenarios this might actually not be a bad think to 
do.

> 
>> 2) Further regarding keep-alives:
>> in sec 6.5.2: "For example, a hypothetical keepalive interval
>>  value of 100ms would result in a continuous stream of at least ten
>>  messages per second, in both directions, to keep the DSO Session
>>  alive."
>> 
>> This does not seems correct. There should be at max one keep-alives message 
>> in
>> flight. Thus the keep-laives timer should only be restarted after the
>> keep-alive reply was received.
> 
> On a campus GigE backbone with sub-millisecond round-trip times, even a 
> hypothetical keepalive interval value of 100ms would still have only one 
> keep-alive message in flight at a time. But it would still be an unreasonable 
> keepalive interval.

Not sure if that is a unreasonable keep-alive in a GigE backbone. I would 
actually hope that you don’t need a keep-alive mechanism at all in those 
scenarios but it depends if there are any middleboxes and how quickly their 
state expires. Given you have a campus network, you might know what the timeout 
are and set the keep-alive interval respectively. Maybe that’a better advise to 
give.

My problem with the example text above it that is seems to indicate that you 
just send a keep-alives very x time units while you need to wait for the 
response before restarting the timer. This needs to be clarified. However as I 
said, I’m not certain about the actual value fo this section as all, as it does 
not seems the right document to discuss these more general issue.

> 
>>  And, in this extreme example, a single packet loss and
>>  retransmission over a long path could introduce a momentary pause in
>>  the stream of messages, long enough to cause 

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

[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)

[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] Spencer Dawkins' Discuss on draft-ietf-dnsop-session-signal-12: (with DISCUSS and COMMENT)

[Mirja Kuehlewind (IETF)]

Hi Spencer, hi authors,

please see a few comments below. More might be coming as I’m currently 
reviewing the doc.

> Am 27.07.2018 um 06:33 schrieb Spencer Dawkins 
> :
> 
> Spencer Dawkins 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:
> --
> 
> I really like this document, and think it's headed the right direction. Of
> course I have four pages of comments, because reasons, but the only part I'm
> really confused about is this one ...
> 
> I would have thought that if you end up with a different endpoint because your
> anycast address now resolves differently, the new endpoint would have to have
> shared a lot of state with the previous endpoint, for this to work:
> 
>  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 timeout process will allow for recovery.
> 
> What I would have expected to happen, is that the new endpoint sees a packet
> arrive that's not on a synchronized TCP connection, and immediately responds
> with a RST (reset), rather than the normal keepalive and TCP connection 
> timeout
> process happening. That's also the way I'm reading
> https://tools.ietf.org/html/rfc7828#section-3.6. Is that not the way it's
> working for anycast these days?

I think is what is meant here, is that is a RST is received, the client can 
reconnect. If the server is not sending a RST, the connection will time out and 
will be re-established. Especially if only keep-alives are currently send (no 
application data), a failure can be detected relatively quickly. I do agree 
that both cases RST and no RST should be mentioned here and the text could be 
further clarified.

> 
> 
> --
> COMMENT:
> --
> 
> 
> Everything else is a comment, so non-blocking, and please do the right thing.
> 
> This is a nit, and your answer could be "no", and that's fine, but in some
> places this document uses "DSO keepalive", and in other places, "keepalive"
> with no qualifier. It's likely that less confusion would result if you could
> consistently call this "DSO keepalive", so that it is clearly NOT a TCP
> keepalive. Do the right thing, of course.
> 
> Is the expectation that DSO would also be used in DNS over HTTP? I'm reading
> 
>  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.
> 
> and noticing that https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-12
> is currently in IETF Last Call.
> 
> This next one is well within the "Spencer wouldn't have done it this way, but
> Spencer's not the working group, or the IETF" range, but
> 
>  However, in the typical case a server will not know in advance
>   whether a client supports DSO, so in general, unless it is known in
>   advance by other means that a client does support DSO, a server MUST
>   NOT initiate DSO request messages or DSO unacknowledged messages
>   until a DSO Session has been mutually established by at least one
>   successful DSO request/response exchange initiated by the client, as
>   described below.  Similarly, unless it is known in advance by other
>   means that a server does support DSO, a client MUST NOT initiate DSO
>   unacknowledged messages until after a DSO Session has been mutually
>   established.
> 
> seems fragile, especially in environments where clients can come and go, and
> servers may be addressed using anycast (so I knew in advance that the four
> servers at that anycast address supported DSO, but somebody installed a fifth
> server that does not). Is that unlikely to be a problem?
> 
> I'm sure
> 
>  A single server may support multiple services, including DNS Updates
>   [RFC2136], DNS Push Notifications [I-D.ietf-dnssd-push], and 

Re: [DNSOP] Mirja Kühlewind's No Objection on draft-ietf-dnsop-dnssec-roadblock-avoidance-04: (with COMMENT)

[Mirja Kuehlewind (IETF)]

Hi Wes,

thanks! See below.

> Am 09.07.2016 um 00:28 schrieb Wes Hardaker :
> 
> "Mirja Kuehlewind"  writes:
> 
>> 1) Shouldn't/can't section 3.1.13. (UDP size limits) also specify a
>>   real test?
> 
> I don't think it's possible to easily test this, sadly, without a target
> set containing different deterministic response sizes.  We could
> probably strike the section and simply state that resolvers MUST support
> TCP (which actually is stated elsewhere). 

In this case it probably make sense to not have an own section but mention 
somewhere else that the packet size can have an influence.

> 
>> 2) To follow up with the tsv-art review: To avoid network as well as
>> server overload, would it be useful to provide further guidance, when and
>> how often these tests should be performed?
> 
>  These tests should be performed when a resolver determines
>  its network infrastructure has changed.  Certainly a resolver
>  should perform these tests when first starting, but MAY also
>  perform these tests when they've detected network changes
>  (e.g. address changes, or network reattachment, etc).
> 
> FYI, I don't think even with a lot of boxes starting at the same time it
> would cause significant overload.  Specifically, those resolver boxes
> are serving many more clients that will be issuing significant more
> traffic once the resolver is operational than these tests actually
> require.

Thanks text sounds good. I’m not worried but it always better to give some 
guidance otherwise the weirdest implementations might show up.

> 
>> 3) In section 6.1.  (What To Do): maybe also list logging as an option in
>> cases where no user is directly involved but a human might check later.
> 
> Good point.  I've changed it to:
> 
>   If Host Validator detects that DNSSEC resolution is not
>   possible it SHOULD log the event and/or SHOULD warn user. In
>   the case there is no user no reporting can be performed thus
>   the device MAY have a policy of action, like continue or
>   fail. 

Great! Thanks!

Mirja


> h
> -- 
> Wes Hardaker
> Parsons
> 

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