Re: [IPsec] Martin Duke's No Objection on draft-ietf-ipsecme-rfc8229bis-07: (with COMMENT)

[Valery Smyslov <[e-mail]>]

Hi Martin,

thank you for your comments. Please see inline.

> Martin Duke has entered the following ballot position for
> draft-ietf-ipsecme-rfc8229bis-07: No Objection
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-
> ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc8229bis/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks to Joe Touch for the TSVART review. There are no showstoppers in this
> document, but some non-normative text makes inaccurate statements about
> TCP and
> RFC6040, and there are some odd decisions with respect to TLS that are worth
> asking about:
> 
> (Sec 9.1)
> "TCP-in-TCP can also lead to "TCP meltdown", where stacked instances
>    of TCP can result in significant impacts to performance
>    [TCP-MELTDOWN].  For the case in this document, such meltdown can
>    occur when the window size of the outer TCP connection is smaller
>    than the window sizes of the inner TCP connections.  The resulting
>    interactions can lead to packets backing up in the outer TCP
>    connection's send buffers.  In order to limit this effect, the outer
>    TCP connection should have limits on its send buffer size and on the
>    rate at which it reduces its window size."
> 
> Which "window" are you referring to? Receive window, congestion window,
> or the
> send buffer? My reading of [TCP-MELTDOWN] is that the tunnel ingress
> should set
> its send buffer size to the BDP of the tunnel, which is easier said than done.
> It appears you are using "window" and "send buffer" interchangeably here in a
> way that is confusing.

This text was suggested by Joe Touch (https://mailarchive.ietf.org/arch/msg/ipsec/eD85hixrzfqwg4UhwRZ8WL5PkDA/)
If you think it is unclear, can you please suggest how it can be improved?

> (9.5)
> Implementations SHOULD follow the ECN compatibility mode for tunnel
>    ingress as described in [RFC6040].  In compatibility mode, the outer
>    tunnel TCP connection marks its packet headers as not ECN-capable.
>    If upon egress, the arriving outer header is marked with CE, the
>    implementation will drop the inner packet, since there is not a
>    distinct inner packet header onto which to translate the ECN
>    markings.
> 
> This is not an accurate summary of compatibility mode. In compatibility mode,
> the outer packet is marked Not-ECT, which means it will not be marked CE. In
> normal mode, the outer packet is marked as the inner, and this might result in
> an outer CE marking.

Can you please, clarify why the description is inaccurate?

According to RFC 6040 in compatibility mode outer packet are marked as not ECN-capable
(Not-ECT). On the other hand, since using compatibility mode is SHOULD here
and currently it is assumed that IPsec tunnels are used with normal mode (RFC 4301, RFC 6040), then some 
additional guidelines are given what to do if peer still uses normal mode.

Am I missing something?

> It's a shame that there is no attempt to figure out a mapping between inner
> and
> outer that would make normal mode work, as this reviewer is optimistic that
> ECN
> marks will become increasingly important. But regardless, this section should
> be clear and make correct statements.

I'm not sure this is generally possible given that one outer TCP tunnel
can include many inner TCP tunnels, so you have to decide which 
of them to inform. The things get worse if AggFrag mechanism
is in use (draft-ietf-ipsecme-iptfs-13, in IESG evaluation).

> (Appendix A) Why not provide an in-band way to determine TLS support?
> There
> could be another port number, or different magic bytes to indicate that TLS
> handshake messages follow.

Actually, with this draft in-band switching to TLS is really a downgrade, rather than an upgrade (surprise?).
The reason is that actual protection of the traffic is provided by IPsec and both TCP and TLS
are only used as transport mechanisms that allow IPsec to work in environments where it cannot
be used otherwise. And TLS is worse, since it requires more resources and has bigger overhead.
So, once you get through using plain TCP there is no sense to switch to TLS.

Regards,
Valery.