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

[Martin Duke <[e-mail]>]

Sounds good to me, we're all set modulo the thread with Joe.

On Wed, Aug 10, 2022, 01:25 Valery Smyslov <[e-mail]> wrote:

> Hi Martin,
>
>
>
> please see inline.
>
>
>
> 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.
>
>
>
>           OK, thank 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.
>
>
>
>           I moved this sentence to a new paragraph.
>
>
>
>
> > 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.
>
>
>
>           Not exactly :-) Note, that TCP is not a default transport for
> IPsec
>
>           and in case ESP is sent over IP or UDP, all the modern ECN
>
>           techniques must work well (I guess you mean L4S networks?).
>
>           TCP is a backup transport in case no other is available and
>
>           due to the inherent problems (TCP-in-TCP) we don't expect
>
>           to get good performance in this case, so there is no point
>
>           to complicate the protocol. TCP encapsulation is for those cases
>
>           when you need things to work somehow, not in the best way.
>
>
>
> 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.
>
>
>
>           This might work, but please, see above.
>
>
>
>
> > (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.
>
>
>
>           Thank you!
>
>           Valery.
>
>
>
>
> Regards,
> Valery.
>
>