From nobody Tue Dec 1 02:14:58 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF4151B2DD6 for ; Tue, 1 Dec 2015 02:14:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=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 ApsA-J_b-QMj for ; Tue, 1 Dec 2015 02:14:56 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 DCCEC1B3A6E for ; Tue, 1 Dec 2015 02:14:55 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.1/8.14.8) with ESMTPS id tB1AEkKa006368 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 1 Dec 2015 12:14:46 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.1/8.14.8/Submit) id tB1AEkBh029267; Tue, 1 Dec 2015 12:14:46 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22109.29462.49109.320818@fireball.acr.fi> Date: Tue, 1 Dec 2015 12:14:46 +0200 From: Tero Kivinen To: In-Reply-To: References: <22069.1448830591@sandelman.ca> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 8 min X-Total-Time: 7 min Archived-At: Cc: ipsec@ietf.org, mcr+ietf@sandelman.ca Subject: Re: [IPsec] certificate lifetimes vs SA lifetimes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 10:14:58 -0000 Paul_Koning@Dell.com writes: > > > On Nov 29, 2015, at 3:56 PM, Michael Richardson wrote: > > > > > > It is my belief/memory that IKEv2 implementations should NOT limit SA > > (PARENT or CHILD) lifetimes based upon certificate lifetime or CRL lifetime. > > > > Neither rfc4945 (pki4ipsec) nor rfc7296 seems to confirm or deny this. > > Yet, I'm sure that this was consensus at some point. Maybe I've mis-remembered? > > What document did I miss? > > I don't remember one way or the other. It seems perfectly logical > to limit SA lifetime. This certainly seems to be what customers > expect (based on some feedback I've seen). We have discussed about this, but I think we never really reached concensus on one thing. There are reasons to limit SA lifetimes, and there are reasons not to. Certificate lifetime is usually ok, as they are long lived, but CRL lifetimes are not something that should be used for limiting SA lifetimes. If you have for example hourly CRLs, that would mean that every connection will do reauthentication hourly and everybody does that reauthnetication at the same time, as they all use same CA, thus same CRL. It would be much better to implement it so that you store the certificate used for authentication and then put verification timers in the future when something happens, i.e. CRL expires etc. When the CRL expires, you download new CRL, and go through that and if you have any connections using any certificates on the CRL, you delete those connections. On the other hand if someones certificate gets compromized, or employee leaves the company, you do not want to wait until next CRL lifetime. You remove his account from the user database, and push that change out to the VPN gateways, and if there are any connections open using that account that got deleted, you remove those connections (i.e. re-evaluate your policy for existing connections after policy update). This will allow you to disable access in timely fashion and you can still use more usable times for CRLs and Certificates. -- kivinen@iki.fi From nobody Tue Dec 1 04:45:16 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C64DE1A016A for ; Tue, 1 Dec 2015 04:45:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.229 X-Spam-Level: X-Spam-Status: No, score=-1.229 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_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=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 ElIbuU3thvgO for ; Tue, 1 Dec 2015 04:45:11 -0800 (PST) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (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 DC58C1AD0AB for ; Tue, 1 Dec 2015 04:45:10 -0800 (PST) Received: by lffu14 with SMTP id u14so6471072lff.1 for ; Tue, 01 Dec 2015 04:45:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version :content-type; bh=5mS0VxwNEJok2T+RngPyjFOXi6HjlAzmWWRbpwnEzOo=; b=vuQQ6vQ71uBtzBDMCx1QAKGzUu4FFlxOAj1e0vT5Mu00dGjOFY/cxtf08nf6O8LdpI ziEuE0qxAkt6GULFu3dLIOWXZpPq2LiNzrC6u+kJHGgxS3aDYI85vUgRsT9ZYWo5w/tQ dIQAAh4M8f2Mb1aRe/sDZnwIClqIi9+q/YjUDBKa7G7msGbRtRntgh/Jzpp46Wb7WAiC Zl6NhkoPuGJXT8wfi2d+LwamQB3ZmSjIfD6wbrVUFcaYhHR9bm2/kIo+xwR8EqmA8op8 HooTU8uvjr/yzYoA2rR9hVCP0Id4XXCu+v7hTzSqxr5bnQSr0AvAtgaHDhWeCOlcVUZ7 JR+Q== X-Received: by 10.25.210.143 with SMTP id j137mr16890255lfg.115.1448973905986; Tue, 01 Dec 2015 04:45:05 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id dz6sm4037032lbb.17.2015.12.01.04.45.05 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Dec 2015 04:45:05 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Waltermire, David A." , References: Date: Tue, 1 Dec 2015 15:45:04 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0809_01D12C4F.3F64E370" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Subject: Re: [IPsec] Review of draft-ietf-ipsecme-ddos-protection-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 12:45:14 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0809_01D12C4F.3F64E370 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi David, thank you for the careful review. I hope we'll manage to address your = comments=20 and issue an updated version shortly. Please find more inline. Regards, Valery. ----- Original Message -----=20 From: Waltermire, David A.=20 To: IPsec@ietf.org=20 Sent: Tuesday, December 01, 2015 6:15 AM Subject: [IPsec] Review of draft-ietf-ipsecme-ddos-protection-02 Please find my comments on draft-ietf-ipsecme-ddos-protection-02 = below. Overall I found the content of the draft to be very good. =20 Here is a quick summary of my comments: - There are still some placeholder sections in the draft that need to = be written (i.e. sections 3.1, 3.2, 11). That's true. However sections 3.1 and 3.2 are left due to = miscommunication between the authors while preparing the draft for publication. The Keyed-Cookie Notification and the Puzzle-Required Notification are left from the earlier version = of the draft, they are now replaced with the PUZZLE Notification and the Puzzle = Solution Notification, which are covered in Sections 10.1 and 10.2. The Security Considerations section need to be filled and I think we = need more input from the WG, since the topic is both important and subtle. - I don't recall seeing many comments on the list, if any, on sections = 6 through 10. In general I'd like to see more review and comments on = these sections in the draft before the draft goes to WGLC. - Also related to sections 6 - 10, there appear to be a number of = requirements that are not capitalized according to RFC 2119 in these = sections. Anyone willing to volunteer to review the draft and make = recommendations for RCF2119 wording changes? - I also found quite a few NITS relating to spelling, grammar, and = punctuation. Given the number of nits, it would be good to produce a = clean draft for additional review, so we don't duplicate review effort. =20 Yoav and Valery, do you have a sense of when you can turn around an = update to this draft with these comments addressed? =20 Regards, Dave =20 Comments/Questions: ---------------------------- =20 General: =20 There seem to be places in the draft where RFC2119 wording should be = used (i.e. sections 6 - 10). It would be good to see more review and = comments on this section to make sure we are 1) providing appropriate = guidance and 2) using the appropriate normative language. For example in = section 6: =20 s/DDoS attack, it is suggested that no Cookie or puzzles be used/DDoS = attack, it is RECOMMENDED that no Cookie or puzzles be used/ I agree that it is good idea if the draft is reviewed for the proper use = of RFC2119 keywords. Section 3: =20 Is it possible if "the same value is sent to all Initiators", that the = attacker could coordinate solving the puzzle across a number of attack = hosts to achieve some efficiency? If so, it might be good to recommend = that a new challenge be sent to each host for each SA. Here "the same value" means "the same number of zero bits", i.e. the = same puzzle difficulty. The puzzles themselves must be different for each initiator. Should we rephrase the para to make it more clear? Sections 3.1 and 3.2 need to be completed or removed. Some of this = looks like it may be included in Section 8. It also looks to be fully = described in sections 10.1 and 10.2. Some work is needed to sort this = out. They should be removed. As I've said they were left due to = miscommunication in a rush conditions. Section 5: =20 I am not a fan of using the phrase "but the current thinking", since = this may be read many years from now. This paragraph should be reworked = to make it more temporally relevant. Perhaps you can tie the thinking = directly to the degree of IPv6 NAT usage directly and avoid the temporal = qualifier? I tend to agree with you, however I'd let Yoav comment on this. Section 6: =20 The phrase "the amount of failed IKE_AUTH exchanges to never exceed = the threshold of attack detection" doesn't make sense and needs to be = reworded.=20 =20 In the phrase "only defensive measure is the monitoring", it is not = clear what is being monitored. I am assuming this is about monitoring = half-open SAs. This should be clarified. OK. Section 8.2.1: =20 Shouldn't the puzzle used in the IKE_SA_INIT be different than the = puzzle used in the IKE_AUTH exchange to prevent the initiator from = sending back a cached response or am I misunderstanding something? Same = comment for section 8.2.1.2. They will be different due to the differences in construction of the = string S. In initial exchange the S is the content of the cookie, while in the IKE_AUTH puzzles the S is the concatenation = of the Responder's nonce (Nr) and Responder's SPI (SPIr). It is very unlikely that these two S are the same. Should we add some = clarification on this? Section 11: =20 The security consideration section needs to be completed. Perhaps this = could be made a summary of the threats and related countermeasures = described in the document? Certainly. However this summary might not be enough, since the topic is = subtle and it's easy to miss some important details. I think we need more reviews and more comments. Nits: ------ I agree with all of the nits even before I read them. Thank you, we'll incorporate the suggested changes into the next version of the = draft. ------=_NextPart_000_0809_01D12C4F.3F64E370 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi David,
 
thank you for the careful review. I hope we'll = manage to=20 address your comments 
and issue an updated = version shortly.=20 Please find more inline.
 
Regards,
Valery.
----- Original Message -----
From:=20 Waltermire, David A. =
Sent: Tuesday, December 01, = 2015 6:15=20 AM
Subject: [IPsec] Review of=20 draft-ietf-ipsecme-ddos-protection-02

Please find my comments on=20 draft-ietf-ipsecme-ddos-protection-02 below. Overall I found the = content of=20 the draft to be very good.

 

Here is a quick summary of my = comments:

- There are still some placeholder sections in = the draft=20 that need to be written (i.e. sections 3.1, 3.2, = 11).

That's true. However = sections 3.1 and=20 3.2 are left due to miscommunication between the authors

while preparing = the draft for=20 publication. The Keyed-Cookie=20 Notification
and the Puzzle-Required Notification are left from the = earlier=20 version of the draft,

they are now replaced = with the PUZZLE=20 Notification and the Puzzle Solution Notification,

which are covered = in Sections=20 10.1 and 10.2.

 

The Security = Considerations section=20 need to be filled and I think we need more input

from the WG, since the = topic is both=20 important and subtle.

- I don=92t recall seeing many comments on the = list, if any,=20 on sections 6 through 10. In general I=92d like to see more review and = comments=20 on these sections in the draft before the draft goes to = WGLC.

- Also related to sections 6 =96 10, there appear = to be a=20 number of requirements that are not capitalized according to RFC 2119 = in these=20 sections. Anyone willing to volunteer to review the draft and make=20 recommendations for RCF2119 wording changes?

- I also found quite a few NITS relating to = spelling,=20 grammar, and punctuation. Given the number of nits, it would be good = to=20 produce a clean draft for additional review, so we don=92t duplicate = review=20 effort.

 

Yoav and Valery, do you have a sense of when you = can turn=20 around an update to this draft with these comments = addressed?

 

Regards,

Dave

 

Comments/Questions:

----------------------------

 

General:

 

There seem to be places in the draft where = RFC2119=20  wording should be used (i.e. sections 6 - 10). It would be good = to see=20 more review and comments on this section to make sure we are 1) = providing=20 appropriate guidance and 2) using the appropriate normative language. = For=20 example in section 6:

 

s/DDoS attack, it is suggested that no Cookie or = puzzles be=20 used/DDoS attack, it is RECOMMENDED that no Cookie or puzzles be=20 used/

I agree that it is good = idea if the=20 draft is reviewed for the proper use of RFC2119 keywords.

Section 3:

 

Is it possible if =93the same value is sent to = all=20 Initiators=94, that the attacker could coordinate solving the puzzle = across a=20 number of attack hosts to achieve some efficiency? If so, it might be = good to=20 recommend that a new challenge be sent to each host for each=20 SA.

Here "the same value" = means "the same=20 number of zero bits", i.e. the same puzzle difficulty. The puzzles = themselves=20 must be different

for each initiator. = Should we=20 rephrase the para to make it more clear?

Sections 3.1 and 3.2 need to be completed or = removed. Some=20 of this looks like it may be included in Section 8. It also looks to = be fully=20 described in sections 10.1 and 10.2. Some work is needed to sort this=20 out.

They should be removed. = As I've said=20 they were left due to miscommunication in a rush conditions.

Section 5:

 

I am not a fan of using the phrase =93but the = current=20 thinking=94, since this may be read many years from now. This = paragraph should=20 be reworked to make it more temporally relevant. Perhaps you can tie = the=20 thinking directly to the degree of IPv6 NAT usage directly and avoid = the=20 temporal qualifier?

I tend to agree with = you, however I'd=20 let Yoav comment on this.

Section 6:

 

The phrase =93the amount of failed IKE_AUTH = exchanges to=20 never exceed the threshold of attack detection=94 doesn=92t make sense = and needs=20 to be reworded.

 

In the phrase =93only defensive measure is the = monitoring=94,=20 it is not clear what is being monitored. I am assuming this is about=20 monitoring half-open SAs. This should be clarified.

OK.

Section 8.2.1:

 

Shouldn=92t the puzzle used in the IKE_SA_INIT be = different=20 than the puzzle used in the IKE_AUTH exchange to prevent the initiator = from=20 sending back a cached response or am I misunderstanding something? = Same=20 comment for section 8.2.1.2.

They will be different due to the differences in = construction of the=20 string S. In initial exchange the S is the content

of the cookie, = while in the=20 IKE_AUTH puzzles the S is the concatenation of the Responder's nonce = (Nr) and=20 Responder's SPI (SPIr).

It is very = unlikely=20 that these two S are the same. Should we add some clarification on = this?

 Section 11:

 

The security consideration section needs to be = completed.=20 Perhaps this could be made a summary of the threats and related=20 countermeasures described in the document?

Certainly. However this = summary might=20 not be enough, since the topic is subtle and it's easy to miss some = important=20 details.

I think we need more = reviews and more=20 comments.

Nits:

------

I agree with all = of the nits=20 even before I read them. Thank=20 you,

we'll incorporate the = suggested=20 changes into the next version of the draft.

 

------=_NextPart_000_0809_01D12C4F.3F64E370-- From nobody Tue Dec 1 06:58:44 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0CA1ABD35 for ; Tue, 1 Dec 2015 06:58:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 gIwwnHh_zXcw for ; Tue, 1 Dec 2015 06:58:42 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 042F71A92ED for ; Tue, 1 Dec 2015 06:58:42 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id EEDD12009E; Tue, 1 Dec 2015 10:03:49 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 4CCEA63757; Tue, 1 Dec 2015 09:58:41 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3CF3863753; Tue, 1 Dec 2015 09:58:41 -0500 (EST) From: Michael Richardson To: "Scott Fluhrer \(sfluhrer\)" In-Reply-To: References: <22069.1448830591@sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Cc: IPsecme WG Subject: Re: [IPsec] certificate lifetimes vs SA lifetimes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 14:58:43 -0000 --=-=-= Content-Type: text/plain Scott Fluhrer (sfluhrer) wrote: >> From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Michael >> Richardson >> >> It is my belief/memory that IKEv2 implementations should NOT limit SA >> (PARENT or CHILD) lifetimes based upon certificate lifetime or CRL lifetime. >> >> Neither rfc4945 (pki4ipsec) nor rfc7296 seems to confirm or deny this. >> Yet, I'm sure that this was consensus at some point. Maybe I've mis- >> remembered? >> What document did I miss? > It's listed as a requirement in 4301; section 4.4.2.1, Data Items in > the SAD, which is the obvious place one should look for requirements on > how IPSec/IKE interacts with PKI. Yes, that would be an obvious place to look for CHILD SA lifetimes. I didn't think to look in 4301 for requirements on IKEv2. What about PARENT SA lifetimes? :-) > See the bullet point 'Lifetime of this SA': -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVl21noCLcPvd0N1lAQLiewgAorTdtFBzCGM4oZ2R+lAGDjV7senKm4qY vB9pVnhJSBXzd+yAG0la8zfMSLI0ZQ6oS86OTokFj6HYa5cZfgJSQhwL53bpIB6p dRhw/8cgHhTRakuzUvgtruchGufbWJbsBIUeJKN4TkV5IcjQbo5cXI89FmdCR4tg Ax8le/MtU8xs7j0Chi/K0N/HedoCnqyxOb2uZQ+jfPX4VnLUzJVRl4K5OGVv6l2P jJa7aKc7z9PSr/+YhKfJFUiliAJqcjOVRRbQ+XknGo4KR4GV5iVIlUdR+7jduqSf XoUFuLiQC4yxKUSenc/fWBCDJCpzTMbg7jGPv4mZ5rzwqBHlAwqr9A== =JtE5 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Dec 1 07:08:04 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAFE51A87A2 for ; Tue, 1 Dec 2015 07:08:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 zsd0LzZ8LSn5 for ; Tue, 1 Dec 2015 07:08:01 -0800 (PST) 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 0A35A1A8A59 for ; Tue, 1 Dec 2015 07:07:59 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3p96Hc1CHPz2DB; Tue, 1 Dec 2015 16:07:56 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=YugM3kDk X-OPENPGPKEY: Message passed unmodified 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 YVGjMepvE7Am; Tue, 1 Dec 2015 16:07:55 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 1 Dec 2015 16:07:55 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPS id 89A92800C6; Tue, 1 Dec 2015 10:07:54 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1448982474; bh=98hRbr0fydxWDfPeZwlOZhQGwyj7tru9DvPxEJTNto0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=YugM3kDk4AojHghezCEnlmtGp6W465l8qJjMku6npd91pULmnXSYgjRqARpBSYvwx U5xAQ/DnUTqPzpSJWuU1KRS4rGhF+BBonYEq3nvQuNdk1IBuqLA95mY3Dm0S8CnmUN eAEcEXl68rqCzduakspBsF/xe4HJ0bnovFTFwcRA= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.2/8.15.2/Submit) with ESMTP id tB1F7s0R017379; Tue, 1 Dec 2015 10:07:54 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 1 Dec 2015 10:07:54 -0500 (EST) From: Paul Wouters To: "ipsec@ietf.org WG" In-Reply-To: <23236.1448981921@sandelman.ca> Message-ID: References: <22069.1448830591@sandelman.ca> <23236.1448981921@sandelman.ca> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] certificate lifetimes vs SA lifetimes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 15:08:02 -0000 On Tue, 1 Dec 2015, Michael Richardson wrote: > Yes, that would be an obvious place to look for CHILD SA lifetimes. > I didn't think to look in 4301 for requirements on IKEv2. > > What about PARENT SA lifetimes? :-) Those are not negotiated, so if any side cares they can re-authenticate the parent SA? Paul From nobody Tue Dec 1 08:03:54 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDCD1ACD6D for ; Tue, 1 Dec 2015 08:03:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 PSpSqkTyX-8s for ; Tue, 1 Dec 2015 08:03:47 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0717.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:717]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AFA81ACD6B for ; Tue, 1 Dec 2015 08:03:46 -0800 (PST) Received: from DM2PR09MB0365.namprd09.prod.outlook.com (10.160.247.18) by DM2PR09MB0365.namprd09.prod.outlook.com (10.160.247.18) with Microsoft SMTP Server (TLS) id 15.1.331.20; Tue, 1 Dec 2015 16:03:22 +0000 Received: from DM2PR09MB0365.namprd09.prod.outlook.com ([10.160.247.18]) by DM2PR09MB0365.namprd09.prod.outlook.com ([10.160.247.18]) with mapi id 15.01.0331.023; Tue, 1 Dec 2015 16:03:22 +0000 From: "Waltermire, David A." To: Valery Smyslov , "IPsec@ietf.org" Thread-Topic: [IPsec] Review of draft-ietf-ipsecme-ddos-protection-02 Thread-Index: AdEr4+tdhV9JhV9OQz+OdTVdFG4uswAUjI2BAAZRdDA= Date: Tue, 1 Dec 2015 16:03:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.227.39] x-microsoft-exchange-diagnostics: 1; DM2PR09MB0365; 5:WLCPeaiC6ea08lTnemlaX/a3NbZEXfpLKkkqs9WCx2eR5yBmDyVGsGxA48AfkiuiaQWD4+ln62dzJWJ2mvhu3+qvuI6su6mzZzjeOlLs/9ZrQB+zTuZr4+TeTZARr8qZ5PzVpSO+1q+a6L7f4R9LKg==; 24:0OHwtBzWoHmBVRcFOhazG75e5kUMiIPnwROFQI3C7ziQdspbE2CneeHAzQGYE8eZYEPyBhviwYpZ6L1gEHo+koE+r+tDOtTXxVzglu0ZBd8= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0365; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671)(65766998875637); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(10201501046)(3002001); SRVR:DM2PR09MB0365; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0365; x-forefront-prvs: 07778E4001 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(199003)(377454003)(13464003)(2950100001)(19580405001)(16236675004)(106356001)(790700001)(5001960100002)(5004730100002)(5001770100001)(33656002)(6116002)(87936001)(76176999)(105586002)(5002640100001)(1220700001)(74316001)(11100500001)(10400500002)(5008740100001)(230783001)(586003)(19300405004)(19580395003)(102836003)(77096005)(54356999)(66066001)(3846002)(81156007)(40100003)(19625215002)(92566002)(2501003)(107886002)(5003600100002)(99286002)(1096002)(15975445007)(97736004)(50986999)(2900100001)(76576001)(86362001)(101416001)(122556002)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0365; H:DM2PR09MB0365.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR09MB0365B8E8F50625F8F2A43104F00F0DM2PR09MB0365namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Dec 2015 16:03:21.8401 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0365 Archived-At: Subject: Re: [IPsec] Review of draft-ietf-ipsecme-ddos-protection-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 16:03:53 -0000 --_000_DM2PR09MB0365B8E8F50625F8F2A43104F00F0DM2PR09MB0365namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Valery Smyslov [mailto:svanru@gmail.com] Sent: Tuesday, December 01, 2015 7:45 AM To: Waltermire, David A. ; IPsec@ietf.org Subject: Re: [IPsec] Review of draft-ietf-ipsecme-ddos-protection-02 Hi David, thank you for the careful review. I hope we'll manage to address your comme= nts and issue an updated version shortly. Please find more inline. Regards, Valery. ----- Original Message ----- From: Waltermire, David A. To: IPsec@ietf.org Sent: Tuesday, December 01, 2015 6:15 AM Subject: [IPsec] Review of draft-ietf-ipsecme-ddos-protection-02 Please find my comments on draft-ietf-ipsecme-ddos-protection-02 below. Ove= rall I found the content of the draft to be very good. Here is a quick summary of my comments: - There are still some placeholder sections in the draft that need to be wr= itten (i.e. sections 3.1, 3.2, 11). That's true. However sections 3.1 and 3.2 are left due to miscommunication = between the authors while preparing the draft for publication. The Keyed-Cookie Notification and the Puzzle-Required Notification are left from the earlier version of t= he draft, they are now replaced with the PUZZLE Notification and the Puzzle Solution = Notification, which are covered in Sections 10.1 and 10.2. The Security Considerations section need to be filled and I think we need m= ore input from the WG, since the topic is both important and subtle. Agreed. - I don't recall seeing many comments on the list, if any, on sections 6 th= rough 10. In general I'd like to see more review and comments on these sect= ions in the draft before the draft goes to WGLC. - Also related to sections 6 - 10, there appear to be a number of requireme= nts that are not capitalized according to RFC 2119 in these sections. Anyon= e willing to volunteer to review the draft and make recommendations for RCF= 2119 wording changes? - I also found quite a few NITS relating to spelling, grammar, and punctuat= ion. Given the number of nits, it would be good to produce a clean draft fo= r additional review, so we don't duplicate review effort. Yoav and Valery, do you have a sense of when you can turn around an update = to this draft with these comments addressed? Regards, Dave Comments/Questions: ---------------------------- General: There seem to be places in the draft where RFC2119 wording should be used = (i.e. sections 6 - 10). It would be good to see more review and comments on= this section to make sure we are 1) providing appropriate guidance and 2) = using the appropriate normative language. For example in section 6: s/DDoS attack, it is suggested that no Cookie or puzzles be used/DDoS attac= k, it is RECOMMENDED that no Cookie or puzzles be used/ I agree that it is good idea if the draft is reviewed for the proper use of= RFC2119 keywords. Section 3: Is it possible if "the same value is sent to all Initiators", that the atta= cker could coordinate solving the puzzle across a number of attack hosts to= achieve some efficiency? If so, it might be good to recommend that a new c= hallenge be sent to each host for each SA. Here "the same value" means "the same number of zero bits", i.e. the same p= uzzle difficulty. The puzzles themselves must be different for each initiator. Should we rephrase the para to make it more clear? I believe rephrasing would be helpful in making this more clear. Sections 3.1 and 3.2 need to be completed or removed. Some of this looks li= ke it may be included in Section 8. It also looks to be fully described in = sections 10.1 and 10.2. Some work is needed to sort this out. They should be removed. As I've said they were left due to miscommunication= in a rush conditions. Section 5: I am not a fan of using the phrase "but the current thinking", since this m= ay be read many years from now. This paragraph should be reworked to make i= t more temporally relevant. Perhaps you can tie the thinking directly to th= e degree of IPv6 NAT usage directly and avoid the temporal qualifier? I tend to agree with you, however I'd let Yoav comment on this. Section 6: The phrase "the amount of failed IKE_AUTH exchanges to never exceed the thr= eshold of attack detection" doesn't make sense and needs to be reworded. In the phrase "only defensive measure is the monitoring", it is not clear w= hat is being monitored. I am assuming this is about monitoring half-open SA= s. This should be clarified. OK. Section 8.2.1: Shouldn't the puzzle used in the IKE_SA_INIT be different than the puzzle u= sed in the IKE_AUTH exchange to prevent the initiator from sending back a c= ached response or am I misunderstanding something? Same comment for section= 8.2.1.2. They will be different due to the differences in construction of the string= S. Ininitial exchange the S is the content of the cookie, while in the IKE_AUTH puzzles the S is the concatenation of = the Responder's nonce (Nr) and Responder's SPI (SPIr). It is very unlikely thatthese two S are the same. Should we add some clarif= icationon this? Looking back the values for S are defined in 8.1.2.1 and 8.2.2.1. The text = in the first paragraph of section 8.2.2 makes the construction distinction = clear. This did not jump out right away for me. It might be more clear to m= ake this distinction up front at the beginning of section 8 by adding an in= troductory paragraph? This text could also describe the layout of section 8= as well. Section 11: The security consideration section needs to be completed. Perhaps this coul= d be made a summary of the threats and related countermeasures described in= the document? Certainly. However this summary might not be enough, since the topic is sub= tle and it's easy to miss some important details. I think we need more reviews and more comments. Agreed. Nits: ------ I agree with all of the nits even before I read them. Thank you, we'll incorporate the suggested changes into the next version of the draft. --_000_DM2PR09MB0365B8E8F50625F8F2A43104F00F0DM2PR09MB0365namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: Valery Smyslov [mailto:svanru@gmail.com= ]
Sent: Tuesday, December 01, 2015 7:45 AM
To: Waltermire, David A. <david.waltermire@nist.gov>; IPsec@ie= tf.org
Subject: Re: [IPsec] Review of draft-ietf-ipsecme-ddos-protection-02=

 

Hi David,

 

thank you for the careful review. I hope we'll m= anage to address your comments 

and issue an updated version shortly. Pleas= e find more inline.

 

Regards,

Valery.

----- Original Message -----

Sent: Tuesday, December 01, 2015 6:15 AM=

Subject: [IPsec] Review of draft-ietf-ip= secme-ddos-protection-02

 

Please find my comments on draft-ietf-ipsecme-ddos-p= rotection-02 below. Overall I found the content of the draft to be very goo= d.

 

Here is a quick summary of my comments:

- There are still some placeholder sections in the d= raft that need to be written (i.e. sections 3.1, 3.2, 11).

That's true. However sections 3.1 and 3.2 are left du= e to miscommunication between the authors

while preparing the draft for publication. = The Keyed-Cookie Notification
and the Puzzle-Required Notification are left from the earlier version of t= he draft,

they are now replaced with the PUZZLE Notification an= d the Puzzle Solution Notification,

which are covered in Sections 10.1 and 10.2. 

 

The Security Considerations section need to be filled= and I think we need more input

from the WG, since the topic is both important and su= btle.

 

Agreed.

 

- I don’t recall seeing many comments on the l= ist, if any, on sections 6 through 10. In general I’d like to see mor= e review and comments on these sections in the draft before the draft goes = to WGLC.

- Also related to sections 6 – 10, there appea= r to be a number of requirements that are not capitalized according to RFC = 2119 in these sections. Anyone willing to volunteer to review the draft and= make recommendations for RCF2119 wording changes?

- I also found quite a few NITS relating to spelling= , grammar, and punctuation. Given the number of nits, it would be good to p= roduce a clean draft for additional review, so we don’t duplicate rev= iew effort.

 

Yoav and Valery, do you have a sense of when you can= turn around an update to this draft with these comments addressed?

 

Regards,

Dave

 

Comments/Questions:

----------------------------

 

General:

 

There seem to be places in the draft where RFC2119 &= nbsp;wording should be used (i.e. sections 6 - 10). It would be good to see= more review and comments on this section to make sure we are 1) providing = appropriate guidance and 2) using the appropriate normative language. For example in section 6:

 

s/DDoS attack, it is suggested that no Cookie or puz= zles be used/DDoS attack, it is RECOMMENDED that no Cookie or puzzles be us= ed/

I agree that it is good idea if the draft is reviewed= for the proper use of RFC2119 keywords.

Section 3:

 

Is it possible if “the same value is sent to a= ll Initiators”, that the attacker could coordinate solving the puzzle= across a number of attack hosts to achieve some efficiency? If so, it migh= t be good to recommend that a new challenge be sent to each host for each SA.

Here "the same value" means "the same = number of zero bits", i.e. the same puzzle difficulty. The puzzles the= mselves must be different

for each initiator. Should we rephrase the para to ma= ke it more clear?

 

I believe rephrasing w= ould be helpful in making this more clear.

 

Sections 3.1 and 3.2 need to be completed or removed= . Some of this looks like it may be included in Section 8. It also looks to= be fully described in sections 10.1 and 10.2. Some work is needed to sort = this out.

They should be removed. As I've said they were left d= ue to miscommunication in a rush conditions.

Section 5:

 

I am not a fan of using the phrase “but the cu= rrent thinking”, since this may be read many years from now. This par= agraph should be reworked to make it more temporally relevant. Perhaps you = can tie the thinking directly to the degree of IPv6 NAT usage directly and avoid the temporal qualifier?

I tend to agree with you, however I'd let Yoav commen= t on this.

Section 6:

 

The phrase “the amount of failed IKE_AUTH exch= anges to never exceed the threshold of attack detection” doesn’= t make sense and needs to be reworded.

 

In the phrase “only defensive measure is the m= onitoring”, it is not clear what is being monitored. I am assuming th= is is about monitoring half-open SAs. This should be clarified.<= /p>

OK.

Section 8.2.1:

 

Shouldn’t the puzzle used in the IKE_SA_INIT b= e different than the puzzle used in the IKE_AUTH exchange to prevent the in= itiator from sending back a cached response or am I misunderstanding someth= ing? Same comment for section 8.2.1.2.

They will be different due to the differences in cons= truction of the string S. Ininitial exchange the S is the content

of the cookie, while in the IKE_AUTH puzzles the S is= the concatenation of the Responder's nonce (Nr) and Responder's SPI (SPIr)= .

It is very unlikely thatthese two S are the same. Sho= uld we add some clarificationon this?

 

Looking back the value= s for S are defined in 8.1.2.1 and 8.2.2.1. The text in the first paragraph= of section 8.2.2 makes the construction distinction clear. This did not ju= mp out right away for me. It might be more clear to make this distinction up front at the beginning of section 8= by adding an introductory paragraph? This text could also describe the lay= out of section 8 as well.

 

Section 11:

 

The security consideration section needs to be compl= eted. Perhaps this could be made a summary of the threats and related count= ermeasures described in the document?

Certainly. However this summary might not be enough, = since the topic is subtle and it's easy to miss some important details.

I think we need more reviews and more comments.<= /o:p>

 

Agreed.

 

Nits:

------

I agree with all of the nits even before I read = them. Thank you,

we'll incorporate the suggested changes into the next= version of the draft.

 

