Subject: [IPsec] Some thoughts regarging draft-hopps-ipsecme-iptfs-01

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 28 Nov 2019 16:49:36 +0300

Hi,

after reading through draft-hopps-ipsecme-iptfs-01 I have some thoughts.

1. I think it's a wrong decision to support tunnel mode ESP only. IP-TFS for transport mode ESP
    is equally important because one of the widely used scenario is to combine general purpose
    tunneling (like GRE) with transport mode ESP. In this case traffic flowing over such SA
    will in fact be tunnel traffic from several hosts, but the SA is created in transport mode.
    For this reason I think that IP-TFS must support transport mode SA either.

2. I don't think new IP protocol number is needed at all. Since SA is created with IKEv2,
     it is always known whether it is IPTFS SA or ordinary SA, so "Next Protocol"
     field in ESP trailer is redundant and can be filled in with arbitrary value (say zero). 
    If a new protocol number is allocated, it will never appear in any network header 
    except for encrypted ESP trailer, still it will occupy a codepoint and some middle-box 
    vendors will probably  try to figure out what to do with it (nothing), adding some confusion. 
    Moreover, I suspect that an idea to allocate a codepoint from rather limited resource
    (only 255 are available and more than half of them is already allocated), that will never
    appear in any network header and in reality is not needed, will meet a negative reaction from 
   INT area guys. So, I think we should not go this way and just use zero (or other value)
    as a filler for "Next Header" field.

3. I think that using new Transform Type for IP-TFS negotiation is a bad idea.
   Transforms are best thing when combination of them matters. I don't think
    that it is the case - negotiation of using IP-TFS is orthogonal to negotiation
    of algorithms to use. I cannot imagine that one wants to use IPTFS with 
    say AES-GCM and doesn't want to do it with say Chacha+Poly. 
    So I believe it is better to negotiate IPTFS by means of notifications, as it is done 
    with transport mode or WESP. So, a new notification (let call it USE_IPTFS) should be 
    introduced, which will contain data regarding whether congestion control
    is needed and whether fragmentation is allowed. If the responder supports
    IPTFS it will return back this notification with the data reflecting its choice
    of IPTFS features. In this case IPTFS_REQUIREMENTS notification is not needed.

4. I'd like to see more text in the draft regarding reassembling of incoming packets.
    It seems to me that it can be done pretty easy by linking the reassembly logic
    with replay protection window. Note, that this won't work in case of
    multicast SA with several senders.

5. In general it seems to me that multicast case must be discussed in more details, 
     since in this case neither congestion control nor fragmentation are possible.

6. I think that having inner IP packets properly aligned is a good idea.

7. I don't think that late-enabling of IP-TFS described in section 2.4
    is really needed. It adds unnecessary complexity and somewhat contradicts 
    to what is stated in section 2.3.

Regards,
Valery.

---

From: Christian Hopps <[email-masked]>
Date: Fri, 29 Nov 2019 06:41:28 -0500

Transforms aren't just about the encryption algorithm though (e.g., the extended sequence number transform). In the IP-TFS case it's not about whether one would enable TFS with a given encryption algorithm. Consider supporting and/or selecting from the set of IP-TFS with congestion control, IP-TFS without congestion control, no-IP-TFS, or even another future-defined TFS algorithm. Being able to easy negotiate these different selections was what drove me to the current design. :)

After coding this I will say using transforms feels like a very natural fit.

Thanks,
Chris.

> On Nov 28, 2019, at 8:49 AM, Valery Smyslov <[email-masked]> wrote:
>

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 29 Nov 2019 15:09:54 +0300

Hi Chris,

> Transforms aren't just about the encryption algorithm though (e.g., the extended sequence number
> transform). 

Whether you want to use ESN or not can depend on selected cryptographic algorithms
(there is no point to use ESN unless algorithm allows to encrypt a large amount of data with a single key).

> In the IP-TFS case it's not about whether one would enable TFS with a given encryption algorithm.

Exactly. That's why I think it's better to decouple the negotiation of IP-TFS from the  negotiation 
of cryptographic algorithms.

In your current proposal they are coupled, and this will lead to some problems.
For example, if using IP-TFS congestion control is optional for the initiator, then it must include
two IP-TFS transforms in every proposal. If using IP-TFS itself is optional, then
all the proposals must be duplicated (with and w/o IP-TFS transforms), because
legacy implementations will ignore the whole proposal when they see
an unknown transform type in it. This will lead to SA payload explosion.
And things will get worse with QSKE, since additional key exchanges must
be negotiated using new transforms (they are crypto-related).

