From nobody Fri May 6 13:39:32 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26CB612D6B7 for ; Fri, 6 May 2016 13:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVdT3E6DUAd6 for ; Fri, 6 May 2016 13:39:29 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 28DEF12D5AC for ; Fri, 6 May 2016 13:39:29 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id g17so95260397wme.1 for ; Fri, 06 May 2016 13:39:29 -0700 (PDT) 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; bh=8RnA5gwnHvzql5R+niVrxNxf3H0/X5BfHyTeX9NxfXg=; b=UrPGrUVNkcJaV2KiXC0kY9+eZbeHBSK20w/Ad7KgiLPoBpNWB6zPO/b5RGbBteLR5K pdxGQXEliKqUVjtaJ5QOOS722PEiO2qQyfJJqkseI45qHs/ZpbH8aaitEUbH3Lks6QwW BsbS50jWTG1iKSPY/UcpkOcOf4uoHhBBokLrYDrHYfgYHHYiQlzvxcGIPHfwhHGhyHpX gonNX8zb1hJLfL5jnf6kyPwSyFMDtufABBssxnKLNzggVP0msAfskB5g9R8FavmSJkox tWiDOLNesbeUad6Z/ws1w4sg4as23xIl61Ja9iKLjj5sIL+rO8XJ+9JqVTOkAiK2k4qk CBGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=8RnA5gwnHvzql5R+niVrxNxf3H0/X5BfHyTeX9NxfXg=; b=itfgs4rNIglRYgaHMBNQyrplIddLa0i7aywMspcl5EFCQFI/rFzp1HOoBDT2cwHuhp 4iQ9u43am0HGNSB8Xdvjl1gZ8Mj5TXO3dm8tol3cXuEJOvG0u6z7Vn+DBSsM6COMF1qk oGidTA2czfir3YTIbe2gRvcNP9hEKPWidHSQATXjNUq/WtPoCMIsNxwM8+vIq9k87DcW YWGWDwSd8oExGBv2//jsPQqq58/v+oL94F5ebY7Nr42GIS5DOlGU2id7Oy34/2Uhj8LS dD2uM3oicE/lMEpCYPJCRYqc6s2gEZxxMBbqwyOgPeFMDy2Zty3JHWzTPG45YdnRzNCU swNQ== X-Gm-Message-State: AOPr4FVTKmYJfjq4AZOaORTx1KZKSaBYQZn7nEtYtNRba41iSQsuc3FLfXBhr+8+P5jsVPSC8UDrB8vkRo9/Bw== MIME-Version: 1.0 X-Received: by 10.28.126.145 with SMTP id z139mr10952706wmc.81.1462567167636; Fri, 06 May 2016 13:39:27 -0700 (PDT) Sender: mglt.ietf@gmail.com Received: by 10.194.78.163 with HTTP; Fri, 6 May 2016 13:39:27 -0700 (PDT) In-Reply-To: References: Date: Fri, 6 May 2016 16:39:27 -0400 X-Google-Sender-Auth: 7PSz6uCmGyJV9S3LpxOvVnXe2aw Message-ID: From: Daniel Migault To: Tommy Pauly Content-Type: multipart/alternative; boundary=001a11417f1e7cbde4053232741c Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for adoption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 20:39:32 -0000 --001a11417f1e7cbde4053232741c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I have read the draft. TCP encapsulation is a topic that matters, and I would like different vendors to implement a standard version of this. I think the draft is in good shape to be adopted and discussed as a WG document. I am volunteering to continue reviewing the draft and contribute to the text once adopted. Please find here my comments. None of them are controversial and they should not prevent the adoption of the draft. BR, Daniel abstract: s/IPSec/IPsec "This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP." This seems to indicates that the method should only be used with IKEv2 which contradicts the title. Thus I would mention. When used with IKE, this method... We have to chose IKE or IKEv2. If IKE is chosen, then may specify that IKE means IKEv2. I have seen IKEV@ in appendix A section 2: """ The configuration defined on each peer should include the following parameters: o One or more TCP ports on which the responder will listen for incoming connections. Note that the initiator may initiate TCP connections to the responder from any local port. This document leaves the selection of TCP ports up to implementations. It's suggested to use TCP port 4500, which is allocated for IPSec NAT Traversal. """ I think that for interoperability, we should define a port at the IANA. If that port is 4500 we should detail why an how the two encapsulation method works. Are there any disadvantages of using an allocated port? One reason reason I suspect port agility may be needed is NAT. If so that should be clearly documented. """ Optionally, an extra framing protocol to use on top of TCP to further encapsulate the stream of IKEv2 and IPSec packets. See Appendix A for a detailed discussion. """ If I am correct the extra framing is TLS. If so I think it woudl be clearer to mention extra framing such as TLS. section 3.2 I think that we shoudl specify that ESP SPI MUST be non zero to avoid the confusion between ESP SPI and Non-ESP marker. section 4: My understanding is that the stream prefix is needed if because tcp does not have a mechanism that indicates the content of the streams. An IANA allocated port could could be such indicaton. In that case, would we need this prefix ? section 5: """ Any specific IKE SA, along with its Child SAs, is either TCP encapsulated or not. A mix of TCP and UDP encapsulation for a single SA is not allowed. """ If I understand this correctly it means: - a) IKEv2 SA using tcp encapsulation requires ESP to use TCP encapsulation. - b) an IKEv2 connection OR an ESP session cannot use TCP encapsulation or UDP or no encapsulation. I propose to have something similar to this: When IKEv2 is using TCP encapsulation, the negotiated ESP SA MUST be encapsulated with TCP. In fact a network may have different firewall rules for IKEv2 and ESP traffic. IKEv2 is an application identified with specific ports whereas ESP packets do not have ports.If the IKEv2 traffic and ESP were not using the same encapsulation method (non encapsulation, UDP encapsulation or TCP encapsulation), then IKEv2 would not be able to proceed to reachability tests of the ESP path, as IKEv2 and ESP would use different paths. In addition, IKEv2 would be expected to negotiate the ESP encapsulation between the peers. With UDP and TCP encapsulation, IKEv2 and ESP packet use the same port and transport protocol, which means that IKEv2 proceeds to the connectivity tests and set the tunnel. In the case non-encapsulated IKEv2 are not blocked, but that ESP packets are blocked, it is the responsibility of the IKEv2 client to DELETE the IKE_SA on both peers and than renegotiate the IKEv2 exchange using UDP and then TCP encapsulation. If IKEv2 peers are using TCP encapsulation, and both peer support UDP encapsulation as well as MOBIKE, then it can switch from TCP to UDP encapsulation for both IKEv2 and ESP traffic by using MOBIKE. The peer can advertise their respective support with MOBIKE_SUPPORTED and NAT_DETECTION_*_IP Notify Payloads. When one of the IKEv2 peer decides to switch from TCP to UDP encapsulation, all IKEv2 and ESP traffic is switched from TCP to UDP. Note that the other way around is not possible as IKEv2 does not advertise its support for TCP encapsulation. [note that using NAT_DETECTION_*_IP as an UDP_ENCAPSULATION_SUPPORTED only works when not encapsulated with UDP/TCP] section 6: Because of this text, I think it would be good to have a TCP encapsulation and TCP decapsulation sections that describes TCP and IPsec interactions. """ The original initiator (that is, the endpoint that initiated the TCP connection and sent the first IKE_SA_INIT message) is responsible for reestablishing the TCP connection if it is torn down for any unexpected reason. Since new TCP connections may use different ports due to NAT mappings or local port allocations changing, the responder MUST allow packets for existing SAs to be received from new source ports. """ Section 7: This re-define how NAT_DETECTION is performed over TCP. NAT_DETECTION may currently seen as a UDP_ENCAPSULATION_SUPPORTED notify payload to. This won't be the case anymore with IKEv2. Maybe we should provide more text on this. On Wed, Apr 27, 2016 at 2:38 PM, Tommy Pauly wrote: > Hello, > > Based on our discussions at IETF 95 and on the list, I=E2=80=99ve posted = a new > revision of the TCP Encapsulation draft ( > draft-pauly-ipsecme-tcp-encaps-04): > https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-04 > > The highlights of the new version are: > - Moved all references to TLS to an appendix, so it is not part of the > standard directly (Valery, I think this should address your concerns) > - Changed the length field to 16 bits to match 3GPP implementations > (thanks to Tero for this suggestion) > - Added a magic value to put once at the beginning of any TCP stream to > indicate that it is being used for IKEv2, to allow differentiation from > other streams if we re-use well-known ports (thanks to Yoav for this > suggestions) > > I believe this addresses all of the concerns brought up previously, so I= =E2=80=99d > like to see if we could get adoption from the working group to move this > draft forward. Please reply with your thoughts on this! > > Thanks, > Tommy Pauly > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > --001a11417f1e7cbde4053232741c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I have read the draft. TCP enc= apsulation is a topic that matters, and I would like different vendors to i= mplement a standard version of this. I think the draft is in good shape to = be adopted and discussed as a WG document. I am volunteering to continue re= viewing the draft and contribute to the text once adopted.

Please f= ind here my comments. None of them are controversial and they should not pr= event the adoption of the draft.


BR,
D= aniel

abstract:

s/IPSec/IPsec


"This met= hod is intended to be used as a fallback option when IKE
cannot be nego= tiated over UDP."

This seems to indicates that the method shoul= d only be used with IKEv2
which contradicts the title. Thus I would men= tion. When used with IKE,
this method...


We have to chose IK= E or IKEv2. If IKE is chosen, then may specify that
IKE means IKEv2. I = have seen IKEV@ in appendix A

section 2:
"""
Th= e configuration defined on each peer should include the following
param= eters:

=C2=A0=C2=A0 o=C2=A0 One or more TCP ports on which the respo= nder will listen for
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 incoming connections= .=C2=A0 Note that the initiator may initiate TCP
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 connections to the responder from any local port.

This doc= ument leaves the selection of TCP ports up to
=C2=A0=C2=A0 implementatio= ns.=C2=A0 It's suggested to use TCP port 4500, which is
=C2=A0=C2=A0= allocated for IPSec NAT Traversal.
"""
I think that f= or interoperability, we should define a port at the
IANA. If that port = is 4500 we should detail why an how the two
encapsulation method works.= Are there any disadvantages of using an
allocated port? One reason rea= son I suspect port agility may be needed
is NAT. If so that should be c= learly documented.

=C2=A0
"""
Optionally, an = extra framing protocol to use on top of TCP to
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 further encapsulate the stream of IKEv2 and IPSec packets.=C2=A0 See=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Appendix A for a detailed discussion."""

If I am correct the extra framing is TLS. If so = I think it woudl be
clearer to mention extra framing such as TLS.

section 3.2
I think that we shoudl specify that ESP SPI MUST be no= n zero to avoid
the confusion between ESP SPI and Non-ESP marker.=C2=A0=

section 4:

My understanding is that the stream prefix is ne= eded if because tcp
does not have a mechanism that indicates the conten= t of the streams.
An IANA allocated port could could be such indicaton.= In that case,
would we need this prefix ?

=C2=A0

section= 5:

"""
Any specific IKE SA, along with its Child = SAs, is either TCP
encapsulated or not.=C2=A0 A mix of TCP and UDP enca= psulation for a single
SA is not allowed.
"""

= If I understand this correctly it means:
=C2=A0=C2=A0=C2=A0 - a) IKEv2 S= A using tcp encapsulation requires ESP to use TCP
encapsulation.
= =C2=A0=C2=A0=C2=A0 - b) an IKEv2 connection OR an ESP session cannot use TC= P
encapsulation or UDP or no encapsulation.

I propose to have s= omething similar to this:

When IKEv2 is using TCP encapsulation, the= negotiated ESP SA MUST be
encapsulated with TCP.
In fact a network= may have different firewall rules for IKEv2 and ESP
traffic. IKEv2 is = an application identified with specific ports
whereas ESP packets do no= t have ports.If the IKEv2 traffic and ESP
were not using the same encap= sulation method (non encapsulation, UDP
encapsulation or TCP encapsulat= ion), then IKEv2 would not be able to
proceed to reachability tests of = the ESP path, as IKEv2 and ESP would
use different paths. In addition, = IKEv2 would be expected to negotiate
the ESP encapsulation between the = peers.

With UDP and TCP encapsulation, IKEv2 and ESP packet use the = same port
and transport protocol, which means that IKEv2 proceeds to th= e
connectivity tests and set the tunnel. In the case non-encapsulated <= br>IKEv2 are not blocked, but that ESP packets are blocked, it is the
r= esponsibility of the IKEv2 client to DELETE the IKE_SA on both peers
an= d than renegotiate the IKEv2 exchange using UDP and then TCP
encapsulat= ion.


If IKEv2 peers are using TCP encapsulation, and both peer = support UDP
encapsulation as well as MOBIKE, then it can switch from TC= P to UDP
encapsulation for both IKEv2 and ESP traffic by using MOBIKE. = The peer
can advertise their respective support with MOBIKE_SUPPORTED an= d
NAT_DETECTION_*_IP Notify Payloads. When one of the IKEv2 peer
de= cides to switch from TCP to UDP encapsulation, all IKEv2 and ESP
traffi= c is switched from TCP to UDP. Note that the other way around is
not po= ssible as IKEv2 does not advertise its support for TCP encapsulation.
[note that using NAT_DETECTION_*_IP as an UDP_ENCAPSULATION_SUPPORTED=C2= =A0 only works when not encapsulated with UDP/TCP]
=C2=A0

sectio= n 6:

Because of this text, I think it would be good to have a TCP encapsulation and TCP decapsulation sections that describes TCP and
<= br>IPsec interactions.


"""
=C2=A0The original = initiator (that is, the endpoint that initiated the TCP
connection and = sent the first IKE_SA_INIT message) is responsible for
reestablishing t= he TCP connection if it is torn down for any
unexpected reason.=C2=A0 S= ince new TCP connections may use different ports
due to NAT mappings or= local port allocations changing, the responder
MUST allow packets for = existing SAs to be received from new source
ports.
"""= ;

Section 7:

This re-define how NAT_DETECTION is performed ov= er TCP. NAT_DETECTION may currently seen as a UDP_ENCAPSULATION_SUPPORTED n= otify payload to. This won't be the case anymore with IKEv2. Maybe we s= hould provide more text on this.
=C2=A0


On Wed, Apr 27, 2016 at 2:38 PM, To= mmy Pauly <tpauly@apple.com> wrote:
Hello,

Bas= ed on our discussions at IETF 95 and on the list, I=E2=80=99ve posted a new= revision of the TCP Encapsulation draft (draft-pauly-ipsecme-tcp-encaps-04):
https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-0= 4

The highlights of the new version are:
=
- Moved all references to TLS to an appendix, so it is not part of the= standard directly (Valery, I think this should address your concerns)
- Changed the length field to 16 bits to match 3GPP implementations (= thanks to Tero for this suggestion)
- Added a magic value to put = once at the beginning of any TCP stream to indicate that it is being used f= or IKEv2, to allow differentiation from other streams if we re-use well-kno= wn ports (thanks to Yoav for this suggestions)

I b= elieve this addresses all of the concerns brought up previously, so I=E2=80= =99d like to see if we could get adoption from the working group to move th= is draft forward. Please reply with your thoughts on this!

Thanks,
Tommy Pauly

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


