Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane)

From: Toerless Eckert <[email-masked]>
Date: Wed, 17 Jun 2020 22:56:20 +0200

Thank, Paul

Given how you are focussing on this aspect,
can i assume that you are happy with the everything
else in the suggested text ?

Wrt to tunnel vs. transport mode:

If you can, please propose specific text that would improve
the quality of the doc wrt. to your point.

I can only observe:

a) I have not found the word "profile" in neither rfc4301
nor rfc5996, so i have no basis from which to argue what could
or could not be called permissible for a "profile"

b) I have not seen MUST support transport and MUST support
tunnel mode, so being "incapable" of either option will
lead to closing the connection, and those implementatoins
are i think compliant with the IPsec/IKEv2 RFCs.

b) All router implementations i know that can do tunnel
and transport mode allow you to configure which option
specifically to use and they too will close a connection
is there is a mismatch. One could call that configuration
"unwilling".

ACP draft does not even have a notion of "unwilling",
just "incapable".

Cheers
    Toerless

Every router allows you to configure whether an 
On Wed, Jun 17, 2020 at 04:01:25PM -0400, Paul Wouters wrote:
> On Wed, 17 Jun 2020, Toerless Eckert wrote:
> 
> > > Note that you cannot _require_ transport mode, as the IKEv2
> > > protocol only allows you to _suggest_ transport mode. The peer
> > > can reject that suggestion and insist the connection uses
> > > tunnel mode.
> > 
> > But we do define a profile of use of IPsec that both sides need to support
> > to ineroperate. So what specifically does prohibit a specificartion of such
> > a profile to require to support and prefer one mode over the other ?
> > 
> > This is a peer-to-peer communication solution, so no interop
> > with devices not confirming to this spec.
> 
> The profile is about protocol choices you agree to set in the
> profile. These choices are expected to be negotiated, eg encryption via
> AES_GCM, or encryption via CHACHA20_POLY1305. Your profile can say to
> pick one of these or both, because the protocol allows that.
> 
> But the protocol does not provide the profiles a way to say "MUST
> do transport mode". The protocol only provides a way to say "Prefers
> transport mode".
> 
> Technically, your profile could say to "request transport mode, and
> refuse the connection if the other end is unwilling to use transport
> mode", but that I would argue that would constitute a protocol
> modification which is not what a profile should do.
> 
> Paul

-- 
---
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Wed, 17 Jun 2020 17:07:48 -0400 (EDT)

> else in the suggested text ?

I don't know yet. I have to re-read the last draft version.

> or could not be called permissible for a "profile"

I don't think we have an official IETF definition of a profile, but it
usually means a collection of protocol parameters that are normally
negotiated. For an example IPsec profile, see:

https://www.rfc-editor.org/rfc/rfc6380.html

Another more recent one is the draft for the updated CNDSA profile:

https://tools.ietf.org/html/draft-corcoran-cnsa-ipsec-profile-00

> are i think compliant with the IPsec/IKEv2 RFCs.

Tunnel Mode is Mandatory To Implement. Transpode Mode is not.

> is there is a mismatch. One could call that configuration

Yes. In IKEv1, one was allowed to require Tunnel OR Transport
mode, but for IKEv2 it was a conscious decision to make
transport mode something a responder could refuse, without
breaking the IPsec connection. This was done specifically to
move most scenarios (especially over the internet, especially
when NAT is involved) to Tunnel Mode. Transport Mode can be
used but really should only be used if there is no NAT.

And those reasons are also why I now bring this up. I want to
avoid a new RFC that requires Transport Mode. It is fine to
recommend it, as long as the responder is still allowed to
refuse this, and be ensured that tunnel mode will be used instead.
A connection MUST NOT hard fail on not getting Transport Mode.

> ACP draft does not even have a notion of "unwilling",

My comments were triggered based on the texts in this email thread.
As I said, I still need to reread the latest draft version.

Paul

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 18 Jun 2020 00:19:17 +0200

> I don't know yet. I have to re-read the last draft version.

Just about the text i sent today on this thread. Still finalizing
the -25 version of the actual draft.

> used but really should only be used if there is no NAT.

The ACP tunnels are across link-local scope IPv6 addresses
inside a LAN. Hence no issue. And for manual configured tunnel
there is the GRE tunnel option.

> A connection MUST NOT hard fail on not getting Transport Mode.

Where does in say in RFC7296 that you MUST implement tunnel
mode  and SHOULD/MAY implement transport mode ?

RFC7296:

| 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.  If this is unacceptable to the initiator, the initiator
| MUST delete the SA.

The last two sentences read to me as if it is fine to only
support transport but not tunnel mode, at least for the initiator:
closing the connection ("deleting SA") if the initiator is only willing
 to do tansport mode, but not tunnel mode.

What do you read from that ?

> As I said, I still need to reread the latest draft version.

Sure, it was just clarification, but logically its hard to
argue protocol violation based on attempting to distinguish
unwilling and incapable. Sounds like a good court soap opera:

DA: "Sir.IKEv2, Where you incapable or unwilling" ?
IKEv2: "Incapable, it's not my fault" !
DA: "But i see your source code which makes you capable".
IKEv2: "But the operator disabled it"
DA: "You should not listen to what the operator says, you are an autonomous system"

;-))

But seriously: Whats the technical reasoning ? Just be sure to
have an MTI ? 

Clearly for the use-case of automatic ACP secure channel,
the transport mode option is the one with least packet header /
MTU loss overhead. 

In 6.7.5 are the actual requirments and it does say for the
ACP baseline profile "MUST transport", "MAY GRE". 

Give or take disagremement about whats technically best
(which we should resolve), lets assume we do agree the
technical goal is correct, if there really is clear text
in IKEv2 thats violated (see above ask), we could still
add a one line section making this an update to IKEv2
RFC for the specific case of automatic ACP link-local tunnels.
I just find that unnecessary based on a) not finding the
IKEv2 RFC requirements text, b) knowing how it is 
common implementation practice to choose an option like
ACP is asking for.

Cheers
    Toerless