Re: [IPsec] Clarifications and Implementation Guidelines for using TCP Encapsulation in IKEv2 draft
Hi Ben, > On Wed, Apr 29, 2020 at 10:54:26PM +0300, Yoav Nir wrote: > > [With chair hat on] > > > > Yes, the charter says that we are to make a guidance document. If the > working group feels that it’s better to put the specification and guidance in > a > single document, we can work on that and clear it with the ADs. > > > > Charters can be modified. > > FWIW I don't see a particular need to recharter to do an 8229bis. Can you please clarify for those of us who (like me) are not native speakers: do you think that the current charter allows to do an 8229bis without need to recharter or do you think there is no need to do an 8229bis and thus no need to recharter? Thank you, Valery. > -Ben ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IPTFS and transport mode.
On Sun, 3 May 2020, Christian Hopps wrote: An open issue we have for IPTFS is the use of transport mode. During the last face-to-face IETF meeting transport mode was mentioned, and my response had been that transport mode was less secure than non-TFS tunnel mode as the IP header was leaking user information so it hadn't been a consideration for us; however, it was later pointed out (by Paul W. I believe), that transport mode is (unfortunately?) commonly used with GRE tunnels in lieu of IPsec tunnel mode so we probably still needed to handle this case. That is one use case of an IPsec connection across the internet using transport mode. There are other uses of transport mode, such as nodes within a LAN/WAN, but I don't think these really gain much from TFS. You can't really have all your data center nodes generate fake traffic between them. If if these cross data centers, there is another gateway to gateway IPsec connection in place as the outer layer, using tunnel mode (or transport mode with GRE) We believe that there's enough complexity in the handling and specification of TFS for transport mode that we should address this mode in a separate draft. This will allow us to get the less complex TFS tunnel mode specified while we continue to work on the various aspects of how best to handle TFS transport mode. That's fine with me, provided that we think that we the current TFS for tunnel mode would not need modification later to support transport mode, and that we are mostly looking to specify restrictions on specific packets and options in the transmode mode draft. We would be happy to work with other interested folks to write this TFS transport mode draft. I think that is valid. Also, anyone who would _really_ want TFS can also turn their transmode mode IPsec into tunnel mode IPsec. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Clarifications and Implementation Guidelines for using TCP Encapsulation in IKEv2 draft
On Wed, Apr 29, 2020 at 10:54:26PM +0300, Yoav Nir wrote: > [With chair hat on] > > Yes, the charter says that we are to make a guidance document. If the working > group feels that it’s better to put the specification and guidance in a > single document, we can work on that and clear it with the ADs. > > Charters can be modified. FWIW I don't see a particular need to recharter to do an 8229bis. -Ben ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IPTFS and transport mode.
> On May 3, 2020, at 1:08 PM, Michael Richardson wrote: > > > Christian Hopps wrote: >> non-TFS tunnel mode as the IP header was leaking user information so it >> hadn't been a consideration for us; however, it was later pointed out >> (by Paul W. I believe), that transport mode is (unfortunately?) >> commonly used with GRE tunnels in lieu of IPsec tunnel mode so we >> probably still needed to handle this case. > > If there will be changes to the GRE/IPsec mode, then maybe BEET mode could be > considered rather than transport mode. BEET mode looks like transport mode > on the wire, but is treated virtually like tunnel mode. This is essentially > what you describe: > >> For the common case of GRE/tunnel (which is the main justification for >> use of transport mode IMO), the GRE header information should be >> stable, and relatively easy to cache/consolidate for >> regeneration/aggregation. Handling only this case is relatively easy, >> We should be able to use the last received header information to >> generate new headers for empty packets, likewise aggregating headers >> should also work as each IP header should be the same. > > You have described essentially BEET mode :-) > It is described in RFC7402. > >> We believe that there's enough complexity in the handling and >> specification of TFS for transport mode that we should address this >> mode in a separate draft. This will allow us to get the less complex >> TFS tunnel mode specified while we continue to work on the various >> aspects of how best to handle TFS transport mode. > > I am not convinced that you really want to handle the generic transport mode > case. I think that you want to handle the GRE case specifically. > I'm unclear if your above description is a hack to make GRE/tunnel fit into > your current situation, or if you are describing a new situation that would > handle in a new draft. The primary thing I'm suggesting here is that we define TFS transport mode in a separate draft. Whether we support generic transport or only a subset of transport configurations (e.g., tunnels) or both, the reasons we make whatever choices we make, and the mechanisms for how to implement TFS with whatever is chosen, is what this new draft would cover. I see this building on top of the TFS tunnel mode draft. The rest of what I put above was really just ideas for what would go in that new draft. My thinking that if we wanted to support a subset of transport mode configurations (e.g., for use with GRE, SRv6, IP-IP, etc) we could specify that by defining a set of restrictions on the user IP headers. I'm not sure if that's what you mean is a hack or not, but I figured if we define it by the restrictions rather than specifically only for GRE it's more broadly useful for little extra cost. In any case the discussion of this and definition is what I think would go well in the context of it's own draft. Thanks, Chris. > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IPTFS and transport mode.
Christian Hopps wrote: > non-TFS tunnel mode as the IP header was leaking user information so it > hadn't been a consideration for us; however, it was later pointed out > (by Paul W. I believe), that transport mode is (unfortunately?) > commonly used with GRE tunnels in lieu of IPsec tunnel mode so we > probably still needed to handle this case. If there will be changes to the GRE/IPsec mode, then maybe BEET mode could be considered rather than transport mode. BEET mode looks like transport mode on the wire, but is treated virtually like tunnel mode. This is essentially what you describe: > For the common case of GRE/tunnel (which is the main justification for > use of transport mode IMO), the GRE header information should be > stable, and relatively easy to cache/consolidate for > regeneration/aggregation. Handling only this case is relatively easy, > We should be able to use the last received header information to > generate new headers for empty packets, likewise aggregating headers > should also work as each IP header should be the same. You have described essentially BEET mode :-) It is described in RFC7402. > We believe that there's enough complexity in the handling and > specification of TFS for transport mode that we should address this > mode in a separate draft. This will allow us to get the less complex > TFS tunnel mode specified while we continue to work on the various > aspects of how best to handle TFS transport mode. I am not convinced that you really want to handle the generic transport mode case. I think that you want to handle the GRE case specifically. I'm unclear if your above description is a hack to make GRE/tunnel fit into your current situation, or if you are describing a new situation that would handle in a new draft. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] IPTFS and transport mode.
Hi ipsecme, An open issue we have for IPTFS is the use of transport mode. During the last face-to-face IETF meeting transport mode was mentioned, and my response had been that transport mode was less secure than non-TFS tunnel mode as the IP header was leaking user information so it hadn't been a consideration for us; however, it was later pointed out (by Paul W. I believe), that transport mode is (unfortunately?) commonly used with GRE tunnels in lieu of IPsec tunnel mode so we probably still needed to handle this case. Key to TFS is sending data even when there is none from the user and also changing the rate at which we send the user data. This means that we need to be able to generate empty packets, and we need to be able to consolidate user data packets. This is the primary hurdle in handling transport mode, it means that we must cache information from the user connection in order to generate empty packets, and we must also be able to aggregate user data packet headers. For the common case of GRE/tunnel (which is the main justification for use of transport mode IMO), the GRE header information should be stable, and relatively easy to cache/consolidate for regeneration/aggregation. Handling only this case is relatively easy, We should be able to use the last received header information to generate new headers for empty packets, likewise aggregating headers should also work as each IP header should be the same. This simpler solution requires specification of what IP header fields are expected to be the same packet to packet. It means that certain things in the user IP header should not be present as well, like IP fragmentation/reassembly data, or per packet varying IP options/extension headers. IP fragmentation: - For the GRE/tunnel case we could mandate that the GRE tunnel packets need to arrive at IPsec un-fragmented. - For a more generic transport case IP fragmentation in the unencrypted header is a leak of user information so we would need to hide it (starts seeming like a tunnel again) IP options/IPv6 extension headers: - These would need to remain stable, or leaving them off or repeating them would need to be OK. - For the the GRE/tunnel case this hopefully would be straight-forward - Unsure on how to specify this for more generic case. We believe that there's enough complexity in the handling and specification of TFS for transport mode that we should address this mode in a separate draft. This will allow us to get the less complex TFS tunnel mode specified while we continue to work on the various aspects of how best to handle TFS transport mode. We would be happy to work with other interested folks to write this TFS transport mode draft. Thanks, Chris. signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