> Consider supporting and/or selecting from the set of IP-TFS with congestion control, IP-TFS without
> congestion control, no-IP-TFS, or even another future-defined TFS algorithm. Being able to easy negotiate
> these different selections was what drove me to the current design. :)

It can easily be done with a single notification containing the proposed features.
The responder would send back the notification indicating the features it agrees to use.

> After coding this I will say using transforms feels like a very natural fit.

And notifications is even more natural fit :-)

Regards,
Valery.

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Christian Hopps <[email-masked]>
Date: Fri, 29 Nov 2019 07:47:29 -0500

>    as a filler for "Next Header" field.

I read part of the above as more an argument for decoupling the ESP next header number from IP protocol number space, and not so much as a lack of need for a unique payload identifier for the ESP next header field. This might work if we really want to do this (i.e., create an ESP payload registry separate from the IP protocol numbers), but honestly I think it may be overkill given there are plenty of IP protocol numbers available, and we only need 1 protocol number which we can re-use later if need be. You may be right that 1/2 of the numbers are allocated; however, at least one is deprecated and others could be deprecated (i.e., there's so little pressure on this registry that deprecating unused numbers just hasn't been something worth doing AFAICT). With all that this represents 38 years of allocations. I think we just need to make a clear case for the use, and that we wont keep coming back for more is all.

Additionally, I'm not sure that we should be so quick to say that the IP-TFS payload would never be used outside of ESP; as was pointed out by Michael using this payload does solve the PMTU issue with (IPsec) tunnels, it could be re-used for this purpose outside of ESP as well.

The next-header value is not always redundant, the use case where IP-TFS is enabled in only one direction with congestion control enabled requires being able to differentiate IPv[46] packets from IP-TFS CC information which is now sent in-band in the return direction. The CC information was moved in-band out of IKEv2 from the original -00 document based on comments from the WG (and I agree is a much better solution :)

So, I think we need to stick with explicitly identifying the payload inside ESP. Using the next-header field feels like the correct way of doing this; however, I haven't looked at ESP wrap yet. I do have concerns (which Tero also mentioned at the mic) that it might not be widely implemented.

Possibly re-using the payload type outside of ESP someday is an additional argument for doing the least-disruptive thing and just allocating an IP number. We don't even need a *new* IP protocol number, we could re-use a deprecated IP protocol number. This seems like a nice option to look into.

>    to what is stated in section 2.3.

Having the late-enable could be useful for debugging tunnels during bring-up. This does rely on having a way to identify the payload, but as mentioned above this isn't the only thing that relies on that. It didn't add much complexity to my code, but I'm certainly curious on other opinions on this.

Thanks,
Chris.

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 29 Nov 2019 16:13:04 +0300

Hi Chris,

> I read part of the above as more an argument for decoupling the ESP next header number from IP protocol
> number space, and not so much as a lack of need for a unique payload identifier for the ESP next header field.
> This might work if we really want to do this (i.e., create an ESP payload registry separate from the IP protocol
> numbers), but honestly I think it may be overkill given there are plenty of IP protocol numbers available, and
> we only need 1 protocol number which we can re-use later if need be. You may be right that 1/2 of the
> numbers are allocated; however, at least one is deprecated and others could be deprecated (i.e., there's so
> little pressure on this registry that deprecating unused numbers just hasn't been something worth doing
> AFAICT). With all that this represents 38 years of allocations. I think we just need to make a clear case for the
> use, and that we wont keep coming back for more is all.

I envision a lively discussion with INT folks if we ask them for a "fake" protocol number :-)

> Additionally, I'm not sure that we should be so quick to say that the IP-TFS payload would never be used
> outside of ESP; as was pointed out by Michael using this payload does solve the PMTU issue with (IPsec)
> tunnels, it could be re-used for this purpose outside of ESP as well.

Please, elaborate.

> The next-header value is not always redundant, the use case where IP-TFS is enabled in only one direction
> with congestion control enabled requires being able to differentiate IPv[46] packets from IP-TFS CC
> information which is now sent in-band in the return direction. The CC information was moved in-band out of
> IKEv2 from the original -00 document based on comments from the WG (and I agree is a much better solution
> :)

It's a strange use case. Both peers must support IP-TFS, but it is used only in one direction, so its usefulness 
is limited (you can gain quite a lot information from timing of return packets). Do we really need to complicate
things to allow such asymmetric use case? BTW, you cannot negotiate it with your current spec :-)

