[talking as another individual and co-author of RFC7296, not as the other chair]


> On 18 Jun 2020, at 21:03, Tero Kivinen <kivi...@iki.fi> wrote:
> 
> [talking as individual and one of RFC7296 authors, not as WG chair].
> 
> Toerless Eckert writes:
>> On Wed, Jun 17, 2020 at 08:55:12PM -0400, Paul Wouters wrote:
>>> The RFC states:
>>> 
>>>   The USE_TRANSPORT_MODE notification MAY be included in a request
>>>   message that also includes an SA payload requesting a Child SA.  It
>>>   requests that the Child SA use transport mode rather than tunnel mode
>>>   for the SA created.  If the request is accepted, the response MUST
>>>   also include a notification of type USE_TRANSPORT_MODE.  If the
>>>   responder declines the request, the Child SA will be established in
>>>   tunnel mode.
> 
> At this point the responder already created an Child SA in tunnel
> mode, and when the initiator receives that message from the responder
> it will also create the Child SA in tunnel mode. Responder might
> already be sending traffic at this point.
> 
> This means both initiator and responder MUST implement tunnel mode, as
> otherwise they cannot perform those actions. Meaning as the fallback
> from the transport mode is tunnel mode, all implementations MUST
> implement it even if it not explictly said in the RFC.

I half agree. RFC 7296 describes IKEv2, not IPsec. An IKEv2 implementation must 
support the creation of a tunnel-mode Child SA. It may configure an IPsec layer 
that does not support tunnel-mode.

I think it’s compliant with the letter if not the spirit of RFC 7296 to have a 
specialized IKEv2 implementation that can negotiate a tunnel mode SA, but 
immediately deletes such an SA if it is created, and I think such an 
implementation will also be compliant if it rejects any CREATE_CHILD_SA request 
that does not include the USE_TRANSPORT_MODE notification.

Of course none of us would use such an implementation in our VPN gateway, but 
it can be appropriate for special uses, such as host-to-host within a 
datacenter.

Having said that, supporting tunnel mode as a fallback and making transport a 
SHOULD is still a good idea. Tunnel mode has a per-packet extra cost of 20 or 
40 bytes, but it’s generally better than no communications at all.

Yoav

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to