Subject: [Dots] Tsvart last call review of draft-ietf-dots-requirements-16

From: Joseph Touch <[email-masked]>
Date: Sat, 17 Nov 2018 17:39:22 -0800

Reviewer: Joseph Touch
Review result: Ready with Issues

Transport issues:
- The GEN requirements refer to signal and data channels; it should be more
clear that these would be transport associations or connections, not
necessarily separate port assignments - GEN-03 recommends transports that avoid
HOL blocking, but that blocking can occur at any protocol layer (e.g., when
using TCP as a tunneling layer or at the application layer) - SIG-001 – PLPMTUD
should be used instead of PMTUD; PMTUD (relying on ICMP, which is often blocked
and remains insecure) should be avoided. The PMTU of 1280 is relevant only for
IPv6. The use of 576 should be more clearly indicated as applying only to IPv4.
(note there is emerging PLPMTUD for UDP). - SIG-004 should address the use of
TCP keepalives for TCP connections as a way to achieve heartbeats. - SIG-004 is
self-contradictory, at first claiming that agents SHOULD avoid termination due
to heartbeat loss then later saying they MAY use heartbeat absence as
indication of defunct connections. Even though SHOULD and MAY can be used
together this way, the advise is confusing. This is a case (see below) where
the reasoning behind exceptions to SHOULDs are needed -- but the MAY clause is
a far too trivial (and, based on our experience with BGP, incorrect) condition
- DATA-002 should suggest protocols for security, at least indicating whether
these need to be at a particular protocol layer (IP, transport, application),
etc.

Other issues:
- the document uses SHOULD without qualifying the conditions for exception

Nits
- the abstract is too brief
- Several requirements suggest that use of TCP avoids the need for separate
congestion control; the same should be mentioned of SCTP and DCCP.

---

From: Joe Touch <[email-masked]>
Date: Sat, 17 Nov 2018 17:42:27 -0800

Hi, all,
The following boilerplate was supposed to have been inserted automatically…
Joe

——
This document has been reviewed as part of the transport area review team's ongoing
effort to review key IETF documents. These comments were written primarily for
the transport area directors, but are copied to the document's authors and WG to 
allow them to address any issues raised and also to the IETF discussion list for 
information. 

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please
always CC [email-masked] <mailto:tsv-art@ietf..org> if you reply to or forward this review.
---

> On Nov 17, 2018, at 5:39 PM, Joseph Touch <[email-masked]> wrote:
> 
> Reviewer: Joseph Touch

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 25 Nov 2018 15:17:34 -0600

Hi Joe,

> Review result: Ready with Issues

[reformatted for readability]

> necessarily separate port assignments
>
> - GEN-03 recommends transports that avoid
> using TCP as a tunneling layer or at the application layer)

Is the concern about "conveyed over a transport not susceptible"?  I don't
think that one needs to read "transport" as "lowest level transport
protocol" here and it would equally apply to any tunneling layer.

> - SIG-001 – PLPMTUD
> (note there is emerging PLPMTUD for UDP).

The IPv4 text is phrased as it currently is since there may be tunneling
scenarios that go over IPv4 at some intermediate link even if the endpoints
are speaking IPv6.

With respect to PMTU vs. PLPMTU, can you give any guidance on whether the
literl 1280 and 576 values are equally valid for assumed PLPMTU as for
"true" PMTU?

> - SIG-004 should address the use of
> TCP keepalives for TCP connections as a way to achieve heartbeats.

I don't believe that there is an IETF consensus position about what layer
is best for performing heartbeats; see the "statement regarding keepalives"
thread.  In particular, since this signal channel is going to support
non-TCP transports and prefers UDP over TCP, it will need its own heartbeat
mechanism anyway, at which point the TCP-layer functionality is going to be
fairly redundant.

> - SIG-004 is

Can you double-check this?  My read is that there are two factors involved
and we are only giving guidance on two quadrants of the truth table, with
the two factors being "failing to receive heartbeats" and "attack traffic
is present".  (The attack traffic is assumed to be swamping other traffic,
but when there is no attack traffic the heartbeats should be more
reliable.)

> these need to be at a particular protocol layer (IP, transport, application),