--001a11417f1e7cbde4053232741c-- From nobody Fri May 6 16:49:01 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D1C12D559 for ; Fri, 6 May 2016 16:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.996] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IoTIt55qYsHs for ; Fri, 6 May 2016 16:48:58 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 774CD12D53D for ; Fri, 6 May 2016 16:48:58 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3r1pQH67gXz5Sh; Sat, 7 May 2016 01:48:55 +0200 (CEST) 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 28IB6x5T8p1h; Sat, 7 May 2016 01:48:53 +0200 (CEST) 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; Sat, 7 May 2016 01:48:53 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 968C97342B2; Fri, 6 May 2016 19:48:51 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 968C97342B2 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8C30A406758D; Fri, 6 May 2016 19:48:51 -0400 (EDT) Date: Fri, 6 May 2016 19:48:51 -0400 (EDT) From: Paul Wouters To: Daniel Migault In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT Archived-At: Cc: IPsecME WG , Tommy Pauly Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for adoption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 23:49:00 -0000 On Fri, 6 May 2016, Daniel Migault wrote: > s/IPSec/IPsec If Tommy could also fix that auto-correct for my iphone, that would be great too :) > "This method is intended to be used as a fallback option when IKE > cannot be negotiated over UDP." > > This seems to indicates that the method should only be used with IKEv2 > which contradicts the title. Thus I would mention. When used with IKE, > this method... This has happened in this group a few times now in different documents. People want to say IKEv2 to exclude IKE, but we should really say IKE so these documents don't look weird when/if we get IKEv3. > I think that for interoperability, we should define a port at the > IANA. If that port is 4500 we should detail why an how the two > encapsulation method works. Are there any disadvantages of using an > allocated port? One reason reason I suspect port agility may be needed > is NAT. If so that should be clearly documented. We should not define a port unless it is 443, which we kind of cannot. > I think that we shoudl specify that ESP SPI MUST be non zero to avoid > the confusion between ESP SPI and Non-ESP marker.  First I thought this was not needed, because RFC-3948 would define that, but it does look confusing because it is mentioned in the section titled "UDP-Encapsulated ESP Header format": https://tools.ietf.org/html/rfc3948#section-2.1 So the draft should probably include something simiar to that section. > An IANA allocated port could could be such indicaton. In that case, > would we need this prefix ? We all know SSL VPNs exist because some networks block (4)500 on purpose. > """ > Any specific IKE SA, along with its Child SAs, is either TCP > encapsulated or not.  A mix of TCP and UDP encapsulation for a single > SA is not allowed. > """ Note: what it you suddenly notice you can go back to UDP. Wouldn't you have a mix while you migrate all the TCP-ESP to UDP-ESP? > If I understand this correctly it means: >     - a) IKEv2 SA using tcp encapsulation requires ESP to use TCP > encapsulation. >     - b) an IKEv2 connection OR an ESP session cannot use TCP > encapsulation or UDP or no encapsulation. > > I propose to have something similar to this: > > When IKEv2 is using TCP encapsulation, the negotiated ESP SA MUST be > encapsulated with TCP. It might be best to avoid making any statement on this. For example libreswan introduced a force-encaps= option to work around Amazon not routing ESP packets. If you mention anything for IKE vs ESP you might add limitations that might cause problems later on. While I think we should have SHOULD language on trying to move TCP sessions to UDP, I wouldn't go as far to forbid certain combinations. > In fact a network may have different firewall rules for IKEv2 and ESP > > """ >  The original initiator (that is, the endpoint that initiated the TCP > connection and sent the first IKE_SA_INIT message) is responsible for > reestablishing the TCP connection if it is torn down for any > unexpected reason.  Since new TCP connections may use different ports > due to NAT mappings or local port allocations changing, the responder > MUST allow packets for existing SAs to be received from new source > ports. > """ > > Section 7: > > This re-define how NAT_DETECTION is performed over TCP. NAT_DETECTION may currently seen as a > UDP_ENCAPSULATION_SUPPORTED notify payload to. This won't be the case anymore with IKEv2. Maybe we > should provide more text on this. well, on UDP it is obvious the port can change and you can just update the port on the receiver based on the last received udp port. with tcp clearly you know when it is being shut down. I'm not sure if the receiver should keep such an orphaned IKE SA while waiting for another TCP session to come in though. It might make sense of there is a DOS attack using spoofed RST packets, but the attacker can't be stopped anyway. Paul From nobody Wed May 11 05:38:32 2016 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 9BB6F12D12B; Wed, 11 May 2016 05:38:30 -0700 (PDT) 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.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160511123830.15198.80422.idtracker@ietfa.amsl.com> Date: Wed, 11 May 2016 05:38:30 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-08.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 12:38:30 -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 of the IETF. Title : Algorithm Implementation Requirements and Usage Guidance for IKEv2 Authors : Yoav Nir Tero Kivinen Paul Wouters Daniel Migault Filename : draft-ietf-ipsecme-rfc4307bis-08.txt Pages : 16 Date : 2016-05-11 Abstract: The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE) protocol is used to negotiate the IPsec Security Association (IPsec SA) parameters, such as which algorithms should be used. To ensure interoperability between different implementations, it is necessary to specify a set of algorithm implementation requirements and usage guidance to ensure that there is at least one algorithm that all implementations support. This document defines the current algorithm implementation requirements and usage guidance for IKEv2. This document does not update the algorithms used for packet encryption using IPsec Encapsulated Security Payload (ESP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc4307bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-08 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 Wed May 11 05:47:59 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8320312D681 for ; Wed, 11 May 2016 05:47:58 -0700 (PDT) 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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07L1tbU7-n3M for ; Wed, 11 May 2016 05:47:51 -0700 (PDT) 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 2B98512DA82 for ; Wed, 11 May 2016 05:47:42 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u4BCldYe003954 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 11 May 2016 15:47:39 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u4BCldBZ007198; Wed, 11 May 2016 15:47:39 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22323.10731.707429.981842@fireball.acr.fi> Date: Wed, 11 May 2016 15:47:39 +0300 From: Tero Kivinen To: ipsec@ietf.org In-Reply-To: <20160511123830.15198.80422.idtracker@ietfa.amsl.com> References: <20160511123830.15198.80422.idtracker@ietfa.amsl.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 8 min X-Total-Time: 8 min Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-08.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 12:47:58 -0000 This version includes changes from the WGLC. Changes include: - In section 1.2 changed the "set to MAY" to "denoted here as MAY" (Yaron). - Added text to end of 1.2: "Requirement levels that are marked as "IoT" apply to IoT devices and to server-side implementations that might presumably need to interoperate with them, including any general- purpose VPN gateways." (Yaron). - Removed text from section 1.3 saying that recommendations are useful for users, i.e., the text now says: "On the other hand, comments from this document are also expected to be useful for such users.". I.e., this tries to clarify that recommendations are for implementors, the comments for algorithms are something that are useful for users too. (Quynh) - Reformatted the AUTH_DES_MAC text a bit. Mention that both MD5 and DES are being deprecated. Even if the last sentence only covers MD5 it does not matter, as it clearly says that sentence covers MD5 only. (Yaron) Current text is AUTH_DES_MAC, AUTH_HMAC_MD5_96, and AUTH_KPDK_MD5 were not mentioned in RFC4307 so their default status ware MAY. They have been downgraded to MUST NOT. There is an industry-wide trend to deprecate DES and MD5. MD5 support is being removed from cryptographic libraries in general because its non-HMAC use is known to be subject to collision attacks, for example as mentioned in [TRANSCRIPTION]. - Changed 4.2 text has been changed to clarify that all these are only for "Digital Signatures authentication method" (Valery) - Changed RSASSA-PSS with SHA-256 to MUST from SHOULD as now it is clear that this table is only applied if Digital Signature authentication method is implemented. (Valery) internet-drafts@ietf.org writes: > 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 of the IETF. > > Title : Algorithm Implementation Requirements and Usage Guidance for IKEv2 > Authors : Yoav Nir > Tero Kivinen > Paul Wouters > Daniel Migault > Filename : draft-ietf-ipsecme-rfc4307bis-08.txt > Pages : 16 > Date : 2016-05-11 > > Abstract: > The IPsec series of protocols makes use of various cryptographic > algorithms in order to provide security services. The Internet Key > Exchange (IKE) protocol is used to negotiate the IPsec Security > Association (IPsec SA) parameters, such as which algorithms should be > used. To ensure interoperability between different implementations, > it is necessary to specify a set of algorithm implementation > requirements and usage guidance to ensure that there is at least one > algorithm that all implementations support. This document defines > the current algorithm implementation requirements and usage guidance > for IKEv2. This document does not update the algorithms used for > packet encryption using IPsec Encapsulated Security Payload (ESP). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc4307bis/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-08 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-08 > > > 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/ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec -- kivinen@iki.fi From nobody Wed May 11 05:50:02 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1124B12D678 for ; Wed, 11 May 2016 05:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.996] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqWaO79YDva5 for ; Wed, 11 May 2016 05:50:00 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD4D212D0EB for ; Wed, 11 May 2016 05:49:59 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3r4bYf1Ybgz3Tv; Wed, 11 May 2016 14:49:58 +0200 (CEST) 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 4jSV7lTdqI7W; Wed, 11 May 2016 14:49:57 +0200 (CEST) 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; Wed, 11 May 2016 14:49:57 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 9D24672437A; Wed, 11 May 2016 08:49:55 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 9D24672437A Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 9618843813CD; Wed, 11 May 2016 08:49:55 -0400 (EDT) Date: Wed, 11 May 2016 08:49:55 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" In-Reply-To: <20160511123830.15198.80422.idtracker@ietfa.amsl.com> Message-ID: References: <20160511123830.15198.80422.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: Tero Kivinen Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-08.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 12:50:01 -0000 On Wed, 11 May 2016, internet-drafts@ietf.org wrote: > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-08 Thanks Tero, My only question is regarding the table formerly known as table 9. If we concluded that RFC7427 is not widely implemented yet, is there any reason to keep 5 SHOULD NOT entries there instead of making those MUST NOT ? Paul From nobody Wed May 11 08:11:53 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20B2E12D1DB for ; Wed, 11 May 2016 08:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QULZH9yK6prj for ; Wed, 11 May 2016 08:11:43 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0106.outbound.protection.outlook.com [23.103.200.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F66E12D6DF for ; Wed, 11 May 2016 08:11:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0lDFCDE31UzGUelKHawvSXcqs3DBVe+4BbjVLuS8VLk=; b=Hi1d/erfaK8jWHDe9zdFOyEyVPV785JgzA5IDL1VeD1hVvhhJDBxcgA65gerooygAXHBIFhYMumLgUI3qwodJESNiTVa2eAvKf08KAMS9YN5OW0KEWwDsSmaqz5bhKSmjNFBoZo0a2/c1HAgJFplE80SiTbMkJmq2g/+R6Yprio= Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) with Microsoft SMTP Server (TLS) id 15.1.492.11; Wed, 11 May 2016 15:11:42 +0000 Received: from BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) by BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) with mapi id 15.01.0492.016; Wed, 11 May 2016 15:11:42 +0000 From: "Dang, Quynh (Fed)" To: IPsecME WG Thread-Topic: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-08.txt Thread-Index: AQHRq4INlfo3vaZ24EeajDZUeKdQeZ+z1mIF Date: Wed, 11 May 2016 15:11:42 +0000 Message-ID: References: <20160511123830.15198.80422.idtracker@ietfa.amsl.com> In-Reply-To: <20160511123830.15198.80422.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.105.150] x-ms-office365-filtering-correlation-id: 0f33967b-3919-4d86-6c4b-08d379ae8f72 x-microsoft-exchange-diagnostics: 1; BN1PR09MB124; 5:egj8AMNlJzwNBI7TwfvINj2BsnGBYpZbCNR8B4HBS3BT7F0YKicOmtOUjExEqgAYaJ8/so6tIimFlp5SxLgXU2v4WCTXzigXELULgKuP1iTKII0V3Uyhi+gDJ9j4IqwQbdEtbTes8JuTNP07eL+AiA==; 24:eb0+VLp3R6ETQlJW3pQqR81wsMiGXZIMx6xS/2p8Mk2XJHK+ovRDHS0Gh19vD0v5LUa+4cNUE36YVqMfVDSVh9k4xhd6r0PZRGfbW4sEYl8=; 7:wMBeR0ufhMNlO/+349JUx4lpFkJX1NVB8YXzL72WAIorFmsjkk6cVo4Pfp0fUipXiJNVXRXn3aHWpQ4l0gbqECKJRRwi4wDtZZWzbWUdN/o9b+Hazf8KIgmPtyhdZBpWCCMNYb9qrOLSFXz89/UgFps/h6hAJ/xdu2+Wni4MgvAevX8YZ+kO29rQlTK/1FJ8 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB124; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:BN1PR09MB124; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB124; x-forefront-prvs: 0939529DE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(53754006)(377424004)(377454003)(110136002)(107886002)(86362001)(66066001)(19580405001)(5008740100001)(189998001)(15975445007)(92566002)(77096005)(3846002)(450100001)(102836003)(6116002)(76576001)(122556002)(81166006)(586003)(5004730100002)(11100500001)(33656002)(87936001)(19580395003)(1220700001)(10400500002)(3280700002)(2906002)(54356999)(50986999)(76176999)(5003600100002)(5002640100001)(3660700001)(8936002)(2950100001)(2900100001)(106116001)(230783001)(9686002)(74316001)(99286002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB124; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2016 15:11:42.3845 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB124 Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-08.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 15:11:47 -0000 Hi all, As I explained before, the group numbers 5 and 2 should become "MUST NOT" = because they don't provide 112 bits of security. And, all signatures with SHA1 should become "MUST NOT". Regards, Quynh. ________________________________________ From: IPsec on behalf of internet-drafts@ietf.org = Sent: Wednesday, May 11, 2016 8:38:30 AM To: i-d-announce@ietf.org Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-08.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Security Maintenance and Extensions of = the IETF. Title : Algorithm Implementation Requirements and Usage G= uidance for IKEv2 Authors : Yoav Nir Tero Kivinen Paul Wouters Daniel Migault Filename : draft-ietf-ipsecme-rfc4307bis-08.txt Pages : 16 Date : 2016-05-11 Abstract: The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE) protocol is used to negotiate the IPsec Security Association (IPsec SA) parameters, such as which algorithms should be used. To ensure interoperability between different implementations, it is necessary to specify a set of algorithm implementation requirements and usage guidance to ensure that there is at least one algorithm that all implementations support. This document defines the current algorithm implementation requirements and usage guidance for IKEv2. This document does not update the algorithms used for packet encryption using IPsec Encapsulated Security Payload (ESP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc4307bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-rfc4307bis-08 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed May 11 08:50:17 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB70B12D1CF for ; Wed, 11 May 2016 08:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.996] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtfiE7GWOS-L for ; Wed, 11 May 2016 08:50:14 -0700 (PDT) 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 BB21412D1B7 for ; Wed, 11 May 2016 08:50:14 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3r4gYb5K9Pz3FT; Wed, 11 May 2016 17:50:11 +0200 (CEST) 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 hIF75K9ADlfk; Wed, 11 May 2016 17:50:10 +0200 (CEST) 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; Wed, 11 May 2016 17:50:10 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 7362772437D; Wed, 11 May 2016 11:50:09 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 7362772437D Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 60B2A43B4307; Wed, 11 May 2016 11:50:09 -0400 (EDT) Date: Wed, 11 May 2016 11:50:09 -0400 (EDT) From: Paul Wouters To: "Dang, Quynh (Fed)" In-Reply-To: Message-ID: References: <20160511123830.15198.80422.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-08.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 15:50:16 -0000 On Wed, 11 May 2016, Dang, Quynh (Fed) wrote: > As I explained before, the group numbers 5 and 2 should become "MUST NOT" because they don't provide 112 bits of security. Checking RFC 4307, group 2 was MUST- so it should go to SHOULD NOT but _maybe_ can go to MUST NOT. For some reason, group 5 was not listed in RFC 4307, so it mist have been a MAY, which would allow us to go to MUST NOT. But it would be weird to have group 2 SHOULD NOT and group 5 MUST NOT. Personally, I have no problem with IKEv2 dropping group 2/5. All IKEv2 clients should have defaulted to group 14 for years now. Obviously, I won't kick group 2/5 out of IKEv1. > And, all signatures with SHA1 should become "MUST NOT". SHA1 was a MUST, so we cannot go to MUST NOT. Instead of MUST- we could go to SHOULD NOT. But I don't know how widespread SHA1 is with IKEv2. Paul From nobody Wed May 11 10:58:27 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 619D212B01F for ; Wed, 11 May 2016 10:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZGzPGqhWQWW for ; Wed, 11 May 2016 10:58:23 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0090.outbound.protection.outlook.com [23.103.200.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D783F12D0F4 for ; Wed, 11 May 2016 10:58:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VNOTF36sH/cM3jXxQTLKuVOezo3avwerP9Lv3tAP4RU=; b=ZVfkSkSQ5JLrYdLjpPCgFMh7brITteNQ59f+4Wb3XFCHFxxbDQZu9s+sBSSdpmvNau4xzSaP0Q8ijfd062Ja/+GiCOEfO3DfhZBhpGnSWF0hk15HruA5ODMh703f0pl6ySX6USDYZBur7i8FMbfzT21axl960DHlN4D0oBnPhys= Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB123.namprd09.prod.outlook.com (10.255.200.25) with Microsoft SMTP Server (TLS) id 15.1.492.11; Wed, 11 May 2016 17:58:21 +0000 Received: from BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) by BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) with mapi id 15.01.0492.016; Wed, 11 May 2016 17:58:21 +0000 From: "Dang, Quynh (Fed)" To: "paul@nohats.ca" Thread-Topic: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-08.txt Thread-Index: AQHRq4INlfo3vaZ24EeajDZUeKdQeZ+z1mIFgAAMMYCAAB0NyQ== Date: Wed, 11 May 2016 17:58:20 +0000 Message-ID: References: <20160511123830.15198.80422.idtracker@ietfa.amsl.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nohats.ca; dkim=none (message not signed) header.d=none;nohats.ca; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.105.150] x-ms-office365-filtering-correlation-id: 6c539f7e-6575-4171-9405-08d379c5d704 x-microsoft-exchange-diagnostics: 1; BN1PR09MB123; 5:Gjekds7d7dNVxlWy7hi6Dh87dTZSQcCoX1a08cpixqDxovbpMDVgMPR19KjJXxlU0Xg1nFyqxoBITWi5cqcU9MirmdK+ZNFtUoHuu0XfiXQMYmKL4m8n0jUjms+zSacUYLhQhNJ23ZBJ1pG2OC24kg==; 24:2u14aDkTRyQdz+3MaJEV47bwGlHTNE/zC3JFW3Z7IspHEKnXxJ7ZmqY6NesWJOAXJiCIB7XiqFZjSXon8Blv0ohhgMmRqe0mCDHl/vDedPQ=; 7:t3vsqUfNIOWhF4e8y5a6fQ1awLfBlWqHOSl7tCRUxiTdFHR/5XeYbJypw2PVIHHs0X2lwOS84npfcmUJDATGPLG61/9CCiI2tpb8Ox9GD8S9q7UMpzm5t4IpnRUPd5QUXuv+jcZnG33YB5W+9hwD/dBGNGsgFHUZAj7j/l0MFDW//+CMBPFX4Vvs0hZtZcUD x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB123; x-ld-processed: 2ab5d82f-d8fa-4797-a93e-054655c61dec,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:BN1PR09MB123; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB123; x-forefront-prvs: 0939529DE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(5002640100001)(189998001)(66066001)(8936002)(230783001)(122556002)(76576001)(33656002)(2906002)(81166006)(87936001)(586003)(1730700002)(74316001)(5640700001)(92566002)(106116001)(19580405001)(5008740100001)(1220700001)(76176999)(6116002)(19580395003)(50986999)(102836003)(3846002)(54356999)(11100500001)(3280700002)(2351001)(5004730100002)(10400500002)(4326007)(2900100001)(2501003)(110136002)(2950100001)(86362001)(5003600100002)(9686002)(77096005)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB123; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2016 17:58:20.9635 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB123 Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-08.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 17:58:25 -0000 Hi Paul, We should explain that current MTI group is the group 2. However, users sha= ll not use that group and the group. We should create a similar statement f= or SHA1 in signatures. If a system has interoperability issue with the requirement, a user needs t= o upgrade his or her system. If she or he ignores our requirement/recommend= ation and uses the group 2 (or group 5), none of us can stop them from doin= g that and our requirement would become a great reminder to her or him that= what he or she is doing is bad and does not comply with our recommendation= s. Regards, Quynh. ________________________________________ From: Paul Wouters Sent: Wednesday, May 11, 2016 11:50:09 AM To: Dang, Quynh (Fed) Cc: IPsecME WG Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-08.txt On Wed, 11 May 2016, Dang, Quynh (Fed) wrote: > As I explained before, the group numbers 5 and 2 should become "MUST NOT= " because they don't provide 112 bits of security. Checking RFC 4307, group 2 was MUST- so it should go to SHOULD NOT but _maybe_ can go to MUST NOT. For some reason, group 5 was not listed in RFC 4307, so it mist have been a= MAY, which would allow us to go to MUST NOT. But it would be weird to have group 2 SHOULD NOT and group 5 MUST NOT. Personally, I have no problem with IKEv2 dropping group 2/5. All IKEv2 clients should have defaulted to group 14 for years now. Obviously, I won't kick group 2/5 out of IKEv1. > And, all signatures with SHA1 should become "MUST NOT". SHA1 was a MUST, so we cannot go to MUST NOT. Instead of MUST- we could go to SHOULD NOT. But I don't know how widespread SHA1 is with IKEv2. Paul From nobody Wed May 11 11:15:29 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 946BC12D10A for ; Wed, 11 May 2016 11:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.996] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8vZh5FY4vV9 for ; Wed, 11 May 2016 11:15:27 -0700 (PDT) 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 29ED912B028 for ; Wed, 11 May 2016 11:15:27 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3r4kn854zSz3Ds; Wed, 11 May 2016 20:15:24 +0200 (CEST) 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 r3piGTSBqe7g; Wed, 11 May 2016 20:15:23 +0200 (CEST) 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; Wed, 11 May 2016 20:15:22 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 0E15372437D; Wed, 11 May 2016 14:15:21 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 0E15372437D Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id EF78243B4307; Wed, 11 May 2016 14:15:21 -0400 (EDT) Date: Wed, 11 May 2016 14:15:21 -0400 (EDT) From: Paul Wouters To: "Dang, Quynh (Fed)" In-Reply-To: Message-ID: References: <20160511123830.15198.80422.idtracker@ietfa.amsl.com> , User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-08.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 18:15:28 -0000 On Wed, 11 May 2016, Dang, Quynh (Fed) wrote: > We should explain that current MTI group is the group 2. But it is not? The only MUST entry for Type 4 is Group 14 (modp2048) Group 2 is SHOULD NOT. > However, users shall not use that group and the group. We should create a similar statement for SHA1 in signatures. What users should or should not do and what implementations offer as default or not are out of scope for this document as explained in: https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-07#section-1.3 The recommendations of this document mostly target IKEv2 implementers as implementations need to meet both high security expectations as well as high interoperability between various vendors and with different versions. Interoperability requires a smooth move to more secure cipher suites. This may differ from a user point of view that may deploy and configure IKEv2 with only the safest cipher suite. On the other hand, comments and recommendations from this document are also expected to be useful for such users. In other words, the document sets the lowest acceptable bar. An implementation only implementing MUST algorithms is obviously more secure than an implementation that implements SHUOLD NOT algorithms. Paul From nobody Wed May 11 12:02:46 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E12912D792 for ; Wed, 11 May 2016 12:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPhkgD5uOjvs for ; Wed, 11 May 2016 12:02:43 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0136.outbound.protection.outlook.com [23.103.200.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53B5312D7A9 for ; Wed, 11 May 2016 12:01:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZU57iVqcO0eL+cw+0GWs/tQMXgv0FOMoW+BNGtDsp18=; b=c6phgZunTVcJueXQBW2K4It1tzpEawwht48jr99d0HAFdP1rl/YZYFHZnJm7LkoqlboOppjd0QYYE1xDjvisYt9Cb9auJgqNbUGeJHDuqVorgzGnw1l74LUxv256+0VOSRU46IObo+axNv1SrWiCZS2elEERUOnvQfc8LfuXrlY= Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB123.namprd09.prod.outlook.com (10.255.200.25) with Microsoft SMTP Server (TLS) id 15.1.492.11; Wed, 11 May 2016 19:01:33 +0000 Received: from BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) by BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) with mapi id 15.01.0492.016; Wed, 11 May 2016 19:01:33 +0000 From: "Dang, Quynh (Fed)" To: "paul@nohats.ca" , IPsecME WG Thread-Topic: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-08.txt Thread-Index: AQHRq4INlfo3vaZ24EeajDZUeKdQeZ+z1mIFgAAMMYCAAB0NyYAAC4SAgAAG7Wc= Date: Wed, 11 May 2016 19:01:33 +0000 Message-ID: References: <20160511123830.15198.80422.idtracker@ietfa.amsl.com> , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nohats.ca; dkim=none (message not signed) header.d=none;nohats.ca; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.105.150] x-ms-office365-filtering-correlation-id: fb17129e-0a09-4557-cd38-08d379ceaba6 x-microsoft-exchange-diagnostics: 1; BN1PR09MB123; 5:BpvjgEoenFq8RHi9/hbSeu8/6jlVqFC7/6770UpsF7LOSO6e9+NcOoT7QaQOXW/M0/h+af4h0qOD6IjfRt+bWCVrpkGO3ZnEBe/n1FSU63V9sVlOO40I8OdjD8eN57OWlb01sgaTmAJDEByaltQP6g==; 24:PZFws6K4ArYePWex8V+H7RfIKW/SQ9tGfvw3+mThx2u5H5mZHDey83cU7rtHx4pbRkVKvW0OalyWZ12oIv4cjLRprMpcnsQ4Of5r98qfk0E=; 7:ASjg5XkVxEfjX5GYN5jMPoBSdGEyML/weQOhUyk6zFzI9n4KLaEKpUVNYXI5JxHwdbhk/QpLCwaXoRJd5FQfmqnSIw+FD75zLzn+raEDuXvBTbvEtsbriZsuEGhYno7a732D4I3pZGc8EbAGkiSZRZt7HjZoBGgb1sGVntkSjurHQujuL1PuzSC6zojLezqD x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB123; x-ld-processed: 2ab5d82f-d8fa-4797-a93e-054655c61dec,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:BN1PR09MB123; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB123; x-forefront-prvs: 0939529DE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(50986999)(11100500001)(19580395003)(3280700002)(3846002)(102836003)(54356999)(1220700001)(6116002)(76176999)(5004730100002)(10400500002)(74316001)(586003)(5001770100001)(106116001)(5008740100001)(19580405001)(92566002)(3660700001)(93886004)(77096005)(107886002)(5003600100002)(2950100001)(9686002)(2900100001)(86362001)(2501003)(230783001)(15975445007)(122556002)(5002640100001)(189998001)(66066001)(8936002)(3900700001)(2906002)(87936001)(81166006)(76576001)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB123; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2016 19:01:33.4431 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB123 Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-08.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 19:02:45 -0000 Hi Paul,=20 I meant implementations conforming to the RFC 4307 which implemented the gr= oup 2. However, users must not use the group 2 because it is not secure at = this time.=20 If we want users not to use bad options, then we must prohibit them with "M= UST NOT" for implementations. There are no reasons for saying "allowed" to= implement them while asking users not to use them unless we want to say to= users they are allowed to be used.=20 This text "On the other hand, comments and recommendations from this docume= nt are also expected to be useful for such users." and the document says th= at the groups 2 and 5 are allowed "SHOULD NOT, not MUST NOT". All of the= se seem to tell users that these groups are allowed to use.=20 Regards, Quynh.=20 ________________________________________ From: Paul Wouters Sent: Wednesday, May 11, 2016 2:15 PM To: Dang, Quynh (Fed) Cc: IPsecME WG Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-08.txt On Wed, 11 May 2016, Dang, Quynh (Fed) wrote: > We should explain that current MTI group is the group 2. But it is not? The only MUST entry for Type 4 is Group 14 (modp2048) Group 2 is SHOULD NOT. > However, users shall not use that group and the group. We should create = a similar statement for SHA1 in signatures. What users should or should not do and what implementations offer as default or not are out of scope for this document as explained in: https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-07#section-1.3 The recommendations of this document mostly target IKEv2 implementers as implementations need to meet both high security expectations as well as high interoperability between various vendors and with different versions. Interoperability requires a smooth move to more secure cipher suites. This may differ from a user point of view that may deploy and configure IKEv2 with only the safest cipher suite. On the other hand, comments and recommendations from this document are also expected to be useful for such users. In other words, the document sets the lowest acceptable bar. An implementation only implementing MUST algorithms is obviously more secure than an implementation that implements SHUOLD NOT algorithms. Paul From nobody Wed May 11 12:47:55 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA17312D7FC for ; Wed, 11 May 2016 12:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.996] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcPAZvfzsRu0 for ; Wed, 11 May 2016 12:47:52 -0700 (PDT) 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 B404012D7C0 for ; Wed, 11 May 2016 12:47:34 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3r4mqS0hPSz3Tx; Wed, 11 May 2016 21:47:32 +0200 (CEST) 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 DoYbOCMLxlUo; Wed, 11 May 2016 21:47:30 +0200 (CEST) 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; Wed, 11 May 2016 21:47:30 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id DC526C0C7C; Wed, 11 May 2016 15:47:29 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca DC526C0C7C Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C9B71406B787; Wed, 11 May 2016 15:47:29 -0400 (EDT) Date: Wed, 11 May 2016 15:47:29 -0400 (EDT) From: Paul Wouters To: "Dang, Quynh (Fed)" In-Reply-To: Message-ID: References: <20160511123830.15198.80422.idtracker@ietfa.amsl.com> , , User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-08.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 19:47:54 -0000 On Wed, 11 May 2016, Dang, Quynh (Fed) wrote: > I meant implementations conforming to the RFC 4307 which implemented the group 2. However, users must not use the group 2 because it is not secure at this time. I disagree that group 2 is not secure. If it was _really_ not secure it would be a candidate for an urgent MUST NOT. > If we want users not to use bad options That is outside the scope of this document. > This text "On the other hand, comments and recommendations from this document are also expected to be useful for such users." and the document says that the groups 2 and 5 are allowed "SHOULD NOT, not MUST NOT". All of these seem to tell users that these groups are allowed to use. that's not how I interpret that. I interpret that as "avoid when possible, there if really needed". Paul From nobody Thu May 12 03:06:52 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E306412D8D8 for ; Thu, 12 May 2016 03:06:50 -0700 (PDT) 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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B_kSO0dODUBx for ; Thu, 12 May 2016 03:06:48 -0700 (PDT) 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 48EA012D8C4 for ; Thu, 12 May 2016 03:05:18 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u4CA5ES0015290 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 12 May 2016 13:05:14 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u4CA5EVS011958; Thu, 12 May 2016 13:05:14 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22324.21850.40571.811336@fireball.acr.fi> Date: Thu, 12 May 2016 13:05:14 +0300 From: Tero Kivinen To: "Dang\, Quynh \(Fed\)" In-Reply-To: References: <20160511123830.15198.80422.idtracker@ietfa.amsl.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 11 min X-Total-Time: 10 min Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-08.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 10:06:51 -0000 Dang, Quynh (Fed) writes: > As I explained before, the group numbers 5 and 2 should become > "MUST NOT" because they don't provide 112 bits of security. And the reply was that as group 2 is the currently used group, changing them to MUST NOT now would cause huge issues for the users. And the comments for users says that "It is expected in the near future to be downgraded to MUST NOT.", so the users knows that they should move away from it. I do not think we can do anything for this now, in the next version of this document (in 2-3 years) we will make them MUST NOT. > And, all signatures with SHA1 should become "MUST NOT". We currently do not really have a way to do that. The most commonly used signature method now is "RSA Digital Signature" with SHA1, but there is no negotiation of hash algorithm to be used in there, thus making it MUST NOT there would cause big interoperability issues, as peers cannot agree not to use SHA1. In the Digital Signature authentication method, there is a method to negotiate hash algorithms, and there we say that SHA1 is SHOULD NOT, which is aligned with other recommendations for SHA1 in the draft. We could change them to MUST NOT, as people have not implemented Digital Signature authentication method yet, so they can also implement SHA2 (and RSASSA-PSS) while implementing it and there the peers can negotiate the hash algorithm to be used. So here we cannot get rid of the most commonly used SHA1 signature method, but we can make it so that when people do implement Digital Signature authentication method, they will not implement SHA1 based signatures at all, and only do the safe hash algorithms. I.e. change 4.2 to say: +--------+-------------+------------+---------+ | Number | Description | Status | Comment | +--------+-------------+------------+---------+ | 1 | SHA1 | MUST NOT | | | 2 | SHA2-256 | MUST | | | 3 | SHA2-384 | MAY | | | 4 | SHA2-512 | SHOULD | | +--------+-------------+------------+---------+ and +------------------------------------+------------+---------+ | Description | Status | Comment | +------------------------------------+------------+---------+ | RSASSA-PSS with SHA-256 | MUST | | | ecdsa-with-sha256 | SHOULD | | | sha1WithRSAEncryption | MUST NOT | | | dsa-with-sha1 | MUST NOT | | | ecdsa-with-sha1 | MUST NOT | | | RSASSA-PSS with Empty Parameters | MUST NOT | | | RSASSA-PSS with Default Parameters | MUST NOT | | +------------------------------------+------------+---------+ -- kivinen@iki.fi From nobody Thu May 12 03:24:09 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27BED12D8BB for ; Thu, 12 May 2016 03:24:08 -0700 (PDT) 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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NC_boj72CJF9 for ; Thu, 12 May 2016 03:24:07 -0700 (PDT) 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 4ECCD12DBB0 for ; Thu, 12 May 2016 03:21:15 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u4CALD3M000351 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 12 May 2016 13:21:13 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u4CALDZp022639; Thu, 12 May 2016 13:21:13 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22324.22809.54109.213161@fireball.acr.fi> Date: Thu, 12 May 2016 13:21:13 +0300 From: Tero Kivinen To: "Dang\, Quynh \(Fed\)" In-Reply-To: References: <20160511123830.15198.80422.idtracker@ietfa.amsl.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 10 min X-Total-Time: 9 min Archived-At: Cc: IPsecME WG , "paul@nohats.ca" Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-08.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 10:24:08 -0000 Dang, Quynh (Fed) writes: > I meant implementations conforming to the RFC 4307 which implemented > the group 2. However, users must not use the group 2 because it is > not secure at this time. Implementation conforming to RFC4307 can decide NOT to implement group 2 or SHA1. You have to remember what SHOULD NOT means: 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. In this case the valid reasons why implementations want to implement group 2 is because not implementing it causes interoperability issues with old version. This does NOT give any guidance or recommendations for the users. We are talking mostly about the implementors here not users when we make those recommendations. > If we want users not to use bad options, then we must prohibit them > with "MUST NOT" for implementations. There are no reasons for saying > "allowed" to implement them while asking users not to use them > unless we want to say to users they are allowed to be used. If implementation prohibits them using it and users notice this cause interoperability issue, users will simply switch to some other product that works, i.e., SSL 3.0 VPN, IKEv1, or simply do not upgrade to the new version as it breaks things. > This text "On the other hand, comments and recommendations from this > document are also expected to be useful for such users." and the > document says that the groups 2 and 5 are allowed "SHOULD NOT, not > MUST NOT". All of these seem to tell users that these groups are > allowed to use. This text was changed in the latest draft, based on your comments. Now it says: 1.3. Document Audience The recommendations of this document mostly target IKEv2 implementers as implementations need to meet both high security expectations as well as high interoperability between various vendors and with different versions. Interoperability requires a smooth move to more secure cipher suites. This may differ from a user point of view that may deploy and configure IKEv2 with only the safest cipher suite. On the other hand, comments from this document are also expected to be useful for such users. I.e., now it does not even claim to give any recommendations for the users, it just says that the comments we have for the algorithms are something that might also be useful for such users. If you think this is not clear enough, we can change it to say: 1.3. Document Audience The recommendations of this document mostly target IKEv2 implementers as implementations need to meet both high security expectations as well as high interoperability between various vendors and with different versions. Interoperability requires a smooth move to more secure cipher suites. This may differ from a user point of view that may deploy and configure IKEv2 with only the safest cipher suite. This document does not give any recommendations for the use of algorithms, it only gives implementation recommendations for implementations. The use of algorithms by users is dictated by the security policy requirements for that specific user, and are outside the scope of this document. -- kivinen@iki.fi From nobody Thu May 12 05:32:00 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F1212D9B2 for ; Thu, 12 May 2016 05:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OGLh6-BczMV for ; Thu, 12 May 2016 05:31:56 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0112.outbound.protection.outlook.com [23.103.200.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A83412D9B0 for ; Thu, 12 May 2016 05:31:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=usZrBpEe0IMNromPD80bwf3nKpISwVs581ASqmZDuxo=; b=e8MB1y2fmCLzHCE0YF2CBLuALJPlLh1oQo9ZIJGxSplUuTT3GSXIaiHhwSMEkdU1DEnDbFXUbXpxSIcsbRQ9+6Fc6Xkgbqm4hnclEkBtxPD3HC+cj8rk+WoUmQsQop1NehwZL+xGWuVKyuPHAPbqAXDLU6ovkZi2XeUqDHxXRCU= Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB122.namprd09.prod.outlook.com (10.255.200.156) with Microsoft SMTP Server (TLS) id 15.1.492.11; Thu, 12 May 2016 12:31:54 +0000 Received: from BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) by BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) with mapi id 15.01.0492.016; Thu, 12 May 2016 12:31:54 +0000 From: "Dang, Quynh (Fed)" To: Tero Kivinen Thread-Topic: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-08.txt Thread-Index: AQHRq4INlfo3vaZ24EeajDZUeKdQeZ+z1mIFgAAMMYCAAB0NyYAAC4SAgAAG7WeAAQbvgIAAILNL Date: Thu, 12 May 2016 12:31:53 +0000 Message-ID: References: <20160511123830.15198.80422.idtracker@ietfa.amsl.com> , <22324.22809.54109.213161@fireball.acr.fi> In-Reply-To: <22324.22809.54109.213161@fireball.acr.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: iki.fi; dkim=none (message not signed) header.d=none;iki.fi; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.223.177] x-ms-office365-filtering-correlation-id: 694bacc6-bc64-4c2b-2043-08d37a6166be x-microsoft-exchange-diagnostics: 1; BN1PR09MB122; 5:hLh4AvFhjB5a3JNqgT7cQmquOni+cHsFJ/TakYhbXEPEEu8TE0OhJrZnbo621pqSsQ1TqLM/dyGoc42uQ1ojp1hEIIiixUgyAyBpTBblkv8w9BrRZhCB+Ar/MwTDt7ivZ/bXm9s0DB7LmQRd/4QFYA==; 24:qZEKF53F5p1h+YtQMub9QK0rPUVg3tvgyUi+UaQBGDsZIehTVvwrElNCpyOy/1uozeuIZH2rOu/O5pUuwmoAYr4DyfjOczGN2iuHZ2ZVfCE=; 7:le5RtsRbil4YRN5pu8uOff8nubUNkR/wW0Idug2cXmQFm/ylqoc5k6nc/0D/Lcu3Wbf314qYkBcyP137RRFfWquMKC8QDfl0SoOjLjfcVpmM2kiHBw+Cs1PpOCPGbnpVf5J3lkMBIoWZBi+5dNRT0LCkhHnnqOV7PFT6bk4DRQz8eOojHjoZLUfPdyagXIUj x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB122; x-ld-processed: 2ab5d82f-d8fa-4797-a93e-054655c61dec,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:BN1PR09MB122; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB122; x-forefront-prvs: 0940A19703 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(110136002)(92566002)(99286002)(189998001)(122556002)(2900100001)(33656002)(8936002)(86362001)(106116001)(9686002)(2950100001)(230783001)(66066001)(1220700001)(87936001)(5008740100001)(2906002)(19580395003)(19580405001)(6116002)(3846002)(5003600100002)(3280700002)(586003)(3660700001)(74316001)(5002640100001)(11100500001)(102836003)(77096005)(76576001)(81166006)(5004730100002)(54356999)(50986999)(93886004)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB122; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 12 May 2016 12:31:53.9774 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB122 Archived-At: Cc: IPsecME WG , "paul@nohats.ca" Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-08.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 12:31:59 -0000 Hi Tero and Paul, I like your proposed new text. I also recommend to add something like this:= "The group 2 and any other cryptographic algorithms which are expected to = provide around 80 bits of security strength are considered insecure mechani= sms." Unless we can describe a complete use case, then we could be able to = say whether or not the group 2 is acceptable in that case. Without that, we= can say either it is secure or not secure, there are nothings in between. Regards, Quynh. ________________________________________ From: Tero Kivinen Sent: Thursday, May 12, 2016 6:21:13 AM To: Dang, Quynh (Fed) Cc: paul@nohats.ca; IPsecME WG Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-08.txt Dang, Quynh (Fed) writes: > I meant implementations conforming to the RFC 4307 which implemented > the group 2. However, users must not use the group 2 because it is > not secure at this time. Implementation conforming to RFC4307 can decide NOT to implement group 2 or SHA1. You have to remember what SHOULD NOT means: 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. In this case the valid reasons why implementations want to implement group 2 is because not implementing it causes interoperability issues with old version. This does NOT give any guidance or recommendations for the users. We are talking mostly about the implementors here not users when we make those recommendations. > If we want users not to use bad options, then we must prohibit them > with "MUST NOT" for implementations. There are no reasons for saying > "allowed" to implement them while asking users not to use them > unless we want to say to users they are allowed to be used. If implementation prohibits them using it and users notice this cause interoperability issue, users will simply switch to some other product that works, i.e., SSL 3.0 VPN, IKEv1, or simply do not upgrade to the new version as it breaks things. > This text "On the other hand, comments and recommendations from this > document are also expected to be useful for such users." and the > document says that the groups 2 and 5 are allowed "SHOULD NOT, not > MUST NOT". All of these seem to tell users that these groups are > allowed to use. This text was changed in the latest draft, based on your comments. Now it says: 1.3. Document Audience The recommendations of this document mostly target IKEv2 implementers as implementations need to meet both high security expectations as well as high interoperability between various vendors and with different versions. Interoperability requires a smooth move to more secure cipher suites. This may differ from a user point of view that may deploy and configure IKEv2 with only the safest cipher suite. On the other hand, comments from this document are also expected to be useful for such users. I.e., now it does not even claim to give any recommendations for the users, it just says that the comments we have for the algorithms are something that might also be useful for such users. If you think this is not clear enough, we can change it to say: 1.3. Document Audience The recommendations of this document mostly target IKEv2 implementers as implementations need to meet both high security expectations as well as high interoperability between various vendors and with different versions. Interoperability requires a smooth move to more secure cipher suites. This may differ from a user point of view that may deploy and configure IKEv2 with only the safest cipher suite. This document does not give any recommendations for the use of algorithms, it only gives implementation recommendations for implementations. The use of algorithms by users is dictated by the security policy requirements for that specific user, and are outside the scope of this document. -- kivinen@iki.fi From nobody Thu May 12 06:47:24 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2EC12D12F for ; Thu, 12 May 2016 06:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.996] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KblgyAYuKb-Q for ; Thu, 12 May 2016 06:47:21 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4926212D0BA for ; Thu, 12 May 2016 06:47:21 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3r5DnL6MD2z3Fc; Thu, 12 May 2016 15:47:18 +0200 (CEST) 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 18SyGn3-VHya; Thu, 12 May 2016 15:47:00 +0200 (CEST) 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, 12 May 2016 15:47:00 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 1C075885752; Thu, 12 May 2016 09:46:58 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 1C075885752 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id EC389406B6E6; Thu, 12 May 2016 09:46:58 -0400 (EDT) Date: Thu, 12 May 2016 09:46:58 -0400 (EDT) From: Paul Wouters To: "Dang, Quynh (Fed)" In-Reply-To: Message-ID: References: <20160511123830.15198.80422.idtracker@ietfa.amsl.com> , <22324.22809.54109.213161@fireball.acr.fi> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: IPsecME WG , Tero Kivinen Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-08.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 13:47:22 -0000 On Thu, 12 May 2016, Dang, Quynh (Fed) wrote: > I like your proposed new text. I also recommend to add something like this: "The group 2 and any other cryptographic algorithms which are expected to provide around 80 bits of security strength are considered insecure mechanisms." Unless we can describe a complete use case, then we could be able to say whether or not the group 2 is acceptable in that case. Without that, we can say either it is secure or not secure, there are nothings in between. I don't like the "and any other cryptographic algorithms which are expected to provide around 80 bits of security" First, it is not very helpful to people who don't know which algorithms are expected to provide 80 bits of security. And second, I guess the 80 bits is a NIST / USG specific value, not a cryptographic community standard. Paul From nobody Thu May 12 07:15:13 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE1F12D6A9 for ; Thu, 12 May 2016 07:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYNybAtl9hLS for ; Thu, 12 May 2016 07:15:05 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0092.outbound.protection.outlook.com [23.103.200.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAF5C12D0BA for ; Thu, 12 May 2016 07:15:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8LwYH0zEpuBm14XaGifZQozWVPpJPyHdvF1cukmV9EQ=; b=0v3FzyDmmfKR+P1h1U4T01V1BvQUK4d/VwQOAmdDuaMm13fR9/6DNWZxOABWIPqA4rVhZ9jzKXJbf/YD/FCrJC9Hpo1oxi7F8TKI0gqqSmbU4+266oIf06qCZ6Tfui+wAPQ9QCfJfJFRcf1qj4e+MeF+KfgJGXnfI6T1DqY4s+A= Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) with Microsoft SMTP Server (TLS) id 15.1.492.11; Thu, 12 May 2016 14:15:00 +0000 Received: from BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) by BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) with mapi id 15.01.0492.019; Thu, 12 May 2016 14:15:00 +0000 From: "Dang, Quynh (Fed)" To: "paul@nohats.ca" Thread-Topic: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-08.txt Thread-Index: AQHRq4INlfo3vaZ24EeajDZUeKdQeZ+z1mIFgAAMMYCAAB0NyYAAC4SAgAAG7WeAAQbvgIAAILNLgAAYygCAAAZD5g== Date: Thu, 12 May 2016 14:14:59 +0000 Message-ID: References: <20160511123830.15198.80422.idtracker@ietfa.amsl.com> , <22324.22809.54109.213161@fireball.acr.fi> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nohats.ca; dkim=none (message not signed) header.d=none;nohats.ca; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.223.177] x-ms-office365-filtering-correlation-id: 19d858ee-3d1f-4a6d-0f95-08d37a6fcdbe x-microsoft-exchange-diagnostics: 1; BN1PR09MB124; 5:56tpOxQBDJEL2Xm31hNj24lul+D8pUZsq0AhjqEgttZXaOibeABRt4AGeU2aSdPzF6Ps9MrpwZKDdq4sQo20UrLu0b1oGLvsaWprrQMVvAEtZjWfh3E+EDO57K2GxBdqCZbpPbXYSK7qNZXDX7M79g==; 24:1BgNhGFV933bfIlKV6uRdQuthM23sy/zkZPggGAVAQqKz0rqy8j0wuwgeKkXfqTmA1fzX95F3XWrBiyjcRq0SJ/8pccrjBIKuBoXMToIKYM=; 7:OA6PC9nbC4GHkRxN9ay468LbD9PMt3kjyKJxa1s1jo26Sh4n2PVuFgCCRPUOlBJ7sy3+DfGATJfGonZEqxn2ASAiJIOAyE7wZ5JfiVZxiUiTEdaOM8cxg9upCF9nKVeZec5wLAP06MrY604y/beCdwUrg9P2wl0iUH5Qv2ENlPmL/g//BCfk/49vBRWUNAEI x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB124; x-ld-processed: 2ab5d82f-d8fa-4797-a93e-054655c61dec,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:BN1PR09MB124; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB124; x-forefront-prvs: 0940A19703 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(230783001)(33656002)(5008740100001)(1730700003)(81166006)(2501003)(15975445007)(77096005)(2900100001)(5003600100002)(2950100001)(8936002)(92566002)(5002640100001)(66066001)(19580405001)(19580395003)(99286002)(93886004)(2906002)(9686002)(189998001)(106116001)(5640700001)(2351001)(11100500001)(87936001)(3660700001)(74316001)(86362001)(122556002)(3280700002)(1220700001)(54356999)(76576001)(110136002)(50986999)(76176999)(6116002)(102836003)(3846002)(586003)(5004730100002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB124; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 12 May 2016 14:14:59.3302 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB124 Archived-At: Cc: IPsecME WG , Tero Kivinen Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-08.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 14:15:11 -0000 Hi Paul, 80 bits of security strength is the bigiest number that I have seen from th= e cryptographic community for estimating the strength of 1k DH. Regards, Quynh. ________________________________________ From: IPsec on behalf of Paul Wouters Sent: Thursday, May 12, 2016 9:46:58 AM To: Dang, Quynh (Fed) Cc: IPsecME WG; Tero Kivinen Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-08.txt On Thu, 12 May 2016, Dang, Quynh (Fed) wrote: > I like your proposed new text. I also recommend to add something like thi= s: "The group 2 and any other cryptographic algorithms which are expected t= o provide around 80 bits of security strength are considered insecure mecha= nisms." Unless we can describe a complete use case, then we could be able t= o say whether or not the group 2 is acceptable in that case. Without that, = we can say either it is secure or not secure, there are nothings in between= . I don't like the "and any other cryptographic algorithms which are expected to provide around 80 bits of security" First, it is not very helpful to people who don't know which algorithms are expected to provide 80 bits of security. And second, I guess the 80 bits is a NIST / USG specific value, not a cryptographic community standard. Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri May 13 01:45:50 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D76E12D0E9 for ; Fri, 13 May 2016 01:45:48 -0700 (PDT) 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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37Zsf-xGLv0J for ; Fri, 13 May 2016 01:45:45 -0700 (PDT) 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 249F312D0A9 for ; Fri, 13 May 2016 01:45:44 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u4D8jdfF013461 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 13 May 2016 11:45:39 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u4D8jd8l017859; Fri, 13 May 2016 11:45:39 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22325.37939.430668.430304@fireball.acr.fi> Date: Fri, 13 May 2016 11:45:39 +0300 From: Tero Kivinen To: "Dang\, Quynh \(Fed\)" In-Reply-To: References: <20160511123830.15198.80422.idtracker@ietfa.amsl.com> <22324.22809.54109.213161@fireball.acr.fi> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 11 min X-Total-Time: 19 min Archived-At: Cc: IPsecME WG , "paul@nohats.ca" Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-08.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 08:45:49 -0000 Dang, Quynh (Fed) writes: > 80 bits of security strength is the bigiest number that I have seen > from the cryptographic community for estimating the strength of 1k > DH. That might be so, but there is still quite a lot of different estimates for the equivalent strengts between symmetric and asymmetric keys. Saying that anything below 80 bits security strength is weak does not mean anything unless we also defined what is the security strength for each algorithm, and we do not want to do it here. Also that statement would not cover group 5 which is considered having more strength than group 2, but how much is open to debate. We already say that: Group 2 or 1024-bit MODP Group has been downgraded from MUST- in RFC4307 to SHOULD NOT. It is known to be weak against sufficiently funded attackers using commercially available mass-computing resources, so its security margin is considered too narrow. It is expected in the near future to be downgraded to MUST NOT. If the reader still wants to use it, he needs to have good reasons why and he then himself takes that risk of using it. For group 5 we say: Group 5 or 1536-bit MODP Group has been downgraded from MAY in RFC4307 to SHOULD NOT. It was specified earlier, but is now considered to be vulnerable to be broken within the next few years by a nation state level attack, so its security margin is considered too narrow. I still think both of those comments are accurate, and suitable for this document. -- kivinen@iki.fi From nobody Fri May 13 03:21:55 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDEC12D169 for ; Fri, 13 May 2016 03:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAKHAKwwW126 for ; Fri, 13 May 2016 03:21:49 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0132.outbound.protection.outlook.com [23.103.201.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05EDB12B05E for ; Fri, 13 May 2016 03:21:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vmVkWJqw0efuzj8G1TlOBFBagPpbR+yGTMUB5h5bMwk=; b=M3UxrRw11ZAua+Z70kVpgTvRHiDXFjEtHpZN17EPxht9nfBJiKHNnid+jKhAYYEhZGdzWocXeSfqQ+bO6Kz3zWiAlsWCIaVfXHlb9ojkcFC1qjeUMdgGPqkGhW0Dk/84lBaTQD7G8uLTygcj76PiTiinkWj70pomk2AzOi4ClCI= Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) with Microsoft SMTP Server (TLS) id 15.1.492.11; Fri, 13 May 2016 10:21:47 +0000 Received: from BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) by BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) with mapi id 15.01.0492.019; Fri, 13 May 2016 10:21:47 +0000 From: "Dang, Quynh (Fed)" To: Tero Kivinen Thread-Topic: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-08.txt Thread-Index: AQHRq4INlfo3vaZ24EeajDZUeKdQeZ+z1mIFgAAMMYCAAB0NyYAAC4SAgAAG7WeAAQbvgIAAILNLgAAYygCAAAZD5oABN+KAgAAaB+g= Date: Fri, 13 May 2016 10:21:46 +0000 Message-ID: References: <20160511123830.15198.80422.idtracker@ietfa.amsl.com> <22324.22809.54109.213161@fireball.acr.fi> , <22325.37939.430668.430304@fireball.acr.fi> In-Reply-To: <22325.37939.430668.430304@fireball.acr.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: iki.fi; dkim=none (message not signed) header.d=none;iki.fi; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.219.77] x-ms-office365-filtering-correlation-id: 5b2c6148-9574-486f-389b-08d37b1863e1 x-microsoft-exchange-diagnostics: 1; BN1PR09MB124; 5:nxDUTFGzn/NRfdzLZf8SHkURbGsJMqrECJ63n2OB0QVuse/k3zniAbab3OiP0i/TEAzxUCEmwhgsHOwBDr0jZQ4qZ7cILAweshhCvgYSU2T74RgFhLOl1mWoql0DJDTLn8F2VLDBmuUZcGOMq/ynqg==; 24:dk2qhaFWiaKoz6pd+iXwS3BhSXDwiUC3ch5sD4GoOdS4TULXbrRqnUS5D225R4TfPzriZUQ1uxs7hjx3peK2yYZv8JrKZ4wBYyv0PqhFMoo=; 7:eGpg31FiXZvo/qnsDFJliuN8atEBkIIorjKUabuTIAl5Ns4nv3aElPRzanxioZ1lQgOutSnwjZdjgLya7qC3IeAmQ9PU3dCM5EF2/Gt7kb8PWJq2lxE2sDHsnozaaWpSz1aB879PrVm9QfOh662nREDlCPNC/bQg9S5QBs/Y4U33GjwL8gwZwHMqZcttgFH/ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB124; x-ld-processed: 2ab5d82f-d8fa-4797-a93e-054655c61dec,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:BN1PR09MB124; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB124; x-forefront-prvs: 0941B96580 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(92566002)(5002640100001)(3846002)(102836003)(6116002)(1220700001)(4326007)(2906002)(586003)(2950100001)(77096005)(5003600100002)(86362001)(19580395003)(19580405001)(74316001)(76176999)(50986999)(54356999)(11100500001)(2900100001)(66066001)(10400500002)(5004730100002)(76576001)(110136002)(33656002)(87936001)(9686002)(189998001)(99286002)(230783001)(122556002)(93886004)(8936002)(106116001)(81166006)(5008740100001)(8676002)(3280700002)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB124; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 13 May 2016 10:21:46.3882 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB124 Archived-At: Cc: IPsecME WG , "paul@nohats.ca" Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-08.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 10:21:53 -0000 Hi Tero, That was why I said "around" when talking about security strength. Again, I like your proposed text change! Regards, Quynh. ________________________________________ From: Tero Kivinen Sent: Friday, May 13, 2016 4:45:39 AM To: Dang, Quynh (Fed) Cc: paul@nohats.ca; IPsecME WG Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-08.txt Dang, Quynh (Fed) writes: > 80 bits of security strength is the bigiest number that I have seen > from the cryptographic community for estimating the strength of 1k > DH. That might be so, but there is still quite a lot of different estimates for the equivalent strengts between symmetric and asymmetric keys. Saying that anything below 80 bits security strength is weak does not mean anything unless we also defined what is the security strength for each algorithm, and we do not want to do it here. Also that statement would not cover group 5 which is considered having more strength than group 2, but how much is open to debate. We already say that: Group 2 or 1024-bit MODP Group has been downgraded from MUST- in RFC4307 to SHOULD NOT. It is known to be weak against sufficiently funded attackers using commercially available mass-computing resources, so its security margin is considered too narrow. It is expected in the near future to be downgraded to MUST NOT. If the reader still wants to use it, he needs to have good reasons why and he then himself takes that risk of using it. For group 5 we say: Group 5 or 1536-bit MODP Group has been downgraded from MAY in RFC4307 to SHOULD NOT. It was specified earlier, but is now considered to be vulnerable to be broken within the next few years by a nation state level attack, so its security margin is considered too narrow. I still think both of those comments are accurate, and suitable for this document. -- kivinen@iki.fi From nobody Fri May 13 03:42:25 2016 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 23CB512B020; Fri, 13 May 2016 03:42:21 -0700 (PDT) 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.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160513104221.13086.32936.idtracker@ietfa.amsl.com> Date: Fri, 13 May 2016 03:42:21 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-09.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 10:42:21 -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 of the IETF. Title : Algorithm Implementation Requirements and Usage Guidance for IKEv2 Authors : Yoav Nir Tero Kivinen Paul Wouters Daniel Migault Filename : draft-ietf-ipsecme-rfc4307bis-09.txt Pages : 16 Date : 2016-05-13 Abstract: The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE) protocol is used to negotiate the IPsec Security Association (IPsec SA) parameters, such as which algorithms should be used. To ensure interoperability between different implementations, it is necessary to specify a set of algorithm implementation requirements and usage guidance to ensure that there is at least one algorithm that all implementations support. This document defines the current algorithm implementation requirements and usage guidance for IKEv2. This document does not update the algorithms used for packet encryption using IPsec Encapsulated Security Payload (ESP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc4307bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-09 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 Mon May 16 13:15:19 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96CF212DA19 for ; Mon, 16 May 2016 13:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.728 X-Spam-Level: X-Spam-Status: No, score=-5.728 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, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSHadg5SHT3S for ; Mon, 16 May 2016 13:15:16 -0700 (PDT) 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 E167712DA18 for ; Mon, 16 May 2016 13:15:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1463429715; x=2327343315; 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=5pywqbW/I5sCbxaCdGdBA5iGeRelJ3IE2iJsUB7RX9k=; b=TOvEP7PtcoIdMxb6YtUfDS/TcjAziKnprXsrt9/YmqvU0jnu/op4QIY1MlHRPb9M RK5CM1v8QJIwSt0fpp83CBSBlBLI5hcsO7DrqMw2SqBCQZ6u1LMQpRUYeXrgNjuq Du89OVQr0IINEcW8BuawRC11tA0VO3g1u4pvOUp9wwYajUMf4C1GxSMjLEImVhsB GGqA0J4a0H8yrzq4fpjE4aj8JQdqkN8vZzqjTanDhVAnRqv34WJznmBrt5GzkS1l Jf5nLWwLQn8yVJVwKGzdgJWoSOolPD9OjkE6XDnXUP4ECqn1NYZVxsomOywUnQsO qH1o2QD8rrs3SD4WFoXnnw==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id B1.86.25552.35A2A375; Mon, 16 May 2016 13:15:15 -0700 (PDT) X-AuditID: 11973e16-f79bc6d0000063d0-d5-573a2a53c4c0 Received: from nwk-mmpp-sz07.apple.com (nwk-mmpp-sz07.apple.com [17.128.115.240]) (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 DD.7C.28643.35A2A375; Mon, 16 May 2016 13:15:15 -0700 (PDT) Received: from [17.235.33.222] (unknown [17.235.33.222]) by nwk-mmpp-sz07.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0O7A00MJPDLEVB70@nwk-mmpp-sz07.apple.com> for ipsec@ietf.org; Mon, 16 May 2016 13:15:14 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable MIME-version: 1.0 (Mac OS X Mail 10.0 \(3186\)) Date: Mon, 16 May 2016 13:15:16 -0700 References: To: Paul Wouters , Daniel Migault , IPsecME WG In-reply-to: Message-id: <2C8840EB-AC99-401F-971A-2962B71FCC08@apple.com> X-Mailer: Apple Mail (2.3186) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHLMWRmVeSWpSXmKPExsUi2FAYpRusZRVuMP82n8X+LS/YHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8br1L0tBl17Fqo4m9gbGNSpdjBwcEgImEtdOGHcxcgKZYhIX 7q1n62Lk4hAS2Mso0bZ3LStEwkRi34x1LBCJ5UwSL/ZdZ4Jw5jFJ7Fn0hh1kkrCAhMTmPYkg DWwCKhLHv21gBrGZBbQk1u88zgRha0s8eXcBbCivgL7E/Ln/mSFagyWmtNmDhFkEVCUmbPvA DmILCexmlDhwzRakREQgT2LRTEOQMKeAk8SKTU3MEFNsJK539jFDvCIrcWWxBMhhEgIz2CT+ rNnBOIFReBaSI2YhOWIWkiMWMDKvYhTKTczM0c3MM9dLLCjISdVLzs/dxAgK4Ol2YjsYH66y OsQowMGoxMMr8M0iXIg1say4MvcQozQHi5I479k8y3AhgfTEktTs1NSC1KL4otKc1OJDjEwc nFINjAclquZPvdkolSWhcejPX49vCaI2l25Puumopbxnqksuc4FQvtyXq479JoeO62ozJ3hF rRHZcMai1oJHftPn7KBrog9Mgq9oHvKoExCbGRqiIrrLrrGAe9X1HqYOQ32vP3xH/Oamc1xb 3v5qzoIbOy41P6104vb/tkdYaOVqxY3VL1xz2HkclViKMxINtZiLihMBfYS/skECAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUi2FD8QTdYyyrcoOkTu8X+LS/YHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8br1L0tBl17Fqo4m9gbGNSpdjJwcEgImEvtmrGOBsMUkLtxb z9bFyMUhJLCcSeLFvutMEM48Jok9i96wdzFycAgLSEhs3pMI0sAmoCJx/NsGZhCbWUBLYv3O 40wQtrbEk3cXWEFsXgF9iflz/zNDtAZLTGmzBwmzCKhKTNj2gR3EFhLYzShx4JotSImIQJ7E opmGIGFOASeJFZuamCGm2Ehc7+wDmyIhICtxZbHEBEaBWUj2zkKydxaSvQsYmVcxChSl5iRW muklFhTkpOol5+duYgSHXGHUDsaG5VaHGAU4GJV4eAW+WYQLsSaWFVfmHmKU4GBWEuE9pm4V LsSbklhZlVqUH19UmpNafIgxGej8icxSosn5wHjIK4k3NDExMDE2NjM2NjcxJ01YSZy31NEs XEggPbEkNTs1tSC1CGYLEwenVAOj7e6vVUxTVm2VydrF++Jn+e2tys6Br9ganTPmsykt9fx6 pK9qs4zjxDXWlpznFP4s+GfGdJCpsstI5qjZQ5XzMQtytPje5qXkyYTaWTy7/iFivsiFh125 uSHpwab1G5kEWo/zLJddmLL//5ErOyeeXNDN8mu60lmT1a1aqfaH+Et7ehv+bJNXYinOSDTU Yi4qTgQAlP+Hu30CAAA= Archived-At: Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for adoption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 20:15:17 -0000 Hi Paul, Daniel, Thanks for the comments! Responses inline. I'd like to also hear feedback from people who brought up issues last = time if possible (Valery regarding inclusion of TLS, Tero regarding the = 3GPP spec conformity, and Yoav regarding the magic value) to validate = that this draft is satisfactory to resolve those issues. Thanks, Tommy > On May 6, 2016, at 4:48 PM, Paul Wouters wrote: >=20 > On Fri, 6 May 2016, Daniel Migault wrote: >=20 >> s/IPSec/IPsec >=20 > If Tommy could also fix that auto-correct for my iphone, that would be > great too :) >=20 >> "This method is intended to be used as a fallback option when IKE >> cannot be negotiated over UDP." >> This seems to indicates that the method should only be used with = IKEv2 >> which contradicts the title. Thus I would mention. When used with = IKE, >> this method... >=20 > This has happened in this group a few times now in different = documents. > People want to say IKEv2 to exclude IKE, but we should really say IKE > so these documents don't look weird when/if we get IKEv3. Sure, this can be changed to IKE rather than IKEv2. Whichever the group = thinks makes most sense is fine with me. >=20 >> I think that for interoperability, we should define a port at the >> IANA. If that port is 4500 we should detail why an how the two >> encapsulation method works. Are there any disadvantages of using an >> allocated port? One reason reason I suspect port agility may be = needed >> is NAT. If so that should be clearly documented. >=20 > We should not define a port unless it is 443, which we kind of cannot. Agreed. The most common port in practice will end up being 443; we do = have 4500 allocated if people want to do generic TCP testing, but to get = through NATs and firewalls, we need to often use 443 today. This may = change in the future, so we specifically leave this port option as a = configuration property. We also specifically don't mention that the extra framing protocol will = likely be TLS until we are in the appendix, due to comments from the = group on inclusion of direct references to TLS in the standard. >=20 >> I think that we shoudl specify that ESP SPI MUST be non zero to avoid >> the confusion between ESP SPI and Non-ESP marker.=20 >=20 > First I thought this was not needed, because RFC-3948 would define = that, > but it does look confusing because it is mentioned in the section = titled > "UDP-Encapsulated ESP Header format": >=20 > https://tools.ietf.org/html/rfc3948#section-2.1 >=20 > So the draft should probably include something simiar to that section. We can add a mention that the ESP SPI must be non-zero to match the = other RFCs. >=20 >> An IANA allocated port could could be such indicaton. In that case, >> would we need this prefix ? >=20 > We all know SSL VPNs exist because some networks block (4)500 on > purpose. That's correct. >=20 >> """ >> Any specific IKE SA, along with its Child SAs, is either TCP >> encapsulated or not. A mix of TCP and UDP encapsulation for a single >> SA is not allowed. >> """ >=20 > Note: what it you suddenly notice you can go back to UDP. Wouldn't you > have a mix while you migrate all the TCP-ESP to UDP-ESP? We can make this section more clear. The main point it was trying to = avoid was a technique used in previous drafts or protocols that used TCP = for IKE in which only long packets would use TCP, and other would use = UDP. The idea here is that all the IKE and ESP packets should share the = same stream, and only switch potentially to use UDP if they do a MOBIKE = switch. In that case, there could be packets on the wire that are mixed, = but there would be a discrete break in message IDs. >=20 >> If I understand this correctly it means: >> - a) IKEv2 SA using tcp encapsulation requires ESP to use TCP >> encapsulation. >> - b) an IKEv2 connection OR an ESP session cannot use TCP >> encapsulation or UDP or no encapsulation. >> I propose to have something similar to this: >> When IKEv2 is using TCP encapsulation, the negotiated ESP SA MUST be >> encapsulated with TCP. >=20 > It might be best to avoid making any statement on this. For example > libreswan introduced a force-encaps=3D option to work around Amazon = not > routing ESP packets. If you mention anything for IKE vs ESP you might > add limitations that might cause problems later on. While I think we > should have SHOULD language on trying to move TCP sessions to UDP, I > wouldn't go as far to forbid certain combinations. >=20 >> In fact a network may have different firewall rules for IKEv2 and ESP >> """ >> The original initiator (that is, the endpoint that initiated the TCP >> connection and sent the first IKE_SA_INIT message) is responsible for >> reestablishing the TCP connection if it is torn down for any >> unexpected reason. Since new TCP connections may use different ports >> due to NAT mappings or local port allocations changing, the responder >> MUST allow packets for existing SAs to be received from new source >> ports. >> """ >> Section 7: >> This re-define how NAT_DETECTION is performed over TCP. NAT_DETECTION = may currently seen as a >> UDP_ENCAPSULATION_SUPPORTED notify payload to. This won't be the case = anymore with IKEv2. Maybe we >> should provide more text on this. >=20 > well, on UDP it is obvious the port can change and you can just update > the port on the receiver based on the last received udp port. with tcp > clearly you know when it is being shut down. I'm not sure if the > receiver should keep such an orphaned IKE SA while waiting for another > TCP session to come in though. It might make sense of there is a DOS > attack using spoofed RST packets, but the attacker can't be stopped > anyway. >=20 > Paul From nobody Mon May 16 13:52:08 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF3D12DA4F for ; Mon, 16 May 2016 13:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tTyJ7aIcYPl for ; Mon, 16 May 2016 13:52:05 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 A003312DA59 for ; Mon, 16 May 2016 13:52:04 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id a17so155281710wme.0 for ; Mon, 16 May 2016 13:52:04 -0700 (PDT) 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; bh=Y4pQRHvSqQnGAywDvGfs/zzH+zYAy1+QGJ3q4jcy6ms=; b=c6/mm7EVXrvtI51w8bprMdanUB3q7jC8iNTEMj+tTO45VhCQDw6rn66MV63O+LKA9Q ksB5WeXQ3rqBWoCBPSJvb77SFBP/z9Ivma41T0hwl4jWlvpoC/xV0V+WiR0IoySiptrm 3G1GKenyTE9riVeEXoF2ETbms1yCGmIt9KXx1xjRd2gAiC0WOBaPKH9nXLwS4AWlSkbB UaIl4PivSaWTfbjYKVqoZAG4nm2O6bQvDrsIjQCkjfQMpdqizo/cuicQ994IF3Dwc8xh Ixtk3e1d4zT9DY66A5iArwgd/gb1H1bconjXLwEN+H+BrjX31P2B3+IFJ0dVRrX2uUTe lopw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Y4pQRHvSqQnGAywDvGfs/zzH+zYAy1+QGJ3q4jcy6ms=; b=fRGchS4LIuuLZg/A0NMT23Dkbua+RRbK/pWVVHHp/jJk1uCB5eSyLG3O+Vc4mEIVkg 5J2Vdg+fcjHjrvJesTlp5kbXEva+0CyK6dhCqReSZd+m5cl6jRLpBPoxFbilEOK8/u2h p9UrvRvfufF1+MKQUI7Xyn6CBAc5HPynUe/fcWdEXY9uurKw42Tv8raG2dFmBA8/jneE SdZAQ0FbKMSBJ0V/0h6xZr0bEKApVMVlsFMsZWuuGC3GATsIuM0eG9kIiEeQZP1VjQoT 22BIqVImxoWPKim8HX40XCSvVPFPyyXc4xUUlqPBq7JNFbLYTXE3xjJjds9IgG2QrUSU goeQ== X-Gm-Message-State: AOPr4FXHBhrpMcc4xKXdiXrG5wDT9w9xf//IabFEQXCK4/0Lp86LtiAf4wo5NXhCQfKuuW9YCU9wjJuD9jCiQw== MIME-Version: 1.0 X-Received: by 10.28.56.4 with SMTP id f4mr19148469wma.70.1463431923207; Mon, 16 May 2016 13:52:03 -0700 (PDT) Sender: mglt.ietf@gmail.com Received: by 10.194.236.1 with HTTP; Mon, 16 May 2016 13:52:03 -0700 (PDT) In-Reply-To: <2C8840EB-AC99-401F-971A-2962B71FCC08@apple.com> References: <2C8840EB-AC99-401F-971A-2962B71FCC08@apple.com> Date: Mon, 16 May 2016 16:52:03 -0400 X-Google-Sender-Auth: wrzdWq5hGYXHGDb6aVnaNPJUSuM Message-ID: From: Daniel Migault To: Tommy Pauly Content-Type: multipart/alternative; boundary=001a114cc21aef94560532fbcb6b Archived-At: Cc: IPsecME WG , Paul Wouters Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for adoption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 20:52:07 -0000 --001a114cc21aef94560532fbcb6b Content-Type: text/plain; charset=UTF-8 Hi Tommy, Thank you very much for the response. They are addressing all my concerns. BR, Daniel On Mon, May 16, 2016 at 4:15 PM, Tommy Pauly wrote: > Hi Paul, Daniel, > > Thanks for the comments! Responses inline. > > I'd like to also hear feedback from people who brought up issues last time > if possible (Valery regarding inclusion of TLS, Tero regarding the 3GPP > spec conformity, and Yoav regarding the magic value) to validate that this > draft is satisfactory to resolve those issues. > > Thanks, > Tommy > > > > On May 6, 2016, at 4:48 PM, Paul Wouters wrote: > > > > On Fri, 6 May 2016, Daniel Migault wrote: > > > >> s/IPSec/IPsec > > > > If Tommy could also fix that auto-correct for my iphone, that would be > > great too :) > > > >> "This method is intended to be used as a fallback option when IKE > >> cannot be negotiated over UDP." > >> This seems to indicates that the method should only be used with IKEv2 > >> which contradicts the title. Thus I would mention. When used with IKE, > >> this method... > > > > This has happened in this group a few times now in different documents. > > People want to say IKEv2 to exclude IKE, but we should really say IKE > > so these documents don't look weird when/if we get IKEv3. > > Sure, this can be changed to IKE rather than IKEv2. Whichever the group > thinks makes most sense is fine with me. > > > > >> I think that for interoperability, we should define a port at the > >> IANA. If that port is 4500 we should detail why an how the two > >> encapsulation method works. Are there any disadvantages of using an > >> allocated port? One reason reason I suspect port agility may be needed > >> is NAT. If so that should be clearly documented. > > > > We should not define a port unless it is 443, which we kind of cannot. > > Agreed. The most common port in practice will end up being 443; we do have > 4500 allocated if people want to do generic TCP testing, but to get through > NATs and firewalls, we need to often use 443 today. This may change in the > future, so we specifically leave this port option as a configuration > property. > > We also specifically don't mention that the extra framing protocol will > likely be TLS until we are in the appendix, due to comments from the group > on inclusion of direct references to TLS in the standard. > > > > >> I think that we shoudl specify that ESP SPI MUST be non zero to avoid > >> the confusion between ESP SPI and Non-ESP marker. > > > > First I thought this was not needed, because RFC-3948 would define that, > > but it does look confusing because it is mentioned in the section titled > > "UDP-Encapsulated ESP Header format": > > > > https://tools.ietf.org/html/rfc3948#section-2.1 > > > > So the draft should probably include something simiar to that section. > > We can add a mention that the ESP SPI must be non-zero to match the other > RFCs. > > > > >> An IANA allocated port could could be such indicaton. In that case, > >> would we need this prefix ? > > > > We all know SSL VPNs exist because some networks block (4)500 on > > purpose. > > That's correct. > > > > >> """ > >> Any specific IKE SA, along with its Child SAs, is either TCP > >> encapsulated or not. A mix of TCP and UDP encapsulation for a single > >> SA is not allowed. > >> """ > > > > Note: what it you suddenly notice you can go back to UDP. Wouldn't you > > have a mix while you migrate all the TCP-ESP to UDP-ESP? > > We can make this section more clear. The main point it was trying to avoid > was a technique used in previous drafts or protocols that used TCP for IKE > in which only long packets would use TCP, and other would use UDP. The idea > here is that all the IKE and ESP packets should share the same stream, and > only switch potentially to use UDP if they do a MOBIKE switch. In that > case, there could be packets on the wire that are mixed, but there would be > a discrete break in message IDs. > > > > >> If I understand this correctly it means: > >> - a) IKEv2 SA using tcp encapsulation requires ESP to use TCP > >> encapsulation. > >> - b) an IKEv2 connection OR an ESP session cannot use TCP > >> encapsulation or UDP or no encapsulation. > >> I propose to have something similar to this: > >> When IKEv2 is using TCP encapsulation, the negotiated ESP SA MUST be > >> encapsulated with TCP. > > > > It might be best to avoid making any statement on this. For example > > libreswan introduced a force-encaps= option to work around Amazon not > > routing ESP packets. If you mention anything for IKE vs ESP you might > > add limitations that might cause problems later on. While I think we > > should have SHOULD language on trying to move TCP sessions to UDP, I > > wouldn't go as far to forbid certain combinations. > > > >> In fact a network may have different firewall rules for IKEv2 and ESP > >> """ > >> The original initiator (that is, the endpoint that initiated the TCP > >> connection and sent the first IKE_SA_INIT message) is responsible for > >> reestablishing the TCP connection if it is torn down for any > >> unexpected reason. Since new TCP connections may use different ports > >> due to NAT mappings or local port allocations changing, the responder > >> MUST allow packets for existing SAs to be received from new source > >> ports. > >> """ > >> Section 7: > >> This re-define how NAT_DETECTION is performed over TCP. NAT_DETECTION > may currently seen as a > >> UDP_ENCAPSULATION_SUPPORTED notify payload to. This won't be the case > anymore with IKEv2. Maybe we > >> should provide more text on this. > > > > well, on UDP it is obvious the port can change and you can just update > > the port on the receiver based on the last received udp port. with tcp > > clearly you know when it is being shut down. I'm not sure if the > > receiver should keep such an orphaned IKE SA while waiting for another > > TCP session to come in though. It might make sense of there is a DOS > > attack using spoofed RST packets, but the attacker can't be stopped > > anyway. > > > > Paul > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --001a114cc21aef94560532fbcb6b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Tommy,

Thank you very much= for the response. They are addressing all my concerns.

BR,
Daniel

On Mon, May 16, 2016 at 4:15 PM, Tommy Pauly <<= a href=3D"mailto:tpauly@apple.com" target=3D"_blank">tpauly@apple.com&g= t; wrote:
Hi Paul, Daniel,

Thanks for the comments! Responses inline.

I'd like to also hear feedback from people who brought up issues last t= ime if possible (Valery regarding inclusion of TLS, Tero regarding the 3GPP= spec conformity, and Yoav regarding the magic value) to validate that this= draft is satisfactory to resolve those issues.

Thanks,
Tommy


> On May 6, 2016, at 4:48 PM, Paul Wouters <paul@nohats.ca> wrote:
>
> On Fri, 6 May 2016, Daniel Migault wrote:
>
>> s/IPSec/IPsec
>
> If Tommy could also fix that auto-correct for my iphone, that would be=
> great too :)
>
>> "This method is intended to be used as a fallback option when= IKE
>> cannot be negotiated over UDP."
>> This seems to indicates that the method should only be used with I= KEv2
>> which contradicts the title. Thus I would mention. When used with = IKE,
>> this method...
>
> This has happened in this group a few times now in different documents= .
> People want to say IKEv2 to exclude IKE, but we should really say IKE<= br> > so these documents don't look weird when/if we get IKEv3.

Sure, this can be changed to IKE rather than IKEv2. Whichever the gr= oup thinks makes most sense is fine with me.

>
>> I think that for interoperability, we should define a port at the<= br> >> IANA. If that port is 4500 we should detail why an how the two
>> encapsulation method works. Are there any disadvantages of using a= n
>> allocated port? One reason reason I suspect port agility may be ne= eded
>> is NAT. If so that should be clearly documented.
>
> We should not define a port unless it is 443, which we kind of cannot.=

Agreed. The most common port in practice will end up being 443; we d= o have 4500 allocated if people want to do generic TCP testing, but to get = through NATs and firewalls, we need to often use 443 today. This may change= in the future, so we specifically leave this port option as a configuratio= n property.

We also specifically don't mention that the extra framing protocol will= likely be TLS until we are in the appendix, due to comments from the group= on inclusion of direct references to TLS in the standard.

>
>> I think that we shoudl specify that ESP SPI MUST be non zero to av= oid
>> the confusion between ESP SPI and Non-ESP marker.
>
> First I thought this was not needed, because RFC-3948 would define tha= t,
> but it does look confusing because it is mentioned in the section titl= ed
> "UDP-Encapsulated ESP Header format":
>
> https://tools.ietf.org/html/rfc3948#section-2.1<= /a>
>
> So the draft should probably include something simiar to that section.=

We can add a mention that the ESP SPI must be non-zero to match the = other RFCs.

>
>> An IANA allocated port could could be such indicaton. In that case= ,
>> would we need this prefix ?
>
> We all know SSL VPNs exist because some networks block (4)500 on
> purpose.

That's correct.

>
>> """
>> Any specific IKE SA, along with its Child SAs, is either TCP
>> encapsulated or not.=C2=A0 A mix of TCP and UDP encapsulation for = a single
>> SA is not allowed.
>> """
>
> Note: what it you suddenly notice you can go back to UDP. Wouldn't= you
> have a mix while you migrate all the TCP-ESP to UDP-ESP?

We can make this section more clear. The main point it was trying to= avoid was a technique used in previous drafts or protocols that used TCP f= or IKE in which only long packets would use TCP, and other would use UDP. T= he idea here is that all the IKE and ESP packets should share the same stre= am, and only switch potentially to use UDP if they do a MOBIKE switch. In t= hat case, there could be packets on the wire that are mixed, but there woul= d be a discrete break in message IDs.

>
>> If I understand this correctly it means:
>>=C2=A0 =C2=A0 =C2=A0- a) IKEv2 SA using tcp encapsulation requires = ESP to use TCP
>> encapsulation.
>>=C2=A0 =C2=A0 =C2=A0- b) an IKEv2 connection OR an ESP session cann= ot use TCP
>> encapsulation or UDP or no encapsulation.
>> I propose to have something similar to this:
>> When IKEv2 is using TCP encapsulation, the negotiated ESP SA MUST = be
>> encapsulated with TCP.
>
> It might be best to avoid making any statement on this. For example > libreswan introduced a force-encaps=3D option to work around Amazon no= t
> routing ESP packets. If you mention anything for IKE vs ESP you might<= br> > add limitations that might cause problems later on. While I think we > should have SHOULD language on trying to move TCP sessions to UDP, I > wouldn't go as far to forbid certain combinations.
>
>> In fact a network may have different firewall rules for IKEv2 and = ESP
>> """
>>=C2=A0 The original initiator (that is, the endpoint that initiated= the TCP
>> connection and sent the first IKE_SA_INIT message) is responsible = for
>> reestablishing the TCP connection if it is torn down for any
>> unexpected reason.=C2=A0 Since new TCP connections may use differe= nt ports
>> due to NAT mappings or local port allocations changing, the respon= der
>> MUST allow packets for existing SAs to be received from new source=
>> ports.
>> """
>> Section 7:
>> This re-define how NAT_DETECTION is performed over TCP. NAT_DETECT= ION may currently seen as a
>> UDP_ENCAPSULATION_SUPPORTED notify payload to. This won't be t= he case anymore with IKEv2. Maybe we
>> should provide more text on this.
>
> well, on UDP it is obvious the port can change and you can just update=
> the port on the receiver based on the last received udp port. with tcp=
> clearly you know when it is being shut down. I'm not sure if the > receiver should keep such an orphaned IKE SA while waiting for another=
> TCP session to come in though. It might make sense of there is a DOS > attack using spoofed RST packets, but the attacker can't be stoppe= d
> anyway.
>
> Paul

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

--001a114cc21aef94560532fbcb6b-- From nobody Mon May 16 23:53:31 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7C112D0CD for ; Mon, 16 May 2016 23:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.491 X-Spam-Level: X-Spam-Status: No, score=-1.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2UyOMYeKJ4B for ; Mon, 16 May 2016 23:53:27 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::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 CB4A112D0FB for ; Mon, 16 May 2016 23:53:26 -0700 (PDT) Received: by mail-lb0-x231.google.com with SMTP id jj5so2355213lbc.0 for ; Mon, 16 May 2016 23:53:26 -0700 (PDT) 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-transfer-encoding; bh=1G0MN6Hn+wbgWjKNdUvcXfuia5P7VidoZPtccGQ3nmM=; b=YOet2cwS/PY/cEr2nLrfg/01aDvYkf7vaVoj25IXVQIsHMO8dwccX4KH7WSaP+Ibyh yD6Pv54nLriMp1JEDp1P0/ZVlY1aHAYwBaClJlKR8PfikRuVExtAeDBE2km0aBgJVKsK JBFClwKPdmFnuToSXNSt7H4XFwB5cSuI5GyKNXLM48MUlcr1hGKqn4wYf0Yko+xnuvZm XgksZfShXpdO71wDWsvMeIgPpF/IAE6tlmwjG48YqkbrSbeaVgykLpv7St+Nk0lihbbo /Zw8+CLCRJI5l39GJh6kW+3hYGYW8JWSLJxgp3NzT5+QuXWT04meppUKg4b4r9N4th4k 2mNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:references:subject:date :mime-version:content-transfer-encoding; bh=1G0MN6Hn+wbgWjKNdUvcXfuia5P7VidoZPtccGQ3nmM=; b=msGLt0yLsg9ZFzuoFIes+/MXXkfjblbdnQ8N0c20qoXyQw+gwU+j8J30Xi5MW+I3v8 MbMtkMnlR/craor0Y3rYf4P7v7SouKjvngWKS2RUS+DjCtDBH/c89iN+4rEX7AMHGaFO J7UpzpoYHOUM8aw3mK8AsqrqZDybO9W8DNEMhKl+PJMmTmIhlLBsQrknYc9y2eW7t1vw 7W6G8d8dLEJr/rNRZImCEYph+nFKxFBiA/d+AEk9urk9uerK5SMYYM82/QFx4SPumS7o I7Cicrofr0b4C4pAVPbHgejxr1uCCYEu3zolmUXz3XfSszy7hwZSP4QbesmABE7TaDFu Wnyg== X-Gm-Message-State: AOPr4FXwmce7FlzeszES4uCtHsUOwTsnHzqtFkpuNv+2A4KC8TDt76htkii7Ar0LbDgPEQ== X-Received: by 10.112.133.166 with SMTP id pd6mr13330536lbb.125.1463468004752; Mon, 16 May 2016 23:53:24 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id jn5sm221253lbc.24.2016.05.16.23.53.23 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 May 2016 23:53:23 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Tommy Pauly" , "Paul Wouters" , "Daniel Migault" , "IPsecME WG" References: <2C8840EB-AC99-401F-971A-2962B71FCC08@apple.com> Date: Tue, 17 May 2016 09:53:20 +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: Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for adoption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 06:53:29 -0000 Hi Tommy, sorry for late reply. I'm mostly OK with the last version of the draft. Few comments. It is a bit unclear how Stream Prefix is intended to be used with TLS. Is it insterted at the beginning of the TLS data stream? Then, I think some text should be added describing a situation when the original responder having a valid (from its point of view) TCP session receives a request from original initiator for a new TCP session. This may happen if original initiator looses TCP state for some reason (RST from an attacker, temporary network failure etc.). In this case the responder will have two TCP sessions associated with the IKE SA. Clearly, the new one should be used for further communications, but only after it is proven to be authentic (some protected message is received over it). But what the responder should do with the old TCP session? Keep it? Send FIN? Send RST? Just discard? Regards, Valery. > Hi Paul, Daniel, > > Thanks for the comments! Responses inline. > > I'd like to also hear feedback from people who brought up issues last time if possible (Valery regarding inclusion of > TLS, Tero regarding the 3GPP spec conformity, and Yoav regarding the magic value) to validate that this draft is > satisfactory to resolve those issues. > > Thanks, > Tommy > > >> On May 6, 2016, at 4:48 PM, Paul Wouters wrote: >> >> On Fri, 6 May 2016, Daniel Migault wrote: >> >>> s/IPSec/IPsec >> >> If Tommy could also fix that auto-correct for my iphone, that would be >> great too :) >> >>> "This method is intended to be used as a fallback option when IKE >>> cannot be negotiated over UDP." >>> This seems to indicates that the method should only be used with IKEv2 >>> which contradicts the title. Thus I would mention. When used with IKE, >>> this method... >> >> This has happened in this group a few times now in different documents. >> People want to say IKEv2 to exclude IKE, but we should really say IKE >> so these documents don't look weird when/if we get IKEv3. > > Sure, this can be changed to IKE rather than IKEv2. Whichever the group thinks makes most sense is fine with me. > >> >>> I think that for interoperability, we should define a port at the >>> IANA. If that port is 4500 we should detail why an how the two >>> encapsulation method works. Are there any disadvantages of using an >>> allocated port? One reason reason I suspect port agility may be needed >>> is NAT. If so that should be clearly documented. >> >> We should not define a port unless it is 443, which we kind of cannot. > > Agreed. The most common port in practice will end up being 443; we do have 4500 allocated if people want to do generic > TCP testing, but to get through NATs and firewalls, we need to often use 443 today. This may change in the future, so > we specifically leave this port option as a configuration property. > > We also specifically don't mention that the extra framing protocol will likely be TLS until we are in the appendix, > due to comments from the group on inclusion of direct references to TLS in the standard. > >> >>> I think that we shoudl specify that ESP SPI MUST be non zero to avoid >>> the confusion between ESP SPI and Non-ESP marker. >> >> First I thought this was not needed, because RFC-3948 would define that, >> but it does look confusing because it is mentioned in the section titled >> "UDP-Encapsulated ESP Header format": >> >> https://tools.ietf.org/html/rfc3948#section-2.1 >> >> So the draft should probably include something simiar to that section. > > We can add a mention that the ESP SPI must be non-zero to match the other RFCs. > >> >>> An IANA allocated port could could be such indicaton. In that case, >>> would we need this prefix ? >> >> We all know SSL VPNs exist because some networks block (4)500 on >> purpose. > > That's correct. > >> >>> """ >>> Any specific IKE SA, along with its Child SAs, is either TCP >>> encapsulated or not. A mix of TCP and UDP encapsulation for a single >>> SA is not allowed. >>> """ >> >> Note: what it you suddenly notice you can go back to UDP. Wouldn't you >> have a mix while you migrate all the TCP-ESP to UDP-ESP? > > We can make this section more clear. The main point it was trying to avoid was a technique used in previous drafts or > protocols that used TCP for IKE in which only long packets would use TCP, and other would use UDP. The idea here is > that all the IKE and ESP packets should share the same stream, and only switch potentially to use UDP if they do a > MOBIKE switch. In that case, there could be packets on the wire that are mixed, but there would be a discrete break in > message IDs. > >> >>> If I understand this correctly it means: >>> - a) IKEv2 SA using tcp encapsulation requires ESP to use TCP >>> encapsulation. >>> - b) an IKEv2 connection OR an ESP session cannot use TCP >>> encapsulation or UDP or no encapsulation. >>> I propose to have something similar to this: >>> When IKEv2 is using TCP encapsulation, the negotiated ESP SA MUST be >>> encapsulated with TCP. >> >> It might be best to avoid making any statement on this. For example >> libreswan introduced a force-encaps= option to work around Amazon not >> routing ESP packets. If you mention anything for IKE vs ESP you might >> add limitations that might cause problems later on. While I think we >> should have SHOULD language on trying to move TCP sessions to UDP, I >> wouldn't go as far to forbid certain combinations. >> >>> In fact a network may have different firewall rules for IKEv2 and ESP >>> """ >>> The original initiator (that is, the endpoint that initiated the TCP >>> connection and sent the first IKE_SA_INIT message) is responsible for >>> reestablishing the TCP connection if it is torn down for any >>> unexpected reason. Since new TCP connections may use different ports >>> due to NAT mappings or local port allocations changing, the responder >>> MUST allow packets for existing SAs to be received from new source >>> ports. >>> """ >>> Section 7: >>> This re-define how NAT_DETECTION is performed over TCP. NAT_DETECTION may currently seen as a >>> UDP_ENCAPSULATION_SUPPORTED notify payload to. This won't be the case anymore with IKEv2. Maybe we >>> should provide more text on this. >> >> well, on UDP it is obvious the port can change and you can just update >> the port on the receiver based on the last received udp port. with tcp >> clearly you know when it is being shut down. I'm not sure if the >> receiver should keep such an orphaned IKE SA while waiting for another >> TCP session to come in though. It might make sense of there is a DOS >> attack using spoofed RST packets, but the attacker can't be stopped >> anyway. >> >> Paul > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed May 18 16:17:40 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B080412D53E for ; Wed, 18 May 2016 16:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGwGXscaIGhP for ; Wed, 18 May 2016 16:17:36 -0700 (PDT) Received: from gateway32.websitewelcome.com (gateway32.websitewelcome.com [192.185.145.170]) (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 C990412D537 for ; Wed, 18 May 2016 16:17:36 -0700 (PDT) Received: from cm2.websitewelcome.com (cm2.websitewelcome.com [192.185.178.13]) by gateway32.websitewelcome.com (Postfix) with ESMTP id 3C009A400654F for ; Wed, 18 May 2016 18:17:36 -0500 (CDT) Received: from daimler.websitewelcome.com ([192.185.82.156]) by cm2.websitewelcome.com with id vzHb1s00S3NMyg001zHcjh; Wed, 18 May 2016 18:17:36 -0500 Received: from [94.241.171.49] (port=51590 helo=tdol.net) by daimler.websitewelcome.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86_1) (envelope-from ) id 1b3Aib-0005T7-NN; Wed, 18 May 2016 18:17:34 -0500 From: To: "ion-users" , "iovisor-dev" , "ipdir" , "ipj" , "ipsec" , "ipv6-ops-bouncesbensons" Date: Thu, 19 May 2016 02:17:26 +0300 Message-ID: <00004e7371fc$9f64e0e9$493f8ddd$@queuefull.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_73696076.56888055" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdGpFPZu35KkRvyhvFycHPXI9k6TbA== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - daimler.websitewelcome.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - queuefull.net X-BWhitelist: no X-Source-IP: 94.241.171.49 X-Exim-ID: 1b3Aib-0005T7-NN X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (tdol.net) [94.241.171.49]:51590 X-Source-Auth: jay@newdreamteam.net X-Email-Count: 398 X-Source-Cap: bmV3ZHJlYW07amF5c3RlYW07ZGFpbWxlci53ZWJzaXRld2VsY29tZS5jb20= Archived-At: Subject: [IPsec] nice stuff X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 23:17:39 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_73696076.56888055 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hey, I was looking for some stuff and eventually came across this! Just look here Thx, bensons@queuefull.net ------=_NextPart_000_0001_73696076.56888055 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

<= span lang=3DEN-US>Hey,

I was looking for some stuff and eventually came across = this! Just look here http://stekaherdo.petsessentials.com/indicate.php

 = ;

Thx, bensons= @queuefull.net

------=_NextPart_000_0001_73696076.56888055-- From nobody Fri May 20 11:11:35 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2972C12D566 for ; Fri, 20 May 2016 11:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.728 X-Spam-Level: X-Spam-Status: No, score=-5.728 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, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXQyc7mYC9Zg for ; Fri, 20 May 2016 11:11:33 -0700 (PDT) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1456112B01C for ; Fri, 20 May 2016 11:11:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1463767892; x=2327681492; 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=upXha/S99oh/uclsIilyJdb5/TS0rdm3BIRDgrn4W7k=; b=HT3eDHkF2dHc3vxzPoiyeu6NBIAP4XFP7jNPatlH95f0J+Q+TNuy2m2lVR1ttWvT 6mz2eGvxwcMebwghIWT0gWGESSuNHC+V8XDerS0pHmGEzNDIThOQGY/3IrrBuLKE qYwNAluHG/44F5VCfuJhv61GQWlSOsFY1FVuJ2XbTaca1UWeem5zOLDx3Nu3cAtS LJfW9YCXuxu0pIK2JYKSlg+Jy82FeFhhDom4UP8aRZlm7fHYOqGX0MyHtyCMNQTe YY+k5OSOBVYqOytfgsNxVF/EWAehndYvThXQsrR08iMjiCO9JwwGC+naLrBgX52C fqemUWG/hHaBJcnaU4XgkA==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id A9.00.03030.4535F375; Fri, 20 May 2016 11:11:32 -0700 (PDT) X-AuditID: 11973e13-f798e6d000000bd6-20-573f5354ff54 Received: from nwk-mmpp-sz06.apple.com (nwk-mmpp-sz06.apple.com [17.128.115.234]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id 09.3E.09064.4535F375; Fri, 20 May 2016 11:11:32 -0700 (PDT) Received: from da0602a-dhcp162.apple.com (da0602a-dhcp162.apple.com [17.226.23.162]) by nwk-mmpp-sz06.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0O7H00B7KMJ6GF80@nwk-mmpp-sz06.apple.com> for ipsec@ietf.org; Fri, 20 May 2016 11:11:31 -0700 (PDT) Sender: tpauly@apple.com Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 10.0 \(3186\)) From: Tommy Pauly X-Priority: 3 In-reply-to: Date: Fri, 20 May 2016 11:11:29 -0700 Content-transfer-encoding: quoted-printable Message-id: <9CC56746-DCA5-42F0-8FBC-B3F5391989E6@apple.com> References: <2C8840EB-AC99-401F-971A-2962B71FCC08@apple.com> To: Valery Smyslov , Yoav Nir X-Mailer: Apple Mail (2.3186) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOLMWRmVeSWpSXmKPExsUi2FAYoRsSbB9usOOTicX+LS/YHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsX75N+aCW64V89c+Zm9g3G7excjJISFgIrFufTcLhC0mceHe erYuRi4OIYG9jBIHmt4DJTjAiq5s04GIL2eSeLx8IiuEs4tJ4uWUA2wgRcICEhKb9ySCDGIW 0JJYv/M4E4jNK6AvMX/uf2aIkmCJKW32IGE2ARWJ4982MEPs5ZWY0f4U7AZOAXOJkw3T2EHK WQRUJXbOqYWYmCdxvectC4StLfHk3QVWiOk2EjPP34c6eTaTRO+bH2wgCREBV4lLP3YzQZwv K3FlsQRIjYTAGjaJU3s+skxgFJ2F5NJZSC6dhWTHAkbmVYxCuYmZObqZeaZ6iQUFOal6yfm5 mxhBIT/dTngH4+lVVocYBTgYlXh4DzjYhQuxJpYVV+YeYpTmYFES513jbB8uJJCeWJKanZpa kFoUX1Sak1p8iJGJg1OqgZHRY0X/Fx3XAP+jFSpNjO/WpK3gtvx9S/3g4989ib/3Cd170LDY +ISldPaj+ElPS/or3285cNasq6eni2PKJeNPms31/Zeune8wZRK2U/tW+Wr32qsON99daX9X ZSvVFP5WqiN97sFg5wfbYj/WL7m9WSFu0o8Sd9ep8/ydVTUTvjxTUzNetVOJpTgj0VCLuag4 EQBlDSgeWgIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42IRbCh+pRsSbB9u8PEmv8X+LS/YHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsX75N+aCW64V89c+Zm9g3G7excjBISFgInFlm04XIyeQKSZx 4d56ti5GLg4hgeVMEo+XT2SFcHYxSbyccoANpEFYQEJi855EkAZmAS2J9TuPM4HYvAL6EvPn /meGKAmWmNJmDxJmE1CROP5tAzPEfF6JGe1PWUBsTgFziZMN09hBylkEVCV2zqmFmJgncb3n LQuErS3x5N0FVojpNhIzz9+HOm02k0Tvmx9sIAkRAVeJSz92M0G8IitxZbHEBEahWUiOm4Xk uFlIxi5gZF7FKFCUmpNYaaqXWFCQk6qXnJ+7iREcooUROxj/L7M6xCjAwajEw5tpZxcuxJpY VlyZe4hRgoNZSYR3U5B9uBBvSmJlVWpRfnxRaU5q8SHGZKBfJjJLiSbnA+MnryTe0MTEwMTY 2MzY2NzEnDRhJXFeqYs24UIC6YklqdmpqQWpRTBbmDg4pRoYyxyfy7aZPZGK7Xnw0b35l9qu HK5f/ZxeyYZyh9kYky48aXn+cvdnI+vkNRy8Bg/j5Y4fXSd36rriy9aDouV80T77H+jc/lux 99beCVHfnaa0p8ckezyo0/rsEVXkYVjxXDFNQzlzdszaQ7sWFpt+v3i/NPn6Pe3t9yMlVr72 qTru8eJSxvTdSizFGYmGWsxFxYkAwknn+pUCAAA= Archived-At: Cc: IPsecME WG , Daniel Migault , Paul Wouters Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for adoption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 18:11:35 -0000 Hi Valery, Thanks for your reply! I think these are good points that we can clarify = in future versions, although we can address these once it is a working = group document. Responses inline. Best, Tommy > On May 16, 2016, at 11:53 PM, Valery Smyslov wrote: >=20 > Hi Tommy, >=20 > sorry for late reply. I'm mostly OK with the last version of the = draft. >=20 > Few comments. It is a bit unclear how Stream Prefix is intended > to be used with TLS. Is it insterted at the beginning of the TLS data = stream? The intention is that the prefix is used at the beginning of the stream = even when TLS is being used (specifically, inside the encrypted TLS = stream). Since the point of the prefix is to identify which specific = protocol is being used, to differentiate from other TLS or VPN traffic, = it is relevant to use it even when going over TLS port 443 in case the = server being used also supports other VPN protocols over the same port = using TLS. This is one of the points Yoav brought up. >=20 > Then, I think some text should be added describing a situation > when the original responder having a valid (from its point of view) > TCP session receives a request from original initiator for a new > TCP session. This may happen if original initiator looses TCP > state for some reason (RST from an attacker, temporary network failure = etc.). > In this case the responder will have two TCP sessions associated with > the IKE SA. Clearly, the new one should be used for further = communications, > but only after it is proven to be authentic (some protected message is = received > over it). But what the responder should do with the old TCP session? > Keep it? Send FIN? Send RST? Just discard? >=20 In general, the approach of the draft is to clearly separate the TCP = state from the IKE session state. If you look at Section 6, it = specifically allows for multiple TCP connections between two peers even = if there is only one IKE SA between them. If one of them becomes = redundant (because the other peer opened up a new TCP flow for some = reason), it would make sense to close the other in a usual way. I think = this can be left to the implementation, but either a FIN or RST would be = appropriate rather than a discard. We can add that to future versions. > Regards, > Valery. >=20 >> Hi Paul, Daniel, >>=20 >> Thanks for the comments! Responses inline. >>=20 >> I'd like to also hear feedback from people who brought up issues last = time if possible (Valery regarding inclusion of TLS, Tero regarding the = 3GPP spec conformity, and Yoav regarding the magic value) to validate = that this draft is satisfactory to resolve those issues. >>=20 >> Thanks, >> Tommy >>=20 >>=20 >>> On May 6, 2016, at 4:48 PM, Paul Wouters wrote: >>>=20 >>> On Fri, 6 May 2016, Daniel Migault wrote: >>>=20 >>>> s/IPSec/IPsec >>>=20 >>> If Tommy could also fix that auto-correct for my iphone, that would = be >>> great too :) >>>=20 >>>> "This method is intended to be used as a fallback option when IKE >>>> cannot be negotiated over UDP." >>>> This seems to indicates that the method should only be used with = IKEv2 >>>> which contradicts the title. Thus I would mention. When used with = IKE, >>>> this method... >>>=20 >>> This has happened in this group a few times now in different = documents. >>> People want to say IKEv2 to exclude IKE, but we should really say = IKE >>> so these documents don't look weird when/if we get IKEv3. >>=20 >> Sure, this can be changed to IKE rather than IKEv2. Whichever the = group thinks makes most sense is fine with me. >>=20 >>>=20 >>>> I think that for interoperability, we should define a port at the >>>> IANA. If that port is 4500 we should detail why an how the two >>>> encapsulation method works. Are there any disadvantages of using an >>>> allocated port? One reason reason I suspect port agility may be = needed >>>> is NAT. If so that should be clearly documented. >>>=20 >>> We should not define a port unless it is 443, which we kind of = cannot. >>=20 >> Agreed. The most common port in practice will end up being 443; we do = have 4500 allocated if people want to do generic TCP testing, but to get = through NATs and firewalls, we need to often use 443 today. This may = change in the future, so we specifically leave this port option as a = configuration property. >>=20 >> We also specifically don't mention that the extra framing protocol = will likely be TLS until we are in the appendix, due to comments from = the group on inclusion of direct references to TLS in the standard. >>=20 >>>=20 >>>> I think that we shoudl specify that ESP SPI MUST be non zero to = avoid >>>> the confusion between ESP SPI and Non-ESP marker. >>>=20 >>> First I thought this was not needed, because RFC-3948 would define = that, >>> but it does look confusing because it is mentioned in the section = titled >>> "UDP-Encapsulated ESP Header format": >>>=20 >>> https://tools.ietf.org/html/rfc3948#section-2.1 >>>=20 >>> So the draft should probably include something simiar to that = section. >>=20 >> We can add a mention that the ESP SPI must be non-zero to match the = other RFCs. >>=20 >>>=20 >>>> An IANA allocated port could could be such indicaton. In that case, >>>> would we need this prefix ? >>>=20 >>> We all know SSL VPNs exist because some networks block (4)500 on >>> purpose. >>=20 >> That's correct. >>=20 >>>=20 >>>> """ >>>> Any specific IKE SA, along with its Child SAs, is either TCP >>>> encapsulated or not. A mix of TCP and UDP encapsulation for a = single >>>> SA is not allowed. >>>> """ >>>=20 >>> Note: what it you suddenly notice you can go back to UDP. Wouldn't = you >>> have a mix while you migrate all the TCP-ESP to UDP-ESP? >>=20 >> We can make this section more clear. The main point it was trying to = avoid was a technique used in previous drafts or protocols that used TCP = for IKE in which only long packets would use TCP, and other would use = UDP. The idea here is that all the IKE and ESP packets should share the = same stream, and only switch potentially to use UDP if they do a MOBIKE = switch. In that case, there could be packets on the wire that are mixed, = but there would be a discrete break in message IDs. >>=20 >>>=20 >>>> If I understand this correctly it means: >>>> - a) IKEv2 SA using tcp encapsulation requires ESP to use TCP >>>> encapsulation. >>>> - b) an IKEv2 connection OR an ESP session cannot use TCP >>>> encapsulation or UDP or no encapsulation. >>>> I propose to have something similar to this: >>>> When IKEv2 is using TCP encapsulation, the negotiated ESP SA MUST = be >>>> encapsulated with TCP. >>>=20 >>> It might be best to avoid making any statement on this. For example >>> libreswan introduced a force-encaps=3D option to work around Amazon = not >>> routing ESP packets. If you mention anything for IKE vs ESP you = might >>> add limitations that might cause problems later on. While I think we >>> should have SHOULD language on trying to move TCP sessions to UDP, I >>> wouldn't go as far to forbid certain combinations. >>>=20 >>>> In fact a network may have different firewall rules for IKEv2 and = ESP >>>> """ >>>> The original initiator (that is, the endpoint that initiated the = TCP >>>> connection and sent the first IKE_SA_INIT message) is responsible = for >>>> reestablishing the TCP connection if it is torn down for any >>>> unexpected reason. Since new TCP connections may use different = ports >>>> due to NAT mappings or local port allocations changing, the = responder >>>> MUST allow packets for existing SAs to be received from new source >>>> ports. >>>> """ >>>> Section 7: >>>> This re-define how NAT_DETECTION is performed over TCP. = NAT_DETECTION may currently seen as a >>>> UDP_ENCAPSULATION_SUPPORTED notify payload to. This won't be the = case anymore with IKEv2. Maybe we >>>> should provide more text on this. >>>=20 >>> well, on UDP it is obvious the port can change and you can just = update >>> the port on the receiver based on the last received udp port. with = tcp >>> clearly you know when it is being shut down. I'm not sure if the >>> receiver should keep such an orphaned IKE SA while waiting for = another >>> TCP session to come in though. It might make sense of there is a DOS >>> attack using spoofed RST packets, but the attacker can't be stopped >>> anyway. >>>=20 >>> Paul >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Sun May 22 23:39:19 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03BA512D531 for ; Sun, 22 May 2016 23:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.491 X-Spam-Level: X-Spam-Status: No, score=-1.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwC8Njtkht7Q for ; Sun, 22 May 2016 23:39:16 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::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 102DD12B047 for ; Sun, 22 May 2016 23:39:16 -0700 (PDT) Received: by mail-lb0-x22e.google.com with SMTP id h1so52101766lbj.3 for ; Sun, 22 May 2016 23:39:15 -0700 (PDT) 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-transfer-encoding; bh=ZvCnQ4mezVWXu02T82DVpCc0C8kAolc2fqTKlGeIf24=; b=R/XRhn8lGQniUtz4MZHs6Q36xU9mZpRKqQ/t6qjgrENCCPC738wz3rmp3lB1J5U9Kb T0G0V+noaMDt372ynbMyJXI8piqttaMnYOvOH6DnjXnImIgaunv74/CCiYr9+LVu/9G1 ng2FatpDdxQmcO312YF/11cUS3W6CRmUeMIrNO9AKFDY4IAjBzSSfpDXpTGOfcmUF3aV S6I9WgzqsQ0wIAjOHmufKdnhJEwdzb1LWwT24+AGY8R2ZwSAEdtpCxy8XvMQiRSC7/gF d4MXkfZXePh/WC0ReY7wamsqVRXxVfQHGw9T2paQwMYzpbWNHeHcN6F1+W3M7Ro3wMdb FdUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-transfer-encoding; bh=ZvCnQ4mezVWXu02T82DVpCc0C8kAolc2fqTKlGeIf24=; b=KzzY9P8QEAj7EXF6BweMsdHoKn2xTPUzOuCUVEHD5O8aZoUeoB/+N+v3ZFhh4PpVyL w2+rUuZGyMGVNymug73d7rtWsje0U9/cHezmitH2TdX0YvWjLXLY+0QUNvqHkt1TElxT dCrVFEsiApgxNLhdMislkTulg3sH/ZkIN7bgFZ0LtATBV/0RVNxItWSgt8cBfuK2UQO6 67DbrUt9evLhB2M/jNTbnquikYnnkQiRgk0KTSSJYhL/8ORb2l/4cjxWTAVJ1okoTg0k npGD9mpr1Ayv1l2GsKDa7/heV7Usl8Tx9BM8+8a7cQjlo8755OI9I7+hjjmayYa4K/VY 9hBQ== X-Gm-Message-State: AOPr4FX7e+hTydQLqU4Z4JUamTYQX0ObJfx5iNqxQDJY97NQj9uoQklL0bw/3WcrD6RoyQ== X-Received: by 10.112.149.137 with SMTP id ua9mr5255122lbb.54.1463985554054; Sun, 22 May 2016 23:39:14 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id z132sm1903934lff.46.2016.05.22.23.39.12 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 22 May 2016 23:39:12 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Tommy Pauly" , "Yoav Nir" References: <2C8840EB-AC99-401F-971A-2962B71FCC08@apple.com> <9CC56746-DCA5-42F0-8FBC-B3F5391989E6@apple.com> Date: Mon, 23 May 2016 09:39:13 +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: IPsecME WG , Daniel Migault , Paul Wouters Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for adoption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 06:39:19 -0000 Hi Tommy, thank you for clarifications. One more point. The draft is silent about what the responder is supposed to do with the stream prefix. Should it check it? In this case what should it do if the prefix is different from "IKEv2"? Discard the TCP session? Or should it ignore the prefix completely? In this case how many bytes should it skip from the beginning of the stream - exactly 5? Regards, Valery. ----- Original Message ----- From: "Tommy Pauly" To: "Valery Smyslov" ; "Yoav Nir" Cc: "Paul Wouters" ; "Daniel Migault" ; "IPsecME WG" Sent: Friday, May 20, 2016 9:11 PM Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for adoption Hi Valery, Thanks for your reply! I think these are good points that we can clarify in future versions, although we can address these once it is a working group document. Responses inline. Best, Tommy > On May 16, 2016, at 11:53 PM, Valery Smyslov wrote: > > Hi Tommy, > > sorry for late reply. I'm mostly OK with the last version of the draft. > > Few comments. It is a bit unclear how Stream Prefix is intended > to be used with TLS. Is it insterted at the beginning of the TLS data stream? The intention is that the prefix is used at the beginning of the stream even when TLS is being used (specifically, inside the encrypted TLS stream). Since the point of the prefix is to identify which specific protocol is being used, to differentiate from other TLS or VPN traffic, it is relevant to use it even when going over TLS port 443 in case the server being used also supports other VPN protocols over the same port using TLS. This is one of the points Yoav brought up. > > Then, I think some text should be added describing a situation > when the original responder having a valid (from its point of view) > TCP session receives a request from original initiator for a new > TCP session. This may happen if original initiator looses TCP > state for some reason (RST from an attacker, temporary network failure etc.). > In this case the responder will have two TCP sessions associated with > the IKE SA. Clearly, the new one should be used for further communications, > but only after it is proven to be authentic (some protected message is received > over it). But what the responder should do with the old TCP session? > Keep it? Send FIN? Send RST? Just discard? > In general, the approach of the draft is to clearly separate the TCP state from the IKE session state. If you look at Section 6, it specifically allows for multiple TCP connections between two peers even if there is only one IKE SA between them. If one of them becomes redundant (because the other peer opened up a new TCP flow for some reason), it would make sense to close the other in a usual way. I think this can be left to the implementation, but either a FIN or RST would be appropriate rather than a discard. We can add that to future versions. > Regards, > Valery. > >> Hi Paul, Daniel, >> >> Thanks for the comments! Responses inline. >> >> I'd like to also hear feedback from people who brought up issues last time if possible (Valery regarding inclusion of >> TLS, Tero regarding the 3GPP spec conformity, and Yoav regarding the magic value) to validate that this draft is >> satisfactory to resolve those issues. >> >> Thanks, >> Tommy >> >> >>> On May 6, 2016, at 4:48 PM, Paul Wouters wrote: >>> >>> On Fri, 6 May 2016, Daniel Migault wrote: >>> >>>> s/IPSec/IPsec >>> >>> If Tommy could also fix that auto-correct for my iphone, that would be >>> great too :) >>> >>>> "This method is intended to be used as a fallback option when IKE >>>> cannot be negotiated over UDP." >>>> This seems to indicates that the method should only be used with IKEv2 >>>> which contradicts the title. Thus I would mention. When used with IKE, >>>> this method... >>> >>> This has happened in this group a few times now in different documents. >>> People want to say IKEv2 to exclude IKE, but we should really say IKE >>> so these documents don't look weird when/if we get IKEv3. >> >> Sure, this can be changed to IKE rather than IKEv2. Whichever the group thinks makes most sense is fine with me. >> >>> >>>> I think that for interoperability, we should define a port at the >>>> IANA. If that port is 4500 we should detail why an how the two >>>> encapsulation method works. Are there any disadvantages of using an >>>> allocated port? One reason reason I suspect port agility may be needed >>>> is NAT. If so that should be clearly documented. >>> >>> We should not define a port unless it is 443, which we kind of cannot. >> >> Agreed. The most common port in practice will end up being 443; we do have 4500 allocated if people want to do >> generic TCP testing, but to get through NATs and firewalls, we need to often use 443 today. This may change in the >> future, so we specifically leave this port option as a configuration property. >> >> We also specifically don't mention that the extra framing protocol will likely be TLS until we are in the appendix, >> due to comments from the group on inclusion of direct references to TLS in the standard. >> >>> >>>> I think that we shoudl specify that ESP SPI MUST be non zero to avoid >>>> the confusion between ESP SPI and Non-ESP marker. >>> >>> First I thought this was not needed, because RFC-3948 would define that, >>> but it does look confusing because it is mentioned in the section titled >>> "UDP-Encapsulated ESP Header format": >>> >>> https://tools.ietf.org/html/rfc3948#section-2.1 >>> >>> So the draft should probably include something simiar to that section. >> >> We can add a mention that the ESP SPI must be non-zero to match the other RFCs. >> >>> >>>> An IANA allocated port could could be such indicaton. In that case, >>>> would we need this prefix ? >>> >>> We all know SSL VPNs exist because some networks block (4)500 on >>> purpose. >> >> That's correct. >> >>> >>>> """ >>>> Any specific IKE SA, along with its Child SAs, is either TCP >>>> encapsulated or not. A mix of TCP and UDP encapsulation for a single >>>> SA is not allowed. >>>> """ >>> >>> Note: what it you suddenly notice you can go back to UDP. Wouldn't you >>> have a mix while you migrate all the TCP-ESP to UDP-ESP? >> >> We can make this section more clear. The main point it was trying to avoid was a technique used in previous drafts or >> protocols that used TCP for IKE in which only long packets would use TCP, and other would use UDP. The idea here is >> that all the IKE and ESP packets should share the same stream, and only switch potentially to use UDP if they do a >> MOBIKE switch. In that case, there could be packets on the wire that are mixed, but there would be a discrete break >> in message IDs. >> >>> >>>> If I understand this correctly it means: >>>> - a) IKEv2 SA using tcp encapsulation requires ESP to use TCP >>>> encapsulation. >>>> - b) an IKEv2 connection OR an ESP session cannot use TCP >>>> encapsulation or UDP or no encapsulation. >>>> I propose to have something similar to this: >>>> When IKEv2 is using TCP encapsulation, the negotiated ESP SA MUST be >>>> encapsulated with TCP. >>> >>> It might be best to avoid making any statement on this. For example >>> libreswan introduced a force-encaps= option to work around Amazon not >>> routing ESP packets. If you mention anything for IKE vs ESP you might >>> add limitations that might cause problems later on. While I think we >>> should have SHOULD language on trying to move TCP sessions to UDP, I >>> wouldn't go as far to forbid certain combinations. >>> >>>> In fact a network may have different firewall rules for IKEv2 and ESP >>>> """ >>>> The original initiator (that is, the endpoint that initiated the TCP >>>> connection and sent the first IKE_SA_INIT message) is responsible for >>>> reestablishing the TCP connection if it is torn down for any >>>> unexpected reason. Since new TCP connections may use different ports >>>> due to NAT mappings or local port allocations changing, the responder >>>> MUST allow packets for existing SAs to be received from new source >>>> ports. >>>> """ >>>> Section 7: >>>> This re-define how NAT_DETECTION is performed over TCP. NAT_DETECTION may currently seen as a >>>> UDP_ENCAPSULATION_SUPPORTED notify payload to. This won't be the case anymore with IKEv2. Maybe we >>>> should provide more text on this. >>> >>> well, on UDP it is obvious the port can change and you can just update >>> the port on the receiver based on the last received udp port. with tcp >>> clearly you know when it is being shut down. I'm not sure if the >>> receiver should keep such an orphaned IKE SA while waiting for another >>> TCP session to come in though. It might make sense of there is a DOS >>> attack using spoofed RST packets, but the attacker can't be stopped >>> anyway. >>> >>> 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 From nobody Mon May 23 12:57:40 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E225412DB16 for ; Mon, 23 May 2016 12:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72VET1SY-NYy for ; Mon, 23 May 2016 12:57:37 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5D8A12D187 for ; Mon, 23 May 2016 12:57:37 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3rD8TV5wD5z36y; Mon, 23 May 2016 21:57:34 +0200 (CEST) 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 TAW321jna9IV; Mon, 23 May 2016 21:57:33 +0200 (CEST) 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; Mon, 23 May 2016 21:57:33 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id E782C801ED1; Mon, 23 May 2016 15:57:32 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca E782C801ED1 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D16704073525; Mon, 23 May 2016 15:57:32 -0400 (EDT) Date: Mon, 23 May 2016 15:57:32 -0400 (EDT) From: Paul Wouters To: Valery Smyslov In-Reply-To: Message-ID: References: <2C8840EB-AC99-401F-971A-2962B71FCC08@apple.com> <9CC56746-DCA5-42F0-8FBC-B3F5391989E6@apple.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for adoption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 19:57:39 -0000 On Mon, 23 May 2016, Valery Smyslov wrote: > thank you for clarifications. One more point. The draft is silent about > what the responder is supposed to do with the stream prefix. > Should it check it? In this case what should it do if the prefix is > different from "IKEv2"? Discard the TCP session? Or should > it ignore the prefix completely? In this case how many bytes > should it skip from the beginning of the stream - exactly 5? That might not work well if we get IKEv2.1 Actually, I'd argue it should be a unique identifier but not contain a verion number of the IKE protocol at all. Paul From nobody Mon May 23 13:22:42 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7E7312DB65 for ; Mon, 23 May 2016 13:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrUuXrmu2utA for ; Mon, 23 May 2016 13:22:39 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::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 0522712DB70 for ; Mon, 23 May 2016 13:22:30 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id k98so18841900lfi.1 for ; Mon, 23 May 2016 13:22:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-transfer-encoding:importance; bh=YnnOz1LUkUapFwFcU3/urYMFf3oE/6u2moLVO8koA6c=; b=ConPDvi6vDk/flC/CfC3k/WBT2KHbp+bh3PkH00kxOPQa1zy85pkaS7uXg2CCNabYX SSsQ2KOxuaCpN/tLPoEDjtzRrSN+rID19YUlCuMA7GA8V0lVwijpd34L3EIfOqU3/giT +EZk07V17KcHxDuNzR1I/tR4ADTld0AhfoBb3iV0fZrGtUdjHW9UQ+NMsb19HkGeUFvF c7WTGhFXkxQ9r4vYY90cNI/R2HxPhpyHw/d1LZC2shyFr7gAA5rsExgCbcIywNSdA4bL KY4DJfeRFh6W9jodTW7hoOsINICIBFCRMiB64vSXKyYEc7GhlAdHADhZ2v9+Yr8rvBhl eJdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:in-reply-to :subject:date:mime-version:content-transfer-encoding:importance; bh=YnnOz1LUkUapFwFcU3/urYMFf3oE/6u2moLVO8koA6c=; b=kiDLNkrbqXvvamMFSXnyuYk3gMiWREJjt8Gq99ZE9L0TzMqDzNaUXW8kQL2Xnxa7AF XYgxAOQrQeLLXTPVEeNh9TSaSro0wxVAQRlYTK8hO1XH05Xx2mKjt46+0jAMZukYGzFz 6Z8K+S9ziOrRarQwaI7N9DceeVtoS0M6rWtpm/Ox4ZfzgYoU3ubqyINlF+MTvChBgzVB Ii8b0HmuZnmrsYeZI/kwVzbqVWc5eelLGyM2UGM0OCh0KbHMxyWzsjjSfWJ0ZzPnNhzp nWJIxqnIv/hpA2RQMbPzQl+ausUNgZZqSMJrPwcL4uagNlbeaYzVXMG2c7kpuewmtcrb 5Ifg== X-Gm-Message-State: AOPr4FVl6+TOesTsrcMyQmO7g8+HvsA70JlpCNnDp5tzrlmPTX3uKrqtO0dV8iI2Km8scQ== X-Received: by 10.25.16.27 with SMTP id f27mr6701717lfi.114.1464034948203; Mon, 23 May 2016 13:22:28 -0700 (PDT) Received: from chichi (ppp83-237-40-63.pppoe.mtu-net.ru. [83.237.40.63]) by smtp.gmail.com with ESMTPSA id y189sm277450lfc.26.2016.05.23.13.22.26 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 May 2016 13:22:27 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Paul Wouters" References: <2C8840EB-AC99-401F-971A-2962B71FCC08@apple.com> <9CC56746-DCA5-42F0-8FBC-B3F5391989E6@apple.com> In-Reply-To: Date: Mon, 23 May 2016 23:22:25 +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 Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for adoption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 20:22:41 -0000 Hi Paul, >> thank you for clarifications. One more point. The draft is silent about >> what the responder is supposed to do with the stream prefix. >> Should it check it? In this case what should it do if the prefix is >> different from "IKEv2"? Discard the TCP session? Or should >> it ignore the prefix completely? In this case how many bytes >> should it skip from the beginning of the stream - exactly 5? > > That might not work well if we get IKEv2.1 That was the point. But please see below. > Actually, I'd argue it should be a unique identifier but not contain a > verion number of the IKE protocol at all. Not sure. Actually, this prefix is meaningful only for middleboxes, so it is not linked with any particular IKE version and can be an arbitrary string, that is different from TLS ClienHello and other existing prefixes Yoav mentioned. On the other hand the prefix can be used as an indication of teh encapsulation format. For example, in the unlikely event we later want to change length field size to 4 bytes, we can change the prefix to distinguish between old and new formats. In this case the responder should discard the TCP session if the prefix doesn't match an expected value, since it means that the encapsulation format is different from what it understands. But my point was that in any case - whether the prefix should be checked or ignored by responder, - the behaviour must be clearly described in the draft. > Paul Regards, Valery. From nobody Mon May 23 14:20:30 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5619412D10F for ; Mon, 23 May 2016 14:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F_9kMjnOeyWO for ; Mon, 23 May 2016 14:20:27 -0700 (PDT) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 B502D12DBD1 for ; Mon, 23 May 2016 14:13:17 -0700 (PDT) Received: by mail-wm0-x243.google.com with SMTP id q62so159968wmg.3 for ; Mon, 23 May 2016 14:13:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3PJMpbk2VKfrPBL5grUZOVOtPk0rJpVklnxUM2Cqd7s=; b=oDaU9Tj3M5AmEHQ2fdo0+HKH0HoOwzZobnhyrGMAHrgbq42RDyHiHItfvY96b+Xp+8 xkD4PtdrijeVpt16DjsS55eQ89TSsa6t0crqJmwGpQbPyDbCiES/HVWhWnf9NWAW5QLp Rg9aRsJ8b2KIIlLiA4zcd++NqsUznlDGzv0qGBbW7FTkOH823FEkUoj3tMkSevZVK59C SXwvrLxXeeAtJ1dG5mXSvutKkT6ozA1tU+nghw7Jej63Xx5seW4vle+OWdkOA0aRsJFr FHc6AE/PZ0d+dxacC1TJgPZYTCMytDe5pX4yAmDRFLdC/YeYDss6sCHB+ROaEJBfLN5c 5rUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3PJMpbk2VKfrPBL5grUZOVOtPk0rJpVklnxUM2Cqd7s=; b=Ldg8j5SHjPpUdK5vCS3yOPDB6baZgTTGw9dvXhKlNH5664Rx6OlXZ3MwAqgQPHFNi/ qbGOUV1J3rFofNmss9OEP67dtLuRl+5cbfEnEq4RDPldB64vj+wJLiVIYLfNfQT5XGCq mJmUALWyIoy4JbVehX0Py7hg3NblXMAfZct3wWHTR4m9+7bxkXogXB5cnVKXPBuzOtKV CA9KqjjfBIsQ52oWxC/ObmosVrTW1QmF3mOQG/THfsLnEaLu/wKGNy2rDgyDL5JYjwAJ olGAryDv36wzUjfykp81M5x6dOVhrXmpyzafd8tPPhyQquOze7VPepBBRvGVpnJriouq N3pQ== X-Gm-Message-State: ALyK8tJunAHM8q6Yfgk4UiTWQfZ34UXvJZCxdZEq1GflQH2YJ045m7eax2LMQW3f0lyZeQ== X-Received: by 10.194.101.170 with SMTP id fh10mr778761wjb.50.1464037996156; Mon, 23 May 2016 14:13:16 -0700 (PDT) Received: from [192.168.1.14] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id t3sm15536624wmf.20.2016.05.23.14.13.14 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 23 May 2016 14:13:15 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 From: Yoav Nir X-Priority: 3 In-Reply-To: Date: Tue, 24 May 2016 00:13:09 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <291B3BE9-0F55-464A-8BDD-A85E803F452D@gmail.com> References: <2C8840EB-AC99-401F-971A-2962B71FCC08@apple.com> <9CC56746-DCA5-42F0-8FBC-B3F5391989E6@apple.com> To: Valery Smyslov X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IPsecME WG , Daniel Migault , Paul Wouters , Tommy Pauly Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for adoption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 21:20:28 -0000 > On 23 May 2016, at 9:39 AM, Valery Smyslov wrote: >=20 > Hi Tommy, >=20 > thank you for clarifications. One more point. The draft is silent = about > what the responder is supposed to do with the stream prefix. > Should it check it? In this case what should it do if the prefix is > different from "IKEv2"? Discard the TCP session? Or should > it ignore the prefix completely? In this case how many bytes > should it skip from the beginning of the stream - exactly 5? This prefix is used for de-multiplexing. For example, if we listen for = IKE on TCP port 443 and also have an HTTPS server there (perhaps as an = administrative interface). Assuming we don=E2=80=99t encrypt IKE in TLS, then we need the prefix to = differentiate between IKE and TLS. Currently, there=E2=80=99s no way a = valid ClientHello begins with =E2=80=9CIKEv2=E2=80=9D, and hopefully = that will not change with TLS 1.3 or any future version. If we do = encapsulate IKEv2 in TLS, we still need to differentiate IKEv2 from = HTTP. And again, there is no HTTP method called =E2=80=9CIKEv2=E2=80=9D. So I think the parsing and consuming of this prefix is not part of the = IKE, but part of the de-multiplexer. If the port has several services, = then not having the =E2=80=9CIKEv2=E2=80=9D prefix means that the stream = should be processed by some other processor. If IKEv2 is the only = service on that particular port, then we need a very simple = de-multiplexer: if the first 5 bytes are =E2=80=9CIKEv2=E2=80=9D then = consume them and forward the rest to the IKEv2 service. If it=E2=80=99s = anything else, close the connection. Yoav= From nobody Mon May 23 15:55:20 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE0A012B060 for ; Mon, 23 May 2016 15:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWGHEgWM4iJG for ; Mon, 23 May 2016 15:55:17 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (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 1098212D174 for ; Mon, 23 May 2016 15:55:17 -0700 (PDT) Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id 5A236B3F53868; Mon, 23 May 2016 22:55:13 +0000 (GMT) Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id u4NMtFm6013059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 May 2016 22:55:16 GMT Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id u4NMtFBe003595 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 May 2016 22:55:15 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.21]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Mon, 23 May 2016 18:55:15 -0400 From: "Hu, Jun (Nokia - US)" To: Yoav Nir , Valery Smyslov Thread-Topic: [IPsec] New version of TCP Encapsulation draft, request for adoption Thread-Index: AQHRoLQbhmlKoxjITU+aiNyunbfH4p+ssGmAgAA064CAD3ujAIAAb1NwgAW3a4CAA7KaPIABNyaA///XDcA= Date: Mon, 23 May 2016 22:55:14 +0000 Message-ID: <876523B00C3F9D47BFD2B654D63DBF92BE97C61E@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <2C8840EB-AC99-401F-971A-2962B71FCC08@apple.com> <9CC56746-DCA5-42F0-8FBC-B3F5391989E6@apple.com> <291B3BE9-0F55-464A-8BDD-A85E803F452D@gmail.com> In-Reply-To: <291B3BE9-0F55-464A-8BDD-A85E803F452D@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: IPsecME WG , Daniel Migault , Paul Wouters , Tommy Pauly Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for adoption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 22:55:19 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBJUHNlYyBbbWFpbHRvOmlwc2Vj LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBZb2F2IE5pcg0KPiBTZW50OiBNb25kYXks IE1heSAyMywgMjAxNiAyOjEzIFBNDQo+IFRvOiBWYWxlcnkgU215c2xvdg0KPiBDYzogSVBzZWNN RSBXRzsgRGFuaWVsIE1pZ2F1bHQ7IFBhdWwgV291dGVyczsgVG9tbXkgUGF1bHkNCj4gU3ViamVj dDogUmU6IFtJUHNlY10gTmV3IHZlcnNpb24gb2YgVENQIEVuY2Fwc3VsYXRpb24gZHJhZnQsIHJl cXVlc3QgZm9yDQo+IGFkb3B0aW9uDQo+IA0KPiANCj4gPiBPbiAyMyBNYXkgMjAxNiwgYXQgOToz OSBBTSwgVmFsZXJ5IFNteXNsb3YgPHN2YW5ydUBnbWFpbC5jb20+IHdyb3RlOg0KPiA+DQo+ID4g SGkgVG9tbXksDQo+ID4NCj4gPiB0aGFuayB5b3UgZm9yIGNsYXJpZmljYXRpb25zLiBPbmUgbW9y ZSBwb2ludC4gVGhlIGRyYWZ0IGlzIHNpbGVudA0KPiA+IGFib3V0IHdoYXQgdGhlIHJlc3BvbmRl ciBpcyBzdXBwb3NlZCB0byBkbyB3aXRoIHRoZSBzdHJlYW0gcHJlZml4Lg0KPiA+IFNob3VsZCBp dCBjaGVjayBpdD8gSW4gdGhpcyBjYXNlIHdoYXQgc2hvdWxkIGl0IGRvIGlmIHRoZSBwcmVmaXgg aXMNCj4gPiBkaWZmZXJlbnQgZnJvbSAiSUtFdjIiPyBEaXNjYXJkIHRoZSBUQ1Agc2Vzc2lvbj8g T3Igc2hvdWxkIGl0IGlnbm9yZQ0KPiA+IHRoZSBwcmVmaXggY29tcGxldGVseT8gSW4gdGhpcyBj YXNlIGhvdyBtYW55IGJ5dGVzIHNob3VsZCBpdCBza2lwIGZyb20NCj4gPiB0aGUgYmVnaW5uaW5n IG9mIHRoZSBzdHJlYW0gLSBleGFjdGx5IDU/DQo+IA0KPiBUaGlzIHByZWZpeCBpcyB1c2VkIGZv ciBkZS1tdWx0aXBsZXhpbmcuIEZvciBleGFtcGxlLCBpZiB3ZSBsaXN0ZW4gZm9yIElLRSBvbiBU Q1ANCj4gcG9ydCA0NDMgYW5kIGFsc28gaGF2ZSBhbiBIVFRQUyBzZXJ2ZXIgdGhlcmUgKHBlcmhh cHMgYXMgYW4gYWRtaW5pc3RyYXRpdmUNCj4gaW50ZXJmYWNlKS4NCj4gDQo+IEFzc3VtaW5nIHdl IGRvbuKAmXQgZW5jcnlwdCBJS0UgaW4gVExTLCANCg0KW0hKXSB0aGlzIHBhcnQgaXMgYSBiaXQg Y29uZnVzaW5nIGZvciBtZSwgaWYgd2UgZG9uJ3QgdXNlIFRMUyBsZXZlbCBlbmNyeXB0aW9uLCB0 aGVuIHdoYXQncyB0aGUgYmVuZWZpdCBvZiB1c2luZyBUTFMgb3ZlciBwbGFpbiBUQ1AgZW5jYXBz dWxhdGlvbj8gIEluIGZhY3QsIEkgZG9uJ3Qga25vdyB3aHkgVExTIGVuY2Fwc3VsYXRpb24gaXMg bmVlZGVkIGF0IGFsbCwgaXQgaXMgc2FpZCBpbiB0aGUgZHJhZnQgdGhhdCAiIFRoZSBzZWN1cml0 eSBvZiB0aGUgSUtFdjIgc2Vzc2lvbiBpcyBlbnRpcmVseSBkZXJpdmVkIGZyb20gdGhlIElLVkV2 MiBuZWdvdGlhdGlvbiBhbmQga2V5IGVzdGFibGlzaG1lbnQiLCBzbyBlbmNyeXB0aW9uL2F1dGhl bnRpY2F0aW9uIG9mIFRMUyBsZXZlbCBhcmUgbm90IG5lZWRlZCBhdCBhbGwuIA0KDQo+IHRoZW4g d2UgbmVlZCB0aGUgcHJlZml4IHRvIGRpZmZlcmVudGlhdGUNCj4gYmV0d2VlbiBJS0UgYW5kIFRM Uy4gQ3VycmVudGx5LCB0aGVyZeKAmXMgbm8gd2F5IGEgdmFsaWQgQ2xpZW50SGVsbG8gYmVnaW5z IHdpdGgNCj4g4oCcSUtFdjLigJ0sIGFuZCBob3BlZnVsbHkgdGhhdCB3aWxsIG5vdCBjaGFuZ2Ug d2l0aCBUTFMgMS4zIG9yIGFueSBmdXR1cmUgdmVyc2lvbi4gSWYNCj4gd2UgZG8gZW5jYXBzdWxh dGUgSUtFdjIgaW4gVExTLCB3ZSBzdGlsbCBuZWVkIHRvIGRpZmZlcmVudGlhdGUgSUtFdjIgZnJv bSBIVFRQLg0KPiBBbmQgYWdhaW4sIHRoZXJlIGlzIG5vIEhUVFAgbWV0aG9kIGNhbGxlZCDigJxJ S0V2MuKAnS4NCg0KPiANCj4gU28gSSB0aGluayB0aGUgcGFyc2luZyBhbmQgY29uc3VtaW5nIG9m IHRoaXMgcHJlZml4IGlzIG5vdCBwYXJ0IG9mIHRoZSBJS0UsIGJ1dA0KPiBwYXJ0IG9mIHRoZSBk ZS1tdWx0aXBsZXhlci4gSWYgdGhlIHBvcnQgaGFzIHNldmVyYWwgc2VydmljZXMsIHRoZW4gbm90 IGhhdmluZyB0aGUNCj4g4oCcSUtFdjLigJ0gcHJlZml4IG1lYW5zIHRoYXQgdGhlIHN0cmVhbSBz aG91bGQgYmUgcHJvY2Vzc2VkIGJ5IHNvbWUgb3RoZXINCj4gcHJvY2Vzc29yLiBJZiBJS0V2MiBp cyB0aGUgb25seSBzZXJ2aWNlIG9uIHRoYXQgcGFydGljdWxhciBwb3J0LCB0aGVuIHdlIG5lZWQg YQ0KPiB2ZXJ5IHNpbXBsZSBkZS1tdWx0aXBsZXhlcjogaWYgdGhlIGZpcnN0IDUgYnl0ZXMgYXJl IOKAnElLRXYy4oCdIHRoZW4gY29uc3VtZSB0aGVtDQo+IGFuZCBmb3J3YXJkIHRoZSByZXN0IHRv IHRoZSBJS0V2MiBzZXJ2aWNlLiBJZiBpdOKAmXMgYW55dGhpbmcgZWxzZSwgY2xvc2UgdGhlDQo+ IGNvbm5lY3Rpb24uDQo+IA0KDQo= From nobody Mon May 23 16:14:53 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E111812DC28 for ; Mon, 23 May 2016 16:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmziwFEsktuX for ; Mon, 23 May 2016 16:14:52 -0700 (PDT) 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 DF80412DC2B for ; Mon, 23 May 2016 16:14:51 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3rDDs44LbWz37k; Tue, 24 May 2016 01:14:48 +0200 (CEST) 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 d2PIaJfvYl4o; Tue, 24 May 2016 01:14:46 +0200 (CEST) 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, 24 May 2016 01:14:46 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 6F5D6801ED1; Mon, 23 May 2016 19:14:45 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 6F5D6801ED1 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 59C99406B6F2; Mon, 23 May 2016 19:14:45 -0400 (EDT) Date: Mon, 23 May 2016 19:14:45 -0400 (EDT) From: Paul Wouters To: "Hu, Jun (Nokia - US)" In-Reply-To: <876523B00C3F9D47BFD2B654D63DBF92BE97C61E@US70UWXCHMBA05.zam.alcatel-lucent.com> Message-ID: References: <2C8840EB-AC99-401F-971A-2962B71FCC08@apple.com> <9CC56746-DCA5-42F0-8FBC-B3F5391989E6@apple.com> <291B3BE9-0F55-464A-8BDD-A85E803F452D@gmail.com> <876523B00C3F9D47BFD2B654D63DBF92BE97C61E@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for adoption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 23:14:53 -0000 On Mon, 23 May 2016, Hu, Jun (Nokia - US) wrote: > [HJ] this part is a bit confusing for me, if we don't use TLS level encryption, then what's the benefit of using TLS over plain TCP encapsulation? In fact, I don't know why TLS encapsulation is needed at all, it is said in the draft that " The security of the IKEv2 session is entirely derived from the IKVEv2 negotiation and key establishment", so encryption/authentication of TLS level are not needed at all. To get past middleware boxes that tend to not touch "real" TLS traffic but mangle anything else. Paul From nobody Mon May 23 16:16:22 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBEED12D500 for ; Mon, 23 May 2016 16:16:20 -0700 (PDT) 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgUo4O5Pwrqn for ; Mon, 23 May 2016 16:16:19 -0700 (PDT) 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 04DAA12D4FB for ; Mon, 23 May 2016 16:16:18 -0700 (PDT) X-AuditID: c618062d-f79886d000002334-b1-574386c1bc2d Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id F5.7A.09012.1C683475; Tue, 24 May 2016 00:40:01 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0294.000; Mon, 23 May 2016 19:16:14 -0400 From: Samy Touati To: "Hu, Jun (Nokia - US)" , Yoav Nir , Valery Smyslov Thread-Topic: [IPsec] New version of TCP Encapsulation draft, request for adoption Thread-Index: AQHRp9dsFYeBQXf63kW+gzKmkjCh2J+s1w2AgA97pACAAG9QJoAFt22AgAOymAiAATcpgIAAHIUA//+QgwA= Date: Mon, 23 May 2016 23:16:13 +0000 Message-ID: References: <2C8840EB-AC99-401F-971A-2962B71FCC08@apple.com> <9CC56746-DCA5-42F0-8FBC-B3F5391989E6@apple.com> <291B3BE9-0F55-464A-8BDD-A85E803F452D@gmail.com> <876523B00C3F9D47BFD2B654D63DBF92BE97C61E@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <876523B00C3F9D47BFD2B654D63DBF92BE97C61E@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.16.0.160506 x-originating-ip: [147.117.188.9] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3546864972_2089499017" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFIsWRmVeSWpSXmKPExsUyuXRPgu7BNudwgw2nZS32b3nBZvHh7wRG i/e3LjFZ3Pgwk81i4omDrBZLj31gcmDz2HryB5vHzll32T2WLPnJ5PF9HpPHXaDCANYoLpuU 1JzMstQifbsErow9rbvYCpYZVEy9tJa1gfGxVhcjJ4eEgInEp8bLrBC2mMSFe+vZuhi5OIQE jjJK9E7bzwzhLGeUaHi5kAmkik1AR+Ly5hksILaIQJFE2+WZYB3MAn2MEv97zoMVCQsES3z+ M40ZoihEomvGPiYIO0li+t9bYM0sAqoSl7ddZQOxeQXsJc5d2Ai1rZFF4vzrFrCbOAViJR7O /g1WxCggK7H77HWwQcwC4hK3nsxngrhbROLhxdNsELaoxMvH/8B6RQX0JE7de8IMEVeU2Nc/ nb2LkQOot1Jiz50kiL2CEidnPmGZwCg2C8nUWQhVs5BUQZRoS+y5tZUZxn7y7gIrhG0tMePX QTYIW1FiSvdDdgjbVOL10Y+MCxg5VjFylBYX5OSmGxlsYgTG8jEJNt0djPenex5iFOBgVOLh Tah1DhdiTSwrrsw9xKgC1Ppow+oLjFIsefl5qUoivF59QGnelMTKqtSi/Pii0pzU4kOM0hws SuK8Yo8Uw4UE0hNLUrNTUwtSi2CyTBycUg2MQROPaN58ej7yb3qM8bUM//XCi2VMDu9I27pJ rHPHdn+BTbO6v8wPNNMvVeLpaVecFL367zTPMGee1UfTHv6sMNVIW8o9de2eX4tY+FikvJea /Y94xngv8Z5FzO4K96UcmhnpT7VOf1N7c+Bbxvza0Ody7bHZjOriL1x/zJ637XuA6tk7BWGM SizFGYmGWsxFxYkANHeN4e0CAAA= Archived-At: Cc: IPsecME WG , Daniel Migault , Paul Wouters , Tommy Pauly Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for adoption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 23:16:21 -0000 --B_3546864972_2089499017 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi=20 We use TLS to facilitate traversal of IPSEC traffic through http proxies. The client would use the HTTP Connect command to connect to the proxy. TLS is only used for this purpose and not for securing the IPSec link. Thanks. Samy. On 5/23/16, 3:55 PM, "IPsec on behalf of Hu, Jun (Nokia - US)" wrote: >> -----Original Message----- >> From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Yoav Nir >> Sent: Monday, May 23, 2016 2:13 PM >> To: Valery Smyslov >> Cc: IPsecME WG; Daniel Migault; Paul Wouters; Tommy Pauly >> Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for >> adoption >>=20 >>=20 >> > On 23 May 2016, at 9:39 AM, Valery Smyslov wrote: >> > >> > Hi Tommy, >> > >> > thank you for clarifications. One more point. The draft is silent >> > about what the responder is supposed to do with the stream prefix. >> > Should it check it? In this case what should it do if the prefix is >> > different from "IKEv2"? Discard the TCP session? Or should it ignore >> > the prefix completely? In this case how many bytes should it skip from >> > the beginning of the stream - exactly 5? >>=20 >> This prefix is used for de-multiplexing. For example, if we listen for I= KE on TCP >> port 443 and also have an HTTPS server there (perhaps as an administrati= ve >> interface). >>=20 >> Assuming we don=E2=80=99t encrypt IKE in TLS,=20 > >[HJ] this part is a bit confusing for me, if we don't use TLS level encryp= tion, then what's the benefit of using TLS over plain TCP encapsulation? In= fact, I don't know why TLS encapsulation is needed at all, it is said in th= e draft that " The security of the IKEv2 session is entirely derived from th= e IKVEv2 negotiation and key establishment", so encryption/authentication of= TLS level are not needed at all.=20 > >> then we need the prefix to differentiate >> between IKE and TLS. Currently, there=E2=80=99s no way a valid ClientHello beg= ins with >> =E2=80=9CIKEv2=E2=80=9D, and hopefully that will not change with TLS 1.3 or any futu= re version. If >> we do encapsulate IKEv2 in TLS, we still need to differentiate IKEv2 fro= m HTTP. >> And again, there is no HTTP method called =E2=80=9CIKEv2=E2=80=9D. > >>=20 >> So I think the parsing and consuming of this prefix is not part of the I= KE, but >> part of the de-multiplexer. If the port has several services, then not h= aving the >> =E2=80=9CIKEv2=E2=80=9D prefix means that the stream should be processed by some oth= er >> processor. If IKEv2 is the only service on that particular port, then we= need a >> very simple de-multiplexer: if the first 5 bytes are =E2=80=9CIKEv2=E2=80=9D then co= nsume them >> and forward the rest to the IKEv2 service. If it=E2=80=99s anything else, clos= e the >> connection. >>=20 > >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec --B_3546864972_2089499017 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 BQCgXTAjBgkqhkiG9w0BCQQxFgQUa3j0Avs+43DEhqsdMlkrpQR1ktIwGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNTIzMjMxNjEyWjANBgkqhkiG9w0B AQEFAASCAQBNnQ3PRA5hZKc/tXzUG5thOd5XarbNNx80vUIscCibSgsRMNup0iEucU05CbyP 9t0z9tmp5J62mDjv76p2JMOzbMiXeKAdhcEsAjx57XIpWn4/HzxdKdWktG0rUVrzQ/WfM1bY 9PL4buYWzNu7XM6rFEHXIA8rDjzjMc+Ws7wDBJBYmom28TZxiM+qou3fpLjpHcDoxwlbNkae 7U27J4m82quMSK2dLYWU8rUTeTbaqZMsC6huDqlnCeVbVwdKuMuIL4uNEjzetrruv4Tn/TXA ZJ5Xy7pfm4mOPBkO7TmNxgItJpS3f0IgVJ9EgP9w+zpTM6zNp3x0yG/xjhFExqMF --B_3546864972_2089499017-- From nobody Mon May 23 16:23:20 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB24612B078 for ; Mon, 23 May 2016 16:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03YlhjVewP32 for ; Mon, 23 May 2016 16:23:18 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (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 3387612B076 for ; Mon, 23 May 2016 16:23:17 -0700 (PDT) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id DDCC57E9648A0; Mon, 23 May 2016 23:23:13 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id u4NNNGkH027378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 May 2016 23:23:16 GMT Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id u4NNNFbC005106 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 May 2016 23:23:15 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.21]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Mon, 23 May 2016 19:23:15 -0400 From: "Hu, Jun (Nokia - US)" To: Paul Wouters Thread-Topic: [IPsec] New version of TCP Encapsulation draft, request for adoption Thread-Index: AQHRoLQbhmlKoxjITU+aiNyunbfH4p+ssGmAgAA064CAD3ujAIAAb1NwgAW3a4CAA7KaPIABNyaA///XDcCAAErtgP//vrdg Date: Mon, 23 May 2016 23:23:14 +0000 Message-ID: <876523B00C3F9D47BFD2B654D63DBF92BE97C73B@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <2C8840EB-AC99-401F-971A-2962B71FCC08@apple.com> <9CC56746-DCA5-42F0-8FBC-B3F5391989E6@apple.com> <291B3BE9-0F55-464A-8BDD-A85E803F452D@gmail.com> <876523B00C3F9D47BFD2B654D63DBF92BE97C61E@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for adoption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 23:23:20 -0000 > -----Original Message----- > From: Paul Wouters [mailto:paul@nohats.ca] > Sent: Monday, May 23, 2016 4:15 PM =20 > To get past middleware boxes that tend to not touch "real" TLS traffic bu= t > mangle anything else. [HJ] so there is middle box that will only allow TLS traffic (and dropping= all plain tcp traffic)? that sounds pretty extreme, but even in such case,= nothing prevent such middle box to have a new rule to drop TLS encapsulate= d IPsec traffic if TLS level encryption is not used. From nobody Mon May 23 16:25:55 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA9212B078 for ; Mon, 23 May 2016 16:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9_IzLgTYpEOv for ; Mon, 23 May 2016 16:25:53 -0700 (PDT) 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 0DC8012B04D for ; Mon, 23 May 2016 16:25:53 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3rDF5q3fBcz36S; Tue, 24 May 2016 01:25:51 +0200 (CEST) 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 tmWVIy1TuhH8; Tue, 24 May 2016 01:25:50 +0200 (CEST) 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, 24 May 2016 01:25:50 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 8CE00801ED1; Mon, 23 May 2016 19:25:49 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 8CE00801ED1 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 75B4D406B6F2; Mon, 23 May 2016 19:25:49 -0400 (EDT) Date: Mon, 23 May 2016 19:25:49 -0400 (EDT) From: Paul Wouters To: "Hu, Jun (Nokia - US)" In-Reply-To: <876523B00C3F9D47BFD2B654D63DBF92BE97C73B@US70UWXCHMBA05.zam.alcatel-lucent.com> Message-ID: References: <2C8840EB-AC99-401F-971A-2962B71FCC08@apple.com> <9CC56746-DCA5-42F0-8FBC-B3F5391989E6@apple.com> <291B3BE9-0F55-464A-8BDD-A85E803F452D@gmail.com> <876523B00C3F9D47BFD2B654D63DBF92BE97C61E@US70UWXCHMBA05.zam.alcatel-lucent.com> <876523B00C3F9D47BFD2B654D63DBF92BE97C73B@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for adoption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 23:25:54 -0000 On Mon, 23 May 2016, Hu, Jun (Nokia - US) wrote: >> To get past middleware boxes that tend to not touch "real" TLS traffic but >> mangle anything else. > > [HJ] so there is middle box that will only allow TLS traffic (and dropping all plain tcp traffic)? that sounds pretty extreme, but even in such case, nothing prevent such middle box to have a new rule to drop TLS encapsulated IPsec traffic if TLS level encryption is not used. Correct. There will always be that battle of deep packet inspection and proxies versus people who want to be protected from them. Paul From nobody Mon May 23 16:42:22 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE3612D5E1 for ; Mon, 23 May 2016 16:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjwL_ru3blau for ; Mon, 23 May 2016 16:42:18 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (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 C8B0512D189 for ; Mon, 23 May 2016 16:42:18 -0700 (PDT) Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id D9CB44D792444; Mon, 23 May 2016 23:42:14 +0000 (GMT) Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id u4NNgHoY020306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 May 2016 23:42:17 GMT Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id u4NNgHWP028971 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 May 2016 23:42:17 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.21]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Mon, 23 May 2016 19:42:17 -0400 From: "Hu, Jun (Nokia - US)" To: Paul Wouters Thread-Topic: [IPsec] New version of TCP Encapsulation draft, request for adoption Thread-Index: AQHRoLQbhmlKoxjITU+aiNyunbfH4p+ssGmAgAA064CAD3ujAIAAb1NwgAW3a4CAA7KaPIABNyaA///XDcCAAErtgP//vrdggABEYID//7/p8A== Date: Mon, 23 May 2016 23:42:16 +0000 Message-ID: <876523B00C3F9D47BFD2B654D63DBF92BE97C7FA@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <2C8840EB-AC99-401F-971A-2962B71FCC08@apple.com> <9CC56746-DCA5-42F0-8FBC-B3F5391989E6@apple.com> <291B3BE9-0F55-464A-8BDD-A85E803F452D@gmail.com> <876523B00C3F9D47BFD2B654D63DBF92BE97C61E@US70UWXCHMBA05.zam.alcatel-lucent.com> <876523B00C3F9D47BFD2B654D63DBF92BE97C73B@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for adoption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 23:42:20 -0000 > From: Paul Wouters [mailto:paul@nohats.ca] > Sent: Monday, May 23, 2016 4:26 PM > To: Hu, Jun (Nokia - US) > Cc: IPsecME WG > Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for > adoption >=20 > On Mon, 23 May 2016, Hu, Jun (Nokia - US) wrote: >=20 > >> To get past middleware boxes that tend to not touch "real" TLS > >> traffic but mangle anything else. > > > > [HJ] so there is middle box that will only allow TLS traffic (and drop= ping all > plain tcp traffic)? that sounds pretty extreme, but even in such case, no= thing > prevent such middle box to have a new rule to drop TLS encapsulated IPsec > traffic if TLS level encryption is not used. >=20 > Correct. There will always be that battle of deep packet inspection and p= roxies > versus people who want to be protected from them. [HJ] ok, so my takeaway is TLS encapsulation without encryption is useful f= or HTTP proxy traversal and some middle box only allows TLS traffic; howeve= r the draft doesn't prevent TLS encapsulation with encryption, which might = be useful to get around some really strict middle box which inspects TLS pa= yload.=20 From nobody Mon May 23 17:27:34 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E2612B00D for ; Mon, 23 May 2016 17:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.518 X-Spam-Level: X-Spam-Status: No, score=-5.518 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMCXcT5mVC58 for ; Mon, 23 May 2016 17:27:32 -0700 (PDT) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53A3512B044 for ; Mon, 23 May 2016 17:27:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1464049652; x=2327963252; 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=tzgHDupL7XxIA8qZez334GfbSSX4X3p1AFl7IBsXCnI=; b=wQ9L6Q8kUdxf5Wb4ZTfqqI1hPRFYXmBHC3EXs8vMweLMIsgAUyldRBtP0nZ8tled aHtPp773vmldfUHXog4wYNS2bY74rGobhbTkkdz2hKbvDU4o5tEkqksdf8sNPPow bvdP54rAWY4pDSUZclGcKl20oa9R3nUUhR66E0wpBruD5JRuh49IC55acvMIgxdd wWg1VuYtAokj3xKWWiGO85mk5j4tx7RH+ArqmNB/weOK77g6yuIT6U1MchylE9sf UoF/RTtUO3d9qihO9WJow1L0U5/jENB5Akk9Pvg2gC6ilEfJOlpzV097p3+5ncbZ zJADokWD5bWk2kHrsPEaHg==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 12.D2.06427.4FF93475; Mon, 23 May 2016 17:27:32 -0700 (PDT) X-AuditID: 11973e11-f79646d00000191b-3e-57439ff428e7 Received: from nwk-mmpp-sz08.apple.com (nwk-mmpp-sz08.apple.com [17.128.115.25]) (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 DA.2A.12923.3FF93475; Mon, 23 May 2016 17:27:32 -0700 (PDT) Received: from da0602a-dhcp220.apple.com (da0602a-dhcp220.apple.com [17.226.23.220]) by nwk-mmpp-sz08.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0O7N00GZ3NXV8YA0@nwk-mmpp-sz08.apple.com> for ipsec@ietf.org; Mon, 23 May 2016 17:27:31 -0700 (PDT) Sender: tpauly@apple.com Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 10.0 \(3186\)) From: Tommy Pauly In-reply-to: <876523B00C3F9D47BFD2B654D63DBF92BE97C7FA@US70UWXCHMBA05.zam.alcatel-lucent.com> Date: Mon, 23 May 2016 17:27:31 -0700 Content-transfer-encoding: quoted-printable Message-id: <929ED8F3-C262-4027-8ED8-177AC6B225F7@apple.com> References: <2C8840EB-AC99-401F-971A-2962B71FCC08@apple.com> <9CC56746-DCA5-42F0-8FBC-B3F5391989E6@apple.com> <291B3BE9-0F55-464A-8BDD-A85E803F452D@gmail.com> <876523B00C3F9D47BFD2B654D63DBF92BE97C61E@US70UWXCHMBA05.zam.alcatel-lucent.com> <876523B00C3F9D47BFD2B654D63DBF92BE97C73B@US70UWXCHMBA05.zam.alcatel-lucent.com> <876523B00C3F9D47BFD2B654D63DBF92BE97C7FA@US70UWXCHMBA05.zam.alcatel-lucent.com> To: "Hu, Jun (Nokia - US)" X-Mailer: Apple Mail (2.3186) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUi2FAYrPtlvnO4wYapXBb7t7xgc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvWPSQWfeSve7p7A1MA4ibuLkZNDQsBE4uqsX8wQtpjEhXvr 2boYuTiEBPYySsx58RfI4QArWtrkCRFfxiTR3XGIBcLZxSTxc8pxVpAiYQEJic17EkFMZgF1 iSlTckFm8groS8yf+58ZoiJYYkqbPUiYTUBF4vi3DWBrOQXiJb6/bmUBsVkEVCXufz7JCmIz C9hJdDxaDGVrSzx5d4EVYqSNxP2/99lAbCGBqWwSPWv8QGwRAV2J76dfQl0sK3FlsQTIkRIC C9gktv39zjqBUWQWwnGzkBw3C8mGBYzMqxiFchMzc3Qz84z0EgsKclL1kvNzNzGCgnq6neAO xuOrrA4xCnAwKvHwBuQ7hwuxJpYVV+YeYpTmYFES5z01ESgkkJ5YkpqdmlqQWhRfVJqTWnyI kYmDU6qBUUlfuKf9alvni1OKZwTb7p+oZrjmeT1N7dGq41K/zabIGLxV2NV4Yc2prI3nuEUm XXZ/U297uOBVLlu1WrWg4MdPh7ZYRlrXyEv8CnGty165ufiKyW9RDd+Uutvq2xt3Lt/WYGxm 73Ihzo1TW3LSl78HrOLZyhNUHbPFyo6kfz7Mbvx/btkBJZbijERDLeai4kQAFc/iiUsCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUi2FAsqftlvnO4wZsdTBb7t7xgc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvWPSQWfeSve7p7A1MA4ibuLkYNDQsBEYmmTZxcjJ5ApJnHh 3nq2LkYuDiGBZUwS3R2HWCCcXUwSP6ccZwVpEBaQkNi8JxHEZBZQl5gyJRekl1dAX2L+3P/M EBXBElPa7EHCbAIqEse/bWAGsTkF4iW+v25lAbFZBFQl7n8+yQpiMwvYSXQ8Wgxla0s8eXeB FWKkjcT9v/fZQGwhgalsEj1r/EBsEQFdie+nX7JBXC8rcWWxxARGwVkI98xCcs8sJEMXMDKv YhQoSs1JrDTWSywoyEnVS87P3cQIDsLC4B2Mf5ZZHWIU4GBU4uENyHcOF2JNLCuuzD3EKMHB rCTC+38eUIg3JbGyKrUoP76oNCe1+BBjMtArE5mlRJPzgRGSVxJvaGJiYGJsbGZsbG5iTpqw kjiv1m6ncCGB9MSS1OzU1ILUIpgtTBycUg2Mqn0H575x+6f+YvGUv3u7Fq35YWqg892dSzX2 6qUmc25Xhq1dX4+X6TQp37bQqOtt29hw6W/z1218GZ82Z3yufieQNpFJzjlC4W9LMe+N3vKF jt/8uwPmWejbRm24cD7WYd6xxnuHzx5e+u9A6DLTdb3Ptd+JN96uzn6SUNmu9tbs25fDP5Xe KrEUZyQaajEXFScCACAYBFGGAgAA Archived-At: Cc: IPsecME WG , Paul Wouters Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for adoption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 00:27:34 -0000 Hi Jun, You are correct=E2=80=94the draft specifically allows for the = possibility of doing encrypted TLS as a tunnel for the purposes of = getting through some middleboxes. There are some that will validate that = traffic is either HTTP or TLS, and since IKE traffic will not look like = HTTP, one could use TLS instead. Thanks, Tommy > On May 23, 2016, at 4:42 PM, Hu, Jun (Nokia - US) = wrote: >=20 >> From: Paul Wouters [mailto:paul@nohats.ca] >> Sent: Monday, May 23, 2016 4:26 PM >> To: Hu, Jun (Nokia - US) >> Cc: IPsecME WG >> Subject: Re: [IPsec] New version of TCP Encapsulation draft, request = for >> adoption >>=20 >> On Mon, 23 May 2016, Hu, Jun (Nokia - US) wrote: >>=20 >>>> To get past middleware boxes that tend to not touch "real" TLS >>>> traffic but mangle anything else. >>>=20 >>> [HJ] so there is middle box that will only allow TLS traffic (and = dropping all >> plain tcp traffic)? that sounds pretty extreme, but even in such = case, nothing >> prevent such middle box to have a new rule to drop TLS encapsulated = IPsec >> traffic if TLS level encryption is not used. >>=20 >> Correct. There will always be that battle of deep packet inspection = and proxies >> versus people who want to be protected from them. >=20 > [HJ] ok, so my takeaway is TLS encapsulation without encryption is = useful for HTTP proxy traversal and some middle box only allows TLS = traffic; however the draft doesn't prevent TLS encapsulation with = encryption, which might be useful to get around some really strict = middle box which inspects TLS payload.=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon May 23 19:38:20 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3000F12D4FE for ; Mon, 23 May 2016 19:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NmEIaVuBhgL for ; Mon, 23 May 2016 19:38:17 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (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 B58F512B05E for ; Mon, 23 May 2016 19:38:17 -0700 (PDT) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id A058962658967; Tue, 24 May 2016 02:38:15 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id u4O2cGFs027502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 May 2016 02:38:16 GMT Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id u4O2cF7E015538 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 May 2016 02:38:15 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.21]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Mon, 23 May 2016 22:38:15 -0400 From: "Hu, Jun (Nokia - US)" To: "tpauly@apple.com" Thread-Topic: [IPsec] New version of TCP Encapsulation draft, request for adoption Thread-Index: AQHRoLQbhmlKoxjITU+aiNyunbfH4p+ssGmAgAA064CAD3ujAIAAb1NwgAW3a4CAA7KaPIABNyaA///XDcCAAErtgP//vrdggABEYID//7/p8AAKKqGAAAPSU8A= Date: Tue, 24 May 2016 02:38:15 +0000 Message-ID: <876523B00C3F9D47BFD2B654D63DBF92BE97CB3A@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <2C8840EB-AC99-401F-971A-2962B71FCC08@apple.com> <9CC56746-DCA5-42F0-8FBC-B3F5391989E6@apple.com> <291B3BE9-0F55-464A-8BDD-A85E803F452D@gmail.com> <876523B00C3F9D47BFD2B654D63DBF92BE97C61E@US70UWXCHMBA05.zam.alcatel-lucent.com> <876523B00C3F9D47BFD2B654D63DBF92BE97C73B@US70UWXCHMBA05.zam.alcatel-lucent.com> <876523B00C3F9D47BFD2B654D63DBF92BE97C7FA@US70UWXCHMBA05.zam.alcatel-lucent.com> <929ED8F3-C262-4027-8ED8-177AC6B225F7@apple.com> In-Reply-To: <929ED8F3-C262-4027-8ED8-177AC6B225F7@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: IPsecME WG , Paul Wouters Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for adoption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 02:38:20 -0000 VGhhbmtzIGFsbCBmb3IgdGhlIGNsYXJpZmljYXRpb24uIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IHRwYXVseUBhcHBsZS5jb20gW21haWx0bzp0cGF1bHlAYXBwbGUu Y29tXQ0KPiBTZW50OiBNb25kYXksIE1heSAyMywgMjAxNiA1OjI4IFBNDQo+IFRvOiBIdSwgSnVu IChOb2tpYSAtIFVTKQ0KPiBDYzogUGF1bCBXb3V0ZXJzOyBJUHNlY01FIFdHDQo+IFN1YmplY3Q6 IFJlOiBbSVBzZWNdIE5ldyB2ZXJzaW9uIG9mIFRDUCBFbmNhcHN1bGF0aW9uIGRyYWZ0LCByZXF1 ZXN0IGZvcg0KPiBhZG9wdGlvbg0KPiANCj4gSGkgSnVuLA0KPiANCj4gWW91IGFyZSBjb3JyZWN0 4oCUdGhlIGRyYWZ0IHNwZWNpZmljYWxseSBhbGxvd3MgZm9yIHRoZSBwb3NzaWJpbGl0eSBvZiBk b2luZw0KPiBlbmNyeXB0ZWQgVExTIGFzIGEgdHVubmVsIGZvciB0aGUgcHVycG9zZXMgb2YgZ2V0 dGluZyB0aHJvdWdoIHNvbWUNCj4gbWlkZGxlYm94ZXMuIFRoZXJlIGFyZSBzb21lIHRoYXQgd2ls bCB2YWxpZGF0ZSB0aGF0IHRyYWZmaWMgaXMgZWl0aGVyIEhUVFAgb3IgVExTLA0KPiBhbmQgc2lu Y2UgSUtFIHRyYWZmaWMgd2lsbCBub3QgbG9vayBsaWtlIEhUVFAsIG9uZSBjb3VsZCB1c2UgVExT IGluc3RlYWQuDQo+IA0KPiBUaGFua3MsDQo+IFRvbW15DQo+IA0KPiA+IE9uIE1heSAyMywgMjAx NiwgYXQgNDo0MiBQTSwgSHUsIEp1biAoTm9raWEgLSBVUykgPGp1bi5odUBub2tpYS5jb20+IHdy b3RlOg0KPiA+DQo+ID4+IEZyb206IFBhdWwgV291dGVycyBbbWFpbHRvOnBhdWxAbm9oYXRzLmNh XQ0KPiA+PiBTZW50OiBNb25kYXksIE1heSAyMywgMjAxNiA0OjI2IFBNDQo+ID4+IFRvOiBIdSwg SnVuIChOb2tpYSAtIFVTKQ0KPiA+PiBDYzogSVBzZWNNRSBXRw0KPiA+PiBTdWJqZWN0OiBSZTog W0lQc2VjXSBOZXcgdmVyc2lvbiBvZiBUQ1AgRW5jYXBzdWxhdGlvbiBkcmFmdCwgcmVxdWVzdA0K PiA+PiBmb3IgYWRvcHRpb24NCj4gPj4NCj4gPj4gT24gTW9uLCAyMyBNYXkgMjAxNiwgSHUsIEp1 biAoTm9raWEgLSBVUykgd3JvdGU6DQo+ID4+DQo+ID4+Pj4gVG8gZ2V0IHBhc3QgbWlkZGxld2Fy ZSBib3hlcyB0aGF0IHRlbmQgdG8gbm90IHRvdWNoICJyZWFsIiBUTFMNCj4gPj4+PiB0cmFmZmlj IGJ1dCBtYW5nbGUgYW55dGhpbmcgZWxzZS4NCj4gPj4+DQo+ID4+PiBbSEpdICBzbyB0aGVyZSBp cyBtaWRkbGUgYm94IHRoYXQgd2lsbCBvbmx5IGFsbG93IFRMUyB0cmFmZmljIChhbmQNCj4gPj4+ IGRyb3BwaW5nIGFsbA0KPiA+PiBwbGFpbiB0Y3AgdHJhZmZpYyk/IHRoYXQgc291bmRzIHByZXR0 eSBleHRyZW1lLCBidXQgZXZlbiBpbiBzdWNoDQo+ID4+IGNhc2UsIG5vdGhpbmcgcHJldmVudCBz dWNoIG1pZGRsZSBib3ggdG8gaGF2ZSBhIG5ldyBydWxlIHRvIGRyb3AgVExTDQo+ID4+IGVuY2Fw c3VsYXRlZCBJUHNlYyB0cmFmZmljIGlmIFRMUyBsZXZlbCBlbmNyeXB0aW9uIGlzIG5vdCB1c2Vk Lg0KPiA+Pg0KPiA+PiBDb3JyZWN0LiBUaGVyZSB3aWxsIGFsd2F5cyBiZSB0aGF0IGJhdHRsZSBv ZiBkZWVwIHBhY2tldCBpbnNwZWN0aW9uDQo+ID4+IGFuZCBwcm94aWVzIHZlcnN1cyBwZW9wbGUg d2hvIHdhbnQgdG8gYmUgcHJvdGVjdGVkIGZyb20gdGhlbS4NCj4gPg0KPiA+IFtISl0gb2ssIHNv IG15IHRha2Vhd2F5IGlzIFRMUyBlbmNhcHN1bGF0aW9uIHdpdGhvdXQgZW5jcnlwdGlvbiBpcyB1 c2VmdWwgZm9yDQo+IEhUVFAgcHJveHkgdHJhdmVyc2FsIGFuZCBzb21lIG1pZGRsZSBib3ggb25s eSBhbGxvd3MgVExTIHRyYWZmaWM7IGhvd2V2ZXIgdGhlDQo+IGRyYWZ0IGRvZXNuJ3QgcHJldmVu dCBUTFMgZW5jYXBzdWxhdGlvbiB3aXRoIGVuY3J5cHRpb24sIHdoaWNoIG1pZ2h0IGJlIHVzZWZ1 bA0KPiB0byBnZXQgYXJvdW5kIHNvbWUgcmVhbGx5IHN0cmljdCBtaWRkbGUgYm94IHdoaWNoIGlu c3BlY3RzIFRMUyBwYXlsb2FkLg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gPiBJUHNlYyBtYWlsaW5nIGxpc3QNCj4gPiBJUHNlY0Bp ZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWMN Cg0K From nobody Thu May 26 06:12:29 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477FF12D5FF for ; Thu, 26 May 2016 06:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.165 X-Spam-Level: ** X-Spam-Status: No, score=2.165 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_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, STOX_REPLY_TYPE_WITHOUT_QUOTES=1.757] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZ_hrJuPJwhw for ; Thu, 26 May 2016 06:12:27 -0700 (PDT) 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 1848112D658 for ; Thu, 26 May 2016 06:12:24 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id k98so32375905lfi.1 for ; Thu, 26 May 2016 06:12:23 -0700 (PDT) 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-transfer-encoding; bh=bdQgqj3E+X4EBc1iDHZLRQCCXqCP9rOz53gc9gC+1KY=; b=E8rbwamTqpA90mOSYSR3ZbdTI39mdQAvdIpxvO+jQDRBysAw99MEfXNia1YY2hQ9OI hHk2fsLHc/1pVCUwH2frntcazIx7LHzBq/o5YZ3n2SVGH1q2DF6MXWfrl+mHJLy4swly 1vKX4GMEMLGh3Ju05HNhPLgjgwAHFtXUkL19NEXvHfoGSJc06jTnJuOsXyWE0yJUMd9S i/l9jk+SBIm4rGQUFV/vK9YMiJkU+At8DRCUAkLJBv8e5RVIF4rN4yb4D9h9pOWtzL5X hOfR/tEfO/eL5abJfNa7aDyS8jg/e2Bb6oqg3/svUnYci/HWBZOnnAafLlceIFdMRu/I gqyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:subject:date:mime-version :content-transfer-encoding; bh=bdQgqj3E+X4EBc1iDHZLRQCCXqCP9rOz53gc9gC+1KY=; b=YLTu82iohMDDEP05zNwv/HOZ/Jy8u5EC3ee4dhcA46WVGfFaz5CranJYVWe9P1EDtg f9b1ETiAYXa70ohGlYxLXWmrqm7Rr+zveSHWg/cKlnNr8YTrbzoZvpVOlOwxp4qElouX TblKRhDDp0AtruRe9n59MWHz4pfSCGQwflgW6hbO9nzYh/rXDevd9mr+2QT6NAC3QxuF rB9ZkI4WSfPsIel/RreZeLeMmdREOmwhegJL0E+0gctc2RrEzQayXfdVfTJAHCwbt4XN twIOHjiV4yDrdD5ngC+z/bNof9M2slxQCAQdU4NEwwQ1KlibJb2/tnYMUhSgCNx7C/LC xA4w== X-Gm-Message-State: ALyK8tKss8uWC5xIBZJf0vKWz0LpW0rNVeCO7PHYCd9EJvi7xVqUyfwhVf664JGriSmOrg== X-Received: by 10.25.16.27 with SMTP id f27mr2762920lfi.114.1464268342247; Thu, 26 May 2016 06:12:22 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id h72sm59907ljh.38.2016.05.26.06.12.21 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 May 2016 06:12:21 -0700 (PDT) Message-ID: <860C938B60E24C76A1749A1563D53A55@buildpc> From: "Valery Smyslov" To: Date: Thu, 26 May 2016 16:12:19 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; 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] Status of draft-ietf-ipsecme-ddos-protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 13:12:28 -0000 Hi, in Buenos-Aires it was expressed a proposal to split the DDoS protection draft into two. One of them would describe possible kinds of (D)DoS attacks and would suggest some counter measures to thwart them without introducing anything new into the IKEv2 protocol. The other document (with Experimental status) would describe the puzzles and would define a new IKEv2 extension defending against (D)DoS attacks using puzzles. The main motivation for such a proposal was a concern that puzzles mechanism would not be as effective as it was initially intended to be, and might even make things worse for "small" devices. On the other hand, if we go this way and give the puzzles stuff an Experimantal status, then probably very few vendors (if any) will implement it and the real problem of defending against (D)DoS attacks will remain unaddressed. So, what folks think about this proposal? Regards, Valery & Yoav. From nobody Thu May 26 07:26:01 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0138812D6E1 for ; Thu, 26 May 2016 07:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sclLRWXNsLKy for ; Thu, 26 May 2016 07:25:59 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::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 733F712D0E5 for ; Thu, 26 May 2016 07:25:59 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id n129so229871913wmn.1 for ; Thu, 26 May 2016 07:25:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EyCJOM/X+NterlMG3yTqugy13YdrJ7217Ackg3HUwWk=; b=xlW9/cexQOoYpejkCSMsEy0rCjEiHPBzNE9JOy4vJsCw2bLZgCbYx/Z4b9YAJykpQB xX7ThjSXdCT2k9yDuYUOeUKCZMmkcS7B4/rYPdU1NhwcZJVtYKVRpeT5K1u0Eopi+qBe WBnPOF6QONLYhfDbFhzgrz3s+3lHCG+7Fdb1juXTSyMj0h50pil1RlwelBWBCgf4G2Hn kp5rme4KBNBBX6kTDMo7geRM/XYNt6MTCXN+Q8i9b2xNysGa/T5pc+bc3tbBSVUjt7Qc mWHEoU3Uw+O0OEux+9JnmesgADFOVtrVUy7hcwg8IdpVHIaRl7Y9FM7+YOATDM/y3+rG gD3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EyCJOM/X+NterlMG3yTqugy13YdrJ7217Ackg3HUwWk=; b=cVY7LggqciIYzr6eaoLmPoUdXcfaft2E7E2Dhkv+MU7t3xkM5hOKGlFwnuINBoeRK6 Oeu+GiVPgDAwgGEY91/bVcspd+oVm6YlKzAZfFYoyr32T1sklJ1W0tvTIH2QiOGslHzj 39u/aTCVdrjLGVwL7uFU/jRqJL9N0OkxGdVXGCFGIlBVDXMLmUXJng+wUMhKHmZLbhjI AHd3PnPksh6XEvHsdGbxGvS79aVrVWg9CzOqJhb7VgeEo7ZvV6uzfSH/mqO83sLaUlBm dfTh81WEdL5f2sYqV1ciOB2DFftE7DBmCrIZf2b1RErAm0AGgJaiP0JFHTvRZ/Q7/Nkc DOyA== X-Gm-Message-State: ALyK8tL4eCABdnECvzg6tvaWEL/3AkdjUGBtr28mcsKSjmQOsAfUiimb8R9V+EpuZnD0cg== X-Received: by 10.28.131.80 with SMTP id f77mr4183259wmd.80.1464272758038; Thu, 26 May 2016 07:25:58 -0700 (PDT) Received: from [172.24.249.173] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id n15sm14634291wjr.1.2016.05.26.07.25.56 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 26 May 2016 07:25:56 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 From: Yoav Nir X-Priority: 3 In-Reply-To: <860C938B60E24C76A1749A1563D53A55@buildpc> Date: Thu, 26 May 2016 17:25:53 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <66526EB9-FFF0-4D99-B960-15990AF6F161@gmail.com> References: <860C938B60E24C76A1749A1563D53A55@buildpc> To: Valery Smyslov X-Mailer: Apple Mail (2.3124) Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] Status of draft-ietf-ipsecme-ddos-protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 14:26:01 -0000 Hi, On 26 May 2016, at 4:12 PM, Valery Smyslov wrote: > Hi, >=20 > in Buenos-Aires it was expressed a proposal to split the DDoS = protection draft into two. One of them would > describe possible kinds of (D)DoS attacks and would suggest some = counter measures to thwart them without > introducing anything new into the IKEv2 protocol. > The other document (with Experimental status) would describe the = puzzles and would define a new IKEv2 extension defending against (D)DoS = attacks using puzzles. >=20 > The main motivation for such a proposal was a concern > that puzzles mechanism would not be as effective as it was initially = intended to be, and might even make things worse for "small" devices.=20 > On the other hand, if we go this way and give the puzzles stuff an = Experimantal status, then probably very few vendors (if any) will = implement it and the real problem of defending against > (D)DoS attacks will remain unaddressed. >=20 > So, what folks think about this proposal? >=20 > Regards, > Valery & Yoav. One more data point. My employer has implemented puzzles in older = versions of our remote access client and gateway. It worked fine, but we = don=E2=80=99t have any numbers on whether it actually stopped DoS = attacks. We ended up abandoning it for IPR reasons, which is why this = draft uses an entirely different kind of puzzle. Regards, Yoav From nobody Mon May 30 10:15:07 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF62E12B05D for ; Mon, 30 May 2016 10:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKZCwBOAqMwC for ; Mon, 30 May 2016 10:15:04 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DBCE12D0C2 for ; Mon, 30 May 2016 10:15:04 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3rJNXg5zyRz40p; Mon, 30 May 2016 19:14:59 +0200 (CEST) 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 N7zuheH3oorv; Mon, 30 May 2016 19:14:58 +0200 (CEST) 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; Mon, 30 May 2016 19:14:58 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id D70F1801EF0; Mon, 30 May 2016 13:14:57 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca D70F1801EF0 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id BC58D41EEB57; Mon, 30 May 2016 13:14:57 -0400 (EDT) Date: Mon, 30 May 2016 13:14:57 -0400 (EDT) From: Paul Wouters To: Valery Smyslov In-Reply-To: <860C938B60E24C76A1749A1563D53A55@buildpc> Message-ID: References: <860C938B60E24C76A1749A1563D53A55@buildpc> User-Agent: Alpine 2.20 (LRH 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] Status of draft-ietf-ipsecme-ddos-protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 17:15:06 -0000 On Thu, 26 May 2016, Valery Smyslov wrote: > On the other hand, if we go this way and give the puzzles stuff an > Experimantal status, then probably very few vendors (if any) will implement > it and the real problem of defending against > (D)DoS attacks will remain unaddressed. I don't think the puzzles implementation adoption will be much different from whether it is part of the ddos document or a stand-alone document. Paul From nobody Mon May 30 22:01:36 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B846F12B008 for ; Mon, 30 May 2016 22:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1WdQE308TK5 for ; Mon, 30 May 2016 22:01:33 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5309812D0DA for ; Mon, 30 May 2016 22:01:33 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id k98so82348155lfi.1 for ; Mon, 30 May 2016 22:01:33 -0700 (PDT) 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-transfer-encoding; bh=omGVMb/D+oHfnhefS0zlD6lv0ohr6w1DbMH2JVBgmU0=; b=Zlp3X7K0Daht1Oy63R6YZXLXdl1c8HfhjRnLZZOnQWFxNtMDRrLow2PVxbYo5lCJmt a5adDsQh6trHbMZunXL4MTu2JYbBH/HTIStNMslwCNKKOoEHTN1nA+gih3KAQRyZcbOw /1RuDpKboitiaXuY4GD9MvDMCnHRQbHHvZ/4l3JUEqmZD0qIa/gB1etf3cnpmn/mHhdt 3hKTuFELc3oSCNNKo2dfcIdnxpJgRSqUrNTt9Su6bDrI//jsEygEmdMQUTfGiBm312u2 ktgCylk9utzZ4VDPqE73OHFMlSnP8UkUkpO2ZF8h83XmTJNNZKCuip3aybBsnsf2VE6H 5ocg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-transfer-encoding; bh=omGVMb/D+oHfnhefS0zlD6lv0ohr6w1DbMH2JVBgmU0=; b=AvLF83UDpfbnMQ2BnamKcoaZfRNHbWIoWvCBeTVJUSwt/jlliuEBs2hQUTwUnX67uJ bB50zUSMClP/5CWE+sx0v6YryYOPM7BVMS1c3O8/00uyKDzJX2qtaRglfmUmmQvYsLI+ lxFVRvK7773P18eaynzIcfZ4mte8Mjgj+PwT0RAOJiSpTvVASW0qvG73FlUpVjasACv+ VhKG+kYb63h4Mey3sI+aCJh4bM/yoPUx5hcF9IMiGabkO68ZQMfTxkN0HTsF9/teMvHx A7wbZoxl3y7vdwZ2Koj4I40vxHmZry4Zf289XCr22mdERybY5g1TJt9NOb+cfoNa9Ney i5kg== X-Gm-Message-State: ALyK8tJF4jag14yBW33ffupML7Q0ZLern+en0aQXYJx8KeCPkTRk/N93tuQrUaeHCDzd7A== X-Received: by 10.25.155.206 with SMTP id d197mr2756294lfe.121.1464670891278; Mon, 30 May 2016 22:01:31 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id 66sm2758342ljf.8.2016.05.30.22.01.30 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 May 2016 22:01:30 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Paul Wouters" References: <860C938B60E24C76A1749A1563D53A55@buildpc> Date: Tue, 31 May 2016 08:01:24 +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] Status of draft-ietf-ipsecme-ddos-protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 05:01:36 -0000 Hi Paul, >> On the other hand, if we go this way and give the puzzles stuff an >> Experimantal status, then probably very few vendors (if any) will implement >> it and the real problem of defending against >> (D)DoS attacks will remain unaddressed. > > I don't think the puzzles implementation adoption will be much different from > whether it is part of the ddos document or a stand-alone document. The concern is not about stand-alone puzzles document. It is about an Experimental status of that document versus Standards Track in the current draft. Vendors tend to ignore Experimental RFCs. > Paul Regards, Valery. From nobody Mon May 30 22:43:55 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20FEB12D136 for ; Mon, 30 May 2016 22:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-CSBqUzpAQE for ; Mon, 30 May 2016 22:43:52 -0700 (PDT) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (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 4D06212D66F for ; Mon, 30 May 2016 22:43:46 -0700 (PDT) Received: by mail-wm0-x242.google.com with SMTP id n129so28961905wmn.1 for ; Mon, 30 May 2016 22:43:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=P1Jd6tgZqX0SMRm2BBIRM/vAyz4vY3WCbJNU2py0L6g=; b=RahAXmHf8cV3oAnti5O/Kqs0OunNpZBYPIsnWMnTU33zEL4qa+VP5x+nKdSlpzoOxk xdiAnQXofznST15i86vI6RYMXQWIDe/+NJVgQAXHLRi7Regg+EAtH2QFbD0gXWtRMTxj M9Jl+jihHAsukqn3TuftIqDZywfuGJuZXvYoz7jAFQJ547/5qZImv3hIhT6NtmAHV4sF emXZpjgJusmMFTY0ahwcT8HGhe2jay6fbrSksk9kHTg/5ydVjWcwyMLqV+aPTR9SLPYN /dhBG921C1rVP5g297QDc7EerQHlRUwl0OS1PSYdSLdthCB90cPJLpL+1IhL5n3mzpYU JPJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=P1Jd6tgZqX0SMRm2BBIRM/vAyz4vY3WCbJNU2py0L6g=; b=mSuBXZ24fglcKRPKm2TrtP6nD3Att1+6N3ZVAe34BTtps9PxoXTeJANjNsS3Zf/C7t n9MCd7Bi4IZvTrY+Jja9hkImJsy14YCnUvkhRJywjmTEkkrWffvldDQFrnihhe62NRQN UQEHnvKj/rEaxsLoscDyThqY+svbrGvRlaaiJ+SzPHvUs/XOwAnB6/MdvVqbTTn9I34k WfckNz8k+JFcWoYcO7lSCM0wqVaCSa25Zr4Budl2SnKU9IuQEfjVTKDj4+OqVjdvswqp uV/bCNvamRARjDnNIhjIc9CVIgmJO+2ikRt3iPA9wIoLym+G76usUlu2j7ikeg6e1TJ5 bOIw== X-Gm-Message-State: ALyK8tLbrR7i8zxsIvOlrsvfe3jEKqdJfOlfDaXGw+s/lDzad8D0epHIYrG0q6bjQ0ni8A== X-Received: by 10.28.8.17 with SMTP id 17mr633619wmi.67.1464673424881; Mon, 30 May 2016 22:43:44 -0700 (PDT) Received: from [192.168.137.214] ([95.35.61.129]) by smtp.gmail.com with ESMTPSA id xz3sm22193145wjb.35.2016.05.30.22.43.42 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 30 May 2016 22:43:44 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 From: Yoav Nir X-Priority: 3 In-Reply-To: Date: Tue, 31 May 2016 08:43:47 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6ECFA010-549C-45DF-9D88-3D916D706A0D@gmail.com> References: <860C938B60E24C76A1749A1563D53A55@buildpc> To: Valery Smyslov X-Mailer: Apple Mail (2.3124) Archived-At: Cc: ipsec@ietf.org, Paul Wouters Subject: Re: [IPsec] Status of draft-ietf-ipsecme-ddos-protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 05:43:54 -0000 > On 31 May 2016, at 8:01 AM, Valery Smyslov wrote: >=20 > Hi Paul, >=20 >>> On the other hand, if we go this way and give the puzzles stuff an = Experimantal status, then probably very few vendors (if any) will = implement it and the real problem of defending against >>> (D)DoS attacks will remain unaddressed. >> I don't think the puzzles implementation adoption will be much = different from >> whether it is part of the ddos document or a stand-alone document. >=20 > The concern is not about stand-alone puzzles document. It is about an = Experimental status > of that document versus Standards Track in the current draft. Vendors = tend to ignore Experimental RFCs. The conventional wisdom is that vendors tend to ignore whatever status = the IETF assigns to documents and implement whatever meets their goals. My preference is to keep it all in one document, and clearly state that = the puzzle part of the document is OPTIONAL, meaning that you can comply = with the RFC even without implementing it.=20 There is a concern about an Initiator that does not implement puzzles = connecting to a Responder that does. Things will work fine until there = is a DoS attack and then we=E2=80=99re helping the attacker by denying = service to the non-implementing Initiator. And that could happen between = an Initiator and Responder, both of whom can claim compliance with the = document. This isn=E2=80=99t great, but separating them into two = documents does not make the problem go away. Yoav From nobody Mon May 30 23:04:49 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA6612D637 for ; Mon, 30 May 2016 23:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.491 X-Spam-Level: X-Spam-Status: No, score=-1.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzoacSJ8XLY1 for ; Mon, 30 May 2016 23:04:46 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::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 5219612D660 for ; Mon, 30 May 2016 23:04:45 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id s64so59065275lfe.0 for ; Mon, 30 May 2016 23:04:45 -0700 (PDT) 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-transfer-encoding; bh=8eHn67QxA07GbeDsVPUVzY3X4WsCaxIFDoZm5DnXdxc=; b=Ga3PUKnycMYL2nCl1s/6K3rxWlQyKjEUpGGl5+XjSN51d7Ge0222f/eKZS6y/vzNlA BV8DhdbyAJAm4xhryqKJG7GdsJMO7fOp9B8WoNqDLLTRS84as/hjO4Ac3V0Iyr4KThrG ithm7AjGs1eo/aGfITEE5Ci31K2YCcaDLZ9rlVM7bjgoWDB4VuYA1mxj5eL0DqDW5aR7 raxxdfIoZCSI26BPZd8wWsFe56QNbqibO15Cc29jzqnR0aVMS0ITXDQ/3yB3DovokyN4 rnchF22o/C/nBl4vE07e0cBW4EUXi6/C9hj+zAkPvRzPXe/uOHoBwLUf2P2//uMfoQ0H JUiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-transfer-encoding; bh=8eHn67QxA07GbeDsVPUVzY3X4WsCaxIFDoZm5DnXdxc=; b=PprgZ3eCLEZ61IHdlj44EJZwC+tcCqjEGQ+IAClNdKXTN8DautGyT9XT6rHqeT2432 5fU9QM1o6iteDZhTF3Bapx4XHJhMg8yUAAtaOLrPy7i5ieGLC8drRUXJ8X+JaRefD54f g6Jq5SxbKLXtn832QyqbZyhFIHVC6ZNwyIJsXh+WfPFfUnH0a0LRzSX55lpCBcVBoyHO PR7a+NwdHJASGn4tSdK+8fjDDB4h3njeGsW1UTmW+Nfb1VD8k3hbR4SbUhy9LdPZasZX nveahkoIgM9VnsRw1daRZQFfchV4suA5fclUmI7O5uEAQ0JhpKIQWtUCzILhhqyzVH2g x3eg== X-Gm-Message-State: ALyK8tL95ebg84iMGnyRe1qtwmkKPCxquWDmD8EqiuWCW/1dtNXXu/2l35Vz26uQrk6rEw== X-Received: by 10.46.5.143 with SMTP id 137mr6983233ljf.7.1464674683108; Mon, 30 May 2016 23:04:43 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id m8sm5153483lfe.15.2016.05.30.23.04.42 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 May 2016 23:04:42 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Yoav Nir" References: <860C938B60E24C76A1749A1563D53A55@buildpc> <6ECFA010-549C-45DF-9D88-3D916D706A0D@gmail.com> Date: Tue, 31 May 2016 09:04:37 +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, Paul Wouters Subject: Re: [IPsec] Status of draft-ietf-ipsecme-ddos-protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 06:04:48 -0000 >> The concern is not about stand-alone puzzles document. It is about an Experimental status >> of that document versus Standards Track in the current draft. Vendors tend to ignore Experimental RFCs. > > The conventional wisdom is that vendors tend to ignore whatever status the IETF assigns to documents and implement > whatever meets their goals. That's true in general. However Experimaental status makes vendors more suspicious that they will spend resources implementing the protocol and gain little, because most other vendors will refrane from implementing it. For puzzles to work they must become ubiquitous. > My preference is to keep it all in one document, and clearly state that the puzzle part of the document is OPTIONAL, > meaning that you can comply with the RFC even without implementing it. That's my preference too. In fact, the current draft doesn't mandate to implement (or even to use) puzzles, so they are already optional. > There is a concern about an Initiator that does not implement puzzles connecting to a Responder that does. > Things will work fine until there is a DoS attack and then we’re helping the attacker by denying service > to the non-implementing Initiator. And that could happen between an Initiator and Responder, > both of whom can claim compliance with the document. This isn’t great, but separating them into two documents > does not make the problem go away. That's true. > Yoav Regards, Valery. From nobody Tue May 31 08:06:07 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E484212D7D7 for ; Tue, 31 May 2016 08:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u_W-Fo9jM2kR for ; Tue, 31 May 2016 08:06:02 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::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 8516B12D600 for ; Tue, 31 May 2016 08:05:59 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id r140so264361494vkf.0 for ; Tue, 31 May 2016 08:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=gwtcGUhcnkKw/SoOwy4x6z0oFbR+P+noBcewyqu80ak=; b=1Fmt8sNsV1OqcwnpGU7tcz/IoMiVxU2xTqp4OA/yqhMoNMuKCCWpzdsf8bSV0M8EYq KJoFXqtPEC9Iv3v4hCtYhE/d3wlRkoZI614LUQY0kPWJzI0hqWVvJTAO49PeIWQD05R6 EbT5tCCs79ga8utjT+MbeeKK73mwpcy4VxGeQ5fyEI1mQq+BTKMib+RHsDZGJ1Nu/SXh vxI2iVCKL7rH6L7XHeQ9i5tZ0miL78NrrxmkZeyr/MgSKUrNyGCbZExurpW3BIIlbEXY H2AmfT/NlLYMsMyqQBCasYQKIpPRRrYhDsFK2LQA3s9ISqe700t9HVYSgmOo0Rxhjy1z ybbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=gwtcGUhcnkKw/SoOwy4x6z0oFbR+P+noBcewyqu80ak=; b=Zy5fS4rXTpodAZ+LE0ikVnWIiBfY6uE2CTAV/Q+eQuJtLZotZOyt7y6AYLnTr3mfTx 9LJAs4tHxRRk5KnTSQFeMqvIlw0/x6tKxlad4+lM8yiQEqeOvLXXYgbAkuAB+3Gb+z75 nsjura5FyE4ULNDW0g/9k2lZ9fx+naq9U8EseV5dC3VFaB3kA3GbG6Rt/M6j20xSferJ B9XptuUNepK8ZsByJAz8N3RU/bXl43yGz1Nj0jJLMw97fTQBh6jJeIO8HrPWPx9yqv1W pibTixPcXsNpIwDpv9Z6A6nhJeIM0/Pkx56BjlPxio7W0JJqSIsqiam9Xvkr7+YQuod3 rqLA== X-Gm-Message-State: ALyK8tLG4ANHfJG/CsgantrjJN2J3MvtvEo6tlxN69QiDgl0Lq02h0QTnkZnKBjud/MNln4Y8SOl+ZfDQIs7tQ== MIME-Version: 1.0 X-Received: by 10.31.85.3 with SMTP id j3mr17376779vkb.156.1464707158680; Tue, 31 May 2016 08:05:58 -0700 (PDT) Received: by 10.159.32.167 with HTTP; Tue, 31 May 2016 08:05:58 -0700 (PDT) Date: Tue, 31 May 2016 11:05:58 -0400 Message-ID: From: Kathleen Moriarty To: "ipsec@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [IPsec] Chairs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 15:06:04 -0000 Hello! I'd like to thank Paul for his many years chairing IPSecMe! We look forward to your continued participation. Tero Kivinen has volunteered to co-chair the working group and still be active as a individual as not to impact the working group. Thank you both! The tools changes are in progress. -- Best regards, Kathleen From nobody Tue May 31 08:14:58 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B30612D603 for ; Tue, 31 May 2016 08:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUnmxEjVaqcw for ; Tue, 31 May 2016 08:14:55 -0700 (PDT) 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 282EB12D0DD for ; Tue, 31 May 2016 08:14:55 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3rJxqb6lwKz4CZ for ; Tue, 31 May 2016 17:14:51 +0200 (CEST) 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 PNNlw3d9n4K2 for ; Tue, 31 May 2016 17:14:51 +0200 (CEST) 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 for ; Tue, 31 May 2016 17:14:51 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 3F87E677A53; Tue, 31 May 2016 11:14:50 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 3F87E677A53 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 28818406538B for ; Tue, 31 May 2016 11:14:50 -0400 (EDT) Date: Tue, 31 May 2016 11:14:49 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Chairs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 15:14:57 -0000 On Tue, 31 May 2016, Kathleen Moriarty wrote: > I'd like to thank Paul for his many years chairing IPSecMe! We look > forward to your continued participation. > > Tero Kivinen has volunteered to co-chair the working group and still > be active as a individual as not to impact the working group. Thanks to PaulH for his many years as chair. And thanks for Tero to filling in the gap! Looking forward to David and Tero putting some documents into working group adoption calls :) Paul From nobody Tue May 31 09:15:19 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C818512D622 for ; Tue, 31 May 2016 09:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIygDlfvhFhO for ; Tue, 31 May 2016 09:15:16 -0700 (PDT) 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 5154012D61D for ; Tue, 31 May 2016 09:15:16 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3rJz9F05F4z4FV for ; Tue, 31 May 2016 18:15:13 +0200 (CEST) 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 22jbqpFfNjtw for ; Tue, 31 May 2016 18:15:09 +0200 (CEST) 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 for ; Tue, 31 May 2016 18:15:09 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 478B0677A53; Tue, 31 May 2016 12:15:08 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 478B0677A53 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2A1F3406538D for ; Tue, 31 May 2016 12:15:08 -0400 (EDT) Date: Tue, 31 May 2016 12:15:07 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" Message-ID: User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [IPsec] how common is ESP TFC support (and signaling of non-support) ? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 16:15:18 -0000 Hi vendors, I am wondering how common it is for stacks to support ESP TFC ? And also, how common it is for stacks that do NOT support ESP TFC, to properly signal that with ESP_TFC_PADDING_NOT_SUPPORTED. That is, has anyone ever encountered an interop problem when enabling ESP TFC? I would be interested in hearing from vendors (offlist or onlist) Paul From nobody Tue May 31 09:25:22 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E64F12D61E for ; Tue, 31 May 2016 09:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srHj9O0Pbb2I for ; Tue, 31 May 2016 09:25:15 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0097.outbound.protection.outlook.com [23.103.201.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C22CC12B053 for ; Tue, 31 May 2016 09:25:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dCfVu/V8XvQlBNJkMgM+xJd3Ab+3E4sR2qaLrOD5Qjo=; b=Styb7rzkz2OFcVkAhwHdTspYbgHjnDJujBki3R+XY0WAQ1cy0n3K+NxZlYd//TWKqtPWWzzHVUtebd7YvdnjRdLHnxy1wL5dKRDR4hhS3i2elOK/LeqCZXea1guOZiaw9oHfGM4Y6Qw1tBOjFUrGpLHf1eCN7+mXU27re+c0QjE= Received: from DM2PR09MB0365.namprd09.prod.outlook.com (10.160.247.18) by DM2PR09MB0366.namprd09.prod.outlook.com (10.160.247.20) with Microsoft SMTP Server (TLS) id 15.1.506.9; Tue, 31 May 2016 16:25:14 +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.0506.011; Tue, 31 May 2016 16:25:14 +0000 From: "Waltermire, David A. (Fed)" To: Valery Smyslov , Yoav Nir Thread-Topic: [IPsec] Status of draft-ietf-ipsecme-ddos-protection Thread-Index: AQHRt1BIyy9sw/ZlnEW3eEL+ii3MLp/RvvOAgADFfk+AAAu7gIAABfblgACqtnA= Date: Tue, 31 May 2016 16:25:13 +0000 Message-ID: References: <860C938B60E24C76A1749A1563D53A55@buildpc> <6ECFA010-549C-45DF-9D88-3D916D706A0D@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.224.58] x-ms-office365-filtering-correlation-id: 5525028f-862b-4c72-24a6-08d389702528 x-microsoft-exchange-diagnostics: 1; DM2PR09MB0366; 5:YTle4Mjr62HWitd4NGoPVuM95T+db2mw1bamxPMlvQEXsw13qSDq+1yFod/e/S4O6/eT/3KKZgG90i5BzGyhNNw8jShL7aoIPBaV+V0UT1I9D7+vlcYFU/GH+cV8gzO4CINU7FHRQaIDKdtO0xUTJg==; 24:Po1YtBa2J3tpVEMbX3kCF4ZVptwfhI0UCDmSvZvS1zDfvydyFeimYNblohcohKs8AsN/A/Q2w8Vj/AWOoahIyAtiTae5eY7x91T3kXnYcJ8=; 7:QGsrJNLriMkIbvKT4MEBk36Cy/RkydTk0Vk05t7aBifZeq1w2TPizrAZFNQA16af/r7YYqP4Ga3G11jDI5Xg2Aw8dpZEo1J7mG6dgpaaiiI5BShT+XcnmNUhc3mpSK7RcptrNNBureDpkKgEGSCds3iEeULHS7kx9yuwIpEi9orrZKz3nu1+Y2ipoc08Eu7M x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0366; x-ld-processed: 2ab5d82f-d8fa-4797-a93e-054655c61dec,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:DM2PR09MB0366; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0366; x-forefront-prvs: 095972DF2F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(77096005)(15975445007)(81166006)(66066001)(3660700001)(50986999)(3280700002)(76176999)(99286002)(2950100001)(8676002)(106116001)(8936002)(10400500002)(54356999)(2900100001)(19580395003)(19580405001)(5004730100002)(92566002)(33656002)(122556002)(9686002)(6116002)(586003)(102836003)(87936001)(3846002)(74316001)(189998001)(2906002)(5002640100001)(86362001)(11100500001)(5001770100001)(230783001)(76576001)(5003600100002)(93886004)(4326007)(5008740100001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0366; H:DM2PR09MB0365.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 31 May 2016 16:25:13.7570 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0366 Archived-At: Cc: "ipsec@ietf.org" , "paul@nohats.ca" Subject: Re: [IPsec] Status of draft-ietf-ipsecme-ddos-protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 16:25:20 -0000 RnJvbSB3aGF0IEkgYW0gcmVhZGluZywgdGhlcmUgaXNuJ3QgYW4gaW50ZXJlc3QgaW4gc3BsaXR0 aW5nIHB1enpsZXMgb3V0IGFzIGV4cGVyaW1lbnRhbC4gSWYgeW91IGZlZWwgc3Ryb25nbHkgdGhh dCBwdXp6bGVzIHNob3VsZCBiZSBzcGxpdCBvdXQgaW50byBhIHNlcGFyYXRlIGV4cGVyaW1lbnRh bCBkcmFmdCwgcGxlYXNlIHNwZWFrIHVwLiBJZiB3ZSBkb24ndCBoZWFyIGFueXRoaW5nIGJ5IE1v bmRheSwgSnVuZSA2LCB3ZSB3aWxsIGJlZ2luIG1ha2luZyBwcmVwYXJhdGlvbnMgdG8gc2VuZCB0 aGUgZHJhZnQgYXMtaXMgdG8gdGhlIElFU0cuDQoNClNpbmNlIHdlIGFyZSB3cmFwcGluZyB1cCB0 aGUgV0dMQywgcGxlYXNlIGFsc28gY29uc2lkZXIgdGhpcyBhIGZpbmFsIGNhbGwgZm9yIGNvbW1l bnRzIG9uIHRoZSBkcmFmdCBiZWZvcmUgd2Ugc2VuZCBpdCBvZmYuDQoNClRoYW5rcywNCkRhdmUN Cg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBJUHNlYyBbbWFpbHRvOmlw c2VjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBWYWxlcnkgU215c2xvdg0KPiBTZW50 OiBUdWVzZGF5LCBNYXkgMzEsIDIwMTYgMjowNSBBTQ0KPiBUbzogWW9hdiBOaXIgPHluaXIuaWV0 ZkBnbWFpbC5jb20+DQo+IENjOiBpcHNlY0BpZXRmLm9yZzsgcGF1bEBub2hhdHMuY2ENCj4gU3Vi amVjdDogUmU6IFtJUHNlY10gU3RhdHVzIG9mIGRyYWZ0LWlldGYtaXBzZWNtZS1kZG9zLXByb3Rl Y3Rpb24NCj4gDQo+ID4+IFRoZSBjb25jZXJuIGlzIG5vdCBhYm91dCBzdGFuZC1hbG9uZSBwdXp6 bGVzIGRvY3VtZW50LiBJdCBpcyBhYm91dCBhbg0KPiA+PiBFeHBlcmltZW50YWwgc3RhdHVzIG9m IHRoYXQgZG9jdW1lbnQgdmVyc3VzIFN0YW5kYXJkcyBUcmFjayBpbiB0aGUNCj4gY3VycmVudCBk cmFmdC4gVmVuZG9ycyB0ZW5kIHRvIGlnbm9yZSBFeHBlcmltZW50YWwgUkZDcy4NCj4gPg0KPiA+ IFRoZSBjb252ZW50aW9uYWwgd2lzZG9tIGlzIHRoYXQgdmVuZG9ycyB0ZW5kIHRvIGlnbm9yZSB3 aGF0ZXZlciBzdGF0dXMNCj4gPiB0aGUgSUVURiBhc3NpZ25zIHRvIGRvY3VtZW50cyBhbmQgaW1w bGVtZW50IHdoYXRldmVyIG1lZXRzIHRoZWlyIGdvYWxzLg0KPiANCj4gVGhhdCdzIHRydWUgaW4g Z2VuZXJhbC4gSG93ZXZlciBFeHBlcmltYWVudGFsIHN0YXR1cyBtYWtlcyB2ZW5kb3JzIG1vcmUN Cj4gc3VzcGljaW91cyB0aGF0IHRoZXkgd2lsbCBzcGVuZCByZXNvdXJjZXMgaW1wbGVtZW50aW5n IHRoZSBwcm90b2NvbCBhbmQgZ2Fpbg0KPiBsaXR0bGUsIGJlY2F1c2UgbW9zdCBvdGhlciB2ZW5k b3JzIHdpbGwgcmVmcmFuZSBmcm9tIGltcGxlbWVudGluZyBpdC4gRm9yDQo+IHB1enpsZXMgdG8g d29yayB0aGV5IG11c3QgYmVjb21lIHViaXF1aXRvdXMuDQo+IA0KPiA+IE15IHByZWZlcmVuY2Ug aXMgdG8ga2VlcCBpdCBhbGwgaW4gb25lIGRvY3VtZW50LCBhbmQgY2xlYXJseSBzdGF0ZQ0KPiA+ IHRoYXQgdGhlIHB1enpsZSBwYXJ0IG9mIHRoZSBkb2N1bWVudCBpcyBPUFRJT05BTCwgbWVhbmlu ZyB0aGF0IHlvdSBjYW4NCj4gY29tcGx5IHdpdGggdGhlIFJGQyBldmVuIHdpdGhvdXQgaW1wbGVt ZW50aW5nIGl0Lg0KPiANCj4gVGhhdCdzIG15IHByZWZlcmVuY2UgdG9vLiBJbiBmYWN0LCB0aGUg Y3VycmVudCBkcmFmdCBkb2Vzbid0IG1hbmRhdGUgdG8NCj4gaW1wbGVtZW50IChvciBldmVuIHRv IHVzZSkgcHV6emxlcywgc28gdGhleSBhcmUgYWxyZWFkeSBvcHRpb25hbC4NCj4gDQo+ID4gVGhl cmUgaXMgYSBjb25jZXJuIGFib3V0IGFuIEluaXRpYXRvciB0aGF0IGRvZXMgbm90IGltcGxlbWVu dCBwdXp6bGVzDQo+IGNvbm5lY3RpbmcgdG8gYSBSZXNwb25kZXIgdGhhdCBkb2VzLg0KPiA+IFRo aW5ncyB3aWxsIHdvcmsgZmluZSB1bnRpbCB0aGVyZSBpcyBhIERvUyBhdHRhY2sgYW5kIHRoZW4g d2XigJlyZQ0KPiA+IGhlbHBpbmcgdGhlIGF0dGFja2VyIGJ5IGRlbnlpbmcgc2VydmljZSB0byB0 aGUgbm9uLWltcGxlbWVudGluZw0KPiA+IEluaXRpYXRvci4gQW5kIHRoYXQgY291bGQgaGFwcGVu IGJldHdlZW4gYW4gSW5pdGlhdG9yIGFuZCBSZXNwb25kZXIsDQo+ID4gYm90aCBvZiB3aG9tIGNh biBjbGFpbSBjb21wbGlhbmNlIHdpdGggdGhlIGRvY3VtZW50LiBUaGlzIGlzbuKAmXQgZ3JlYXQs DQo+IGJ1dCBzZXBhcmF0aW5nIHRoZW0gaW50byB0d28gZG9jdW1lbnRzIGRvZXMgbm90IG1ha2Ug dGhlIHByb2JsZW0gZ28NCj4gYXdheS4NCj4gDQo+IFRoYXQncyB0cnVlLg0KPiANCj4gPiBZb2F2 DQo+IA0KPiBSZWdhcmRzLA0KPiBWYWxlcnkuDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJUHNlYyBtYWlsaW5nIGxpc3QNCj4gSVBzZWNA aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHNlYw0K From nobody Tue May 31 13:36:06 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51B2F12D640 for ; Tue, 31 May 2016 13:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKWOHG7Akt6Q for ; Tue, 31 May 2016 13:36:02 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CB0212D8C9 for ; Tue, 31 May 2016 13:35:58 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3rK4y13f2wz4K8; Tue, 31 May 2016 22:35:53 +0200 (CEST) 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 G-LkVU9JXAVN; Tue, 31 May 2016 22:35:52 +0200 (CEST) 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, 31 May 2016 22:35:52 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id DFA51677A53; Tue, 31 May 2016 16:35:48 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca DFA51677A53 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id CFF2C4066B3C; Tue, 31 May 2016 16:35:48 -0400 (EDT) Date: Tue, 31 May 2016 16:35:48 -0400 (EDT) From: Paul Wouters To: "Waltermire, David A. (Fed)" In-Reply-To: Message-ID: References: <860C938B60E24C76A1749A1563D53A55@buildpc> <6ECFA010-549C-45DF-9D88-3D916D706A0D@gmail.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: "ipsec@ietf.org" , Valery Smyslov , Yoav Nir Subject: Re: [IPsec] Status of draft-ietf-ipsecme-ddos-protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 20:36:04 -0000 On Tue, 31 May 2016, Waltermire, David A. (Fed) wrote: > From what I am reading, there isn't an interest in splitting puzzles out as experimental. If you feel strongly that puzzles should be split out into a separate experimental draft, please speak up. If we don't hear anything by Monday, June 6, we will begin making preparations to send the draft as-is to the IESG. I still prefer the puzzles going into a seperate document, so we as an implementor could say we implement the anti-ddos RFC without having to explain we implement some parts and not other parts. I don't think this matters much for the structure of the document, as it just puts Section 7 to 11 in a separate document. > Since we are wrapping up the WGLC, please also consider this a final call for comments on the draft before we send it off. Responding to this in a separate email. Paul From nobody Tue May 31 13:44:24 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45AAF12D8D6 for ; Tue, 31 May 2016 13:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpO1yfbbArww for ; Tue, 31 May 2016 13:44:20 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2BDF12D8D8 for ; Tue, 31 May 2016 13:44:20 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3rK57l2VLDz4K8 for ; Tue, 31 May 2016 22:44:19 +0200 (CEST) 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 3YPobIKcqGM9 for ; Tue, 31 May 2016 22:44:17 +0200 (CEST) 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 for ; Tue, 31 May 2016 22:44:17 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 4535C677A53; Tue, 31 May 2016 16:44:16 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 4535C677A53 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 336D44066B3C for ; Tue, 31 May 2016 16:44:16 -0400 (EDT) Date: Tue, 31 May 2016 16:44:16 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" Message-ID: User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [IPsec] Review of draft-ietf-ipsecme-ddos-protection-06 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 20:44:23 -0000 This is a partial review of draft-ietf-ipsecme-ddos-protection-06 up to Section 6. I hope to complete the rest in the next few days. I think this document needs another revision before continuing. (and I would prefer it to be split in two) Issues / Questions: An obvious defense, which is described in Section 4.2, is limiting the number of half-open SAs opened by a single peer. However, since all that is required is a single packet, an attacker can use multiple spoofed source IP addresses. I am not sure why this is mentioned here in this way, because the attack of spoofed source IP is already handled effectively with DOS cookies. I think it is better to state "bot-nets are large enough that they have enough unique IP addresses" and avoid talking about spoofing in this section altogether. Stage #3 includes public key operations, typically more than one. It seems this sentence needs to say something that these operations are very expensive, similar to describing the "effort" in the previous sentences of stage #1 and stage #2. It seems that the first thing cannot be dealt with at the IKE level. It's probably better left to Intrusion Prevention System (IPS) technology. I would rewrite this more authoritively, and not use the word "seems" Depending on the Responder implementation, this can be repeated with the same half-open SA. I don't think this "depends on the implemention". Since any on-path attacker can spoof rubbish, a Responder MUST ignore the failed packet and remain ready to accept the real one for a certain about of time. And this also applies to this later section in the document: If the received IKE_AUTH message failed to decrypt correctly (or failed to pass ICV check), then the Responder SHOULD still keep the computed SK_* keys, so that if it happened to be an attack, then the malicious Initiator cannot get advantage of repeating the attack multiple times on a single IKE SA. Retransmission policies in practice wait at least one or two seconds before retransmitting for the first time. I'm not sure if this is still true. Libreswan starts at 0.5s and doubles, and I know that iOS was faster too. When not under attack, the half-open SA timeout SHOULD be set high enough that the Initiator will have enough time to send multiple retransmissions, minimizing the chance of transient network congestion causing IKE failure. I agree, but I'd like to note that this and the text just above mentioning "several minutes" is kind of archaic. We found a limit of 30 seconds on other implementations so common as a timeout, that we see no more value in keeping an IKE exchange around for more then 30 seconds. (we do re-start and try a new exchange from scratch for longer, in some configurations we try that forever) For IPv6, ISPs assign between a /48 and a /64, so it makes sense to use a 64-bit prefix as the basis for rate limiting in IPv6. Why does that make sense over using /48 ? Wouldn't you rather rate limit some innocent neighbours over not actually defending against the attack? If puzzles work as advertised, real clients on that /48 should still be able to connect. Regardless of the type of rate-limiting used, there is a huge advantage in blocking the DoS attack using rate-limiting for legitimate clients that are away from the attacking nodes. In such cases, adverse impacts caused by the attack or by the measures used to counteract the attack can be avoided. I don't understand this paragraph at all. I guess "rate-limiting for legitimate clients" just confuses me. I think it might attempt to be saying "not blocking ranges with no attackers helps real clients", but it is very unclear. to calculate the PRF One does not "calculate" a PRF. One uses a PRF to calculate something. The section that starts with "Upon receiving this challenge," seems to be discussing the pros and conns of this method before it has explained the method. The reader is forced to skip this or forward to section 7 and getting back to this part. I suggest to re-order some text to avoid this, or to give a better short summary of the puzzle nature just before this paragraph. When the Responder is under attack, it MAY choose to prefer previously authenticated peers who present a Session Resumption ticket (see [RFC5723] for details). Why is this only a MAY? Why is it not a SHOULD or MUST? The Responder MAY require such Initiators to pass a return routability check by including the COOKIE notification in the IKE_SESSION_RESUME response message, as allowed by Section 4.3.2. of [RFC5723]. Perhaps this should say the responder SHOULD require COOKIEs for resumed sessions if it also requires COOKIEs for IKE_INIT requests. That is, it should not give preference to resumed sessions as those could be equally forged as IKE_INIT requests. With a typical setup and typical Child SA lifetimes, there are typically no more than a few such exchanges, often less. (ignoring the language) I do not believe this is true. This goes back to the discussion on how often people deploy liveness probes. Implementors seem to think 30s, while endusers want and do configure things like 1s. I don't think the text about the amount of IKE exchanges are typical are needed because the text below talks about specific abuse anyway, and not in terms of just number of exchanges. If the peer creates too many Child SA with the same or overlapping Traffic Selectors, implementations can respond with the NO_ADDITIONAL_SAS notification. I think this requires normative language, eg: implementations MUST respond with a NO_ADDITIONAL_SAS notification. The same for the next bullet item where it says "implementations can introduce an artificial delay", which should be like: "MAY introduce an artificial delay" (or even SHOULD, or rewrite "too many" to "many" and use MAY) Section 5 switchs from talking about "the Responder" to "the implementation". I think it should be "the Responder" throughout the document. the retransmitted messages should be silently discarded. That should be normative too, MUST be discarded. NITS: always bounded -> always bound "effectively defend" -> defend (if it was "effective", we wouldn't need puzzles :) thwart -> prevent or handle or counter? (thwart is just an odd/uncommon word for non-native englush speakers) The following sentence kind of runs on: Generating the IKE_SA_INIT request is cheap, and sending multiple such requests can either cause the Responder to allocate too much resources and fail, or else if resource allocation is somehow throttled, legitimate Initiators would also be prevented from setting up IKE SAs. How about: Generating the IKE_SA_INIT request is cheap. Sending large amounts of IKE_SA_INIT requests can cause a Responder to use up all its resources. If the Responder tries to defend against this by throttling new requests, this will also prevent legitimate Initiators from setting up IKE SAs. Next, Yes, there's a stage 4 where the Responder actually creates Child SAs, but when talking about (D)DoS, we never get to this stage. This is rather strange language for an RFC, how about: The fourth stage where the Responder creates the Child SA is not reached by attackers who cannot pass the authentication step. so it's -> so it is attempt to either exhaust -> attempt either to exhaust This should be easy because -> this is easy because even without changes to the protocol -> without changes to the protocol Puzzles, introduced in Section 4.4, do the same thing only more of it -> Puzzles, introduced in Section 4.4, accomplish this goal and more. They don't have to be so hard -> Puzzles do not have to be so hard can't -> cannot it's -> it is they increase the cost of a half-open SAs for the attacker so that it can create only a few. -> puzzles increase the cost of creating half-open SAs so the attacker is limited in the amount they can create. Reducing the amount of time an abandoned half-open SA is kept attacks the issue from the other side. It reduces the value the attacker gets from managing to create a half-open SA. -> Reducing the lifetime of an abandoned half-open SA also reduces the impact of such attacks. (I don't much like using comma's for numbers, as it means different things in different parts of the worlds. eg 60,000 and 1,000 in this document) Reduce the retention time to 3 seconds, and the attacker needs to create 20,000 half-open SAs per second. -> If the retention time is reduced to 3 seconds, the attacker would need to create 20,000 half-open SAs per second to get the same result. making it more likely to thwart an exhaustion attack against Responder memory -> making it more likely that the attacks run out of memory before the Responder. The attacker has two ways to do better -> The attacker has two alternative attacks to do better It seems that the first thing -> It seems that the first alternative On the other hand, sending an IKE_AUTH request is surprisingly cheap. -> On the other hand, the second alternative of sending an IKE_AUTH request is very cheap. It requires a proper IKE header with the correct IKE SPIs, and it requires a single Encrypted payload. The content of the payload might as well be junk. -> It requires generating a roper IKE header with correct IKE SPIs and a single Encrypted payload. The content of the Encrypted payload is irrelevant and therefore cheap to generate. does not check -> fails the integrity check. Puzzles can make attacks of such sort -> Puzzles make attacks of such sort Puzzles have their place as part of #4 -> Puzzles are used as a solution for strategy #4. Defense Measures while IKE SA is being created -> Defense Measures while the IKE SA is being created any IKE_SA_INIT request will require solving a puzzle. -> any IKE_SA_INIT request will be required to solve a puzzle. The downside -> The disadvantage (the other case does use advantage/disadvantage properly, so this is the odd one out) can still effectively DoS the Responder -> can still effectively DDoS the Responder. (there are some more DoS -> DDoS changes that you could make) to mitigate DoS attack -> to mitigate DoS attacks the cookie mechanism from -> the cookie mechanism of It is loosely based on the proof-of-work technique used in Bitcoins [bitcoins]. I think refering to bitcoins is a bit of a stretch and only distracts. This sets an upper bound, determined by the attacker's CPU, to the number of negotiations it can initiate in a unit of time. -> Puzzles set an upper bound, determined by the attacker's CPU, to the number of negotiations the attacker can initiate in a unit of time. -> for it to make any difference in mitigating DDoS attacks. -> [remove] and this fact allows -> and this allows a malicious peer -> an attacker (we used attacker all the way up to here in this document, why change it now?) Preventing Attacks using "Hash and URL" Certificate Encoding -> Preventing "Hash and URL" Certificate Encoding attacks In IKEv2 each side may use "Hash and URL" Certificate Encoding -> In IKEv2 each side may use the "Hash and URL" Certificate Encoding a DoS attack on responder -> a DoS attack on the responder before continue downloading. -> before continuing to download the file. See Section 5 of [RFC7383] for details. -> See Section 5 of [RFC7383] for details on how to mitigate these attacks. Defense Measures after IKE SA is created -> Defense Measures after an IKE SA is created Once IKE SA is created -> Once an IKE SA is created there is usually not much traffic over it -> there usually are only a limited amount of IKE messages exchanged. In most cases this traffic consists of exchanges aimed to create additional Child SAs, rekey, or delete them and check the liveness of the peer. -> This IKE traffic consists of exchanges aimed to create additional Child SAs, IKE rekeys, IKE deletions and IKE liveness tests. Such behavior may be caused by buggy implementation, misconfiguration or be intentional. The latter becomes more of a real threat if the peer uses NULL Authentication, described in [RFC7619]. In this case the peer remains anonymous, allowing it to escape any responsibility for its actions. -> Such behavior can be caused by broken implementations, misconfiguration or as an intended attack. Extra case should be taken in the case of NULL Authentication [RFC7619] where one essentially allows IKE SAs with untrusted third parties that could be malicious. See Section 3 of [RFC7619] for details -> See Section 3 of [RFC7619] for details on how to mitigate attacks when using NULL Authentication. The following recommendations for defense against possible DoS attacks after IKE SA is established are mostly intended for implementations that allow unauthenticated IKE sessions; however, they may also be useful in other cases. -> The following recommendations apply especially for NULL Authenticated IKE sessions, but also apply to authenticated IKE sessions, with the difference that in the latter case, the identified peer can be locked out. then the peer could initiate multiple simultaneous -> peers are able to initiate multiple simultaneous that could increase host resource consumption -> that increases host resource consumption Since currently there is no way -> Since there is no way decrease window size once it was increased -> decrease the window size once it has been increased For that reason, it is NOT RECOMMENDED to ever increase the IKEv2 window size above its default value of one if the peer uses NULL Authentication.-> It is NOT RECOMMENDED to allow an IKEv2 window size greater than one when NULL Authentication has been used. If the peer initiates requests to rekey IKE SA or Child SA too often, implementations can respond to some of these requests with the TEMPORARY_FAILURE notification, indicating that the request should be retried after some period of time. -> If a peer initiates an abusive amount of CREATE_CHILD exchanges, the Responder SHOULD reply with TEMPORARY_FAILURE notifications indicating the peer must slow down their requests. If the peer initiates too many exchanges of any kind, implementations can introduce an artificial delay before responding to each request message.-> If a peer initiates many exchanges of any kind, the Responder MAY introduce an artificial delay before responding to the request. "the implementation need" -> the Responder needs making it possible to process requests from the others -> and frees up resources on the Responder that can be used for answering legitimate clients. Note, that if the Responder receives retransmissions -> If the Responder receives retransmissions the retransmitted messages should be silently discarded. -> the retransmitted messages MUST be discarded. The delay should not be too long to avoid causing the IKE SA to be deleted on the other end due to timeout. -> The delay must be short enough to avoid legitimate peers deleting the IKE SA due to a timeout. [ to be continued ] From nobody Tue May 31 18:09:01 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE6F412D94C for ; Tue, 31 May 2016 18:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.728 X-Spam-Level: X-Spam-Status: No, score=-5.728 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, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFE7X3dy8gjs for ; Tue, 31 May 2016 18:08:58 -0700 (PDT) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CACD12D62E for ; Tue, 31 May 2016 18:08:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1464743338; x=2328656938; 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=uY38QFcFNNYUHHUjxRQiFWsF6v5+LUF85lzH/tnNnw8=; b=YHPT5TqipIdgiBt677EfUGbPIFnjcaantJl6ukfUPny4xptru49QPnsoQl68Dcb7 BfEwYtAnPgPKG053YCm8EIvWCF85ml1NowIAqcn+SAF0yuNSsXAUXCt2L9eeMdgk q7bOSbINVA+N0udPGvKHYomG+d0f3+fPXabrvGONqH2Dimu001h62ajTNMVTLhv/ u0of6jeYaVxb8W9InHdHHHS+DTf9ru2qWbHDXl1EnF5Yvtwy6e7tou615yMA8sYh QYErlNnK0LNKh4Wk4b3D6jLLNj/nWmPmTqujqVDtHhmwP4Xr9UcohgcwoSt3Socb ojy9oszDNl3mdoApw4Tx/w==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 6C.9C.06427.AA53E475; Tue, 31 May 2016 18:08:58 -0700 (PDT) X-AuditID: 11973e11-f79646d00000191b-ef-574e35aabcb6 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay2.apple.com (Apple SCV relay) with SMTP id BB.8A.11233.9A53E475; Tue, 31 May 2016 18:08:57 -0700 (PDT) Received: from [17.114.154.71] (unknown [17.114.154.71]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0O82002ZPJ6XLJ80@nwk-mmpp-sz12.apple.com> for ipsec@ietf.org; Tue, 31 May 2016 18:08:57 -0700 (PDT) Sender: tpauly@apple.com Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 10.0 \(3186\)) From: Tommy Pauly In-reply-to: Date: Tue, 31 May 2016 18:08:57 -0700 Content-transfer-encoding: quoted-printable Message-id: References: To: Paul Wouters X-Mailer: Apple Mail (2.3186) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUi2FDorLvK1C/cYPs0bov9W16wOTB6LFny kymAMYrLJiU1J7MstUjfLoErY97/ooJtbBV/J81hb2CczNrFyMkhIWAi8eb+UUYIW0ziwr31 bF2MXBxCAnsZJV7f/8MMUzR19SVGiMRyJolt1w4xQTjzmCT+XT8BVMXBISwgIbF5TyJIA7OA lsT6nceZQGxeAX2J+XP/gw0SFgiVaJt2mh3EZhNQkTj+bQNYnFPAUeLH0Z1gcRYBVYnJy24w QczRkLj45CQ7hK0t8eTdBVaImTYS07ougsWFBBwkPr3YDfaBiICixKQzj1hAzpEQkJW4slgC 5EwJgRVsEl/Of2aawCgyC8l5s5CcNwvJigWMzKsYhXITM3N0M/OM9BILCnJS9ZLzczcxgoJ7 up3gDsbjq6wOMQpwMCrx8FZc9g0XYk0sK67MPcQozcGiJM6bzeoXLiSQnliSmp2aWpBaFF9U mpNafIiRiYNTqoFRKlRMYu0/s/pAg6ai77++OB1tmHDX+huH7L/tds8vLp132fNC46YjzuHV GTNsfnQeKH8fuLDXi/lnn+S1pnPbixZFL3e0uVoZk3csIaqjoTVyWmZrKMvMWxON6rWCOcPS 8q+VbGvTeJVwR1P9yjTe0t8miYv+PzXeejL5cMMh75bI8C0fUpcqsRRnJBpqMRcVJwIA7pZH wE8CAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUi2FB8RneVqV+4wb8+Vov9W16wOTB6LFny kymAMYrLJiU1J7MstUjfLoErY97/ooJtbBV/J81hb2CczNrFyMkhIWAiMXX1JUYIW0ziwr31 bF2MXBxCAsuZJLZdO8QE4cxjkvh3/QRzFyMHh7CAhMTmPYkgDcwCWhLrdx5nArF5BfQl5s/9 zwxiCwuESrRNO80OYrMJqEgc/7YBLM4p4Cjx4+hOsDiLgKrE5GU3mCDmaEhcfHKSHcLWlnjy 7gIrxEwbiWldF8HiQgIOEp9e7AY7VERAUWLSmUcsIOdICMhKXFksMYFRcBaSi2YhuWgWkqkL GJlXMQoUpeYkVhrpJRYU5KTqJefnbmIEB2Oh8w7GY8usDjEKcDAq8fBWXPYNF2JNLCuuzD3E KMHBrCTC+8bEL1yINyWxsiq1KD++qDQntfgQYzLQLxOZpUST84GRklcSb2hiYmBibGxmbGxu Yk6asJI4r3ONR7iQQHpiSWp2ampBahHMFiYOTqkGxqI4g0drNydunLRj8dlw45aXJ5+fWiEv UsZda+/25uXnuGXTVDg3vVZ7xCMYE7ohr5h5yg8nIZv9WY47k+bbzHsvZRq7XGaWQoTQxZtr W37Gf/racXS+pdKzk2J837aUzcua9tjsUPvjkiixpfOCb9/haIssvt18z/Ln9vRVudOvvk++ bfPt0HwlluKMREMt5qLiRACd4Dt7igIAAA== Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] how common is ESP TFC support (and signaling of non-support) ? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 01:09:00 -0000 iOS and Mac OS X do not support ESP TFC, and mark = ESP_TFC_PADDING_NOT_SUPPORTED in the IKE_AUTH packets. I have not heard = of problems with interop in this area. Thanks, Tommy > On May 31, 2016, at 9:15 AM, Paul Wouters wrote: >=20 >=20 > Hi vendors, >=20 > I am wondering how common it is for stacks to support ESP TFC ? >=20 > And also, how common it is for stacks that do NOT support ESP TFC, to > properly signal that with ESP_TFC_PADDING_NOT_SUPPORTED. >=20 > That is, has anyone ever encountered an interop problem when enabling > ESP TFC? >=20 > I would be interested in hearing from vendors (offlist or onlist) >=20 > Paul >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue May 31 19:28:43 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D6B12D09C for ; Tue, 31 May 2016 19:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9Sff0fUyMWh for ; Tue, 31 May 2016 19:28:40 -0700 (PDT) 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 0EBE312B051 for ; Tue, 31 May 2016 19:28:40 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3rKDmw2lQ6z33H; Wed, 1 Jun 2016 04:28:32 +0200 (CEST) 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 vG0bS4Z9zbfq; Wed, 1 Jun 2016 04:28:29 +0200 (CEST) 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; Wed, 1 Jun 2016 04:28:29 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 6351C677A53; Tue, 31 May 2016 22:28:27 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 6351C677A53 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4C2E44073480; Tue, 31 May 2016 22:28:27 -0400 (EDT) Date: Tue, 31 May 2016 22:28:27 -0400 (EDT) From: Paul Wouters To: Tommy Pauly In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LRH 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] how common is ESP TFC support (and signaling of non-support) ? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 02:28:42 -0000 On Tue, 31 May 2016, Tommy Pauly wrote: > iOS and Mac OS X do not support ESP TFC, and mark ESP_TFC_PADDING_NOT_SUPPORTED in the IKE_AUTH packets. I have not heard of problems with interop in this area. So I just did an interop, enabled TFC and it worked great with iOS :) 22:10:29.449629 IP 193.110.157.103.ipsec-nat-t > 206.248.139.105.ipsec-nat-t: UDP-encap: ESP(spi=0x0ac48b5c,seq=0x33), length 1460 22:10:29.626665 IP 206.248.139.105.ipsec-nat-t > 193.110.157.103.ipsec-nat-t: UDP-encap: ESP(spi=0x7c5c55a3,seq=0x36), length 132 22:10:30.450711 IP 193.110.157.103.ipsec-nat-t > 206.248.139.105.ipsec-nat-t: UDP-encap: ESP(spi=0x0ac48b5c,seq=0x34), length 1460 22:10:30.627503 IP 206.248.139.105.ipsec-nat-t > 193.110.157.103.ipsec-nat-t: UDP-encap: ESP(spi=0x7c5c55a3,seq=0x37), length 132 This is a ping and you can see the linux server sending pings padded to 1460 bytes and the iphone replying with 132 byte ESP packets. I guess the kernel is properly handling ESP decryption, grabbing the length field and decrypting the packet, and doesn't care about the extra bytes at the end. This was using IKEv1, which prevented me from seeing the notify payload for it not being supported. But I assume ESP is handled identically on iOS regardless of IKE version, so I think for IKEv2 you do not need to send ESP_TFC_PADDING_NOT_SUPPORTED, since you support it fine :) I noticed you said you send the notify in IKE_AUTH. In my code I had added it to IKE_INIT. Reading 7296 is a bit unclear on this, since it only mentions ESP_TFC_PADDING_NOT_SUPPORTED for the CREATE_CHILD exchange, and not the Initial Exchanges. Although it does become clear when you read the appendix examples where these appear in IKE_AUTH. It seems RFC 4718 had clarified this, but somehow we missed including that clarified text in either 5996 or 7296 :/ https://tools.ietf.org/html/rfc4718#section-4.5 And it makes sense since it is supposed to be a "per SA" option, even though I'd guess that support for it would depend on the OS/kernel so it seems a little odd to make it a per-SA option. I guess "supported" really means "desired". And iOS sending the notify might be because they prefer to do less traffic to save on battery and data usage even though they support it? So I'll update my code. Of course, I'm still curious about other vendors too. And still wondering if TFC should be enabled per default if not ESP_TFC_PADDING_NOT_SUPPORTED is received. Thanks, Paul