> On May 3, 2020, at 1:08 PM, Michael Richardson <mcr+i...@sandelman.ca> wrote:
>
>
> Christian Hopps <cho...@chopps.org> 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 <mcr+i...@sandelman.ca>, 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
