Aggregation and Fragmentation Mode for Encapsulating Security Payload (ESP) and Its Use for IP Traffic Flow Security (IP-TFS)
draft-ietf-ipsecme-iptfs-19

[Ballot comment]
# GEN AD review of draft-ietf-ipsecme-iptfs-14

CC @larseggert

Thanks to Peter E. Yee for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/VKlfYh3uoGomO4_Lv8e6kltl36g).

## Comments

### Section 2, paragraph 0
```
  2.  The AGGFRAG Tunnel
```
This description in this section doesn't seem to accurately reflect the
availability of a congestion-controlled mode of operation, it's only about CBR.

### Section 2.2.3.1, paragraph 1
```
    When the tunnel bandwidth is not being fully utilized, a sender MAY
    pad-out the current encapsulating packet in order to deliver an inner
    packet un-fragmented in the following outer packet.  The benefit
```
If this MAY is not followed, the tunnel isn't a CBR tunnel anymore. Permitting
that seems to contradict one of the main premises of this approach?

### Section 2.2.5.2, paragraph 0
```
  2.2.5.2.  ECN value
```
RFC6040 has updated the guidance in RFC4301 for ECN (see above, too.)

### Section 2.4.2, paragraph 1
```
    The required inputs for the TCP friendly rate control algorithm
    described in [RFC5348] are the receiver's loss event rate and the
    sender's estimated round-trip time (RTT).  These values are provided
    by IP-TFS using the congestion information header fields described in
    Section 3.  In particular, these values are sufficient to implement
    the algorithm described in [RFC5348].
```
RFC5348 like most IETF congestion control mechanisms are sender-side. Is there a
good reason to flip this around and do the computation on the receiver, which
complicates the actual use of RFC5348?

### Section 2.4.2, paragraph 2
```
    the available tunnel bandwidth.  An implementation choosing to always
    send the data MAY also choose to only update the LossEventRate and
    RTT header field values it sends every RTT though.
```
Why? Sending known stale data is worse than not sending any data.

### Section 4.1, paragraph 1
```
    Bandwidth is a local configuration option.  For non-congestion-
    controlled mode, the bandwidth SHOULD be configured.  For congestion-
    controlled mode, the bandwidth can be configured or the congestion
    control algorithm discovers and uses the maximum bandwidth available.
    No standardized configuration method is required.
```
For congestion-controlled mode, what is the point of configuring bandwidth? The
CC algorithm will not use this at all.

### Section 4.3, paragraph 1
```
    Congestion control is a local configuration option.  No standardized
    configuration method is required.
```
I don't understand what this is supposed to express?

### Section 6.1.2, paragraph 8
```
    E:
        A 1-bit value that if set indicates that Congestion Experienced
        (CE) ECN bits were received and used in deriving the reported
        LossEventRate.
```
What is the reason for signaling this? CC does not depend on this.

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term `traditional`; alternatives might be `classic`, `classical`, `common`,
  `conventional`, `customary`, `fixed`, `habitual`, `historic`,
  `long-established`, `popular`, `prescribed`, `regular`, `rooted`,
  `time-honored`, `universal`, `widely used`, `widespread`
* Term `native`; alternatives might be `built-in`, `fundamental`, `ingrained`,
  `intrinsic`, `original`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Section 2.4.2, paragraph 1
```
    practice RECOMMENDS that the algorithm conform to [RFC5348].
```
"RECOMMENDS" is not an RFC2119 keyword.

### Grammar/style

#### Section 2.2.3, paragraph 5
```
mbers will not work for this document so the sequence number stream MUST incr
                                    ^^^
```
Use a comma before "so" if it connects two independent clauses (unless they are
closely connected and short).

#### Section 2.2.3, paragraph 5
```
w sizes. This is because packets outside of the smaller window but inside the
                                ^^^^^^^^^^
```
This phrase is redundant. Consider using "outside".

#### Section 2.2.3.1, paragraph 3
```
load is called an empty payload. Currently this situation is only applicable
                                ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Currently".

#### Section 2.2.3.1, paragraph 4
```
[RFC4301], AGGFRAG mode may and often will be encapsulating more than one IP
                                ^^^^^^^^^^^^^
```
The adverb "often" is usually put between "will" and "be".

#### Section 2.2.7, paragraph 1
```
e tunnel will take. This is required so the user can guarantee the bandwidth
                                    ^^^
```
Use a comma before "so" if it connects two independent clauses (unless they are
closely connected and short).

#### Section 2.5, paragraph 3
```
to have a round-trip time estimate. Thus the sender communicates this estimat
                                    ^^^^
```
A comma may be missing after the conjunctive/linking adverb "Thus".

#### Section 6.1.1, paragraph 7
```
value of zero indicates no loss. Otherwise the loss event rate is 1/LossEven
                                ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Otherwise".

#### Section 6.1.3.3, paragraph 3
```
ffecting network congestion in a predictable way, and if it would be, then n
                            ^^^^^^^^^^^^^^^^^^^^
```
Consider replacing this phrase with the adverb "predictably" to avoid
wordiness.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot comment]
Thanks for addressing my discuss points. The resolution looks good.

