[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.
> > If this is unacceptable to the initiator, the initiator
> > MUST delete the SA.
This thing happens after the Child SA is created. I.e., now the
initiator will check whether the Child SA created was following its
policy, and it is completely valid for the initiators policy to say
that must use transport mode, and then it will delete the SA as it was
not following its policy.
It still means that the initiator implementation MUST implement tunnel
mode, but it does not have to USE it if it does not feel like doing
that.
The MUST/SHOULD etc only give requirements for the implementors, i.e.,
what features MUST or SHOULD be implemented and what MAY be
implemented. In the RFCs we cannot use those keywords to instruct
adminstrators/users what they should use.
Quite often, especially in the security considerations section, we try
to give requirements to the users, but we need to be very carefull not
to do that. We can give information to users saying "do not use low
entrypy passwords as PSK as they are known to be unsafe", but we
cannot say MUST NOT use low entropy passwords, as there is no easy for
for implementor to enforce that.
For every single MUST or SHOULD and especially MUST NOT or SHOULD NOT
you are writing to the RFC, you should think how can you answer to
question from the customer who says, "show me the lines in your
implementation which implements this MUST or SHOULD". For MUST and
SHOULDs, that is usully still quite easy, but when someone asks "Show
me the lines of code where you implement: This notification MUST NOT
BE sent by an entity that may be replicated"....
(and yes, I have had incoming customer support case, where they asked
for every single MUST/SHOULD/MUST NOT/SHOULD NOT where it was
implemented in the source of our toolkit).
> > But note that the responder has already installed the IPsec SA in tunnel
> > mode. So if the initiator finds that unacceptable, it must send the
> > delete. During all this time, connectivity between the nodes will be
> > blocked. The intention here is that transport mode is optional and
> > should not be mandated by other protocols. Otherwise, the IKEv1
> > style negoation of transport OR tunnel mode would have been kept.
Also the delete notifications might get lost, and it might takes tens
of seconds, or even minutes before the initiator can finally tell the
responder that the Child SA that didn't follow its policy is deleted.
> How about my mails ask that i read this text such that the initiator will
> delete the SA (not only client SA) if transport mode is not supported
> be responder. Aka: the last two sentences to me describe exactly the
> case where the initiator can/want only support transport mode.
Initiator and responder can delete whatever SAs they like whenever
they like. That does not matter to the actual case here. The issue
there is that if the responder does not want to do transport mode,
then SA will be created in tunnel mode, and the initiator must be able
to cope with tunnel mode ESP packets it is receiving from the
responder. I.e., it needs to be able to implement tunnel mode as much
it understands those packets and does something to them (dropping them
is fine, as if his policy says he wants to get transport mode packets
and do not allow tunnel mode packets, then it is fine to have policy
dropping all tunnel mode packets).
> Aka: i can not read your interpretation into this text.
Anyways, this discussion is not really useful. If the other end does
not support transport mode (as it is allowed to do by IKEv2, as
transport mode is optional), there is nothing you can do to make it
support transport mode, and deleting the Child SA will just cause
initiator to try again few seconds later when it gets next packet to
that direction, with exactly same bad result.
It would be much better to simply say that SHOULD use transport mode,
as it is more efficient for GRE, but if other end does not support
transport mode, using tunnel mode still gets the connectivity, even
when we are wasting few bytes.
In IPsec we had so much issues in IKEv1 where every single option and
feature knob needed to be exactly right to get any connectivity, that
in IKEv2 we tried to get rid of exact negotiation things, instead we
propose something, and we do have fallback to go if other end does not
accept our proposel.
Transport -> tunnel is one of those. IPcomp -> no IPcomp is another,
traffic selector narrowing is third, getting rid of negotiated
lifetimes for SAs was yet another one etc.
The basic idea is that when you finish IKEv2 exchange you have
"usable" child SA you can use to send and receive traffic.
Whether it was exactly what you wanted is another thing, and whether
you can accept that, is initiator choise, and if he cannot accept it,
he can delete the SA and be without connectivity compared to
non-optimal connectivity.
Also as I have understood that your nodes are security gateways (not
hosts, as they do forward packets from other nodes) the RFC4301
already says that they:
b) A security gateway MUST support tunnel mode and MAY support
transport mode. If it supports transport mode, that should be
used only when the security gateway is acting as a host, e.g., for
network management, or to provide security between two
intermediate systems along a path.
Meaning tunnel mode is mandatory to implement in those devices
anyways. The use of tunnel mode is completely different matter then.
> Please answer the other questions from my reply mail.
>
> > So I would recommend to follow the intention of RFC 7296 and not make
> > up your own restrictions.
>
> Again, i had a lot of arguments in my email that i need to see answers
> to so that we can make progress here.
I do disagree with Paul that I think profiles can require certain
optional features to be implemented and used from the base standard,
if it makes sense in there. That does not mean that you can remove
features from the base standards, so even if you do say you use GRE
with transport mode, the IPsec implementations used still need to
implement tunnel mode too, as that is part of the base standard, but
of course you do not need to allow that to be configured, so detecting
use of that might be difficult.
So I think it is ok to say that SHOULD (or even MUST) implement
transport mode for GRE, but it is not ok to say that tunnel mode would
be OPTIONAL, as that would make it so that it cannot connect to the
conforming IKEv2 implementations not supporting transport mode.
We had similar discussion in the RFC7815 minimal IKEv2. That document
really only covered the Shared key authentication even when the base
IKEv2 do require also PKIX certificates and RSA signatures. It does
use one of the mandatory to implement features of the IKEv2, thus it
can talk to all conforming IKEv2 implementations, thus
interoperability is there, but cannot do both of the required
authentication methods, which does not cause problems as full
implementations need to support both anyways.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
