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

[Martin Duke <[e-mail]>]

On Mon, Aug 8, 2022 at 5:12 AM Valery Smyslov <[e-mail]> wrote:

> >
> > (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?
>

OK, I'll start a separate thread with Joe and you.


>
> > (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?
>

I think my confusion here was that I read the second sentence ("If upon
egress...") as also describing RFC6040,
which I see now it does not. My apologies; perhaps splitting it into two
paragraphs would help. However, the need
for this text is related to difficulty mapping outer to inner; see also
below.


> > 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).
>

This isn't a DISCUSS, so you can choose to ignore this advice or not.
However, my concern is that IPSec is going to miss
out on the low-latency services operators are now enabling through ECN.

If it were me I would design it this way:

1) Encapsulators SHOULD NOT mix ECT(0), Not-ECT, and ECT(1) inner packets
in the same outer packet.
2) If they do, the outer packet MUST be marked Not-ECT.
3) If all packets are marked CE, mark the outer packet CE.
4) If CE packets are mixed with "something else", mark it "something else".
5) Decapsulators follow Figure 4 in RFC6040, except they SHOULD NOT log an
event or raise an alarm when
the outer packet is ECT(1) and one of the inner packets is CE.

Per 3168, if an inner packet is fragmented, any CE applied to a fragment is
applied to the reassembled packet.


>
> > (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.
>

Thanks for the info. It might be good to explicitly state this in Appendix
A, but feel free to ignore that suggestion.


>
> Regards,
> Valery.
>
>
>