However, I have small regret that the following comments were not addressed which I believe would add more clarity to the specification.

# Section 2.4: I would like to have rational behind the two mode of operations. what are the pros and cons and when would an implementer select one over another? if this is written somewhere else then having a point would be great benefit.

# Section 2.4.1: The failure correction due to the expected bandwidth under estimation, where loss seems to be an indication, seems like a serious matter and but still there is no normative language requirements on the reporting the loss. I wonder how useful this could be. If the reporting is that important to have a note in this specification then it is better to use normative langues to enforce it.

[Ballot comment]
# Éric Vyncke, INT AD, comments for draft-ietf-ipsecme-iptfs-13
CC @evyncke

Thank you for the work put into this document and the quick reactions on my original DISCUSS ballot on -14. Having a proper IP protocol number is the right way to proceed. I am still uneasy with the ICMP text though, but not to point of blocking this document any further.

I have now cleared my DISCUSS. I was about to ballot ABSTAIN because I am still concerned about the ICMP processing, about not specifying a generic tunnel rather than something specific to IPsec, but this does not fit the ABSTAIN per https://www.ietf.org/standards/process/iesg-ballots/, hence my no objection.

My previous COMMENTS are still there as most of them have not been replied/addressed AFAIK, this is non blocking, but the intent of those COMMENTS is to improve the document quality.

The same applies for Antoine Fressancourt’s review https://mailarchive.ietf.org/arch/msg/ipsec/4u9zP9mkITwUWPfjPBg_abo4r54/ A reply by the authors will also be welcome.

Please find below *for archiving only* my DISCUSS points, some non-blocking COMMENT points, and some nits.

Special thanks to Tero Kivinen for the shepherd's detailed write-up including the WG consensus, alas the justification of the intended status is missing :-(

Please note that Tatuya Jinmei is the Internet directorate reviewer (at my request) and you may want to consider this int-dir review as well:
https://datatracker.ietf.org/doc/review-ietf-ipsecme-iptfs-13-intdir-telechat-jinmei-2022-08-18/

I hope that this review helps to improve the document,

Regards,

-éric


## Previous DISCUSS kept for archiving

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

### Section 6.1

```
  An AGGFRAG payload is identified by the ESP Next Header value
  AGGFRAG_PAYLOAD which has the value 0x5.  The value 5 was chosen to
  not conflict with other used values.  The first octet of this payload
  indicates the format of the remaining payload data.
```
This is in direct conflict with RFC 4303 (see below) IMHO as 5 is already allocated to ST (RFC 1819, which is still 'current' even if it was never used).

But ESP RFC 4303 section 2.6 says that this is an IP protocol number (and 5 is already allocated by the IANA):
```
  The Next Header is a mandatory, 8-bit field that identifies the type
  of data contained in the Payload Data field, e.g., an IPv4 or IPv6
  packet, or a next layer header and data.  The value of this field is
  chosen from the set of IP Protocol Numbers defined on the web page of
  the IANA, e.g., a value of 4 indicates IPv4, a value of 41 indicates
  IPv6, and a value of 6 indicates TCP.
```

I.e., either this document needs to formally update RFC 4303 by allowing any number or another IP protocol number must be requested to the IANA.


### Section 2.1, generic tunnel capability

```
  Other non-IP-TFS uses of this AGGFRAG mode have been suggested, such
  as increased performance through packet aggregation, as well as
  handling MTU issues using fragmentation.  These uses are not defined
  here, but are also not restricted by this document.
```

Moreover, while IPSECme charter includes:
```
The demand for Traffic Flow Confidentiality has been increasing in the user
community, but the current method defined in RFC4303 (adding null
padding to each ESP payload) is very inefficient in its use of network
resources. The working group will develop an alternative TFC solution that
uses network resources more efficiently.
```
it says nothing about a generic tunnelling protocol, which is usually INTAREA topic, and I cannot refrain from thinking that this tunnelling mechanism could be used on any connection-less transport, e.g., UDP or IP.

Hence, this DISCUSS point is only to initiate a discussion with IPSECME chairs and AD; Christian Hopps has already given some explanations when I deferred this I-D. I understand that I am in the rough here (no reaction on int-area and int-dir review is positive).


### Section 2.2.6

Please also mention hop-limit and RFC 8200.

### Absence of ICMP considerations

Should there be an equivalent of section 6 of RFC 4301 about ICMP ? As several unprotected packets can be bundled together, some guidance to the implementers will be welcome.

## COMMENTS

### Yet another fragmentation above layer 3

No need to reply on this comment, but I cannot refrain from wondering how many fragmentation mechanisms above layer 3 have been specified by the IETF... We could end up running this specification over IPsec over TCP ;-)

### draft-templin-intarea-parcels

Are the authors/WG aware of draft-templin-intarea-parcels ? This draft was not adopted by intarea (lack of interest mainly) but also aggregates packets into "parcels".

Christian has already replied to this comment when I deferred the IESG evaluation. This is only kept for archiving.

### Section 1

s/(indicated using protocol 59)/(indicated using IP protocol 59)/ ?

### Section 2.1

