Subject: [IPsec] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt

From: Christian Hopps <[email-masked]>
Date: Mon, 11 Mar 2019 10:32:48 -0400

Hi ipsecme folks,

Here's some new work on improving IP traffic flow security. I've requested a presentation slot from the chairs for the upcoming ipsecme WG meeting @ IETF 104, and will hopefully be able to present this work at that time as well.

Thanks,
Chris.

[email-masked] writes:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>         Title           : IP Traffic Flow Security
>         Author          : Christian Hopps
> 	Filename        : draft-hopps-ipsecme-iptfs-00.txt
> 	Pages           : 22
> 	Date            : 2019-03-11
>
> Abstract:
>    This document describes a mechanism to enhance IPsec traffic flow
>    security by adding traffic flow confidentiality to encrypted IP
>    encapsulated traffic.  Traffic flow confidentiality is provided by
>    obscuring the size and frequency of IP traffic using a fixed-sized,
>    constant-send-rate IPsec tunnel.  The solution allows for congestion
>    control as well.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-hopps-ipsecme-iptfs/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-hopps-ipsecme-iptfs-00
> https://datatracker.ietf.org/doc/html/draft-hopps-ipsecme-iptfs-00
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Paul Wouters <[email-masked]>
Date: Mon, 11 Mar 2019 10:51:22 -0400 (EDT)

On Mon, 11 Mar 2019, Christian Hopps wrote:

> Here's some new work on improving IP traffic flow security. I've requested a 
> presentation slot from the chairs for the upcoming ipsecme WG meeting @ IETF 
> 104, and will hopefully be able to present this work at that time as well.

Thanks. I did a quick read and I'm still digesting this, but one thing
seems a concern:

    We utilize a send only (i.e., no response expected) IKEv2
    INFORMATIONAL exchange (37) to transmit the congestion information
    using a notification payload of type TFS_CONGEST_INFO (TBD).  The The
    Response bit should be set to 0.  As no response is expected the only
    payload should be the congestion information in the notification
    payload.

This very much violates the state machine model of IKEv2, and I would
not be in favour of this without strong arguments of why requiring a
response (even if empty) is harmful.

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 11 Mar 2019 18:43:49 +0300

Hi,

> response (even if empty) is harmful.

Strongly agree. Actually, one-way notifications are only defined
in IKEv2 for unprotected error notifications when no IKE SA exists
(like INVALID_IKE_SPI notifications). They simply don't work
for regular IKEv2 traffic.

Regards,
Valery.

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

---

From: Christian Hopps <[email-masked]>
Date: Mon, 11 Mar 2019 12:20:42 -0400

Sure, I'm definitely open to changes, and in particular with the congestion info report. This is just the first draft. :)

So my reading of IKEv2 indicated that one way notifications were supported, not that they were *only* to be used for unprotected error notification though. Yes, they are currently only used for errors, but again I didn't read they were restricted to that use alone.

The reason I did not want to make the report sending reliable is that they are continuously sent on an relatively short interval. It didn't make a lot of sense to be re-sending a possibly growing queue of reports repeatedly, when the latest one would do.

Thanks,
Chris.

> On Mar 11, 2019, at 11:43 AM, Valery Smyslov <[email-masked]> wrote:
> 
> Hi,
>

---

From: Paul Wouters <[email-masked]>
Date: Mon, 11 Mar 2019 12:32:42 -0400 (EDT)

> So my reading of IKEv2 indicated that one way notifications were supported, not that they were *only* to be used for unprotected error notification though. Yes, they are currently only used for err…

Note that even those errors are in reply to an IKE request, so you still
have a request and reply message.

> The reason I did not want to make the report sending reliable is that they are continuously sent on an relatively short interval. It didn't make a lot of sense to be re-sending a possibly growing q…

You might find previous discussion about MSGID and liveness probes
interesting then. That runs into similar issues and we don't have
a fix for this yet, although it has come up a few times that we
sould write a clarifying draft on MSGID.

