|
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 <kaduk@xxxxxxx> 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
Tsv-art@xxxxxxxx
https://www.ietf.org/mailman/listinfo/tsv-art
|