```
  Padding is only added
  to the tunnel packets if there is no data available to be sent at the
  time of tunnel packet transmission, or if fragmentation has been
  disabled by the receiver.
```

The reader will welcome explanation about why a receiver disabling fragmentation is influencing padding at the sender side.

### Section 2.2

As ESP next header expects an IP protocol number and this one should probably be an IPv6 extension header, then the format proposed on figure 1 does not fit the usual extension header format. Did the authors analyze the potential use of the usual IPv6 extension header ? (at the expense of wasting bytes of course...)

### Section 2.2 dual-stack blocks ?

Should there be a note about having a mix of IPv4 and IPv6 data blocks inside a single payload ?

### Section 2.2.5.1

Please add text about this section being IPv4-only as IPv6 header does not have a DF bit.

Is there a recommended value for the DF bit for IPv4 outer headers ?


## NITS

### Section 1

```
  While directly
  obscuring the data with encryption [RFC4303], fully, the patterns in
  the message traffic may expose information due to variations in its
  shape and timing ([RFC8546], [AppCrypt]).
```

Possible wrong places for ',' around 'fully' ?

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot comment]
[ Chat with Christian Hopps on the telechat -- I explained my concerns and Christian will add some text around how to deploy this safely / some background context. Even if you are the network admin and in complete control of the network, having some "here are some things to keep in mind when deploying, like that that will ALWAYS use the configured bandwidth so make sure you will always have that free during failures and congestion and things like that..." type warnings are helpful. ]

Clearing my discuss.


Much thanks to Bo Wu for the OpsDir review, and to the authors for addressing / incorporating the comments.

[Ballot comment]
The first question of the shepherd writeup was not completely answered.  Question 18, which is particularly relevant here, was not answered at all.

Section 7.1 creates an IANA registry with "Expert Review" rules.  Of such a registry, Section 4.5 of RFC 8126 says, among other things:

  The required documentation and review criteria, giving clear guidance
  to the designated expert, should be provided when defining the
  registry.

This document doesn't do so.  After discussion, I'm told this is typical for IPSec registries; it's just understood that whoever might be assigned as a DE for this new registry will have the knowledge, context, and vision to do a good job.  I have some broad concerns about how much our succession planning in general needs improvement, and I think this sort of thing is one aspect of that problem.  I urge the WG and the AD to give this some more thought.

Thanks for including Section 8.  This is always helpful to read.

[Ballot discuss]
[ Chat with Christian Hopps on the telechat -- I explained my concerns and Christian will add some text around how to deploy this safely / some background context. Even if you are the network admin and in complete control of the network, having some "here are some things to keep in mind when deploying, like that that will ALWAYS use the configured bandwidth so make sure you will always have that free during failures and congestion and things like that..." type warnings are helpful. ]

Clearing my discuss.

[Ballot comment]
Nit:

I just happened to notice this bit in the Intro:

"While directly
  obscuring the data with encryption [RFC4303], fully"

There seem to be words missing before "fully"?

[Ballot discuss]
Thanks for working on this specification. I found this spec to be a mix of transport and non-transport related topics and had to think a bit more due to lack of rational behind choices made.

I would like to discuss - why there is no normative text (MUST/MUST NOT) for non-congestion controlled mode over operation in this specification that prohibits the use of non-congestion controlled mode out side of controlled environment?

I am also supporting Lars's discuss on 3.1 ECN support.

[Ballot comment]
The version of this specification changed quite frequently during the telechat review period, hence I am mentioning that I am reviewing the -17th version of this specification.

I have following comments, which I believe will improve the specification if properly addressed -

# Section 2.4: I would like to have rational behind the two mode of operations. what are the pros and cons and when would an implementer select one over another? if this is written somewhere else then having a point would be great benefit.

# Section 2.4.1: I believe the assumption here is that the network is fully provisioned and no congestion related loss should occur hence here would not need to react to any loss. what would be source of the potential loss then? link failure only? if the loss is due to underestimation of bandwidth then 8084 need to be implemented as a last resort. It actually talks about circuit breakers in section 2.4.2.1 and somehow managed to say in addition to congestion control, the implementation that support non-congestion control mode should implement circuit breaker. This is where I am a bit lost, why is this written in section 2.4.2.1 and not in 2.4.1? is this the assumption that the implementation that have non-congestion control mode would not have congestion control mode? 

The failure correction due to the expected bandwidth under, where loss seems to be an indication, seems like a serious matter and but still there is no normative language requirements on the reporting the loss. I wonder how useful this could be.

The last line actually makes me more confused. If ESP over TCP is in use then TCP would trigger the congestion control, thus this becomes a congestion controlled case and yes, you can then perhaps send out packets without thinking about congestion collapse. But then the assumption changes, then it becomes the case IP-TFS is expected to run over a congestion controlled transport. however, that is not the general assumption for the whole non-congestion controlled mode of operation. Here, I think we need to clarify a bit more on how to interpret the non-congestion controlled mode description.

[Ballot discuss]
Section 7.1 creates an IANA registry with "Expert Review" rules.  Of such a registry, Section 4.5 of RFC 8126 says, among other things:

  The required documentation and review criteria, giving clear guidance
  to the designated expert, should be provided when defining the
  registry.