> So, I think we need to stick with explicitly identifying the payload inside ESP. Using the next-header field feels
> like the correct way of doing this; however, I haven't looked at ESP wrap yet. I do have concerns (which Tero
> also mentioned at the mic) that it might not be widely implemented.
> 
> Possibly re-using the payload type outside of ESP someday is an additional argument for doing the least-
> disruptive thing and just allocating an IP number. We don't even need a *new* IP protocol number, we could
> re-use a deprecated IP protocol number. This seems like a nice option to look into.

I'm still not sure that it's really needed.

> Having the late-enable could be useful for debugging tunnels during bring-up. This does rely on having a way
> to identify the payload, but as mentioned above this isn't the only thing that relies on that. It didn't add much
> complexity to my code, but I'm certainly curious on other opinions on this.

Color me unconvinced. Debugging is a local matter and should not be reflected in the spec.

Regards,
Valery.

> Chris.=

---

From: Christian Hopps <[email-masked]>
Date: Fri, 29 Nov 2019 08:48:48 -0500

> On Nov 29, 2019, at 7:09 AM, Valery Smyslov <[email-masked]> wrote:
> 
> Hi Chris,
> 

I have some doubts about calling this "easy". This sounds a lot like the already existing transform mechanism. Are there other deployed examples of negotiating the required features of an SA using notifications in parallel with the transforms? It seems to me there's a lot of standard text, experience, and deployed code written getting the transform negotiation mechanism working correctly. Duplicating this rather than re-using it worries me.

Thanks,
Chris.

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 29 Nov 2019 17:01:31 +0300

> I have some doubts about calling this "easy". This sounds a lot like the already existing transform mechanism.
> Are there other deployed examples of negotiating the required features of an SA using notifications in parallel
> with the transforms? It seems to me there's a lot of standard text, experience, and deployed code written
> getting the transform negotiation mechanism working correctly. Duplicating this rather than re-using it
> worries me.

A lot of things in IKEv2 is negotiated by using notifications. With regard to child SA they are - 
using transport mode, using IPcomp, using WESP, using ROHC. 
IP-TFC looks to me like a natural continuation of this line.

Regards,
Valery.

---

From: Christian Hopps <[email-masked]>
Date: Fri, 29 Nov 2019 10:38:16 -0500

> On Nov 29, 2019, at 8:13 AM, Valery Smyslov <[email-masked]> wrote:
> 
> Hi Chris,
> 

I would not choose to refer to it as a fake protocol. The field is defined as an IPv4 or IPv6 protocol value to identify the ESP payload. IPsec/ESP is *the* standard for encrypting IP traffic so this field has a valid claim to make on that number space. Just b/c it may not (but see next point) be used outside of IPsec/ESP doesn't mean that IPsec should not be able to allocate a number from it.

>> tunnels, it could be re-used for this purpose outside of ESP as well.

The IP-TFS payload format allows for any-sized IP packet to be encapsulated inside an MTU sized outer header. Thus something like a GRE tunnel (with sequence numbers) with PMTU size-limited packets would not limit the inner payload packet size to the PMTU of the GRE tunnel. I'm not proposing this right now, but it's not hard to envision this use in the future, especially if IP-TFS is widely adopted by vendors.

> things to allow such asymmetric use case? BTW, you cannot negotiate it with your current spec :-)

I do not think this is strange, consider uni-directional data streams, e.g., telemetry.

> Color me unconvinced. Debugging is a local matter and should not be reflected in the spec.

ICMP echo request/reply? :)

More apropos, adding things to a protocol to make it easier to deploy/debug is not uncommon, we certainly have examples of this in routing (e.g., host identifier TLV in IS-IS etc)...

If this were the only reason for using the next header field I'd say the case is not strong for keeping it, but we still have the uni-directional CC case, so this second use doesn't cost much IMO.

Thanks,
Chris.

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 29 Nov 2019 19:14:00 +0300

> I would not choose to refer to it as a fake protocol. The field is defined as an IPv4 or IPv6 protocol value to
> identify the ESP payload. IPsec/ESP is *the* standard for encrypting IP traffic so this field has a valid claim to
> make on that number space. Just b/c it may not (but see next point) be used outside of IPsec/ESP doesn't
> mean that IPsec should not be able to allocate a number from it.

I meant that this IP protocol number will never be seen (and used) outside ESP. 
So, it's an ESP-only protocol number, thus for INT folks it's a "fake" one.

