Re: [Tsv-art] Tsvart last call review of draft-ietf-dots-requirements-16

[Joe Touch <[e-mail]>]

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

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

> 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...
> 
> On Sun, Nov 25, 2018 at 09:08:39PM -0800, Joe Touch wrote: Hi, Benjamin,
> 
> On Nov 25, 2018, at 1:17 PM, Benjamin Kaduk <[e-mail]> wrote:
> 
> Hi Joe,
> 
> On Sat, Nov 17, 2018 at 05:39:22PM -0800, Joseph Touch wrote: Reviewer: Joseph Touch
> Review result: Ready with Issues 
> [reformatted for readability]
> 
> 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) 
> 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.

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

That should be made more explicit.

> 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?

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 

> - 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.

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
> 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.

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. 

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

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 

> -Ben
> 
> - DATA-002 should suggest protocols for security, at least indicating whether
> these need to be at a particular protocol layer (IP, transport, application),
> etc. 
> I think it's fine for a requirements document to limit itself to the actual
> 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:
>> - 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.
> 
> _______________________________________________
> Tsv-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tsv-art