For example, if you send a liveness probe and receive no answer, you
cannot send a delete notification because the liveness answer is
still pending. If you send many of these kind of IKE packets, then
you would run into similar problems.

Paul

---

From: Christian Hopps <[email-masked]>
Date: Mon, 11 Mar 2019 12:35:39 -0400

> On Mar 11, 2019, at 10:51 AM, Paul Wouters <[email-masked]> wrote:
> 

The strongest case I can give is that this data represents "telemetry" and is sent at a constant rate, there's no need to make it reliable (and resending queues of them seems bad if they aren't being ack'd).

There are other ways to skin this cat though. :)

One option is that instead of sending a new CC info report on the interval timer expiry if we haven't received a response "ack" yet, we simply update the data (last seq num seen, drop count and timestamp) we sent previously to be current, keep the message ID the same and resend the message. Would changing the data in the message prior to resending be preferable?

Thanks,
Chris.

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 12 Mar 2019 17:34:25 +0300

Hi Chris,

> So my reading of IKEv2 indicated that one way notifications were supported, not that they were *only* to be
> used for unprotected error notification though. Yes, they are currently only used for errors, but again I didn't
> read they were restricted to that use alone.

No, unidirectional notifications cannot be used in regular IKE SAs. The reason is that both peers must have common view 
on the next Message ID to be used in each direction. If unidirectional message with Message ID N is lost, its sender will never know
that
and think he can safely use Message ID N+1 for the next exchange, while the receiver will discard N+1, since
N is not received yet (I assume for simplicity that IKE window size is 1). This simply won't work.

In current IKEv2 unidirectional messages are exceptions and can only be sent unencrypted outside 
any existing IKE SA.

> The reason I did not want to make the report sending reliable is that they are continuously sent on an
> relatively short interval. It didn't make a lot of sense to be re-sending a possibly growing queue of reports
> repeatedly, when the latest one would do.

Then send them over IPsec.

Regards,
Valery.

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 12 Mar 2019 17:39:06 +0300

Hi Chris,

> One option is that instead of sending a new CC info report on the interval timer expiry if we haven't received a
> response "ack" yet, we simply update the data (last seq num seen, drop count and timestamp) we sent
> previously to be current, keep the message ID the same and resend the message. Would changing the data in
> the message prior to resending be preferable?

No, all retransmissions of IKE message with the same Message ID must be binary identical.

Regards,
Valery.

---

From: Christian Hopps <[email-masked]>
Date: Tue, 12 Mar 2019 11:42:44 -0400

> On Mar 12, 2019, at 10:34, Valery Smyslov <[email-masked]> wrote:
> 
> Hi Chris,
> 

Ok. Perhaps we could look into extending their usefulness?

> Then send them over IPsec.

Unfortunately this would require bi-directional tunnels, which we don’t want to require.

More in the reply to the other email...

Thanks,
Chris.

---

From: Christian Hopps <[email-masked]>
Date: Tue, 12 Mar 2019 11:54:44 -0400

> On Mar 12, 2019, at 10:39, Valery Smyslov <[email-masked]> wrote:
> 
> Hi Chris,
> 

Perhaps we could relax this requirement for this particular message though. This seems like a simple tightly-focused semantic change which gets us past the roadblock. 

FWIW, regarding retransmission and message IDs, one thing I considered was not even using the message ID at all  (e.g., let it be 0)  but this seemed too radical as a first approach. :)

If there really is no way to work around this, I suppose we just require retransmissions of CC info reports until they are ACKd or things are torn down b/c of drops (i.e., normal INFO exchange). It does feel like we are adding fragility here that isn’t really needed though. It makes the functioning of the unidirectional tunnel depend more heavily on the reverse direction traffic working when that isn’t actually needed for the tunnel to operate.

Thanks,
Chris.

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 14 Mar 2019 11:34:01 +0300

> Perhaps we could relax this requirement for this particular message though. This seems like a simple tightly-
> focused semantic change which gets us past the roadblock.