I think it's fine for a requirements document to limit itself to the actual
cryptographic requirements.  FWIW, the current data-channel spec is using
TLS.

-Ben

---

From: Joe Touch <[email-masked]>
Date: Sun, 25 Nov 2018 21:08:39 -0800

Hi, Benjamin,

> On Nov 25, 2018, at 1:17 PM, Benjamin Kaduk <[email-masked]> wrote:
> 
> Hi Joe,
> 

The point is that avoiding HOL blocking at one layer may have no impact on HOL blocking at another layer. If HOL blocking is a significant problem, it needs to be noted that this can happen at many places in the stack, not just at the transport layer.

> scenarios that go over IPv4 at some intermediate link even if the endpoints

That should be made more explicit.

> literl 1280 and 576 values are equally valid for assumed PLPMTU as for

These are independent issues. The MTU minimums are set by the protocols; the MTU used on a given path is discovered by PMTUD or PLPMTUD; the former is not as reliable as the latter, due to ICMP blocking.

> thread.  

There’s a lot of misundestanding on this issue. Keepalives can be needed at multiple layers; a keep alive at one layer is never a direct substitute for a keep alive at another layer. If keepalives are enabled at multiple layers, they should never need to interfere, though - they basically disable keepalives at lower layer ONLY when they are frequent enough relative to that lower layer.

> In particular, since this signal channel is going to support

It depends on whether you also need TCP to keep active state. If so, turning TCP keepalives on would not necessarily interfere with app-layer keepalives; it would serve its own purpose.

Again, the error is thinking that keealives at one layer either avoid the need for keepalives at another layer OR interfere per se; correctly implemented, they do not interfere even when enabled at multiple layers.

> but when there is no attack traffic the heartbeats should be more

You need to explain these as a SINGLE recommendation. Putting contradictory advice in different places makes it confusing to determine how it is applied.

> cryptographic requirements.

If you have something in mind that exists, say it. If not, then assume it will be incorrectly interpreted as suggesting something you didn’t have in mind.

IMO, better to avoid the ambiguity, i.e., to actually include the following to explain that TLS is sufficient:

>  FWIW, the current data-channel spec is using
> TLS.
> 
> -Ben
> 
>> Other issues:
> _______________________________________________
> Tsv-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tsv-art

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 26 Nov 2018 16:14:46 -0600

Hi Joe,

Many of these points are at a point where the authors will need to weigh
in, but I can help a little bit more...

> The point is that avoiding HOL blocking at one layer may have no impact on HOL blocking at another layer. If HOL blocking is a significant problem, it needs to be noted that this can happen at many…

HoL blocking is a very big problem for the signal channel specifically, so
this is good feedback.

> These are independent issues. The MTU minimums are set by the protocols; the MTU used on a given path is discovered by PMTUD or PLPMTUD; the former is not as reliable as the latter, due to ICMP blo…

Maybe I am confused, but I have in mind a scenario where we PLPMTU
discovery fails so we assume 1280, but there's a tunneling protocol and
we traverse a minimum-MTU IPv6 segment, so our packet would be too big if
we assume PMTU of 1280 and don't know about the tunnel.  Can we do any
better than the existing assumptions from the IP minimum values?

> Again, the error is thinking that keealives at one layer either avoid the need for keepalives at another layer OR interfere per se; correctly implemented, they do not interfere even when enabled at…

I don't think that's the argument I was trying to make; I'm saying that
this is a generic requirements document and we are covering the application
layer's heartbeat needs.  If we don't require stable transport state (note
the lack of such a requirement in the SIG-XXX block), then why would we
need to talk about TCP hearbeats at all?

> You need to explain these as a SINGLE recommendation. Putting contradictory advice in different places makes it confusing to determine how it is applied.

I'm still not seeing how these are contradictory.  We have "if A and not B,
do X" and "if not A and not B, do Y".  The predicates are different, so
where is the contradiction?

-Ben

---

From: Joe Touch <[email-masked]>
Date: Mon, 26 Nov 2018 15:02:14 -0800

Thanks for the input -- some suggestions below...

On 2018-11-26 14:14, Benjamin Kaduk wrote:

> On Sun, Nov 25, 2018 at 09:08:39PM -0800, Joe Touch wrote: Hi, Benjamin,
> 
> On Sat, Nov 17, 2018 at 05:39:22PM -0800, Joseph Touch wrote: Reviewer: Joseph Touch

The point is that avoiding HOL blocking at one layer may have no impact
on HOL blocking at another layer. If HOL blocking is a significant
problem, it needs to be noted that this can happen at many places in the
stack, not just at the transport layer. 
HoL blocking is a very big problem for the signal channel specifically,
so
this is good feedback.

> - SIG-001 - PLPMTUD

> literl 1280 and 576 values are equally valid for assumed PLPMTU as for

These are independent issues. The MTU minimums are set by the protocols;
the MTU used on a given path is discovered by PMTUD or PLPMTUD; the
former is not as reliable as the latter, due to ICMP blocking. 
Maybe I am confused, but I have in mind a scenario where we PLPMTU
discovery fails so we assume 1280, but there's a tunneling protocol and
we traverse a minimum-MTU IPv6 segment, so our packet would be too big
if
we assume PMTU of 1280 and don't know about the tunnel.  Can we do any
better than the existing assumptions from the IP minimum values? 

A tunnel that transits IP MUST be able to send 1280 bytes across it.
That may require fragmentation at the ingress and reassembly at the
egress -- which is why IPv6 link MTU is 1280 but the receiver reassembly
MTU is 1500. You cannot simply say that the tunnel eats the MTU and the
MTU is below 1280 - that's not allowed for IPv6. In this case, the
PLPMTUD between ingress and egress could report 1280 while the
end-to-end path that goes over the tunnel also reports 1280. 

This is explained in more detail in draft-ietf-intarea-tunnels 

> is best for performing heartbeats; see the "statement regarding keepalives"

There's a lot of misundestanding on this issue. Keepalives can be needed
at multiple layers; a keep alive at one layer is never a direct
substitute for a keep alive at another layer. If keepalives are enabled
at multiple layers, they should never need to interfere, though - they
basically disable keepalives at lower layer ONLY when they are frequent
enough relative to that lower layer.

> mechanism anyway, at which point the TCP-layer functionality is going to be

It depends on whether you also need TCP to keep active state. If so,
turning TCP keepalives on would not necessarily interfere with app-layer
keepalives; it would serve its own purpose.

Again, the error is thinking that keealives at one layer either avoid
the need for keepalives at another layer OR interfere per se; correctly
implemented, they do not interfere even when enabled at multiple layers.

I don't think that's the argument I was trying to make; I'm saying that
this is a generic requirements document and we are covering the
application
layer's heartbeat needs.  If we don't require stable transport state
(note
the lack of such a requirement in the SIG-XXX block), then why would we
need to talk about TCP hearbeats at all? 

An app layer can decide to use TCP as its heartbeat under some
circumstances, e.g., when it monitors the TCP state and uses it to
determine the application state. If that's never going to be sufficient,
they you should say so and explain why. 

> but when there is no attack traffic the heartbeats should be more

You need to explain these as a SINGLE recommendation. Putting
contradictory advice in different places makes it confusing to determine
how it is applied. 
I'm still not seeing how these are contradictory.  We have "if A and not
B,
do X" and "if not A and not B, do Y".  The predicates are different, so
where is the contradiction? 

SHOULD avoid termination due to the lack of heartbeats 
  - Implies that I can I terminate due to lack of heartbeats only in
some (exceptional) circumstances, 
    but doesn't say what those are 

MAY use heartbeat loss as indication of defunct connection 
  - Gives blanket permission to ignore the SHOULD above, without
consideration for circumstance 

Those are contradictory as phrased. They could be revised: 

SHOULD avoid termination... except possibly under circumstance X 
MAY terminate during circumstance X, but (we'd prefer not) OR (anytime
it wants) 

Joe 

> cryptographic requirements.

If you have something in mind that exists, say it. If not, then assume
it will be incorrectly interpreted as suggesting something you didn't
have in mind.

IMO, better to avoid the ambiguity, i.e., to actually include the