Hi Michael, Thanks for the review, q's, comments, and changes inline..
> On Feb 14, 2021, at 11:45 PM, Michael Richardson <mcr+i...@sandelman.ca> > wrote: > > Signed PGP part > > I have read draft-ietf-ipsecme-iptfs before it was adopted, and during the > adoption call, but have been busy. So I have read it again today from > beginning to end before tackling the long thread that has developed. > > EXEC SUM: I think that the document is not ready. > There are a lot of MAYs and future work thoughts on the sender. > That's fine. But, in order for future senders to know what's legal and > what's not, what we really need is a clearly articulated Receiver State > Machine. > I suggest that this is pretty important. What did you have in mind? There are purposefully no restrictions for the receiver to enforce. From section 2: The egress (receiving) side of the IP-TFS tunnel MUST allow for and expect the ingress (sending) side of the IP-TFS tunnel to vary the size and rate of sent encapsulating packets, unless constrained by other policy. > === > > The first sentence of the Abstract needs rework. > The words "security" and "confidentiality" are used, but really it's about > traffic analysis. So, if there is anything with increased confidentiality, > it's the pattern, right? Abstracts are really hard to write. > Ah, the problem is that "traffic flow security" is not the term, > it's traffic flow confidentiality, and it is not capitalized! > So, that would help, but... it's not defined yet. > > I suggest the following terms be added to section 1.1. > - TFC Capitalized and "acronymized" TFC and called it out specifically now: This document assumes familiarity with IP security concepts including Traffic Flow Confidentiality as described in [RFC4301]. > * I'm glad you recommend PLMTUD, I suggest PMTUD is dead. > How do use PLMTUD? Will you tell us later in the document, or is that new > work? > (does not look like you tell us) I believed it was enough to just reference the mechanism (as we do for PMTUD as well). This was added during the transport area review. > > * You are using "CamelCase" for variables, I found that jarring. > I wondered what rfc4303 used, but found nothing. > RFC7296 uses UPPER_CASE. > RFC7296 does not use _ for field names. > I might prefer snake_case, but whatever... You must not like Python very much. :) I used UPPER_CASE for constants as that's what seemed to be the prior art in ipsec. For field names camel case seemed to work pretty good differentiates them from constants and non-actual-field references. I could add spaces instead of using CamelCase if you think this is important, though. > > * I would prefer "If BlockOffset != 0" rather than > Conversely, if the "BlockOffset" value is non-zero it points to the Usually I don't use "=" or "!=" in text. I'd prefer to leave this as is, otherwise when reconciling that change with the rest of the text e.g.: The "BlockOffset" value is either zero or some offset into or past the end of the "DataBlocks" data. Becomes The "BlockOffset" == 0 or some offset into or past the end of the "DataBlocks" data. Doesn't seem correct to mix and match like that. >> The "BlockOffset" can point past the end of the "DataBlocks" data >> which indicates that the next data block occurs in a subsequent >> encapsulating packet. > > I guess, it the actual value does not matter: it's not remembered. > As long it is bigger than the packet, it's good. So 0xffff probably works? Your right it just has to point past; however, it helps to have it point to the exact ending when implementing (the code is easy to implmeent and it caught multiple bugs for me as well). >> 2.2.2. No Implicit End Padding Required > > -- I think you are telling me that the IPv4/IPv6 length field is good enough > to find the end of the packet. If not, I didn't quite understand. You understood. > Later in 6.1, I learn that AGGFRAG_PAYLOADS are squatting on 'IPv5' > I hope this will be acceptable :-) > I think it's a reasonable hack, and I don't see us wrapping around > IP versions within a hundred years, soooo... > And pad blocks are "IPv0" > >> This possible interleaving of all-pad >> payloads allows the sender to always be able to send a tunnel packet, >> regardless of the encapsulation computational requirements. > > I think that you are telling me that a sender can have some pad packets being > created regularly (perhaps on a CPU dedicated to this) and almost ready to > send, and the pad packet is just replaced by real data if it happens to be > ready. You understood perfectly. > > Please split 2.2.5 up by flag type into subsubsubsection. Done. > 2.4.21: Maybe need to briefly explain circuit breakers to us > non-transport-types. I think the reference should serve here. I try to avoid paraphrasing other documents as one often just gets it wrong (i.e., prefer a single source of truth). :) > >> If the SA back to the sender is a non- >> AGGFRAG_PAYLOAD enabled SA then an AGGFRAG_PAYLOAD empty payload >> (i.e., header only) is used to convey the information. > > is this really worth supporting? It doesn't take much to continue to allow for unidirectional use at the lowest layer (ESP/SA). It isn't relevant once you get to IKE where bidirectionality is required. > Please break up third paragraph. Done. Thanks again for the review! Chris. > > ===== > > > > > > > > -- > Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