This document doesn't do so.  Is that guidance available somewhere else, or should some be added here?

[Ballot comment]
The first question of the shepherd writeup was not completely answered.  Question 18, which is particularly relevant here, was not answered at all.

Thanks for including Section 8.  This is always helpful to read.

[Ballot discuss]
## Discuss

### S6.1

* I think this document should get a separate protocol value from the IANA
  "Protocol Numbers" registry, since that's where 4303 S2.6 clearly says they
  values come from.

  The "value of 41 indicates IPv6" makes it pretty clear where this field
  gets its values from.

  https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml

[Ballot discuss]
I supporting Lars' DISCUSS points, especially that around Section 2.4.1, paragraph 3:
  The packet send
  rate is constant and is not automatically adjusted regardless of any
  network congestion (e.g., packet loss).

  For similar reasons as given in [RFC7510] the non-congestion-
  controlled mode should only be used where the user has full
  administrative control over the path the tunnel will take.  This is
  required so the user can guarantee the bandwidth and also be sure as
  to not be negatively affecting network congestion [RFC2914].  In this
  case, packet loss should be reported to the administrator (e.g., via
  syslog, YANG notification, SNMP traps, etc.) so that any failures due
  to a lack of bandwidth can be corrected.

This is a largely unrealistic requirement -- unless you are specifically meaning "a bump-in-the-wire deployment over a point to point link" users fairly much never have control over the path that the tunnel will take. At some point the primary path **will** go down, and the tunnel will route over some backup path, most likely at 3AM on the Sunday that the CEO's daughter is getting married...

It what you are describing really is "only ever use this as a bump-in-the-wire over a PtP interface" or "make sure that the configured bandwidth is many many magnitudes smaller than the smallest link in the network, even when congested", then please state that instead. As written, this text seems dangerous: you are basically handing an enterprise network admin a DoS cannon and washing your hands of the consequences.

[Ballot discuss]
I am strongly supporting Lars' DISCUSS points (actually, enough that I decided to ballot discuss too), especially that around Section 2.4.1, paragraph 3:
  The packet send
  rate is constant and is not automatically adjusted regardless of any
  network congestion (e.g., packet loss).

  For similar reasons as given in [RFC7510] the non-congestion-
  controlled mode should only be used where the user has full
  administrative control over the path the tunnel will take.  This is
  required so the user can guarantee the bandwidth and also be sure as
  to not be negatively affecting network congestion [RFC2914].  In this
  case, packet loss should be reported to the administrator (e.g., via
  syslog, YANG notification, SNMP traps, etc.) so that any failures due
  to a lack of bandwidth can be corrected.

This is a largely unrealistic requirement -- unless you are specifically meaning "a bump-in-the-wire deployment over a point to point link" users fairly much never have control over the path that the tunnel will take. At some point the primary path **will** go down, and the tunnel will route over some backup path, most likely at 3AM on the Sunday that the CEO's daughter is getting married...

It what you are describing really is "only ever use this as a bump-in-the-wire over a PtP interface" or "make sure that the configured bandwidth is many many magnitudes smaller than the smallest link in the network, even when congested", then please state that instead. As written, this text seems dangerous: you are basically handing an enterprise network admin a DoS cannon and washing your hands of the consequences.

[Ballot comment]
# Security AD review of draft-ietf-ipsecme-iptfs-14

CC @paulwouters

## COMMENTS

### users don't implement?

  A good choice
  for the size of this window depends on the amount of misordering the
  user may normally experience.

This sentence does not help the implementer, nor the user. Users only experience "works well", "is slow", "does not work" :P

### tunnel vs SA

  2.4.  Modes of Operation

  Just as with normal IPsec/ESP tunnels, AGGFRAG tunnels are
  unidirectional.  Bidirectional IP-TFS functionality is achieved by
  setting up 2 AGGFRAG tunnels, one in either direction.

  An AGGFRAG tunnel used for IP-TFS can operate in 2 modes, a non-
  congestion-controlled mode and congestion-controlled mode.

Do you mean to say IPsec SA's are unidirectional? Because when you talk
about a "tunnel", that to me feels bidirectional so it reads as if you
need two IPsec tunnels (eg 4 IPsec SAs) but I think you mean to say that
the inbound and outbound IPsec SA both need to enable AGGFRAG. That is,
you need to decide on whether an "AGGFRAG tunnel" is a set of two IPsec SAs
or not and then use the term consistently. Or perhaps call it an
"AGGFRAG IPsec SA" ?

[Ballot discuss]
# GEN AD review of draft-ietf-ipsecme-iptfs-14

CC @larseggert

Thanks to Peter E. Yee for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/VKlfYh3uoGomO4_Lv8e6kltl36g).

## Discuss

