[IPsec] I-D Action: draft-ietf-ipsecme-iptfs-14.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : IP-TFS: Aggregation and Fragmentation Mode for ESP and its Use for IP Traffic Flow Security Author : Christian Hopps Filename: draft-ietf-ipsecme-iptfs-14.txt Pages : 32 Date: 2022-08-18 Abstract: This document describes a mechanism for aggregation and fragmentation of IP packets when they are being encapsulated in ESP payloads. This new payload type can be used for various purposes such as decreasing encapsulation overhead for small IP packets; however, the focus in this document is to enhance IPsec traffic flow security (IP-TFS) by adding Traffic Flow Confidentiality (TFC) to encrypted IP encapsulated traffic. TFC is provided by obscuring the size and frequency of IP traffic using a fixed-sized, constant-send-rate IPsec tunnel. The solution allows for congestion control as well as non- constant send-rate usage. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-iptfs-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-iptfs-14 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Martin Duke's No Objection on draft-ietf-ipsecme-iptfs-14: (with COMMENT)
Martin Duke has entered the following ballot position for draft-ietf-ipsecme-iptfs-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/ -- COMMENT: -- Thanks for addressing my DISCUSS. Thanks to Joe Touch for 2 TSVART reviews, and for addressing his comments. Also thanks for the very literate discussion of congestion control. (2.2.3) It would be nice to at least suggest a default number for the reordering window. In TCP, we traditionally use 3, but really any suggestion for the clueless is fine. (3) Please clarify: is TsVal the actual tranmission time, or the time the packet is queued for the next transmission opportunity? (3) This probably just needs a bit more explanation, but reading this document, and not knowing much about ESP, I could not figure out the case where the return path does not support AGGFRAG_PAYLOAD. IIUC, IKEv2 negotiates this for the pair explicitly, so this case cannot arise. Otherwise, how is this negotiated? Why would a tunnel endpoint support just AGGFRAG without payloads but not with? NITS (2.4.1) update the [RFC8229] reference to RFC8229bis? (6.1) "The value 5 was chosen to not conflict with other used values." IIUC the values here are just Protocol numbers from the registry. So maybe it's better to be more explicit and say that this cannot be used with RFC1819 streams? ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Paul Wouters' Yes on draft-ietf-ipsecme-rfc8229bis-07: (with COMMENT)
[Cut parts we agreed on, and where you provided text that is okay with me] Note the last outstanding minor issue for me is the "one ESP message" (see below). Paul On Wed, Aug 10, 2022 at 8:49 AM Valery Smyslov wrote: BTW, the value 3 for the Length field is valid, even if it is under 4 :-) > - > in case of NAT keepalive packet (discouraged, but not prohibited over TCP). > :-) I guess technically, it should have been separated into its own section, eg IKE Message, ESP packet and NAT Keepalive. But I'm okay as it is now. > ### > > > > Section 5: > > > > when it has been configured to be used with specific IKE peers. > > > > I would say "when it has been configured to be optionally used with > specific > > IKE peers. > > Otherwise, implementers might think it needs to be an on/off setting > instead > > of a > > "may be used when udp is blocked" setting. > > Well, I think these implementation details need not to be covered in the > spec. > While UDP is preferred, there may be situations, where it is known for sure > that UDP is permanently blocked, so there is no need to try it each time > introducing additional delay. > For example, our implementations may be configured with three choices (per > peer) - > never use TCP, may use TCP if UDP is blocked, always use TCP. > > I'd leave the text as is. > My problem is a bit with the term "use". Does it mean "when actively using this" or "when allowed as per local config to use this when UDP fails". So "to be used with specific IKE peers" might be read as "always only use TCP with these peers", or "always allow TCP fallback" > > > Similarly: > > > > If a Responder is configured to use TCP encapsulation, > > > > I would say "is configured to accept TCP encapsulation" > > Hm, I think "use" is more generic, after accepting TCP > the responder will also send something over it :-) > > I suggest: > > s/is configured to use/is configured to accept and use > > is it OK? > How about "accept and allowed to use" ? > > Also instead of "previous IKE session" maybe say "previous encapsulation > > session"? > > Then what is "encapsulation session"? This term is not defined in the spec. > I think we may leave the text as is for simplicity, although I see your > point. > I would still like to see something that is not "previous IKE session" as that might confuse implementer in thinking they need to start a new IKE session instead of just starting a new TCP connection. > ### > > > > Implementations > > SHOULD NOT tear down a connection if only a single ESP message > has an > > unknown SPI, since the SPI databases may be momentarily out of > sync. > > > > This advise might be difficult to follow. If this out of sync really > happens, > > it would be likely that a number of ESP packets would be seen before the > IKE > > packet comes in that syncs up the SPI. (assuming this out of sync issue > > happens > > when the TCP responder is also the IKE responder to a rekey and once it > > rekeyed > > and installed a new IPsec SA it starts sending ESP packets before it > sends its > > IKE rekey reply, or a number of smaller ESP packets arrive sooner > somehow?) > > There may be delays while installing the ESP SAs depending on the > implementation. > E.g. if you have an asynchronous API between IKE and kernel. > My problem is still not resolved through. You say "a single ESP message". Whatever is causing the "single" message, could also cause 2 or 3 or 10 messages? So I find the guidance unsafe. Maybe talk in vague time windows, eg "a brief time" or "a few seconds" ? > ### > > > > Section 6.3 talks a lot about how COOKIE stuff is both useless for TCP > > and can fail in mysterious new ways. Why not simplify things and say > > "cookies must (should?) not be verified and fully ignored when over TCP, > > and only puzzles should be verified" > > I think it's too radical change. Cookies can still be verified with TCP > if no source IP and port are included into their calculation. > Reluctantly will let you get away with it :) > ### > > > > How about sharing an alternative to the transport mode checksum fixups: > > > > Implementations MAY use the information that a NAT is present to > omit > > sending USE_TRANSPORT over TCP, and thus enforce tunnel mode > IPsec > > SA's > > to avoid the need for checksum fixups for encapsulated packets > inside > > TCP. > > This is not specific to TCP encapsulation. And I think that the selection > of mode > may be driven by various considerations, so avoiding checksum fixups > is usually not the primary one. > Sure. Let's leave this one up to the implementers. Whatever they do, it is clearly signaled. > ### > > > > for which purpose the standard IKEv2 mechanism of > > exchanging empty INFORMATIONAL messages is used > > > > I believe these INFORMATIONALs are not neccessarilly empty, even though > > they started > > out that way. I would just leave out the word
[IPsec] Intdir telechat review of draft-ietf-ipsecme-iptfs-13
Reviewer: Tatuya Jinmei Review result: Ready I've reviewed version 13 of draft-ietf-ipsecme-iptfs. I'm by no means an IPsec expert or very much familiar with ESP details, so it's quite possible I may miss something in its technical details. That said, I think it's very well written to understand the concept, and I've not found any obvious problems. So I'd say it's "ready". It looks like one underlying high level question is whether we should rather standardize a (single, unified) mechanism that does not necessarily depend on ESP. For that question, I think this response from the author is convincing: > We designed the encapsulation with IPsec/IP-TFS (IP traffic flow > security) in mind. This work defines sending fixed-sized packets at > a constant rate specifically decoupled from the user load to achieve > a high degree of traffic flow security. We might design a generic tunneling mechanism that parameterizes the sending rate or whether to use of padding or encryption, but unless we have a clear demand for such a mechanism today (which I actually don't know well but doesn't look likely) that seems to me to be over generalization. I have a couple of very minor comments on the draft content: - In Section 6, some integer fields are explicitly defined as "unsigned" while some others don't specify the sign. Maybe it's obvious (all seem to be unsigned anyway), but for consistency and by convention I'd suggest clarifying the sign for all integer fields. - Since the "BlockOffset" field is 16-bit, this mechanism can't support IPv6 jumbograms. I don't really think it a problem, and it may not even be worth mentioning, but I'm pointing it out just in case the author wants to clarify it. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