No, we cannot. Retransmissions are sent when no response is received. You don't know whether request 
or response was lost. If you retransmit packet not equal to original, then you don't know which
packet the responder received - first or second. I guess in your case you don't care, but in general it's not appropriate.

> FWIW, regarding retransmission and message IDs, one thing I considered was not even using the message ID
> at all  (e.g., let it be 0)  but this seemed too radical as a first approach. :)
> 
> If there really is no way to work around this, I suppose we just require retransmissions of CC info reports until
> they are ACKd or things are torn down b/c of drops (i.e., normal INFO exchange). It does feel like we are
> adding fragility here that isn’t really needed though. It makes the functioning of the unidirectional tunnel
> depend more heavily on the reverse direction traffic working when that isn’t actually needed for the tunnel to
> operate.

Yes, don't break IKE core things.

Regards,
Valery.

---

From: Christian Hopps <[email-masked]>
Date: Thu, 14 Mar 2019 05:37:44 -0400

> Yes, don't break IKE core things.

I was hoping there would be an openness to possible improvements, and wasn't looking to just break well established protocols. An earlier mail from Paul made it sound like other use-cases have wanted for expanded functionality as well.

This isn't a blocker for this work, so if other people agree that it's not worth trying to improve IKE to support this use case, we can just conform rather than try to improve things.

Thanks,
Chris.

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 29 Mar 2019 09:14:27 +0300

Hi Christian,

having think a bit more about reassembling on a receiving side,
I think that there may be some issues. You rely on ESP SN to 
properly reassemble the IP packets, but there is at least one
case when it doesn't work - when IPsec protects multicast traffic
and there are several senders in SA. In this case SN will repeat,
so your reassembling mechanism won't work (well, there is
no any replay protection in this case too).

And I really want to make reassembling feature optional
and negotiable.

Regards,
Valery.

> presentation slot from the chairs for the upcoming ipsecme WG meeting @
> IETF 104, and will hopefully be able to present this work at that time as
well.
> > Please note that it may take a couple of minutes from the time of
> > submission until the htmlized version and diff are available at
tools.ietf.org.
> > Internet-Draft directories: http://www.ietf.org/shadow.html or
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Graham Bartlett (grbartle)" <[email-masked]>
Date: Fri, 29 Mar 2019 09:54:15 +0000

Hi Chris

Thanks for the presentation yesterday.

I have been thinking about traffic with different DSCP markings.

e.g if I have voice, video and web traffic (with their configured DSCP), it looks like all three flows could be sent in a single encrypted payload and the DSCP marking in the outer header is ignored.

How do you look to address the challenges that this will bring with regards to traffic prioritisation ?

Many thanks

On 11/03/2019, 14:33, "IPsec on behalf of Christian Hopps" <[email-masked] on behalf of [email-masked]> wrote:

    Hi ipsecme folks,

    Thanks,
    Chris.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 29 Mar 2019 11:13:31 +0100

> On Mar 14, 2019, at 10:37, Christian Hopps <[email-masked]> wrote:
> 
> 

Just to clarify. It is not that people are not open minded, but that the suggested change technically cannot work due to the base model of how IKEv2 works. The way msgid handling is specified in the core spec cannot support uni-directional behaviour even if we all wanted to add it. And even the current handling has some issues we must clarify in future drafts without the addition of uni-directionality. It is too complicated already. Supporting uni-directionality would mean creating IKEv2.1 or IKEv3, which would be years of efforts.

Paul

---

From: Christian Hopps <[email-masked]>
Date: Fri, 29 Mar 2019 11:25:22 +0100

> Just to clarify. It is not that people are not open minded, but that the suggested change technically cannot work due to the base model of how IKEv2 works. The way msgid handling is specified in th…

Indeed.

Based on some discussions with folks prior and during the meeting it seems like we may have non-IKE options as well.

Thanks,
Chris.

---

From: Christian Hopps <[email-masked]>
Date: Fri, 29 Mar 2019 11:35:02 +0100

Hi Graham,

This is a good question. We currently indicate it's a local configuration decision, but we may want to go deeper into possible options in the draft.