### Section 2.4.1, paragraph 3
```
    For similar reasons as given in [RFC7510] the non-congestion-
    controlled mode should only be used where the user has full
    administrative control over the path the tunnel will take.  This is
    required so the user can guarantee the bandwidth and also be sure as
    to not be negatively affecting network congestion [RFC2914].  In this
    case, packet loss should be reported to the administrator (e.g., via
    syslog, YANG notification, SNMP traps, etc.) so that any failures due
    to a lack of bandwidth can be corrected.
```
There is a lot more nuance and there are a lot more restrictions in RFC7510 that
also apply here. If a non-congestion-controlled mode is desired, especially
without even using RFC8084 circuit breakers, similar mandatory text needs to be
crafted for this mechanism. (I would also strongly suggest to require circuit
breakers here.)

### Section 2.4.2, paragraph 0
```
  2.4.2.  Congestion-Controlled Mode
```
This mode adds a LOT of complexity to this mechanism. Is this really needed?
Could not RFC8229 be used instead of defining an entirely separate congestion
control scheme for (padded/fragmented) ESP?

### Section 2.4.2.1, paragraph 1
```
    In additional to congestion control, implementations MAY choose to
    define and implement circuit breakers [RFC8084] as a recovery method
    of last resort.  Enabling circuit breakers is also a reason a user
    may wish to enable congestion information reports even when using the
    non-congestion-controlled mode of operation.
```
This makes no sense. If implemented in addition to CC, circuit breakers will
never fire, because a functioning congestion control algorithm will always
maintain a send rate below the circuit breaker threshold.

What would make sense is to use circuit breakers in the
non-congestion-controlled case, to provide a safety mechanism in cases the
network provisioning changes for an active tunnel.

### Section 3.1, paragraph 0
```
  3.1.  ECN Support
```
There is a lot more nuance to this, as described in RC6040. This document needs
to follow that existing standard rather than define another variant.

### Section 6.1.2, paragraph 9
```
    RTT:
        A 22-bit value specifying the sender's current round-trip time
        estimate in microseconds.  The value MAY be zero prior to the
        sender having calculated a round-trip time estimate.  The value
        SHOULD be set to zero on non-AGGFRAG_PAYLOAD-enabled SAs.  If the
        RTT is equal to or larger than 0x3FFFFF the value MUST be set to
        0x3FFFFF.
```
This can only encode RTTs of up to around four seconds. That is too little for
Internet usage. (Same concern about other 22-bit microsecond values below.)

[Ballot comment]
## Comments

### Section 2, paragraph 0
```
  2.  The AGGFRAG Tunnel
```
This description in this section doesn't seem to accurately reflect the
availability of a congestion-controlled mode of operation, it's only about CBR.

### Section 2.2.3.1, paragraph 1
```
    When the tunnel bandwidth is not being fully utilized, a sender MAY
    pad-out the current encapsulating packet in order to deliver an inner
    packet un-fragmented in the following outer packet.  The benefit
```
If this MAY is not followed, the tunnel isn't a CBR tunnel anymore. Permitting
that seems to contradict one of the main premises of this approach?

### Section 2.2.5.2, paragraph 0
```
  2.2.5.2.  ECN value
```
RFC6040 has updated the guidance in RFC4301 for ECN (see above, too.)

### Section 2.4.2, paragraph 1
```
    The required inputs for the TCP friendly rate control algorithm
    described in [RFC5348] are the receiver's loss event rate and the
    sender's estimated round-trip time (RTT).  These values are provided
    by IP-TFS using the congestion information header fields described in
    Section 3.  In particular, these values are sufficient to implement
    the algorithm described in [RFC5348].
```
RFC5348 like most IETF congestion control mechanisms are sender-side. Is there a
good reason to flip this around and do the computation on the receiver, which
complicates the actual use of RFC5348?

### Section 2.4.2, paragraph 2
```
    the available tunnel bandwidth.  An implementation choosing to always
    send the data MAY also choose to only update the LossEventRate and
    RTT header field values it sends every RTT though.
```
Why? Sending known stale data is worse than not sending any data.

### Section 4.1, paragraph 1
```
    Bandwidth is a local configuration option.  For non-congestion-
    controlled mode, the bandwidth SHOULD be configured.  For congestion-
    controlled mode, the bandwidth can be configured or the congestion
    control algorithm discovers and uses the maximum bandwidth available.
    No standardized configuration method is required.
```
For congestion-controlled mode, what is the point of configuring bandwidth? The
CC algorithm will not use this at all.

### Section 4.3, paragraph 1
```
    Congestion control is a local configuration option.  No standardized
    configuration method is required.
```
I don't understand what this is supposed to express?

### Section 6.1.2, paragraph 8
```
    E:
        A 1-bit value that if set indicates that Congestion Experienced
        (CE) ECN bits were received and used in deriving the reported
        LossEventRate.
```
What is the reason for signaling this? CC does not depend on this.

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term `traditional`; alternatives might be `classic`, `classical`, `common`,
  `conventional`, `customary`, `fixed`, `habitual`, `historic`,
  `long-established`, `popular`, `prescribed`, `regular`, `rooted`,
  `time-honored`, `universal`, `widely used`, `widespread`
* Term `native`; alternatives might be `built-in`, `fundamental`, `ingrained`,
  `intrinsic`, `original`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Section 2.4.2, paragraph 1
