Re: [tcpm] 64-bit sequence numbers

Joe Touch <touch@isi.edu> Mon, 20 March 2017 18:31 UTC

Return-Path: <touch@isi.edu>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB43D131650 for <tcpm@ietfa.amsl.com>; Mon, 20 Mar 2017 11:31:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwoMuUMK2oPB for <tcpm@ietfa.amsl.com>; Mon, 20 Mar 2017 11:31:44 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DFB0131647 for <tcpm@ietf.org>; Mon, 20 Mar 2017 11:31:44 -0700 (PDT)
Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v2KIUcSH018500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 20 Mar 2017 11:30:40 -0700 (PDT)
To: Jonathan Looney <jtl.ietf@gmail.com>
References: <CAJrujPmZ-H3YfBGpz4D=5K6EH=+XrgN9Hf4Pk3NVgFT47R-7uQ@mail.gmail.com> <c00dcd80-436e-d614-ffe2-135c0466f834@isi.edu> <CAJrujPm1WQpqU0ALTqCm9iYgkER_KeFS6=dH0E7M0KU8jV2A2w@mail.gmail.com>
Cc: tcpm@ietf.org
From: Joe Touch <touch@isi.edu>
Message-ID: <4a8cfeac-e453-a70d-716d-dd2a41fb2777@isi.edu>
Date: Mon, 20 Mar 2017 11:30:38 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CAJrujPm1WQpqU0ALTqCm9iYgkER_KeFS6=dH0E7M0KU8jV2A2w@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------72171B8D55E90B5DA483F794"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/ZQfb2UD-hsqkeCGrBwuXu9-Z70s>
Subject: Re: [tcpm] 64-bit sequence numbers
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Mar 2017 18:31:47 -0000

See below...

Joe


On 3/20/2017 11:12 AM, Jonathan Looney wrote:
> Dear Joe,
>
> Thanks for taking the time to provide feedback!
>
> On Wed, Mar 15, 2017 at 4:25 PM, Joe Touch <touch@isi.edu
> <mailto:touch@isi.edu>> wrote:
>
>     Hi, Jonathan (et al.),
>
>     A few issues:
>
>     1) why do you want to use all 64 bits for the TCP-AO MAC, but only the
>     low 32 bits for the KDF? The latter won't help with backward
>     compatibility, so why do this? FWIW, one mode of TCP-AO ignores
>     options;
>     I don't see how you can say "ignore options" (experimental - RFC6978).
>     This doc probably needs to explain what happens when "ignore
>     options" is
>     set (for NAT traversal), i.e., the sequence number extensions will be
>     ignored completely for TCP-AO in that case, AFAICT.
>
>
> Because the KDFs are expected to take 32-bit sequence numbers, it
> seemed to make sense to only use 32-bit sequence numbers as input to
> these functions. If there is a desire to take 64-bit sequence numbers
> as input to the KDFs, we could certainly specify this; however, I
> believe this would require modifying the specifications for KDFs, and
> I wanted to avoid going farther than necessary in this draft.
I don't see a rationale for treating the two differently... (see the
next note)

> The MAC only takes 64-bit sequence numbers once we are reasonably sure
> that the session supports 64-bit sequence numbers. Because the MAC
> already used a 64-bit sequence number, there were not the same
> concerns with MACs as the KDF.
The MAC uses an *internal* SNE; you're overriding that by using the
extension in the option. That's a change too.

>
> I don't see an automatic conflict between ignoring TCP options while
> constructing the MAC on the one hand, and using 64-bit sequence
> numbers in the MAC on the other hand. Can you explain why you think
> this is a conflict?

I don't think you should be say two conflicting things to the protocol -
"ignore options" means ignore them all, not "ignore all except this one".