> The IP-TFS payload format allows for any-sized IP packet to be encapsulated inside an MTU sized outer
> header. Thus something like a GRE tunnel (with sequence numbers) with PMTU size-limited packets would not
> limit the inner payload packet size to the PMTU of the GRE tunnel. I'm not proposing this right now, but it's
> not hard to envision this use in the future, especially if IP-TFS is widely adopted by vendors.

Ah, I see - you want to use the same technique inside some other tunneling protocol.
This is doable, but in my opinion you should have control layer to set up such a tunnel
(like IKEv2 does for ESP), and you'll probably have this tunnel dedicated to IP-TFS traffic only,
and the peers would negotiate this feature over the control layer. So, new protocol
number seems redundant in this case too. I can't buy this argument.

> I do not think this is strange, consider uni-directional data streams, e.g., telemetry.

ESP SAs are always created in pairs. And whether IP-TFS is enabled or not is common for both SAs.
Even if you use only one SA for IP-TFS traffic, the other will have IP-TFS enabled too.
How are you going with your spec to create a pair of SAs where IP-TFS is enabled in one direction and 
disabled in the other? Am I missing something? Even if you are able to create such a pair of SAs, is it justified?

> ICMP echo request/reply? :)

It's not for debugging, it's for testing network connectivity.

>From what's written in you draft I made a conclusion that you want to help debugging
implementations, that's completely different thing. 

> More apropos, adding things to a protocol to make it easier to deploy/debug is not uncommon, we certainly
> have examples of this in routing (e.g., host identifier TLV in IS-IS etc)...
> 
> If this were the only reason for using the next header field I'd say the case is not strong for keeping it, but we
> still have the uni-directional CC case, so this second use doesn't cost much IMO.

Hmm, see above about uni-directional CC.

Regards,
Valery.

---

From: Christian Hopps <[email-masked]>
Date: Fri, 29 Nov 2019 12:38:51 -0500

> On Nov 29, 2019, at 11:14 AM, Valery Smyslov <[email-masked]> wrote:
> 

What I'm saying is that IPsec/ESP is *the* standard for encrypted IP even in the context of INT, so the next header field in the ESP payload is a valid IP protocol payload in that context, it's not fake in the INT context just b/c it might not be used outside of encrypted IP packets.

[...]

> disabled in the other? Am I missing something? Even if you are able to create such a pair of SAs, is it justified?

Understood that SAs are created in pairs. The intent here (and throughout the draft) is not to unnecessarily restrict possible uses. Having IP-TFS enabled on only one of a pair of SAs can make sense when you're only trying to protect traffic sent in one direction from traffic analysis (again e.g., telemetry). The use of IP-TFS does involve the allocation of a fixed amount of bandwidth so the justification for not enabling it in one direction is to save that bandwidth.

The spec is (trying to be) very careful in not restricting the unidirectional TFS use case b/c there's no reason to do so, and so there should not be anything in the document that restricts having only one of the SA pairs used by IPsec/ESP running with IP-TFS.

Setting up such an SA pair is orthogonal to being able to run with that configuration. While the vast majority of IPsec utilizes IKEv2 for SA creation/management, this is not a requirement of IPsec/ESP. The unidirectional case can be covered with local configuration (along with IKEv2), or by using another method entirely for the SA management.

The intent in the end is to specify what we need to for IP-TFS operation, but not too over-specify and unnecessarily restrict possible future (or outside) uses. IOW, less is more.

FWIW, I did explore adding machinery to IKEv2 to allow setting up/negotiating unidirectional use cases, but it adds a lot of complexity, and so we decided that while unidirectional TFS protection is useful it will still be a relatively uncommon configuration and was best left for local configuration for now. If in the future we see a large call for on-demand/negotiated (vs local config) uni-directional TFS we can always come back and add it to IKEv2. What's important in the context of the IKEv2 changes for now is that we don't do anything to block doing this in the future.

Thanks,
Chris.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 29 Nov 2019 14:18:01 -0500

As I understand it, the question is:

  ESP(np=??)[IP-fragment, .., IP-fragment, padding]
  IPvX(np=ESP)
  L2

What will the ?? be.   I agree that it makes no sense to mark this as IPIP.
I see that we could re-use TF-ESP's number here if we got push-back.
 a) It would make no sense to put a TF-ESP inside an ESP in "transport" mode.
 b) nobody uses TF-ESP, we should just deprecate it :-)