```
    practice RECOMMENDS that the algorithm conform to [RFC5348].
```
"RECOMMENDS" is not an RFC2119 keyword.

### Grammar/style

#### Section 2.2.3, paragraph 5
```
mbers will not work for this document so the sequence number stream MUST incr
                                    ^^^
```
Use a comma before "so" if it connects two independent clauses (unless they are
closely connected and short).

#### Section 2.2.3, paragraph 5
```
w sizes. This is because packets outside of the smaller window but inside the
                                ^^^^^^^^^^
```
This phrase is redundant. Consider using "outside".

#### Section 2.2.3.1, paragraph 3
```
load is called an empty payload. Currently this situation is only applicable
                                ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Currently".

#### Section 2.2.3.1, paragraph 4
```
[RFC4301], AGGFRAG mode may and often will be encapsulating more than one IP
                                ^^^^^^^^^^^^^
```
The adverb "often" is usually put between "will" and "be".

#### Section 2.2.7, paragraph 1
```
e tunnel will take. This is required so the user can guarantee the bandwidth
                                    ^^^
```
Use a comma before "so" if it connects two independent clauses (unless they are
closely connected and short).

#### Section 2.5, paragraph 3
```
to have a round-trip time estimate. Thus the sender communicates this estimat
                                    ^^^^
```
A comma may be missing after the conjunctive/linking adverb "Thus".

#### Section 6.1.1, paragraph 7
```
value of zero indicates no loss. Otherwise the loss event rate is 1/LossEven
                                ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Otherwise".

#### Section 6.1.3.3, paragraph 3
```
ffecting network congestion in a predictable way, and if it would be, then n
                            ^^^^^^^^^^^^^^^^^^^^
```
Consider replacing this phrase with the adverb "predictably" to avoid
wordiness.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot discuss]
# Éric Vyncke, INT AD, comments for draft-ietf-ipsecme-iptfs-13
CC @evyncke

Thank you for the work put into this document.

Please find below one blocking DISCUSS points, some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Tero Kivinen for the shepherd's detailed write-up including the WG consensus, alas the justification of the intended status is missing :-(

Please note that Tatuya Jinmei is the Internet directorate reviewer (at my request) and you may want to consider this int-dir review as well:
https://datatracker.ietf.org/doc/review-ietf-ipsecme-iptfs-13-intdir-telechat-jinmei-2022-08-18/

I hope that this review helps to improve the document,

Regards,

-éric


## DISCUSS

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

### Section 6.1

```
  An AGGFRAG payload is identified by the ESP Next Header value
  AGGFRAG_PAYLOAD which has the value 0x5.  The value 5 was chosen to
  not conflict with other used values.  The first octet of this payload
  indicates the format of the remaining payload data.
```
This is in direct conflict with RFC 4303 (see below) IMHO as 5 is already allocated to ST (RFC 1819, which is still 'current' even if it was never used).

But ESP RFC 4303 section 2.6 says that this is an IP protocol number (and 5 is already allocated by the IANA):
```
  The Next Header is a mandatory, 8-bit field that identifies the type
  of data contained in the Payload Data field, e.g., an IPv4 or IPv6
  packet, or a next layer header and data.  The value of this field is
  chosen from the set of IP Protocol Numbers defined on the web page of
  the IANA, e.g., a value of 4 indicates IPv4, a value of 41 indicates
  IPv6, and a value of 6 indicates TCP.
```

I.e., either this document needs to formally update RFC 4303 by allowing any number or another IP protocol number must be requested to the IANA.


### Section 2.1, generic tunnel capability

```
  Other non-IP-TFS uses of this AGGFRAG mode have been suggested, such
  as increased performance through packet aggregation, as well as
  handling MTU issues using fragmentation.  These uses are not defined
  here, but are also not restricted by this document.
```

Moreover, while IPSECme charter includes:
```
The demand for Traffic Flow Confidentiality has been increasing in the user
community, but the current method defined in RFC4303 (adding null
padding to each ESP payload) is very inefficient in its use of network
resources. The working group will develop an alternative TFC solution that
uses network resources more efficiently.
```
it says nothing about a generic tunnelling protocol, which is usually INTAREA topic, and I cannot refrain from thinking that this tunnelling mechanism could be used on any connection-less transport, e.g., UDP or IP.

Hence, this DISCUSS point is only to initiate a discussion with IPSECME chairs and AD; Christian Hopps has already given some explanations when I deferred this I-D. I understand that I am in the rough here (no reaction on int-area and int-dir review is positive).


### Section 2.2.6

Please also mention hop-limit and RFC 8200.

### Absence of ICMP considerations

Should there be an equivalent of section 6 of RFC 4301 about ICMP ? As several unprotected packets can be bundled together, some guidance to the implementers will be welcome.

[Ballot comment]

## COMMENTS

### Yet another fragmentation above layer 3

No need to reply on this comment, but I cannot refrain from wondering how many fragmentation mechanisms above layer 3 have been specified by the IETF... We could end up running this specification over IPsec over TCP ;-)

### draft-templin-intarea-parcels

Are the authors/WG aware of draft-templin-intarea-parcels ? This draft was not adopted by intarea (lack of interest mainly) but also aggregates packets into "parcels".

