Subject: [IPsec] I-D Action: draft-ietf-ipsecme-iptfs-12.txt

From: [email-masked]
Date: Mon, 08 Nov 2021 05:33:06 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF.

        Title           : IP-TFS: Aggregation and Fragmentation Mode for ESP and its Use for IP Traffic Flow Security
        Author          : Christian Hopps
	Filename        : draft-ietf-ipsecme-iptfs-12.txt
	Pages           : 31
	Date            : 2021-11-08

Abstract:
   This document describes a mechanism for aggregation and fragmentation
   of IP packets when they are being encapsulated in ESP payload.  This
   new payload type can be used for various purposes such as decreasing
   encapsulation overhead for small IP packets; however, the focus in
   this document is to enhance IPsec traffic flow security (IP-TFS) by
   adding Traffic Flow Confidentiality (TFC) to encrypted IP
   encapsulated traffic.  TFC 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 as non-
   constant send-rate usage.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-iptfs-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-iptfs-12

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Paul Wouters <[email-masked]>
Date: Mon, 8 Nov 2021 13:16:25 -0500 (EST)

> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-iptfs-12

Looks good to me other than a typo:  s/the they fall/they fall/

(but we can let the RFC editor fix that one without issuing a new draft)

Paul

---

From: Michael Richardson <[email-masked]>
Date: Mon, 08 Nov 2021 18:00:27 -0500

I've read the diff, and it looks good to me.
--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Christian Hopps <[email-masked]>
Date: Mon, 08 Nov 2021 23:02:32 -0500

> (but we can let the RFC editor fix that one without issuing a new draft)

Thanks, I've made the update locally to keep track of it as well.

Also, Yoav flagged "is comprised of" to me off-list, so I locally changed those to "consists of". There's a subgroup of language experts that really don't like people to use "is comprised of". :)

Thanks,
Chris.

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

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 9 Nov 2021 12:11:24 +0200

> 	Filename        : draft-ietf-ipsecme-iptfs-12.txt

I checked the diffs, and I think this text is mostly ok.

I think there is still bit of tweaking that can be done, mostly as
what happens if using the 2nd option and the frame appears after the
lost timer, but inside the reorder window.

My understanding is that it would still be good idea to process that
frame, but there is text which says "Using this method will make sure
the packets are sent in-order, i.e., there is no reordering possible,
...", and that would indicate that we must drop that frame that comes
after the lost timer expire, but inside the reorder window, as if we
process it after the lost timer has expired this may cause inner
packets sent out of order.

The question really is do we want really make sure there can not be
reorderings on the 2nd option, i.e., we will drop all frames that
would send reordered inner frames?

In that case the reorder window size does not have any meaning if we
have loss timer defined.

On the other hand having small lost timer, but bigger reorder window
would allow fixing localized reorderings (i.e., like getting two outer
frames almost back to back, but in wrong order), but still not throw
away frames that come in too late.

To allow that we could simply change text to "Using this method will
make sure the packets are sent in-order as much is possible, ...".

Ps. Other option is to allow that kind of localized reorderings is to
add that option to 1st option, i.e., add sentence to the end of 1st
paragraph saying "The receiver MAY also have reordering timer, so that
when out of order outer packet comes in, the receiver waits for this
reordering timer to see if new packets comes during that time, and if
so it can reorder the frames before processing them.", but on the
other hand I do not think anything in the 1st option forbids doing
that anyways, so I do not think we need such text.
-- 
[email-masked]

---

From: Christian Hopps <[email-masked]>
Date: Tue, 09 Nov 2021 06:49:55 -0500

I believe this is a good time to apply KISS method.

We have a lost packet timer and additionally this is the "in order delivery" mode. Let's not make this more complex to try and eek out every ounce of potential, especially given we are already documenting 2 possible receiver behaviors (instead of 1 recommended one) specifically b/c we need to gain more experience for what affects they have on the inner traffic and various applications.

Please also consider this from the perspective of congestion control. When a packet is considered lost it will trigger various actions in the congestion control algorithms.

Let's just keep lost packets lost for now.

Thanks,
Chris.

---

From: Lou Berger <[email-masked]>
Date: Fri, 12 Nov 2021 10:05:05 -0500

Hi Tero,

You said:

On 11/9/2021 5:11 AM, Tero Kivinen wrote:
> I think there is still bit of tweaking that can be done,

Is this tweak being made as a blocking comment by the document Shepherd 
or a non-blocking comment as a contributor?

If it's a blocking comment -- Sure let's make whatever change you want 
(as long as long as the rest of the WG can live with the change/doesn't 
break anything)  so we can get this document out of the WG.

If as contributor -- can you live with the current text?  It would be 
great to get the document set to the IESG as discussed this week.

Thank you!

Lou

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 12 Nov 2021 07:20:53 -0800

> break anything)  so we can get this document out of the WG.

And to follow up, "out of the WG" doesn't mean "done and finalized" --
these are topics that I mostly expect to get more feedback on during the
IETF last call.  So we may want to go forward with what we have and polish
the text with involvement from the broader (e.g., transport) community.

> great to get the document set to the IESG as discussed this week.

Full disclosure: my queue is a little backed up at the moment, and if I go
in FIFO order it is likely to take a few weeks to clear that.  But that's
not a reason to wait, as there are a couple other documents from other WGs
that are about to enter the queue as well.

-Ben

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 12 Nov 2021 22:31:07 +0200

> or a non-blocking comment as a contributor?

No. It is just a comment.

> break anything)  so we can get this document out of the WG.

The new version was posted on Monday, I will wait for at least a week to
allow people to read the document and send their comments to list
before I send document forward.

During that time I hope to get the yang and mib documents also in a
shape where they can be put forward at the same time (both of those
documents do have some issues that I noticed during my shepherd
review, and at least the MIB document missing IANA considerations
section is blocking).

> great to get the document set to the IESG as discussed this week.

I can live with the current text, I will assume there will be more
comments to this during the IETF last call or IESG review time, but I
will not be sending it to IESG this week, I will do it next week (most
likely on Thursday as I have full schedule (16:00-04:00) on
Monday-Wednesday as IEEE still continues until that).
-- 
[email-masked]