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

[Martin Duke <[e-mail]>]

Re: the ECN rules for aggregated packets, I got intrigued by this problem
and wrote a draft. The rules I proposed earlier are, unsurprisingly, not
the whole story.

On Wed, Aug 10, 2022 at 7:05 AM Martin Duke <[e-mail]> wrote:

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