--_000_DM2PR09MB0365B8E8F50625F8F2A43104F00F0DM2PR09MB0365namp_-- From nobody Tue Dec 1 08:30:43 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C97E01A1A78 for ; Tue, 1 Dec 2015 08:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 RwjGHBo444NZ for ; Tue, 1 Dec 2015 08:30:39 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EB7A1A044E for ; Tue, 1 Dec 2015 08:30:39 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 893BA2009E; Tue, 1 Dec 2015 11:35:47 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 9F80763757; Tue, 1 Dec 2015 11:30:38 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 8554A63753; Tue, 1 Dec 2015 11:30:38 -0500 (EST) From: Michael Richardson To: Tero Kivinen In-Reply-To: <22109.29462.49109.320818@fireball.acr.fi> References: <22069.1448830591@sandelman.ca> <22109.29462.49109.320818@fireball.acr.fi> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Cc: ipsec@ietf.org, Paul_Koning@Dell.com Subject: Re: [IPsec] certificate lifetimes vs SA lifetimes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 16:30:42 -0000 --=-=-= Content-Type: text/plain Tero Kivinen wrote: > We have discussed about this, but I think we never really reached > concensus on one thing. There are reasons to limit SA lifetimes, and > there are reasons not to. > Certificate lifetime is usually ok, as they are long lived, but CRL > lifetimes are not something that should be used for limiting SA > lifetimes. If you have for example hourly CRLs, that would mean that > every connection will do reauthentication hourly and everybody does > that reauthnetication at the same time, as they all use same CA, thus > same CRL. > It would be much better to implement it so that you store the > certificate used for authentication and then put verification timers > in the future when something happens, i.e. CRL expires etc. When the > CRL expires, you download new CRL, and go through that and if you have > any connections using any certificates on the CRL, you delete those > connections. I think that this is the right approach to CRLs, and I'd like to see this concept written down so that it can be referenced. Knowing this helps the security review for protocols that live on top of IPsec. > On the other hand if someones certificate gets compromized, or > employee leaves the company, you do not want to wait until next CRL > lifetime. You remove his account from the user database, and push that > change out to the VPN gateways, and if there are any connections open > using that account that got deleted, you remove those connections > (i.e. re-evaluate your policy for existing connections after policy > update). This will allow you to disable access in timely fashion and > you can still use more usable times for CRLs and Certificates. In context of how IPsec has been used for remote access to date, this is feasible. In situations where IPsec might be used as part of an autonomic system, this won't work with some protocol to do this. OCSP can't help here because we don't know when to do another OCSP, so I think the recommendation is going to be to set the CRL lifetime shorter. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVl3LK4CLcPvd0N1lAQJ+Rgf+JsORZchkF86gxqIIGVapfPg+ukysG3Xx TUUcSdYpDtFZCxEYGbiADdIY1VKAxM7Z4fXVuzq6zvMqBWpD6CgrpQ2iZHgXxqV7 TDWHrZKbteZGxRebhG2sDcMGmBfFuFcsLUEC/72wPYIvJrPZss7W0nVh9tq954U3 h64assnB8LJT9wOlGxwoQCIY1bI2tGu0SWiNxW1qVTIJXxDM6yI3g0uO0eCfMqoK dxRnLHImJUS6Hwk5qazv3cS/NU8DUbSBmcpKX93j0fMORstfC590hi0e9smoK9Bd pkMJobgMZUNkBpHLi3F6J1YHryQVjpG4I9GMZDMTTqxr0YG+EXVaXw== =twX3 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Dec 1 09:11:01 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E39731ACECE for ; Tue, 1 Dec 2015 09:10:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 DJ7aEQ4XY3No for ; Tue, 1 Dec 2015 09:10:58 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 862F41ACECF for ; Tue, 1 Dec 2015 09:10:58 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 375912009E for ; Tue, 1 Dec 2015 12:16:06 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 3107663757; Tue, 1 Dec 2015 12:10:57 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0D38063753 for ; Tue, 1 Dec 2015 12:10:57 -0500 (EST) From: Michael Richardson To: "ipsec\@ietf.org WG" In-Reply-To: References: <22069.1448830591@sandelman.ca> <23236.1448981921@sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Subject: Re: [IPsec] certificate lifetimes vs SA lifetimes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 17:11:00 -0000 --=-=-= Content-Type: text/plain Paul Wouters wrote: >> Yes, that would be an obvious place to look for CHILD SA lifetimes. >> I didn't think to look in 4301 for requirements on IKEv2. >> >> What about PARENT SA lifetimes? :-) > Those are not negotiated, so if any side cares they can re-authenticate > the parent SA? The fact that they aren't negotiated, doesn't change the fact that there is a lifetime. That it isn't negotiated is good: the lifetime of the two certificates and CRLs could be very different. Upon PARENT SA re-authentication, one will find out if the certificate is still valid, and run all of the CRL checks. So, if one limits the PARENT SA's lifetime to the CRL lifetime (which ought to be less than the certificate's lifetime), then one will do all the checking at the right time. Tero's point, however, is that you don't have actually do all of that rekeying. You can simply look at the CRL, and if it turns out the key is bad, you kill the SA, regardless of the PARENT SA lifetime. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVl3Um4CLcPvd0N1lAQK2Egf/d/2h0h4xx7aTISnHDMIptpKmqZHXc2YF Cjs8HC3TueKgna15QFTzZkCd9qJSu+DUc6EvIeFRXabYr656aS5hEf1rdmQlfxo4 lJvYUB6zmky5CGr8EB2yScDPrjJe32z70pfeKkA9gqpFd5oC7XJU0mf/BmYOf2b1 FUTUW276VzAPxRuG3hdFJrG8JWOj1U/UFWHeTq75E5aM18qbwhuO0jz2wkyoXWJt scq2lBoH9h+7AOWdhEdLCtSwZ+LaQhOWURj8Kvx7ppcLG4Acv33sFzhOrw+8rdyU DHBiBmGTjw8EpTtQgqgwdiC2b7d5PYe2VVO77TvreShHYcZeZpbP3Q== =wn+i -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Dec 1 09:51:35 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C02BF1B2E0B for ; Tue, 1 Dec 2015 09:51:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 EDd7LJC_q1Ul for ; Tue, 1 Dec 2015 09:51:29 -0800 (PST) Received: from ausc60pc101.us.dell.com (ausc60pc101.us.dell.com [143.166.85.206]) by ietfa.amsl.com (Postfix) with ESMTP id EF4101B2DE7 for ; Tue, 1 Dec 2015 09:51:27 -0800 (PST) DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version:Return-Path; b=ZtDRUL1HItBY8iJfTB8fVcDx4xNi1ehivO/j9uU+TVeI0zGC/y6+rwpA Pa/OhTrd23sdpp9UFnrPug9wOI4TldkT/B1AGhu09KEDXrDbuWo6WTfNG 4yfGzt2SLBYTC28M32nR4n9UC3NeVDkrOP9S/9O6lvIh1YCZ6pJ9Fv44a s=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1448992165; x=1480528165; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vo9acnmv/hPj4w6MH5FHf3Rk9zuipnrXFo399eDlA6Q=; b=TRDzkybzUpoWSuR633OAzLXYUeXBjq1tA9Zi0H9QB91NjlwCG2L0WTDq CvrPwOfDfgGEfvZ0A4XS/sa/vPxLdOVoWMiC4jMLsvKreGtU+Xudc1HXt QU6kUgts1ZKyDGUJkeTwKG3DLkTQHfv7bShVgUmcL5BXTSfi8XQXw304z w=; X-LoopCount0: from 10.175.216.251 X-IronPort-AV: E=Sophos;i="5.20,369,1444712400"; d="scan'208";a="872362794" From: To: Thread-Topic: [IPsec] certificate lifetimes vs SA lifetimes Thread-Index: AQHRKuhyuc9ljkr7Z0m0q6+f373My561HPUAgAE0BACAAHg6gA== Date: Tue, 1 Dec 2015 17:25:06 +0000 Message-ID: <92D09372-483C-42E5-A0AF-4609B418D3EF@dell.com> References: <22069.1448830591@sandelman.ca> <22109.29462.49109.320818@fireball.acr.fi> In-Reply-To: <22109.29462.49109.320818@fireball.acr.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.177.90.67] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: ipsec@ietf.org, mcr+ietf@sandelman.ca Subject: Re: [IPsec] certificate lifetimes vs SA lifetimes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 17:51:32 -0000 > On Dec 1, 2015, at 5:14 AM, Tero Kivinen wrote: >=20 > Paul_Koning@Dell.com writes: >>=20 >>> On Nov 29, 2015, at 3:56 PM, Michael Richardson = wrote: >>>=20 >>>=20 >>> It is my belief/memory that IKEv2 implementations should NOT limit SA >>> (PARENT or CHILD) lifetimes based upon certificate lifetime or CRL life= time. >>>=20 >>> Neither rfc4945 (pki4ipsec) nor rfc7296 seems to confirm or deny this. >>> Yet, I'm sure that this was consensus at some point. Maybe I've mis-re= membered? >>> What document did I miss? >>=20 >> I don't remember one way or the other. It seems perfectly logical >> to limit SA lifetime. This certainly seems to be what customers >> expect (based on some feedback I've seen). =20 >=20 > We have discussed about this, but I think we never really reached > concensus on one thing. There are reasons to limit SA lifetimes, and > there are reasons not to. >=20 > Certificate lifetime is usually ok, as they are long lived, but CRL > lifetimes are not something that should be used for limiting SA > lifetimes. If you have for example hourly CRLs, that would mean that > every connection will do reauthentication hourly and everybody does > that reauthnetication at the same time, as they all use same CA, thus > same CRL. It might mean that, but if you recognize this issue, you can adjust the tim= ers by a random fraction. This is a classic answer to the problem of "ever= yone doing stuff at the same time" problem. It's not as well known as it s= hould be, unfortunately. paul From nobody Wed Dec 2 14:01:51 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 243F61B2DF0 for ; Wed, 2 Dec 2015 14:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 aIir5T7Gz01W for ; Wed, 2 Dec 2015 14:01:48 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::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 7E2DD1B2DEF for ; Wed, 2 Dec 2015 14:01:47 -0800 (PST) Received: by wmvv187 with SMTP id v187so276462914wmv.1 for ; Wed, 02 Dec 2015 14:01:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=nKm1HVODYNuZhYqY6QqPucS/0OhpfxZJBymnuwRbBTs=; b=edao8Oce8bi+cQsDx1P3hU4Is/6kY3Or1TnMondoxILmTJsUlwud31q8xio7BeI5rk QIsEHq9jjUFzG8N8/NOEjjhkWdy4JMI9OgLDaO6t97qd4+15s0YjRZOGJL9qjBK05zwC ojE0hRlXMp92iu9ebmAFhJ6hjiyPPH7tfRdf2BW3zUXpMWFZi/ZSLxOg033hHvnC3xk7 zSbiTAv66ioxmXxiRcUmvlbtlaXltZQrym6i3zsR00P2LC/dKVZbvyWKhNERSKq2/5iV 2/RVNlJZsMJXJ3BOFXOVVDWfQJDnRBqsJSWeoo3vSBE//gWm0yFZ6qffUpWgz8QLufQL HVsg== MIME-Version: 1.0 X-Received: by 10.194.201.134 with SMTP id ka6mr7420143wjc.116.1449093705799; Wed, 02 Dec 2015 14:01:45 -0800 (PST) Sender: mglt.ietf@gmail.com Received: by 10.194.9.106 with HTTP; Wed, 2 Dec 2015 14:01:45 -0800 (PST) In-Reply-To: References: <0748F101-7104-4F07-B440-31A9CF63BE32@gmail.com> <9EBE3C6E-C7F2-4327-B4E2-3363BD96ECC1@gmail.com> <56421D6F.7080506@gmail.com> <22082.23345.969526.729086@fireball.acr.fi> <564A1549.1010001@gmail.com> Date: Wed, 2 Dec 2015 16:01:45 -0600 X-Google-Sender-Auth: VD8ZtNPInuKOG8popNEhzRSj-bY Message-ID: From: Daniel Migault To: Tommy Pauly Content-Type: multipart/alternative; boundary=047d7ba97e6494a3780525f16b59 Archived-At: Cc: IPsecME WG , Paul Wouters Subject: Re: [IPsec] RFC 4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 22:01:50 -0000 --047d7ba97e6494a3780525f16b59 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Please se the current version of the document with the subsection in the Introduction. https://github.com/mglt/drafts/commit/ef72ea482af74d4226d3059237024f63d0add= 01b The subsections are: 1.1 Updating Mandatory to Implement Algorythms 1.2 Algorithm Status Update Policy 1.3 Audience of the Document Feel free to provide any comment. I beleive we have addressed all comments we received. I am finding the terminology mandatory-to-implement maybe a bit misleading for status like MAY or a MUST NOT. Any suggestion to clarify that? BR, Daniel On Mon, Nov 30, 2015 at 12:22 PM, Daniel Migault < daniel.migault@ericsson.com> wrote: > Hi Tommy, > > Thanks for the proposition Tommy, I thnik that will clearer to have > dedicated subsections in the intro. Here are the subsection I would > propose. I am waiting for the WG feed back before updating the draft, so > please let m eknow whether: > > A) You like the idea of subsection in the intro > B) You DO NOT like the idea of subsections > > C) If you like the following: > c1) The need for mandatory-to-implement algorithms > c2) The scope of the document (IKEv2 + implementer) > c3) Updating algorithm status (deprecation of algorithms and the IoT > section) > > D) If you have other propositions. > > I will update the draft this week according to the responses. > > BR, > Daniel > > > On Mon, Nov 30, 2015 at 12:20 PM, Tommy Pauly wrote: > >> Hi Daniel, >> >> Thanks for making these changes! I think this makes the document much >> clearer. >> >> With regards to the Introduction, it may be beneficial at this point to >> have subsections of the introduction to make it easier to parse. Right n= ow >> there seem to be several topics that don=E2=80=99t necessarily flow into= one >> another: explaining mandatory-to-implement algorithms, explaining which >> version of IKE is relevant, explaining deprecation of algorithms, and th= e >> IoT section. >> >> Thanks, >> tommy >> >> On Nov 26, 2015, at 2:58 PM, Daniel Migault >> wrote: >> >> Hi Paul and Tommy, >> >> Please find the new update of the draft: >> 1) text in the introduction has been added to specify the IoT use case, >> and the motivations for having IoT considerations in this document. >> 2) IoT has been indicated in the tables with a comment specifying that >> the requirement is for IoT interoperability. I was not able to have two >> lines in the postamble. It seems is not accepted as a children >> for >> 3) RFCs have been added in the reference section to enable xml2rfc to ru= n >> properly. >> >> The update is available here: >> >> https://github.com/mglt/drafts/commit/8c125fa2a82af21a44c5035c3311938d26= 443652 >> >> Feel free to comment update the text. >> >> BR, >> Daniel >> >> >> On Mon, Nov 23, 2015 at 11:20 AM, Paul Wouters wrote: >> >>> On Fri, 20 Nov 2015, Tommy Pauly wrote: >>> >>> On a broader note, many of the SHOULD algorithms (ENCR_AES_CCM_8, >>>> PRF_AES128_CBC, AUTH_AES-XCBC) are >>>> justified as being present for the purposes of Internet of Things >>>> devices. I tend to think that it would be >>>> more straightforward to have a separate document that explains the >>>> preferred algorithms for IoT devices (an >>>> IKEv2 profile for IoT, for example). However, if we do want to keep >>>> them in this document, I think it would >>>> help to have a section in the introduction to the document explaining >>>> the use case for the IoT devices and >>>> why they are now included in the bis document, whereas they were not >>>> relevant yet in RFC 4307. It may also >>>> be helpful to qualify the SHOULDs as pertaining more, perhaps, to >>>> servers; traditional VPN clients would >>>> generally not be interacting with IoT devices directly, and thus would >>>> have little reason to implement >>>> these algorithms. >>>> >>> >>> I would suggest if we want to do that, to just use a [*] notation where >>> the [*] gets explained as "For interoperability with IoT clients only" >>> >>> I would not want to leave it out because that will cause us to get >>> servers that won't support IoT devices. >>> >>> Paul >>> >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> >> >> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> > --047d7ba97e6494a3780525f16b59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Please se the current ver= sion of the document with the subsection in the Introduction.

https://github.com/mglt/drafts/commit/ef72ea482af74d4226d30592370= 24f63d0add01b

The subsections are:
=C2=A0=C2=A0 1.1 Updating = Mandatory to Implement Algorythms
=C2=A0=C2=A0 1.2 Algorithm Status Upda= te Policy
=C2=A0=C2=A0 1.3 Audience of the Document

Feel fr= ee to provide any comment. I beleive we have addressed all comments we rece= ived.

I am finding the terminology mandatory-to-implement mayb= e a bit misleading for status like MAY or a MUST NOT. Any suggestion to cla= rify that? =C2=A0

BR,
Daniel
On Mon, Nov 30, 2015 at 12:22 PM, Daniel Migaul= t <daniel.migault@ericsson.com> wrote:
H= i Tommy,

Thanks for the proposition Tommy, I thnik that will = clearer to have dedicated subsections in the intro. Here are the subsection= I would propose. I am waiting for the WG feed back before updating the dra= ft, so please let m eknow whether:

A) You like the idea of subsectio= n in the intro
B) You DO NOT like the idea of subsections

<= /div>
C) If you like the following:=C2=A0 =C2=A0
= =C2=A0=C2=A0=C2=A0 c1) The need for mandatory-to-implement algorithms
= =C2=A0=C2=A0=C2=A0 c2) The scope of the document (IKEv2 + implementer)
= =C2=A0=C2=A0=C2=A0 c3) Updating algorithm status (deprecation of algorithms= and=20 the IoT section)

D) If you have other propositions.
<= br>
I will update the draft this week according to the responses.=
=C2=A0
BR,
Daniel


On Mon, Nov 30, 2015 at 12:20 PM, Tommy Pauly <tpau= ly@apple.com> wrote:
Hi Daniel,
=
Thanks for making these changes! I think this makes the docu= ment much clearer.

With regards to the Introductio= n, it may be beneficial at this point to have subsections of the introducti= on to make it easier to parse. Right now there seem to be several topics th= at don=E2=80=99t necessarily flow into one another: explaining mandatory-to= -implement algorithms, explaining which version of IKE is relevant, explain= ing deprecation of algorithms, and the IoT section.

Thanks,
tommy

On Nov 26, 2015, at 2:58 PM, Daniel Migault <daniel.migault@ericsson.com= > wrote:

Hi Paul and Tommy,

=
Please find the new update of the draft:
1) text in the intro= duction has been added to specify the IoT use case, and the motivations for= having IoT considerations in this document.
2) IoT has been indicated in the tables with a comment specifying tha= t the requirement is for IoT interoperability. I was not able to have two l= ines in the postamble. It seems <artwork> is not accepted as a childr= en for <postamble>
3) RFCs have b= een added in the reference section to enable xml2rfc to run properly.
The update is available here:
https://github.com/mglt/drafts/commit/8c125fa2a8= 2af21a44c5035c3311938d26443652

= Feel free to comment update the text.

BR,
Daniel


On Mon, Nov 23, 2015 at 11:20 AM, Paul Wouters <<= a href=3D"mailto:paul@nohats.ca" target=3D"_blank">paul@nohats.ca> wrote:
On = Fri, 20 Nov 2015, Tommy Pauly wrote:

On a broader note, many of the SHOULD algorithms (ENCR_AES_CCM_8, PRF_AES12= 8_CBC,=C2=A0AUTH_AES-XCBC) are
justified as being present for the purposes of Internet of Things devices. = I tend to think that it would be
more straightforward to have a separate document that explains the preferre= d algorithms for IoT devices (an
IKEv2 profile for IoT, for example). However, if we do want to keep them in= this document, I think it would
help to have a section in the introduction to the document explaining the u= se case for the IoT devices and
why they are now included in the bis document, whereas they were not releva= nt yet in=C2=A0RFC 4307. It may also
be helpful to qualify the SHOULDs as pertaining more, perhaps, to servers; = traditional VPN clients would
generally not be interacting with IoT devices directly, and thus would have= little reason to implement
these algorithms.

 I would suggest if we want to do that, to just use a [*] notation where
the [*] gets explained as "For interoperability with IoT clients only&= quot;

I would not want to leave it out because that will cause us to get
servers that won't support IoT devices.
Paul


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



________________________= _______________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec



--047d7ba97e6494a3780525f16b59-- From nobody Wed Dec 2 14:25:29 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC441A00FC for ; Wed, 2 Dec 2015 14:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 HeRoYNWucKjS for ; Wed, 2 Dec 2015 14:25:24 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::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 A04131B2E77 for ; Wed, 2 Dec 2015 14:24:41 -0800 (PST) Received: by wmvv187 with SMTP id v187so547631wmv.1 for ; Wed, 02 Dec 2015 14:24:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ImRVdpFDHQf3HaE6cnz8Y1jE6UKy3ayqDZpoMohlb9E=; b=XzpfKAW8spmcCJwDaHsbp0qRC8PZhfubr8wNvyHPV5t8fcN/vwMlLnC3ydHg4Iv1E7 vwzaAv9pJR5XxTJ7SEOWWJ+O6z8wRBlf8xsdla+ANdWSqxoh4k8GtHlEXqbTKwjXLQ/Y RYcpWvRyZ/YUsNxocY0OpACXwa/JZ/CjVI+5tsPRDq3n2VozSvvHcB2jh2feRzGa3jNv kfw6WFII4X66B7vSq8mjfCF0DxI9+g90SZT6vya2hnoqnMARji2AhCNTOuMf7ZHq2LeQ HLBa/xIHzuzEA2Cg7X0mQ9ypVvCoVtNUb1ESsL5vgR4yexFVhtp8wHoemAS4WFRIjapT 89ow== MIME-Version: 1.0 X-Received: by 10.28.143.11 with SMTP id r11mr48389393wmd.28.1449095080283; Wed, 02 Dec 2015 14:24:40 -0800 (PST) Sender: mglt.ietf@gmail.com Received: by 10.194.9.106 with HTTP; Wed, 2 Dec 2015 14:24:40 -0800 (PST) In-Reply-To: References: <0748F101-7104-4F07-B440-31A9CF63BE32@gmail.com> <9EBE3C6E-C7F2-4327-B4E2-3363BD96ECC1@gmail.com> <56421D6F.7080506@gmail.com> <22082.23345.969526.729086@fireball.acr.fi> <564A1549.1010001@gmail.com> Date: Wed, 2 Dec 2015 16:24:40 -0600 X-Google-Sender-Auth: UUVyUxAFnqaxrQ9eCGSihUs-x_E Message-ID: From: Daniel Migault To: Tommy Pauly Content-Type: multipart/alternative; boundary=001a11469bd881955b0525f1bde2 Archived-At: Cc: IPsecME WG , Paul Wouters Subject: Re: [IPsec] RFC 4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 22:25:27 -0000 --001a11469bd881955b0525f1bde2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Please find the updated version with the new section titles suggested by Yaron: 1.1 Updating Mandatory to Implement Algorithms 1.2 Updating Algorithm Requirement Levels 1.3 Document Audience BR, Daniel https://github.com/mglt/drafts/commit/ffb6e9ad82bc952f3a891de232cd10be35387= 8a9 On Wed, Dec 2, 2015 at 4:01 PM, Daniel Migault wrote: > Hi, > > Please se the current version of the document with the subsection in the > Introduction. > > > https://github.com/mglt/drafts/commit/ef72ea482af74d4226d3059237024f63d0a= dd01b > > The subsections are: > 1.1 Updating Mandatory to Implement Algorythms > 1.2 Algorithm Status Update Policy > 1.3 Audience of the Document > > Feel free to provide any comment. I beleive we have addressed all comment= s > we received. > > I am finding the terminology mandatory-to-implement maybe a bit misleadin= g > for status like MAY or a MUST NOT. Any suggestion to clarify that? > > BR, > Daniel > > On Mon, Nov 30, 2015 at 12:22 PM, Daniel Migault < > daniel.migault@ericsson.com> wrote: > >> Hi Tommy, >> >> Thanks for the proposition Tommy, I thnik that will clearer to have >> dedicated subsections in the intro. Here are the subsection I would >> propose. I am waiting for the WG feed back before updating the draft, so >> please let m eknow whether: >> >> A) You like the idea of subsection in the intro >> B) You DO NOT like the idea of subsections >> >> C) If you like the following: >> c1) The need for mandatory-to-implement algorithms >> c2) The scope of the document (IKEv2 + implementer) >> c3) Updating algorithm status (deprecation of algorithms and the IoT >> section) >> >> D) If you have other propositions. >> >> I will update the draft this week according to the responses. >> >> BR, >> Daniel >> >> >> On Mon, Nov 30, 2015 at 12:20 PM, Tommy Pauly wrote: >> >>> Hi Daniel, >>> >>> Thanks for making these changes! I think this makes the document much >>> clearer. >>> >>> With regards to the Introduction, it may be beneficial at this point to >>> have subsections of the introduction to make it easier to parse. Right = now >>> there seem to be several topics that don=E2=80=99t necessarily flow int= o one >>> another: explaining mandatory-to-implement algorithms, explaining which >>> version of IKE is relevant, explaining deprecation of algorithms, and t= he >>> IoT section. >>> >>> Thanks, >>> tommy >>> >>> On Nov 26, 2015, at 2:58 PM, Daniel Migault >>> wrote: >>> >>> Hi Paul and Tommy, >>> >>> Please find the new update of the draft: >>> 1) text in the introduction has been added to specify the IoT use case, >>> and the motivations for having IoT considerations in this document. >>> 2) IoT has been indicated in the tables with a comment specifying that >>> the requirement is for IoT interoperability. I was not able to have two >>> lines in the postamble. It seems is not accepted as a childre= n >>> for >>> 3) RFCs have been added in the reference section to enable xml2rfc to >>> run properly. >>> >>> The update is available here: >>> >>> https://github.com/mglt/drafts/commit/8c125fa2a82af21a44c5035c3311938d2= 6443652 >>> >>> Feel free to comment update the text. >>> >>> BR, >>> Daniel >>> >>> >>> On Mon, Nov 23, 2015 at 11:20 AM, Paul Wouters wrote: >>> >>>> On Fri, 20 Nov 2015, Tommy Pauly wrote: >>>> >>>> On a broader note, many of the SHOULD algorithms (ENCR_AES_CCM_8, >>>>> PRF_AES128_CBC, AUTH_AES-XCBC) are >>>>> justified as being present for the purposes of Internet of Things >>>>> devices. I tend to think that it would be >>>>> more straightforward to have a separate document that explains the >>>>> preferred algorithms for IoT devices (an >>>>> IKEv2 profile for IoT, for example). However, if we do want to keep >>>>> them in this document, I think it would >>>>> help to have a section in the introduction to the document explaining >>>>> the use case for the IoT devices and >>>>> why they are now included in the bis document, whereas they were not >>>>> relevant yet in RFC 4307. It may also >>>>> be helpful to qualify the SHOULDs as pertaining more, perhaps, to >>>>> servers; traditional VPN clients would >>>>> generally not be interacting with IoT devices directly, and thus woul= d >>>>> have little reason to implement >>>>> these algorithms. >>>>> >>>> >>>> I would suggest if we want to do that, to just use a [*] notation wher= e >>>> the [*] gets explained as "For interoperability with IoT clients only" >>>> >>>> I would not want to leave it out because that will cause us to get >>>> servers that won't support IoT devices. >>>> >>>> Paul >>>> >>>> >>>> _______________________________________________ >>>> IPsec mailing list >>>> IPsec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipsec >>>> >>> >>> >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> >>> >> > --001a11469bd881955b0525f1bde2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Please find the updated version with the new s= ection titles suggested by Yaron:
1.1 Updating Mandatory to Implement A= lgorithms
1.2 Updating Algorithm Requirement Levels
1.3 Document Audi= ence

BR,
Daniel
https://github.com/mglt/draft= s/commit/ffb6e9ad82bc952f3a891de232cd10be353878a9

On Wed, Dec 2, 2015 at 4:01= PM, Daniel Migault <daniel.migault@ericsson.com> = wrote:
Feel free to provide an= y comment. I beleive we have addressed all comments we received.

I am finding the terminology mandatory-to-implement maybe a bit misleadi= ng for status like MAY or a MUST NOT. Any suggestion to clarify that? =C2= =A0

BR,
Daniel

On Mon, Nov 30, 2015 at 12:22 PM, Da= niel Migault <daniel.migault@ericsson.com> wrote:<= br>
=
Hi Tommy,

Thanks for the proposition Tommy, I thnik= that will clearer to have dedicated subsections in the intro. Here are the= subsection I would propose. I am waiting for the WG feed back before updat= ing the draft, so please let m eknow whether:

A) You like the idea o= f subsection in the intro
B) You DO NOT like the idea of subsectio= ns

C) If you like the following:=C2=A0 =C2=A0
<= div>
=C2=A0=C2=A0=C2=A0 c1) The need for mandatory-to-implement algorit= hms
=C2=A0=C2=A0=C2=A0 c2) The scope of the document (IKEv2 + implemente= r)
=C2=A0=C2=A0=C2=A0 c3) Updating algorithm status (deprecation of alg= orithms and=20 the IoT section)

D) If you have other propositions.
<= br>
I will update the draft this week according to the responses.=
=C2=A0
BR,
Daniel


= On Mon, Nov 30, 2015 at 12:20 PM, Tommy Pauly <tpauly@apple.com> wrote:
Hi Daniel,

Thanks f= or making these changes! I think this makes the document much clearer.

With regards to the Introduction, it may be beneficial= at this point to have subsections of the introduction to make it easier to= parse. Right now there seem to be several topics that don=E2=80=99t necess= arily flow into one another: explaining mandatory-to-implement algorithms, = explaining which version of IKE is relevant, explaining deprecation of algo= rithms, and the IoT section.

Thanks,
tom= my

On Nov 26, 2015, = at 2:58 PM, Daniel Migault <daniel.migault@ericsson.com> wrote:

Hi Paul and Tommy,

Please find = the new update of the draft:
1) text in the introduction has been added = to specify the IoT use case, and the motivations for having IoT considerati= ons in this document.
2) IoT has been i= ndicated in the tables with a comment specifying that the requirement is fo= r IoT interoperability. I was not able to have two lines in the postamble. = It seems <artwork> is not accepted as a children for <postamble>= ;
3) RFCs have been added in the refere= nce section to enable xml2rfc to run properly.

The update is available here:
https://github.com/mglt/drafts/commit/8c125fa2a82af21a44c5035c3311938d2= 6443652

Feel free to comment up= date the text.

BR,
Daniel

<= div class=3D"gmail_extra">
On Mon, Nov 23, 20= 15 at 11:20 AM, Paul Wouters <paul@nohats.ca> wrote:
On Fri, 20 Nov 2015, Tommy= Pauly wrote:

On a broader note, many of the SHOULD algorithms (ENCR_AES_CCM_8, PRF_AES12= 8_CBC,=C2=A0AUTH_AES-XCBC) are
justified as being present for the purposes of Internet of Things devices. = I tend to think that it would be
more straightforward to have a separate document that explains the preferre= d algorithms for IoT devices (an
IKEv2 profile for IoT, for example). However, if we do want to keep them in= this document, I think it would
help to have a section in the introduction to the document explaining the u= se case for the IoT devices and
why they are now included in the bis document, whereas they were not releva= nt yet in=C2=A0RFC 4307. It may also
be helpful to qualify the SHOULDs as pertaining more, perhaps, to servers; = traditional VPN clients would
generally not be interacting with IoT devices directly, and thus would have= little reason to implement
these algorithms.

 I would suggest if we want to do that, to just use a [*] notation where
the [*] gets explained as "For interoperability with IoT clients only&= quot;

I would not want to leave it out because that will cause us to get
servers that won't support IoT devices.
Paul


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



________________________= _______________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec




--001a11469bd881955b0525f1bde2-- From nobody Fri Dec 4 01:45:29 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B9B1A21C1 for ; Fri, 4 Dec 2015 01:45:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 LOBQcbpYeVyj for ; Fri, 4 Dec 2015 01:45:25 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E0B31A1F04 for ; Fri, 4 Dec 2015 01:45:24 -0800 (PST) X-AuditID: c1b4fb25-f79876d0000011ee-33-566160b23627 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 1F.C0.04590.2B061665; Fri, 4 Dec 2015 10:45:22 +0100 (CET) Received: from ESESSMB307.ericsson.se ([169.254.7.72]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0248.002; Fri, 4 Dec 2015 10:45:22 +0100 From: John Mattsson To: Daniel Migault , Tommy Pauly Thread-Topic: [IPsec] RFC 4307bis Thread-Index: AQHRFx9kTj6DrkVftkG95I6GEgtiE56Tq7aAgAAsQwCAAGVjgIAAAQuAgAEu8YCAAEmfgIAJGx0AgAAa9YCAA11vAIAC13aAgAAPYoCABKVlgIAFJiAAgAXrBQCAABE2AIADYf6AgAAGZwCAAmFTgA== Date: Fri, 4 Dec 2015 09:45:21 +0000 Message-ID: References: <0748F101-7104-4F07-B440-31A9CF63BE32@gmail.com> <9EBE3C6E-C7F2-4327-B4E2-3363BD96ECC1@gmail.com> <56421D6F.7080506@gmail.com> <22082.23345.969526.729086@fireball.acr.fi> <564A1549.1010001@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.8.151023 x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_D2871DDB41E3Cjohnmattssonericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPIsWRmVeSWpSXmKPExsUyM2J7uO6mhMQwg9VLlS32b3nBZvH+1iUm i4knDrI6MHtsPfmDzWPJkp9MHt/nMQUwR3HZpKTmZJalFunbJXBlLN9hUdCzibFizYydrA2M a9cydjFycEgImEisXJbbxcgJZIpJXLi3ng3EFhI4zCgxu90Swl7EKDHrQRmIzSZgIDF3TwNY jYhAkMSU/XuYQGxmATuJ3pV7wEYKCyhI9LeaQ5QoSkx72A1UwgVkLwMas62DBSTBIqAicW75 BGYQm1fAXKLrcg8LSJGQwCQOiZ1z1rCDDOIUCJQ4fxNsFyPQbd9PrYHaJS5x68l8JoibBSSW 7DnPDGGLSrx8/I8VxBYV0JM4+GklK0RcUeLjq32MEL0xEv++dkPtFZQ4OfMJywRGsVlIxs5C UjYLSdksoIuYBTQl1u/ShyhRlJjS/ZAdwtaQaJ0zF8q2lji9eSobspoFjByrGEWLU4uTctON jPVSizKTi4vz8/TyUks2MQKj9eCW36o7GC+/cTzEKMDBqMTDW3AyIUyINbGsuDL3EKMEB7OS CC+zTGKYEG9KYmVValF+fFFpTmrxIUZpDhYlcd5mpgehQgLpiSWp2ampBalFMFkmDk6pBsZW nmN70jXq7O4q+q1d4J9t/PPX+bnbC+p0PG477j2rUHLmlemliLlL8m8o/W2cVXw2MC/ftPZu 7nKp6df2H/Z7tvfr9fM1TYdXlQfZ3p+W9SWvJslXKP5DyvzAMzen7dG7oeTj/Pf6Grm5a4W/ 7LjzS5lB0aXjyzSN7FjzMvsfVqYbe37/K5quxFKckWioxVxUnAgAP3oF1dICAAA= Archived-At: Cc: IPsecME WG , Paul Wouters Subject: Re: [IPsec] RFC 4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 09:45:28 -0000 --_000_D2871DDB41E3Cjohnmattssonericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCi1BZ3JlZSB3aXRoIHlvdXIgY29tbWVudCBvbiDigJxtYW5kYXRvcnktdG8taW1wbGVt ZW504oCdLiBJIHRoaW5rIHRoZSBJbnRyb2R1Y3Rpb24gc2hvdWxkIGJlIGNoYW5nZWQsIGFuZCBJ IHN1Z2dlc3QgdXNpbmcgc29tZXRoaW5nIGxpa2UgdGhlIHRleHQgdXNlZCBpbiBSRkM3MzIxIOKA nEFsZ29yaXRobSBJbXBsZW1lbnRhdGlvbiBSZXF1aXJlbWVudHMgYW5kIFVzYWdlIEd1aWRhbmNl 4oCdLiBSRkM3MzIxIGFsc28gaGFzIGEgbW9yZSBleHBsYWluaW5nIHRpdGxlLg0KDQotIEkgdGhp bmsgMTAyNC1iaXQgTU9EUCBzaG91bGQgYmUg4oCcU0hPVUxEIE5PVC3igJ0gYXMgaXQgc2VlbXMg dG8gYmUgYWdyZWVtZW50IHRoYXQgaXMgc2hvdWxkIGJlIOKAnE1VU1QgTk9U4oCdIGluIHRoZSBu ZXh0IHVwZGF0ZS4gTWlnaHQgbWF5IHNlbnNlIHRvIGRlZmluZSDigJwr4oCdIGFuZCDigJwt4oCd IGluc3RlYWQgb2Yg4oCcU0hPVUxEKywgU0hPVUxELSwgTVVTVC3igJ0NCg0KLSBJIHRoaW5rIOKA nEN1cnZlMjU1MTnigJ0gc2hvdWxkIGJlIGluY2x1ZGVkIGFzIOKAnE1BWeKAnSBvciDigJxNQVkr 4oCdLCBldmVuIGlmIG5vYm9keSBoYXMgaW1wbGVtZW50ZWQgaXQgeWV0LCBpdCBzZWVtcyBsaWtl IHRoZSBvYnZpb3VzIGNob2ljZSBsb25nLXRlcm0uDQoNCkNoZWVycywNCkpvaG4NCg0KRnJvbTog SVBzZWMgPGlwc2VjLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmlwc2VjLWJvdW5jZXNAaWV0Zi5v cmc+PiBvbiBiZWhhbGYgb2YgRGFuaWVsIE1pZ2F1bHQgPGRhbmllbC5taWdhdWx0QGVyaWNzc29u LmNvbTxtYWlsdG86ZGFuaWVsLm1pZ2F1bHRAZXJpY3Nzb24uY29tPj4NCkRhdGU6IFdlZG5lc2Rh eSAyIERlY2VtYmVyIDIwMTUgMjM6MjQNClRvOiBUb21teSBQYXVseSA8dHBhdWx5QGFwcGxlLmNv bTxtYWlsdG86dHBhdWx5QGFwcGxlLmNvbT4+DQpDYzogSVBzZWNNRSBXRyA8aXBzZWNAaWV0Zi5v cmc8bWFpbHRvOmlwc2VjQGlldGYub3JnPj4sIFBhdWwgV291dGVycyA8cGF1bEBub2hhdHMuY2E8 bWFpbHRvOnBhdWxAbm9oYXRzLmNhPj4NClN1YmplY3Q6IFJlOiBbSVBzZWNdIFJGQyA0MzA3Ymlz DQoNCkhpLA0KDQpQbGVhc2UgZmluZCB0aGUgdXBkYXRlZCB2ZXJzaW9uIHdpdGggdGhlIG5ldyBz ZWN0aW9uIHRpdGxlcyBzdWdnZXN0ZWQgYnkgWWFyb246DQoxLjEgVXBkYXRpbmcgTWFuZGF0b3J5 IHRvIEltcGxlbWVudCBBbGdvcml0aG1zDQoxLjIgVXBkYXRpbmcgQWxnb3JpdGhtIFJlcXVpcmVt ZW50IExldmVscw0KMS4zIERvY3VtZW50IEF1ZGllbmNlDQoNCkJSLA0KRGFuaWVsDQpodHRwczov L2dpdGh1Yi5jb20vbWdsdC9kcmFmdHMvY29tbWl0L2ZmYjZlOWFkODJiYzk1MmYzYTg5MWRlMjMy Y2QxMGJlMzUzODc4YTkNCg0KT24gV2VkLCBEZWMgMiwgMjAxNSBhdCA0OjAxIFBNLCBEYW5pZWwg TWlnYXVsdCA8ZGFuaWVsLm1pZ2F1bHRAZXJpY3Nzb24uY29tPG1haWx0bzpkYW5pZWwubWlnYXVs dEBlcmljc3Nvbi5jb20+PiB3cm90ZToNCkhpLA0KDQpQbGVhc2Ugc2UgdGhlIGN1cnJlbnQgdmVy c2lvbiBvZiB0aGUgZG9jdW1lbnQgd2l0aCB0aGUgc3Vic2VjdGlvbiBpbiB0aGUgSW50cm9kdWN0 aW9uLg0KDQpodHRwczovL2dpdGh1Yi5jb20vbWdsdC9kcmFmdHMvY29tbWl0L2VmNzJlYTQ4MmFm NzRkNDIyNmQzMDU5MjM3MDI0ZjYzZDBhZGQwMWINCg0KVGhlIHN1YnNlY3Rpb25zIGFyZToNCiAg IDEuMSBVcGRhdGluZyBNYW5kYXRvcnkgdG8gSW1wbGVtZW50IEFsZ29yeXRobXMNCiAgIDEuMiBB bGdvcml0aG0gU3RhdHVzIFVwZGF0ZSBQb2xpY3kNCiAgIDEuMyBBdWRpZW5jZSBvZiB0aGUgRG9j dW1lbnQNCg0KRmVlbCBmcmVlIHRvIHByb3ZpZGUgYW55IGNvbW1lbnQuIEkgYmVsZWl2ZSB3ZSBo YXZlIGFkZHJlc3NlZCBhbGwgY29tbWVudHMgd2UgcmVjZWl2ZWQuDQoNCkkgYW0gZmluZGluZyB0 aGUgdGVybWlub2xvZ3kgbWFuZGF0b3J5LXRvLWltcGxlbWVudCBtYXliZSBhIGJpdCBtaXNsZWFk aW5nIGZvciBzdGF0dXMgbGlrZSBNQVkgb3IgYSBNVVNUIE5PVC4gQW55IHN1Z2dlc3Rpb24gdG8g Y2xhcmlmeSB0aGF0Pw0KDQpCUiwNCkRhbmllbA0KDQpPbiBNb24sIE5vdiAzMCwgMjAxNSBhdCAx MjoyMiBQTSwgRGFuaWVsIE1pZ2F1bHQgPGRhbmllbC5taWdhdWx0QGVyaWNzc29uLmNvbTxtYWls dG86ZGFuaWVsLm1pZ2F1bHRAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSBUb21teSwNCg0KVGhh bmtzIGZvciB0aGUgcHJvcG9zaXRpb24gVG9tbXksIEkgdGhuaWsgdGhhdCB3aWxsIGNsZWFyZXIg dG8gaGF2ZSBkZWRpY2F0ZWQgc3Vic2VjdGlvbnMgaW4gdGhlIGludHJvLiBIZXJlIGFyZSB0aGUg c3Vic2VjdGlvbiBJIHdvdWxkIHByb3Bvc2UuIEkgYW0gd2FpdGluZyBmb3IgdGhlIFdHIGZlZWQg YmFjayBiZWZvcmUgdXBkYXRpbmcgdGhlIGRyYWZ0LCBzbyBwbGVhc2UgbGV0IG0gZWtub3cgd2hl dGhlcjoNCg0KQSkgWW91IGxpa2UgdGhlIGlkZWEgb2Ygc3Vic2VjdGlvbiBpbiB0aGUgaW50cm8N CkIpIFlvdSBETyBOT1QgbGlrZSB0aGUgaWRlYSBvZiBzdWJzZWN0aW9ucw0KDQpDKSBJZiB5b3Ug bGlrZSB0aGUgZm9sbG93aW5nOg0KICAgIGMxKSBUaGUgbmVlZCBmb3IgbWFuZGF0b3J5LXRvLWlt cGxlbWVudCBhbGdvcml0aG1zDQogICAgYzIpIFRoZSBzY29wZSBvZiB0aGUgZG9jdW1lbnQgKElL RXYyICsgaW1wbGVtZW50ZXIpDQogICAgYzMpIFVwZGF0aW5nIGFsZ29yaXRobSBzdGF0dXMgKGRl cHJlY2F0aW9uIG9mIGFsZ29yaXRobXMgYW5kIHRoZSBJb1Qgc2VjdGlvbikNCg0KRCkgSWYgeW91 IGhhdmUgb3RoZXIgcHJvcG9zaXRpb25zLg0KDQpJIHdpbGwgdXBkYXRlIHRoZSBkcmFmdCB0aGlz IHdlZWsgYWNjb3JkaW5nIHRvIHRoZSByZXNwb25zZXMuDQoNCkJSLA0KRGFuaWVsDQoNCg0KT24g TW9uLCBOb3YgMzAsIDIwMTUgYXQgMTI6MjAgUE0sIFRvbW15IFBhdWx5IDx0cGF1bHlAYXBwbGUu Y29tPG1haWx0bzp0cGF1bHlAYXBwbGUuY29tPj4gd3JvdGU6DQpIaSBEYW5pZWwsDQoNClRoYW5r cyBmb3IgbWFraW5nIHRoZXNlIGNoYW5nZXMhIEkgdGhpbmsgdGhpcyBtYWtlcyB0aGUgZG9jdW1l bnQgbXVjaCBjbGVhcmVyLg0KDQpXaXRoIHJlZ2FyZHMgdG8gdGhlIEludHJvZHVjdGlvbiwgaXQg bWF5IGJlIGJlbmVmaWNpYWwgYXQgdGhpcyBwb2ludCB0byBoYXZlIHN1YnNlY3Rpb25zIG9mIHRo ZSBpbnRyb2R1Y3Rpb24gdG8gbWFrZSBpdCBlYXNpZXIgdG8gcGFyc2UuIFJpZ2h0IG5vdyB0aGVy ZSBzZWVtIHRvIGJlIHNldmVyYWwgdG9waWNzIHRoYXQgZG9u4oCZdCBuZWNlc3NhcmlseSBmbG93 IGludG8gb25lIGFub3RoZXI6IGV4cGxhaW5pbmcgbWFuZGF0b3J5LXRvLWltcGxlbWVudCBhbGdv cml0aG1zLCBleHBsYWluaW5nIHdoaWNoIHZlcnNpb24gb2YgSUtFIGlzIHJlbGV2YW50LCBleHBs YWluaW5nIGRlcHJlY2F0aW9uIG9mIGFsZ29yaXRobXMsIGFuZCB0aGUgSW9UIHNlY3Rpb24uDQoN ClRoYW5rcywNCnRvbW15DQoNCk9uIE5vdiAyNiwgMjAxNSwgYXQgMjo1OCBQTSwgRGFuaWVsIE1p Z2F1bHQgPGRhbmllbC5taWdhdWx0QGVyaWNzc29uLmNvbTxtYWlsdG86ZGFuaWVsLm1pZ2F1bHRA ZXJpY3Nzb24uY29tPj4gd3JvdGU6DQoNCkhpIFBhdWwgYW5kIFRvbW15LA0KDQpQbGVhc2UgZmlu ZCB0aGUgbmV3IHVwZGF0ZSBvZiB0aGUgZHJhZnQ6DQoxKSB0ZXh0IGluIHRoZSBpbnRyb2R1Y3Rp b24gaGFzIGJlZW4gYWRkZWQgdG8gc3BlY2lmeSB0aGUgSW9UIHVzZSBjYXNlLCBhbmQgdGhlIG1v dGl2YXRpb25zIGZvciBoYXZpbmcgSW9UIGNvbnNpZGVyYXRpb25zIGluIHRoaXMgZG9jdW1lbnQu DQoyKSBJb1QgaGFzIGJlZW4gaW5kaWNhdGVkIGluIHRoZSB0YWJsZXMgd2l0aCBhIGNvbW1lbnQg c3BlY2lmeWluZyB0aGF0IHRoZSByZXF1aXJlbWVudCBpcyBmb3IgSW9UIGludGVyb3BlcmFiaWxp dHkuIEkgd2FzIG5vdCBhYmxlIHRvIGhhdmUgdHdvIGxpbmVzIGluIHRoZSBwb3N0YW1ibGUuIEl0 IHNlZW1zIDxhcnR3b3JrPiBpcyBub3QgYWNjZXB0ZWQgYXMgYSBjaGlsZHJlbiBmb3IgPHBvc3Rh bWJsZT4NCjMpIFJGQ3MgaGF2ZSBiZWVuIGFkZGVkIGluIHRoZSByZWZlcmVuY2Ugc2VjdGlvbiB0 byBlbmFibGUgeG1sMnJmYyB0byBydW4gcHJvcGVybHkuDQoNClRoZSB1cGRhdGUgaXMgYXZhaWxh YmxlIGhlcmU6DQpodHRwczovL2dpdGh1Yi5jb20vbWdsdC9kcmFmdHMvY29tbWl0LzhjMTI1ZmEy YTgyYWYyMWE0NGM1MDM1YzMzMTE5MzhkMjY0NDM2NTINCg0KRmVlbCBmcmVlIHRvIGNvbW1lbnQg dXBkYXRlIHRoZSB0ZXh0Lg0KDQpCUiwNCkRhbmllbA0KDQoNCk9uIE1vbiwgTm92IDIzLCAyMDE1 IGF0IDExOjIwIEFNLCBQYXVsIFdvdXRlcnMgPHBhdWxAbm9oYXRzLmNhPG1haWx0bzpwYXVsQG5v aGF0cy5jYT4+IHdyb3RlOg0KT24gRnJpLCAyMCBOb3YgMjAxNSwgVG9tbXkgUGF1bHkgd3JvdGU6 DQoNCk9uIGEgYnJvYWRlciBub3RlLCBtYW55IG9mIHRoZSBTSE9VTEQgYWxnb3JpdGhtcyAoRU5D Ul9BRVNfQ0NNXzgsIFBSRl9BRVMxMjhfQ0JDLCBBVVRIX0FFUy1YQ0JDKSBhcmUNCmp1c3RpZmll ZCBhcyBiZWluZyBwcmVzZW50IGZvciB0aGUgcHVycG9zZXMgb2YgSW50ZXJuZXQgb2YgVGhpbmdz IGRldmljZXMuIEkgdGVuZCB0byB0aGluayB0aGF0IGl0IHdvdWxkIGJlDQptb3JlIHN0cmFpZ2h0 Zm9yd2FyZCB0byBoYXZlIGEgc2VwYXJhdGUgZG9jdW1lbnQgdGhhdCBleHBsYWlucyB0aGUgcHJl ZmVycmVkIGFsZ29yaXRobXMgZm9yIElvVCBkZXZpY2VzIChhbg0KSUtFdjIgcHJvZmlsZSBmb3Ig SW9ULCBmb3IgZXhhbXBsZSkuIEhvd2V2ZXIsIGlmIHdlIGRvIHdhbnQgdG8ga2VlcCB0aGVtIGlu IHRoaXMgZG9jdW1lbnQsIEkgdGhpbmsgaXQgd291bGQNCmhlbHAgdG8gaGF2ZSBhIHNlY3Rpb24g aW4gdGhlIGludHJvZHVjdGlvbiB0byB0aGUgZG9jdW1lbnQgZXhwbGFpbmluZyB0aGUgdXNlIGNh c2UgZm9yIHRoZSBJb1QgZGV2aWNlcyBhbmQNCndoeSB0aGV5IGFyZSBub3cgaW5jbHVkZWQgaW4g dGhlIGJpcyBkb2N1bWVudCwgd2hlcmVhcyB0aGV5IHdlcmUgbm90IHJlbGV2YW50IHlldCBpbiBS RkMgNDMwNy4gSXQgbWF5IGFsc28NCmJlIGhlbHBmdWwgdG8gcXVhbGlmeSB0aGUgU0hPVUxEcyBh cyBwZXJ0YWluaW5nIG1vcmUsIHBlcmhhcHMsIHRvIHNlcnZlcnM7IHRyYWRpdGlvbmFsIFZQTiBj bGllbnRzIHdvdWxkDQpnZW5lcmFsbHkgbm90IGJlIGludGVyYWN0aW5nIHdpdGggSW9UIGRldmlj ZXMgZGlyZWN0bHksIGFuZCB0aHVzIHdvdWxkIGhhdmUgbGl0dGxlIHJlYXNvbiB0byBpbXBsZW1l bnQNCnRoZXNlIGFsZ29yaXRobXMuDQoNCkkgd291bGQgc3VnZ2VzdCBpZiB3ZSB3YW50IHRvIGRv IHRoYXQsIHRvIGp1c3QgdXNlIGEgWypdIG5vdGF0aW9uIHdoZXJlDQp0aGUgWypdIGdldHMgZXhw bGFpbmVkIGFzICJGb3IgaW50ZXJvcGVyYWJpbGl0eSB3aXRoIElvVCBjbGllbnRzIG9ubHkiDQoN Ckkgd291bGQgbm90IHdhbnQgdG8gbGVhdmUgaXQgb3V0IGJlY2F1c2UgdGhhdCB3aWxsIGNhdXNl IHVzIHRvIGdldA0Kc2VydmVycyB0aGF0IHdvbid0IHN1cHBvcnQgSW9UIGRldmljZXMuDQoNClBh dWwNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K SVBzZWMgbWFpbGluZyBsaXN0DQpJUHNlY0BpZXRmLm9yZzxtYWlsdG86SVBzZWNAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwc2VjDQoNCg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSVBzZWMgbWFpbGlu ZyBsaXN0DQpJUHNlY0BpZXRmLm9yZzxtYWlsdG86SVBzZWNAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwc2VjDQoNCg0KDQoNCg== --_000_D2871DDB41E3Cjohnmattssonericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj5IaSw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pi1BZ3JlZSB3aXRo IHlvdXIgY29tbWVudCBvbiDigJxtYW5kYXRvcnktdG8taW1wbGVtZW504oCdLiBJIHRoaW5rIHRo ZSBJbnRyb2R1Y3Rpb24gc2hvdWxkIGJlIGNoYW5nZWQsIGFuZCBJIHN1Z2dlc3QgdXNpbmcgc29t ZXRoaW5nIGxpa2UgdGhlIHRleHQgdXNlZCBpbiBSRkM3MzIxIOKAnEFsZ29yaXRobSBJbXBsZW1l bnRhdGlvbiBSZXF1aXJlbWVudHMgYW5kIFVzYWdlIEd1aWRhbmNl4oCdLiBSRkM3MzIxIGFsc28g aGFzIGEgbW9yZSBleHBsYWluaW5nDQogdGl0bGUuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj4tIEkgdGhpbmsgMTAyNC1iaXQgTU9EUCBzaG91bGQgYmUg4oCcU0hPVUxEIE5PVC3igJ0g YXMgaXQgc2VlbXMgdG8gYmUgYWdyZWVtZW50IHRoYXQgaXMgc2hvdWxkIGJlIOKAnE1VU1QgTk9U 4oCdIGluIHRoZSBuZXh0IHVwZGF0ZS4gTWlnaHQgbWF5IHNlbnNlIHRvIGRlZmluZSDigJwmIzQz O+KAnSBhbmQg4oCcLeKAnSBpbnN0ZWFkIG9mIOKAnFNIT1VMRCYjNDM7LCBTSE9VTEQtLCBNVVNU LeKAnTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+LSBJIHRoaW5rIOKAnEN1cnZlMjU1 MTnigJ0gc2hvdWxkIGJlIGluY2x1ZGVkIGFzIOKAnE1BWeKAnSBvciDigJxNQVkmIzQzO+KAnSwg ZXZlbiBpZiBub2JvZHkgaGFzIGltcGxlbWVudGVkIGl0IHlldCwgaXQgc2VlbXMgbGlrZSB0aGUg b2J2aW91cyBjaG9pY2UgbG9uZy10ZXJtLjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj5DaGVlcnMsPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj5Kb2huPC9kaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFsaWduOmxl ZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6 IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFE RElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJ R0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13 ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPklQc2VjICZsdDs8YSBocmVmPSJtYWlsdG86aXBzZWMt Ym91bmNlc0BpZXRmLm9yZyI+aXBzZWMtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFs ZiBvZiBEYW5pZWwgTWlnYXVsdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRhbmllbC5taWdhdWx0QGVy aWNzc29uLmNvbSI+ZGFuaWVsLm1pZ2F1bHRAZXJpY3Nzb24uY29tPC9hPiZndDs8YnI+DQo8c3Bh biBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPldlZG5lc2RheSAyIERlY2Vt YmVyIDIwMTUgMjM6MjQ8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwv c3Bhbj5Ub21teSBQYXVseSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRwYXVseUBhcHBsZS5jb20iPnRw YXVseUBhcHBsZS5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5DYzogPC9zcGFuPklQc2VjTUUgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzppcHNlY0BpZXRmLm9y ZyI+aXBzZWNAaWV0Zi5vcmc8L2E+Jmd0OywgUGF1bCBXb3V0ZXJzICZsdDs8YSBocmVmPSJtYWls dG86cGF1bEBub2hhdHMuY2EiPnBhdWxAbm9oYXRzLmNhPC9hPiZndDs8YnI+DQo8c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJlOiBbSVBzZWNdIFJGQyA0MzA3 YmlzPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRp cj0ibHRyIj5IaSwgPGJyPg0KPGJyPg0KUGxlYXNlIGZpbmQgdGhlIHVwZGF0ZWQgdmVyc2lvbiB3 aXRoIHRoZSBuZXcgc2VjdGlvbiB0aXRsZXMgc3VnZ2VzdGVkIGJ5IFlhcm9uOiA8YnI+DQoxLjEg VXBkYXRpbmcgTWFuZGF0b3J5IHRvIEltcGxlbWVudCBBbGdvcml0aG1zPGJyPg0KMS4yIFVwZGF0 aW5nIEFsZ29yaXRobSBSZXF1aXJlbWVudCBMZXZlbHM8YnI+DQoxLjMgRG9jdW1lbnQgQXVkaWVu Y2U8YnI+DQo8YnI+DQpCUiwgPGJyPg0KRGFuaWVsPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9naXRo dWIuY29tL21nbHQvZHJhZnRzL2NvbW1pdC9mZmI2ZTlhZDgyYmM5NTJmM2E4OTFkZTIzMmNkMTBi ZTM1Mzg3OGE5Ij5odHRwczovL2dpdGh1Yi5jb20vbWdsdC9kcmFmdHMvY29tbWl0L2ZmYjZlOWFk ODJiYzk1MmYzYTg5MWRlMjMyY2QxMGJlMzUzODc4YTk8L2E+PGJyPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSJnbWFpbF9leHRyYSI+PGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFdlZCwg RGVjIDIsIDIwMTUgYXQgNDowMSBQTSwgRGFuaWVsIE1pZ2F1bHQgPHNwYW4gZGlyPSJsdHIiPg0K Jmx0OzxhIGhyZWY9Im1haWx0bzpkYW5pZWwubWlnYXVsdEBlcmljc3Nvbi5jb20iIHRhcmdldD0i X2JsYW5rIj5kYW5pZWwubWlnYXVsdEBlcmljc3Nvbi5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6 PGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAw IC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2 IGRpcj0ibHRyIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj5IaSwgPGJyPg0KPGJyPg0KPC9kaXY+DQpQ bGVhc2Ugc2UgdGhlIGN1cnJlbnQgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQgd2l0aCB0aGUgc3Vi c2VjdGlvbiBpbiB0aGUgSW50cm9kdWN0aW9uLjxicj4NCjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v Z2l0aHViLmNvbS9tZ2x0L2RyYWZ0cy9jb21taXQvZWY3MmVhNDgyYWY3NGQ0MjI2ZDMwNTkyMzcw MjRmNjNkMGFkZDAxYiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZ2l0aHViLmNvbS9tZ2x0L2Ry YWZ0cy9jb21taXQvZWY3MmVhNDgyYWY3NGQ0MjI2ZDMwNTkyMzcwMjRmNjNkMGFkZDAxYjwvYT48 YnI+DQo8YnI+DQpUaGUgc3Vic2VjdGlvbnMgYXJlOjxicj4NCiZuYnNwOyZuYnNwOyAxLjEgVXBk YXRpbmcgTWFuZGF0b3J5IHRvIEltcGxlbWVudCBBbGdvcnl0aG1zPGJyPg0KJm5ic3A7Jm5ic3A7 IDEuMiBBbGdvcml0aG0gU3RhdHVzIFVwZGF0ZSBQb2xpY3k8YnI+DQombmJzcDsmbmJzcDsgMS4z IEF1ZGllbmNlIG9mIHRoZSBEb2N1bWVudDxicj4NCjxicj4NCjwvZGl2Pg0KRmVlbCBmcmVlIHRv IHByb3ZpZGUgYW55IGNvbW1lbnQuIEkgYmVsZWl2ZSB3ZSBoYXZlIGFkZHJlc3NlZCBhbGwgY29t bWVudHMgd2UgcmVjZWl2ZWQuPGJyPg0KPGJyPg0KPC9kaXY+DQpJIGFtIGZpbmRpbmcgdGhlIHRl cm1pbm9sb2d5IG1hbmRhdG9yeS10by1pbXBsZW1lbnQgbWF5YmUgYSBiaXQgbWlzbGVhZGluZyBm b3Igc3RhdHVzIGxpa2UgTUFZIG9yIGEgTVVTVCBOT1QuIEFueSBzdWdnZXN0aW9uIHRvIGNsYXJp ZnkgdGhhdD8gJm5ic3A7DQo8YnI+DQo8ZGl2Pjxicj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJnbWFp bF9leHRyYSI+QlIsIDxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPkRhbmll bDxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9Img1Ij4NCjxkaXYgY2xhc3M9ImdtYWls X2V4dHJhIj48YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gTW9uLCBOb3YgMzAsIDIw MTUgYXQgMTI6MjIgUE0sIERhbmllbCBNaWdhdWx0IDxzcGFuIGRpcj0ibHRyIj4NCiZsdDs8YSBo cmVmPSJtYWlsdG86ZGFuaWVsLm1pZ2F1bHRAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+ ZGFuaWVsLm1pZ2F1bHRAZXJpY3Nzb24uY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjxi bG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAw LjhleDtib3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6 MWV4Ij4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2PkhpIFRvbW15LCA8YnI+ DQo8YnI+DQo8L2Rpdj4NClRoYW5rcyBmb3IgdGhlIHByb3Bvc2l0aW9uIFRvbW15LCBJIHRobmlr IHRoYXQgd2lsbCBjbGVhcmVyIHRvIGhhdmUgZGVkaWNhdGVkIHN1YnNlY3Rpb25zIGluIHRoZSBp bnRyby4gSGVyZSBhcmUgdGhlIHN1YnNlY3Rpb24gSSB3b3VsZCBwcm9wb3NlLiBJIGFtIHdhaXRp bmcgZm9yIHRoZSBXRyBmZWVkIGJhY2sgYmVmb3JlIHVwZGF0aW5nIHRoZSBkcmFmdCwgc28gcGxl YXNlIGxldCBtIGVrbm93IHdoZXRoZXI6PGJyPg0KPGJyPg0KQSkgWW91IGxpa2UgdGhlIGlkZWEg b2Ygc3Vic2VjdGlvbiBpbiB0aGUgaW50cm88YnI+DQo8L2Rpdj4NCkIpIFlvdSBETyBOT1QgbGlr ZSB0aGUgaWRlYSBvZiBzdWJzZWN0aW9uczxicj4NCjxicj4NCjwvZGl2Pg0KPGRpdj5DKSBJZiB5 b3UgbGlrZSB0aGUgZm9sbG93aW5nOiZuYnNwOyAmbmJzcDsgPGJyPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgYzEpIFRoZSBuZWVkIGZvciBtYW5kYXRvcnktdG8taW1w bGVtZW50IGFsZ29yaXRobXM8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgYzIpIFRoZSBzY29wZSBv ZiB0aGUgZG9jdW1lbnQgKElLRXYyICYjNDM7IGltcGxlbWVudGVyKSA8YnI+DQombmJzcDsmbmJz cDsmbmJzcDsgYzMpIFVwZGF0aW5nIGFsZ29yaXRobSBzdGF0dXMgKGRlcHJlY2F0aW9uIG9mIGFs Z29yaXRobXMgYW5kIHRoZSBJb1Qgc2VjdGlvbikNCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkQp IElmIHlvdSBoYXZlIG90aGVyIHByb3Bvc2l0aW9ucy48YnI+DQo8YnI+DQo8L2Rpdj4NCjxkaXY+ SSB3aWxsIHVwZGF0ZSB0aGUgZHJhZnQgdGhpcyB3ZWVrIGFjY29yZGluZyB0byB0aGUgcmVzcG9u c2VzLjxicj4NCiZuYnNwOzxicj4NCjwvZGl2Pg0KPGRpdj5CUiwgPGJyPg0KPC9kaXY+DQo8ZGl2 PkRhbmllbDxicj4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPg0KPGRpdiBjbGFzcz0iZ21haWxf cXVvdGUiPk9uIE1vbiwgTm92IDMwLCAyMDE1IGF0IDEyOjIwIFBNLCBUb21teSBQYXVseSA8c3Bh biBkaXI9Imx0ciI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOnRwYXVseUBhcHBsZS5jb20iIHRhcmdl dD0iX2JsYW5rIj50cGF1bHlAYXBwbGUuY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjxi bG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAw LjhleDtib3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6 MWV4Ij4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXY+SGkgRGFuaWVs LDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhbmtzIGZvciBtYWtpbmcgdGhlc2Ug Y2hhbmdlcyEgSSB0aGluayB0aGlzIG1ha2VzIHRoZSBkb2N1bWVudCBtdWNoIGNsZWFyZXIuPC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5XaXRoIHJlZ2FyZHMgdG8gdGhlIEludHJvZHVj dGlvbiwgaXQgbWF5IGJlIGJlbmVmaWNpYWwgYXQgdGhpcyBwb2ludCB0byBoYXZlIHN1YnNlY3Rp b25zIG9mIHRoZSBpbnRyb2R1Y3Rpb24gdG8gbWFrZSBpdCBlYXNpZXIgdG8gcGFyc2UuIFJpZ2h0 IG5vdyB0aGVyZSBzZWVtIHRvIGJlIHNldmVyYWwgdG9waWNzIHRoYXQgZG9u4oCZdCBuZWNlc3Nh cmlseSBmbG93IGludG8gb25lIGFub3RoZXI6IGV4cGxhaW5pbmcgbWFuZGF0b3J5LXRvLWltcGxl bWVudA0KIGFsZ29yaXRobXMsIGV4cGxhaW5pbmcgd2hpY2ggdmVyc2lvbiBvZiBJS0UgaXMgcmVs ZXZhbnQsIGV4cGxhaW5pbmcgZGVwcmVjYXRpb24gb2YgYWxnb3JpdGhtcywgYW5kIHRoZSBJb1Qg c2VjdGlvbi48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoYW5rcyw8L2Rpdj4NCjxk aXY+dG9tbXk8L2Rpdj4NCjxkaXY+DQo8ZGl2Pjxicj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIj4NCjxkaXY+T24gTm92IDI2LCAyMDE1LCBhdCAyOjU4IFBNLCBEYW5pZWwgTWlnYXVs dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRhbmllbC5taWdhdWx0QGVyaWNzc29uLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmRhbmllbC5taWdhdWx0QGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2 Pg0KPGJyPg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdj5IaSBQYXVsIGFuZCBUb21teSwg PGJyPg0KPGJyPg0KPC9kaXY+DQo8ZGl2PlBsZWFzZSBmaW5kIHRoZSBuZXcgdXBkYXRlIG9mIHRo ZSBkcmFmdDo8YnI+DQoxKSB0ZXh0IGluIHRoZSBpbnRyb2R1Y3Rpb24gaGFzIGJlZW4gYWRkZWQg dG8gc3BlY2lmeSB0aGUgSW9UIHVzZSBjYXNlLCBhbmQgdGhlIG1vdGl2YXRpb25zIGZvciBoYXZp bmcgSW9UIGNvbnNpZGVyYXRpb25zIGluIHRoaXMgZG9jdW1lbnQuPGJyPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSJnbWFpbF9leHRyYSI+MikgSW9UIGhhcyBiZWVuIGluZGljYXRlZCBpbiB0aGUgdGFi bGVzIHdpdGggYSBjb21tZW50IHNwZWNpZnlpbmcgdGhhdCB0aGUgcmVxdWlyZW1lbnQgaXMgZm9y IElvVCBpbnRlcm9wZXJhYmlsaXR5LiBJIHdhcyBub3QgYWJsZSB0byBoYXZlIHR3byBsaW5lcyBp biB0aGUgcG9zdGFtYmxlLiBJdCBzZWVtcyAmbHQ7YXJ0d29yayZndDsgaXMgbm90IGFjY2VwdGVk IGFzIGEgY2hpbGRyZW4gZm9yICZsdDtwb3N0YW1ibGUmZ3Q7PGJyPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSJnbWFpbF9leHRyYSI+MykgUkZDcyBoYXZlIGJlZW4gYWRkZWQgaW4gdGhlIHJlZmVyZW5j ZSBzZWN0aW9uIHRvIGVuYWJsZSB4bWwycmZjIHRvIHJ1biBwcm9wZXJseS48YnI+DQo8YnI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj5UaGUgdXBkYXRlIGlzIGF2YWlsYWJsZSBo ZXJlOjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9tZ2x0L2RyYWZ0cy9jb21taXQv OGMxMjVmYTJhODJhZjIxYTQ0YzUwMzVjMzMxMTkzOGQyNjQ0MzY1MiIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vZ2l0aHViLmNvbS9tZ2x0L2RyYWZ0cy9jb21taXQvOGMxMjVmYTJhODJhZjIxYTQ0 YzUwMzVjMzMxMTkzOGQyNjQ0MzY1MjwvYT48YnI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 ImdtYWlsX2V4dHJhIj5GZWVsIGZyZWUgdG8gY29tbWVudCB1cGRhdGUgdGhlIHRleHQuPGJyPg0K PGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+QlIsIDxicj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPkRhbmllbDxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Z21haWxfZXh0cmEiPjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj4N CjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBNb24sIE5vdiAyMywgMjAxNSBhdCAxMToyMCBB TSwgUGF1bCBXb3V0ZXJzIDxzcGFuIGRpcj0ibHRyIj4NCiZsdDs8YSBocmVmPSJtYWlsdG86cGF1 bEBub2hhdHMuY2EiIHRhcmdldD0iX2JsYW5rIj5wYXVsQG5vaGF0cy5jYTwvYT4mZ3Q7PC9zcGFu PiB3cm90ZTo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJn aW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIw NCk7cGFkZGluZy1sZWZ0OjFleCI+DQo8c3Bhbj5PbiBGcmksIDIwIE5vdiAyMDE1LCBUb21teSBQ YXVseSB3cm90ZTo8YnI+DQo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0 eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigy MDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+DQpPbiBhIGJyb2FkZXIgbm90ZSwgbWFueSBv ZiB0aGUgU0hPVUxEIGFsZ29yaXRobXMgKEVOQ1JfQUVTX0NDTV84LCBQUkZfQUVTMTI4X0NCQywm bmJzcDtBVVRIX0FFUy1YQ0JDKSBhcmU8YnI+DQpqdXN0aWZpZWQgYXMgYmVpbmcgcHJlc2VudCBm b3IgdGhlIHB1cnBvc2VzIG9mIEludGVybmV0IG9mIFRoaW5ncyBkZXZpY2VzLiBJIHRlbmQgdG8g dGhpbmsgdGhhdCBpdCB3b3VsZCBiZTxicj4NCm1vcmUgc3RyYWlnaHRmb3J3YXJkIHRvIGhhdmUg YSBzZXBhcmF0ZSBkb2N1bWVudCB0aGF0IGV4cGxhaW5zIHRoZSBwcmVmZXJyZWQgYWxnb3JpdGht cyBmb3IgSW9UIGRldmljZXMgKGFuPGJyPg0KSUtFdjIgcHJvZmlsZSBmb3IgSW9ULCBmb3IgZXhh bXBsZSkuIEhvd2V2ZXIsIGlmIHdlIGRvIHdhbnQgdG8ga2VlcCB0aGVtIGluIHRoaXMgZG9jdW1l bnQsIEkgdGhpbmsgaXQgd291bGQ8YnI+DQpoZWxwIHRvIGhhdmUgYSBzZWN0aW9uIGluIHRoZSBp bnRyb2R1Y3Rpb24gdG8gdGhlIGRvY3VtZW50IGV4cGxhaW5pbmcgdGhlIHVzZSBjYXNlIGZvciB0 aGUgSW9UIGRldmljZXMgYW5kPGJyPg0Kd2h5IHRoZXkgYXJlIG5vdyBpbmNsdWRlZCBpbiB0aGUg YmlzIGRvY3VtZW50LCB3aGVyZWFzIHRoZXkgd2VyZSBub3QgcmVsZXZhbnQgeWV0IGluJm5ic3A7 UkZDIDQzMDcuIEl0IG1heSBhbHNvPGJyPg0KYmUgaGVscGZ1bCB0byBxdWFsaWZ5IHRoZSBTSE9V TERzIGFzIHBlcnRhaW5pbmcgbW9yZSwgcGVyaGFwcywgdG8gc2VydmVyczsgdHJhZGl0aW9uYWwg VlBOIGNsaWVudHMgd291bGQ8YnI+DQpnZW5lcmFsbHkgbm90IGJlIGludGVyYWN0aW5nIHdpdGgg SW9UIGRldmljZXMgZGlyZWN0bHksIGFuZCB0aHVzIHdvdWxkIGhhdmUgbGl0dGxlIHJlYXNvbiB0 byBpbXBsZW1lbnQ8YnI+DQp0aGVzZSBhbGdvcml0aG1zLjxicj4NCjwvYmxvY2txdW90ZT4NCjxi cj4NCjwvc3Bhbj5JIHdvdWxkIHN1Z2dlc3QgaWYgd2Ugd2FudCB0byBkbyB0aGF0LCB0byBqdXN0 IHVzZSBhIFsqXSBub3RhdGlvbiB3aGVyZTxicj4NCnRoZSBbKl0gZ2V0cyBleHBsYWluZWQgYXMg JnF1b3Q7Rm9yIGludGVyb3BlcmFiaWxpdHkgd2l0aCBJb1QgY2xpZW50cyBvbmx5JnF1b3Q7PGJy Pg0KPGJyPg0KSSB3b3VsZCBub3Qgd2FudCB0byBsZWF2ZSBpdCBvdXQgYmVjYXVzZSB0aGF0IHdp bGwgY2F1c2UgdXMgdG8gZ2V0PGJyPg0Kc2VydmVycyB0aGF0IHdvbid0IHN1cHBvcnQgSW9UIGRl dmljZXMuPHNwYW4+PGZvbnQgY29sb3I9IiM4ODg4ODgiPjxicj4NCjxicj4NClBhdWw8L2ZvbnQ+ PC9zcGFuPg0KPGRpdj4NCjxkaXY+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJUHNlYyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo cmVmPSJtYWlsdG86SVBzZWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5JUHNlY0BpZXRmLm9y ZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2lwc2VjIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwc2VjPC9hPjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJUHNlYyBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SVBzZWNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5JUHNlY0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2lwc2VjIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwc2VjPC9hPjxicj4NCjxi cj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D2871DDB41E3Cjohnmattssonericssoncom_-- From nobody Mon Dec 7 22:40:19 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E211B33CE for ; Mon, 7 Dec 2015 22:40:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 2OGZYqV3YLbs for ; Mon, 7 Dec 2015 22:40:14 -0800 (PST) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37E601B2F71 for ; Mon, 7 Dec 2015 22:40:13 -0800 (PST) X-AuditID: c618062d-f79d16d000001b1c-8e-56667aea2724 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 13.94.06940.AEA76665; Tue, 8 Dec 2015 07:38:35 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0248.002; Tue, 8 Dec 2015 01:40:12 -0500 From: Samy Touati To: "yaron.ietf@gmail.com" , "ipsec@ietf.org" , "tpauly@apple.com" , "ynir.ietf@gmail.com" Thread-Topic: [IPsec] New revision of TCP Encapsulation draft Thread-Index: AQHRMYNJNzc9CwwTqE+dh5CWSKsB8w== Date: Tue, 8 Dec 2015 06:40:11 +0000 Message-ID: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151105 x-originating-ip: [147.117.188.12] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3532372811_1709585849" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGIsWRmVeSWpSXmKPExsUyuXRPuO7rqrQwg85/HBb7t7xgs5h44iCr xf/PkhZLj31gcmDx2HryB5vHzll32T2WLPnJFMAcxWWTkpqTWZZapG+XwJXx4/psloITsRWn vq9lbmB8GtTFyMkhIWAicejdVjYIW0ziwr31QDYXh5DAEUaJrW9WMEI4yxgl3s5ZxghSxSag I3F58wwWkISIwBpGiaMvVrCDJIQFbCTmrTrAAmKLCNhKnH62ggnC1pO4NvMVM4jNIqAisfPm E7B1vAL2Eu/2TwXrZRSQldh99jpYPbOAuMStJ/OZIE4SkXh48TTUeaISLx//Y+1i5OAQFdCV +PY3ACKsJDHn9TVmiNZKibXtH5kgxgtKnJz5hGUCo/AsJFNnISmbhaQMIu4psbfxNyOErS2x 59ZWZhj7ybsLrBC2lsSVG4fZMcWtJWb8OsgGYStKTOl+CFVjKvH66EfGBYzcqxg5SosLcnLT jQw2MQJj9JgEm+4OxvvTPQ8xCnAwKvHwGlxPDRNiTSwrrsw9xKgC1Ppow+oLjFIsefl5qUoi vK26aWFCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeRkZGBiEBNITS1KzU1MLUotgskwcnFINjK2W s+Nf/TXXlturtPta+UHbnGNZV4oX9FZOOHSEc9He1WXLFsj2WWYoNQnGOKZHv6jOrlhT67iQ e8u0gv2yuonbFR/vfsup4PXEIbNAT9js3YSKok2u6dcntdcm2UjYHLktErRvssuLZ8x60yeX R7Dah4m7zjZrmMdz38rDQH9u/c0L934aK7EUZyQaajEXFScCAKV58bLZAgAA Archived-At: Subject: Re: [IPsec] New revision of TCP Encapsulation draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 06:40:17 -0000 --B_3532372811_1709585849 Content-type: multipart/alternative; boundary="B_3532372811_1049211940" --B_3532372811_1049211940 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Yaron and Yoav, An updated draft addressing your comments has been posted. https://www.ietf.org/internet-drafts/draft-pauly-ipsecme-tcp-encaps-02.txt Please check it out, and provide feedback. Thanks. Samy. From: Yaron Sheffer Sent: Nov 20, 2015 3:11 PM To: Tommy Pauly; IPsecME WG Subject: Re: [IPsec] New revision of TCP Encapsulation draft Hi Tommy, I also think this is very relevant work. Here are some comments to -01: I think that Yoav's draft, draft-nir-ipsecme-ike-tcp-01, should be cited=20 under "prior work", both because it is documented and also because I=20 believe it is implemented by a vendor. In Sec. 1, under the UDP encapsulation, I suggest to add "Often peers=20 will use UDP encapsulation even when there is no NAT on the path, for=20 example because networks or middleboxes do not support IP protocols=20 other than TCP and UDP." "Although a stream" - this paragraph is not worded very well (streams=20 don't send anything) and is hard to understand. There are lots of=20 networks that use jumbo frames and so hardcoding the value 1500 into the=20 spec may not be a good idea. I can think of HA cases where several gateways are handling ESP SAs that=20 are all associated with the same IKE SA. So I'm wondering why we are=20 insisting on all Child SAs being in the same connection, and as a result=20 requiring that an IKE message be the preamble to any new connection. Although it might seem obvious, I think Sec. 3 should say explicitly=20 that if the connection is closed midway through a message, the recipient=20 must silently drop the partial message. You may want to add to the last paragraph of the Security=20 Considerations: This document explicitly does not define a profile for=20 TLS when used in this manner, or any relation between identities at the=20 IPsec level and those at the TLS level ("channel binding"). Thanks, Yaron On 11/20/2015 11:49 PM, Tommy Pauly wrote: > Hello, > > Based on the feedback received at our informal meeting in Yokohama, I=E2=80=99v= e updated the draft for TCP Encapsulation of IKEv2 and ESP: > > https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-01 > > The revisions include: > - More explanation in the introduction about the motivation, and other wo= rk that this draft is trying to standardize (3GPP recommendations, proprieta= ry IKEv1 IPSec over TCP versions, and SSL VPNs). > - Comments about maximum IKE and ESP message size within the TCP stream, = which is effective the MTU of the tunnel. > - Specify that if the TCP connection is brought down and re-established, = the first message on the stream must be an IKE message. > - Detailed considerations about interactions with middleboxes (thanks Gra= ham Bartlett for input on this). > > In the meeting in Yokohama, there was general agreement that this was rel= evant work that we=E2=80=99d like to keep looking into. Please read the document, = and provide any feedback you have! > > Thanks, > Tommy > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --B_3532372811_1049211940 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Hi Yaron and Yoav,<= /div>

An updated draft addressing your comments has been = posted.


Please check it out, and provide feedback.<= /div>


Thanks.
Samy.

From: Yaron Sheffer <yaronf.ietf@gmail.com>
Sent: Nov 20, 2015 3:11 P= M
To: Tommy Pauly; IPsecME WG
Subject: Re: [IP= sec] New revision of TCP Encapsulation draft

Hi Tommy,

I also = think this is very relevant work. Here are some comments to -01:

I th= ink that Yoav's draft, draft-nir-ipsecme-ike-tcp-01, should be cited under "prior work", both because it is documented and also because I =
believe it is implemented by a vendor.

In Sec. 1, under the UDP e= ncapsulation, I suggest to add "Often peers 
will use UDP encapsulat= ion even when there is no NAT on the path, for 
example because netw= orks or middleboxes do not support IP protocols 
other than TCP and = UDP."

"Although a stream" - this paragraph is not worded very well (s= treams 
don't send anything) and is hard to understand. There are lo= ts of 
networks that use jumbo frames and so hardcoding the value 15= 00 into the 
spec may not be a good idea.

I can think of HA c= ases where several gateways are handling ESP SAs that 
are all assoc= iated with the same IKE SA. So I'm wondering why we are 
insisting o= n all Child SAs being in the same connection, and as a result 
requi= ring that an IKE message be the preamble to any new connection.

Altho= ugh it might seem obvious, I think Sec. 3 should say explicitly 
tha= t if the connection is closed midway through a message, the recipient <= br>must silently drop the partial message.

You may want to add to the= last paragraph of the Security 
Considerations: This document expli= citly does not define a profile for 
TLS when used in this manner, o= r any relation between identities at the 
IPsec level and those at t= he TLS level ("channel binding").

Thanks,
    =     Yaron

On 11/20/2015 11:49 PM, Tommy Pauly wrote:> Hello,
>
> Based on the feedback received at our informal= meeting in Yokohama, I’ve updated the draft for TCP Encapsulation of = IKEv2 and ESP:
>
> https://tools.ietf.org/html/draft-pauly-ipse= cme-tcp-encaps-01
>
> The revisions include:
> - More = explanation in the introduction about the motivation, and other work that th= is draft is trying to standardize (3GPP recommendations, proprietary IKEv1 I= PSec over TCP versions, and SSL VPNs).
> - Comments about maximum IKE = and ESP message size within the TCP stream, which is effective the MTU of th= e tunnel.
> - Specify that if the TCP connection is brought down and r= e-established, the first message on the stream must be an IKE message.
&g= t; - Detailed considerations about interactions with middleboxes (thanks Gra= ham Bartlett for input on this).
>
> In the meeting in Yokohama,= there was general agreement that this was relevant work that we’d lik= e to keep looking into. Please read the document, and provide any feedback y= ou have!
>
> Thanks,
> Tommy
> _____________________= __________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec=
>

_______________________________________________
IPsec= mailing list
IPsec@ietf.org
https://www.ietf.org/mailma= n/listinfo/ipsec

--B_3532372811_1049211940-- --B_3532372811_1709585849 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIH+gYJKoZIhvcNAQcCoIIH6zCCB+cCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Be0wggXpMIID0aADAgECAhEAzxzmCopx75U64hFk/UYzGzANBgkqhkiG9w0BAQUFADA6MREw DwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2 MjAeFw0xNDExMTAxODMyMTRaFw0xNzExMTAxODMyMTNaMGQxETAPBgNVBAoMCEVyaWNzc29u MRQwEgYDVQQDDAtTYW15IFRvdWF0aTEnMCUGCSqGSIb3DQEJARYYc2FteS50b3VhdGlAZXJp Y3Nzb24uY29tMRAwDgYDVQQFEwdsbWNzYXRvMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAtTzHN2e42IspS2LTetBYT1X297J5UERFKNlGu1pG2pcGU/NBSwsizw/RDI/q+c42 EkEAWzJ4usb2oO4//CLw5Foboonf8N2qhwRx5O7gEEIjjSCt2Q7O4mToKM4xoNSTmRrF2war 3mnRc3g0A9T69MD2ipYU3/l7HVnAH4z+95t8FrL/oeFXuc/XgWfBGBSYY6uiyLujAZckgwWV FPN4ZMdGAZJ1AgU8tTLWafREHu3stvWcVniIQoOvJVNLHfYcnW8r/Lh0zaTSDCxusleG+YY3 aKtXGF6CyaxuI8i3GmXWI+LEjNeJUesb/WKnZAubl51efuDJvQ+MDA7dNJaDdQIDAQABo4IB vjCCAbowSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJp Y3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzAB hhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2Eu dHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jZXIwIwYD VR0RBBwwGoEYc2FteS50b3VhdGlAZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGC DwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNv bmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU rvTqPsDyVm3LeP+8KcedI3WxmhIwHwYDVR0jBBgwFoAUsQ3K1Ea3r4YCwy9vBsoOdnF/Szcw DgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBBQUAA4ICAQBCT4SQnpZQ7Ur2tRXshjkw2pJJ dHA70enikN4bx2cLmhaRlPfS4/SVEXYMLiTRb58jD0N7/wobI7UAWSRlj5zHn21La1HIE0Mt dsJutSPckZWbguCAl9TgEIGdGIVXKhsanr107KLIyrSu+DwgxOLE5kx6JqgcVV2e3ZockG6s hOGXy1O83yP3muINapuuIdY6qtvPTUJ5zZqNPTCHIDrQLwNx07HVflUkS0G/Ac6W6qdfDnu8 qAE0YAxe1dajdphQK/c3pskR5X7M39t7TlZfnFIxOWco3N7odbZo/8fmjxxvfqtcHa1qBrLr qHz9Itfrn+r5KEMqQG/2WUotU6XuBSuNiDQvLt0VH324IOmlLJpTOG5pWbwIKm0Vz65NcP38 S6Qg3k1XmSYa3Nd/eBDM2S7xsx9gxlxqcGtB0HX7lRFCqNtPd1U7YqPag+fKFgs2rbkrNm9T U0jN95UnrJn0lM4zJgL2Xel2keiuySOQzI9r7NOyaEZXwtnhV3BgcIPZit3D4W6awzI/3HaZ Ub2Cr7HbrHBQAGknGpZZd00a/waLeolL5CvALtUt0KpNz1Jqk5dKGfWLJNNxy2iNFrTThVkU YDEIyyqHLSzxj+W0vq8imtNDvul+8WK/1hCw+XJb9mVb3gpXONrneo5d5oj6SolE/O46eq6+ 2jcfWcwATTGCAdUwggHRAgEBME8wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVy aWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDPHOYKinHvlTriEWT9RjMbMAkGBSsOAwIa BQCgXTAjBgkqhkiG9w0BCQQxFgQUhi4OpTTIzzIbEWZIFwQ1GnNcKKYwGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUxMjA4MDY0MDExWjANBgkqhkiG9w0B AQEFAASCAQApgFQbu1ZHzoAkcXPUgbS/P/aAXCKHAd0GwdK8R8e0HU41Ci2gzLCUyZk9iLTJ 6qwzfyoXhksyEp+oeVhuK3lu/ZwDj6X1OqFprqB5IeIHiaHw5b4d/ryWyOTVqpIXVbZax9p5 CNc6PgmOJHDiNmFrntDjz/JTfhUfq2x0FYcjQgAAy0JcKBwvTzGkhNG0Eq/1oVcWhg+gdZcw rU+glq5BM9cokNRo6wpKG4MsMIuu9njnSaEXaXAfIGEck3k+/RuyGzkZdDivaF5bv287e1bw n8sQWgwkeZHf+wqD1tupJh9rsPpclH8hshTzknmIidlleWOf2LTkhPB3MtLmV6Ja --B_3532372811_1709585849-- From nobody Tue Dec 8 02:12:55 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D535C1ACC83 for ; Tue, 8 Dec 2015 02:12:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 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, MANGLED_TOOL=2.3, SPF_PASS=-0.001] autolearn=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 O419igWwkGhS for ; Tue, 8 Dec 2015 02:12:51 -0800 (PST) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (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 A06A61ACAD5 for ; Tue, 8 Dec 2015 02:12:51 -0800 (PST) Received: by pfnn128 with SMTP id n128so10071260pfn.0 for ; Tue, 08 Dec 2015 02:12:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=xraEdlsS4s2Et8XbobeQxheUZGKqY3CEno2ruNblLsU=; b=KGonlzeVG9dVbvrLRasAd4LRv25q5OP6aOsXD2x3xiLy1BbRDAYvxFefEt/jiuF4Xq CulDp6eMb56hiipQFu0IsZGro3FK9cbujSBZnnjzzQhrZtcLa2UF1ZV6eloj3i0Rj0uY 5gjlHC3a8EA1jKJSWQL7ZKhh8im6ZAyc2yRotC9uSifT2KFy5/tmNyuLwsmjSzHSSZrD zUGhtob87zk+oxlIg7lwaenqKitKAR7GbByspDOQbxb/VmCvERQf9E05ZARh/CqTmyFh maU+VKueFd99gNFacFTSZqT0/CQX885TJx8sckiJxJxzrC6qszjeviLOnPXhIhamgCel KmNg== X-Received: by 10.98.74.129 with SMTP id c1mr3676194pfj.124.1449569571252; Tue, 08 Dec 2015 02:12:51 -0800 (PST) Received: from [172.18.133.40] (cowboy.intuit.com. [65.204.229.11]) by smtp.gmail.com with ESMTPSA id c14sm3650946pfd.38.2015.12.08.02.12.46 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Dec 2015 02:12:49 -0800 (PST) To: Samy Touati , "yaron.ietf@gmail.com" , "ipsec@ietf.org" , "tpauly@apple.com" , "ynir.ietf@gmail.com" References: From: Yaron Sheffer Message-ID: <5666AD1B.6000105@gmail.com> Date: Tue, 8 Dec 2015 12:12:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------060009020302070304050300" Archived-At: Subject: Re: [IPsec] New revision of TCP Encapsulation draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 10:12:54 -0000 This is a multi-part message in MIME format. --------------060009020302070304050300 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Samy, Thanks for the new draft. It addresses most of my comments, but one question remains. I still don't understand why we require that each connection should start with an IKE message. The explanation given is "to allow the peer to know with which IKE session the traffic is associated." But of course the ESP SPI identifies the Child SA, and implicitly, the IKE SA. Moreover, later in the same section you allow multiple IKE SAs over the same connection, which again doesn't work well with the reasoning above. Best, Yaron On 12/08/2015 08:40 AM, Samy Touati wrote: > Hi Yaron and Yoav, > > An updated draft addressing your comments has been posted. > > https://www.ietf.org/internet-drafts/draft-pauly-ipsecme-tcp-encaps-02.txt > > Please check it out, and provide feedback. > > > Thanks. > Samy. > > > *From:* Yaron Sheffer > > *Sent:* Nov 20, 2015 3:11 PM > *To:* Tommy Pauly; IPsecME WG > *Subject:* Re: [IPsec] New revision of TCP Encapsulation draft > > Hi Tommy, > > I also think this is very relevant work. Here are some comments to -01: > > I think that Yoav's draft, draft-nir-ipsecme-ike-tcp-01, should be cited > under "prior work", both because it is documented and also because I > believe it is implemented by a vendor. > > In Sec. 1, under the UDP encapsulation, I suggest to add "Often peers > will use UDP encapsulation even when there is no NAT on the path, for > example because networks or middleboxes do not support IP protocols > other than TCP and UDP." > > "Although a stream" - this paragraph is not worded very well (streams > don't send anything) and is hard to understand. There are lots of > networks that use jumbo frames and so hardcoding the value 1500 into the > spec may not be a good idea. > > I can think of HA cases where several gateways are handling ESP SAs that > are all associated with the same IKE SA. So I'm wondering why we are > insisting on all Child SAs being in the same connection, and as a result > requiring that an IKE message be the preamble to any new connection. > > Although it might seem obvious, I think Sec. 3 should say explicitly > that if the connection is closed midway through a message, the recipient > must silently drop the partial message. > > You may want to add to the last paragraph of the Security > Considerations: This document explicitly does not define a profile for > TLS when used in this manner, or any relation between identities at the > IPsec level and those at the TLS level ("channel binding"). > > Thanks, > Yaron > > On 11/20/2015 11:49 PM, Tommy Pauly wrote: > > Hello, > > > > Based on the feedback received at our informal meeting in Yokohama, > I’ve updated the draft for TCP Encapsulation of IKEv2 and ESP: > > > > https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-01 > > > > The revisions include: > > - More explanation in the introduction about the motivation, and > other work that this draft is trying to standardize (3GPP > recommendations, proprietary IKEv1 IPSec over TCP versions, and SSL VPNs). > > - Comments about maximum IKE and ESP message size within the TCP > stream, which is effective the MTU of the tunnel. > > - Specify that if the TCP connection is brought down and > re-established, the first message on the stream must be an IKE message. > > - Detailed considerations about interactions with middleboxes > (thanks Graham Bartlett for input on this). > > > > In the meeting in Yokohama, there was general agreement that this > was relevant work that we’d like to keep looking into. Please read the > document, and provide any feedback you have! > > > > Thanks, > > Tommy > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --------------060009020302070304050300 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Samy,

Thanks for the new draft. It addresses most of my comments, but one question remains.

I still don't understand why we require that each connection should start with an IKE message. The explanation given is "to allow the peer to know with which IKE session the traffic is associated." But of course the ESP SPI identifies the Child SA, and implicitly, the IKE SA.

Moreover, later in the same section you allow multiple IKE SAs over the same connection, which again doesn't work well with the reasoning above.

Best,
    Yaron

On 12/08/2015 08:40 AM, Samy Touati wrote:
Hi Yaron and Yoav,

An updated draft addressing your comments has been posted.


Please check it out, and provide feedback.


Thanks.
Samy.


From: Yaron Sheffer <yaronf.ietf@gmail.com>
Sent: Nov 20, 2015 3:11 PM
To: Tommy Pauly; IPsecME WG
Subject: Re: [IPsec] New revision of TCP Encapsulation draft

Hi Tommy,

I also think this is very relevant work. Here are some comments to -01:

I think that Yoav's draft, draft-nir-ipsecme-ike-tcp-01, should be cited 
under "prior work", both because it is documented and also because I 
believe it is implemented by a vendor.

In Sec. 1, under the UDP encapsulation, I suggest to add "Often peers 
will use UDP encapsulation even when there is no NAT on the path, for 
example because networks or middleboxes do not support IP protocols 
other than TCP and UDP."

"Although a stream" - this paragraph is not worded very well (streams 
don't send anything) and is hard to understand. There are lots of 
networks that use jumbo frames and so hardcoding the value 1500 into the 
spec may not be a good idea.

I can think of HA cases where several gateways are handling ESP SAs that 
are all associated with the same IKE SA. So I'm wondering why we are 
insisting on all Child SAs being in the same connection, and as a result 
requiring that an IKE message be the preamble to any new connection.

Although it might seem obvious, I think Sec. 3 should say explicitly 
that if the connection is closed midway through a message, the recipient 
must silently drop the partial message.

You may want to add to the last paragraph of the Security 
Considerations: This document explicitly does not define a profile for 
TLS when used in this manner, or any relation between identities at the 
IPsec level and those at the TLS level ("channel binding").

Thanks,
        Yaron

On 11/20/2015 11:49 PM, Tommy Pauly wrote:
> Hello,
>
> Based on the feedback received at our informal meeting in Yokohama, I’ve updated the draft for TCP Encapsulation of IKEv2 and ESP:
>
> https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-01
>
> The revisions include:
> - More explanation in the introduction about the motivation, and other work that this draft is trying to standardize (3GPP recommendations, proprietary IKEv1 IPSec over TCP versions, and SSL VPNs).
> - Comments about maximum IKE and ESP message size within the TCP stream, which is effective the MTU of the tunnel.
> - Specify that if the TCP connection is brought down and re-established, the first message on the stream must be an IKE message.
> - Detailed considerations about interactions with middleboxes (thanks Graham Bartlett for input on this).
>
> In the meeting in Yokohama, there was general agreement that this was relevant work that we’d like to keep looking into. Please read the document, and provide any feedback you have!
>
> Thanks,
> Tommy
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>

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



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

--------------060009020302070304050300-- From nobody Tue Dec 8 12:24:10 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAC951A6F4C for ; Tue, 8 Dec 2015 12:24:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Vi3GFaOMfSgC for ; Tue, 8 Dec 2015 12:24:06 -0800 (PST) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B9CF1A6F29 for ; Tue, 8 Dec 2015 12:23:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1449606238; x=2313519838; 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=DVYftnbP1q75nDGvCHn5rTeK6pDYUyAprjVciKF5oW4=; b=PLlfDHfrI/UF1leIPCxvwkL9jtgAdQ5HQAU6I2eOzvQckXsoBl3YbjsuIXJZUtos 7gqWVW8Faj9Yfl4rgJJBuxAaBKiMNVsngUpgy+MNyO+ETlz+BVBqcdKL8S6MClKq cf+IH0KwEd7olWwzwgbO/4ItgY2v4mXdT08an+/xYUMjJ2cBoUBE0tbkwljHjCNk CZaPIKkIy15H/MM2I18HO8DqYSZ56hvWnczUdAzkhwua0mQFAEfNfhxW3Zn0tNsu 9nF0xIPGFim4a+wLFZGRMz7cFRGJNlcDCdsTbXpvvA7QzTxoPYxQUS6+jLI1O0p6 fvG5fOOkXYxXKZSOWOhXJg==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 0C.5B.27232.E5C37665; Tue, 8 Dec 2015 12:23:58 -0800 (PST) X-AuditID: 11973e15-f79366d000006a60-3c-56673c5e2efa Received: from cilantro.apple.com (cilantro.apple.com [17.128.115.18]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id B4.77.05180.D5C37665; Tue, 8 Dec 2015 12:23:58 -0800 (PST) Received: from da0602a-dhcp203.apple.com (da0602a-dhcp203.apple.com [17.226.23.203]) by cilantro.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0NZ200JCN3BX6V30@cilantro.apple.com> for ipsec@ietf.org; Tue, 08 Dec 2015 12:23:57 -0800 (PST) Sender: tpauly@apple.com Content-type: multipart/alternative; boundary="Apple-Mail=_E7F12F0A-CCC1-4FA0-BAE1-D07C0CC08989" MIME-version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Tommy Pauly In-reply-to: <5666AD1B.6000105@gmail.com> Date: Tue, 08 Dec 2015 12:24:21 -0800 Message-id: <18BF5929-6C8C-41A5-A3BC-764D3F56B2F3@apple.com> References: <5666AD1B.6000105@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.3112) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUi2FAYrBtnkx5m8OAQu8X+LS/YHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMaH9NGvB/emMFW1Tb7E1MO4r6GLk5JAQMJF4uewHI4QtJnHh 3no2EFtIYC+jRHdXFUzN+9ULWLoYuYDic5gkLly7xA7hbGCSeDLrDVMXIweHsICExOY9iSAN zAJJEmuXLwEbxCugJ/Hvwk12EFtYwEZi3qoDLCA2m4CKxPFvG5hBbE4BTYkVLy6xgtgsAqoS X/8/YQKZzyywllGiZfcjqEE2EvtvLGKEuC5O4kHfBBaQvSJAzdOOWkEcKiuxb8MCNpBeCYE9 bBKbzyxmmsAoPAvJTbOQ3AQR15ZYtvA1M4StKbG/ezkLpriGROe3iawLGNlWMQrlJmbm6Gbm meklFhTkpOol5+duYgRFxHQ70R2MZ1ZZHWIU4GBU4uE9cSw1TIg1say4MvcQozQHi5I4b7ZH WpiQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxnyHCN7f22fV5cnFHzqukVWkfd+kVWM5z581 lj7rPz/d1FASqj5L0MFDPC6kaVHKR73vlwxf/Jy1bnoT/+3bVk6PjVx5Gz817F9U8TDatmTa McdlDrvb1Qp2yTkw1Bcvvp8a5r5PYrN7reT/hP5gi4feFxr8bs/WWBu+K+ekU5Ekv4727luf lFiKMxINtZiLihMB2CQPGWkCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrIIsWRmVeSWpSXmKPExsUi2FAspBtnkx5mMPMis8X+LS/YHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMaH9NGvB/emMFW1Tb7E1MO4r6GLk5JAQMJF4v3oBC4QtJnHh 3nq2LkYuDiGBOUwSF65dYodwNjBJPJn1hqmLkYNDWEBCYvOeRJAGZoEkibXLl7CB2LwCehL/ LtxkB7GFBWwk5q06ADaUTUBF4vi3DcwgNqeApsSKF5dYQWwWAVWJr/+fMIHMZxZYyyjRsvsR 1CAbif03FjGC2EICcRIP+iawgOwVAWqedtQK4lBZiX0bFrBNYBSYheSMWUjOgIhrSyxb+JoZ wtaU2N+9nAVTXEOi89tE1gWMbKsYBYpScxIrjfUSCwpyUvWS83M3MYJDuDB4B+OfZVaHGAU4 GJV4eBVOpoYJsSaWFVfmHmKU4GBWEuEt1kgPE+JNSaysSi3Kjy8qzUktPsQ4kRHoy4nMUqLJ +cAIyyuJNzQxMTAxNjYzNjY3MaelsJI47xsroIsE0hNLUrNTUwtSi2COYuLglGpgZDiSkqxn 9m+DxqG/v+dzK/yt7N7+bYHhsXl2qxWavrsahP5mEDJj5vt67oLguhUP1vOZ8rl4+rsXiBZd df7+TipyBd/1SonOnBn2+btC72cu3O9w3mQiR8qzx7eXfFrDai/vHPTgz7ZP/zm2Olhdaj/Q cnOpiHd601ehFw78Yh0a4Rz8Lke/KLEUZyQaajEXFScCABrb4zzUAgAA Archived-At: Cc: "ipsec@ietf.org" , Samy Touati , "yaron.ietf@gmail.com" , "ynir.ietf@gmail.com" Subject: Re: [IPsec] New revision of TCP Encapsulation draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 20:24:09 -0000 --Apple-Mail=_E7F12F0A-CCC1-4FA0-BAE1-D07C0CC08989 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Yaron, The original version of the draft did not require that the new TCP = connection begin with an IKE message, but it was added in response to = feedback we received at our meeting in Yokohama. The concern was that the new TCP connection would almost certainly have = different ports from the old connection. In order for the server to send = packets back to the client, it needs to know the correct mapping for = both the IKE SAs and the Child SAs. If we allow an ESP packet to be the = first packet of a new connection, it may be hard to implement a correct = server that reacts to that and adjusts all associated IKE and Child SA = values to use the new port. However, it the first packet is an IKE = packet, the server can essentially treat it as if it were MOBIKE and = reset the ports. In the case of multiple IKE SAs over a TCP connection (which is a new = edge case that has been brought up), perhaps it would make sense to say = that for all IKE SAs using the connection, at least one IKE message must = precede any ESP messages for a Child SA of the IKE SA. Does this make sense? Thanks, Tommy > On Dec 8, 2015, at 2:12 AM, Yaron Sheffer = wrote: >=20 > Hi Samy, >=20 > Thanks for the new draft. It addresses most of my comments, but one = question remains. >=20 > I still don't understand why we require that each connection should = start with an IKE message. The explanation given is "to allow the peer = to know with which IKE session the traffic is associated." But of course = the ESP SPI identifies the Child SA, and implicitly, the IKE SA. >=20 > Moreover, later in the same section you allow multiple IKE SAs over = the same connection, which again doesn't work well with the reasoning = above. >=20 > Best, > Yaron >=20 > On 12/08/2015 08:40 AM, Samy Touati wrote: >> Hi Yaron and Yoav, >>=20 >> An updated draft addressing your comments has been posted. >>=20 >> = https://www.ietf.org/internet-drafts/draft-pauly-ipsecme-tcp-encaps-02.txt= = >>=20 >> Please check it out, and provide feedback. >>=20 >>=20 >> Thanks. >> Samy. >>=20 >>=20 >> From: Yaron Sheffer < = yaronf.ietf@gmail.com = > >> Sent: Nov 20, 2015 3:11 PM >> To: Tommy Pauly; IPsecME WG >> Subject: Re: [IPsec] New revision of TCP Encapsulation draft >>=20 >> Hi Tommy, >>=20 >> I also think this is very relevant work. Here are some comments to = -01: >>=20 >> I think that Yoav's draft, draft-nir-ipsecme-ike-tcp-01, should be = cited=20 >> under "prior work", both because it is documented and also because I=20= >> believe it is implemented by a vendor. >>=20 >> In Sec. 1, under the UDP encapsulation, I suggest to add "Often peers=20= >> will use UDP encapsulation even when there is no NAT on the path, for=20= >> example because networks or middleboxes do not support IP protocols=20= >> other than TCP and UDP." >>=20 >> "Although a stream" - this paragraph is not worded very well (streams=20= >> don't send anything) and is hard to understand. There are lots of=20 >> networks that use jumbo frames and so hardcoding the value 1500 into = the=20 >> spec may not be a good idea. >>=20 >> I can think of HA cases where several gateways are handling ESP SAs = that=20 >> are all associated with the same IKE SA. So I'm wondering why we are=20= >> insisting on all Child SAs being in the same connection, and as a = result=20 >> requiring that an IKE message be the preamble to any new connection. >>=20 >> Although it might seem obvious, I think Sec. 3 should say explicitly=20= >> that if the connection is closed midway through a message, the = recipient=20 >> must silently drop the partial message. >>=20 >> You may want to add to the last paragraph of the Security=20 >> Considerations: This document explicitly does not define a profile = for=20 >> TLS when used in this manner, or any relation between identities at = the=20 >> IPsec level and those at the TLS level ("channel binding"). >>=20 >> Thanks, >> Yaron >>=20 >> On 11/20/2015 11:49 PM, Tommy Pauly wrote: >> > Hello, >> > >> > Based on the feedback received at our informal meeting in Yokohama, = I=E2=80=99ve updated the draft for TCP Encapsulation of IKEv2 and ESP: >> > >> > https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-01 = >> > >> > The revisions include: >> > - More explanation in the introduction about the motivation, and = other work that this draft is trying to standardize (3GPP = recommendations, proprietary IKEv1 IPSec over TCP versions, and SSL = VPNs). >> > - Comments about maximum IKE and ESP message size within the TCP = stream, which is effective the MTU of the tunnel. >> > - Specify that if the TCP connection is brought down and = re-established, the first message on the stream must be an IKE message. >> > - Detailed considerations about interactions with middleboxes = (thanks Graham Bartlett for input on this). >> > >> > In the meeting in Yokohama, there was general agreement that this = was relevant work that we=E2=80=99d like to keep looking into. Please = read the document, and provide any feedback you have! >> > >> > Thanks, >> > Tommy >> > _______________________________________________ >> > IPsec mailing list >> > IPsec@ietf.org >> > https://www.ietf.org/mailman/listinfo/ipsec = >> > >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec = >>=20 >>=20 >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec = >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail=_E7F12F0A-CCC1-4FA0-BAE1-D07C0CC08989 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Yaron,

The original version of the draft did = not require that the new TCP connection begin with an IKE message, but = it was added in response to feedback we received at our meeting in = Yokohama.

The = concern was that the new TCP connection would almost certainly have = different ports from the old connection. In order for the server to send = packets back to the client, it needs to know the correct mapping for = both the IKE SAs and the Child SAs. If we allow an ESP packet to be the = first packet of a new connection, it may be hard to implement a correct = server that reacts to that and adjusts all associated IKE and Child SA = values to use the new port. However, it the first packet is an IKE = packet, the server can essentially treat it as if it were MOBIKE and = reset the ports.

In the case of multiple IKE SAs over a TCP connection (which = is a new edge case that has been brought up), perhaps it would make = sense to say that for all IKE SAs using the connection, at least one IKE = message must precede any ESP messages for a Child SA of the IKE = SA.

Does this = make sense?

Thanks,
Tommy

On = Dec 8, 2015, at 2:12 AM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

=20 =20
Hi Samy,

Thanks for the new draft. It addresses most of my comments, but one question remains.

I still don't understand why we require that each connection should start with an IKE message. The explanation given is "to allow the peer to know with which IKE session the traffic is associated." But of course the ESP SPI identifies the Child SA, and implicitly, the IKE SA.

Moreover, later in the same section you allow multiple IKE SAs over the same connection, which again doesn't work well with the reasoning above.

Best,
    Yaron

On 12/08/2015 08:40 AM, Samy Touati wrote:
Hi Yaron and Yoav,

An updated draft addressing your comments has = been posted.

https://www.ietf.org/internet-drafts/draft-pauly-ipsecme-tcp-en= caps-02.txt

Please check it out, and provide = feedback.


Thanks.
Samy.


From: Yaron Sheffer <yaronf.ietf@gmail.com>
Sent: Nov 20, 2015 3:11 PM
To: Tommy Pauly; IPsecME = WG
Subject: Re: [IPsec] New = revision of TCP Encapsulation draft

Hi Tommy,

I also think this is very relevant work. Here are some comments to -01:

I think that Yoav's draft, draft-nir-ipsecme-ike-tcp-01, should be cited 
under "prior work", both because it is documented and also because I 
believe it is implemented by a vendor.

In Sec. 1, under the UDP encapsulation, I suggest to add "Often peers 
will use UDP encapsulation even when there is no NAT on the path, for 
example because networks or middleboxes do not support IP protocols 
other than TCP and UDP."

"Although a stream" - this paragraph is not worded very well (streams 
don't send anything) and is hard to understand. There are lots of 
networks that use jumbo frames and so hardcoding the value 1500 into the 
spec may not be a good idea.

I can think of HA cases where several gateways are handling ESP SAs that 
are all associated with the same IKE SA. So I'm wondering why we are 
insisting on all Child SAs being in the same connection, and as a result 
requiring that an IKE message be the preamble to any new connection.

Although it might seem obvious, I think Sec. 3 should say explicitly 
that if the connection is closed midway through a message, the recipient 
must silently drop the partial message.

You may want to add to the last paragraph of the Security 
Considerations: This document explicitly does not define a profile for 
TLS when used in this manner, or any relation between identities at the 
IPsec level and those at the TLS level ("channel binding").

Thanks,
        Yaron

On 11/20/2015 11:49 PM, Tommy Pauly wrote:
> Hello,
>
> Based on the feedback received at our informal meeting in Yokohama, I=E2=80=99ve updated the draft = for TCP Encapsulation of IKEv2 and ESP:
>
> https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-01
>
> The revisions include:
> - More explanation in the introduction about the motivation, and other work that this draft is trying to standardize (3GPP recommendations, proprietary IKEv1 IPSec over TCP versions, and SSL VPNs).
> - Comments about maximum IKE and ESP message size within the TCP stream, which is effective the MTU of the tunnel.
> - Specify that if the TCP connection is brought down and re-established, the first message on the stream must be an IKE message.
> - Detailed considerations about interactions with middleboxes (thanks Graham Bartlett for input on this).
>
> In the meeting in Yokohama, there was general agreement that this was relevant work that we=E2=80=99d = like to keep looking into. Please read the document, and provide any feedback you have!
>
> Thanks,
> Tommy
> = _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>

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



_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/=
mailman/listinfo/ipsec

_______________________________________________
IPsec = mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

= --Apple-Mail=_E7F12F0A-CCC1-4FA0-BAE1-D07C0CC08989-- From nobody Tue Dec 8 13:08:35 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D70C1A8757 for ; Tue, 8 Dec 2015 13:08:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 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, MANGLED_TOOL=2.3, SPF_PASS=-0.001] autolearn=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 a-umH52rKJJg for ; Tue, 8 Dec 2015 13:08:31 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 34B211A8756 for ; Tue, 8 Dec 2015 13:08:31 -0800 (PST) Received: by wmuu63 with SMTP id u63so196983724wmu.0 for ; Tue, 08 Dec 2015 13:08:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=7uxJnphm7KSAJ/YoNHacya5Q+3K+OEG2YVaiNt/E6dk=; b=Fi8lNxM09BSSJvNhLZjDVb9h/Apld/s/LFaNzMvFV1ftb2QBEe5Yadeg1rsIlhdIJm yl4UgODfR9yqN5pH7FXz4nNpULcgOZVoW/KidGNBSDQ5BaKPE+lrPwlHjo11vWitM4PX SK7OisCQISX4BCP++NHAY3XRr4h2wLpbvLa7S+wtahIz7Cr3Ao99HkHvhdl5hubwlNgg Vh9MGcW+fdWOe0dN55fLVLFHkTjRnNsjVn0KmOER4E1lOlfJy3ITlXdcsMBUWOqJ94eL ld5I9Ex/LLY7I6+Q1m5ChhrO55fk8es+H6GJVeg41UtunZo051j3b2rHLHcatxpp3Atu BShw== X-Received: by 10.194.71.16 with SMTP id q16mr1785172wju.49.1449608909778; Tue, 08 Dec 2015 13:08:29 -0800 (PST) Received: from [10.0.0.5] (bzq-109-65-33-177.red.bezeqint.net. [109.65.33.177]) by smtp.gmail.com with ESMTPSA id vu4sm4624382wjc.2.2015.12.08.13.08.27 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Dec 2015 13:08:28 -0800 (PST) To: Tommy Pauly References: <5666AD1B.6000105@gmail.com> <18BF5929-6C8C-41A5-A3BC-764D3F56B2F3@apple.com> From: Yaron Sheffer Message-ID: <566746C9.1020202@gmail.com> Date: Tue, 8 Dec 2015 23:08:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <18BF5929-6C8C-41A5-A3BC-764D3F56B2F3@apple.com> Content-Type: multipart/alternative; boundary="------------040400000306060707030003" Archived-At: Cc: "ipsec@ietf.org" , Samy Touati , "ynir.ietf@gmail.com" Subject: Re: [IPsec] New revision of TCP Encapsulation draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 21:08:34 -0000 This is a multi-part message in MIME format. --------------040400000306060707030003 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Tommy, Thanks for clarifying this point. But I still think we are making a protocol change for what can be solved easily at the implementation level. Implementations will need to tag each IKE SA with the currently valid TCP connection on which responses can be sent. And ESP SAs likely already point to their parent IKE SA. So when we have an ESP packet that needs to be sent back from the responder, why not look up its associated IKE SA and use it to find the TCP connection? IMHO it would be better if we can stick to the simple model of a TCP wrapper for an unordered pile of IKE and ESP messages. This would add TCP with the minimal change to ESP, IKE and the relationship between them. Thanks, Yaron On 12/08/2015 10:24 PM, Tommy Pauly wrote: > Hi Yaron, > > The original version of the draft did not require that the new TCP > connection begin with an IKE message, but it was added in response to > feedback we received at our meeting in Yokohama. > > The concern was that the new TCP connection would almost certainly > have different ports from the old connection. In order for the server > to send packets back to the client, it needs to know the correct > mapping for both the IKE SAs and the Child SAs. If we allow an ESP > packet to be the first packet of a new connection, it may be hard to > implement a correct server that reacts to that and adjusts all > associated IKE and Child SA values to use the new port. However, it > the first packet is an IKE packet, the server can essentially treat it > as if it were MOBIKE and reset the ports. > > In the case of multiple IKE SAs over a TCP connection (which is a new > edge case that has been brought up), perhaps it would make sense to > say that for all IKE SAs using the connection, at least one IKE > message must precede any ESP messages for a Child SA of the IKE SA. > > Does this make sense? > > Thanks, > Tommy > >> On Dec 8, 2015, at 2:12 AM, Yaron Sheffer > > wrote: >> >> Hi Samy, >> >> Thanks for the new draft. It addresses most of my comments, but one >> question remains. >> >> I still don't understand why we require that each connection should >> start with an IKE message. The explanation given is "to allow the >> peer to know with which IKE session the traffic is associated." But >> of course the ESP SPI identifies the Child SA, and implicitly, the >> IKE SA. >> >> Moreover, later in the same section you allow multiple IKE SAs over >> the same connection, which again doesn't work well with the reasoning >> above. >> >> Best, >> Yaron >> >> On 12/08/2015 08:40 AM, Samy Touati wrote: >>> Hi Yaron and Yoav, >>> >>> An updated draft addressing your comments has been posted. >>> >>> https://www.ietf.org/internet-drafts/draft-pauly-ipsecme-tcp-encaps-02.txt >>> >>> Please check it out, and provide feedback. >>> >>> >>> Thanks. >>> Samy. >>> >>> >>> *From:* Yaron Sheffer >>> *Sent:* Nov 20, 2015 3:11 PM >>> *To:* Tommy Pauly; IPsecME WG >>> *Subject:* Re: [IPsec] New revision of TCP Encapsulation draft >>> >>> Hi Tommy, >>> >>> I also think this is very relevant work. Here are some comments to -01: >>> >>> I think that Yoav's draft, draft-nir-ipsecme-ike-tcp-01, should be >>> cited >>> under "prior work", both because it is documented and also because I >>> believe it is implemented by a vendor. >>> >>> In Sec. 1, under the UDP encapsulation, I suggest to add "Often peers >>> will use UDP encapsulation even when there is no NAT on the path, for >>> example because networks or middleboxes do not support IP protocols >>> other than TCP and UDP." >>> >>> "Although a stream" - this paragraph is not worded very well (streams >>> don't send anything) and is hard to understand. There are lots of >>> networks that use jumbo frames and so hardcoding the value 1500 into >>> the >>> spec may not be a good idea. >>> >>> I can think of HA cases where several gateways are handling ESP SAs >>> that >>> are all associated with the same IKE SA. So I'm wondering why we are >>> insisting on all Child SAs being in the same connection, and as a >>> result >>> requiring that an IKE message be the preamble to any new connection. >>> >>> Although it might seem obvious, I think Sec. 3 should say explicitly >>> that if the connection is closed midway through a message, the >>> recipient >>> must silently drop the partial message. >>> >>> You may want to add to the last paragraph of the Security >>> Considerations: This document explicitly does not define a profile for >>> TLS when used in this manner, or any relation between identities at the >>> IPsec level and those at the TLS level ("channel binding"). >>> >>> Thanks, >>> Yaron >>> >>> On 11/20/2015 11:49 PM, Tommy Pauly wrote: >>> > Hello, >>> > >>> > Based on the feedback received at our informal meeting in >>> Yokohama, I’ve updated the draft for TCP Encapsulation of IKEv2 and ESP: >>> > >>> > https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-01 >>> > >>> > The revisions include: >>> > - More explanation in the introduction about the motivation, and >>> other work that this draft is trying to standardize (3GPP >>> recommendations, proprietary IKEv1 IPSec over TCP versions, and SSL >>> VPNs). >>> > - Comments about maximum IKE and ESP message size within the TCP >>> stream, which is effective the MTU of the tunnel. >>> > - Specify that if the TCP connection is brought down and >>> re-established, the first message on the stream must be an IKE message. >>> > - Detailed considerations about interactions with middleboxes >>> (thanks Graham Bartlett for input on this). >>> > >>> > In the meeting in Yokohama, there was general agreement that this >>> was relevant work that we’d like to keep looking into. Please read >>> the document, and provide any feedback you have! >>> > >>> > Thanks, >>> > Tommy >>> > _______________________________________________ >>> > IPsec mailing list >>> > IPsec@ietf.org >>> > https://www.ietf.org/mailman/listinfo/ipsec >>> > >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> >>> >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > --------------040400000306060707030003 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Tommy,

Thanks for clarifying this point. But I still think we are making a protocol change for what can be solved easily at the implementation level. Implementations will need to tag each IKE SA with the currently valid TCP connection on which responses can be sent. And ESP SAs likely already point to their parent IKE SA. So when we have an ESP packet that needs to be sent back from the responder, why not look up its associated IKE SA and use it to find the TCP connection?

IMHO it would be better if we can stick to the simple model of a TCP wrapper for an unordered pile of IKE and ESP messages. This would add TCP with the minimal change to ESP, IKE and the relationship between them.

Thanks,
    Yaron

On 12/08/2015 10:24 PM, Tommy Pauly wrote:
Hi Yaron,

The original version of the draft did not require that the new TCP connection begin with an IKE message, but it was added in response to feedback we received at our meeting in Yokohama.

The concern was that the new TCP connection would almost certainly have different ports from the old connection. In order for the server to send packets back to the client, it needs to know the correct mapping for both the IKE SAs and the Child SAs. If we allow an ESP packet to be the first packet of a new connection, it may be hard to implement a correct server that reacts to that and adjusts all associated IKE and Child SA values to use the new port. However, it the first packet is an IKE packet, the server can essentially treat it as if it were MOBIKE and reset the ports.

In the case of multiple IKE SAs over a TCP connection (which is a new edge case that has been brought up), perhaps it would make sense to say that for all IKE SAs using the connection, at least one IKE message must precede any ESP messages for a Child SA of the IKE SA.

Does this make sense?

Thanks,
Tommy

On Dec 8, 2015, at 2:12 AM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

Hi Samy,

Thanks for the new draft. It addresses most of my comments, but one question remains.

I still don't understand why we require that each connection should start with an IKE message. The explanation given is "to allow the peer to know with which IKE session the traffic is associated." But of course the ESP SPI identifies the Child SA, and implicitly, the IKE SA.

Moreover, later in the same section you allow multiple IKE SAs over the same connection, which again doesn't work well with the reasoning above.

Best,
    Yaron

On 12/08/2015 08:40 AM, Samy Touati wrote:
Hi Yaron and Yoav,

An updated draft addressing your comments has been posted.


Please check it out, and provide feedback.


Thanks.
Samy.


From: Yaron Sheffer <yaronf.ietf@gmail.com>
Sent: Nov 20, 2015 3:11 PM
To: Tommy Pauly; IPsecME WG
Subject: Re: [IPsec] New revision of TCP Encapsulation draft

Hi Tommy,

I also think this is very relevant work. Here are some comments to -01:

I think that Yoav's draft, draft-nir-ipsecme-ike-tcp-01, should be cited 
under "prior work", both because it is documented and also because I 
believe it is implemented by a vendor.

In Sec. 1, under the UDP encapsulation, I suggest to add "Often peers 
will use UDP encapsulation even when there is no NAT on the path, for 
example because networks or middleboxes do not support IP protocols 
other than TCP and UDP."

"Although a stream" - this paragraph is not worded very well (streams 
don't send anything) and is hard to understand. There are lots of 
networks that use jumbo frames and so hardcoding the value 1500 into the 
spec may not be a good idea.

I can think of HA cases where several gateways are handling ESP SAs that 
are all associated with the same IKE SA. So I'm wondering why we are 
insisting on all Child SAs being in the same connection, and as a result 
requiring that an IKE message be the preamble to any new connection.

Although it might seem obvious, I think Sec. 3 should say explicitly 
that if the connection is closed midway through a message, the recipient 
must silently drop the partial message.

You may want to add to the last paragraph of the Security 
Considerations: This document explicitly does not define a profile for 
TLS when used in this manner, or any relation between identities at the 
IPsec level and those at the TLS level ("channel binding").

Thanks,
        Yaron

On 11/20/2015 11:49 PM, Tommy Pauly wrote:
> Hello,
>
> Based on the feedback received at our informal meeting in Yokohama, I’ve updated the draft for TCP Encapsulation of IKEv2 and ESP:
>
> https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-01
>
> The revisions include:
> - More explanation in the introduction about the motivation, and other work that this draft is trying to standardize (3GPP recommendations, proprietary IKEv1 IPSec over TCP versions, and SSL VPNs).
> - Comments about maximum IKE and ESP message size within the TCP stream, which is effective the MTU of the tunnel.
> - Specify that if the TCP connection is brought down and re-established, the first message on the stream must be an IKE message.
> - Detailed considerations about interactions with middleboxes (thanks Graham Bartlett for input on this).
>
> In the meeting in Yokohama, there was general agreement that this was relevant work that we’d like to keep looking into. Please read the document, and provide any feedback you have!
>
> Thanks,
> Tommy
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>

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



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

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


--------------040400000306060707030003-- From nobody Thu Dec 10 06:00:25 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D24A1A8ACC for ; Thu, 10 Dec 2015 06:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=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 AOroZwcjnl7j for ; Thu, 10 Dec 2015 06:00:19 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 D15BA1A6F82 for ; Thu, 10 Dec 2015 06:00:18 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.1/8.14.8) with ESMTPS id tBAE0GCK016065 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 10 Dec 2015 16:00:16 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.1/8.14.8/Submit) id tBAE0GOT028745; Thu, 10 Dec 2015 16:00:16 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22121.34160.710157.289114@fireball.acr.fi> Date: Thu, 10 Dec 2015 16:00:16 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 9 min X-Total-Time: 8 min Archived-At: Subject: [IPsec] RFC4307bis and authentication methods X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 14:00:23 -0000 During the draft-ietf-lwig-ikev2-minimal Stephen pointed out that in my draft I have copied requirements from the RFC7296: ---------------------------------------------------------------------- ... For an implementation to be called conforming to this specification, it MUST be possible to configure it to accept the following: o Public Key Infrastructure using X.509 (PKIX) Certificates containing and signed by RSA keys of size 1024 or 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR, or ID_DER_ASN1_DN. ... ---------------------------------------------------------------------- And he pointed out that this asks for mandatory to implemented key size for RSA to be 1024 or 2048-bits. It is not up to the ikev2-minimal to change these, but RFC4307bis is different thing. I.e. should we modify this also while updating the RFC4307? We could add section about the mandatory to implement authentication methods, and specify which methods are to be used, for example require RSA key lengths of 2048 bits, and perhaps say that implementations SHOULD support RSA key lengths up to 4096 bits. For the elliptic curves we might want to say something about signature authentication method (RFC 7427) as that supports generic elliptic curves not only the nist versions. Also should we say something about the RSASSA-PKCS1-v1_5 vs RSASSA-PSS? -- kivinen@iki.fi From nobody Thu Dec 10 08:28:00 2015 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 1E4CD1A88D6 for ; Thu, 10 Dec 2015 08:27:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151210162759.6203.31924.idtracker@ietfa.amsl.com> Date: Thu, 10 Dec 2015 08:27:59 -0800 From: IETF Secretariat Archived-At: Subject: [IPsec] Milestones changed for ipsecme WG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 16:27:59 -0000 Deleted milestone "IETF Last Call on null authentication". URL: https://datatracker.ietf.org/wg/ipsecme/charter/ From nobody Thu Dec 10 08:28:19 2015 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 16FD61A88FE for ; Thu, 10 Dec 2015 08:28:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151210162818.10026.97348.idtracker@ietfa.amsl.com> Date: Thu, 10 Dec 2015 08:28:18 -0800 From: IETF Secretariat Archived-At: Subject: [IPsec] Milestones changed for ipsecme WG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 16:28:18 -0000 Deleted milestone "IETF Last Call on Chacha20-Poly1305". URL: https://datatracker.ietf.org/wg/ipsecme/charter/ From nobody Thu Dec 10 08:29:03 2015 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 54BB51A88D6 for ; Thu, 10 Dec 2015 08:29:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151210162901.7081.9361.idtracker@ietfa.amsl.com> Date: Thu, 10 Dec 2015 08:29:01 -0800 From: IETF Secretariat Archived-At: Subject: [IPsec] Milestones changed for ipsecme WG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 16:29:01 -0000 Changed milestone "IETF Last Call on DDoS protection", set due date to March 2016 from August 2015, added draft-ietf-ipsecme-ddos-protection to milestone. URL: https://datatracker.ietf.org/wg/ipsecme/charter/ From nobody Thu Dec 10 10:24:30 2015 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 802721AC3E3 for ; Thu, 10 Dec 2015 10:24:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151210182428.7802.77949.idtracker@ietfa.amsl.com> Date: Thu, 10 Dec 2015 10:24:28 -0800 From: IETF Secretariat Archived-At: Subject: [IPsec] Milestones changed for ipsecme WG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 18:24:28 -0000 Changed milestone "IETF Last Call on cryptographic algorithms for IKEv2", set state to active from review, accepting new milestone. Changed milestone "IETF Last Call on Curve25519 and Curve448 for IKEv2", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/ipsecme/charter/ From nobody Thu Dec 10 15:18:56 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF961B2DB7 for ; Thu, 10 Dec 2015 15:18:55 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains text/plain,.exe X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_82=0.6, SPF_PASS=-0.001] autolearn=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 v9VUwHa4FHPc for ; Thu, 10 Dec 2015 15:18:52 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 0125B1B2DF7 for ; Thu, 10 Dec 2015 15:18:51 -0800 (PST) Received: by wmnn186 with SMTP id n186so7781091wmn.0 for ; Thu, 10 Dec 2015 15:18:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=+2uDnD7vq233cRaUZyETvmnLlXBQ3joq9nwTA//+3Ag=; b=mWSvdOqEBG1xWhjg84uZzlurkCziIRnfkrVgl1OpB6fs0Ee023k9A+3BVml0PbLSTG EIfEAy3o4Zk+ccDYOcgB9uOoAyOQ+ms40TIRHwcldYZ4isnBb5w7q9Lzgk03ekpv0T78 B2uMLQRpnndMzAV0gyOhFkCI6ZnXKf2kPYHjEFsJ9jGNZVBWA0EKtflx9xQfVaJrZnUu Ja7JDa1H41HtPLRLQEvXnroV/pXG1tQXldcuRWi97nhZ/cuTn3w1Std1PWc+Xb8GOJQu 3g3C+R6ChheEvTbXarpgVKSdTY8fy6EasSbnpCBswp/SIGBaMKTtJsTVKbqjB+tdezSt U/Qw== MIME-Version: 1.0 X-Received: by 10.28.32.65 with SMTP id g62mr1709863wmg.81.1449789530461; Thu, 10 Dec 2015 15:18:50 -0800 (PST) Sender: mglt.ietf@gmail.com Received: by 10.194.9.106 with HTTP; Thu, 10 Dec 2015 15:18:50 -0800 (PST) In-Reply-To: References: <0748F101-7104-4F07-B440-31A9CF63BE32@gmail.com> <9EBE3C6E-C7F2-4327-B4E2-3363BD96ECC1@gmail.com> <56421D6F.7080506@gmail.com> <22082.23345.969526.729086@fireball.acr.fi> <564A1549.1010001@gmail.com> Date: Thu, 10 Dec 2015 18:18:50 -0500 X-Google-Sender-Auth: LgPuhgYlP8ss4ydTRWGTPCIYaTI Message-ID: From: Daniel Migault To: John Mattsson Content-Type: multipart/alternative; boundary=001a113c8346f65f020526936dd9 Archived-At: Cc: IPsecME WG , Paul Wouters , Tommy Pauly Subject: Re: [IPsec] RFC 4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 23:18:55 -0000 --001a113c8346f65f020526936dd9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi John, Thank you for your inputs. In order to update the document any further I would like to get feed backs from the WG. Please provide your comments so I can update the document appropriately next week. 1) MTI? Are there any opinion to replace Mandatory to implement by something like "Algorithm Implementation Requirements and Usage Guidance"or close to. This designation seems more in scope with the different status. 2) 1024-bit MODP SHOULD NOT- ? The current draft set 1024-bit MODP Group as SHOULD NOT with the following explanation: """Group 2 or 1024-bit MODP Group is downgraded from MUST- to SHOULD NOT. It was specified earlier, and now it is known to be weak against a nation state attack, so its security margin is considered too narrow.""" My understanding from the discussion at the IETF94 was that we are trying to avoid the +/- notation but instead clarify the status with some additional text. The current version only use the +/- notation for AUTH_HMAC_SHA2_512_256 SHOULD+. Here are my question for the WG: a) Do we want to keep the notation +/- ? b) if not would people agree with AUTH_HMAC_SHA2_512_256 set to SHOULD Depending on the above outputs, are there any opinion for: c) Changing the status from SHOULD NOT to SHOULD NOT + ? d) Explicitely mentionning in the text that we expect it to downgraded to MUST NOT in the near future. 3) +/- notations? If we keep the +/- notations, I agree we should define +/- only.I will change that unless some people think it is a bad idea. 4) Curve25519 ? Curve25519 is by default set to MAY. If we still have the -/+ notation would people agree to have MAY+ for its status. If I remember correctly, we did not mentionned Curve25519 to SHOULD as it is not yet widely deployed. By default all non mentioned algorithms are set to MAY. Maybe having MAY+ would be good alternative to show what we expect next and enable implementer to anticipate. Here are my questions: e) Should we upgrade Curve25519 to MAY+? BR, Daniel On Fri, Dec 4, 2015 at 4:45 AM, John Mattsson wrote: > Hi, > > -Agree with your comment on =E2=80=9Cmandatory-to-implement=E2=80=9D. I t= hink the > Introduction should be changed, and I suggest using something like the te= xt > used in RFC7321 =E2=80=9CAlgorithm Implementation Requirements and Usage = Guidance=E2=80=9D. > RFC7321 also has a more explaining title. > > - I think 1024-bit MODP should be =E2=80=9CSHOULD NOT-=E2=80=9D as it see= ms to be > agreement that is should be =E2=80=9CMUST NOT=E2=80=9D in the next update= . Might may sense > to define =E2=80=9C+=E2=80=9D and =E2=80=9C-=E2=80=9D instead of =E2=80= =9CSHOULD+, SHOULD-, MUST-=E2=80=9D > > - I think =E2=80=9CCurve25519=E2=80=9D should be included as =E2=80=9CMAY= =E2=80=9D or =E2=80=9CMAY+=E2=80=9D, even if > nobody has implemented it yet, it seems like the obvious choice long-term= . > > Cheers, > John > > From: IPsec on behalf of Daniel Migault < > daniel.migault@ericsson.com> > Date: Wednesday 2 December 2015 23:24 > To: Tommy Pauly > Cc: IPsecME WG , Paul Wouters > Subject: Re: [IPsec] RFC 4307bis > > Hi, > > Please find the updated version with the new section titles suggested by > Yaron: > 1.1 Updating Mandatory to Implement Algorithms > 1.2 Updating Algorithm Requirement Levels > 1.3 Document Audience > > BR, > Daniel > > https://github.com/mglt/drafts/commit/ffb6e9ad82bc952f3a891de232cd10be353= 878a9 > > On Wed, Dec 2, 2015 at 4:01 PM, Daniel Migault < > daniel.migault@ericsson.com> wrote: > >> Hi, >> >> Please se the current version of the document with the subsection in the >> Introduction. >> >> >> https://github.com/mglt/drafts/commit/ef72ea482af74d4226d3059237024f63d0= add01b >> >> The subsections are: >> 1.1 Updating Mandatory to Implement Algorythms >> 1.2 Algorithm Status Update Policy >> 1.3 Audience of the Document >> >> Feel free to provide any comment. I beleive we have addressed all >> comments we received. >> >> I am finding the terminology mandatory-to-implement maybe a bit >> misleading for status like MAY or a MUST NOT. Any suggestion to clarify >> that? >> >> BR, >> Daniel >> >> On Mon, Nov 30, 2015 at 12:22 PM, Daniel Migault < >> daniel.migault@ericsson.com> wrote: >> >>> Hi Tommy, >>> >>> Thanks for the proposition Tommy, I thnik that will clearer to have >>> dedicated subsections in the intro. Here are the subsection I would >>> propose. I am waiting for the WG feed back before updating the draft, s= o >>> please let m eknow whether: >>> >>> A) You like the idea of subsection in the intro >>> B) You DO NOT like the idea of subsections >>> >>> C) If you like the following: >>> c1) The need for mandatory-to-implement algorithms >>> c2) The scope of the document (IKEv2 + implementer) >>> c3) Updating algorithm status (deprecation of algorithms and the Io= T >>> section) >>> >>> D) If you have other propositions. >>> >>> I will update the draft this week according to the responses. >>> >>> BR, >>> Daniel >>> >>> >>> On Mon, Nov 30, 2015 at 12:20 PM, Tommy Pauly wrote: >>> >>>> Hi Daniel, >>>> >>>> Thanks for making these changes! I think this makes the document much >>>> clearer. >>>> >>>> With regards to the Introduction, it may be beneficial at this point t= o >>>> have subsections of the introduction to make it easier to parse. Right= now >>>> there seem to be several topics that don=E2=80=99t necessarily flow in= to one >>>> another: explaining mandatory-to-implement algorithms, explaining whic= h >>>> version of IKE is relevant, explaining deprecation of algorithms, and = the >>>> IoT section. >>>> >>>> Thanks, >>>> tommy >>>> >>>> On Nov 26, 2015, at 2:58 PM, Daniel Migault < >>>> daniel.migault@ericsson.com> wrote: >>>> >>>> Hi Paul and Tommy, >>>> >>>> Please find the new update of the draft: >>>> 1) text in the introduction has been added to specify the IoT use case= , >>>> and the motivations for having IoT considerations in this document. >>>> 2) IoT has been indicated in the tables with a comment specifying that >>>> the requirement is for IoT interoperability. I was not able to have tw= o >>>> lines in the postamble. It seems is not accepted as a childr= en >>>> for >>>> 3) RFCs have been added in the reference section to enable xml2rfc to >>>> run properly. >>>> >>>> The update is available here: >>>> >>>> https://github.com/mglt/drafts/commit/8c125fa2a82af21a44c5035c3311938d= 26443652 >>>> >>>> Feel free to comment update the text. >>>> >>>> BR, >>>> Daniel >>>> >>>> >>>> On Mon, Nov 23, 2015 at 11:20 AM, Paul Wouters wrote: >>>> >>>>> On Fri, 20 Nov 2015, Tommy Pauly wrote: >>>>> >>>>> On a broader note, many of the SHOULD algorithms (ENCR_AES_CCM_8, >>>>>> PRF_AES128_CBC, AUTH_AES-XCBC) are >>>>>> justified as being present for the purposes of Internet of Things >>>>>> devices. I tend to think that it would be >>>>>> more straightforward to have a separate document that explains the >>>>>> preferred algorithms for IoT devices (an >>>>>> IKEv2 profile for IoT, for example). However, if we do want to keep >>>>>> them in this document, I think it would >>>>>> help to have a section in the introduction to the document explainin= g >>>>>> the use case for the IoT devices and >>>>>> why they are now included in the bis document, whereas they were not >>>>>> relevant yet in RFC 4307. It may also >>>>>> be helpful to qualify the SHOULDs as pertaining more, perhaps, to >>>>>> servers; traditional VPN clients would >>>>>> generally not be interacting with IoT devices directly, and thus >>>>>> would have little reason to implement >>>>>> these algorithms. >>>>>> >>>>> >>>>> I would suggest if we want to do that, to just use a [*] notation whe= re >>>>> the [*] gets explained as "For interoperability with IoT clients only= " >>>>> >>>>> I would not want to leave it out because that will cause us to get >>>>> servers that won't support IoT devices. >>>>> >>>>> Paul >>>>> >>>>> >>>>> _______________________________________________ >>>>> IPsec mailing list >>>>> IPsec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ipsec >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> IPsec mailing list >>>> IPsec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipsec >>>> >>>> >>> >> > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > --001a113c8346f65f020526936dd9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi John,

Thank you for your inputs= . In order to update the document any further I would like to get feed back= s from the WG. Please provide your comments so I can update th= e document appropriately next week.

1) MTI?
Are there any opinion to replace Mandatory to implement by something lik= e "Algorithm Implementation Requirements and Usage Guidance"or cl= ose to. This designation seems more in scope with the different status.
2) 1024-bit MODP SHOULD NOT- ?
The current = draft set 1024-bit MODP Group as SHOULD NOT with the following= explanation:

