Re: [Tsv-art] [Last-Call] Tsvart last call review of draft-ietf-ipsecme-rfc8229bis-06

"touch@strayalpha.com" <touch@strayalpha.com> Wed, 25 May 2022 15:15 UTC

Return-Path: <touch@strayalpha.com>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC04FC1850E1; Wed, 25 May 2022 08:15:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.308
X-Spam-Level:
X-Spam-Status: No, score=-6.308 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, T_PDS_SHORTFWD_URISHRT_QP=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pcyx6Cs9kQeg; Wed, 25 May 2022 08:15:26 -0700 (PDT)
Received: from server217-1.web-hosting.com (server217-1.web-hosting.com [198.54.114.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E88AC1850F2; Wed, 25 May 2022 08:15:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=xIAsmL0CwJA5OogKphKHhhf5fPH0d8W02bDwThfl9aM=; b=yISjQhX4gMopPAj/Witr4Zrklq xFk6Hxg/hmQlUfDrV0Q8LgDpBMN7tTyIIdRy9QqQFuoairTip1ZLGPRn4emsUdqATuhBgasEVW/aj pjCYxz18Q+CxrLj5MOsYAQBJNs9tThvuvTornvcQzq6v16FsxDGMIJ2CXte4mrgw6Qda5d3pkzali QBCCqSWA0uIKYelenZyr8c+qnsIXoL/s1KVx0g1FETPCMZXDG1LOG0JDZALPocFgJYMB3rsWvSgJt i3GOuJU28Dg2wP0gRLsA5Xf+/ccUDg6HIdtSZG45JkmM+4u1DdYaz0dEv6knN1k0rLIMbH1oOK1G/ GhRHMxXg==;
Received: from cpe-172-114-237-88.socal.res.rr.com ([172.114.237.88]:49426 helo=smtpclient.apple) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from <touch@strayalpha.com>) id 1ntsjH-004h3g-HL; Wed, 25 May 2022 11:15:25 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_5B33AA37-4C8C-4174-9F39-745BF4C42AEB"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\))
From: "touch@strayalpha.com" <touch@strayalpha.com>
In-Reply-To: <02c301d86f61$341c2440$9c546cc0$@elvis.ru>
Date: Wed, 25 May 2022 08:15:17 -0700
Cc: tsv-art <tsv-art@ietf.org>, draft-ietf-ipsecme-rfc8229bis.all@ietf.org, ipsec@ietf.org, last-call@ietf.org
Message-Id: <4188F964-8316-4EAC-B66F-93FB769CD6BC@strayalpha.com>
References: <02c301d86f61$341c2440$9c546cc0$@elvis.ru>
To: Valery Smyslov <svan@elvis.ru>
X-Mailer: Apple Mail (2.3696.80.82.1.1)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/undW4NDFBYJlxR--qNFgf0eDTeU>
Subject: Re: [Tsv-art] [Last-Call] Tsvart last call review of draft-ietf-ipsecme-rfc8229bis-06
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 May 2022 15:15:30 -0000

Hi, Valery,

Thanks - I will confirm when the update is posted so this can be closed out.

Joe

—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com

> On May 24, 2022, at 4:27 AM, Valery Smyslov <svan@elvis.ru> wrote:
> 
> Hi Joe,
>  
> please see inline.
>  
> Regards,
> Valery.
>  
> From: touch@strayalpha.com <mailto:touch@strayalpha.com> [mailto:touch@strayalpha.com <mailto:touch@strayalpha.com>] 
> Sent: Monday, May 23, 2022 6:14 PM
> To: Valery Smyslov
> Cc: tsv-art; draft-ietf-ipsecme-rfc8229bis.all@ietf.org <mailto:draft-ietf-ipsecme-rfc8229bis.all@ietf.org>; ipsec@ietf.org <mailto:ipsec@ietf.org>; last-call@ietf.org <mailto:last-call@ietf.org>
> Subject: [***SPAM***] Re: [Tsv-art] Tsvart last call review of draft-ietf-ipsecme-rfc8229bis-06
>  
> Hi Valery,
>  
> Notes below.
>  
> Joe
> 
> 
> On May 23, 2022, at 4:53 AM, Valery Smyslov <svan@elvis.ru <mailto:svan@elvis.ru>> wrote:
>  
> Hi Joseph,
> 
> thank for your review, much appreciated. More inline.
> 
> 
> Reviewer: Joseph Touch
> Review result: Ready with Issues
> 
> This document has been reviewed as part of the transport area review team's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the document's
> authors and WG to allow them to address any issues raised and also to the IETF
> discussion list for information.
> 
> When done at the time of IETF Last Call, the authors should consider this
> review as part of the last-call comments they receive. Please always CC
> tsv-art@ietf.org <mailto:tsv-art@ietf.org> if you reply to or forward this review.
> 
> Overall, this document adds useful clarifications to the original RFC on
> tunneling IPsec over TCP. There are a number of issues that should be addressed
> as it proceeds, as noted below. All can be addressed relatively directly (i.e.,
> none create new open issues).
> 
> General comments:
> 
> The document lacks (and would benefit from) a section providing details of the
> differences in this update.
> 
> Good point.
> 
> can add the following text at the end of 1.1:
> 
> In particular:
> o The interpretation of the Length field preceding every message is clarified
> o Use of NAT_DETECTION_*_IP notifications is clarified
> o Retransmission behavior is clarified
> o Using cookie and puzzles is described with more detail
> o Error handling is clarified
> o Implications of TCP encapsulation on IPsec SA processing are expanded
> o Interaction of TCP encapsulation with MOBIKE is clarified
> o Section describing interactions with other IKEv2 extensions is added
> o Recommendation for TLS encapsulation include using TLS 1.3
> 
> Is it OK?
>  
> Sure; it might also be useful to indicate the section where each is addressed in most detail.
>  
>           Done.
>  
>> Figures should include captions.
> 
> I would leave this to RFC Editor (we tried to keep RFC 8229 text when possible,
> and it doesn't have captions too).
>  
> The RFC Editor isn’t likely to care. These can be added without changing the intent of RFC 8229; in most cases, the caption is fairly obvious from the text.
>  
>           I’ve added titles for the figures defining headers and prefix formats 
>           and removed anchors from figures in Appendix B (so they are now “inline”).
>  
>> Given the new document adds primarily clarifications, it would be preferable if
>> the header numbering were not gratuitously modified vs. the original. The new
>> section 2 should be demoted to 1.2 as per the original; this would go a long
>> way to avoiding unnecessary confusion between the two.
> 
> OK, makes sense.
> 
> 
> Specific suggestions and concerns:
> 
> Section 3 clarifies the meaning of the 16-bit length field as including both
> the message and the message length field. This is counterintuitive and
> problematic, notably because ESP messages could be up to 65535 bytes long. This
> possibility should be addressed (e.g., prohibit tunneling of messages over
> 65533 bytes).
> 
> This is a a good catch, we'll add this clarification.
> 
> 
> Section 4.2 claims the length cannot be 0 or 1 bytes; again, this suggests it
> might have been better to have the length field no include the length itself.
> 
> The design decision that length field includes both the message and the message
> length was made back in 2016 when RFC 8229 was developed to align 
> it with 3GPP’s recommendation. We are not in a position to change this design.
>  
> Understood.
> 
> 
>> Regardless, it seems there are other lengths that are equally invalid (isn’t
>> there a min ESP header size? What about the IP packet header inside)? The true
>> min should be indicated.
> 
> TCP encapsulation is used for IKE too and "NAT keepalive" messages 
> may still be sent by IKE (even they are not needed for TCP), which are 1 byte long.
>  
> It might be useful to mention that.
>  
>           This possibility is mentioned in Section 7.6. Added a clarification referencing this section.
>  
> It's a good question whether empty messages (with Length = 2) are OK.
>  
>>> From receiver's point of view following the Postel's rule I'd simply ignore them 
>> and don't tear down TCP...
>> 
>> Added a clarification for receiving empty messages.
>> 
>> 
>> Section 7.1 suggests closing idle TCP connections to clean up resources; this
>> is inconsistent with TCP’s basic premise (don’t clean it up until those
>> resources are used for a new connection). There should be a more direct reason
>> given for this change.
>> 
>> If a TCP connection is no more associated with any SA, then it SHOULD be 
>> deleted by TCP Originator. In some cases the TCP FIN/ACK messages 
>> will not reach the Responder (e.g. due to network problems), 
>> so this TCP connection will become an orphan on Responder, 
>> since no new traffic will ever be sent over it. 
>> We see no reason to waste Responder's resources in this case - this is the reason.
>> Note, that this recommendation is MAY, you are free to ignore it.
>  
> It might be useful to indicate that the reason is to conserve responder IPsec resources, i.e., this is (to TCP) an application consideration, not a TCP one.
> 
> Done.
> 
> 
> Section 7.1 mentions a keep-alive; it would be useful to explain whether this
> is intended to use TCP keepalives or IPsec keepalives or both. It may also be
> important to indicate how these keepalives might interact. This might refer to
> the more detailed discussion in Section 7.6.
> 
> Section 7.1 talks about IKE keep-alive messages (more formally called "liveness check" messages).
> The idea is that an encrypted and authenticated message must be received,
> so that the responder may learn new SPIs, so TCP keep-alives are not suited.
> 
> Will add clarification.
> 
> 
> Section 7.2 on retransmissions should explain the need for IPsec to continue to
> retransmit messages even though the transport ensures reliable delivery (e.g.,
> that messages could be ignored or delayed elsewhere in receiver processing).
> 
> There is generally no need to do it (except for the situations when TCP connection
> is replaced with a new one while waiting for the response). And Section 7.2 
> describes it very clear, we think. However, there is no harm if the initiator retransmits 
> the request (following IKEv2 recommendations on exponential back-off between retransmissions), 
> so some implementations might choose not to complicate retransmission logic and always follow
> the same pattern regardless on the transport (note, that TCP encapsulation
> adds quite a lot of changes to IKE codebase, so it's a valid desire to minimize them).
> Thus "SHOULD NOT" retransmit in the first button in 7.2.
>  
> It might be useful to indicate this rationale there.
> 
> Done.
> 
> 
> Section 7.7 discusses the relation of the IPsec DFs to the outer TCP DFs. As
> with all tunnels, there need be no direct relation. The outer TCP header acts
> as a link layer protocol and its frag/reassembly need have no correlation to
> the inner payload. Additionally, it is nonsensical to relate the two for TCP as
> a tunnel because it does not preserve message boundaries of the carried IPsec
> traffic anyway. It might be useful to mention this, rather than indicating this
> as “not possible”. (i.e., even if it were possible, it would be incorrect to do
> so).
> 
> We believe that is exactly what Section 7.7 1-st bullet says.
> Do you want some specific text to be added here?
>  
> It might be useful to indicate that you’re doing what tunnels (not IPsec tunnels) should be doing, not creating a new solution for this specific approach.
>  
>           Added a clarification.
> 
> 
> (Note, that we are not in a position to discuss generic considerations
> of using tunnels, we just explain that what is required 
> by RFC 4301, is not possible with TCP. We don't want to discuss
> here whether RFC 4301 requirements are wrong).
>  
> RFC4301’s tunnels are not the tunnel you’re describing here; agreed that those tunnel considerations are not relevant.
> 
> 
>> Section 10.1 indicates problems with TCP-in-TCP. It would probably be useful to
>> provide a citation with better treatment of this issue (e.g,,
>> https://www.spiedigitallibrary.org/conference-proceedings-of-spie/6011/1/Understanding-TCP-over-TCP-- <https://www.spiedigitallibrary.org/conference-proceedings-of-spie/6011/1/Understanding-TCP-over-TCP-->
>> effects-of-TCP-tunneling-on/10.1117/12.630496.short?SSO=1,
>> https://link.springer.com/chapter/10.1007/978-981-13-3329-3_32 <https://link.springer.com/chapter/10.1007/978-981-13-3329-3_32>). This is more
>> commonly referred to as “TCP meltdown”; bufferbloat is a different phenomenon
>> with a different cause (in-network queuing that relies on tail-drop and/or
>> lacks ECN), and does not appear relevant to the issues presented in this
>> section.
> 
> We'd be happy to include good references, but It seems that both articles are behind paywalls, 
> or at least require some subscription to be able to read. Do you have some free references? 
> Or probably you can craft a proper text to be included in this section?
>  
> Being behind a paywall does not disqualify a document as an appropriate citation, especially when that is the primary source.
>  
> Here’s from/to text:
>  
> FROM:
>    TCP-in-TCP can also lead to increased buffering, or bufferbloat.
>    This can occur when the window size of the outer TCP connection is
>    reduced and becomes smaller than the window sizes of the inner TCP
>    connections.  This 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.
> TO:
>  
>    TCP-in-TCP can also lead to “TCP meltdown”, where stacked instances 
>    of TCP can result in significant impacts to performance [Ho05].
>    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.
> 
> Here’s the bibtex:
> @inproceedings{10.1117/12.630496,
> author = {Osamu Honda and Hiroyuki Ohsaki and Makoto Imase and Mika Ishizuka and Junichi Murayama},
> title = {{Understanding TCP over TCP: effects of TCP tunneling on end-to-end throughput and latency}},
> volume = {6011},
> booktitle = {Performance, Quality of Service, and Control of Next-Generation Communication and Sensor Networks III},
> editor = {Mohammed Atiquzzaman and Sergey I. Balandin},
> organization = {International Society for Optics and Photonics},
> publisher = {SPIE},
> pages = {138 -- 146},
> keywords = {TCP, TCP over TCP, TCP tunnel, Performance Evaluation, Goodput, Round-Trip Time},
> year = {2005},
> doi = {10.1117/12.630496},
> URL = {https://doi.org/10.1117/12.630496 <https://doi.org/10.1117/12.630496>}
> } 
>  
>               Thank you for the text!
>  
>>> Section 11 (security considerations) mentions the new vulnerability introduced
>>> by the outer TCP layer, but only DoS via SYN-flooding. This connection is also
>>> susceptible to RST and other spoofing attacks attacks (RFC4953), which should
>>> be noted as well. Data injection attacks are not possible, but all the rest of
>>> the TCP machinery remains vulnerable.
>> 
>> Good point, will add clarification and cite RFC 4953.
>> 
>> Regards,
>> Valery.
>> 
>> _______________________________________________
>> Tsv-art mailing list
>> Tsv-art@ietf.org <mailto:Tsv-art@ietf.org>
>> https://www.ietf.org/mailman/listinfo/tsv-art <https://www.ietf.org/mailman/listinfo/tsv-art>
>  
> -- 
> last-call mailing list
> last-call@ietf.org <mailto:last-call@ietf.org>
> https://www.ietf.org/mailman/listinfo/last-call <https://www.ietf.org/mailman/listinfo/last-call>