IETF Logo Mail Archive

[IPsec] TCP and MOBIKE

"Valery Smyslov" <smyslov.ietf@gmail.com> Thu, 08 November 2018 05:07 UTC

Return-Path: <smyslov.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C902130DC8 for <ipsec@ietfa.amsl.com>; Wed, 7 Nov 2018 21:07:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 szyHD4Mkt8qC for <ipsec@ietfa.amsl.com>; Wed, 7 Nov 2018 21:07:16 -0800 (PST)
Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (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 A1407126CB6 for <ipsec@ietf.org>; Wed, 7 Nov 2018 21:07:16 -0800 (PST)
Received: by mail-pl1-x629.google.com with SMTP id c13-v6so8950155plz.13 for <ipsec@ietf.org>; Wed, 07 Nov 2018 21:07:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=G4UP3v3KdKfZf18/0+hd21E79NOOoSDSqYt/GIiTqZA=; b=nj+tVrq4zmlXBT2hYdHRxZxz6VzhMFtkFJe9gd7Jt1DnNq1+7CYpxAN16KD8Xt89HF uwRh33qSbc1xuFsnYuMaNr9tVSa6vrgv0jRMjbUqefi8cpDqLCgiwo71o1Cg/YA2oww+ izvHlV4jt1ZEKj7fAQKsfirrFFZj+WQw2yYmvCS0IUO7O134OgMsKnIeEIogpQb+PLUA sWldUUSjt8WCeHIb6DLoR/T2fCuM260J8hlhSeCW/0IHAvN/HWDsq2iX5K63JRqRXZQ2 XGdbxg125Qt1iS2cO/CNU80Bfsc5BZGwgtk4TW2xVx4bjMkyCmQHZMZUlK4GJ1YmYIy0 7jYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=G4UP3v3KdKfZf18/0+hd21E79NOOoSDSqYt/GIiTqZA=; b=nTqgW/6BUQIl2scNpmuJSEzcx3o2x/xEOjXk1ZWGaOlUS10QCrcgrERzH7FrwLfYTN MNDVQXi5aojE50nUC6fzmCYeTnvt0GmRH8Gycl3JVu1P/JGtL91lhANRsXzvY0oM/HhV +rE5d9xzYpnpfuIQf/fnc4oWpO2wfx4cKnxLQyc6fWUXJWPw67Hzd7bXNCuWG0sQbm2u tWl9R2X7835L6sMeIVZA4Gy6MK6PIR78/FtYpYQDJrXfnfOZPAHS7auCd1B8N3YojTwr yX2LQlvP6DG4TX8SpuMAcjhPck5AjB7sIVOVscG1NHzdUGdDQqkBXoYlOCGDzfp6qflz zY6g==
X-Gm-Message-State: AGRZ1gKkKlw8CqUz8S4obkst/CWKUD3CPLjmCnZOuEQ9pUNGmlPLZaMh BBmpieoCwa7b9C5PgTzHiUNXEwKRpwM=
X-Google-Smtp-Source: AJdET5dBY2W3zes9pM7qGDgLpKiGHYtFL7b3OGhW2xPD+Nd2b8iQtoNVgFX3lD2drJaqSrpfpifghA==
X-Received: by 2002:a17:902:aa46:: with SMTP id c6-v6mr3224227plr.182.1541653635532; Wed, 07 Nov 2018 21:07:15 -0800 (PST)
Received: from svannotebook ([2001:67c:370:128:d0fc:a79b:6612:e3cb]) by smtp.gmail.com with ESMTPSA id d197-v6sm3828845pga.1.2018.11.07.21.07.14 for <ipsec@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Nov 2018 21:07:15 -0800 (PST)
From: Valery Smyslov <smyslov.ietf@gmail.com>
To: 'IPsecME WG' <ipsec@ietf.org>
Date: Thu, 08 Nov 2018 12:07:12 +0700
Message-ID: <031f01d47720$e9fb8220$bdf28660$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdR3Hk31rop2W0hhSPSOG6Xzw31sYw==
Content-Language: ru
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/NSEGfxha0bISISe4AfKxPMwF0MY>
Subject: [IPsec] TCP and MOBIKE
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Nov 2018 05:07:18 -0000

Hi,

coming back to the yesterday discussion. There seems to be another issue 
if implementation first sends request to update address over UDP and
then switches to TCP. The problem arises if NO_NATS_ALLOWED is included - 
it contains IP addresses and ports for initiator and responder. If you
leave it intact while switching to TCP, then it won't match real addresses
and the responder will treat it as NAT presence. In this case RFC 4555
suggests to retry sending request several times with a new INFORMATIONAL
request. Probably we could clarify in TCP guidelines draft that the content
of NO_NATS_ALLOWED MUST be recalculated in this case? Or is it obvious?

Regards,
Valery.

v2.23.0 | Report a Bug | By Email