Christian has already replied to this comment when I deferred the IESG evaluation. This is only kept for archiving.

### Section 1

s/(indicated using protocol 59)/(indicated using IP protocol 59)/ ?

### Section 2.1

```
  Padding is only added
  to the tunnel packets if there is no data available to be sent at the
  time of tunnel packet transmission, or if fragmentation has been
  disabled by the receiver.
```

The reader will welcome explanation about why a receiver disabling fragmentation is influencing padding at the sender side.

### Section 2.2

As ESP next header expects an IP protocol number and this one should probably be an IPv6 extension header, then the format proposed on figure 1 does not fit the usual extension header format. Did the authors analyze the potential use of the usual IPv6 extension header ? (at the expense of wasting bytes of course...)

### Section 2.2 dual-stack blocks ?

Should there be a note about having a mix of IPv4 and IPv6 data blocks inside a single payload ?

### Section 2.2.5.1

Please add text about this section being IPv4-only as IPv6 header does not have a DF bit.

Is there a recommended value for the DF bit for IPv4 outer headers ?


## NITS

### Section 1

```
  While directly
  obscuring the data with encryption [RFC4303], fully, the patterns in
  the message traffic may expose information due to variations in its
  shape and timing ([RFC8546], [AppCrypt]).
```

Possible wrong places for ',' around 'fully' ?

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot comment]
Thanks for addressing my DISCUSS.

Thanks to Joe Touch for 2 TSVART reviews, and for addressing his comments. Also thanks for the very literate discussion of congestion control.

(2.2.3) It would be nice to at least suggest a default number for the reordering window. In TCP, we traditionally use 3, but really any suggestion for the clueless is fine.

(3) Please clarify: is TsVal the actual tranmission time, or the time the packet is queued for the next transmission opportunity?

(3) This probably just needs a bit more explanation, but reading this document, and not knowing much about ESP, I could not figure out the case where the return path does not support AGGFRAG_PAYLOAD. IIUC, IKEv2 negotiates this for the pair explicitly, so this case cannot arise. Otherwise, how is this negotiated? Why would a tunnel endpoint support just AGGFRAG without payloads but not with?

NITS
(2.4.1) update the [RFC8229] reference to RFC8229bis?

(6.1) "The value 5 was chosen to not conflict with other used values." IIUC the values here are just Protocol numbers from the registry. So maybe it's better to be more explicit and say that this cannot be used with RFC1819 streams?

[Ballot discuss]
One point which I think will be simple to address:

(6) As malformed packets are sometimes an attack vector, it would be good to specify behavior in response to pathological BlockOffsets, for instance:

- What if two BlockOffset fields disagree? e.g., with 500 byte outer packets, what if the sequence of block offsets is {0, 750, 100}? Does the third packet have 250 or 100 bytes of the first data block? Drop the packet, kill the SA, ignore one and accept the other, or something else?

- What if a pad block is in a packet with a BlockOffset greater than the packet length? Would the receiver skip over the specified bytes in the subsequent packet, even though padding is supposed to only be at the end of packets?

[Ballot comment]
Thanks to Joe Touch for 2 TSVART reviews, and for addressing his comments. Also thanks for the very literate discussion of congestion control.

(2.2.3) It would be nice to at least suggest a default number for the reordering window. In TCP, we traditionally use 3, but really any suggestion for the clueless is fine.

(3) Please clarify: is TsVal the actual tranmission time, or the time the packet is queued for the next transmission opportunity?

(3) This probably just needs a bit more explanation, but reading this document, and not knowing much about ESP, I could not figure out the case where the return path does not support AGGFRAG_PAYLOAD. IIUC, IKEv2 negotiates this for the pair explicitly, so this case cannot arise. Otherwise, how is this negotiated? Why would a tunnel endpoint support just AGGFRAG without payloads but not with?

NITS
(2.4.1) update the [RFC8229] reference to RFC8229bis?

(6.1) "The value 5 was chosen to not conflict with other used values." IIUC the values here are just Protocol numbers from the registry. So maybe it's better to be more explicit and say that this cannot be used with RFC1819 streams?

(BEGIN IANA COMMENTS)

IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-ipsecme-iptfs-12. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, a new registry is to be created called the AGGFRAG_PAYLOAD Sub-Type Registry.

IANA Question --> NOTE: Wherever possible, IANA prefers that the word "Registry" be omitted from registry names, unless doing so will cause confusion. Is "AGGFRAG_PAYLOAD Sub-Types" an acceptable registry name?

The new registry is to be put in a new registry grouping called ESP AGGFRAG_PAYLOAD Parameters.

NOTE: In accordance with current practice, IANA prefers to leave the string "Parameters" out of the name of a new registry grouping, unless doing so will cause confusion. Please let us know if there will be any issues with using the term "ESP AGGFRAG_PAYLOADs" instead of "ESP AGGFRAG_PAYLOAD Parameters."

The new registry will be managed via Expert Review as defined in RFC8126.

There are initial registrations in the new registry as follows:

Sub-Type Name Reference
--------------------------------------------------------
0 Non-Congestion Control Format [ RFC-to-be ]
1 Congestion Control Format [ RFC-to-be ]
3-255 Reserved

IANA Question --> Sub-type values 3-255 do not seem to be reserved by any text in the current document. Are they perhaps "unassigned" instead?

Second, in the IKEv2 Notify Message Types - Status Types registry on the Internet Key Exchange Version 2 (IKEv2) Parameters registry page located at:

https://www.iana.org/assignments/ikev2-parameters/

a single, new status type is to be registered as follows:

Value: [ TBD-at-Registration ]
NOTIFY MESSAGES - STATUS TYPES: USE_AGGFRAG
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

The IANA Functions Operator understands that these two actions are the only ones required to be completed upon approval of this document.

Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

Michelle Thangtamsatid
IANA Services Specialist

(END IANA COMMENTS)

The following Last Call announcement was sent out (ends 2022-05-18):

From: The IESG
To: IETF-Announce
CC: draft-ietf-ipsecme-iptfs@ietf.org, ipsec@ietf.org, ipsecme-chairs@ietf.org, kivinen@iki.fi, rdd@cert.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (IP-TFS: Aggregation and Fragmentation Mode for ESP and its Use for IP Traffic Flow Security) to Proposed Standard


The IESG has received a request from the IP Security Maintenance and
Extensions WG (ipsecme) to consider the following document: - 'IP-TFS:
Aggregation and Fragmentation Mode for ESP and its Use for IP
  Traffic Flow Security'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-05-18. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

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 file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/



No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

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.

Working Group Summary:

Various aspects of the document were discussed and debated, with multiple
revisions incorporating the results. There was no controversy though, and there
is good WG consensus.

Document Quality:

At least one implementation will be open sourced, with interest by others in
implementing. There were multiple thorough reviews by experts in the WG.

Personnel:

Who is the Document Shepherd?

Tero Kivinen

Who is the Responsible Area Director?

Roman Danyliw.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have reviewed this document several time, and I think is ready to be forwarded to the IESG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

None. This document do cover cross area boundaries, by including congestion control and path mtu issues, but those
were reviewed during the transport area review.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

A transport area review was given, and the resulting comments addressed to the
reviewers satisfaction.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

The path mtu and congestion control issues are outside the most of the experts in the WG, thus
specific review from the transport area review group was requested and done, and issues found
during that was resolved, but there might be other issues missed in those sections, as most of the
reviewers in the WG do not have expertise on those issues.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Well reviewed by many active WG members, consensus is solid.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Nothing major. There are few figures using [60] style numbers which cause warnings in the idnits references checking system, and one table causing warnings about weird spacing.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

All required reservations are made (a notification message state type in IKEv2),
and the newly created registry is adequately documented.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

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.

Working Group Summary:

Various aspects of the document were discussed and debated, with multiple
revisions incorporating the results. There was no controversy though, and there
is good WG consensus.

Document Quality:

At least one implementation will be open sourced, with interest by others in
implementing. There were multiple thorough reviews by experts in the WG.

Personnel:

Who is the Document Shepherd?

Tero Kivinen

Who is the Responsible Area Director?

Benjamin Kaduk.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have reviewed this document several time, and I think is ready to be forwarded to the IESG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

None. This document do cover cross area boundaries, by including congestion control and path mtu issues, but those
were reviewed during the transport area review.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

A transport area review was given, and the resulting comments addressed to the
reviewers satisfaction.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

The path mtu and congestion control issues are outside the most of the experts in the WG, thus
specific review from the transport area review group was requested and done, and issues found
during that was resolved, but there might be other issues missed in those sections, as most of the
reviewers in the WG do not have expertise on those issues.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Well reviewed by many active WG members, consensus is solid.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Nothing major. There are few figures using [60] style numbers which cause warnings in the idnits references checking system, and one table causing warnings about weird spacing.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

All required reservations are made (a notification message state type in IKEv2),
and the newly created registry is adequately documented.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

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.

Working Group Summary:

Various aspects of the document were discussed and debated, with multiple
revisions incorporating the results. There was no controversy though, and there
is good WG consensus.

Document Quality:

At least one implementation will be open sourced, with interest by others in
implementing. There were multiple thorough reviews by experts in the WG.

Personnel:

Who is the Document Shepherd?

Tero Kivinen

Who is the Responsible Area Director?

Benjamin Kaduk.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have reviewed this document several time, and I think is ready to be forwarded to the IESG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

None. This document do cover cross area boundaries, by including congestion control and path mtu issues, but those
were reviewed during the transport area review.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

A transport area review was given, and the resulting comments addressed to the
reviewers satisfaction.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

The path mtu and congestion control issues are outside the most of the experts in the WG, thus
specific review from the transport area review group was requested and done, and issues found
during that was resolved, but there might be other issues missed in those sections, as most of the
reviewers in the WG do not have expertise on those issues.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Well reviewed by many active WG members, consensus is solid.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Nothing major. There are few figures using [60] style numbers which cause warnings in the idnits references checking system, and one table causing warnings about weird spacing.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

All required reservations are made (a notification message state type in IKEv2),
and the newly created registry is adequately documented.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A.