> On Jan 24, 2021, at 8:53 PM, Tero Kivinen <kivi...@iki.fi> wrote: > > Christian Hopps writes: >> I have published a new version of the draft which I believe >> addresses the issues you raise in your WGLC readiness review below. >> As such, I'd like to request the document enter WGLC. > > Thanks, I will start WGLC soon. > >> The lack of the assumption is also more clear with the additional >> text about the window sizes when both IP-TFS and replay protection >> are in use. > > Yes, the new text seems much better. > >>> I think we could just say that when using this detection of replays is >>> mandatory and that replay window and the reassembly window are same. >> >> Continued to leave the option to use replay protection or not to the >> user. This change isn't required so I'd rather leave it as optional >> as the base ESP spec does. > > Actually the way you do reassembly already does replay protection, as > if you receive frame with same sequence number you have already > received you drop it. Or can you explain when there would not be > effective replay protection enabled when IPTFS is enabled. It does not > matter whether the replay protection happens in the IPsec replay > protection window or in the reassembly algorith, the offered > functionality is same.
Right. From an operational point of view I figured it comes down to whether one gets a specific type of log message/alert. > >>> In section 2.3 why does the text say: >>> >>> In other words, an SA that has >>> AGGFRAG_PAYLOAD enabled MUST NOT have non-AGGFRAG_PAYLOAD payloads >>> such as IP (IP protocol 4), TCP transport (IP protocol 6), or ESP pad >>> packets (protocol 59) intermixed with non-empty AGGFRAG_PAYLOAD >>> payloads. >>> >>> why is that restriction with only non-empty AGGFRAG_PAYLOAD payloads? >>> When can empty AGGFRAG_PAYLOAD used intermixed with other payloads? >> >> Added sentence explaining this and referring back to "Empty Payload" >> section which also explains this. > > This I do not understand. I assumed the congestion control only > covered the IPTFS SA, and it was done per SA bases. How does this > congestion control work when it is controlling non IPTFS SAs? Why do > you need it if you are not doing traffic flow confidentiality, but are > only sending frames based on the normal traffic patterns, and the > normal congestion control functions should work normally without > issues? Correct the CC is only covering an IPTFS SA; however, the receiver has to send back information to the sender for CC to function, that is what the empty payload is for, to send the CC information back over the non-IPTFS SA. This is only going to be used when the user has configured IPTFS in only one direction -- we're covering all the bases here. > >>> Also it does not mention whether frame is allowed to to be fragmented >>> across the old and new SA. It should say that as sequence numbers are >>> different for the SAs, the packet can never be fragmented so that part >>> of it is in old SA, and part of it is in the newly created SA. >> >> Added sentence saying inner packets should not be fragmented across >> different SAs. > > I think it should say that implementations MUST NOT send initial > fragments of an inner packet using one SA and subsequent fragments in > a different SA, as allowing this would make reassembly much harder, as > it needs to check that the older frames are the last ones to be sent > on that old SA, and there must not be any others after them etc... OK. > > I think it would be better to just assume that those SAs do have > separate windows, thus fragments can never cross over from one SA to > other. > >>> In section 2.2.4 draft says: ESP payload length is equal to the >>> AGGFRAG_PAYLOAD header length. This would indicate that this packet is >>> not the same length than other frames. I think it would be better to >>> say that this has just the AGGFRAG_PAYLOAD header, and then rest of >>> the frame is padding. >> >> These are only used to transmit congestion control information back >> to the sender on non-IP-TFS SAs, there's no reason to pad them out. > > So these packets are not same size than others, thus outsiders can > see that these are congestion control information frames, and not real > traffic. Can they also get some other information of the inner flows > by analysing those empty frames? See above, but these empty payloads are not being protected by IPTFS they are just for transmitting required info back to the sender. > >> Once again I believe we are ready for WGLC. > > I will start 3 week WGLC on the document, ending 2021-02-15. Thanks! Chris. > -- > kivi...@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