"""Group 2 or 1024-bit MODP Group is downgraded from MUST- to SHOULD NOT. It was specified earlier, a= nd now it is known to be weak against a nation state attack, so its securit= y margin is considered too narrow."""

My u= nderstanding from the discussion at the IETF94 was that we are trying to av= oid the +/- notation but instead clarify the status with some additional te= xt. The current version only use the +/- notation for AUTH_HMAC_SHA2_512_256 SHOULD+. Here are my question for = the WG:
=C2=A0=C2=A0=C2=A0 a) Do we want to keep= the notation +/- ?
=C2=A0=C2=A0=C2=A0 b) if not would people= agree with AUTH_HMAC_SHA2_512_256 set to SHOULD<= /div>

Depending on the above outputs, are there any opinion for:=C2=A0=C2=A0 c) Changing the status from SHOULD NOT to SHOULD NOT + ?
= =C2=A0=C2=A0 d) Explicitely mentionning in the te= xt that we expect it to downgraded to MUST NOT in the near future.

=
3) +/- notations?
If we keep the +/- notations, I = agree we should define +/- only.I will change that unless some people think= it is a bad idea.

4) Curve25519 ?
Curve25519 is by default set t= o MAY. If we still have the -/+ notation would people agree to have MAY+ fo= r its status. If I remember correctly, we did not mentionned C= urve25519 to SHOULD as it is not yet widely deployed. By default all non me= ntioned algorithms are set to MAY. Maybe having MAY+ would be good alternat= ive to show what we expect next and enable implementer to anticipate. Here = are my questions:
=C2=A0=C2=A0=C2=A0 e) Should we upgrade Cur= ve25519 to MAY+?