But, before we do this, we should just ask for a number.
I don't see a reason to support transport inside of this formulation, I'd
have to go back the document to see why it might be difficult to do, but if
it's not hard to do, then don't forbid it.

(We also shouldn't forbid transporting Elephants in small clown cars, but I
don't recommend that either)

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Fri, 29 Nov 2019 14:23:11 -0500

Christian Hopps <[email-masked]> wrote:
    > Additionally, I'm not sure that we should be so quick to say that the
    > IP-TFS payload would never be used outside of ESP; as was pointed out
    > by Michael using this payload does solve the PMTU issue with (IPsec)

I think that I was mis-interpreted.
I wasn't saying that this protocol would get used outside of ESP.
I'm saying that this protocol (with ESP) will solve the PMTU problem, and so
make IPsec more popular.

Maybe that also means that being able to use it with transport mode could be
interesting, but I think that BEET mode is more likely.

I think that having a proper IP protocol number will simplify kernel implementations.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Christian Hopps <[email-masked]>
Date: Fri, 29 Nov 2019 14:30:01 -0500

> On Nov 29, 2019, at 2:23 PM, Michael Richardson <[email-masked]> wrote:
> 
> 

Right, sorry, I put your meaning in parens "(Ipsec)", and I probably shouldn't have been trying to also point out, in the same overloaded sentence, that this same logic would apply to any IP-in-IP tunnel context as well. :)

Thanks,
Chris.

---

From: Paul Wouters <[email-masked]>
Date: Sat, 30 Nov 2019 13:35:22 +0700

> IP-TFC looks to me like a natural continuation of this line.

I agree. This is easier to implement than using traffic selectors and seems more appropriate as it is an “optional” thing to enable - similar to transport mode and compression.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Sun, 1 Dec 2019 02:41:38 -0500 (EST)

> Understood that SAs are created in pairs. The intent here (and throughout the draft) is not to unnecessarily restrict possible uses. Having IP-TFS enabled on only one of a pair of SAs can make sens…

It seems unwise to protect traffic one way but not the other way. Are
endusers really able to make the right decision based on their generated
traffic? If you are that hungry for resources, perhaps this isn't an
option for you to use?

Also, if an inbound or outbound SA is not using IP-TFS, couldn't the
memory be deallocated, or the memory allocation could be postponed
until the first IP-TFS type packet arrives?

The architecture is really symmetrical for in/out bound SA's, so I
would prefer we do not change that.

> The spec is (trying to be) very careful in not restricting the unidirectional TFS use case b/c there's no reason to do so, and so there should not be anything in the document that restricts having…

The question is, does it need to be negotiated or not or can a well
implemented implementation postpone all memory requirements if this
feature is unused in one direction?

> Setting up such an SA pair is orthogonal to being able to run with that configuration. While the vast majority of IPsec utilizes IKEv2 for SA creation/management, this is not a requirement of IPsec…

Non-IKE can negotiate whatever it want and hack in custom IPsec SA's
that we would find completely illegal. That's out of scope of this WG,
but we should also not bring it into scope as "others might want that".

> The intent in the end is to specify what we need to for IP-TFS operation, but not too over-specify and unnecessarily restrict possible future (or outside) uses. IOW, less is more.

But I am still not convinced endusers can make these decisions of
bidirectional vs unidirectional and whther or not their traffic
becomes more susceptible to traffic analyses attacks.

> FWIW, I did explore adding machinery to IKEv2 to allow setting up/negotiating unidirectional use cases, but it adds a lot of complexity, and so we decided that while unidirectional TFS protection i…

I have not yet been convinced of this.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Sun, 1 Dec 2019 02:52:49 -0500 (EST)

>    For this reason I think that IP-TFS must support transport mode SA either.

I sadly agree. I was quite shocked to recently learn that Cisco prefers
GRE over Transport Mode for _all_ of their subnet to subnet configurations and
they consider their policy based VPN configs using cryptomap "obsolete".

> 3. I think that using new Transform Type for IP-TFS negotiation is a bad idea.

I also prefer to see a USE_IPTFS notify similar to USE_TRANSPORT and USE_COMPRESS.

>    to what is stated in section 2.3.

I agree. It would also have to specify a PF_KEY/NETLINK type message
because the userland IKE daemon must know this has happened, to be
able to reject/accept or at least log this event. If the only goal is
debugging, then we should just not allow this. The same could be
achieved by rekeying the child sa with the USE_IPTFS notify (which
would be another reason not to use a transform, because those must
not change during rekey)

Paul