Hi Valery, I think we're getting a bit too caught in the details, to circle back:
> I think that in its current form the draft is too focused on a single > application for > the Aggregation and Fragmentation mode - IP-TFS. From architectural > point of view I'd like to see the draft first defining the mechanism itself > and then describing possible applications for it, focusing on IP-TFS > as the primary application. > We discussed this with Christian off the list in length and came to > a good compromise regarding naming of new entities defined in the draft. > After re-reading the draft I still think that its structure of the document > should be > changed to better decouple mechanism from its applications. The discussion in the WG over the last 2 years has focused on providing a better TFS solution, indeed this is what the work is chartered to do. Your excellent observation that this work could be used in other ways was spot on, and is reflected in the current text. Restructuring the draft to focus on a generic encapsulation solution goes beyond the WG discussion and our chartered task. If the working group consensus is to shift gears then that is what we can do; however, the document is in WGLC and it's rather late in the process. I think it's best to move forward with the current document as discussed in the WG, and let the WG discuss other use cases in future documents. Thanks, Chris. > On Feb 11, 2021, at 3:23 AM, Valery Smyslov <smyslov.i...@gmail.com> wrote: > > Hi Christian, > > I agree with what Lou with regards to it going too far to recast/redirect > this work any further. I did do a round > of changes based on our agreement to help with future uses, and while it's > nice that this work could lead to > these uses, those should be documented in another document at this point. The > focus of this work has and > should continue to be traffic flow security. > > Here we disagree. My point is that you define a very good mechanism > that can be used not only for IP-TFS, but for other purposes too. > I fully understand that IP-TFS was your primary focus and I agree > the document to remain focused on it. However, if the document > is kept in its current form any attempt to use it for other applications > will look as an improper use of mechanism, because the way document > is organized highly ties the mechanism and its application. > > A compromise and to address your concern that other uses might look improper > I've changed the abstract to include this final sentence: > > "The mechanisms defined in this document are generic with the intent of > allowing for non-TFS uses, but such uses are outside the scope of this > document." > > The introduction to include this final paragraph: > > "The mechanisms defined in this document are generic with the intent of > allowing for non-TFS uses, but such uses are outside the scope of this > document." > > And the "Packets and Data Formats" top level section to start: > > "The packet and data formats defined below are generic with the intent of > allowing for non-IP-TFS uses, but such uses are outside the scope of this > document." > > I believe this addresses your concern about other uses looking improper. > > That changes are the very minimal ones and in my opinion they’re > not enough. > The document still looks like a mess, because it constantly used > term “IP-TFS” > when describing a generic behavior of Aggregation and Fragmentation > mode. > Few examples: > > 2. The IP-TFS Tunnel > > As mentioned in Section 1 IP-TFS utilizes an IPsec [RFC4303] tunnel > (SA) as it's transport. To provide for full TFC, fixed-sized > encapsulating packets are sent at a constant rate on the tunnel. > > The egress 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. > > IP-TFS aggregates as well as fragments the inner IP traffic flow into > fixed-sized encapsulating IPsec tunnel packets. > > In particular IP-TFS never maps the inner DF bit as it is > unrelated to the IP-TFS tunnel functionality; IP-TFS never IP > fragments the inner packets and the inner packets will not affect the > fragmentation of the outer encapsulation packets. Likewise, the ECN > value need not be mapped as any congestion related to the constant- > send-rate IP-TFS tunnel is unrelated (by design!) to the inner > traffic flow > > An example IP-TFS packet flow can be found in Appendix A. > > > And so on. I think the text must be cleaned up to be more accurate > with this regard. > >>> I've incorporated your other suggestions from below. >> >> Please see my comments (I removed parts where we are in concert). >> >> >>> 9. Section 2.2.3: >>> >>> When using the AGGFRAG_PAYLOAD in conjunction with replay detection, >>> the window size for both MAY be reduced to share the smaller of the >>> two window sizes. This is b/c packets outside of the smaller window >>> but inside the larger would still be dropped by the mechanism with >>> the smaller window size. >>> >>> I wonder why MAY is used here. It should be MUST instead. >>> As you explained there is no point for the sizes to be different. >> >> They remain different mechanisms and the user may wish to have them treated >> differently (e.g., logging >> replayed packets). >> >> My question was regarding "MAY" vs "MUST". Even if these are different >> mechanisms, what is the reason for having different window sizes if both >> mechanisms >> are employed? I may yet understand that reassembly window may be shorter >> then replay window (you will just have a penalty of dropping too old packets >> even when replay protection allows them in), but what may be the reason >> for having reassembly window longer than replay window? If you have some gaps >> at the far left end of reassembly window waiting for missing packets, >> you'll never receive them if replay window is shorter - they will fall >> outside it. So, it's just a waste of resources. > > The implementation may wish to allow the user to have replayed packets logged > (one can have a very large replay window w/o consuming many resources). > > Well, I probably was unclear, but you missed my point. I’ll try > again. > The current text says that if both replay protection and AGGFRAG > are employed, then replay protection window and reassembling window > MAY > be of the same size, which is the smaller of both. > > Since MAY means that you think it’s OK for these windows to be of > different > sizes in this case, I wondered in which situations you think it’s > OK. > You gave me an example, for situation when replay window is longer > than > reassembly window, which I can reluctantly buy (I still think that > it’s a waste > of resources: some delayed packets will pass the replay protection, > decrypted and then dropped because they would fall outside > reassembly window). > > But can you please give me an example when it’s useful to have > reassembly > window longer than replay protection window? > > Consider an example when reassembly window size is 100 and replay > protection window size is 10. > For simplicity let’s assume that reassembly window at the moment is > filled with packets with odd SNs > starting from 1 to 99. So, you are waiting for the rest packets > with even SNs from 0 to 98 to be able > to complete reassembly process. But since replay protection window > size is only 10 and the > most recently received ESP packet has SN 99, you never receive > packets with SNs from 0 to 89, > (because the will be dropped by replay protection logic) and the > first 90 packets will never be reassembled. > It’s just a waste of resources. > > So, I think that MAY above should be at least SHOULD. Or leave it > as MAY and say that > reassembly window SHOULD NOT (MUST NOT?) be longer that replay > protection (for the reason > outlined above). > > >>>> 10. Section 2.2.3: >>>> >>>> Finally, as sequence numbers are reset when switching SAs (e.g., when >>>> re-keying a child SA), an implementation SHOULD NOT send initial >>>> fragments of an inner packet using one SA and subsequent fragments in >>>> a different SA. >>>> >>>> Two issues here - first why SHOULD NOT and not MUST NOT? >>>> In general you cannot reliably reassemble packet if it is fragmented over >>>> several SAs, so it will be dropped. Why do you allow this? >>> >>> Changed to MUST NOT. >>> >>> >>> Then, IPsec architecture allows several parallel ESP SAs >>> to co-exist with the intention that kernel may use any of these SAs to send >>> packets >>> (e.g. for improving performance, see draft-pwouters-multi-sa-performance). >>> I think you should mention that in this case a care must be taken not to >>> fragment outgoing packets over several parallel SAs. I.e. if a packet get >>> fragmented, >>> all its fragments must be sent over single ESP SA. >>> >>> Covered by the switch to MUST NOT. >> >> Well, this text is explicitly about "sequence numbers are reset when >> switching SAs". >> I think it's better to generalize it and say that "packet fragmentation MUST >> not take >> place over different SAs". This will cover both cases - rekeying and >> parallel SAs. > > It's explaining the restriction. This adds information/justification w/o > changing the actual requirement. I think that's a good thing not bad. > > If you have several parallel SAs their SNs are not reset, they are > just different... > OK, I can live with this, although I still think the text is a bit > confusing. > > >>>> 20. Section 6.1.4: >>>> >>>> 0: >>>> 6 bits - reserved, MUST be zero on send, unless defined by later >>>> specifications. >>>> >>>> Add a sentence that these bits MUST be ignored on receipt. >>> >>> They must not be ignored. If they are set and they and not understood then >>> AGGFRAG mode will not be >>> enabled as indicated in section 5.1 >> >> Section 5.1 is about USE_AGGFRAG notification, here we talk about >> Reserved bits AGGFRAG_PAYLOAD. How they are related? >> >> As implementer I have a question - what should I do if these bits >> are non-zero on receipt? The draft is silent about this. > > I think maybe you mixed something up in your reading? Section 6.1.4 is: > > " <>6.1.4 > <https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-06#section-6.1.4>. > IKEv2 USE_AGGFRAG Notification Message" > > It is not about the AGGFRAG_PAYLOAD. > > > You are right, I somehow mixed up these sections. That’s probably > because > the description of USE_AGGFRAG is split over 5.1 and 6.1.4, that > was a cause of my confusion. I’d rather merge them not to confuse > other readers :-) > > >>> 22. Security Considerations. >>> >>> Add a text that correct functionality of the AGGFRAG mode >>> requires restoring packets order on the receiver. Since this >>> is done by utilizing ESP Sequence Number field, the ESP >>> header must be authenticated, and thus the ESP SA MUST >>> be created with authentication other than NONE >>> or with AEAD cipher. >> >> I think this falls under the non-IPTFS use case. I'd like to leave it out as >> it would be confusing. > > No, it's about any use case of this mechanism. > ESP can be used without authentication > (although it's strictly discouraged) and in this > if AGGFRAG is employed (regardless of IP-TFS), > then an attacker can re-order packets on his/her will, > by playing with SN field, so your reassembly mechanism won't work. > > You think I need to state that things are not secure if the user turns off > authentication? > > I think yes. You may have ESP SA w/o authentication, it’s not > prohibited by RFC 4303. > In this case replay protection won’t work (it may be OK for some > application). > What I want is to stress that AGGFRAG won’t work either in this > situation. > > Regards, > Valery. > > > I would think that's covered already by: > > " > Other than > the additional security afforded by using this mechanism, IP-TFS > utilizes the security protocols [RFC4303 > <https://tools.ietf.org/html/rfc4303>] and [RFC7296 > <https://tools.ietf.org/html/rfc7296>] and so their > security considerations apply to IP-TFS as well. > " > > Thanks, > Chris. > > > > Regards, > Valery.
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
