[tcpm] regarding upcoming tcpcrypt presentation

Joe Touch <touch@isi.edu> Thu, 13 February 2014 21:00 UTC

Message-ID: <52FD326A.10803@isi.edu>
Date: Thu, 13 Feb 2014 13:00:26 -0800
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "tcpm@ietf.org" <tcpm@ietf.org>
References: <4DC6C56D.6040709@ieca.com> <D1CCED3D-C041-4DA2-B999-D3EF7FC889D0@cisco.com> <20110727184256.GA3690@shorty> <CADRHXGuS3G=UWVxZzuQ80kHEydrcMZKJ4hG23Sm8h7A3LPvULQ@mail.gmail.com> <4E308A4B.4090702@isi.edu>
In-Reply-To: <4E308A4B.4090702@isi.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/6kh42OuiE1cewl9bKQh42P7LjFI
Subject: [tcpm] regarding upcoming tcpcrypt presentation
Precedence: list

Since this is the second (at least - maybe third) time this concept will 
be presented to the IETF, it might be useful to at least consider 
addressing comments that go back around 3 years:

1) the posted code still codepoint-squats:

> ...it appears to use *two* unassigned TCP option codepoints
> (69 and 70), rather than experimental codepoints (and, IMO, it should
> use the latter instead).

The doc should use the experimental codepoints with registered ExIDs, as 
per RFC6994

2) The MAC aspect is redundant with TCP-AO, and it might even be 
reasonable to consider extending TCP-AO to support encryption in 
addition to authentication using a single system.

> TCP-AO could easily support a mode where the TCP body was encrypted,
> e.g., where the encryption algorithm were defined to use the
> connection context (TCP header, IP pseudoheader) as context.

3) the description of the protocol itself is insufficient

The draft does not link sufficiently to the description of TCP states 
and processing options in those different states, or to the order of 
option processing.

Joe

[tcpm] regarding upcoming tcpcrypt presentation Joe Touch