BR,
Daniel
=
=C2=A0

On Fri, Dec 4, 2015 at 4:45 AM, John Mattsson <john.mattsson@ericsson.com> wr= ote:
Hi,

-Agree with your comment on =E2=80=9Cmandatory-to-implement=E2=80=9D. = I think the Introduction should be changed, and I suggest using something l= ike the text used in RFC7321 =E2=80=9CAlgorithm Implementation Requirements= and Usage Guidance=E2=80=9D. RFC7321 also has a more explaining title.

- I think 1024-bit MODP should be =E2=80=9CSHOULD NOT-=E2=80=9D as it = seems to be agreement that is should be =E2=80=9CMUST NOT=E2=80=9D in the n= ext update. Might may sense to define =E2=80=9C+=E2=80=9D and =E2=80=9C-=E2= =80=9D instead of =E2=80=9CSHOULD+, SHOULD-, MUST-=E2=80=9D

- I think =E2=80=9CCurve25519=E2=80=9D should be included as =E2=80=9C= MAY=E2=80=9D or =E2=80=9CMAY+=E2=80=9D, even if nobody has implemented it y= et, it seems like the obvious choice long-term.

Cheers,
John

From: IPsec <ipsec-bounces@ietf.org> on = behalf of Daniel Migault <daniel.migault@ericsson.com>
Date: Wednesday 2 December 2015 23:= 24
To: Tommy Pauly <tpauly@apple.com>
Cc: IPsecME WG <ipsec@ietf.org>, Paul Wouters &l= t;paul@nohats.ca>= ;
Subject: Re: [IPsec] RFC 4307bis

Hi,

Please find the updated version with the new section titles suggested by Ya= ron:
1.1 Updating Mandatory to Implement Algorithms
1.2 Updating Algorithm Requirement Levels
1.3 Document Audience

BR,
Daniel
https://github.com/mglt/drafts/commit/ffb= 6e9ad82bc952f3a891de232cd10be353878a9

On Wed, Dec 2, 2015 at 4:01 PM, Daniel Migault <= span dir=3D"ltr"> <daniel= .migault@ericsson.com> wrote:
Hi,

Please se the current version of the document with the subsection in the In= troduction.

https://github.com/mglt/drafts/commit/ef7= 2ea482af74d4226d3059237024f63d0add01b

The subsections are:
=C2=A0=C2=A0 1.1 Updating Mandatory to Implement Algorythms
=C2=A0=C2=A0 1.2 Algorithm Status Update Policy
=C2=A0=C2=A0 1.3 Audience of the Document

Feel free to provide any comment. I beleive we have addressed all comments = we received.

I am finding the terminology mandatory-to-implement maybe a bit misleading = for status like MAY or a MUST NOT. Any suggestion to clarify that? =C2=A0

BR,
Daniel

On Mon, Nov 30, 2015 at 12:22 PM, Daniel Migault= <daniel= .migault@ericsson.com> wrote:
Hi Tommy,

Thanks for the proposition Tommy, I thnik that will clearer to have dedicat= ed subsections in the intro. Here are the subsection I would propose. I am = waiting for the WG feed back before updating the draft, so please let m ekn= ow whether:

A) You like the idea of subsection in the intro
B) You DO NOT like the idea of subsections

C) If you like the following:=C2=A0 =C2=A0
=C2=A0=C2=A0=C2=A0 c1) The need for mandatory-to-implement algorithms<= br> =C2=A0=C2=A0=C2=A0 c2) The scope of the document (IKEv2 + implementer)
=C2=A0=C2=A0=C2=A0 c3) Updating algorithm status (deprecation of algorithms= and the IoT section)

D) If you have other propositions.

I will update the draft this week according to the responses.
=C2=A0
BR,
Daniel


On Mon, Nov 30, 2015 at 12:20 PM, Tommy Pauly <tpauly@apple.com<= /a>> wrote:
Hi Daniel,

Thanks for making these changes! I think this makes the document much = clearer.

With regards to the Introduction, it may be beneficial at this point t= o have subsections of the introduction to make it easier to parse. Right no= w there seem to be several topics that don=E2=80=99t necessarily flow into = one another: explaining mandatory-to-implement algorithms, explaining which version of IKE is relevant, explaining deprec= ation of algorithms, and the IoT section.

Thanks,
tommy


Hi Paul and Tommy,

Please find the new update of the draft:
1) text in the introduction has been added to specify the IoT use case, and= the motivations for having IoT considerations in this document.
2) IoT has been indicated in the tables with a c= omment specifying that the requirement is for IoT interoperability. I was n= ot able to have two lines in the postamble. It seems <artwork> is not= accepted as a children for <postamble>
3) RFCs have been added in the reference section= to enable xml2rfc to run properly.

The update is available here:
https://github.com/mglt/drafts/commit/8c1= 25fa2a82af21a44c5035c3311938d26443652

Feel free to comment update the text.

BR,
Daniel


On Mon, Nov 23, 2015 at 11:20 AM, Paul Wouters <= span dir=3D"ltr"> <paul@nohats.ca&= gt; wrote:
On Fri, 20 Nov 2015, Tommy Pauly wrote:

On a broader note, many of the SHOULD algorithms (ENCR_AES_CCM_8, PRF_AES12= 8_CBC,=C2=A0AUTH_AES-XCBC) are
justified as being present for the purposes of Internet of Things devices. = I tend to think that it would be
more straightforward to have a separate document that explains the preferre= d algorithms for IoT devices (an
IKEv2 profile for IoT, for example). However, if we do want to keep them in= this document, I think it would
help to have a section in the introduction to the document explaining the u= se case for the IoT devices and
why they are now included in the bis document, whereas they were not releva= nt yet in=C2=A0RFC 4307. It may also
be helpful to qualify the SHOULDs as pertaining more, perhaps, to servers; = traditional VPN clients would
generally not be interacting with IoT devices directly, and thus would have= little reason to implement
these algorithms.

I would suggest if we want to do that, to just use a [*] notation wh= ere
the [*] gets explained as "For interoperability with IoT clients only&= quot;

I would not want to leave it out because that will cause us to get
servers that won't support IoT devices.
Paul


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



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

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


--001a113c8346f65f020526936dd9-- From nobody Thu Dec 10 15:46:49 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4406C1B2EDB for ; Thu, 10 Dec 2015 15:46:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 8fJPrUuBe4xr for ; Thu, 10 Dec 2015 15:46:45 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 67F091B2ECC for ; Thu, 10 Dec 2015 15:46:45 -0800 (PST) Received: by wmnn186 with SMTP id n186so8456231wmn.0 for ; Thu, 10 Dec 2015 15:46:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=EcM0cQN7KA+0tfCnqylR+gkxssvoNHBCifCJkiG3L7Y=; b=KKp4L7Amt115IMboir0XqYfnxedZGbFQ3WAyg9NlbbVLfzjcdsVK5SFQbvjqz/w9H+ bCPWoguxDWyIyQt4A1BERQg9sJWFOVoKZpgq6l30bgXX5fVUTxkb8nwPygRfgweDZ7ZY fTve5v2+L3tp9qaip94DJo+eM7eQKxORjExVyDqxP9fAgn1SAY4rJ6PIGyDakbQWuwb/ jW8AbFD1idXV281ot9ACCvH5iLGTnFxgUuUbx4/heAayVFJJiZknsLSkSgojzmwqzsXJ /sMhiS2/lloO6UIfUGm+vfvFZiXMnan830jlii7E9hbEhIkBF/J3UrSb3/N8Q8NjQlAh dIPQ== MIME-Version: 1.0 X-Received: by 10.28.179.68 with SMTP id c65mr1841752wmf.81.1449791204030; Thu, 10 Dec 2015 15:46:44 -0800 (PST) Sender: mglt.ietf@gmail.com Received: by 10.194.9.106 with HTTP; Thu, 10 Dec 2015 15:46:43 -0800 (PST) In-Reply-To: <22121.34160.710157.289114@fireball.acr.fi> References: <22121.34160.710157.289114@fireball.acr.fi> Date: Thu, 10 Dec 2015 18:46:43 -0500 X-Google-Sender-Auth: XYwgs_UfWAFPoeoj8Uz4vGeLms0 Message-ID: From: Daniel Migault To: Tero Kivinen Content-Type: multipart/alternative; boundary=001a114532bcb708d3052693d1bb Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] RFC4307bis and authentication methods X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 23:46:47 -0000 --001a114532bcb708d3052693d1bb Content-Type: text/plain; charset=UTF-8 Hi, I have the impression the recommendation goes beyond the scope of IKEv2 and is more targeting Certificates. On the other hand, having these requirements would make all cryptographic requirements fit into a single document IKEv2 As a result, I would rather have a section with a link to a document that contains requirements that are specific to the Certificates. I am also wondering if the IKEv2 spec should not also point to that document. BR, Daniel On Thu, Dec 10, 2015 at 9:00 AM, Tero Kivinen wrote: > During the draft-ietf-lwig-ikev2-minimal Stephen pointed out that in > my draft I have copied requirements from the RFC7296: > > ---------------------------------------------------------------------- > ... > For an implementation to be called conforming to this specification, > it MUST be possible to configure it to accept the following: > > o Public Key Infrastructure using X.509 (PKIX) Certificates > containing and signed by RSA keys of size 1024 or 2048 bits, where > the ID passed is any of ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR, or > ID_DER_ASN1_DN. > ... > ---------------------------------------------------------------------- > > And he pointed out that this asks for mandatory to implemented key > size for RSA to be 1024 or 2048-bits. > > It is not up to the ikev2-minimal to change these, but RFC4307bis is > different thing. > > I.e. should we modify this also while updating the RFC4307? We could > add section about the mandatory to implement authentication methods, > and specify which methods are to be used, for example require RSA key > lengths of 2048 bits, and perhaps say that implementations SHOULD > support RSA key lengths up to 4096 bits. > > For the elliptic curves we might want to say something about signature > authentication method (RFC 7427) as that supports generic elliptic > curves not only the nist versions. Also should we say something about > the RSASSA-PKCS1-v1_5 vs RSASSA-PSS? > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --001a114532bcb708d3052693d1bb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I have the impression the recommendation g= oes beyond the scope of IKEv2 and is more targeting Certificates. On the ot= her hand, having these requirements would make all cryptographic requiremen= ts fit into a single document IKEv2 As a result, I would rather have a sect= ion with a link to a document that contains requirements that are specific = to the Certificates.

I am also wondering if the IKEv2 spec should n= ot also point to that document.

BR,
Daniel=

= On Thu, Dec 10, 2015 at 9:00 AM, Tero Kivinen <kivinen@iki.fi> = wrote:
During the draft-ietf-lwig-ikev2-m= inimal Stephen pointed out that in
my draft I have copied requirements from the RFC7296:

----------------------------------------------------------------------
...
=C2=A0 =C2=A0For an implementation to be called conforming to this specific= ation,
=C2=A0 =C2=A0it MUST be possible to configure it to accept the following:
=C2=A0 =C2=A0o=C2=A0 Public Key Infrastructure using X.509 (PKIX) Certifica= tes
=C2=A0 =C2=A0 =C2=A0 containing and signed by RSA keys of size 1024 or 2048= bits, where
=C2=A0 =C2=A0 =C2=A0 the ID passed is any of ID_KEY_ID, ID_FQDN, ID_RFC822_= ADDR, or
=C2=A0 =C2=A0 =C2=A0 ID_DER_ASN1_DN.
...
----------------------------------------------------------------------

And he pointed out that this asks for mandatory to implemented key
size for RSA to be 1024 or 2048-bits.

It is not up to the ikev2-minimal to change these, but RFC4307bis is
different thing.

I.e. should we modify this also while updating the RFC4307? We could
add section about the mandatory to implement authentication methods,
and specify which methods are to be used, for example require RSA key
lengths of 2048 bits, and perhaps say that implementations SHOULD
support RSA key lengths up to 4096 bits.

For the elliptic curves we might want to say something about signature
authentication method (RFC 7427) as that supports generic elliptic
curves not only the nist versions. Also should we say something about
the RSASSA-PKCS1-v1_5 vs RSASSA-PSS?
--
kivinen@iki.fi

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