>  
>
>     2) the doc should address how to handle RSTs, esp. if the state goes
>     away. It seems like a connection negotiated with 64-bit sequence
>     numbers
>     can't ever be reset if the connection state is lost (all the RSTs will
>     be treated as out of window
>
>
> I'm not sure I understand this comment. If the host sending the RST
> understands 64-bit sequence numbers, it can use full 64-bit sequence
> numbers in the RST. If the host doesn't understand 64-bit sequence
> numbers, it will use 32-bit sequence numbers and (after the three-way
> handshake) that RST will be ignored. While that *may* result in
> ignoring "legitimate" RSTs from middleboxes that don't understand
> 64-bit sequence numbers, I'm not sure this is a fatal flaw.

It means you can't reset a connection. Remember that TCP state doesn't
go away by itself. So you'll accumulate dead connections that will
interfere with new ones - and the new one won't reset the old one away
either. This can be handled, but requires timeouts to cleanup dead
connections, which are not part of the TCP spec. This was discussed in
TCP-AO.

> After all, in today's Internet, it seems better to err on the side of
> ignoring legitimate RSTs rather than accepting illegitimate RSTs.

Agreed, but you need to discuss it and find a way to reset connections
when state is lost.

>  3) there are more things than just TCP-AO that use ISNs as input; it
>
>     seems like you need a blanket statement on how they're handled. This
>     also then seems to kill automatic fall-back, AFAICT.
>
>
> I'm not sure which features you are referring to. If you can provide
> specifics, I can try to provide a more specific answer.
Search the RFCs for ISNs. Some crypto algs use ISNs as a source or
"randomness" (incorrectly, of course). There are also RFCs that talk
about generating ISNs. A scrub of these will give you a list of what to
address.

>  
> The general principal is to use 32-bit sequence numbers until you are
> sure you can successfully negotiate 64-bit sequence numbers. So, if a
> feature needs to use ISNs in the three-way handshake, it will need to
> use 32-bit sequence numbers. If a feature uses ISNs after that point,
> it can use 64-bit sequence numbers.

If that's true, then TCP-AO MAC cannot use the 64-bit ISNs in MAC
calculations until after the handshake completes! Otherwise, you can't
fall-back.

>
> More details may be needed. (e.g. Does a feature switch to using
> 64-bit sequence numbers as soon as it detects support?) A general rule
> will need to be conservative (if you need to use ISNs in the three-way
> handshake, you need to always use 32-bit sequence numbers); however,
> specific rules can be more tailored to the specific feature. If there
> are features that would benefit from the use of 64-bit sequence
> numbers, we should be sure to specify how they can use them.

This is a dangerous pit. TCP should have one set of assumptions at the
start of a connection, and another after the TWHS completes. Doing
changes at any other time is perilous and ill-defined.

> If this is not explained thoroughly enough in the document, I would be
> happy to modify it to explain the general rule in more detail. (Again,
> more specific examples will help, since there are limits to how
> specific you can be in a "general rule".)
>
>
>     4) the doc needs to explain the impact of using this feature on each
>     segment on the TCP option space
>
>
> I'm not sure what you mean by this. Can you elaborate?

You're using bytes for this option, and option space is very limited.
See the discussion of option space in TCP-AO.

>
>     5) the doc should probably address the impact of odd middleboxes,
>     e.g.,
>     that split or splice segments or change sequence numbers
>
>
> Fair enough. IMHO, such middleboxes are already broken, since they
> can't possibly know how to properly modify the TCP options. However,
> it is a good point that the document should consider this.

Right - the issue is whether you give false positives and whether you
can detect these and fall back (or should).

>  
>
>     That's just scratching the surface; I fear this is a Gordian knot of
>     issues for which there is no simple sword.
>
>
> It may be that there are challenges to using 64-bit sequence numbers.
> However, I think it is important to find a way forward on this.
> Otherwise, I fear we will "soon" (in TCP modification timelines) run
> into performance limitations.

"Important" doesn't mean "possible". Don't get ahead of that issue, please.

Joe