Right now we see 3 options:

- A static configured value for the SA
- Inherit the "best" value from the encapsulated traffic.
- Inherit the "worst" value from the encapsulated traffic.

Thanks,
Chris.

---

From: "Graham Bartlett (grbartle)" <[email-masked]>
Date: Fri, 29 Mar 2019 12:16:18 +0000

Hi Chris

Sorry, I meant to catch you yesterday, but had to leave.

I see this as a really hard problem to solve (and don't have a solution).

The issue is, if you're mixing different traffic into an encrypted payload then there's a very good chance your inner flows are going to start becoming out of order when they are sent encapsulated.

So for a mix of DSCP traffic I see the following occurring;

> priority queuing of traffic of priority traffic flows doesn't occur when it's encrypted as everything is sharing the same DSCP

>low priority traffic gets a free ride if it's bundled with traffic of high priority     

>high priority traffic gets a downgrade when it's bundled with low priority traffic

I'd be interested to see testing with various traffic flows and traffic that requires some form of quality of service. I've seen similar solutions break real time traffic.

cheers

On 29/03/2019, 10:35, "Christian Hopps" <[email-masked]> wrote:

    Hi Graham,

    
    
    Thanks,
    Chris.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 30 Mar 2019 17:10:36 +0100

> The issue is, if you're mixing different traffic into an encrypted
    > payload then there's a very good chance your inner flows are going to
    > start becoming out of order when they are sent encapsulated.

Can you explain why this is an issue?

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

---

From: Michael Richardson <[email-masked]>
Date: Sat, 30 Mar 2019 17:09:32 +0100

Christian Hopps <[email-masked]> wrote:
    > This is a good question. We currently indicate it's a local
    > configuration decision, but we may want to go deeper into possible
    > options in the draft.

    > - Inherit the "best" value from the encapsulated traffic.

The DSCP value is only meaningful within an AS.  
The end points of the tunnel and the outside of the tunnel are really
different diffserv domains.
The ECN markings are in the same byte, and we do things with that, but
that's not the DSCP.

Changing the DSCP would seem to enable traffic analysis.

As TFS needs to do congestion control, I think that the ECN markings should
be used by TFS, and TFS should do ECN markings upon entry/exit of the tunnel
itself, after some processing itself.  It might mark congestion seen more
often than the outside of the tunnel sees if it needs the users of the tunnel
to back down because they are exceeding the allocation.

It might also ignore congestion if the congestion is due to the extra traffic.

So I think that the DSCP needs to be configured appropriately for the AS
that is sending the packets.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 30 Mar 2019 17:03:13 +0100

Valery Smyslov <[email-masked]> wrote:
    > having think a bit more about reassembling on a receiving side, I think
    > that there may be some issues. You rely on ESP SN to properly
    > reassemble the IP packets, but there is at least one case when it
    > doesn't work - when IPsec protects multicast traffic and there are

I don't think it is useful to run tfs for multicast traffic.

    > And I really want to make reassembling feature optional and negotiable.

It seems to me that the receiver has to indicate that it supports it or not,
(just like we do for compression), and the sender either uses it or does not.

---

From: Christian Hopps <[email-masked]>
Date: Sun, 31 Mar 2019 01:56:27 -0400

> (just like we do for compression), and the sender either uses it or does not.

This seems like a good solution.

Thanks,
Chris.

---

From: "Graham Bartlett (grbartle)" <[email-masked]>
Date: Sun, 31 Mar 2019 22:06:35 +0000

Hi Michael

>From my limited experience the performance of many applications is degraded when traffic is received out of order.

cheers

On 31/03/2019, 02:37, "IPsec on behalf of Michael Richardson" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Michael Richardson <[email-masked]>
Date: Sun, 31 Mar 2019 19:27:27 -0400

Graham Bartlett (grbartle) <[email-masked]> wrote:
    > From my limited experience the performance of many applications is
    > degraded when traffic is received out of order.

If the flows are marked differently, then they are from different
applications, so it does not matter.

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