From nobody Tue Sep 4 01:07:08 2018 Return-Path: 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 85521130E00 for ; Tue, 4 Sep 2018 01:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 npG2K96u4Tbj for ; Tue, 4 Sep 2018 01:07:05 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 A0FBE128B14 for ; Tue, 4 Sep 2018 01:07:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1536048422; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=wntpDlNLVgn9CyJrUlYpzp9GxJq0Jwpl3VSOxAy9Wu8=; b=GsPdv6XUVoVz0czSNCb43EYoQZYCGPGIqN8YkMS8k2nmZJKa8mEkMF9R84M5NIOA 69aqkvI0B0YtQNP1ZSIi1aGQ89enXGxGQWtzeNGYvXaJQLlkVLHIgl0sGS1mHluG 4m0JMvFzOqrcpgb88+SLfPIyq+R9AXHctwoxeTFHj8A=; X-AuditID: c1b4fb25-8e7ff700000013ad-ac-5b8e3d267b2d Received: from ESESBMB505.ericsson.se (Unknown_Domain [153.88.183.118]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id E7.5D.05037.62D3E8B5; Tue, 4 Sep 2018 10:07:02 +0200 (CEST) Received: from ESESSMB502.ericsson.se (153.88.183.163) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 4 Sep 2018 10:07:02 +0200 Received: from nomadiclab.fi.eu.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.190) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Tue, 4 Sep 2018 10:07:02 +0200 Received: from nomadiclab.fi.eu.ericsson.se (localhost [127.0.0.1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id 4F03A4821CF; Tue, 4 Sep 2018 11:07:02 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id D51024821CB; Tue, 4 Sep 2018 11:07:01 +0300 (EEST) To: Tero Kivinen , Heinrich Singh CC: , References: <23433.17795.580382.531001@fireball.acr.fi> From: Mohit Sethi Message-ID: Date: Tue, 4 Sep 2018 11:07:01 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <23433.17795.580382.531001@fireball.acr.fi> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-AV-Checked: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZGbG9TFfNti/a4H6jpkXTgu1sFvu3vGCz OHr+OZvFvH3CDiweO2fdZfdYsuQnk8fhrwtZApijuGxSUnMyy1KL9O0SuDJmPlzIXHDHpGLN 0UbmBsbZWl2MnBwSAiYSj648Y+li5OIQEjjKKDFn3zpGkISQwFdGiVX3HSASFxglpqycwwrh bGaU6Lu/FcpZyCjxtuUTM0iLsECVxIzrl1lBbBEBb4m+NxPZQWxmAVWJT2/6oHb0MEl8WXiC DSTBJqAn0XnuOFgzr4C9xOO5v4GaOThYBFQkmpeD9YoKREisXv6CFaJEUOLkzCcsIDangIXE sg/dLBDzLSRmzj/PCGFrSyxb+JoZwhaXuPVkPhPEn8oSC1oWQb2mLrG14wDjBEbRWUjGzkIy ahaSUbOQjFrAyLKKUbQ4tTgpN93IWC+1KDO5uDg/Ty8vtWQTIzCSDm75rbqD8fIbx0OMAhyM Sjy8/037ooVYE8uKK3MPMUpwMCuJ8PrxA4V4UxIrq1KL8uOLSnNSiw8xSnOwKInzPjTfHCUk kJ5YkpqdmlqQWgSTZeLglGpgzFgeXvCkM/MC48+Srw95+fXeV6lbT7gatfb6nqnfPiVzLHRa HJa/5/zEe32+MTo22/i32PRveDtJ9LWYsmPWqTsZ88xcrx1O2nCwfcGzGXLnMy6X2t1u+7I0 9c1ha5M7QT8U5J+767VruNnacoUXrhB4U30gINA2LOf1tX+f2D8GR4uemKcbqsRSnJFoqMVc VJwIADrnaLugAgAA Archived-At: Subject: Re: [IPsec] [Lwip] The LWIG WG has placed draft-mglt-lwig-minimal-esp in state "Call For Adoption By WG Issued" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 08:07:06 -0000 Hi Tero, You raise some very interesting points here. I personally think that the draft can benefit from more information=20 about existing implementations of ESP. For example, documenting the fact = that many implementations do not send dummy packets or which=20 implementations use TFC. Adding specific example of=C2=A0 802.15.4 TSCH=20 networks and how synchronized time is available would also be helpful. Of course, this could be done before or after its adoption. --Mohit On 08/31/2018 04:41 PM, Tero Kivinen wrote: > Heinrich Singh writes: >> Text saying that you would loose some privacy by using fixed number >> of SPI does not absolve your responsibility. It should not recommend >> that. > There is no requirement for SPI to be random and originally it was > written that way so implementations can use whatever method to > allocate SPIs they like. For example they can use index to the SPI > table or whatever instead of allocating random SPI, or they could even > use pointer to the SPI structure in memory as SPI value (would of > course need some kind of checks that address is in area allocated for > SPIs and is aligned properly). > > Adding requirement that SPI needs to be random would be modifying the > base ESP, and is not in the scope of draft trying to define minimal > ESP. Saying that in contrained devices which have very few SPIs the > SPIs can be allocated using some other method than random is in scope > of the this draft. > > Also most of the constrained devices do not care about privacy as they > have fixed hardware address, stable IPv6 address and are not > associated with any person. Sensor sending wind speed, or temperature > to the cloud service does not have privacy requirements, sensors > sending temperature inside your house might have (as it might leak out > information whether you are home or not), but even in that case the > fact that it is your sensor sending information every 60 seconds does > not, only the data inside. > > Privacy requirements are not something that are always there, they > always depend heavily about what you do with the protocol. I.e., in > some cases the IP addresses, hardware addresses, SPIs etc need to be > protected against tracking, but in many cases they do not need to be. > > This document gives recommendation that in some cases it might be good > idea to use fixed SPI as it might make implementations smaller. I.e., > if the option is either not to use IPsec at all, as it is too big, or > to use IPsec with fixed SPI and other limitations that make it small, > I think the option with IPsec is better. > >> I do not know 802.15. Others can also say what they feel but from my >> experience simple monotonic sequence numbers are more easier than >> having a clocks. > True. But for example 802.15.4 TSCH (i.e., the protocol over which > 6TiSCH is working) does have globally shared clock which is kept in > sync with everybody. So in that kind of situations using clock as > monotonically incrementing counter and using that as sequence number > might save resources in constrained device. > >> This I think is a not a good idea. Sender and receiver can easily >> get out of sync because your rate of sending packets is not >> proportional to time. The receiver would need to allow very large >> window. The sender would still need to store time to flash in-case >> there is need for sync after device reset. > Sequence numbers are in one direction, i.e., I need to use > monotonically incrementing sequence number when I send, but that > sequence number does not have anything to do with other ends sequence > number. Also window size is need only if you have out of order > packets, and you care about replay protection. Both of them are > something that might not be something that constrained device cares. > > For example it might have internal replay protection for the messages > it sends, so it does not need to care whether there is replays on the > IPsec level, thus it can drop the whole replay protection checks > completely. Or it might work on the environment where out of order > deliver is not possible, thus it can just keep window size to 1. > > Also recipient cannot know which method other end is using when > generating sequence numbers, so it needs to do the replay protection > checking using whatever method it wants. It might need to store the > last received sequence number to the flash if it cares about replay > protections, or it can simply drop replay protection completely. > > On the other hand sender is REQUIRED to send sequence numbers in such > way they are monotonically incrementing (not necessarely by one), and > if it has any kind of other monotonically incrementing counter like > clock, it can use that to generate the sequence numbers and get rid of > the requirement to store outgoing sequence number to the flash. > >> What you mean implementations must discard dummy packets? Even >> non-constrained implementations must discard dummy packets so what >> is new here? > Yes. And that quite often happens automatically as there is nobody in > the device that wants to get packets with that protocol number. > > I have not actually never seen anybody sending dummy packets or TFC > padding packets in any implementations. I guess most of them know how > to ignore them, but sending them is not something people do. And I am > not even sure which implementation support for sending dummy packets. > TFC is most likely supported in some implementations (libreswan at > least seems to support it) as it is much easier to configure, just pad > all packets to fixed length. When sending dummy packets configuration > is much more complicated, as you need to configure what kind of > traffic pattern you want to maintain. > > So as those are not really used in non-constrained devices, I do not > think there is that big different in constrained devices. Again all of > this depends on the environment. For example some kind of door sensor > might want to keep sending packets every n seconds just not to leak > out when the door was opened and closed, but it might just use real > packets instead of dummy packets. I.e., it might be configured to send > the door status every 30 seconds, and in that packet it tells whether > door is now open or closed, and whether what transitions happened > during last 30 seconds. > > Privacy is so hard topic to solve that it always requires you to check > out the actual environment and use case where the protocol is used > before you can decide what kind of protections are needed. There is no > this thing solves all issues solution there. From nobody Tue Sep 4 04:56:01 2018 Return-Path: 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 C3A16130DCA; Tue, 4 Sep 2018 04:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 wbs7n1GBFCVt; Tue, 4 Sep 2018 04:55:57 -0700 (PDT) Received: from mail-lj1-f169.google.com (mail-lj1-f169.google.com [209.85.208.169]) (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 1D385128CF2; Tue, 4 Sep 2018 04:55:57 -0700 (PDT) Received: by mail-lj1-f169.google.com with SMTP id f1-v6so2872772ljc.9; Tue, 04 Sep 2018 04:55:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=49m4uNTnCvgLM50IpfJzAR3g5uAluw4azEooGw5jahQ=; b=i7r12G6QaaGhq6LWLeRz6Zg2V618QQ9JVUuLWvPFYlEFeflxrzvdeF1QZC73gcX012 9KsnKKAzbEqobzJdkYRcKcK5BAQSkhIGZicx79T1Z7yyqDiYhEZgwgNgh3Jp8LnUXk9I Sr3sbZgCBAs9orHXVahAhjlAGY5A2OquzajagT4NR4B4Rx8t82n/o0mtg+pNKuli5JQ3 zeHKi8dOX13vc94+OxhZ9a/icQsdq52YaZcJMn3OQDHvZ11vblm9HBadfIKd/NvSEg// VxSuYaRB6LNXSWgQ+Osyirh/wcv24jYU8r2yRDNbJjMHOuss/POtWl7MF/uONtKHnuty dhuA== X-Gm-Message-State: APzg51Az38SqMORdipsoATIMJw1QkH+QHiEGmKTm195YJ8ThXN4ArsJw i7g/4mAwj7YKpQFBDDyzebc60y4OUCOhBecKZZE= X-Google-Smtp-Source: ANB0VdZfbQDW+w5LkKVt9/4e79ouEDbKanyvKmfA/GLRvr1N8uyyTRTrEWqIWu2fHCPFQEeL63J6ijNoVwnMr+5YxQQ= X-Received: by 2002:a2e:9c82:: with SMTP id x2-v6mr14759276lji.131.1536062154008; Tue, 04 Sep 2018 04:55:54 -0700 (PDT) MIME-Version: 1.0 References: <23433.17795.580382.531001@fireball.acr.fi> In-Reply-To: From: Daniel Migault Date: Tue, 4 Sep 2018 07:55:42 -0400 Message-ID: To: Mohit Sethi Cc: Tero Kivinen , Heinrich Singh , IPsecME WG , lwip@ietf.org Content-Type: multipart/alternative; boundary="0000000000000aeec205750a57e5" Archived-At: Subject: Re: [IPsec] [Lwip] The LWIG WG has placed draft-mglt-lwig-minimal-esp in state "Call For Adoption By WG Issued" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 11:56:00 -0000 --0000000000000aeec205750a57e5 Content-Type: text/plain; charset="UTF-8" Hi, Just to mention that of course, the draft will be updated to reflect the discussions / clarifications raised on the mailing list. Yours, Daniel On Tue, Sep 4, 2018 at 4:07 AM Mohit Sethi wrote: > Hi Tero, > > You raise some very interesting points here. > > I personally think that the draft can benefit from more information > about existing implementations of ESP. For example, documenting the fact > that many implementations do not send dummy packets or which > implementations use TFC. Adding specific example of 802.15.4 TSCH > networks and how synchronized time is available would also be helpful. > > Of course, this could be done before or after its adoption. > > --Mohit > > > On 08/31/2018 04:41 PM, Tero Kivinen wrote: > > Heinrich Singh writes: > >> Text saying that you would loose some privacy by using fixed number > >> of SPI does not absolve your responsibility. It should not recommend > >> that. > > There is no requirement for SPI to be random and originally it was > > written that way so implementations can use whatever method to > > allocate SPIs they like. For example they can use index to the SPI > > table or whatever instead of allocating random SPI, or they could even > > use pointer to the SPI structure in memory as SPI value (would of > > course need some kind of checks that address is in area allocated for > > SPIs and is aligned properly). > > > > Adding requirement that SPI needs to be random would be modifying the > > base ESP, and is not in the scope of draft trying to define minimal > > ESP. Saying that in contrained devices which have very few SPIs the > > SPIs can be allocated using some other method than random is in scope > > of the this draft. > > > > Also most of the constrained devices do not care about privacy as they > > have fixed hardware address, stable IPv6 address and are not > > associated with any person. Sensor sending wind speed, or temperature > > to the cloud service does not have privacy requirements, sensors > > sending temperature inside your house might have (as it might leak out > > information whether you are home or not), but even in that case the > > fact that it is your sensor sending information every 60 seconds does > > not, only the data inside. > > > > Privacy requirements are not something that are always there, they > > always depend heavily about what you do with the protocol. I.e., in > > some cases the IP addresses, hardware addresses, SPIs etc need to be > > protected against tracking, but in many cases they do not need to be. > > > > This document gives recommendation that in some cases it might be good > > idea to use fixed SPI as it might make implementations smaller. I.e., > > if the option is either not to use IPsec at all, as it is too big, or > > to use IPsec with fixed SPI and other limitations that make it small, > > I think the option with IPsec is better. > > > >> I do not know 802.15. Others can also say what they feel but from my > >> experience simple monotonic sequence numbers are more easier than > >> having a clocks. > > True. But for example 802.15.4 TSCH (i.e., the protocol over which > > 6TiSCH is working) does have globally shared clock which is kept in > > sync with everybody. So in that kind of situations using clock as > > monotonically incrementing counter and using that as sequence number > > might save resources in constrained device. > > > >> This I think is a not a good idea. Sender and receiver can easily > >> get out of sync because your rate of sending packets is not > >> proportional to time. The receiver would need to allow very large > >> window. The sender would still need to store time to flash in-case > >> there is need for sync after device reset. > > Sequence numbers are in one direction, i.e., I need to use > > monotonically incrementing sequence number when I send, but that > > sequence number does not have anything to do with other ends sequence > > number. Also window size is need only if you have out of order > > packets, and you care about replay protection. Both of them are > > something that might not be something that constrained device cares. > > > > For example it might have internal replay protection for the messages > > it sends, so it does not need to care whether there is replays on the > > IPsec level, thus it can drop the whole replay protection checks > > completely. Or it might work on the environment where out of order > > deliver is not possible, thus it can just keep window size to 1. > > > > Also recipient cannot know which method other end is using when > > generating sequence numbers, so it needs to do the replay protection > > checking using whatever method it wants. It might need to store the > > last received sequence number to the flash if it cares about replay > > protections, or it can simply drop replay protection completely. > > > > On the other hand sender is REQUIRED to send sequence numbers in such > > way they are monotonically incrementing (not necessarely by one), and > > if it has any kind of other monotonically incrementing counter like > > clock, it can use that to generate the sequence numbers and get rid of > > the requirement to store outgoing sequence number to the flash. > > > >> What you mean implementations must discard dummy packets? Even > >> non-constrained implementations must discard dummy packets so what > >> is new here? > > Yes. And that quite often happens automatically as there is nobody in > > the device that wants to get packets with that protocol number. > > > > I have not actually never seen anybody sending dummy packets or TFC > > padding packets in any implementations. I guess most of them know how > > to ignore them, but sending them is not something people do. And I am > > not even sure which implementation support for sending dummy packets. > > TFC is most likely supported in some implementations (libreswan at > > least seems to support it) as it is much easier to configure, just pad > > all packets to fixed length. When sending dummy packets configuration > > is much more complicated, as you need to configure what kind of > > traffic pattern you want to maintain. > > > > So as those are not really used in non-constrained devices, I do not > > think there is that big different in constrained devices. Again all of > > this depends on the environment. For example some kind of door sensor > > might want to keep sending packets every n seconds just not to leak > > out when the door was opened and closed, but it might just use real > > packets instead of dummy packets. I.e., it might be configured to send > > the door status every 30 seconds, and in that packet it tells whether > > door is now open or closed, and whether what transitions happened > > during last 30 seconds. > > > > Privacy is so hard topic to solve that it always requires you to check > > out the actual environment and use case where the protocol is used > > before you can decide what kind of protections are needed. There is no > > this thing solves all issues solution there. > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --0000000000000aeec205750a57e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Just to mention tha= t of course, the draft will be updated to reflect the discussions / clarifi= cations raised on the mailing list.

Yours,
Daniel

On Tue, Sep 4, 2018 at 4:07 AM Mohit Sethi <mohit.m.sethi@ericsson.com> wrote:
Hi Tero,

You raise some very interesting points here.

I personally think that the draft can benefit from more information
about existing implementations of ESP. For example, documenting the fact that many implementations do not send dummy packets or which
implementations use TFC. Adding specific example of=C2=A0 802.15.4 TSCH networks and how synchronized time is available would also be helpful.

Of course, this could be done before or after its adoption.

--Mohit


On 08/31/2018 04:41 PM, Tero Kivinen wrote:
> Heinrich Singh writes:
>> Text saying that you would loose some privacy by using fixed numbe= r
>> of SPI does not absolve your responsibility. It should not recomme= nd
>> that.
> There is no requirement for SPI to be random and originally it was
> written that way so implementations can use whatever method to
> allocate SPIs they like. For example they can use index to the SPI
> table or whatever instead of allocating random SPI, or they could even=
> use pointer to the SPI structure in memory as SPI value (would of
> course need some kind of checks that address is in area allocated for<= br> > SPIs and is aligned properly).
>
> Adding requirement that SPI needs to be random would be modifying the<= br> > base ESP, and is not in the scope of draft trying to define minimal > ESP. Saying that in contrained devices which have very few SPIs the > SPIs can be allocated using some other method than random is in scope<= br> > of the this draft.
>
> Also most of the constrained devices do not care about privacy as they=
> have fixed hardware address, stable IPv6 address and are not
> associated with any person. Sensor sending wind speed, or temperature<= br> > to the cloud service does not have privacy requirements, sensors
> sending temperature inside your house might have (as it might leak out=
> information whether you are home or not), but even in that case the > fact that it is your sensor sending information every 60 seconds does<= br> > not, only the data inside.
>
> Privacy requirements are not something that are always there, they
> always depend heavily about what you do with the protocol. I.e., in > some cases the IP addresses, hardware addresses, SPIs etc need to be > protected against tracking, but in many cases they do not need to be.<= br> >
> This document gives recommendation that in some cases it might be good=
> idea to use fixed SPI as it might make implementations smaller. I.e.,<= br> > if the option is either not to use IPsec at all, as it is too big, or<= br> > to use IPsec with fixed SPI and other limitations that make it small,<= br> > I think the option with IPsec is better.
>
>> I do not know 802.15. Others can also say what they feel but from = my
>> experience simple monotonic sequence numbers are more easier than<= br> >> having a clocks.
> True. But for example 802.15.4 TSCH (i.e., the protocol over which
> 6TiSCH is working) does have globally shared clock which is kept in > sync with everybody. So in that kind of situations using clock as
> monotonically incrementing counter and using that as sequence number > might save resources in constrained device.
>
>> This I think is a not a good idea. Sender and receiver can easily<= br> >> get out of sync because your rate of sending packets is not
>> proportional to time. The receiver would need to allow very large<= br> >> window. The sender would still need to store time to flash in-case=
>> there is need for sync after device reset.
> Sequence numbers are in one direction, i.e., I need to use
> monotonically incrementing sequence number when I send, but that
> sequence number does not have anything to do with other ends sequence<= br> > number. Also window size is need only if you have out of order
> packets, and you care about replay protection. Both of them are
> something that might not be something that constrained device cares. >
> For example it might have internal replay protection for the messages<= br> > it sends, so it does not need to care whether there is replays on the<= br> > IPsec level, thus it can drop the whole replay protection checks
> completely. Or it might work on the environment where out of order
> deliver is not possible, thus it can just keep window size to 1.
>
> Also recipient cannot know which method other end is using when
> generating sequence numbers, so it needs to do the replay protection > checking using whatever method it wants. It might need to store the > last received sequence number to the flash if it cares about replay > protections, or it can simply drop replay protection completely.
>
> On the other hand sender is REQUIRED to send sequence numbers in such<= br> > way they are monotonically incrementing (not necessarely by one), and<= br> > if it has any kind of other monotonically incrementing counter like > clock, it can use that to generate the sequence numbers and get rid of=
> the requirement to store outgoing sequence number to the flash.
>
>> What you mean implementations must discard dummy packets? Even
>> non-constrained implementations must discard dummy packets so what=
>> is new here?
> Yes. And that quite often happens automatically as there is nobody in<= br> > the device that wants to get packets with that protocol number.
>
> I have not actually never seen anybody sending dummy packets or TFC > padding packets in any implementations. I guess most of them know how<= br> > to ignore them, but sending them is not something people do. And I am<= br> > not even sure which implementation support for sending dummy packets.<= br> > TFC is most likely supported in some implementations (libreswan at
> least seems to support it) as it is much easier to configure, just pad=
> all packets to fixed length. When sending dummy packets configuration<= br> > is much more complicated, as you need to configure what kind of
> traffic pattern you want to maintain.
>
> So as those are not really used in non-constrained devices, I do not > think there is that big different in constrained devices. Again all of=
> this depends on the environment. For example some kind of door sensor<= br> > might want to keep sending packets every n seconds just not to leak > out when the door was opened and closed, but it might just use real > packets instead of dummy packets. I.e., it might be configured to send=
> the door status every 30 seconds, and in that packet it tells whether<= br> > door is now open or closed, and whether what transitions happened
> during last 30 seconds.
>
> Privacy is so hard topic to solve that it always requires you to check=
> out the actual environment and use case where the protocol is used
> before you can decide what kind of protections are needed. There is no=
> this thing solves all issues solution there.


_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--0000000000000aeec205750a57e5-- From nobody Wed Sep 5 21:21:30 2018 Return-Path: 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 7067F130E5B; Wed, 5 Sep 2018 21:21:23 -0700 (PDT) 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 8Wk3eTFZPkyJ; Wed, 5 Sep 2018 21:21:22 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 A771A130E5A; Wed, 5 Sep 2018 21:21:21 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id b19-v6so9971926wme.3; Wed, 05 Sep 2018 21:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WYzHug5i4bU+V7qaElbbVKrXoDGfP4yRKFuAiyMjKZk=; b=Jqyso8WJrxBOAihBPRPIhbsHgBQqfVBKTXWYlbH9jgeFpSWKhgjnRYiTCtgbwPYuZw OM1XVabp1YHjnvnpQ7ghh/n15h1Xcd52n+ehJN1iv/Ll+emxu5LPbK+mwmZPnNwvuQW4 Z20/eXXufVM3pWYozNFi+uioq+5eg+XQKv2NRAxUlmIkDbbyhrgBLleYUgyl3hEcZ2ir g67UupXAAmEGDR9AOvxCZxnMR8aO7fyluKl9UP5PEil2z7PMLYGDgSj5dFUOSZpzRJxI wbkNMKZAaM4Xhvj1FJrXtjp2fFrzxIVkXDlERmwYMit5BbKg0L++O05yYaiTqZYH9eAQ 7OpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WYzHug5i4bU+V7qaElbbVKrXoDGfP4yRKFuAiyMjKZk=; b=aSV58oaIkZpFoJBSpdye75WhYO0K5xV7d9LKFayNfcgrQPRNItv/eyJKBTr34y609z qi4kdhsoqcLbwi6z2SHx0+VQwhiX+hGCdq4EG9GJ4ozacVgi2eopjbj2sBZOSzFX9OhZ pseSBl/krKDhu+2Cb6DGby1gTZSfgjaEcJwGJY6EHuOB+A4AgtWfXV+3KMVKXyS1qs4M NsR1TmIzmjhkWF/S2eycoFh/P6ZEnJrrRba2haqORrUDvYc00H3QhIZ3uwXPf2JVpVoU PU4XOdHzX3YTLI8nQpuOGw47JxdVD/fEe31UNjCZxBQWlg4x2m6gGpi2SimNSNKltHbl uAPQ== X-Gm-Message-State: APzg51C0rtbZ19nlQRl6VT5GYDJRXlOma8hRR7Fl7PInQbixwNoEs4YL se71tlvfHxa5/EznHexWXcAVeFNSWO0lRP/cNsM= X-Google-Smtp-Source: ANB0VdYSaPF5dspRHefzrtO6QHtV3U8CKEWyJ/afdjKsfgr/Jqew3APFFpvfLsrKiZ30vC3nJKFBAZ7WMbYtaZqvo4Q= X-Received: by 2002:a1c:2d54:: with SMTP id t81-v6mr864864wmt.31.1536207680261; Wed, 05 Sep 2018 21:21:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Heinrich Singh Date: Thu, 6 Sep 2018 07:21:09 +0300 Message-ID: To: zhencao.ietf@gmail.com Cc: lwip@ietf.org, ipsec@ietf.org Content-Type: multipart/alternative; boundary="0000000000001553fe05752c3908" Archived-At: Subject: Re: [IPsec] [Lwip] The LWIG WG has placed draft-mglt-lwig-minimal-esp in state "Call For Adoption By WG Issued" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 04:21:24 -0000 --0000000000001553fe05752c3908 Content-Type: text/plain; charset="UTF-8" About RFC 6973, I mean that we have privacy guidelines. RFC 6973 does not talk about ESP. But can we publish a draft saying don't use ESP privacy features for some devices. It is different story if other implementations don't use it also. Then OK. Ciao Heinrich On Fri, 31 Aug 2018 at 14:05, Zhen Cao wrote: > Hello Heinrich, > > Thanks for your review and comments. See my comments&questions to > confirm inline. > > > I don't know why IETF would publish this document when they have rfc > 6973. > This draft has much content not stated in RFC6973 (which is a general > recommendation) , e.g., overhead analysis /delay/handshake performance > analysis. > > > I want to see some actual performance from a real ESP implementation > where privacy is protected and energy is saved by tweaking the TFC and how > often dummy packet is sent. > > Are you saying that you would like to see more implementation guidance > other than what's been already provided? or do you think the current > recommendations are unreasonable? > > Btw, sharing the implementation code is encouraged but not mandatory > in IETF. We by default trust the authors because they are foremost > responsible for their work (particularly informational ones). > > Best regards, > Zhen > > > > Ciao > > Heinrich > > _______________________________________________ > > Lwip mailing list > > Lwip@ietf.org > > https://www.ietf.org/mailman/listinfo/lwip > --0000000000001553fe05752c3908 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
About RFC 6973, I mean that we have privacy guidelines. RF= C 6973 does not talk about ESP. But can we publish a draft saying don't= use ESP privacy features for some devices. It is different story if other = implementations don't use it also. Then OK.

Ciao
Heinrich

= On Fri, 31 Aug 2018 at 14:05, Zhen Cao <zhencao.ietf@gmail.com> wrote:
Hello Heinrich,

Thanks for your review and comments.=C2=A0 See my comments&questions to=
confirm inline.

> I don't know why IETF would publish this document when they have r= fc 6973.
This draft has much content not stated in RFC6973 (which is a general
recommendation) , e.g., overhead analysis /delay/handshake performance
analysis.

> I want to see some actual performance from a real ESP implementation w= here privacy is protected and energy is saved by tweaking the TFC and how o= ften dummy packet is sent.

Are you saying that you would like to see more implementation guidance
other than what's been already provided?=C2=A0 or do you think the curr= ent
recommendations are unreasonable?

Btw, sharing the implementation code is encouraged but not mandatory
in IETF.=C2=A0 We by default trust the authors because they are foremost responsible for their work (particularly informational ones).

Best regards,
Zhen
>
> Ciao
> Heinrich
> _______________________________________________
> Lwip mailing list
> Lwip@ietf.org > https://www.ietf.org/mailman/listinfo/lwip
--0000000000001553fe05752c3908-- From nobody Fri Sep 7 06:23:59 2018 Return-Path: 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 929DC130E04; Fri, 7 Sep 2018 06:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 g1pz8zDELjt5; Fri, 7 Sep 2018 06:23:56 -0700 (PDT) Received: from akamail.elvis.ru (akamail.elvis.ru [82.138.51.96]) (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 C3AE0130E00; Fri, 7 Sep 2018 06:23:52 -0700 (PDT) Received: from kmail.elvis.ru ([93.188.44.208]) by akamail.elvis.ru with esmtp (Exim 4.88) (envelope-from ) id 1fyGjm-0003Ww-AB; Fri, 07 Sep 2018 16:23:51 +0300 Received: from robin.office.elvis.ru ([10.111.1.40]) by kmail.elvis.ru with esmtp (Exim 4.88) (envelope-from ) id 1fyGjl-0003wF-M3; Fri, 07 Sep 2018 16:23:50 +0300 Received: from buildpc (10.111.10.33) by robin.office.elvis.ru (10.111.1.40) with Microsoft SMTP Server id 14.3.382.0; Fri, 7 Sep 2018 16:23:49 +0300 From: Valery Smyslov To: IPsecME WG CC: References: <153632409170.28963.3858352353321879475.idtracker@ietfa.amsl.com> In-Reply-To: <153632409170.28963.3858352353321879475.idtracker@ietfa.amsl.com> Date: Fri, 7 Sep 2018 16:23:39 +0300 Message-ID: <058901d446ad$fd78b5a0$f86a20e0$@elvis.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJcXB691A5/IRakRUGL31dObam09KPUoUAg Content-Language: ru X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Status: not scanned, disabled by settings X-KLMS-AntiSpam-Interceptor-Info: not scanned X-KLMS-AntiPhishing: Clean, 2018/09/06 15:32:42 X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.721, bases: 2018/09/07 08:55:00 #8682191 X-KLMS-AntiVirus-Status: Clean, skipped Archived-At: Subject: Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-tcp-guidelines-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 13:23:58 -0000 Hi, I've posted a draft with clarifications and implementation guidelines for RFC8229. These clarifications and recommendations are based on experience of implementing TCP encapsulation and testing it in various IKEv2 scenarios. Feedback of any sort is highly appreciated. Regards, Valery. > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Friday, September 07, 2018 3:42 PM > To: Valery Smyslov > Subject: New Version Notification for draft-smyslov-ipsecme-tcp-guidelines-00.txt > > > A new version of I-D, draft-smyslov-ipsecme-tcp-guidelines-00.txt > has been successfully submitted by Valery Smyslov and posted to the > IETF repository. > > Name: draft-smyslov-ipsecme-tcp-guidelines > Revision: 00 > Title: Clarifications and Implementation Guidelines for using TCP Encapsulation in IKEv2 > Document date: 2018-09-07 > Group: Individual Submission > Pages: 8 > URL: https://www.ietf.org/internet-drafts/draft-smyslov-ipsecme-tcp-guidelines-00.txt > Status: https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-tcp-guidelines/ > Htmlized: https://tools.ietf.org/html/draft-smyslov-ipsecme-tcp-guidelines-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-smyslov-ipsecme-tcp-guidelines > > > Abstract: > The Internet Key Exchange Protocol version 2 (IKEv2) defined in > [RFC7296] uses UDP transport for its messages. [RFC8229] specifies a > way to encapsulate IKEv2 and ESP (Encapsulating Security Payload) > messages in TCP, thus making possible to use them in network > environments that block UDP traffic. However, some nuances of using > TCP in IKEv2 are not covered by that specification. This document > provides clarifications and implementation guidelines for [RFC8229]. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat From nobody Fri Sep 7 07:06:09 2018 Return-Path: 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 4721F129AB8; Fri, 7 Sep 2018 07:06:07 -0700 (PDT) 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 geGS1DwIUgFM; Fri, 7 Sep 2018 07:06:04 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 6D6C5130DD5; Fri, 7 Sep 2018 07:06:04 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 426K3Y1zXHzD0G; Fri, 7 Sep 2018 16:06:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1536329161; bh=AR5uIql1P+S6Ceff5pTdHI1kdGCSBxrONq7ELeGPkT8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=T2cnC8mzfFZyQNRHt6TjJHHOWeQwoBWus7q3lUAKSn9z8ThWN63PRGTB4uGyC87pG z52OwiKF7TrwGAU3hG63eMvNzA5GDCF2haW3q1QEwm30XigmUMR7tXDvMF0SVAB9yS ciVqsli9XPkFuxmfcdfVk4+AG4iI8JXM2WFc1ZQc= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id JzRYEo_mu_Sq; Fri, 7 Sep 2018 16:05:59 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 7 Sep 2018 16:05:58 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 213DE5E2A4E; Fri, 7 Sep 2018 10:05:57 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 213DE5E2A4E Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 1ACA84027A89; Fri, 7 Sep 2018 10:05:57 -0400 (EDT) Date: Fri, 7 Sep 2018 10:05:57 -0400 (EDT) From: Paul Wouters To: Valery Smyslov cc: IPsecME WG , draft-ietf-ipsecme-tcp-encaps@ietf.org In-Reply-To: <058901d446ad$fd78b5a0$f86a20e0$@elvis.ru> Message-ID: References: <153632409170.28963.3858352353321879475.idtracker@ietfa.amsl.com> <058901d446ad$fd78b5a0$f86a20e0$@elvis.ru> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-tcp-guidelines-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 14:06:08 -0000 On Fri, 7 Sep 2018, Valery Smyslov wrote: > I've posted a draft with clarifications and implementation guidelines > for RFC8229. These clarifications and recommendations are based > on experience of implementing TCP encapsulation and testing it in > various IKEv2 scenarios. > > Feedback of any sort is highly appreciated. I would cut a lot of the introduction / abstract and come straight to the point. Simiarly, further one not provide as much details and just come to the point faster. I don't see any consideration in the document about deployments that use a TCP proxy in front of the IKE daemon. In those scenarios, the daemon might not even know TCP is used or the proxy code is written in a way that only minimal changes to the IKEv2 core are needed. So a lot of decisions you specify, such as not sending retransmits, might not be possible for those kind of implementations, and so this document dictating them for make interop harder, not easier. As this also touches on message IDs, and I think we might have some msgid deadlocks even in the UDP only case, perhaps a clarifying document could add some non-TCP items as well? And the TCP part could be part of the new clarification draft ? Paul From nobody Fri Sep 7 07:19:17 2018 Return-Path: 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 DA5CE128766; Fri, 7 Sep 2018 07:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 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, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no 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 IQaFzLqfHN2D; Fri, 7 Sep 2018 07:19:12 -0700 (PDT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 0EF4D126CB6; Fri, 7 Sep 2018 07:19:12 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id e23-v6so12141886lfc.13; Fri, 07 Sep 2018 07:19:11 -0700 (PDT) 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:content-transfer-encoding:thread-index :content-language; bh=o5isiscANTwtQM6+gsWYwOt3FX+8ARHGYgWErVtlWd0=; b=HMXf1nnomT5HOMhFULQpejgW+ya+8tqM9LCv5H1zIF9uOh2xcvS0mM8nh3u0dvqLe9 kHrQ1XFbZhNh+ERc6WmYTAJa8y8fOgIhLQ0BAz0+beTup8ySNa+NDnvImQcuE/kIPIi8 FqkVlp4PMi3V0iz0zYWc7XU6Br3r0s7aiq1/4zo7R8s9lBVwOxZyVPJCSpt4CNz0I/5z 5bZYk4tzp3fBcUcOaauQrDQX2Jzn23eI0fr6fR86l9zNmPwrNPpykON2fzVn8U9dAzB+ dcaRRY3NtP5bxR6vuoFZ7TA6LV5n2EF8b/U7v+74LdUW8klRXXspIn8V2AaDIb93PCqY rc8w== 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:content-transfer-encoding:thread-index :content-language; bh=o5isiscANTwtQM6+gsWYwOt3FX+8ARHGYgWErVtlWd0=; b=Z1gza+Uz2racOPiGlrB67pHR6b5y4kX8Qc6RU3YFzinK/rLWQKSkL+di5k0Nz2gYTG 5SOe8scPDqCNM+rnPGdAuzX2h+nuUqU6T15JUgWvt+TvdU0zHPzcFSlAQ9i0A92X9hVP jgdzfQpeVd0L1sSqMJjTAimWABBhY/6NJKKKJK4GM+d3PLkdZBhZg4gy7Se4q2H6sWfI 657AvZxb6e1Y2TsxjI0ZOodDJEavlhWuQuydG8AqXh/R8SgS4IZT9sJFaXxfYIMAKQLT UmaEhwHHpSm9VP6nCqXcl/uoj3//jeI5hpmhaZn7SocsFIkyFrsPCXdfbw7Xro0Um1/7 ATFA== X-Gm-Message-State: APzg51DpZ/Pv6wsaljHYfjpgVVujAN70WS89biZPdDvi0iXLhPhLfzLG 2mw4NVCRx5vLXE8M0TMVkJkzfrQU X-Google-Smtp-Source: ANB0Vdbrci5vfU27mUWl/rTc6Zc3v509YUNVpoz4gBK4yjSlQget4FFAGRMkrmnsRKP1kRRh0Bg9Lw== X-Received: by 2002:a19:7118:: with SMTP id m24-v6mr5202569lfc.6.1536329950038; Fri, 07 Sep 2018 07:19:10 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id y16-v6sm1322585lje.30.2018.09.07.07.19.08 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 07 Sep 2018 07:19:09 -0700 (PDT) From: "Valery Smyslov" To: "'Paul Wouters'" , "'Valery Smyslov'" Cc: "'IPsecME WG'" , References: <153632409170.28963.3858352353321879475.idtracker@ietfa.amsl.com> <058901d446ad$fd78b5a0$f86a20e0$@elvis.ru> In-Reply-To: Date: Fri, 7 Sep 2018 17:18:58 +0300 Message-ID: <059d01d446b5$b85610a0$290231e0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJcXB691A5/IRakRUGL31dObam09AIk+U4iAZLUdFujtvI14A== Content-Language: ru Archived-At: Subject: Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-tcp-guidelines-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 14:19:15 -0000 Hi Paul, > > I've posted a draft with clarifications and implementation guidelines > > for RFC8229. These clarifications and recommendations are based > > on experience of implementing TCP encapsulation and testing it in > > various IKEv2 scenarios. > > > > Feedback of any sort is highly appreciated. > > I would cut a lot of the introduction / abstract and come straight to > the point. Simiarly, further one not provide as much details and just > come to the point faster. I tried to be pedant :-) > I don't see any consideration in the document about deployments that > use a TCP proxy in front of the IKE daemon. In those scenarios, the > daemon might not even know TCP is used or the proxy code is written in > a way that only minimal changes to the IKEv2 core are needed. Is it ever possible? My experience shows that adding TCP encapsulation influences IKEv2 code pretty highly. > So a lot of decisions you specify, such as not sending retransmits, might not > be possible for those kind of implementations, and so this document > dictating them for make interop harder, not easier. Why? Can you clarify in which cases interop will be harder? > As this also touches on message IDs, and I think we might have some > msgid deadlocks even in the UDP only case, perhaps a clarifying If you mean MOBIKE, I agree with you that deadlocks seem to be possible. > document could add some non-TCP items as well? And the TCP part could > be part of the new clarification draft ? Not sure it's worth to mix them. Regards, Valery. > > Paul > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Sep 7 08:48:12 2018 Return-Path: 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 AE590130DD4; Fri, 7 Sep 2018 08:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 BB2DzB7JlvPC; Fri, 7 Sep 2018 08:48:07 -0700 (PDT) Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.67]) (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 C943E12F1AB; Fri, 7 Sep 2018 08:48:07 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.22/8.16.0.22) with SMTP id w87FfOPf028838; Fri, 7 Sep 2018 08:48:00 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=Jm24OJ3Vk7b+Jxze3sZeO0WEt36aEmwVPwEqR2xDe8s=; b=hozWfxlmpjCgm+a2Oi4/C1hDaJ6HyPRoaGFYKks9/dPARPbRjHop6bOIO+S9JZXLkyD5 GoxFrkD60miAYhoY3sFt3X/Bgi6mQsHPrX6RNkSBxFprc7WG4RDJ1L9PkQWNTRI4Xzvs ZZ0dCvrVQCPsRBc0b+UtxgptNcrrIx1ZIWmnqtI6P7Uz7YWEL5E5LiRUkgNYldVyxM5I QchOSCu79CDNj1/skdSHPWwc++MYsJVwwGoUFJOGPp56MjJ5i7pGfc+bFCVCC9VJk4xL Un6OyV+20gvOJ3fOOMFpZ5sZOWN4zOAKPo9/hPiNulD82NtMg+MxTbmsTFIUogEOpEc5 xA== Received: from ma1-mtap-s01.corp.apple.com (ma1-mtap-s01.corp.apple.com [17.40.76.5]) by nwk-aaemail-lapp02.apple.com with ESMTP id 2m7qbrj2s8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 07 Sep 2018 08:47:59 -0700 MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by ma1-mtap-s01.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PEO00JWLZVZKL50@ma1-mtap-s01.corp.apple.com>; Fri, 07 Sep 2018 08:47:59 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PEO00F00YES5E00@nwk-mmpp-sz10.apple.com>; Fri, 07 Sep 2018 08:47:58 -0700 (PDT) X-Va-A: X-Va-T-CD: c32dbaa97f6cb839155684977103028d X-Va-E-CD: 5ebd350c3104e03c31bb529541a1dbe7 X-Va-R-CD: b3d5e4c71d6ae56c65ff667bce554311 X-Va-CD: 0 X-Va-ID: 48e610fe-93c2-4612-ae46-d32dce733084 X-V-A: X-V-T-CD: c32dbaa97f6cb839155684977103028d X-V-E-CD: 5ebd350c3104e03c31bb529541a1dbe7 X-V-R-CD: b3d5e4c71d6ae56c65ff667bce554311 X-V-CD: 0 X-V-ID: ae6506f6-64a0-48cf-854a-58dd16e6af4e Received: from process_milters-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PEO00200ZQDZM00@nwk-mmpp-sz10.apple.com>; Fri, 07 Sep 2018 08:47:58 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-09-07_08:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp15.corp.apple.com-10000_instance1 Received: from tpauly.scv.apple.com (tpauly.scv.apple.com [17.192.171.37]) by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PEO0076ZZVXKK20@nwk-mmpp-sz10.apple.com>; Fri, 07 Sep 2018 08:47:57 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: <059d01d446b5$b85610a0$290231e0$@gmail.com> Date: Fri, 07 Sep 2018 08:47:57 -0700 Cc: Paul Wouters , Valery Smyslov , IPsecME WG , draft-ietf-ipsecme-tcp-encaps@ietf.org Content-transfer-encoding: quoted-printable Message-id: <27A951D3-CA76-4C38-990B-6553B4B0CA74@apple.com> References: <153632409170.28963.3858352353321879475.idtracker@ietfa.amsl.com> <058901d446ad$fd78b5a0$f86a20e0$@elvis.ru> <059d01d446b5$b85610a0$290231e0$@gmail.com> To: Valery Smyslov X-Mailer: Apple Mail (2.3445.100.21) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-07_08:, , signatures=0 Archived-At: Subject: Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-tcp-guidelines-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 15:48:10 -0000 Hi Valery, Thanks for sharing this! I agree with the points you bring up for MOBIKE (not changing the = message ID, and needing to recalculate NAT detection payloads). Those = are useful to clarify. Regarding retransmissions/puzzles/error handling, I agree with Paul that = the recommendations being provided in your draft are potentially harmful = to interoperability. We specifically did not include those in RFC8229 = because it is not only possible, but likely, that some deployments will = use TCP as a proxying layer that=E2=80=99s not directly implemented on = the IKE endpoint, and that the IKE messages may be sometimes transmitted = over both UDP and TCP (UDP behind TCP). This is, in fact, how we did our = initial testing and bringup of the functionality. Not retransmitting (or the other examples) assumes that the reliable = link is end-to-end, even though that is not guaranteed or required by = the spec. Can you clarify why an implementation would require = modification of the protocol such that TCP encapsulation could not occur = in a proxy? The one case I see is client-side MOBIKE, but I don=E2=80=99t = think the server needs to do anything special (and clients that don=E2=80=99= t want to do fancy MOBIKE fallback between UDP and TCP don=E2=80=99t = need to change). Thanks, Tommy > On Sep 7, 2018, at 7:18 AM, Valery Smyslov = wrote: >=20 > Hi Paul, >=20 >>> I've posted a draft with clarifications and implementation = guidelines >>> for RFC8229. These clarifications and recommendations are based >>> on experience of implementing TCP encapsulation and testing it in >>> various IKEv2 scenarios. >>>=20 >>> Feedback of any sort is highly appreciated. >>=20 >> I would cut a lot of the introduction / abstract and come straight to >> the point. Simiarly, further one not provide as much details and just >> come to the point faster. >=20 > I tried to be pedant :-)=20 >=20 >> I don't see any consideration in the document about deployments that >> use a TCP proxy in front of the IKE daemon. In those scenarios, the >> daemon might not even know TCP is used or the proxy code is written = in >> a way that only minimal changes to the IKEv2 core are needed.=20 >=20 > Is it ever possible? My experience shows that adding TCP encapsulation > influences IKEv2 code pretty highly. >=20 >> So a lot of decisions you specify, such as not sending retransmits, = might not >> be possible for those kind of implementations, and so this document >> dictating them for make interop harder, not easier. >=20 > Why? Can you clarify in which cases interop will be harder? >=20 >> As this also touches on message IDs, and I think we might have some >> msgid deadlocks even in the UDP only case, perhaps a clarifying >=20 > If you mean MOBIKE, I agree with you that deadlocks seem to be = possible. >=20 >> document could add some non-TCP items as well? And the TCP part could >> be part of the new clarification draft ? >=20 > Not sure it's worth to mix them.=20 >=20 > Regards, > Valery. >=20 >>=20 >> Paul >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 From nobody Fri Sep 7 18:26:05 2018 Return-Path: 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 53D21130E28; Fri, 7 Sep 2018 18:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.503 X-Spam-Level: X-Spam-Status: No, score=-1.503 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.146, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 g1NeQDHZmnIC; Fri, 7 Sep 2018 18:25:55 -0700 (PDT) Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com [209.85.208.175]) (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 DCCF2130DD0; Fri, 7 Sep 2018 18:25:54 -0700 (PDT) Received: by mail-lj1-f175.google.com with SMTP id q127-v6so13606294ljq.11; Fri, 07 Sep 2018 18:25:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uMMy+KfA++Dl59J1uAwE0+LtYm9D9oRwZq4gJmadIlc=; b=a+vqgR1XgXOttdJKRge+c2Pto3M0dgiX7CRatyj/1L6oJfuuyQyeRwW4X4YqADznTY Q/+lby1A2VD7QovfurCu7CNndapIj4I36GMjYkduufF5iHDJUS+QfjDYJvH1VPsIM/Ub /nLvGLwDZk8FpyhSYH4yzbcHwRw/SXejsJC+0FNXjbk2B9t4vLjrDUSvsrsCAuKNY4Wm UAawfnNDe2lVjULOtEntlwh2B8081j/6uiu1O6BndFDmwdO1b9cmhNi3HOfTwBDqY1EK 7zsxFqYOuJE7syDccRRoY9cnSsCEUIOEworF8aqNUSaRLW6eGY0s3H8KH/ZPheCpaE4L E2qQ== X-Gm-Message-State: APzg51AloHea5W85ucM2uMz4wki+7i6ANJqcUHrdJli2dERBYxeIqAFX 7k+08EdLm2kUekKeKYz4H9/MTKStJQ8YFy976k4= X-Google-Smtp-Source: ANB0VdbkhwRqvhRdN3HmFqj6RyHO3JaPn0fJ/ihKfp/rVlNLERh2pjGOMiCIYNh9n3QbyRZl46IiFkDrf8fi1a3jrZU= X-Received: by 2002:a2e:550b:: with SMTP id j11-v6mr6571143ljb.124.1536369952991; Fri, 07 Sep 2018 18:25:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Daniel Migault Date: Fri, 7 Sep 2018 21:25:40 -0400 Message-ID: To: Heinrich Singh Cc: zhencao.ietf@gmail.com, IPsecME WG , lwip@ietf.org Content-Type: multipart/alternative; boundary="0000000000004aaf3c05755201de" Archived-At: Subject: Re: [IPsec] [Lwip] The LWIG WG has placed draft-mglt-lwig-minimal-esp in state "Call For Adoption By WG Issued" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2018 01:25:57 -0000 --0000000000004aaf3c05755201de Content-Type: text/plain; charset="UTF-8" Thanks for the feed back, we will careful on the wording and make sure we address this. Thanks, Yours, Daniel --0000000000004aaf3c05755201de Content-Type: text/html; charset="UTF-8"
Thanks for the feed back, we will careful on the wording and make sure we address this.
Thanks,
Yours,
Daniel
--0000000000004aaf3c05755201de-- From nobody Mon Sep 10 05:14:59 2018 Return-Path: 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 99E5A130EB8; Mon, 10 Sep 2018 05:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 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, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no 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 AFa8-EiN6xZb; Mon, 10 Sep 2018 05:14:55 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 49FD8130EAE; Mon, 10 Sep 2018 05:14:55 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id v9-v6so17692953ljk.4; Mon, 10 Sep 2018 05:14:55 -0700 (PDT) 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:content-transfer-encoding:thread-index :content-language; bh=CaxFlKme+x4t2gA/1jFl4yc5BZUJn4c8gFwVGUjPow4=; b=Kygo7+Qp01vwnOh1Xxn/O+lvugzUBObPzlS8IelO5g6WcQ7dy/ILMcISCjhEhUsYg7 8W7FCB2rRCkTrwOTpGgvKCbuUR/Ujjts88To/Gg9p5MIvdMNP5VclOWuksPYqllgJOjR Zha2mmkqAhoLIBoZdUOSdtSdHCgMcFnQ5vk87TEj7YDKm60esCLV6G6PxquhAnvX4XlW te1NnpWUFsXmswxWgBkvgN0GG6oTNdDBLpZke1y2rXIRqatl5LG6K5Buq6A9ecHXlkHH AsfTfRdTE712oygNSPVrKYLZmrAVV0rFnE/fJ9n20jGFMvNQMgXHA1f+5eJwwBrk4d9H ph0Q== 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:content-transfer-encoding:thread-index :content-language; bh=CaxFlKme+x4t2gA/1jFl4yc5BZUJn4c8gFwVGUjPow4=; b=a7P0A0eBtzXpSdFZ+IvuRdISqClIlNcb9QRbU/0XkSXoKrvTeKYermQ2fw07mx5Kcp 2Suf9l/hyMUuXsVhY05YHz88wpqBXj2CeVUX+6sVbTw6g/+Ys/gpQFLvC5AQeEKGbGVW JiOCJOfxYYyPj9hvmYyc55myUVIdBIjyWDNuWFi5oiajWQ9/rS0pBd8lah5Hzlh5Qqmp XdQ9rI+XU8JXjeukCz5Qe5L8b44rWMqThlrUsdpBxunxi/FCWXovl1hdvVAmyMy8LYC5 VK8QwfJAcyNMu/Iua2TdAy3dbDJ5WbwCHHQXFpg0vgtgTwYJqyHrmvqCOU3DF1eideIz bRYQ== X-Gm-Message-State: APzg51AakrYxrnVBA8PQ8oPJ0CYKvGtFsjITCGdCwxBXsfrN+tMvg76m 3/HIHcDbKhWA6VkbUcliDgBaJ+Ib X-Google-Smtp-Source: ANB0VdbNaMBKU1dfPuLTmsnUsi2bstmlQDViF3glevzR9fOnwnDhX6BaV5zcSR6AfholxQrQjLq0FQ== X-Received: by 2002:a2e:350b:: with SMTP id z11-v6mr12773976ljz.55.1536581692944; Mon, 10 Sep 2018 05:14:52 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id x3-v6sm2747999ljb.25.2018.09.10.05.14.51 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 10 Sep 2018 05:14:52 -0700 (PDT) From: "Valery Smyslov" To: Cc: "'Paul Wouters'" , "'IPsecME WG'" , References: <153632409170.28963.3858352353321879475.idtracker@ietfa.amsl.com> <058901d446ad$fd78b5a0$f86a20e0$@elvis.ru> <059d01d446b5$b85610a0$290231e0$@gmail.com> <27A951D3-CA76-4C38-990B-6553B4B0CA74@apple.com> In-Reply-To: <27A951D3-CA76-4C38-990B-6553B4B0CA74@apple.com> Date: Mon, 10 Sep 2018 15:14:52 +0300 Message-ID: <070201d448ff$e10860b0$a3192210$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJcXB691A5/IRakRUGL31dObam09AIk+U4iAZLUdFsBvh/7AQH5rVJZo52N0LA= Content-Language: ru Archived-At: Subject: Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-tcp-guidelines-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2018 12:14:58 -0000 Hi Tommy, > I agree with the points you bring up for MOBIKE (not changing the = message ID, and needing to recalculate > NAT detection payloads). Those are useful to clarify. >=20 > Regarding retransmissions/puzzles/error handling, I agree with Paul = that the recommendations being > provided in your draft are potentially harmful to interoperability. We = specifically did not include those in > RFC8229 because it is not only possible, but likely, that some = deployments will use TCP as a proxying layer > that=E2=80=99s not directly implemented on the IKE endpoint, and that = the IKE messages may be sometimes > transmitted over both UDP and TCP (UDP behind TCP). This is, in fact, = how we did our initial testing and > bringup of the functionality. Yes, I assumed that TCP is end-to-end.=20 > Not retransmitting (or the other examples) assumes that the reliable = link is end-to-end, even though that is > not guaranteed or required by the spec. Can you clarify why an = implementation would require modification of > the protocol such that TCP encapsulation could not occur in a proxy? = The one case I see is client-side MOBIKE, > but I don=E2=80=99t think the server needs to do anything special (and = clients that don=E2=80=99t want to do fancy MOBIKE > fallback between UDP and TCP don=E2=80=99t need to change). Let's first clarify what TCP proxy is. I can imagine a four different = scenarios=20 ( <-> means UDP traffic, <=3D> means TCP traffic): 1. UDP IKEv2 Initiator <-> TCP Proxy 1 <=3D> TCP Proxy 2 <-> UDP IKEv2 = Responder In this case both IKEv2 implementations see only UDP traffic, so = recommendations given in the draft are not applicable. 2. TCP IKEv2 Initiator <=3D> TCP IKEv2 Responder In this case there are no TCP proxies at all, this is the case that is = assumed in the draft. 3. TCP IKEv2 Initiator <=3D> TCP Proxy <-> UDP IKEv2 Responder 4. UDP IKEv2 Initiator <-> TCP Proxy <=3D> TCP IKEv2 Responder These are the cases where problems might arise. In particular: a. NAT_DETECTION_*_IP content won't match, so there will always be "false positive" detection of NAT.=20 b. In case 4 if TCP session is broken for any reason, then it is the=20 Initiator's responsibility to restore it. However, in this case=20 Initiator is not aware of the presence of TCP, so if it has no = traffic to send, the TCP connection will remain broken. If the responder during that period needs to send something to the Initiator (say, to rekey SA), it will fail and the SA will be deleted, causing de-synchronization between the peers. c. Multihomed MOBIKE scenarios won't work (unless proxy is co-located on the same host with IKEv2). d. There may be some issues with transport mode, because it is=20 assumed that the IPsec SA is between IKE peers, and the "peers" will be different in case of TCP and UDP (unless proxy is = co-located on the same host with IKEv2). Am I missing something? BTW, if you assume that the TCP proxy is always co-located on the same = host with UDP IKEv2 implementation, then we can assume that the UDP link=20 proxy <-> IKEv2 is reliable (the packets don't leave the host),=20 so recommendations given in the draft (no retransmissions etc.) won't = harm. Regards, Valery. > Thanks, > Tommy >=20 > > On Sep 7, 2018, at 7:18 AM, Valery Smyslov = wrote: > > > > Hi Paul, > > > >>> I've posted a draft with clarifications and implementation = guidelines > >>> for RFC8229. These clarifications and recommendations are based > >>> on experience of implementing TCP encapsulation and testing it in > >>> various IKEv2 scenarios. > >>> > >>> Feedback of any sort is highly appreciated. > >> > >> I would cut a lot of the introduction / abstract and come straight = to > >> the point. Simiarly, further one not provide as much details and = just > >> come to the point faster. > > > > I tried to be pedant :-) > > > >> I don't see any consideration in the document about deployments = that > >> use a TCP proxy in front of the IKE daemon. In those scenarios, the > >> daemon might not even know TCP is used or the proxy code is written = in > >> a way that only minimal changes to the IKEv2 core are needed. > > > > Is it ever possible? My experience shows that adding TCP = encapsulation > > influences IKEv2 code pretty highly. > > > >> So a lot of decisions you specify, such as not sending retransmits, = might not > >> be possible for those kind of implementations, and so this document > >> dictating them for make interop harder, not easier. > > > > Why? Can you clarify in which cases interop will be harder? > > > >> As this also touches on message IDs, and I think we might have some > >> msgid deadlocks even in the UDP only case, perhaps a clarifying > > > > If you mean MOBIKE, I agree with you that deadlocks seem to be = possible. > > > >> document could add some non-TCP items as well? And the TCP part = could > >> be part of the new clarification draft ? > > > > Not sure it's worth to mix them. > > > > Regards, > > Valery. > > > >> > >> Paul > >> > >> _______________________________________________ > >> IPsec mailing list > >> IPsec@ietf.org > >> https://www.ietf.org/mailman/listinfo/ipsec > > From nobody Mon Sep 10 07:35:14 2018 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 72253130DFB; Mon, 10 Sep 2018 07:35:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: ipsecme-chairs@tools.ietf.org, ipsecme-chairs@ietf.org, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153659010539.26497.2929008541684614415.idtracker@ietfa.amsl.com> Date: Mon, 10 Sep 2018 07:35:05 -0700 Archived-At: Subject: [IPsec] Spencer Dawkins' No Objection on charter-ietf-ipsecme-11-05: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2018 14:35:06 -0000 Spencer Dawkins has entered the following ballot position for charter-ietf-ipsecme-11-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- If TSV can help with the work on Postquantum key exchange methods and the impact of increased size of initial IKEv2 messages, please let us know. I note that https://tools.ietf.org/html/draft-ietf-tsvwg-datagram-plpmtud-04#section-6 is part of a current TSVWG work item, and this might be relevant to that discussion, but that's only my poorly informed opinion. But we may be able to help in other ways. From nobody Tue Sep 11 19:53:52 2018 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D86130DC1; Tue, 11 Sep 2018 19:53:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: ipsecme-chairs@tools.ietf.org, ipsecme-chairs@ietf.org, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153672082269.16741.3638014483541629645.idtracker@ietfa.amsl.com> Date: Tue, 11 Sep 2018 19:53:42 -0700 Archived-At: Subject: [IPsec] Ben Campbell's No Objection on charter-ietf-ipsecme-11-05: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2018 02:53:43 -0000 Ben Campbell has entered the following ballot position for charter-ietf-ipsecme-11-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Minor punctuation comment for the paragraph starting with "RFC7427": OLD: "A prominent example is RSASSA-PKCS#1 v 1.5 and RSASSA-PSS, however it is envisioned..." NEW: "A prominent example is RSASSA-PKCS#1 v 1.5 and RSASSA-PSS; however, it is envisioned..." From nobody Thu Sep 13 16:01:35 2018 Return-Path: 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 E7CEB130E91; Thu, 13 Sep 2018 16:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Nmbw9XmMWm3z; Thu, 13 Sep 2018 16:01:19 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 1F56E12008A; Thu, 13 Sep 2018 16:01:19 -0700 (PDT) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 851E82471B21E; Fri, 14 Sep 2018 00:01:13 +0100 (IST) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.399.0; Fri, 14 Sep 2018 00:01:15 +0100 Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.77]) by SJCEML701-CHM.china.huawei.com ([169.254.3.36]) with mapi id 14.03.0415.000; Thu, 13 Sep 2018 16:01:10 -0700 From: Linda Dunbar To: RTGWG , "sdwan-sec@ietf.org" , IPsecME WG , "idr@ietf.org" Thread-Topic: Issues of draft-dm-net2cloud-gap-analysis using BGP to carry IPsec configuration (such as Public key, etc) and Peer authentication information Thread-Index: AdRLtFx4qME4Sg99T4W5aAeVt14v2w== Date: Thu, 13 Sep 2018 23:01:09 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F66B1473F5@sjceml521-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.218.180.231] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F66B1473F5sjceml521mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [IPsec] Issues of draft-dm-net2cloud-gap-analysis using BGP to carry IPsec configuration (such as Public key, etc) and Peer authentication information X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2018 23:01:23 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F66B1473F5sjceml521mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable During the IETF 102 RTGwg discussion of draft-dm-net2cloud-gap-analysis on = using BGP to carry IPsec configuration (such as Public key, etc) and Peer a= uthentication information, there are people stating it is troublesome of us= ing BGP to carry IPsec configuration & authentication request because it is= difficult for a BGP node to guarantee not forwarding the BGP advertisement= (even if the update is marked as Not Forward). Can someone elaborate why? Thanks, Linda Dunbar P.s. a new mailing list has been created to for discussing the risks associ= ated with various simplification of IPsec protocol by utilizing SD-WAN cent= ral controller. The traditional IPsec scheme requires that in a fully meshe= d network, each device has to manage n2 key exchanges and (n-1) keys. As an= example, in a 1,000-node network, 1,000,000 key exchanges are required to = authenticate the devices, and each node is responsible for maintaining and = managing 999 keys. In addition, when an edge node has multiple tenants atta= ched, the edge node has to establish multiple tunnels for tenants. For exam= ple, for a network with N nodes, a node A has 5 tenants app attached to it,= then the node A has to maintain 5*(N-1) number of keys if each tenant need= s to communicate with all other nodes. Therefore, simplification facilitate= d by SD-WAN controller is needed for large scale deployment. However, it is= necessary identify the associated risks, so that the industry can make the= informed decision on risks that can be tolerated for their specific enviro= nment. To subscribe:: https://www.ietf.org/mailman/listinfo/sdwan-sec --_000_4A95BA014132FF49AE685FAB4B9F17F66B1473F5sjceml521mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

During the IETF 102 RTGwg discussion of draft-dm-net= 2cloud-gap-analysis on using BGP to carry IPsec configuration (such as Publ= ic key, etc) and Peer authentication information, there are people stating = it is troublesome of using BGP to carry IPsec configuration & authentication request because it is diffi= cult for a BGP node to guarantee not forwarding the BGP advertisement (even= if the update is marked as Not Forward).

 

Can someone elaborate why?

 

Thanks, Linda Dunbar

 

P.s. a new mailing list has been created to for disc= ussing the risks associated with various simplification of IPsec protocol b= y utilizing SD-WAN central controller. The traditional IPsec scheme require= s that in a fully meshed network, each device has to manage n2 key exchanges and (n-1) keys. As an example, = in a 1,000-node network, 1,000,000 key exchanges are required to authentica= te the devices, and each node is responsible for maintaining and managing 9= 99 keys. In addition, when an edge node has multiple tenants attached, the edge node has to establish multipl= e tunnels for tenants. For example, for a network with N nodes, a node A ha= s 5 tenants app attached to it, then the node A has to maintain 5*(N-1) num= ber of keys if each tenant needs to communicate with all other nodes. Therefore, simplification facilitated= by SD-WAN controller is needed for large scale deployment. However, it is = necessary identify the associated risks, so that the industry can make the = informed decision on risks that can be tolerated for their specific environment.

 

To subscr= ibe:: https://www.ietf.org/mailman/listinfo/sdw= an-sec

 

 

 

 

--_000_4A95BA014132FF49AE685FAB4B9F17F66B1473F5sjceml521mbschi_-- From nobody Mon Sep 17 14:30:18 2018 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C48130DFF; Mon, 17 Sep 2018 14:30:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Cc: ipsec@ietf.org, ipsecme-chairs@tools.ietf.org, ipsecme-chairs@ietf.org, The IESG MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <153721980519.24684.7975791578913292986.idtracker@ietfa.amsl.com> Date: Mon, 17 Sep 2018 14:30:05 -0700 Archived-At: Subject: [IPsec] WG Action: Rechartered IP Security Maintenance and Extensions (ipsecme) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2018 21:30:05 -0000 The IP Security Maintenance and Extensions (ipsecme) WG in the Security Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs. IP Security Maintenance and Extensions (ipsecme) ----------------------------------------------------------------------- Current status: Active WG Chairs: David Waltermire Tero Kivinen Assigned Area Director: Eric Rescorla Security Area Directors: Eric Rescorla Benjamin Kaduk Mailing list: Address: ipsec@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/ipsec Archive: https://mailarchive.ietf.org/arch/browse/ipsec/ Group page: https://datatracker.ietf.org/group/ipsecme/ Charter: https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs, IKEv1 is now obsoleted), IKEv2 (RFC 7296), and the IPsec security architecture (RFC 4301). IPsec is widely deployed in VPN gateways, VPN remote access clients, and as a substrate for host-to-host, host-to-network, and network-to-network security. The IPsec Maintenance and Extensions Working Group continues the work of the earlier IPsec Working Group which was concluded in 2005. Its purpose is to maintain the IPsec standard and to facilitate discussion of clarifications, improvements, and extensions to IPsec, mostly to ESP and IKEv2. The working group also serves as a focus point for other IETF Working Groups who use IPsec in their own protocols. The current work items include: IKEv1 using shared secret authentication was partially resistant to quantum computers. IKEv2 removed this feature to make the protocol more usable. The working group will add a mode to IKEv2 or otherwise modify the shared-secret mode of IKEv2 to have similar or better quantum resistant properties to those of IKEv1. Split-DNS is a common configuration for VPN deployments in which only one or a few private DNS domains are accessible and resolvable via the tunnel. Adding new configuration attributes to IKEv2 for configuring Split-DNS would allow more deployments to adopt IKEv2. This configuration should also allow verification of the domains using DNSSEC. Working group will specify needed configuration attributes for IKEv2. Currently, widely used counter mode based ciphers send both the ESP sequence number and IV in the form of a counter, as they are very commonly the same. There has been interest to work on a document that will compress the packet and derive IV from the sequence number instead of sending it in separate field. The working group will specify how this compression can be negotiated in the IKEv2, and specify how the encryption algorithm and ESP format is used in this case. The Group Domain of Interpretation (GDOI - RFC 6407) is an IKEv1-based protocol for negotiating group keys for both multicast and unicast uses. The Working Group will develop an IKEv2-based alternative that will include cryptographic updates. A possible starting point is draft-yeung-g-ikev2. Postquantum Cryptography brings new key exchange methods. Most of these methods that are known to date have much larger public keys than conventional Diffie-Hellman public keys. Directly using these methods in IKEv2 might lead to a number of problems due to the increased size of initial IKEv2 messages. The working group will analyze the possible problems and develop a solution, that will make adding Postquantum key exchange methods more easy. The solution will allow post quantum key exchange to be performed in parallel with (or instead of) the existing Diffie-Hellman key exchange. A growing number of use cases for constrained networks - but not limited to those networks - have shown interest in reducing ESP (resp. IKEv2) overhead by compressing ESP (resp IKEv2) fields. The WG will define extensions of ESP and IKEv2 to enable ESP header compression. Possible starting points are draft-mglt-ipsecme-diet-esp, draft-mglt-ipsecme-ikev2-diet-esp-extension, draft-smyslov-ipsecme-ikev2-compression and draft-smyslov-ipsecme-ikev2-compact. RFC7427 allows peers to indicate hash algorithms they support, thus eliminating ambiguity in selecting a hash function for digital signature authentication. However, advances in cryptography lead to a situation when some signature algorithms have several signature formats. A prominent example is RSASSA-PKCS#1 v 1.5 and RSASSA-PSS; however it is envisioned that the same situation may repeat in future with other signature algorithms. Currently IKE peers have no explicit way to indicate to each other which signature format(s) they support. That leads to interoperability problems. The WG will investigate the situation and come up with a solution that allows peers to deal with the problem in an interoperable way. RFC7296 defines a generic notification code that is related to a failure to handle an internal address failure. That code does not explicitly allow an initiator to determine why a given address family is not assigned, nor whether it should try using another address family. The Working Group will specify a set of more specific notification codes that will provide sufficient information to the IKEv2 initiator about the encountered failure. A possible starting pointing is draft-boucadair-ipsecme-ipv6-ipv4-codes. Some systems support security labels (aka security context) as one of the selectors of the SPD. This label needs to be part of the IKE negotiation for the IPsec SA. Non-standard implementations exist for IKEv1 (formerly abusing IPSEC Security Association Attribute 10, now using private space IPSEC Security Association Attribute 32001). The work is to standarize this for IKEv2, in a way that will be backwards compatible with old implementations, meaning it must not require any changes to implementations not supporting this. Milestones: Apr 2018 - IETF Last Call on Split-DNS Configuration for IKEv2 Apr 2018 - IETF Last Call on Implicit IV in IPsec May 2018 - IETF Last Call on partially quantum resistant IKEv2 Oct 2018 - The internal address failure indication in IKEv2 to IESG Dec 2018 - The ESP on contrained network to IESG Dec 2018 - G-DOI for IKEv2 to IESG Jan 2019 - The security labels support for IKEv2 to IESG Mar 2019 - Signature algorithm negotiation for IKEv2 to IESG May 2019 - Postquantum cryptography document for IKEv2 to IESG From nobody Fri Sep 21 23:03:22 2018 Return-Path: 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 E0183130DF2 for ; Fri, 21 Sep 2018 23:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=ZTAKc173; dkim=pass (1024-bit key) header.d=ericsson.com header.b=WtpPF7Sp 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 AGwwqTnS0qfy for ; Fri, 21 Sep 2018 23:03:19 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 C5C061271FF for ; Fri, 21 Sep 2018 23:03:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1537596196; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ylWWY8aj39PgUqh3U/e2e7erqOIc4gR2iUEMwTDDCMc=; b=ZTAKc173/BGdt5re0h/+PSEI1LgfWte7p3mVBcRizCkiDeAConP4Fw+iX6XPGZwj hXttWbVm/x4D4bvA8Pyry5GngrZ/HRAOlrZPEDgc1gBuBUOJ6u5b0NiicpQyj97+ ORpKJoeDAIHgQ0TBjzUj5OsOhMXGhPlXbX0/HHK4IyM=; X-AuditID: c1b4fb30-fe1ff700000055da-bf-5ba5db24cbf0 Received: from ESESBMB501.ericsson.se (Unknown_Domain [153.88.183.114]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 1D.A9.21978.42BD5AB5; Sat, 22 Sep 2018 08:03:16 +0200 (CEST) Received: from ESESBMB504.ericsson.se (153.88.183.171) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sat, 22 Sep 2018 08:03:16 +0200 Received: from EUR04-DB3-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Sat, 22 Sep 2018 08:03:16 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ylWWY8aj39PgUqh3U/e2e7erqOIc4gR2iUEMwTDDCMc=; b=WtpPF7SpdFTCX+RTeW3SpsnCA/EDWzzRfnWwYJlIYgNldNYFE1uTu0rcBkbm4PKcAN401MeUrjcV0Viq7106uSZhTWI8Rc3OEkUcj3kw6PD+gB1GfFL93dEeb8Hg7e2VfrVFb7AJtGmX+EGSFgdh3bS2vwkyrwGh5+ZFM/L/8io= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.166.22) by HE1PR07MB3225.eurprd07.prod.outlook.com (10.170.246.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1164.11; Sat, 22 Sep 2018 06:03:15 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::a451:7626:5a73:809]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::a451:7626:5a73:809%5]) with mapi id 15.20.1164.014; Sat, 22 Sep 2018 06:03:15 +0000 From: John Mattsson To: "ipsec@ietf.org" Thread-Topic: Comments on draft-ietf-ipsecme-implicit-iv-05 Thread-Index: AQHUS3RpShWuNfCP002LTkZsSiwDkKT7/oKA Date: Sat, 22 Sep 2018 06:03:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.11.0.180909 x-originating-ip: [95.192.79.163] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB3225; 6:vGiEi/t8M/Nhw+roFVI0E0mzcT0ld6ISgzw7LTqhz3/Q7bBhHjR6DDQKS05oVKzSvgsHzrLVV2U8YC/LPXsGaeDGscEKF1Ek6TOvsDk+D+Tibz4CCfSu+qc8Lf6NR+cXzUdWZWr9V/Fl/jVx50I+uR8vxjX+8eTsdA8ykHp+czem4MoxRnNdBJ83Dqs6LKMD1jfcal/Nz4wFgSIEI/HptOREABenq/WxO7y93kr4Svsfombe3kwb8m4l6QWTOyXkjTnVefwypDgi0vK7ytK5LfMUPVTNr8e6JyOs2q9DSXjohFQFY4O3g/+6RaDd7ESiSvYJ6sARmv7g6UEQ2P3k13b7SvojibsHvXLaEJQjh7nvya1B2gPHV+givxFDUwckMz7kDM8Ogmxl1JNx8ukHoUvdBUzw1WEMuXtOFxjBfzrIiNklxu3u/jwvtAyT/ce9WCkUYfca6luPx9G953TgOg==; 5:tKFDf0Z7770PjZp7DwNGJyo9sbnK1orUahikUn6Ph8LDdCHTkUEHoGTyrEjge0LwSOHORQVjjMXjirIJj0/JooSubTYI+pf73oEcUip5ZBzUWT6nb9efcXdRYwOlBRktPOX+FtfZ8xebnSb6FHnzAj++Ko+HmV4uJCL1ecAlr6Q=; 7:1oXu5yyyJBC4aHQaRfBsX9O0WVE3hViIQw0xV8EDwbcNwN0BHviUa+uXPDIBvao/5yGxmKDVrxB2c2Z3dvDcIt3fV6PFg/0lXS5Oqjka3FrM40c/2KEYcWF1p+Zm2/UK6+DlPZe/hoHie99ERKCL4b384FhC2A/mC68zDWqJU5M6m/hVLPUx5sY11CNXJk5uHiKdSoBAZlLrt5BMcs9vAnzNw5LQ/pMOeLW9tOcagWYt5Q7ErY67ihZWfDPCVedQ x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: f46a8e90-ee2e-42bf-602b-08d6205115f7 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534165)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB3225; x-ms-traffictypediagnostic: HE1PR07MB3225: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231355)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(149051)(150027)(6041310)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991041); SRVR:HE1PR07MB3225; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB3225; x-forefront-prvs: 0803A0241F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(396003)(346002)(366004)(39860400002)(189003)(199004)(6116002)(446003)(68736007)(8936002)(6916009)(81156014)(6486002)(81166006)(44832011)(2900100001)(486006)(305945005)(36756003)(5640700003)(71200400001)(6512007)(71190400001)(6436002)(83716004)(5250100002)(14444005)(256004)(229853002)(1730700003)(476003)(2501003)(2616005)(3846002)(82746002)(106356001)(102836004)(99286004)(105586002)(2351001)(26005)(6506007)(14454004)(316002)(478600001)(8676002)(86362001)(11346002)(97736004)(76176011)(5660300001)(53936002)(33656002)(58126008)(6346003)(2906002)(6246003)(7736002)(66066001)(186003)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3225; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-microsoft-antispam-message-info: ibtt+YR+FuBjuz92mT43k6KCYL1H2aisUAVBGP4xCvJD5JS+AgjjEf8DR+ZA/P0W8Qf/V9uAcMI45joecIikBjdZVdD6MHjp2MYUzvZCnITDKuBoHDAbgxKy3feqAATaeU3VDRQjPC+7iJ/zdTnBMX1HXZOD/OZ2oS/138+lYT/CZEmLS7AtALKOr4Cvzp121uzss2v3ewpwEYiAr2dPq7MZYfHtPmM3nr2SZ3gSOs2R+VYOkSw6sdDOQ3RT/ML+firSTzTZ38Dizesk1iRp5x41iwzeYMf4t5o3aGn/9Btr9mMa0zoghhKFbu/dCFi3emH3XYE0JJIdkISpkO3wbWi4xKsOYP3upDlpyGX0hI4= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f46a8e90-ee2e-42bf-602b-08d6205115f7 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2018 06:03:15.0936 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3225 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplleLIzCtJLcpLzFFi42KZGbG9SFfl9tJog7+/TC32b3nB5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujPsfrjEV7FGoOPJ4OXMD4wX5LkYODgkBE4m3a8K6GLk4hASO MkqsnzqHBcL5xijRunkJE4SzhEmi/8hHZhCHRWACs8SXvy/YIDKTmSSW7XrA3sXICeQ8YJRo /2oIYrMJGEjM3dPABmKLCKhKnFo2nRXEFhawkliwfhZU3Fri26PjjBC2kcTyqw/ZQG5iAap/ N8ULJMwrYC/x4FI7E8R4e4nbvxeCjeEUcJBY9u0vWJxRQEzi+6k1YDazgLjErSfzwWwJAQGJ JXvOM0PYohIvH/8D6xUV0JeY/6CDFSKuKNG7aw9UvazEpfndjCB/SQjsY5c4eOIMC0RCV+LD 1KnMkPDylXiwQhOi5jijxKt1+6EGaUnsuLYUalm2xPpZr9khbGuJl+d2Q9XISazqfcgC0byf WeLxwl+sExiNZiE5fBbQDmYBTYn1u/Qhwh4Sk1YsZIOwFSWmdD9knwUOF0GJkzOfsCxgZF3F KFqcWpyUm25kpJdalJlcXJyfp5eXWrKJEZg4Dm75bbCD8eVzx0OMAhyMSjy8ubeWRguxJpYV V+YeYpTgYFYS4bV1BwrxpiRWVqUW5ccXleakFh9ilOZgURLntfDbHCUkkJ5YkpqdmlqQWgST ZeLglGpgVN5s3dxgLL2qkjs13psrwPB5+MKGW0siYjcrbvg85avedql9J7yzeu9xO15W+3hA aOkBiS0fGGxme3ib79XOXqwyWW8WU8O+s6tVt4YkZee+Xyn1Q2mn1r+Wtet3fNzUbL1Jfdf9 /RF7rLp8tzgpiyz1vSUbn92Upa/U5PtigW/9Sz6Tf+fTlViKMxINtZiLihMBwZtwOBgDAAA= Archived-At: Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-implicit-iv-05 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2018 06:03:21 -0000 SGksDQoNCkkgdGhpbmsgdGhlIGlkZWEgb2YgaW50cm9kdWNpbmcgImltcGxpY2l0IElWIiBhbHNv IGluIElQc2VjIGlzIGdyZWF0IGFuZCBzb21ldGhpbmcgdGhhdCBhYnNvbHV0ZWx5IHNob3VsZCBi ZSBkb25lLiBTb21lIGNvbW1lbnRzOg0KDQotIFRoZSBhYnN0cmFjdC9pbnRyb2R1Y3Rpb24vc2Vj dXJpdHkgY29uc2lkZXJhdGlvbiBnaXZlcyB0aGUgaWRlYSB0aGF0IGl0IGRlZmluZXMgaW1wbGlj aXQgSVYgZm9yIEVOQ1JfQUVTX0NUUiB3aGljaCBpcyBkb2VzIG5vdC4gSSB0aGluayBBRVMtQ1RS IGNvdWxkIGJlIHJlbW92ZWQgZnJvbSB0aGUgZG9jdW1lbnQuDQoNCi0gSSB0aGluayB0aGUgdGhl IHRlcm1pbm9sb2d5IG9mIElWLCBub25jZSBldGMuIGluIHRoaXMgZG9jdW1lbnQgaXMgdmVyeSBj b25mdXNpbmcuIEF0IGxlYXN0IFJGQyA0MTA2IGRlZmluZXMgSVYgdG8gYmUgdGhlIDggb2N0ZXQg RVNQIElWLCB3aGlsZSBub25jZSBpcyB1c2VkIGZvciB0aGUgMTIgb2N0ZXQgQUVBRCBub25jZSwg YWxpZ25pbmcgd2l0aCBSRkMgNTExNi4gSSB0aGluayB0aGlzIGRvY3VtZW50IHNob3VsZCBhbHNv IGZvbGxvdyB0aGlzIGNvbnZlbnRpb24uIGUuZy4gSSB0aGluayB0aGUgc2VudGVuY2VzIHNob3Vs ZCB0YWxrIGFib3V0IElWIGluc3RlYWQgb2Ygbm9uY2UuDQoNCiAgICJidXQgYWxsIG9mIHRoZSBh bGdvcml0aG1zIG1lbnRpb25lZCBhYm92ZSB0YWtlIGFuIDgtb2N0ZXQgbm9uY2UuIg0KDQogICAi Q3VycmVudGx5IHRoaXMgbm9uY2UgaXMgc2VudCBpbiBlYWNoIEVTUCBwYWNrZXQiDQoNCi0gIk5v bmNlIGdlbmVyYXRpb24gZm9yIHRoZXNlIGFsZ29yaXRobXMgaGFzIG5vdCBiZWVuIGV4cGxpY2l0 bHkgZGVmaW5lZC4gDQogICBJdCBoYXMgYmVlbiBsZWZ0IHRvIHRoZSBpbXBsZW1lbnRhdGlvbiIN Cg0KSSBkbyBub3QgdW5kZXJzdGFuZCBob3cgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMgbm9uY2Ug KG9yIElWKSBnZW5lcmF0aW9uIGNvdWxkIGJlIGludGVyb3BlcmFibGUgYmV0d2VlbiBpbXBsZW1l bnRhdGlvbj8gSWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSwgdGhlIG9ubHkgdGhpbmcgc2VudCBp biB0aGUgRVNQIHBhY2tldCBpcyB0aGUgc2VxdWVuY2UgbnVtYmVyLg0KDQotIElmIHdlIGdvIHRv IHRoZSB0cm91YmxlIG9mIGRlc2lnbmluZyBuZXcgZW5jcnlwdGlvbiBhbGdvcml0aG1zIGZvciBF U1AsIEkgdGhpbmsgdGhpcyBkb2N1bWVudCBkb2VzIHRvbyBsaXR0bGUgYW5kIG1pc3NlcyBvcHBv cnR1bml0aWVzIHRvIHdpdGggdmVyeSBsaXR0bGUgd29yayBhbHNvIG1ha2UgdGhlIGFsZ29yaXRo bXMgc3Ryb25nZXIgY3J5cHRvZ3JhcGhpY2FsbHkgYXMgd2FzIGRvbmUgd2l0aCBUTFMgMS4yIC0+ IFRMUyAxLjMuIEkgc3RvbmdseSBzdWdnZXN0IHRvIGNoYW5nZSB0aGUgbm9uY2UgZ2VuZXJhdGlv biB0byBmb2xsb3cgY3VycmVudCBiZXN0IHByYWN0aWNlcyBlc3RhYmxpc2hlZCBieSBlLmcuIFRM UyAxLjMuIFN1Z2dlc3Rpb24gKGhlcmUgZXhhbXBsaWZpZWQgZm9yIEFFUy0xMjggaW4gR0NNIG1v ZGUpDQoNCiAgIDEuIFRoZSBLRVlNQVQgcmVxdWVzdGVkIGZvciBlYWNoIEFFUy1HQ00ga2V5IGlz IDI4IG9jdGV0cy4gIFRoZSBmaXJzdA0KICAgICAgICAxNiBvY3RldHMgYXJlIHRoZSAxMjgtYml0 IEFFUyBrZXksIGFuZCB0aGUgcmVtYWluaW5nIDEyIG9jdGV0cw0KICAgICAgICBhcmUgdXNlZCBh cyB0aGUgc2FsdCB2YWx1ZSBpbiB0aGUgbm9uY2UuDQoNCiAgIDIuIFRoZSBub25jZSBmb3JtYXQg aXMgY2hhbmdlZCB0byBhIGZvcm1hdCBmb2xsb3dpbmcgU2VjdGlvbiA0LjQgb2YgZHJhZnQtbWNn cmV3LWl2LWdlbiBbWFhdIHdoZXJlIElWID0gaW1wbGljaXQgSVYNCg0KICAgICAgICAgICAgICAg ICAgIDAgIDEgIDIgIDMgIDQgIDUgIDYgIDcgIDggIDkgMTAgMTENCiAgICAgICAgICAgICAgICAg Ky0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKw0KICAgICAgICAgICAgICAgICB8 MDB8MDB8MDB8MDB8ICAgICAgICAgICBJViAgICAgICAgICB8LS0tKw0KICAgICAgICAgICAgICAg ICArLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rICAgfA0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAg ICAgICAgICArLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rICAgfA0KICAgICAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgIHNhbHQgICAgICAgICAgICAgICB8LT4oKykNCiAg ICAgICAgICAgICAgICAgKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKyAgIHwN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwNCiAgICAgICAgICAgICAgICAgKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0t KyAgIHwNCiAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICBub25jZSAgICAgICAgICAg ICAgfDwtLSsNCiAgICAgICAgICAgICAgICAgKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0t Ky0tKy0tKw0KDQogICAgICAgICAgICAgICAgICAgICAgRmlndXJlOiBOb25jZSBGb3JtYXQNCg0K ICAgMy4gVGhlIHNhbHQgaXMga2VwdCBzZWNyZXQNCg0KICAgIEluIFtZWV0gaXQgaXMgc2hvd24g dGhhdCB0aGlzIGNhbiBiZSB1bmRlcnN0b29kIGFzIGEga2V5LWxlbmd0aCBleHRlbnNpb24gdGhh dCBlc3NlbnRpYWxseSBleHRlbmRzIHRoZSAxMjgtYml0IGtleSBvZiBBRVMtR0NNIHRvIGEgMjI0 LWJpdCBrZXkgZ2l2aW5nIHNpZ25pZmljYXRudGx5IGJldHRlciBtdWx0aS11c2VyIHNlY3VyaXR5 IChhbmQgc2luZ2xlLXVzZXIgc2VjdXJpdHkpDQoNCi0gQSBsYXJnZSBzZWNyZXQgc2FsdCBpcyB1 c2VmdWwgZm9yIElLRXYyIGFzIHdlbGwsIEkgdGhpbmsgdGhlIGFsZ29yaXRobXMgc2hvdWxkIGJl IGRlZmluZWQgZm9yIElLRXYyIGFzIGJ1dCB3aXRoIElWID0gZXhwbGljaXQgSVYuDQoNCkNoZWVy cywNCkpvaG4NCg0KDQo=