--001a114532bcb708d3052693d1bb-- From nobody Fri Dec 11 04:03:14 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECCD61A8A0D for ; Fri, 11 Dec 2015 04:03:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=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 gf99SeCdM0Wq for ; Fri, 11 Dec 2015 04:03:11 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 7420B1A8A09 for ; Fri, 11 Dec 2015 04:03:11 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.1/8.14.8) with ESMTPS id tBBC38ll006232 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 11 Dec 2015 14:03:08 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.1/8.14.8/Submit) id tBBC37Ov005113; Fri, 11 Dec 2015 14:03:07 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22122.47995.926025.193723@fireball.acr.fi> Date: Fri, 11 Dec 2015 14:03:07 +0200 From: Tero Kivinen To: Daniel Migault In-Reply-To: References: <22121.34160.710157.289114@fireball.acr.fi> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 2 min X-Total-Time: 1 min Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] RFC4307bis and authentication methods X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 12:03:13 -0000 Daniel Migault writes: > I have the impression the recommendation goes beyond the scope of > IKEv2 and is more targeting Certificates. On the other hand, having > these requirements would make all cryptographic requirements fit > into a single document IKEv2 As a result, I would rather have a > section with a link to a document that contains requirements that > are specific to the Certificates. Partially yes, but the final certificate is also used in the IKEv2 for the authentication, so at least specifying something about that in here would be in line with RFC7296. Also as we currently do say bit sizes in the RFC7296, I think it is good idea to keep them up to date. -- kivinen@iki.fi From nobody Fri Dec 11 04:26:20 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCDFC1A9064 for ; Fri, 11 Dec 2015 04:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 c2PlV1kf6GnC for ; Fri, 11 Dec 2015 04:26:17 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB9CD1A9056 for ; Fri, 11 Dec 2015 04:26:16 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-58-566ac0e6b8c4 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 20.57.05041.6E0CA665; Fri, 11 Dec 2015 13:26:14 +0100 (CET) Received: from ESESSMB307.ericsson.se ([169.254.7.72]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0248.002; Fri, 11 Dec 2015 13:26:14 +0100 From: John Mattsson To: Tero Kivinen , "ipsec@ietf.org" Thread-Topic: [IPsec] RFC4307bis and authentication methods Thread-Index: AQHRM1Mk86wS+SUYhE2Ij/9JHCvQKJ7Ft52A Date: Fri, 11 Dec 2015 12:26:14 +0000 Message-ID: References: <22121.34160.710157.289114@fireball.acr.fi> In-Reply-To: <22121.34160.710157.289114@fireball.acr.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.8.151023 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUyM2K7se6zA1lhBhsPWlrs3/KCzeLo+eds DkweS5b8ZPI4/HUhSwBTFJdNSmpOZllqkb5dAldG//7MglliFd9+TmdsYLwg2sXIySEhYCJx /1Y/O4QtJnHh3nq2LkYuDiGBw4wSt9suMUM4ixklPr/5wgpSxSZgIDF3TwMbiC0i4CLx/8EC sG5hASuJ26u+sULErSV+7VjDCGEbSXzceQPMZhFQlXj8ZQdTFyMHB6+AucTGi8kgYSEgc9Hr tUwgNqeAhcTWad/ARjICHfT91BqwOLOAuMStJ/OZIA4VkFiy5zwzhC0q8fLxP7C1ogJ6Egc/ rWQFGS8hoCQxbWsaiMksoCmxfpc+hGkt8fZHJcRARYkp3Q/BFvEKCEqcnPmEZQKj+Cwku2Yh NM9CaJ6FpHkWkuYFjKyrGEWLU4uLc9ONjPRSizKTi4vz8/TyUks2MQJj7OCW31Y7GA8+dzzE KMDBqMTDa2CTFSbEmlhWXJl7iFGCg1lJhPfXBqAQb0piZVVqUX58UWlOavEhRmkOFiVx3mam B6FCAumJJanZqakFqUUwWSYOTqkGRsW3VcePdfZVLFp75EzYKXVZhYW/fhV6HrTZs+Q4s+ny G7pTRT3+nJng+nXK/CtR2461OCtEd6xXYnK9dEWNQ2T2vtuJgs+nLelI2eqyPzvl4Qr76qu7 G/P6by8omHLu9Ywrrzwrg9x4j03eN+dq19HEQxfsH33U4E3OrFmwZ9uti5vND8rlc8xWYinO SDTUYi4qTgQAjxTiSq0CAAA= Archived-At: Subject: Re: [IPsec] RFC4307bis and authentication methods X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 12:26:18 -0000 R29vZCBwb2ludCENCg0KDQpPbiAxMC8xMi8xNSAxNTowMCwgIklQc2VjIG9uIGJlaGFsZiBvZiBU ZXJvIEtpdmluZW4iDQo8aXBzZWMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Yga2l2aW5l bkBpa2kuZmk+IHdyb3RlOg0KDQo+RHVyaW5nIHRoZSBkcmFmdC1pZXRmLWx3aWctaWtldjItbWlu aW1hbCBTdGVwaGVuIHBvaW50ZWQgb3V0IHRoYXQgaW4NCj5teSBkcmFmdCBJIGhhdmUgY29waWVk IHJlcXVpcmVtZW50cyBmcm9tIHRoZSBSRkM3Mjk2Og0KPg0KPi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4uLi4N Cj4gICBGb3IgYW4gaW1wbGVtZW50YXRpb24gdG8gYmUgY2FsbGVkIGNvbmZvcm1pbmcgdG8gdGhp cyBzcGVjaWZpY2F0aW9uLA0KPiAgIGl0IE1VU1QgYmUgcG9zc2libGUgdG8gY29uZmlndXJlIGl0 IHRvIGFjY2VwdCB0aGUgZm9sbG93aW5nOg0KPg0KPiAgIG8gIFB1YmxpYyBLZXkgSW5mcmFzdHJ1 Y3R1cmUgdXNpbmcgWC41MDkgKFBLSVgpIENlcnRpZmljYXRlcw0KPiAgICAgIGNvbnRhaW5pbmcg YW5kIHNpZ25lZCBieSBSU0Ega2V5cyBvZiBzaXplIDEwMjQgb3IgMjA0OCBiaXRzLCB3aGVyZQ0K PiAgICAgIHRoZSBJRCBwYXNzZWQgaXMgYW55IG9mIElEX0tFWV9JRCwgSURfRlFETiwgSURfUkZD ODIyX0FERFIsIG9yDQo+ICAgICAgSURfREVSX0FTTjFfRE4uDQo+Li4uDQo+LS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPg0KPkFuZCBoZSBwb2ludGVkIG91dCB0aGF0IHRoaXMgYXNrcyBmb3IgbWFuZGF0b3J5IHRv IGltcGxlbWVudGVkIGtleQ0KPnNpemUgZm9yIFJTQSB0byBiZSAxMDI0IG9yIDIwNDgtYml0cy4N Cj4NCj5JdCBpcyBub3QgdXAgdG8gdGhlIGlrZXYyLW1pbmltYWwgdG8gY2hhbmdlIHRoZXNlLCBi dXQgUkZDNDMwN2JpcyBpcw0KPmRpZmZlcmVudCB0aGluZy4NCj4NCj5JLmUuIHNob3VsZCB3ZSBt b2RpZnkgdGhpcyBhbHNvIHdoaWxlIHVwZGF0aW5nIHRoZSBSRkM0MzA3PyBXZSBjb3VsZA0KPmFk ZCBzZWN0aW9uIGFib3V0IHRoZSBtYW5kYXRvcnkgdG8gaW1wbGVtZW50IGF1dGhlbnRpY2F0aW9u IG1ldGhvZHMsDQo+YW5kIHNwZWNpZnkgd2hpY2ggbWV0aG9kcyBhcmUgdG8gYmUgdXNlZCwgZm9y IGV4YW1wbGUgcmVxdWlyZSBSU0Ega2V5DQo+bGVuZ3RocyBvZiAyMDQ4IGJpdHMsIGFuZCBwZXJo YXBzIHNheSB0aGF0IGltcGxlbWVudGF0aW9ucyBTSE9VTEQNCj5zdXBwb3J0IFJTQSBrZXkgbGVu Z3RocyB1cCB0byA0MDk2IGJpdHMuDQoNCisxIGZvciBNVVNUIE5PVCBzdXBwb3J0IGxlc3MgdGhh biAyMDQ4LWJpdCBSU0ENCisxIGZvciBTSE9VTEQvU0hBTEwgc3VwcG9ydCAzMDcyLzQwOTYtYml0 IFJTQQ0KDQoNCj5Gb3IgdGhlIGVsbGlwdGljIGN1cnZlcyB3ZSBtaWdodCB3YW50IHRvIHNheSBz b21ldGhpbmcgYWJvdXQgc2lnbmF0dXJlDQo+YXV0aGVudGljYXRpb24gbWV0aG9kIChSRkMgNzQy NykgYXMgdGhhdCBzdXBwb3J0cyBnZW5lcmljIGVsbGlwdGljDQo+Y3VydmVzIG5vdCBvbmx5IHRo ZSBuaXN0IHZlcnNpb25zLg0KDQpJZiB3ZSBzYXkgc29tZXRoaW5nIGFib3V0IFJTQSB3ZSBzaG91 bGQgc2F5IHNvbWV0aGluZyBhYm91dCBrZXkgbGVuZ3RocyBpbg0KKEVDKURTQSBhcyB3ZWxsLiBB bmQgaWYgd2UgZGlzY3VzcyBhdXRoZW50aWNhdGlvbiB3ZSBzaG91bGQgYWxzbyBzYXkNCnNvbWV0 aGluZyBhYm91dCBTSEEtMS4NCg0KPkFsc28gc2hvdWxkIHdlIHNheSBzb21ldGhpbmcgYWJvdXQN Cj50aGUgUlNBU1NBLVBLQ1MxLXYxXzUgdnMgUlNBU1NBLVBTUz8NCg0KKzEgZm9yIFNIT1VMRCBO T1Qgc3VwcG9ydC91c2UgUEtDUzEtdjFfNQ0KDQoNCj4tLSANCj5raXZpbmVuQGlraS5maQ0KPg0K Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+SVBzZWMg bWFpbGluZyBsaXN0DQo+SVBzZWNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2lwc2VjDQoNCg== From nobody Mon Dec 14 06:46:01 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 580D41A1BF6 for ; Mon, 14 Dec 2015 06:45:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.666 X-Spam-Level: *** X-Spam-Status: No, score=3.666 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, STOX_REPLY_TYPE_WITHOUT_QUOTES=1.757] autolearn=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 ZDqSeT9FEhZX for ; Mon, 14 Dec 2015 06:45:57 -0800 (PST) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (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 2AA3F1A1B3D for ; Mon, 14 Dec 2015 06:45:55 -0800 (PST) Received: by lbpu9 with SMTP id u9so100631193lbp.2 for ; Mon, 14 Dec 2015 06:45:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=KcmtAcfnzJsuJzjC3TfE3oFUYqrpVy/+bFhlsHr/iXw=; b=c5E8bhgS6zuL8wKUTjv2rDcUmJqszoydBfBVQlMLVQEvzhoxKSye4YGVW59lvfimeu Wf+9toYT3MZk+TQYeE1Yg/jbkAATXYKR0k3SBuZpW6onZ3vK2uHAA8p1cwZNt16L1oMY tSDJBZECOwa6mXgpLs7hi92aw/evvEnfqYXs5F9czrbAwe3OkzgJqqsuNgNHUsOqThDB vc8aMP0f6mPhG9aqVmQgmfhoOGmYoHC8ypedT/V/Hn4LwO2EdIBjo9/zWIBkNG0n3pi5 3zfl7DKBO5U+YjhirH/56nJqy83DesXTB6wWmM60HVDg7NKX0ypJoHDAw+FAIOHu8x1m 5+fg== X-Received: by 10.112.170.194 with SMTP id ao2mr13339876lbc.142.1450104353143; Mon, 14 Dec 2015 06:45:53 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id j189sm5654200lfg.46.2015.12.14.06.45.51 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Dec 2015 06:45:52 -0800 (PST) Message-ID: <0929AB361BDD4969BFBECB1DCF365433@buildpc> From: "Valery Smyslov" To: "Tommy Pauly" , "Samy Touati" References: <5666AD1B.6000105@gmail.com> <18BF5929-6C8C-41A5-A3BC-764D3F56B2F3@apple.com> <566746C9.1020202@gmail.com> Date: Mon, 14 Dec 2015 17:46:07 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] TCP Encapsulation draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 14:45:59 -0000 Hi, I have some comments on the TCP Encapsulation draft. 1. The draft assumes that using TCP encapsulation is always pre-configured, i.e. for each peer there is a configuration option with two possible values - either "use traditional UDP transport" or "use TCP (TLS) transport". I think that this is inflexible since network topology can change over time as well as middleboxes' capabilities. Since TCP encapsulation is a "last resort" with a lot of drawbacks, I'd rather make it use only when it is really needed. Granted the use of TCP encapsulation cannot be negotiated, however the case when it is needed can be detected. So, I suggest to add the third option - "try first UDP transport and fall back to TCP (TLS) encapsulation if no response was received". Note, that this behaviour is already defined in the draft when peer's addresses are changed via MOBIKE, I just suggest to make it available from the beginning of SA establishment. 2. Please, emphasize that TCP encapsulation cannot replace traditional transport, otherwise we can run into interoperability problem. Something along the lines: Those implementations that support TCP encapsulation MUST still support traditional transport, defined in [RFC7296] for IKE and in [RFC4303] and [RFC3948] for ESP. 3. The following text in Section 3 is unclear to me: Although a TCP stream may be able to send very long messages, implementations SHOULD limit message lengths to typical UDP datagram ESP payload lengths. I wonder what is a "typical UDP datagram ESP payload lengths"? How implementation could limit upper-level's message length? 4. The draft is silent about AH. I presume AH cannot be used with TCP encapsulation (as it cannot be used with UDP encapsulation), however I think it must be spelled out. 5. For the following text: An unexpected FIN or a RST on the TCP connection may indicate either a loss of connectivity, an attack, or some other error. ... The original initiator (that is, the endpoint that initiated the TCP connection and sent the first IKE_SA_INIT message) is responsible for re- establishing the TCP connection if it is torn down for any unexpected reason. I think this is not enough. Consider the situation when attacker manages to send RST to only one peer, say it be the original responder. In this case the states of the peers become de-syncronized: while the original responder tearns down its TCP session, the original initiator thinks it is up. If the original responder has some data to be sent while the original initiator has no such data, then we have some kind of deadlock. It seems that the original initiator must send keepalive messages with a pretty high frequency whenever it becomes idle. 6. Section 5 allows presence of multiple TCP connections for a single IKE SA, however this is allowed for some corner cases. It is my impression, that in most cases there will be one TCP connection per IKE SA. If it is the case, then some clarification should be added how situations when peer temporarily has more TCP commections per IKE SA are resolved. Consider the example from the comment above, but when RST is sent only to the original initiator. In this case the initiator restores TCP connection, that leads to an existence of 2 TCP connections on the original responder - the old, which is defunct, but the responder thinks it's up, and the newly created. Which connection the responder should use? It seems that some clarification should be added along the lines: If an IKE endpoint receives cryptographically protected message on a new TCP connection, that is different from the TCP connection associated with the IKE/ESP SA the message was received over, the endpoint MUST tear down existing TCP connection and MUST use the new one for their outgoing traffic. I'm not sure this text alignes witth the allowance to have multiple TCP connections per SA, though... 7. I think it's worth to clarify that with TCP encapsulation the IKE SA establishment starts using port 4500 from the very beginning, so no port switching from 500 to 4500 takes place. 8. In my opinion Section 8 is a mess. It mixes up all kinds of keepalive-like messages used for different purposes. First, I don't think NAT keepalive messages are needed for TCP encapsulation. As far as I know NAT boxes keep track of TCP state and keep mapping until TCP is torn down (unlike UDP where no explicit indication of session state exists and therefore it is only determided by existence of traffic). Disclaimer: I'm not an expert in modern NATs and probably things get changed and I'm wrong. In this case the TCP encapsulation of NAT keepalive messages must be described in the document, since they are neither IKE nor ESP messages. Then, there is no such thing as "TCP NAT keepalives". The referenced RFC1122 describes TCP keep-alives (no "NAT"!) and their sole purpose is to allow server to clear up stale TCP connections when clients reboot. RFC1122 never suggested to use them as NAT keepalives (note the recommended default interval for them - no less than 2 hours!). Disclaimer: again, I'm not an expert in modern TCP trends, but if currently TCP keep-alives are used differently, then appropriate source should be referenced. I'm not familiar with TLS keepalives, but I'd rather let TLS along and let it use its mechanisms as specified in TLS RFC, without imposing additional requirements in this document. Conclusion: among the listed only the IKE check liveness messages are relevant to TCP encapsulation. But their usage in this case should be clarified (see my comment #5). 9. Please, add text that some of IKEv2 (and its extensions) mechanisms become useless with TCP encapsulation and MUST NOT (SHOULD NOT?) be used. In particular - cookie has a little value with TCP since it is no longer allows responder to remain stateless. Moreover, TCP handshake determines peer IP address and protects to some extend from spoofing (I assume ISN is unpredictable as it should be). Another thing that becomes useless is sending NAT keepalive messages (but see previous comment). And IKEv2 extension that becomes useless with TCP encapsulation is IKEv2 fragmentation. Regards, Valery Smyslov. From nobody Mon Dec 14 16:29:34 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6751A884C for ; Mon, 14 Dec 2015 16:29:32 -0800 (PST) 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_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 U0kCZpbEP5dA for ; Mon, 14 Dec 2015 16:29:26 -0800 (PST) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 295041A8881 for ; Mon, 14 Dec 2015 16:29:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1450139365; x=2314052965; 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=pxGHvXhm7agX0yS5kzAMOiou7BLkUBv3vkDXXGu9G14=; b=llQe2LdulhgzRACaFUYw4vdNw7RHZmvyWezn4OIAaHz/DVXjrGSY3C66jbn0JIXs EcHRjTrgu4+8F7D6YtIh4CCe41YiZSJ1iM2wwUD352WiU0oElYpfuI35+dBD1LaF 0LWdCyA3Y2AjDIdcB5fxlw/YYDFKN+lQC5pPsSYHJKaDLQOtvBo0ZLdEIcBZS581 xSyMaeNSwgfIARgkl0qCFAXGWrLHJl92JRnZ3f0KYGZDg/cG+I9CK7gKwgqrCQhw XkdtxHP/laOM5wNeXjGToKBeaOWPUK+KngH0tmy82kWfxPjrH4WplIum2jB9J987 L0JUmRsJheND8WdftR1jgA==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id E4.6B.27014.5EE5F665; Mon, 14 Dec 2015 16:29:25 -0800 (PST) X-AuditID: 11973e16-f793c6d000006986-9e-566f5ee55496 Received: from orrisroot.apple.com (orrisroot.apple.com [17.128.115.106]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id 57.01.29392.5EE5F665; Mon, 14 Dec 2015 16:29:25 -0800 (PST) Received: from da0602a-dhcp187.apple.com (da0602a-dhcp187.apple.com [17.226.23.187]) by orrisroot.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0NZD008VWIP07J00@orrisroot.apple.com> for ipsec@ietf.org; Mon, 14 Dec 2015 16:29:25 -0800 (PST) Sender: tpauly@apple.com MIME-version: 1.0 (Mac OS X Mail 10.0 \(3153\)) Content-type: text/plain; charset=utf-8 From: Tommy Pauly X-Priority: 3 In-reply-to: <0929AB361BDD4969BFBECB1DCF365433@buildpc> Date: Mon, 14 Dec 2015 16:29:28 -0800 Content-transfer-encoding: quoted-printable Message-id: References: <5666AD1B.6000105@gmail.com> <18BF5929-6C8C-41A5-A3BC-764D3F56B2F3@apple.com> <566746C9.1020202@gmail.com> <0929AB361BDD4969BFBECB1DCF365433@buildpc> To: Valery Smyslov X-Mailer: Apple Mail (2.3153) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUi2FAYpfs0Lj/MYNYZNYv9W16wOTB6LFny kymAMYrLJiU1J7MstUjfLoEr49q8+2wF+yIrvryYz97A+Mq1i5GTQ0LAROJhw212CFtM4sK9 9WxdjFwcQgJ7GSValp9nhCl69+4VVGI+k8Tj1UcYIZwtTBJ7bj9k6mLk4BAWkJDYvCcRpEFY QEfizX2IqbwC+hLLFv5hAylhFlCXmDIlFyTMJqAicfzbBmaI+bwSM9qfsoDYnALmEksnXWIF sVkEVCXOXPgNNoZZwEpi1dMZULa2xJN3F1hBRvIK2EjMWG4Kcc1NRom+fdvZQGpEgHpvbvsJ NV9W4u3PeUwgRRICa9gk1v97zDaBUXQWkvNmIZw3C8mKBYzMqxiFchMzc3Qz88z1EgsKclL1 kvNzNzGCgn66ndgOxoerrA4xCnAwKvHwLmDODxNiTSwrrsw9xCjNwaIkzvvVDCgkkJ5Ykpqd mlqQWhRfVJqTWnyIkYmDU6qB8XhYVa7QR2nrs8efLmooXcCqd+TnjvnHLDcYrtBZGN34x0Xu Q22gpqAQs117x3IpAfkKdZvjvPMLHv64OmfhnJUmgT/PMZyLS9F9lTnBfOdTnez/D5d8XVh3 arJol+kmnS23b/kfnXM+QWLas48+j95uuhEg03/Ly1VTjN3RPsPu02STlX9mSSixFGckGmox FxUnAgBxZ4LjWwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42IRbCjO0n0alx9mcH+tjMX+LS/YHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcW3efbaCfZEVX17MZ29gfOXaxcjJISFgIvHu3Ss2CFtM4sK9 9UA2F4eQwHwmicerjzBCOFuYJPbcfsjUxcjBISwgIbF5TyJIg7CAjsSb+7fZQWxeAX2JZQv/ sIGUMAuoS0yZkgsSZhNQkTj+bQMzxHxeiRntT1lAbE4Bc4mlky6xgtgsAqoSZy78BhvDLGAl serpDChbW+LJuwusICN5BWwkZiw3hbjmJqNE377tYDeLAPXe3PYTar6sxNuf85gmMArNQnLR LISLZiGZuoCReRWjQFFqTmKlmV5iQUFOql5yfu4mRnCQFkbtYGxYbnWIUYCDUYmHdwFzfpgQ a2JZcWXuIUYJDmYlEd5iC6AQb0piZVVqUX58UWlOavEhxmSgXyYyS4km5wMjKK8k3tDExMDE 2NjM2NjcxJw0YSVxXhUjoBUC6YklqdmpqQWpRTBbmDg4pRoYw+8895W47KR57ckm5m2fVRQb P8ZN9hCYJ7HJ57fxLdMnRmvO5HFUaloF/QzcUaNZ1642U7rjNyNjOfestuOm34481r2t+Inj +weWh2eu/o3VKZo1qd5w1ZzQD/HiZ36EWxmvDntTUjKf86ncjuSSFacle2VFduXr3qp1Xqh5 fa7YtY4le5kmKLEUZyQaajEXFScCAOo9nXaWAgAA Archived-At: Cc: ipsec@ietf.org, Samy Touati Subject: Re: [IPsec] TCP Encapsulation draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 00:29:32 -0000 > On Dec 14, 2015, at 6:46 AM, Valery Smyslov wrote: >=20 > Hi, Hi Valery, Thanks for your comments! Responses inline. >=20 > I have some comments on the TCP Encapsulation draft. >=20 > 1. The draft assumes that using TCP encapsulation is always = pre-configured, > i.e. for each peer there is a configuration option with two possible = values - either "use traditional UDP transport" or "use TCP (TLS) = transport". > I think that this is inflexible since network topology can change = over time > as well as middleboxes' capabilities. Since TCP encapsulation is = a "last resort" with a lot of drawbacks, I'd rather make it use only = when it is really needed. Granted the use of TCP encapsulation > cannot be negotiated, however the case when it is needed can be = detected. > So, I suggest to add the third option - "try first UDP transport and = fall back > to TCP (TLS) encapsulation if no response was received". Note, that = this behaviour > is already defined in the draft when peer's addresses are changed = via MOBIKE, I just suggest to make it available from the beginning of = SA establishment. =20 The idea of using TCP as the fallback from UDP is exactly what the = entire draft is about. The preconfiguration is not whether to always use = TCP, but whether to use TCP once UDP fails, and upon which port. Since = the entire idea of using TCP is predicated on the idea that UDP was = already blocked on a previous attempt, this must be preconfigured. TCP is only used when UDP fails: "If both of the other two methods are not available or appropriate, both IKEv2 negotiation packets as well as ESP packets can be sent over a single TCP connection to the peer." As it says in the configuration section, UDP is the preferred transport:=20= "Since TCP encapsulation of IKEv2 and IPSec packets adds overhead and has potential performance trade-offs compared to direct or UDP- encapsulated tunnels (as described in Performance Considerations, = Section 7),=20 implementations SHOULD prefer IKEv2 negotiation over UDP.=E2=80=9D We can make it more explicit that UDP should be tried first, but that is = certainly the intent. > 2. Please, emphasize that TCP encapsulation cannot replace traditional > transport, otherwise we can run into interoperability problem. = Something along the lines: >=20 > Those implementations that support TCP encapsulation MUST still = support traditional transport, defined in [RFC7296] for IKE and = in [RFC4303] and > [RFC3948] for ESP. Sure, although I think clarifying (1) that UDP is always tried first = should cover this as well. >=20 > 3. The following text in Section 3 is unclear to me: >=20 > Although a TCP stream may be able to send very long messages, > implementations SHOULD limit message lengths to typical UDP = datagram > ESP payload lengths. =20 > I wonder what is a "typical UDP datagram ESP payload lengths"? > How implementation could limit upper-level's message length?=20 Based on discussion on the list, we decided not to specify a specific = value. The point is to not send very large messages in the TCP stream, = since they will often be sent back into a traditional unix networking = kernel once decrypted. The message length can be simply limited by = setting the MTU to a normal value on the virtual interface being used = for the VPN. > 4. The draft is silent about AH. I presume AH cannot be used with = TCP encapsulation (as it cannot be used with UDP encapsulation), > however I think it must be spelled out. Okay, we can say this only applies to ESP, not AH. >=20 > 5. For the following text: >=20 > An unexpected FIN or a RST on the TCP connection may indicate = either > a loss of connectivity, an attack, or some other error. ... The = original > initiator (that is, the endpoint that initiated the TCP = connection > and sent the first IKE_SA_INIT message) is responsible for re- > establishing the TCP connection if it is torn down for any = unexpected > reason.=20 > I think this is not enough. Consider the situation when attacker = manages to > send RST to only one peer, say it be the original responder. In this = case > the states of the peers become de-syncronized: while the original = responder > tearns down its TCP session, the original initiator thinks it is up. > If the original responder has some data to be sent while the = original initiator has no such data, then we have some kind of = deadlock. > It seems that the original initiator must send keepalive messages > with a pretty high frequency whenever it becomes idle. RST attacks are inherent to TCP. What do you propose on top of this? I = don=E2=80=99t think we want to recommend for more frequent keepalives, = necessarily. Note that any time the client will try to send any traffic = (this is any ESP traffic, so it will probably be fairly quickly), the = connection will get a RST if the server thinks the port is no longer = open. >=20 > 6. Section 5 allows presence of multiple TCP connections for a single = IKE SA, > however this is allowed for some corner cases. It is my impression, = that > in most cases there will be one TCP connection per IKE SA. If it = is the case, then some clarification should be added how > situations when peer temporarily has more TCP commections per > IKE SA are resolved. Consider the example from the comment above, = but > when RST is sent only to the original initiator. In this case the = initiator > restores TCP connection, that leads to an existence of 2 TCP > connections on the original responder - the old, which is defunct, > but the responder thinks it's up, and the newly created. Which = connection the responder should use? It seems that > some clarification should be added along the lines: >=20 > If an IKE endpoint receives cryptographically protected = message on a new TCP connection, that is different from the TCP = connection associated with the IKE/ESP > SA the message was received over, the endpoint MUST > tear down existing TCP connection and MUST use the new > one for their outgoing traffic. >=20 > I'm not sure this text alignes witth the allowance to have > multiple TCP connections per SA, though=E2=80=A6 I think that recommendation makes sense. We=E2=80=99ll work on it and = add to the next version. >=20 > 7. I think it's worth to clarify that with TCP encapsulation the IKE = SA > establishment starts using port 4500 from the very beginning, so = no port switching from 500 to 4500 takes place. It=E2=80=99s not necessarily port 4500 at all! In fact, it will likely = not be. But that is true that port switching does not take place. We can = add a line to re-iterate that. >=20 > 8. In my opinion Section 8 is a mess. It mixes up all kinds of > keepalive-like messages used for different purposes.=20 > First, I don't think NAT keepalive messages are needed > for TCP encapsulation. As far as I know NAT boxes keep track > of TCP state and keep mapping until TCP is torn down > (unlike UDP where no explicit indication of session state exists > and therefore it is only determided by existence of traffic). > Disclaimer: I'm not an expert in modern NATs and probably > things get changed and I'm wrong. In this case the TCP encapsulation = of NAT keepalive messages must be described in the document, > since they are neither IKE nor ESP messages. > Then, there is no such thing as "TCP NAT keepalives". The = referenced RFC1122 describes TCP keep-alives (no "NAT"!) > and their sole purpose is to allow server to clear up stale > TCP connections when clients reboot. RFC1122 never suggested > to use them as NAT keepalives (note the recommended default = interval for them - no less than 2 hours!). Disclaimer: again, > I'm not an expert in modern TCP trends, but if currently TCP > keep-alives are used differently, then appropriate source > should be referenced. >=20 > I'm not familiar with TLS keepalives, but I'd rather let TLS > along and let it use its mechanisms as specified in TLS RFC, > without imposing additional requirements in this document. >=20 > Conclusion: among the listed only the IKE check liveness messages > are relevant to TCP encapsulation. But their usage in this case = should be clarified (see my comment #5). I disagree that the other keep alive types are not relevant. This = section is simply a list of "mechanisms [that] may be employed=E2=80=9D = for keepalives, and it is useful for an implementer to know which keep = alive mechanisms may be taking place on their connection. It is very = important that TCP encapsulation can be implemented as a layer = transparent to existing TCP, TLS, and ESP implementations. By default, = these layers may have keepalives of their own. The ESP implementation in = a kernel may not know that the traffic will be sent over a TCP flow, and = if MOBIKE is being used, it may switch between UDP and TCP on different = networks. Therefore, we should not recommend that NAT keepalives be = disabled. We can remove the spurious =E2=80=9CNAT=E2=80=9D qualifier from the TCP = keepalives. >=20 > 9. Please, add text that some of IKEv2 (and its extensions) mechanisms > become useless with TCP encapsulation and MUST NOT (SHOULD NOT?) > be used. In particular - cookie has a little value with TCP since it = is no longer allows responder to remain stateless. Moreover, TCP = handshake determines > peer IP address and protects to some extend from spoofing (I assume = ISN > is unpredictable as it should be). Another thing that becomes = useless is sending NAT keepalive messages (but see previous comment). = And IKEv2 extension that becomes useless with TCP encapsulation is = IKEv2 fragmentation. I do not think we should recommend that any of these extensions MUST NOT = be used, specifically since TCP encapsulation is something done as = fallback for connections in which UDP is blocked, and in the case of = MOBIKE, may be used on a connection that uses UDP on other networks. - Cookies: the TCP connection here should not be considered =E2=80=98state= =E2=80=99 from the perspective of IKE. The TCP connection is independent = of the IKE sessions. It still may be useful to keep the cookie = mechanism. - We already address NAT keepalives: "If TCP keep-alives are used, IPSec = ESP NAT keep-alives may be considered redundant and can safely be = disabled.=E2=80=9D - Fragmentation is still useful, depending on the implementation. One = way of implementing is by taking the TCP messages, re-encapsulating them = as traditional UDP, and forwarding them onto a legacy stack. There is = also the consideration of MOBIKE=E2=80=94we want to negotiate = fragmentation support in case we switch back to a network that supports = UDP! Thanks for your time looking at this! Tommy >=20 > Regards, > Valery Smyslov. >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Dec 15 00:16:10 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC0E1A1A66 for ; Tue, 15 Dec 2015 00:16:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.791 X-Spam-Level: X-Spam-Status: No, score=-0.791 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_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=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 UyuZRDXJeua2 for ; Tue, 15 Dec 2015 00:16:07 -0800 (PST) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::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 A02BF1A1A6F for ; Tue, 15 Dec 2015 00:16:06 -0800 (PST) Received: by mail-lb0-x235.google.com with SMTP id u9so772321lbp.2 for ; Tue, 15 Dec 2015 00:16:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=rMw4XFELqqZVtra6dl8l1j0Bf8EtXxCYtiHsVJEd0Z4=; b=IF+LGDNrCbsxoK/ISeAxBjAGzMqlFO1yx02+YutEsz87h1iWz4g9TemAd2trFw/p2D AatT4lZNWb6pIYDCJJ7S2qmyYOzhQrXfJhYfLV/ApWUcMeTpn+ZuvYmlBlRftKqXC9yU 5aoK/lf1UfGf7qumeWKgvzbxDrfb5OhLq6EV1OKqkZFSMpMRrzZtEf/i4pXzeLuo/WH2 q/yme7h7xUM7cK5HjxE69M6Sv5Mzj3YTNR0JqnxEYCbfMXMRgFdUdSK5easkclVucbwh 4s2zN7MnOZT9bvoaiAvVHp7jRCPhMZlCyyi62frGxua14VbKV8rrJbQO3jssi0uV4YR0 60Kg== X-Received: by 10.112.141.131 with SMTP id ro3mr15643121lbb.106.1450167364848; Tue, 15 Dec 2015 00:16:04 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id m189sm28346lfm.21.2015.12.15.00.16.03 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Dec 2015 00:16:04 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Tommy Pauly" References: <5666AD1B.6000105@gmail.com> <18BF5929-6C8C-41A5-A3BC-764D3F56B2F3@apple.com> <566746C9.1020202@gmail.com> <0929AB361BDD4969BFBECB1DCF365433@buildpc> Date: Tue, 15 Dec 2015 11:16:18 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: ipsec@ietf.org, Samy Touati Subject: Re: [IPsec] TCP Encapsulation draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 08:16:09 -0000 Hi Tommy, thank you for the answers. See my comments inline. > The idea of using TCP as the fallback from UDP is exactly what the entire draft is about. > The preconfiguration is not whether to always use TCP, but whether to use TCP once > UDP fails, and upon which port. Since the entire idea of using TCP is predicated on the > idea that UDP was already blocked on a previous attempt, this must be preconfigured. > > TCP is only used when UDP fails: > "If both of the other two methods are not > available or appropriate, both IKEv2 negotiation packets as > well as ESP packets can be sent over a single TCP connection to > the peer." > > As it says in the configuration section, UDP is the preferred transport: > > "Since TCP encapsulation of IKEv2 and IPSec packets adds overhead and > has potential performance trade-offs compared to direct or UDP- > encapsulated tunnels (as described in Performance Considerations, Section 7), > implementations SHOULD prefer IKEv2 negotiation over UDP.” > > We can make it more explicit that UDP should be tried first, but that is certainly the intent. Yes, please. The current text is not very explicit about that, at least in me reading. >> Those implementations that support TCP encapsulation MUST still support >> traditional transport, defined in [RFC7296] for IKE and in [RFC4303] and >> [RFC3948] for ESP. > > Sure, although I think clarifying (1) that UDP is always tried first should cover this as well. Agree. >> Although a TCP stream may be able to send very long messages, >> implementations SHOULD limit message lengths to typical UDP datagram >> ESP payload lengths. >> I wonder what is a "typical UDP datagram ESP payload lengths"? >> How implementation could limit upper-level's message length? > > Based on discussion on the list, we decided not to specify a specific value. The point is to not send very > large messages in the TCP stream, since they will often be sent back into a traditional unix > networking kernel once decrypted. The message length can be simply limited by setting the > MTU to a normal value on the virtual interface being used for the VPN. I think it would be benefitical for implemeters if you clarify this giving them some concrete guidelines. >> An unexpected FIN or a RST on the TCP connection may indicate either >> a loss of connectivity, an attack, or some other error. ... The original >> initiator (that is, the endpoint that initiated the TCP connection >> and sent the first IKE_SA_INIT message) is responsible for re- >> establishing the TCP connection if it is torn down for any unexpected >> reason. >> I think this is not enough. Consider the situation when attacker manages to >> send RST to only one peer, say it be the original responder. In this case >> the states of the peers become de-syncronized: while the original responder >> tearns down its TCP session, the original initiator thinks it is up. >> If the original responder has some data to be sent while the original initiator has no such data, then we have >> some kind of deadlock. >> It seems that the original initiator must send keepalive messages >> with a pretty high frequency whenever it becomes idle. > > RST attacks are inherent to TCP. What do you propose on top of this? I don’t think we want > to recommend for more frequent keepalives, necessarily. Note that any time the client will > try to send any traffic (this is any ESP traffic, so it will probably be fairly quickly), > the connection will get a RST if the server thinks the port is no longer open. The situation described above is quite real. Suppose the client is downloading a large file from the server. In this case the server always has data to be sent, while the client only responses with ACKs. If the client receives no new data it just waits. Of course if it has something to send, the TCP connection will be restored. That's why it is probably worth to send liveness check messages from the initiator to the responder if there is no incoming traffic for some period of time (say 10-20 seconds) and the endpoint has no data to send to the peer. Note, that it is a bit different from how liveness check messages are supposed to be used in IKEv2, where liveness check should be done if there is no incoming traffic for some period of time AND if the endpoint is about to send new data to the peer. >> 7. I think it's worth to clarify that with TCP encapsulation the IKE SA >> establishment starts using port 4500 from the very beginning, so no port switching from 500 to 4500 takes place. > > It’s not necessarily port 4500 at all! In fact, it will likely not be. But that is true that port switching does not > take place. We can add a line to re-iterate that. Oh, I see that the port is not necessary 4500. However I think the clarification that no port switching takes place would be useful. >> Conclusion: among the listed only the IKE check liveness messages >> are relevant to TCP encapsulation. But their usage in this case should be clarified (see my comment #5). > > I disagree that the other keep alive types are not relevant. This section is simply a list > of "mechanisms [that] may be employed” for keepalives, and it is useful for an implementer > to know which keep alive mechanisms may be taking place on their connection. >From my naive :-) literal reading the section lists the keepalive methods that are available for the implementation to choose from: It is up to the implementation to decide which keepalives are appropriate for TCP-encapsulated connections. So, I read that as the implementations should be aware of all these methods and use an appropriate one. But this reading differs from your clarification below: > It is very important > that TCP encapsulation can be implemented as a layer transparent to existing TCP, TLS, and ESP > implementations. By default, these layers may have keepalives of their own. I agree that layer separation is important, so the only available keepalives for the IPsec layer are NAT keepalives and liveness check messages. The other methods are irrelevant here. An implementation can be aware of their an existance, but usually cannot control them. I think it must be clarified. > The ESP implementation > in a kernel may not know that the traffic will be sent over a TCP flow, and if MOBIKE is being used, > it may switch between UDP and TCP on different networks. Therefore, we should not recommend > that NAT keepalives be disabled. Well, I think that IPsec level must always know what encapsulation is currently active and use NAT keepalives only when UDP encapsulation takes place. For example, it doesn't send NAT keepalives if "direct" encapsulation is used. In any case, if for the purposes of simplicity the draft allowed an implementation to send NAT keepalives in case of TCP encapsulation, then their layout and processing should have been described (a la Sections 3.1 and 3.2). And in this case the text from Section 3: In order to encapsulate IKEv2 and ESP messages within a stream (which may be raw TCP, or TLS over TCP), a 32-bit length field precedes every message. If the first 32-bits of the message are zeros (a Non- ESP Marker), then the contents comprise an IKEv2 message. Otherwise, the contents comprise an ESP message. is not correct, since NAT keepalives are neigther IKE nor ESP messages. > We can remove the spurious “NAT” qualifier from the TCP keepalives. OK. >> 9. Please, add text that some of IKEv2 (and its extensions) mechanisms >> become useless with TCP encapsulation and MUST NOT (SHOULD NOT?) >> be used. In particular - cookie has a little value with TCP since it is no longer >> allows responder to remain stateless. Moreover, TCP handshake determines >> peer IP address and protects to some extend from spoofing (I assume ISN >> is unpredictable as it should be). Another thing that becomes useless is >> sending NAT keepalive messages (but see previous comment). >> And IKEv2 extension that becomes useless with TCP encapsulation is >> IKEv2 fragmentation. > > I do not think we should recommend that any of these extensions MUST NOT be used, Note, that I've also included "SHOULD NOT" as an alternative since MUST NOT is probably too strong. > specifically since TCP encapsulation is something done as fallback for connections in which > UDP is blocked, and in the case of MOBIKE, may be used on a connection that uses UDP > on other networks. > - Cookies: the TCP connection here should not be considered ‘state’ from the perspective of IKE. > The TCP connection is independent of the IKE sessions. It still may be useful to keep the cookie mechanism. Well, I see the only useful application for the cookie in case of TCP encapsulation - if puzzle mechanism is adopted then the cookie must be used even in this case. > - We already address NAT keepalives: "If TCP keep-alives are used, IPSec ESP NAT keep-alives may be > considered redundant and can safely be disabled.” > - Fragmentation is still useful, depending on the implementation. One way of implementing is by taking > the TCP messages, re-encapsulating them as traditional UDP, and forwarding them onto a legacy stack. > There is also the consideration of MOBIKE—we want to negotiate fragmentation support in case we > switch back to a network that supports UDP! I think that all the mechanisms that seem to become unnecessary with TCP encapsulation must be separately discussed in the document. There must be some text describing under which circumstances these mechanisms are still useful and when it is safe to abandon them. I don't insist on MUST NOT (or SHOULD NOT), but some guidlines must be given, otherwise implementers will wonder: why should we spent resources doing useless things. Thank you, Valery. From nobody Tue Dec 15 04:18:25 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F751A884D for ; Tue, 15 Dec 2015 04:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=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 qnUI_Vy-Ij49 for ; Tue, 15 Dec 2015 04:18:20 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 1813E1A884B for ; Tue, 15 Dec 2015 04:18:19 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.1/8.14.8) with ESMTPS id tBFCIGH5019938 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 15 Dec 2015 14:18:16 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.1/8.14.8/Submit) id tBFCIGrp023455; Tue, 15 Dec 2015 14:18:16 +0200 (EET) Message-ID: <22128.1279.575334.647846@fireball.acr.fi> Date: Tue, 15 Dec 2015 14:18:07 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="eaQlR3W0/r" Content-Transfer-Encoding: 7bit From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 2 min X-Total-Time: 2 min Archived-At: Subject: [IPsec] FWD from Tero Kivinen: [IANA #879113] General Request for Assignment (ikev2-parameters) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 12:18:22 -0000 --eaQlR3W0/r Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit FYI, I just rejected the DEVICE_IDENTITY configuration payload attribute request for IKEv2 because of following reasons. --eaQlR3W0/r Content-Type: message/rfc822 Content-Description: forwarded message Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <22128.1130.703040.132526@fireball.acr.fi> In-Reply-To: References: <201511050932.tA59WlrY009376@smtp01.icann.org> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) From: Tero Kivinen To: iana-prot-param-comment@iana.org Subject: [IANA #879113] General Request for Assignment (ikev2-parameters) Date: Tue, 15 Dec 2015 14:15:38 +0200 Michelle Cotton via RT writes: > I'm sending this request to you for expert review. > If you could reply back before or by 23 November 2015 that would be > most appreciated.\ Sorry for being late for this reply, but I have been quite busy last few months. > On Thu Nov 05 09:32:49 2015, frederic.firmin@etsi.org wrote: > > > > Contact Name: > > Frederic Firmin > > > > Contact Email: > > frederic.firmin@etsi.org > > > > Type of Assignment: > > New item in the "IKEv2 Configuration Payload Attribute Types" of the > > "Internet Key Exchange Version 2 (IKEv2) Parameters" as shown at > > http://www.iana.org/assignments/ikev2-parameters/ikev2- > > parameters.xhtml#ikev2-parameters-21 and as specified in IETF RFC 4306 > > and updated by IETF RFC 5996 and IETF RFC 7296. > > > > Registry: > > The "IKEv2 Configuration Payload Attribute Types" of the "Internet Key > > Exchange Version 2 (IKEv2) Parameters" as shown at > > http://www.iana.org/assignments/ikev2-parameters/ikev2- > > parameters.xhtml#ikev2-parameters-21 and as specified in IETF RFC 4306 > > and updated by IETF RFC 5996 and IETF RFC 7296. > > > > Description: > > This IKEv2 attribute is used to provide device identity. > > > > Additional Info: > > IETF RFC 4306 defines the registry for the "IKEv2 Configuration > > Payload Attribute Types". IETF RFC 7296 and IETF RFC 5996 refer to > > IETF RFC 4306 for the definition of the registry. > > > > The following attribute is requested to be registered: > > - value: (number to be assigned by IANA) > > - attribute type: DEVICE_IDENTITY > > - multi-valued: no > > - length: 1 or more octets > > - reference: 24.302 13.3.0 http://www.3gpp.org/ftp/Specs/html- > > info/24302.htm This assignment is problematic. If I have understood correclty this will use configuration payloads in non-standard way, i.e. in way where it has not been used before. Normally client requests parameters by sending CFG_REQUEST, and server replies values back using CFG_REPLY. In this case if I have understood correctly the server sends CFG_REPLY back asking for client provide the DEVICE_IDENTITY. The RFC7296 says that "In variations of the protocol where there are multiple IKE_AUTH exchanges, the CP payloads MUST be inserted in the messages containing the SA payloads." (RFC7296 section 2.19). This means that CP(CFG_REPLY) is in the last IKE_AUTH, i.e. after the EAP authentication is finished. The 24302-d30 section 7.2 seems to indicate that we send CFG_REPLY back during the EAP and IKE_AUTH exchanges, and then do second CFG_REQEST after that. This is against the RFC7296, as the first CFG_REQUEST already contains the IP-address assingment request, and its CFG_REPLY MUST be in the last IKE_AUTH. Also the DEVICE_IDENTITY is attribute that is flowing in wrong direction. I.e. the CFG_REQUEST/CFG_REPLY is meant to be working so that CFG_REQUEST is used by the initiator to request something and CFG_REPLY is used by responder to reply those configuration parameters. In this case the responder is requesting the initiator to provide some information. Also DEVICE_IDENTITY has nothing to do with the configurations of the devices, and is not needed by the IKE or the networks stack to create the IKEv2 tunnel. It does not belong to the configuration payloads. As this is also completely untrusted, and provided just for the information for the server side, I think it would be better to use Notify payloads to send this information. I.e. allocate status notification payload for IMEI and another one for IMEISV, and require that clients send those notifications during the IKE_AUTH exchange. -- kivinen@iki.fi --eaQlR3W0/r-- From nobody Tue Dec 15 05:36:41 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE0E1A8952 for ; Tue, 15 Dec 2015 05:36:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=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 4GFBdvP-vAGZ for ; Tue, 15 Dec 2015 05:36:38 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 9D9B01A894F for ; Tue, 15 Dec 2015 05:36:37 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.1/8.14.8) with ESMTPS id tBFDaXBt021626 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 15 Dec 2015 15:36:33 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.1/8.14.8/Submit) id tBFDaXaN025016; Tue, 15 Dec 2015 15:36:33 +0200 (EET) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="pFldRXreRG" Content-Transfer-Encoding: 7bit Message-ID: <22128.5985.479575.552797@fireball.acr.fi> Date: Tue, 15 Dec 2015 15:36:33 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: Subject: [IPsec] FWD from Tero Kivinen: [IANA #879114] General Request for Assignment (ikev2-parameters) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 13:36:40 -0000 --pFldRXreRG Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit FYI, here is another request and my reply to that. --pFldRXreRG Content-Type: message/rfc822 Content-Description: forwarded message Content-Transfer-Encoding: 7bit CONTENT-TRANSFER-ENCODING: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <22128.3526.783785.55445@fireball.acr.fi> In-Reply-To: References: <201511050934.tA59Yfo9009414@smtp01.icann.org> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) From: Tero Kivinen To: iana-prot-param-comment@iana.org Subject: [IANA #879114] General Request for Assignment (ikev2-parameters) Date: Tue, 15 Dec 2015 14:55:34 +0200 Michelle Cotton via RT writes: > On Thu Nov 05 09:34:43 2015, frederic.firmin@etsi.org wrote: > >=20 > > Contact Name: > > Frederic Firmin > >=20 > > Contact Email: > > frederic.firmin@etsi.org > >=20 > > Type of Assignment: > > New item in the "IKEv2 Configuration Payload Attribute Types" of th= e > > "Internet Key Exchange Version 2 (IKEv2) Parameters" as shown at > > http://www.iana.org/assignments/ikev2-parameters/ikev2- > > parameters.xhtml#ikev2-parameters-21 and as specified in IETF RFC 4= 306 > > and updated by IETF RFC 5996 and IETF RFC 7296. > >=20 > > Registry: > > The "IKEv2 Configuration Payload Attribute Types" of the "Internet = Key > > Exchange Version 2 (IKEv2) Parameters" as shown at > > http://www.iana.org/assignments/ikev2-parameters/ikev2- > > parameters.xhtml#ikev2-parameters-21 and as specified in IETF RFC 4= 306 > > and updated by IETF RFC 5996 and IETF RFC 7296. > >=20 > > Description: > > This IKEv2 attribute is used to provide indication of UE supporting= > > re-selection P-CSCF. > >=20 > > Additional Info: > > IETF RFC 4306 defines the registry for the "IKEv2 Configuration > > Payload Attribute Types". IETF RFC 7296 and IETF RFC 5996 refer to > > IETF RFC 4306 for the definition of the registry. > > The following attribute is requested to be registered: > > - value: (number to be assigned by IANA) > > - attribute type: P-CSCF=5FRESELECTION=5FSUPPORT > > - multi-valued: no > > - length: 1 octet > > - reference: http://www.3gpp.org/ftp/Specs/html-info/24302.ht= m This also have some problems. This is one way indication from the client to the server, this is not configuration value that the client requests from the server. Also it is not clear what this parameter means. The section 7.2.2 of 24320-d30 says: =09If the UE supports P-CSCF restoration extension for untrusted =09WLAN as specified in 3GPP=A0TS=A023.380=A0[66], the UE shall send =09its capability indication of the support of P-CSCF restoration =09to the ePDG by including the P-CSCF=5FRESELECTION=5FSUPPORT =09attribute in the CFG=5FREQUEST Configuration Payload within the =09IKE=5FAUTH request message. The P-CSCF=5FRESELECTION=5FSUPPORT =09attribute content is defined in subclause=A08.2.4.2. i.e. it seems this reSELECTION support attribute is used to indicate whether reSTORATION is supported=3F I do not know where this attribute affects, is it something that affects the configuration of the devices, or is just indication from the client to the server indicating that client supports some features (in which case it might be better to indicate that in notify payload).=20 --=20 kivinen@iki.fi --pFldRXreRG Content-Type: text/plain; charset=us-ascii Content-Description: .signature Content-Transfer-Encoding: 7bit -- kivinen@iki.fi --pFldRXreRG-- From nobody Tue Dec 15 05:38:37 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA7C1A894F for ; Tue, 15 Dec 2015 05:38:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=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 UgobVHmL-FgE for ; Tue, 15 Dec 2015 05:38:34 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 227851A8952 for ; Tue, 15 Dec 2015 05:38:33 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.1/8.14.8) with ESMTPS id tBFDcWHw016133 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 15 Dec 2015 15:38:32 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.1/8.14.8/Submit) id tBFDcWMG021474; Tue, 15 Dec 2015 15:38:32 +0200 (EET) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="2kIXTdCFKB" Content-Transfer-Encoding: 7bit Message-ID: <22128.6104.21984.375282@fireball.acr.fi> Date: Tue, 15 Dec 2015 15:38:32 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 2 min Archived-At: Subject: [IPsec] FWD from Tero Kivinen: [IANA #879115] General Request for Assignment (ikev2-parameters) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 13:38:35 -0000 --2kIXTdCFKB Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit FYI, and this is the last one. I think 3GPP should have someone who knows bit more of IPsec and IKEv2, when they are trying to add things to IKEv2. It would be better to get comments how they should do things earlier than in the IANA allocation phase. --2kIXTdCFKB Content-Type: message/rfc822 Content-Description: forwarded message Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <22128.4228.464197.998746@fireball.acr.fi> In-Reply-To: References: <201511050935.tA59ZSgV009458@smtp01.icann.org> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) From: Tero Kivinen To: iana-prot-param-comment@iana.org Subject: [IANA #879115] General Request for Assignment (ikev2-parameters) Date: Tue, 15 Dec 2015 15:07:16 +0200 Michelle Cotton via RT writes: > On Thu Nov 05 09:35:29 2015, frederic.firmin@etsi.org wrote: > > > > Contact Name: > > Frederic Firmin > > > > Contact Email: > > frederic.firmin@etsi.org > > > > Type of Assignment: > > New item in the "IKEv2 Configuration Payload Attribute Types" of the > > "Internet Key Exchange Version 2 (IKEv2) Parameters" as shown at > > http://www.iana.org/assignments/ikev2-parameters/ikev2- > > parameters.xhtml#ikev2-parameters-21 and as specified in IETF RFC 4306 > > and updated by IETF RFC 5996 and IETF RFC 7296. > > > > Registry: > > The "IKEv2 Configuration Payload Attribute Types" of the "Internet Key > > Exchange Version 2 (IKEv2) Parameters" as shown at > > http://www.iana.org/assignments/ikev2-parameters/ikev2- > > parameters.xhtml#ikev2-parameters-21 and as specified in IETF RFC 4306 > > and updated by IETF RFC 5996 and IETF RFC 7296. > > > > Description: > > This IKEv2 attribute is used to indicate establishment for emergency > > session. > > > > Additional Info: > > IETF RFC 4306 defines the registry for the "IKEv2 Configuration > > Payload Attribute Types". IETF RFC 7296 and IETF RFC 5996 refer to > > IETF RFC 4306 for the definition of the registry. > > The following attribute is requested to be registered: > > - value: (number to be assigned by IANA) > > - attribute type: EMERGENCY_IND > > - multi-valued: no > > - length: 0 octets > > - reference: http://www.3gpp.org/ftp/Specs/html-info/24302.htm Again this has similar problems. This is not a configuration value. This is something that is also needed before the configuration request is even parsed. Configuration payloads are usually only processed after the full authentication is done and when the final IKE_AUTH message is to be sent back, as that is place where we have all the information to provide the reply, i.e. in that case it might be too late to change something like how the IDr fields are used. Section 7.4.4 of 24302-d30 says that if this attribute is included, then APN information in the IDr is ignored. It actually would be much better to use some special string for the IDr in the IKE_AUTH request to indicate that we are doing emergency session establishment. I.e. IDr is supposed to tell which service we want to connect. If that value would be for example string "EMERGENCY" or similar than that could be used to select suitable IPsec policy based on fact that we are doing the emergency session establishment, and it would be clear separation form the normal session establishment. -- kivinen@iki.fi --2kIXTdCFKB Content-Type: text/plain; charset=us-ascii Content-Description: .signature Content-Transfer-Encoding: 7bit -- kivinen@iki.fi --2kIXTdCFKB-- From nobody Tue Dec 15 05:55:54 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8361A8973 for ; Tue, 15 Dec 2015 05:55:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 OkWe8L5XocSt for ; Tue, 15 Dec 2015 05:55:49 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 9A9291A8925 for ; Tue, 15 Dec 2015 05:55:43 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id n186so95746844wmn.0 for ; Tue, 15 Dec 2015 05:55:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=/t36/C05O3L2ETGjoalY6VNb82bbcp4g1D2/CYHmfMM=; b=EFFbco1yoLDngxW3e1yf9ufnm45H8Suqwr00WhcCiSwaK6Taaj23EmZhy0gHqzcYSc bck6miTn5wonjee6e2C7DZOZeLhbwDizcG2IhySxd9sKHkKVKaLD82S4c1yawHpOQuPt flHFpqMhZAYw9Hr/lonhEimc+HsAYjh+f2jtS3X1XL7+dcdXkb4azV2EjhKRpzNNleyf mNO8vrPvTreTFH8/uEZL2nvqu80ILUiA3bbDuAdV5Xw1t2brMf83IxCAd5OiEwp4Dtej D17gDPdnpFG0L0kKaf5hR/UyYHUpruLMb43cZoBX/hROHXasUTfcrjDbzuHTV68YZEFL 0Prg== X-Received: by 10.28.93.144 with SMTP id r138mr5171123wmb.84.1450187742201; Tue, 15 Dec 2015 05:55:42 -0800 (PST) Received: from [172.24.251.233] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id cw3sm1535201wjb.26.2015.12.15.05.55.40 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 15 Dec 2015 05:55:41 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_457FB269-7385-4168-BA12-E4CE1EBC8033" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: <22128.1279.575334.647846@fireball.acr.fi> Date: Tue, 15 Dec 2015 15:55:39 +0200 Message-Id: <86D711D8-1BA4-4CF3-9105-463ED56E89EA@gmail.com> References: <22128.1279.575334.647846@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3112) Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] FWD from Tero Kivinen: [IANA #879113] General Request for Assignment (ikev2-parameters) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 13:55:52 -0000 --Apple-Mail=_457FB269-7385-4168-BA12-E4CE1EBC8033 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Tero I realise you are not the one to ask about this, but why not use = CFG_SET? =20 This IMEI information is about as trustworthy as the = =E2=80=9CAPPLICATION_VERSION=E2=80=9D type. Yoav > On 15 Dec 2015, at 2:18 PM, Tero Kivinen wrote: >=20 > FYI, I just rejected the DEVICE_IDENTITY configuration payload > attribute request for IKEv2 because of following reasons. >=20 >=20 > From: Tero Kivinen > Subject: [IANA #879113] General Request for Assignment = (ikev2-parameters) > Date: 15 December 2015 at 2:15:38 PM GMT+2 > To: iana-prot-param-comment@iana.org >=20 >=20 > Michelle Cotton via RT writes: >> I'm sending this request to you for expert review. >> If you could reply back before or by 23 November 2015 that would be >> most appreciated.\=20 >=20 > Sorry for being late for this reply, but I have been quite busy last > few months.=20 >=20 >> On Thu Nov 05 09:32:49 2015, frederic.firmin@etsi.org wrote: >>>=20 >>> Contact Name: >>> Frederic Firmin >>>=20 >>> Contact Email: >>> frederic.firmin@etsi.org >>>=20 >>> Type of Assignment: >>> New item in the "IKEv2 Configuration Payload Attribute Types" of the >>> "Internet Key Exchange Version 2 (IKEv2) Parameters" as shown at >>> http://www.iana.org/assignments/ikev2-parameters/ikev2- >>> parameters.xhtml#ikev2-parameters-21 and as specified in IETF RFC = 4306 >>> and updated by IETF RFC 5996 and IETF RFC 7296. >>>=20 >>> Registry: >>> The "IKEv2 Configuration Payload Attribute Types" of the "Internet = Key >>> Exchange Version 2 (IKEv2) Parameters" as shown at >>> http://www.iana.org/assignments/ikev2-parameters/ikev2- >>> parameters.xhtml#ikev2-parameters-21 and as specified in IETF RFC = 4306 >>> and updated by IETF RFC 5996 and IETF RFC 7296. >>>=20 >>> Description: >>> This IKEv2 attribute is used to provide device identity. >>>=20 >>> Additional Info: >>> IETF RFC 4306 defines the registry for the "IKEv2 Configuration >>> Payload Attribute Types". IETF RFC 7296 and IETF RFC 5996 refer to >>> IETF RFC 4306 for the definition of the registry. >>>=20 >>> The following attribute is requested to be registered: >>> - value: (number to be assigned by IANA) >>> - attribute type: DEVICE_IDENTITY >>> - multi-valued: no >>> - length: 1 or more octets >>> - reference: 24.302 13.3.0 http://www.3gpp.org/ftp/Specs/html- >>> info/24302.htm >=20 > This assignment is problematic.=20 >=20 > If I have understood correclty this will use configuration payloads in > non-standard way, i.e. in way where it has not been used before. >=20 > Normally client requests parameters by sending CFG_REQUEST, and server > replies values back using CFG_REPLY. >=20 > In this case if I have understood correctly the server sends CFG_REPLY > back asking for client provide the DEVICE_IDENTITY. The RFC7296 says > that "In variations of the protocol where there are multiple IKE_AUTH > exchanges, the CP payloads MUST be inserted in the messages containing > the SA payloads." (RFC7296 section 2.19). This means that > CP(CFG_REPLY) is in the last IKE_AUTH, i.e. after the EAP > authentication is finished. >=20 > The 24302-d30 section 7.2 seems to indicate that we send CFG_REPLY > back during the EAP and IKE_AUTH exchanges, and then do second > CFG_REQEST after that. This is against the RFC7296, as the first > CFG_REQUEST already contains the IP-address assingment request, and > its CFG_REPLY MUST be in the last IKE_AUTH. >=20 > Also the DEVICE_IDENTITY is attribute that is flowing in wrong > direction. I.e. the CFG_REQUEST/CFG_REPLY is meant to be working so > that CFG_REQUEST is used by the initiator to request something and > CFG_REPLY is used by responder to reply those configuration > parameters. In this case the responder is requesting the initiator to > provide some information. >=20 > Also DEVICE_IDENTITY has nothing to do with the configurations of the > devices, and is not needed by the IKE or the networks stack to create > the IKEv2 tunnel. It does not belong to the configuration payloads. >=20 > As this is also completely untrusted, and provided just for the > information for the server side, I think it would be better to use > Notify payloads to send this information. I.e. allocate status > notification payload for IMEI and another one for IMEISV, and require > that clients send those notifications during the IKE_AUTH exchange.=20 > --=20 > kivinen@iki.fi >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail=_457FB269-7385-4168-BA12-E4CE1EBC8033 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, Tero

I = realise you are not the one to ask about this, but why not use CFG_SET? =  

This = IMEI information is about as trustworthy as the = =E2=80=9CAPPLICATION_VERSION=E2=80=9D type.

Yoav

On = 15 Dec 2015, at 2:18 PM, Tero Kivinen <kivinen@iki.fi> = wrote:

FYI, = I just rejected the DEVICE_IDENTITY configuration payload
attribute request for IKEv2 because of following reasons.


From: Tero Kivinen <kivinen@iki.fi>
Subject: = [IANA #879113] = General Request for Assignment (ikev2-parameters)
Date: 15= December 2015 at 2:15:38 PM GMT+2
To: = iana-prot-param-comment@iana.org


Michelle Cotton = via RT writes:
I'm = sending this request to you for expert review.
If you = could reply back before or by 23 November 2015 that would be
most appreciated.\

Sorry for being late for this reply, but I have been quite = busy last
few months.

On Thu Nov 05 09:32:49 = 2015, frederic.firmin@etsi.org wrote:

Contact Name:
Frederic Firmin

Contact = Email:
frederic.firmin@etsi.org

Type = of Assignment:
New item in the "IKEv2 Configuration = Payload Attribute Types" of the
"Internet Key Exchange = Version 2 (IKEv2) Parameters" as shown at
http://www.iana.org/assignments/ikev2-parameters/ikev2-
parameters.xhtml#ikev2-parameters-21 and as specified in IETF = RFC 4306
and updated by IETF RFC 5996 and IETF RFC = 7296.

Registry:
The "IKEv2 = Configuration Payload Attribute Types" of the "Internet Key
Exchange Version 2 (IKEv2) Parameters" as shown at
http://www.iana.org/assignments/ikev2-parameters/ikev2-
parameters.xhtml#ikev2-parameters-21 and as specified in IETF = RFC 4306
and updated by IETF RFC 5996 and IETF RFC = 7296.

Description:
This IKEv2 = attribute is used to provide device identity.

Additional Info:
IETF RFC 4306 defines the = registry for the "IKEv2 Configuration
Payload Attribute = Types". IETF RFC 7296 and IETF RFC 5996 refer to
IETF RFC = 4306 for the definition of the registry.

The = following attribute is requested to be registered:
- =       value: (number to be assigned by = IANA)
-       attribute = type: DEVICE_IDENTITY
- =       multi-valued: no
- =       length: 1 or more octets
-       reference: 24.302 = 13.3.0 http://www.3gpp.org/ftp/Specs/html-
info/24302.htm

This assignment is = problematic.

If I have understood = correclty this will use configuration payloads in
non-standard way, i.e. in way where it has not been used = before.

Normally client requests parameters = by sending CFG_REQUEST, and server
replies values back = using CFG_REPLY.

In this case if I have = understood correctly the server sends CFG_REPLY
back = asking for client provide the DEVICE_IDENTITY. The RFC7296 says
that "In variations of the protocol where there are multiple = IKE_AUTH
exchanges, the CP payloads MUST be inserted in = the messages containing
the SA payloads." (RFC7296 section = 2.19). This means that
CP(CFG_REPLY) is in the last = IKE_AUTH, i.e. after the EAP
authentication is = finished.

The 24302-d30 section 7.2 seems = to indicate that we send CFG_REPLY
back during the EAP and = IKE_AUTH exchanges, and then do second
CFG_REQEST after = that. This is against the RFC7296, as the first
CFG_REQUEST = already contains the IP-address assingment request, and
its = CFG_REPLY MUST be in the last IKE_AUTH.

Also = the DEVICE_IDENTITY is attribute that is flowing in wrong
direction. I.e. the CFG_REQUEST/CFG_REPLY is meant to be = working so
that CFG_REQUEST is used by the initiator to = request something and
CFG_REPLY is used by responder to = reply those configuration
parameters. In this case the = responder is requesting the initiator to
provide some = information.

Also DEVICE_IDENTITY has = nothing to do with the configurations of the
devices, and = is not needed by the IKE or the networks stack to create
the= IKEv2 tunnel. It does not belong to the configuration payloads.

As this is also completely untrusted, and = provided just for the
information for the server side, I = think it would be better to use
Notify payloads to send = this information. I.e. allocate status
notification = payload for IMEI and another one for IMEISV, and require
that clients send those notifications during the IKE_AUTH = exchange.
--
kivinen@iki.fi


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

= --Apple-Mail=_457FB269-7385-4168-BA12-E4CE1EBC8033-- From nobody Tue Dec 15 07:05:59 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1D91A8A9C for ; Tue, 15 Dec 2015 07:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 N6-KxM84DQZN for ; Tue, 15 Dec 2015 07:05:44 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.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 4DF3B1A1B1C for ; Tue, 15 Dec 2015 07:05:38 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3pKjZQ5drwz3Qq; Tue, 15 Dec 2015 16:05:34 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=ZBzsA01I X-OPENPGPKEY: Message passed unmodified 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 bs7NS8oG0oj6; Tue, 15 Dec 2015 16:05:33 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 15 Dec 2015 16:05:33 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPS id 454178009F; Tue, 15 Dec 2015 10:05:32 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1450191932; bh=yDL/806HyEIxgH2oJi86OJQebyTQzwaJxxZJhjVSqmc=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=ZBzsA01ImqpRCAhi1+VXGGtqDK0DpWxi1E11lH1+eT1mVUXjHd8+0ZiAIuMhL2hhT xJFVzDBhexPKRIaK5IB8+PXoXUZqxE6jhmmI2ECSb/1KxyI2WYRPoMFcbakcP7tAmK jB+o4CV7wL8xaKiHMAfVHkSbBim8lwes1E7HDyks= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.2/8.15.2/Submit) with ESMTP id tBFF5V7H026093; Tue, 15 Dec 2015 10:05:31 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 15 Dec 2015 10:05:31 -0500 (EST) From: Paul Wouters To: Valery Smyslov In-Reply-To: Message-ID: References: <5666AD1B.6000105@gmail.com> <18BF5929-6C8C-41A5-A3BC-764D3F56B2F3@apple.com> <566746C9.1020202@gmail.com> <0929AB361BDD4969BFBECB1DCF365433@buildpc> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: ipsec@ietf.org, Samy Touati , Tommy Pauly Subject: Re: [IPsec] TCP Encapsulation draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 15:05:51 -0000 On Tue, 15 Dec 2015, Valery Smyslov wrote: > The situation described above is quite real. Suppose the client is > downloading a large file > from the server. In this case the server always has data to be sent, while > the client > only responses with ACKs. If the client receives no new data it just waits. > Of course > if it has something to send, the TCP connection will be restored. That's why > it is probably worth to send liveness check messages from the initiator to > the responder > if there is no incoming traffic for some period of time (say 10-20 seconds) > and the endpoint has no data to send to the peer. Applications already need to deal with silent remote parties? It does not depend on ESPinTCP. So I find this example not very convincing. However, NAT gateways do time out TCP connections, so if the IPsec SA is genuinely idle, we might need to send something to keep it alive. But then sending a liveness probe is fine for that. > Note, that it is a bit different from how liveness check messages are > supposed > to be used in IKEv2, where liveness check should be done if there is no > incoming > traffic for some period of time AND if the endpoint is about to send new data > to the peer. That's not my understanding of livenss. What we do is time based liveness probes that are skipped when we detected there was recent traffic on the IPsec SA. > Oh, I see that the port is not necessary 4500. However I think > the clarification that no port switching takes place would be useful. When an RST happens, you do come back and if behind NAT you most likely will come back on a different port. So be caerful with using terms as port switching. (I wish we could get rid of that anyway, are there still any ipsec passthrough devices in use mangling port 500? or is there any reason why not to always start on 4500?) >> It is very important >> that TCP encapsulation can be implemented as a layer transparent to >> existing TCP, TLS, and ESP >> implementations. By default, these layers may have keepalives of their >> own. > > I agree that layer separation is important, so the only available keepalives > for the IPsec layer are NAT keepalives and liveness check messages. > The other methods are irrelevant here. An implementation can be aware > of their an existance, but usually cannot control them. I think it must be > clarified. Something along the lines of "Since the goal is to move back to UDP as soon as possible, most properties of the IKE connection that only make sense on UDP should still be kept for TCP". > In any case, if for the purposes of simplicity the draft allowed an > implementation > to send NAT keepalives in case of TCP encapsulation, then their layout and > processing should have been described (a la Sections 3.1 and 3.2). > And in this case the text from Section 3: NAT keepalives and ESPinTCP packets have the same property of needing to take packets from the TCP stream and not send them to userland. I'm not sure if that's easy to do. Does an application need to see any lowlevel TCP stuff like sequence numbers? Or can it just do a read() and not worry? If this is transparent to the userland, eg it wont see the NAT keepalives, then we might as well just allow them simiarly to UDP. Although with DPD/liveness, it makes more sense to never use NAT keepalives as the latter only keeps the mapping open but you don't know if there is still anyone at the other end. > In order to encapsulate IKEv2 and ESP messages within a stream (which > may be raw TCP, or TLS over TCP), a 32-bit length field precedes > every message. If the first 32-bits of the message are zeros (a Non- > ESP Marker), then the contents comprise an IKEv2 message. Otherwise, > the contents comprise an ESP message. > is not correct, since NAT keepalives are neigther IKE nor ESP messages. Oh, if we allow this inside a TLS stream, then I guess NAT keepalives cannot be eaten by the kernel, so I would recommend not using them and use a liveness probe instead. > I think that all the mechanisms that seem to become unnecessary with TCP > encapsulation > must be separately discussed in the document. There must be some text > describing under which > circumstances these mechanisms are still useful and when it is safe to > abandon them. I don't insist > on MUST NOT (or SHOULD NOT), but some guidlines must be given, otherwise > implementers will wonder: why should we spent resources doing useless things. Isn't it more the other way around? When we cannot use these things we need new code to track when NOT to do things. Still I agree we need to guide implementors properly. Paul From nobody Tue Dec 15 07:50:45 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84F71A9039 for ; Tue, 15 Dec 2015 07:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 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_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=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 l4jjzmEw80eq for ; Tue, 15 Dec 2015 07:50:43 -0800 (PST) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 C360C1A21AE for ; Tue, 15 Dec 2015 07:50:11 -0800 (PST) Received: by mail-lf0-x22c.google.com with SMTP id l133so9576118lfd.2 for ; Tue, 15 Dec 2015 07:50:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=7TcLLm7u00AtsVrmtnXkEVUcRdLzaRpMkRooYb72T3k=; b=b1I88Mioi4kdnQYSVNNP2ZxVK/rCliHzXjaZKLgLnH9H4RVgc8stkBQZWuFHQmj00q ckEUx3lOeQvDcEHqdw3FP9NnOaGnHloRCQzdGGoffuXXUm+wFMCANf5rtB9AGlEql168 hn5pzdJnfPhsP8ofYd8Du7gd0CKra3bcUpF79usRDU0+UTz7a5xFwe/GTAXSdACevKCG 3Zt1VwB1Eq4OAJFRFUaMr50R6JoDdisdTAcy+kPTVzceCrjlWk1h4Y5VleC5Y3Ws70SN b1SyTz94jHlFoE3RA6tH6+kEo+QjX0nIYQ2MAG5rB+Jcz9ixF3aTsfdOFkEVYtI91FEt 4S7Q== X-Received: by 10.25.127.204 with SMTP id a195mr8431276lfd.27.1450194610062; Tue, 15 Dec 2015 07:50:10 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id pl2sm301097lbc.8.2015.12.15.07.50.08 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Dec 2015 07:50:09 -0800 (PST) Message-ID: <8486CC23F71E4425B396ABCB8450581B@buildpc> From: "Valery Smyslov" To: "Paul Wouters" References: <5666AD1B.6000105@gmail.com> <18BF5929-6C8C-41A5-A3BC-764D3F56B2F3@apple.com> <566746C9.1020202@gmail.com> <0929AB361BDD4969BFBECB1DCF365433@buildpc> Date: Tue, 15 Dec 2015 18:50:06 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: ipsec@ietf.org, Samy Touati , Tommy Pauly Subject: Re: [IPsec] TCP Encapsulation draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 15:50:44 -0000 Hi Paul, >> The situation described above is quite real. Suppose the client is >> downloading a large file >> from the server. In this case the server always has data to be sent, while >> the client >> only responses with ACKs. If the client receives no new data it just waits. >> Of course >> if it has something to send, the TCP connection will be restored. That's why >> it is probably worth to send liveness check messages from the initiator to >> the responder >> if there is no incoming traffic for some period of time (say 10-20 seconds) >> and the endpoint has no data to send to the peer. > > Applications already need to deal with silent remote parties? It > does not depend on ESPinTCP. So I find this example not very convincing. I don't care about applications, I care about IPsec implementations :-) Currently an IPsec implementation can always send out a ESP packet if ESP SA is up. With TCP encapsulation there may be situations when ESP SA is up, however the encrypted packet cannot be send out because there is no TCP session associated with this ESP SA. What IPsec implementation is supposed to do with the data that TCP/IP stack is trying to send out? Discard? Collect in a hope that TCP is restored quickly? > However, NAT gateways do time out TCP connections, so if the IPsec SA is > genuinely idle, we might need to send something to keep it alive. But > then sending a liveness probe is fine for that. Are you saying that if I open telnet session via NAT and then go for dinner, that the session will be broken when I return? Well, I agree that NAT and firewalls can drop any TCP session at their will, but do they do it regularly in case of timeout? And what is the typical timeout timeout for TCP? >> Note, that it is a bit different from how liveness check messages are >> supposed >> to be used in IKEv2, where liveness check should be done if there is no >> incoming >> traffic for some period of time AND if the endpoint is about to send new data >> to the peer. > > That's not my understanding of livenss. What we do is time based > liveness probes that are skipped when we detected there was recent > traffic on the IPsec SA. RFC7296 is not very explicit about that. Please see RFC3706 (DPD) Section 5.5, that contains more speculations on this: Since the liveliness of a peer is only questionable when no traffic is exchanged, a viable implementation might begin by monitoring idleness. Along these lines, a peer's liveliness is only important when there is outbound traffic to be sent. To this end, an implementation can initiate a DPD exchange (i.e., send an R-U-THERE message) when there has been some period of idleness, followed by the desire to send outbound traffic. Compare with RFC7296, Section 2.4: If no cryptographically protected messages have been received on an IKE SA or any of its Child SAs recently, the system needs to perform a liveness check in order to prevent sending messages to a dead peer. Here - if you don't want to send message to a peer, you don't care if it is dead, do you? >> Oh, I see that the port is not necessary 4500. However I think >> the clarification that no port switching takes place would be useful. > > When an RST happens, you do come back and if behind NAT you most likely > will come back on a different port. So be caerful with using terms as > port switching. Agree. > (I wish we could get rid of that anyway, are there still > any ipsec passthrough devices in use mangling port 500? or is there any > reason why not to always start on 4500?) You can. It is explicitely allowed by RFC7296. Regards, Valery. From nobody Tue Dec 15 07:55:15 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38EB31A6FAA for ; Tue, 15 Dec 2015 07:55:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=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 xSXevpcBrw69 for ; Tue, 15 Dec 2015 07:55:12 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 2F8161A6F34 for ; Tue, 15 Dec 2015 07:55:12 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.1/8.14.8) with ESMTPS id tBFFt7So024768 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 15 Dec 2015 17:55:07 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.1/8.14.8/Submit) id tBFFt7Wm026264; Tue, 15 Dec 2015 17:55:07 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <22128.14299.370422.558869@fireball.acr.fi> Date: Tue, 15 Dec 2015 17:55:07 +0200 From: Tero Kivinen To: Yoav Nir In-Reply-To: <86D711D8-1BA4-4CF3-9105-463ED56E89EA@gmail.com> References: <22128.1279.575334.647846@fireball.acr.fi> <86D711D8-1BA4-4CF3-9105-463ED56E89EA@gmail.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 13 min X-Total-Time: 14 min Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] FWD from Tero Kivinen: [IANA #879113] General Request for Assignment (ikev2-parameters) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 15:55:14 -0000 Yoav Nir writes: > I realise you are not the one to ask about this, but why not use > CFG=5FSET=3F Mostly, because it is not a configuration information, and what would be the meaning when the server does not ACK your DEVICE=5FIDENTITY. Als= o I do not know any implementations that actually supports CFG=5FSET / CFG=5FACK. And I think they want to get that during the IKE=5FAUTH, and= they are already using CFG=5FREQUEST and CFG=5FREPLY to get the IP-address etc, so mixing two configuration payloads inside IKE=5FAUTH during EAP authentication would be quite confusing.=20 I.e. what they propose doing now is: HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, CP(CFG=5FREQUEST), SAi2, TSi, TSr} --> =09=09=09 <-- HDR, SK {IDr, [CERT+,] AUTH, =09=09=09=09 =09 CP(CFG=5FREPLY), EAP } HDR, SK { EAP } -> =09=09=09=09<-- HDR, SK { EAP } HDR, CP(CFG=5FREPLY), AUTH --> =09=09 =09 <-- HDR, SK { AUTH, =09 =09 CP(CFG=5FREPLY), =09=09=09=09=09 SA, TSi, TSr } or something like that, i.e. the first CFG=5FREPLY says that return DEVICE=5FIDENTITY, and then there probably needs to be second CP to get= the actual IP address or something. The text in their documentation does not really tell how it is supposed to work.=20 > This IMEI information is about as trustworthy as the =E2=80=9CAPPLICA= TION=5FVERSION=E2=80=9D > type. Yep. I.e. it is whatever the client software or user decided to configure there.=20 --=20 kivinen@iki.fi From nobody Tue Dec 15 08:04:45 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 331581A1C04 for ; Tue, 15 Dec 2015 08:04:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 e9x5B_BIDjdU for ; Tue, 15 Dec 2015 08:04:38 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.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 7C3331A903B for ; Tue, 15 Dec 2015 08:04:36 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3pKktV30mzz4Cb; Tue, 15 Dec 2015 17:04:34 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=XeFCTZ8T X-OPENPGPKEY: Message passed unmodified 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 IdS1eCytPgrk; Tue, 15 Dec 2015 17:04:33 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 15 Dec 2015 17:04:33 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPS id AA4D48009F; Tue, 15 Dec 2015 11:04:31 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1450195471; bh=7fnUwkbS9X++mZwF2RPGYEdDrKbDveo9CwdaqjTicvU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=XeFCTZ8TJhy+97NU7esW01MxKI33Tx8BrjnjDILOrCVnTY8COa7RVt1+ZeJYKoMJy SCa+35tJFe8EyXyCyLLl+zYv4mTNQ5v/hl8A/ovlbyFFfUIfXtjTcJo+zC5sF9Cw6C 7EqpaS8UkIafuk6qwElqNmUJKxtc44inHzlpDymU= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.2/8.15.2/Submit) with ESMTP id tBFG4VY1001233; Tue, 15 Dec 2015 11:04:31 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 15 Dec 2015 11:04:31 -0500 (EST) From: Paul Wouters To: Valery Smyslov In-Reply-To: <8486CC23F71E4425B396ABCB8450581B@buildpc> Message-ID: References: <5666AD1B.6000105@gmail.com> <18BF5929-6C8C-41A5-A3BC-764D3F56B2F3@apple.com> <566746C9.1020202@gmail.com> <0929AB361BDD4969BFBECB1DCF365433@buildpc> <8486CC23F71E4425B396ABCB8450581B@buildpc> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] TCP Encapsulation draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 16:04:44 -0000 On Tue, 15 Dec 2015, Valery Smyslov wrote: > I don't care about applications, I care about IPsec implementations :-) > Currently an IPsec implementation can always send out a ESP packet > if ESP SA is up. With TCP encapsulation there may be situations > when ESP SA is up, however the encrypted packet cannot be send out because > there is no TCP session associated with this ESP SA. What IPsec > implementation is supposed to do with the data > that TCP/IP stack is trying to send out? Discard? Collect in a hope > that TCP is restored quickly? I think the subsystem should "send" it, whether it gets dropped or queued up for a new TCP session would be up to the implementation? >> However, NAT gateways do time out TCP connections, so if the IPsec SA is >> genuinely idle, we might need to send something to keep it alive. But >> then sending a liveness probe is fine for that. > > Are you saying that if I open telnet session via NAT and then > go for dinner, that the session will be broken when I return? Yes, since about 1997 :) If you did not realise that you spend too much time on IETF networks :) > Well, I agree that NAT and firewalls can drop any TCP session > at their will, but do they do it regularly in case of timeout? > And what is the typical timeout timeout for TCP? Yes. around 15-20 minutes if you are on stable (non-coffee, not-hotel) NATworks. >> > Note, that it is a bit different from how liveness check messages are >> > supposed >> > to be used in IKEv2, where liveness check should be done if there is no >> > incoming >> > traffic for some period of time AND if the endpoint is about to send new >> > data to the peer. >> >> That's not my understanding of livenss. What we do is time based >> liveness probes that are skipped when we detected there was recent >> traffic on the IPsec SA. > > RFC7296 is not very explicit about that. Please see RFC3706 (DPD) > Section 5.5, that contains more speculations on this: > > Since the liveliness of a peer is only questionable when no traffic > is exchanged, a viable implementation might begin by monitoring > idleness. Along these lines, a peer's liveliness is only important > when there is outbound traffic to be sent. That I disagree with. I want to cleanup roadwarriors who have left at some point, which means a liveness probe without me having traffic pending for them. > To this end, an > implementation can initiate a DPD exchange (i.e., send an R-U-THERE > message) when there has been some period of idleness, followed by the > desire to send outbound traffic. > > Compare with RFC7296, Section 2.4: > > If no > cryptographically protected messages have been received on an IKE SA > or any of its Child SAs recently, the system needs to perform a > liveness check in order to prevent sending messages to a dead peer. > > Here - if you don't want to send message to a peer, you don't care if > it is dead, do you? I guess it assumes the other end acts the same, so if any endpoint wants to send, they will do liveness. But I agree the RFC text could be better. >> (I wish we could get rid of that anyway, are there still >> any ipsec passthrough devices in use mangling port 500? or is there any >> reason why not to always start on 4500?) > > You can. It is explicitely allowed by RFC7296. I know. But I still can't do that :) I'm not even sure if most IKEv2 implementations can run fine without port 500. Also I would have prefered to get rick of 4500, not 500, which is not what 7296 allows. Paul From nobody Tue Dec 15 22:20:18 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD571A8791 for ; Tue, 15 Dec 2015 22:20:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.47 X-Spam-Level: * X-Spam-Status: No, score=1.47 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=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 GxBniRm4FVFV for ; Tue, 15 Dec 2015 22:20:16 -0800 (PST) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (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 010001A8788 for ; Tue, 15 Dec 2015 22:20:16 -0800 (PST) Received: by mail-lf0-x22d.google.com with SMTP id z124so17462236lfa.3 for ; Tue, 15 Dec 2015 22:20:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=2SjQkT7RVyaJHqlFaOpqy2BaVEzceqPY8H6zbnWTu7E=; b=SuvDFibiobZ/Jy4784fkeLkiYc3e9+JvBGMM9Qeun69KiMWRZcYykEzi6/LBbY8TOT O4tOT3XD7dUk+Vq55Eow8KfYiq01RNNH8Pwz3GWJ2TGJZ4fEYNYWEuqs1RXL/skzNJnw XEwEBpStxJRO2SW9JdgpjnbaFIHojKY8x4xEuzdwtDzTLtMT+pCPohGohRSkHxg/K+y3 5AgtGtc0YyKqlXfZGqRpbl9O/arr4+G7I06wsv1/CnmnDFooOinzJ41DS9d6/zc5l2B0 zoOo+JF7h9TcpVNZI8LFLe8Ox7Mn9xGGGN1ZxTTo06yv77azjI3xk0B7pa+1vW763MdM 2tGA== X-Received: by 10.25.157.83 with SMTP id g80mr5756312lfe.80.1450246814105; Tue, 15 Dec 2015 22:20:14 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id m70sm724297lfb.17.2015.12.15.22.20.13 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Dec 2015 22:20:13 -0800 (PST) Message-ID: <87B98D33834C4FC288253FF269BB83E1@buildpc> From: "Valery Smyslov" To: "Paul Wouters" References: <5666AD1B.6000105@gmail.com> <18BF5929-6C8C-41A5-A3BC-764D3F56B2F3@apple.com> <566746C9.1020202@gmail.com> <0929AB361BDD4969BFBECB1DCF365433@buildpc> <8486CC23F71E4425B396ABCB8450581B@buildpc> Date: Wed, 16 Dec 2015 09:20:04 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] TCP Encapsulation draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2015 06:20:17 -0000 >> Since the liveliness of a peer is only questionable when no traffic >> is exchanged, a viable implementation might begin by monitoring >> idleness. Along these lines, a peer's liveliness is only important >> when there is outbound traffic to be sent. > > That I disagree with. I want to cleanup roadwarriors who have left at > some point, which means a liveness probe without me having traffic > pending for them. Definitely you can do it. It's a usual tradeoff between wasting resources doing frequent liveness checks and wasting memory for the dead connection. Choose right balance. >> To this end, an >> implementation can initiate a DPD exchange (i.e., send an R-U-THERE >> message) when there has been some period of idleness, followed by the >> desire to send outbound traffic. >> >> Compare with RFC7296, Section 2.4: >> >> If no >> cryptographically protected messages have been received on an IKE SA >> or any of its Child SAs recently, the system needs to perform a >> liveness check in order to prevent sending messages to a dead peer. >> >> Here - if you don't want to send message to a peer, you don't care if >> it is dead, do you? > > I guess it assumes the other end acts the same, so if any endpoint wants > to send, they will do liveness. Sure. The problem is that with TCP encapsulation the other end may have no TCP session and would have been unable to send any traffic (including liveness checks) until this end (the original initiator) restores TCP seesion. Valery. From nobody Wed Dec 16 00:33:23 2015 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 844FB1A6F5A; Wed, 16 Dec 2015 00:33:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151216083320.19499.73449.idtracker@ietfa.amsl.com> Date: Wed, 16 Dec 2015 00:33:20 -0800 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2015 08:33:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Protecting Internet Key Exchange (IKE) Implementations from Distributed Denial of Service Attacks Authors : Yoav Nir Valery Smyslov Filename : draft-ietf-ipsecme-ddos-protection-03.txt Pages : 27 Date : 2015-12-16 Abstract: This document recommends implementation and configuration best practices for Internet-connected IPsec Responders, to allow them to resist Denial of Service and Distributed Denial of Service attacks. Additionally, the document introduces a new mechanism called "Client Puzzles" that help accomplish this task. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ddos-protection/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-ddos-protection-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ddos-protection-03 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 17 04:46:55 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 419FF1B2BF8 for ; Thu, 17 Dec 2015 04:46:54 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains text/plain,.exe X-Spam-Flag: NO X-Spam-Score: -0.521 X-Spam-Level: X-Spam-Status: No, score=-0.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_82=0.6, SPF_NEUTRAL=0.779] autolearn=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 QvPwziCwPybG for ; Thu, 17 Dec 2015 04:46:52 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 0F4761A87AB for ; Thu, 17 Dec 2015 04:46:51 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.1/8.14.8) with ESMTPS id tBHCkfRr012265 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 17 Dec 2015 14:46:41 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.1/8.14.8/Submit) id tBHCkeDf016846; Thu, 17 Dec 2015 14:46:40 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <22130.44720.140409.176734@fireball.acr.fi> Date: Thu, 17 Dec 2015 14:46:40 +0200 From: Tero Kivinen To: Daniel Migault In-Reply-To: References: <0748F101-7104-4F07-B440-31A9CF63BE32@gmail.com> <9EBE3C6E-C7F2-4327-B4E2-3363BD96ECC1@gmail.com> <56421D6F.7080506@gmail.com> <22082.23345.969526.729086@fireball.acr.fi> <564A1549.1010001@gmail.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 5 min X-Total-Time: 5 min Archived-At: Cc: IPsecME WG , Paul Wouters , Tommy Pauly , John Mattsson Subject: Re: [IPsec] RFC 4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 12:46:54 -0000 Daniel Migault writes: > 1) MTI=3F > Are there any opinion to replace Mandatory to implement by something = like > "Algorithm Implementation Requirements and Usage Guidance"or close to= . This > designation seems more in scope with the different status. I agree on that.=20 > 2) 1024-bit MODP SHOULD NOT- =3F > The current draft set 1024-bit MODP Group as SHOULD NOT with the foll= owing > explanation: >=20 > """Group 2 or 1024-bit MODP Group is downgraded from MUST- to SHOULD = NOT. It > was specified earlier, and now it is known to be weak against a natio= n state > attack, so its security margin is considered too narrow.""" >=20 > My understanding from the discussion at the IETF94 was that we are tr= ying to > avoid the +/- notation but instead clarify the status with some addit= ional > text. Actually I think it might be better to just use text, and get rid of the + and -. > The current version only use the +/- notation for AUTH=5FHMAC=5FSHA2=5F= 512=5F256 > SHOULD+. Here are my question for the WG: > =A0=A0=A0 a) Do we want to keep the notation +/- =3F I would get rid of the notation, as we now have text explaining more about the status of algorithms, and that text can express things more clearly than the + and - can. > =A0=A0=A0 b) if not would people agree with AUTH=5FHMAC=5FSHA2=5F512=5F= 256 set to > SHOULD=20 I think it should be SHOULD.=20 > Depending on the above outputs, are there any opinion for: > =A0=A0 c) Changing the status from SHOULD NOT to SHOULD NOT + =3F > =A0=A0 d) Explicitely mentionning in the text that we expect it to do= wngraded to > MUST NOT in the near future. I do not know if it is near future, but sometime in future. And yes, I think we should state that.=20 > 3) +/- notations=3F > If we keep the +/- notations, I agree we should define +/- only.I wil= l change > that unless some people think it is a bad idea. >=20 > 4) Curve25519 =3F > Curve25519 is by default set to MAY. If we still have the -/+ notatio= n would > people agree to have MAY+ for its status. If I remember correctly, we= did not=20 > mentionned Curve25519 to SHOULD as it is not yet widely deployed. By = default > all non mentioned algorithms are set to MAY. Maybe having MAY+ would = be good > alternative to show what we expect next and enable implementer to ant= icipate. > Here are my questions: > =A0=A0=A0 e) Should we upgrade Curve25519 to MAY+=3F I think we can have Curve25519 listed as MAY, with text explaining that if it gets widely implemented then it most likely will be upgraded to should or even must in the future. Btw, there is quite a lot of changes in the draft now, so I think it would be good idea to publish 02 version now, as drafts are easier to read than the changes in some repository. --=20 kivinen@iki.fi From nobody Thu Dec 17 04:53:29 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D11F01A6F5B for ; Thu, 17 Dec 2015 04:53:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=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 6wHODpaJok-u for ; Thu, 17 Dec 2015 04:53:27 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 EED681A6F2A for ; Thu, 17 Dec 2015 04:53:25 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.1/8.14.8) with ESMTPS id tBHCrHAI026521 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 17 Dec 2015 14:53:17 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.1/8.14.8/Submit) id tBHCrHhP013667; Thu, 17 Dec 2015 14:53:17 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22130.45117.662858.325368@fireball.acr.fi> Date: Thu, 17 Dec 2015 14:53:17 +0200 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: <5666AD1B.6000105@gmail.com> <18BF5929-6C8C-41A5-A3BC-764D3F56B2F3@apple.com> <566746C9.1020202@gmail.com> <0929AB361BDD4969BFBECB1DCF365433@buildpc> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 5 min Archived-At: Cc: ipsec@ietf.org, Samy Touati , Valery Smyslov , Tommy Pauly Subject: Re: [IPsec] TCP Encapsulation draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 12:53:28 -0000 Paul Wouters writes: > > Oh, I see that the port is not necessary 4500. However I think > > the clarification that no port switching takes place would be useful. > > When an RST happens, you do come back and if behind NAT you most likely > will come back on a different port. So be caerful with using terms as > port switching. (I wish we could get rid of that anyway, are there still > any ipsec passthrough devices in use mangling port 500? or is there any > reason why not to always start on 4500?) Has there ever been devices doing something special for TCP traffic on port 500? I think most of the issues has been with UDP traffic, where the both source and destination ports were specified to be 500, so some NAT devices decided, that because of that we cannot NAT the source port, thus we need to do something special for IPsec traffic. The port 4500 was just getting rid of this helpful thing NAT boxes tried to do. With TCP encapsulated IPsec, the source port will most likely be random port anyways, and the destination port will be either 500 or 4500. I would actually say we should use TCP port 500 for servers always and not use port 4500 at all. And the source TCP port will most likely be different even if there is no NAT between, for example when using IPv6 and going through firewall which is configured to drop all UDP traffic (and which might do some special cases for DNS). -- kivinen@iki.fi From nobody Thu Dec 17 05:09:03 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C52A31B2C9E for ; Thu, 17 Dec 2015 05:09:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=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 jW0yPR9MV92p for ; Thu, 17 Dec 2015 05:08:58 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 366B21B2C93 for ; Thu, 17 Dec 2015 05:08:54 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.1/8.14.8) with ESMTPS id tBHD8koK017146 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 17 Dec 2015 15:08:46 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.1/8.14.8/Submit) id tBHD8kEW006572; Thu, 17 Dec 2015 15:08:46 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22130.46046.432836.630317@fireball.acr.fi> Date: Thu, 17 Dec 2015 15:08:46 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <8486CC23F71E4425B396ABCB8450581B@buildpc> References: <5666AD1B.6000105@gmail.com> <18BF5929-6C8C-41A5-A3BC-764D3F56B2F3@apple.com> <566746C9.1020202@gmail.com> <0929AB361BDD4969BFBECB1DCF365433@buildpc> <8486CC23F71E4425B396ABCB8450581B@buildpc> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 14 min X-Total-Time: 14 min Archived-At: Cc: ipsec@ietf.org, Samy Touati , Paul Wouters , Tommy Pauly Subject: Re: [IPsec] TCP Encapsulation draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 13:09:01 -0000 Valery Smyslov writes: > I don't care about applications, I care about IPsec implementations :-) > Currently an IPsec implementation can always send out a ESP packet > if ESP SA is up. With TCP encapsulation there may be situations > when ESP SA is up, however the encrypted packet cannot be > send out because there is no TCP session associated with this > ESP SA. What IPsec implementation is supposed to do with the data > that TCP/IP stack is trying to send out? Discard? Collect in a hope > that TCP is restored quickly? Most likely the smart thing is to drop it immediately. It is exactly same thing than when your ESP packets do not go through as network is broken somewhere in the middle. There is no point of queuing them up, as upper layer protocols will retransmit those packets and then the queue will fill up with retransmissions etc, and the upper layer protocols are expecting more about dropped packets, than packets delayed by tens of seconds. > > However, NAT gateways do time out TCP connections, so if the IPsec SA is > > genuinely idle, we might need to send something to keep it alive. But > > then sending a liveness probe is fine for that. > > Are you saying that if I open telnet session via NAT and then > go for dinner, that the session will be broken when I return? Yes. Just last week I was in some meeting room network, which teared down my ssh connections every few minutes. I kept hitting enter on my shell windows every now and then, and usually some of them got disconnected. The stupid NAT box didn't even send RST, thus my connections just hang for several minutes waiting for the TCP timeouts. As this didn't seem to be consistent with activity, i.e it could happen even when I was using the connection, we assumed the NAT box was running out of memory or something and cleaning up TCP connections at random... > Well, I agree that NAT and firewalls can drop any TCP session > at their will, but do they do it regularly in case of timeout? > And what is the typical timeout timeout for TCP? If the NAT boxes have timeout for TCP sessions it is quite long (minutes, tens of minutes, or hours), but if they run out of memory they can clear state quite quickly. > >> Note, that it is a bit different from how liveness check messages are > >> supposed > >> to be used in IKEv2, where liveness check should be done if there is no > >> incoming > >> traffic for some period of time AND if the endpoint is about to send new data > >> to the peer. > > > > That's not my understanding of livenss. What we do is time based > > liveness probes that are skipped when we detected there was recent > > traffic on the IPsec SA. There is no point of sending periodic liveness checks ever. Liveness checks are supposed to be used when you suspect that other end is no longer alive, and if you get reply back you do know it is alive. > RFC7296 is not very explicit about that. Please see RFC3706 (DPD) > Section 5.5, that contains more speculations on this: > > Since the liveliness of a peer is only questionable when no traffic > is exchanged, a viable implementation might begin by monitoring > idleness. Along these lines, a peer's liveliness is only important > when there is outbound traffic to be sent. To this end, an > implementation can initiate a DPD exchange (i.e., send an R-U-THERE > message) when there has been some period of idleness, followed by the > desire to send outbound traffic. > > Compare with RFC7296, Section 2.4: > > If no > cryptographically protected messages have been received on an IKE SA > or any of its Child SAs recently, the system needs to perform a > liveness check in order to prevent sending messages to a dead peer. > > Here - if you don't want to send message to a peer, you don't care if > it is dead, do you? Yes. The idea is that you want to avoid black hole, i.e. you are sending stuff, and other end is dropping it because state got cleared from the other end. I.e. you are supposed to do liveness check when you for example receive some kind of ICMP which would indicate that other end might be down (for example port unreachable, host unreachable etc). Also other end is sending traffic to you and you are sending traffic to him, but then suddenly the other end stops sending traffic to you, i.e. the traffic pattern changed to be unidirectional. This could of course be because traffic changed, but it could indicate there is problem. So when you detect that (i.e. you are sending traffic, but other end is not sending any cryptographically protected messages), you do liveness check. If the other end respondes you know it is alive, and traffic pattern simply changed. If the traffic pattern stays one way for longer time, you might repeat the liveness check at some point, as otherwise you do not detect whether the other end died or not. In normal case one way traffic patters are not very common, so you always have traffic coming back (ACKs etc). There is stupid implementations out there which do send liveness checks every n seconds regardless of anything else, but those are just bad implementations. -- kivinen@iki.fi From nobody Thu Dec 17 05:18:03 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE02E1B2CF4 for ; Thu, 17 Dec 2015 05:18:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=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 sDc_LljymfAd for ; Thu, 17 Dec 2015 05:17:58 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 6623A1B2CEA for ; Thu, 17 Dec 2015 05:17:58 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.1/8.14.8) with ESMTPS id tBHDHtNL019617 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 17 Dec 2015 15:17:55 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.1/8.14.8/Submit) id tBHDHtXl013289; Thu, 17 Dec 2015 15:17:55 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22130.46595.453837.770060@fireball.acr.fi> Date: Thu, 17 Dec 2015 15:17:55 +0200 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: <5666AD1B.6000105@gmail.com> <18BF5929-6C8C-41A5-A3BC-764D3F56B2F3@apple.com> <566746C9.1020202@gmail.com> <0929AB361BDD4969BFBECB1DCF365433@buildpc> <8486CC23F71E4425B396ABCB8450581B@buildpc> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 7 min X-Total-Time: 8 min Archived-At: Cc: "ipsec@ietf.org WG" , Valery Smyslov Subject: Re: [IPsec] TCP Encapsulation draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 13:18:02 -0000 Paul Wouters writes: > > Since the liveliness of a peer is only questionable when no traffic > > is exchanged, a viable implementation might begin by monitoring > > idleness. Along these lines, a peer's liveliness is only important > > when there is outbound traffic to be sent. > > That I disagree with. I want to cleanup roadwarriors who have left at > some point, which means a liveness probe without me having traffic > pending for them. Why? Doing liveness probe is much more expensive operation than keeping IKE SA and Child SAs in memory. If the connection is silent, there is no traffic thus there is no cost unless you run out of memory. When you are starting to run out of memory you can do liveness checks to clear out dead connections. You can also just set the rekey interval to be 3600 seconds or something, and then that rekey will do "liveness" check for you :-) > > To this end, an > > implementation can initiate a DPD exchange (i.e., send an R-U-THERE > > message) when there has been some period of idleness, followed by the > > desire to send outbound traffic. > > > > Compare with RFC7296, Section 2.4: > > > > If no > > cryptographically protected messages have been received on an IKE SA > > or any of its Child SAs recently, the system needs to perform a > > liveness check in order to prevent sending messages to a dead peer. > > > > Here - if you don't want to send message to a peer, you don't care if > > it is dead, do you? > > I guess it assumes the other end acts the same, so if any endpoint wants > to send, they will do liveness. Of course both ends acts the same. This text is not tied to any one end. > But I agree the RFC text could be better. I think the current text is fine. It could also say that "you MUST NOT do periodic liveness checks", but I assume some people would have objected to that, just because that would made their implementations non-conforming... -- kivinen@iki.fi From nobody Thu Dec 17 05:38:53 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C77171B2D11 for ; Thu, 17 Dec 2015 05:38:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 AUx02V4GXXIx for ; Thu, 17 Dec 2015 05:38:51 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 7C3051B2CF1 for ; Thu, 17 Dec 2015 05:38:51 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id l126so22038568wml.1 for ; Thu, 17 Dec 2015 05:38:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=CgC/SKEfcje+JNqpAqQnLMvMsQkeEOiv7XvuUbpVHz4=; b=B6ZMAStmzFPYgWfRpN+hV9NdNATAK+o3XPRM7FZ4DkwdJU1++BQEbTD7wjWBiSYMKS hfen6yZIauoDIUK8QH30sJ5xH7u77ZwA0cqsRTuKjpxtAQ1FI3gxqqVIfh7Io8fqxHyg sI6blyPXphicqDQP518a1oJ63NQV8zEm8KAaZW16ith1i5ksTDJX1sSikX+LAahEOfws G6AvOc+pvvusTdoHz7eOmYSJqBkE8+oSv9NvcvWJhtbS2wCwGBIVO0Pp0o4/prIVJy6o 8uAO6C2dlBQgxDAFb19AsQh2U/TtF07x3LWFFiSwJHs3fhM6u5D1MRe7bH15tsJ6mHXZ Gz/w== X-Received: by 10.194.119.68 with SMTP id ks4mr56091882wjb.45.1450359530160; Thu, 17 Dec 2015 05:38:50 -0800 (PST) Received: from [172.24.248.186] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id a186sm2407099wmh.4.2015.12.17.05.38.48 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 17 Dec 2015 05:38:49 -0800 (PST) From: Yoav Nir Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <039D81DE-FDFE-4B5C-BDA5-20F35AC09492@gmail.com> Date: Thu, 17 Dec 2015 15:38:46 +0200 To: IPsecME WG Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: Subject: [IPsec] Progressing on 4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 13:38:53 -0000 Hi Pretty much all of the discussion in the last month or so has been based = on Daniel=E2=80=99s pull request. I think we might as well take that as = a given. I propose to merge this CR and publish a new revision so that people can = begin making changes on top of that. Of course, as always, everything is up for a change based on group = consensus, but I think we should move the baseline. Any objections? Yoav From nobody Thu Dec 17 05:45:04 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA4621B2D19 for ; Thu, 17 Dec 2015 05:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.108 X-Spam-Level: * X-Spam-Status: No, score=1.108 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=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 xPVNSRbYGrxV for ; Thu, 17 Dec 2015 05:44:58 -0800 (PST) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (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 3F6D61AD352 for ; Thu, 17 Dec 2015 05:44:58 -0800 (PST) Received: by mail-lf0-x22f.google.com with SMTP id y184so51964060lfc.1 for ; Thu, 17 Dec 2015 05:44:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=FGt6bbKlK5fPCJ47m/1m4piALpYeTD160a76PAVpD1U=; b=tF7To6cxT2g/MsaPT8R9SCSeeHtaA9+2HntCmgIrK1p4BgfId2jay6ps5A5Aggqmw4 KmvZ/m2BsjMdJPGAFTa82JMWT8Of3SQfMaTB7C7FyZyoEZ8S1SOpKz20WNN6cuqo4Huc UsdLQ4xUYQdR8uglG7M1TP4eZmB5wqy348jKMbqGxqKHhi/hUf6R4M+fnS16t/Eto3bx Hj6nH+EgeHXFJyGGq9V1+rp0rbprv94EkOv4ZKWMNVzpe99nXdVbXN5CMfdsI59vg2rE x9bA2NItLEypKxB/7R5+IYrHx2XdJ3wP6x/UDUpZU+VO9nBHBOaY1/T4LbYjrNTsyVcI i+jw== X-Received: by 10.25.31.81 with SMTP id f78mr3488367lff.60.1450359896412; Thu, 17 Dec 2015 05:44:56 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id o67sm1962551lfo.33.2015.12.17.05.44.55 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Dec 2015 05:44:55 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Tero Kivinen" References: <5666AD1B.6000105@gmail.com><18BF5929-6C8C-41A5-A3BC-764D3F56B2F3@apple.com><566746C9.1020202@gmail.com><0929AB361BDD4969BFBECB1DCF365433@buildpc><8486CC23F71E4425B396ABCB8450581B@buildpc> <22130.46046.432836.630317@fireball.acr.fi> Date: Thu, 17 Dec 2015 16:44:47 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: ipsec@ietf.org, Samy Touati , Paul Wouters , Tommy Pauly Subject: Re: [IPsec] TCP Encapsulation draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 13:44:59 -0000 Hi Tero, >> If no >> cryptographically protected messages have been received on an IKE SA >> or any of its Child SAs recently, the system needs to perform a >> liveness check in order to prevent sending messages to a dead peer. >> >> Here - if you don't want to send message to a peer, you don't care if >> it is dead, do you? > > Yes. > > The idea is that you want to avoid black hole, i.e. you are sending > stuff, and other end is dropping it because state got cleared from the > other end. > > I.e. you are supposed to do liveness check when you for example > receive some kind of ICMP which would indicate that other end might be > down (for example port unreachable, host unreachable etc). > > Also other end is sending traffic to you and you are sending traffic > to him, but then suddenly the other end stops sending traffic to you, > i.e. the traffic pattern changed to be unidirectional. This could of > course be because traffic changed, but it could indicate there is > problem. So when you detect that (i.e. you are sending traffic, but > other end is not sending any cryptographically protected messages), > you do liveness check. If the other end respondes you know it is > alive, and traffic pattern simply changed. If the traffic pattern > stays one way for longer time, you might repeat the liveness check at > some point, as otherwise you do not detect whether the other end died > or not. > > In normal case one way traffic patters are not very common, so you > always have traffic coming back (ACKs etc). > > There is stupid implementations out there which do send liveness > checks every n seconds regardless of anything else, but those are just > bad implementations. My point was that with TCP encapsulation this "stupid" behaviour wil probably become the "standard" one. Otherwise there is a chance running into the situation when the original responder loses TCP session (e.g. RST from an attacker), while the original Initiator thinks the TCP session is still up. In this case if the Initiator has nothing to send to the responder, it will remain silent, while the responder will be unable to use the SAs. The situation will last until the initiator sends something to the responder: the responder sends back RST (as it doesn't have this TCP session) and then the initiator creates a new TCP session. Regards, Valery. From nobody Thu Dec 17 06:36:26 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0981B2E37 for ; Thu, 17 Dec 2015 06:36:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=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 JXFUTaOB3DsH for ; Thu, 17 Dec 2015 06:36:24 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 857151B2E30 for ; Thu, 17 Dec 2015 06:36:24 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.1/8.14.8) with ESMTPS id tBHEaDkm015214 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 17 Dec 2015 16:36:13 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.1/8.14.8/Submit) id tBHEaDfO016960; Thu, 17 Dec 2015 16:36:13 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22130.51293.130044.467641@fireball.acr.fi> Date: Thu, 17 Dec 2015 16:36:13 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: References: <5666AD1B.6000105@gmail.com> <18BF5929-6C8C-41A5-A3BC-764D3F56B2F3@apple.com> <566746C9.1020202@gmail.com> <0929AB361BDD4969BFBECB1DCF365433@buildpc> <8486CC23F71E4425B396ABCB8450581B@buildpc> <22130.46046.432836.630317@fireball.acr.fi> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 3 min Archived-At: Cc: ipsec@ietf.org, Samy Touati , Paul Wouters , Tommy Pauly Subject: Re: [IPsec] TCP Encapsulation draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 14:36:25 -0000 Valery Smyslov writes: > > There is stupid implementations out there which do send liveness > > checks every n seconds regardless of anything else, but those are just > > bad implementations. > > My point was that with TCP encapsulation this "stupid" behaviour > wil probably become the "standard" one. Otherwise there is > a chance running into the situation when the original responder loses > TCP session (e.g. RST from an attacker), while the original Initiator > thinks the TCP session is still up. In this case if the Initiator > has nothing to send to the responder, it will remain silent, > while the responder will be unable to use the SAs. > The situation will last until the initiator sends something to the responder: > the responder sends back RST (as it doesn't have this TCP session) > and then the initiator creates a new TCP session. This is exactly what happens when you using NAT-T in normal case too. I.e. if the responder looses state, it cannot do anything until initiator reconnects. Btw, if you have integrated TCP encapsulated IPsec you can also act on the TCP RST by trying to do liveness check inside the TCP. If that fails then you tear down the TCP session, if it works, then you simply ignore the RST, as it was clearly an attack as other end is still has TCP session up and running. This of course requires kernel to know which TCP sessions are used for the IPsec, and instead of tearing the TCP sessions down they need to indicate the RST to the IPsec so IPsec can check things before telling whether the TCP session needs to be taken down. -- kivinen@iki.fi From nobody Thu Dec 17 07:35:23 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0BE1B2EC2 for ; Thu, 17 Dec 2015 07:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.108 X-Spam-Level: * X-Spam-Status: No, score=1.108 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=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 wOdQbi8IybY0 for ; Thu, 17 Dec 2015 07:35:22 -0800 (PST) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (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 A08DB1B2E99 for ; Thu, 17 Dec 2015 07:35:21 -0800 (PST) Received: by mail-lf0-x234.google.com with SMTP id z124so49454232lfa.3 for ; Thu, 17 Dec 2015 07:35:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=jYio1dg1L9vJrzvr/YNici3BIA4cCKLFGDHQpqoUjbs=; b=z6mASG96zwHUgl2Yq737sbsqyzoyqHHHfq2tth5DWcQaXuo2BGNIYvm8aeMmRr1K2v a3/ZZKU1NTn6xmniBlXXYL+MYvq504i+ZQj1yxglSPBklMdaNRkNuy7nLyWcxZhaMOxM xWPx0RqxufTJkcav6rb3oB+bvAJ0S6nBC3+VFHoKkjzBBrlyuRl2+1Z/jvNOoGmIms3n JX3Y/ZYcHUfynDUKAjssOeRixfkfA0Gu1JTv68L0OBLeQ/6OHc2krPvLPSJsevM0uPJv r3FVkI7kozbRTtc69+RAjD0PywBwhx7t5mYqFbUrTW8EAf8v/ZnMBanrdfHdYcK3mtPY r9zg== X-Received: by 10.25.33.149 with SMTP id h143mr11783674lfh.61.1450366519923; Thu, 17 Dec 2015 07:35:19 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id nr3sm1138886lbb.38.2015.12.17.07.35.18 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Dec 2015 07:35:19 -0800 (PST) Message-ID: <783EE9DA4C0D4CFB9EE9A543D2970B56@buildpc> From: "Valery Smyslov" To: "Tero Kivinen" References: <5666AD1B.6000105@gmail.com><18BF5929-6C8C-41A5-A3BC-764D3F56B2F3@apple.com><566746C9.1020202@gmail.com><0929AB361BDD4969BFBECB1DCF365433@buildpc><8486CC23F71E4425B396ABCB8450581B@buildpc><22130.46046.432836.630317@fireball.acr.fi> <22130.51293.130044.467641@fireball.acr.fi> Date: Thu, 17 Dec 2015 18:35:12 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: ipsec@ietf.org, Samy Touati , Paul Wouters , Tommy Pauly Subject: Re: [IPsec] TCP Encapsulation draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 15:35:22 -0000 > This is exactly what happens when you using NAT-T in normal case too. > I.e. if the responder looses state, it cannot do anything until > initiator reconnects. What do you mean by state here? SA? It is not so easy for attacker to force responder loose its SA. If the responder is rebooted than it probably looses all the upper level connections with the initiator and has nothing to send. On the other hand, such situation may appear if NAT in between deletes its mapping. The NAT keepalives messages from the initiator will quickly create a new one, however the responder won't use new ports until it receives a cryptographically protected message from the initiator. This situation is similar to what I described. From nobody Fri Dec 25 04:18:47 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 686EB1A92ED for ; Fri, 25 Dec 2015 04:18:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.477 X-Spam-Level: *** X-Spam-Status: No, score=3.477 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, XPRIO=1.568] autolearn=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 Zesr1L4TCu1v for ; Fri, 25 Dec 2015 04:18:45 -0800 (PST) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (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 D0F4B1A92EC for ; Fri, 25 Dec 2015 04:18:44 -0800 (PST) Received: by mail-lf0-x233.google.com with SMTP id y184so172767765lfc.1 for ; Fri, 25 Dec 2015 04:18:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:subject:date:mime-version:content-type :content-transfer-encoding; bh=t0Joc8sdd2rpcfOsIa0Vvtr7TDhLZfwG9X/2+Gq3w68=; b=dnqxDoI60lioenlUDqCpWeHGZxMwpFrb6ZL7j/PpLEYOrJGW0Z8XPlf+uoQ3qaBkWK 65xpMN/fM+cyJzufp3ZyBLHZPuYG2fgrpsYAYtTxO/o73kaaw04zBeKFxH3/oplQZEZW gmUPkyKYEiNjNBdyVu4sczyBcVfsmUmhr7Nsqt5Rxa/Jz6pNsZsZzCFRcOQhInQ6HQ6E ac7PSapccuRUPty/LlxEzrd6aGs1sM21PCRcQNlbSqcd6B/Ko1NzLASMIKlbac09lW03 Lv9ESwuo6Wg9Y5+vvSd8OzjGs/92tr70/unczy6iOaicoZOkoKbufX95MlrpWMTT+YB1 FXmA== X-Received: by 10.25.162.65 with SMTP id l62mr14470297lfe.64.1451045922988; Fri, 25 Dec 2015 04:18:42 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id j123sm8022691lfb.19.2015.12.25.04.18.42 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 25 Dec 2015 04:18:42 -0800 (PST) Message-ID: <7A83C993003E493EB2E895E2B8CFEC61@buildpc> From: "Valery Smyslov" To: Date: Fri, 25 Dec 2015 15:18:49 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Subject: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-compression-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Dec 2015 12:18:46 -0000 Hi, I've posted a new draft on using compression in IKEv2. Comments, thoughts, criticism are very very welcome. Regards, Valery Smyslov. > A new version of I-D, draft-smyslov-ipsecme-ikev2-compression-00.txt > has been successfully submitted by Valery Smyslov and posted to the > IETF repository. > > Name: draft-smyslov-ipsecme-ikev2-compression > Revision: 00 > Title: Compression in the Internet Key Exchange Protocol Version 2 (IKEv2) > Document date: 2015-12-25 > Group: Individual Submission > Pages: 17 > URL: https://www.ietf.org/internet-drafts/draft-smyslov-ipsecme-ikev2-compression-00.txt > Status: https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-compression/ > Htmlized: https://tools.ietf.org/html/draft-smyslov-ipsecme-ikev2-compression-00 > > > Abstract: > This document describes a method for reducing the size of IKEv2 > messages by means of lossless compression. Making IKEv2 messages > smaller is desirable for low power consumption battery powered IoT > devices. It also helps avoid IP fragmentation of IKEv2 messages. > This document describes how compression is negotiated maintaining > backward compatibility and how it is used in IKEv2. > > > > > 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 Thu Dec 31 13:58:58 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3C31A8932 for ; Thu, 31 Dec 2015 13:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.59 X-Spam-Level: * X-Spam-Status: No, score=1.59 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_ALL=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=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 RlKpj59_q-xO for ; Thu, 31 Dec 2015 13:58:57 -0800 (PST) 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 DD70E1A892A for ; Thu, 31 Dec 2015 13:58:56 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3pWjzy5MVkz30V; Thu, 31 Dec 2015 22:58:54 +0100 (CET) X-OPENPGPKEY: Message passed unmodified 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 9OpreRosWnVT; Thu, 31 Dec 2015 22:58:39 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 31 Dec 2015 22:58:39 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 339F6603AF12; Thu, 31 Dec 2015 16:58:38 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 339F6603AF12 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2F4D22593F; Thu, 31 Dec 2015 16:58:38 -0500 (EST) Date: Thu, 31 Dec 2015 16:58:38 -0500 (EST) From: Paul Wouters To: Valery Smyslov In-Reply-To: <7A83C993003E493EB2E895E2B8CFEC61@buildpc> Message-ID: References: <7A83C993003E493EB2E895E2B8CFEC61@buildpc> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-compression-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2015 21:58:57 -0000 On Fri, 25 Dec 2015, Valery Smyslov wrote: > I've posted a new draft on using compression in IKEv2. > Comments, thoughts, criticism are very very welcome. This draft makes me nervous, as compression has been removed from encryption specifications in the last few years. I find the security considerations also weak on this. It basically says "if you think compression might be security issue, don't use it". Which isn't helpful at all to implementors. I am also worried about the security of maliciously compressed payloads, eg a zillion 0's, and other corner cases such as AUTH-NULL clients. I'm also not yet very convinced about the use case. For instance, the mentioned explosion of algorithms supported causing big IKE_INIT packets seems very unlikely for IoT devices which most likely only support 1 or 2 algorithms anyway. Note I'm not strongly against it. I just need more convincing. Paul