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