IETF Logo Mail Archive

Re: [IPsec] TCP and MOBIKE

"Valery Smyslov" <smyslov.ietf@gmail.com> Thu, 08 November 2018 05:36 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 D29A313107E for <ipsec@ietfa.amsl.com>; Wed, 7 Nov 2018 21:36:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 EF_qHGJ3ISkg for <ipsec@ietfa.amsl.com>; Wed, 7 Nov 2018 21:36:27 -0800 (PST)
Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (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 35AFA130EBB for <ipsec@ietf.org>; Wed, 7 Nov 2018 21:36:20 -0800 (PST)
Received: by mail-pf1-x433.google.com with SMTP id d13-v6so1626952pfo.3 for <ipsec@ietf.org>; Wed, 07 Nov 2018 21:36:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=oW3hfy8nfJfxxFbJDj9G4RwW2UH9+XTw29dS23Pktug=; b=H3cnLfE+FI282xhHsxR1RjVS6IwpXL/g3J3Zz4gfx8oor/oaahU4FTw8IcsMjmYy8M tqlVVLnuWnbzHYFXBEzOkl57uDQk/JgNtiYqQzQsLdGidS1dozbQRCJ45NoK7nGEv+gO QEicx/YmQJGnF24CgE3AU6J1SLLbJSnp+Vur9pNxk2Cgo80qq+BrjbKGtkVC4CIgKrU1 OyJRpcu86WAagmLLp7rMMZSZfR23+eHhBgSZDOBZB969hVLSxdhVwi+cIAqecakUhkVB cwZVDEvP/ewr+a2RDSEKF2L8gFYrpfnNfx1tzlQ0fFG1EQF2x4iwbKdfMVe4lVG7o2Wj bETQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=oW3hfy8nfJfxxFbJDj9G4RwW2UH9+XTw29dS23Pktug=; b=LwBlPxnGiN/LL3ptNjtDUyQ8ntSyFWSP3/hjssIRg1T0TVLbKQ2gvkDsrpGBE3YZLE j0FabQWhvwd/+OaJzTN8HQb4tIIJQhuc6q9MdWZw1kv8xgfluhv/8DHOaHAZde2XantO L4MJKE8m2Gj0cXT0lxfKgf9dNOHASPB5PbGO7/kNNSxDklpW8syDKOyM5e88IKQOeMsh Y38j2MelPlTMZNuap1Dv0ZHvjqJaAtG7EMnmUBW5hzQBjazG7npf+Q5U5s/ZgJfFPwpM pwvaEKRMkc0JcCgqHjUXm/tnLLQ2gCH0JX2bRY07UXuZ2io3uSjn8UMJNKccfASD7O6U sSkg==
X-Gm-Message-State: AGRZ1gKpa0zj8A3ua3i4Zc7Kgc6WHngcN6oIeHqeonI8htAQaZ73MLyK rP6BhviVf5Xc2RvloXqlFmM=
X-Google-Smtp-Source: AJdET5cgUCv5z+v+H5VGzH1XzCojQAUt2r2BDAg4fGXks81LxktbKxMLpuDGPNg8tAQQhItp8u6hLQ==
X-Received: by 2002:a63:1204:: with SMTP id h4mr2729472pgl.51.1541655379354; Wed, 07 Nov 2018 21:36:19 -0800 (PST)
Received: from svannotebook ([2001:67c:1232:144:e423:48:6da9:175f]) by smtp.gmail.com with ESMTPSA id s141-v6sm5273967pfc.63.2018.11.07.21.36.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Nov 2018 21:36:18 -0800 (PST)
From: Valery Smyslov <smyslov.ietf@gmail.com>
To: 'David Schinazi' <dschinazi.ietf@gmail.com>
Cc: ipsec@ietf.org
References: <031f01d47720$e9fb8220$bdf28660$@gmail.com> <CAPDSy+6V3dVkrcX=Lgd-G47RaLug8fhR=SZcD-cBdAmXJeCXvA@mail.gmail.com>
In-Reply-To: <CAPDSy+6V3dVkrcX=Lgd-G47RaLug8fhR=SZcD-cBdAmXJeCXvA@mail.gmail.com>
Date: Thu, 08 Nov 2018 12:36:14 +0700
Message-ID: <032c01d47724$f906d6d0$eb148470$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_032D_01D4775F.A56D01D0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQINC5x2IttgBeVJM8GBpgLrp7BrywFkiMAmpMkKaGA=
Content-Language: ru
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/vrtJAilzeR1MccRk5reyniYZI9Q>
Subject: Re: [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:36:34 -0000

Hmm, maybe. Or maybe not. Or maybe just ignore it in case of TCP?

I think that in general the co-existence of MOBIKE and TCP must be

elaborated in more detail in the draft.

 

 

 

I'm having a hard time imagining why anyone would want to use NO_NATS_ALLOWED with TCP encapsulation. If you're encapsulating in TCP it means that there is something on path even worse than a NAT, right?

 

Perhaps we could simply say you MUST NOT use NO_NATS_ALLOWED with TCP encaps?

 

David

 

On Thu, Nov 8, 2018 at 12:07 PM Valery Smyslov <smyslov.ietf@gmail.com <mailto:smyslov.ietf@gmail.com> > wrote:

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.


_______________________________________________
IPsec mailing list
IPsec@ietf.org <mailto:IPsec@ietf.org> 
https://www.ietf.org/mailman/listinfo/ipsec

v2.23.0 | Report a Bug | By Email