Re: [IPsec] Split DNS in IKEv2 Configuration Payload

On Jul 30, 2015, at 3:08 AM, Paul Wouters p...@nohats.ca wrote: On Thu, 30 Jul 2015, Tero Kivinen wrote: Paul Wouters writes: Should such a document include a section on client usage or just specify the payload formats? If such document is written, it has to defined client usage for

[IPsec] Split DNS in IKEv2 Configuration Payload

Hello, I’d like to see if the working group has interest in adding support for a list of split-DNS domains to the configuration payload for IKEv2. Existing split-tunnel VPN solutions often use a configuration in which only a private domain is resolved using the VPN’s DNS server, and all other

Re: [IPsec] Call for adoption: draft-nir-ipsecme-curve25519 as a WG work item

I think this would be a good feature for the WG to work on, and that this document provides a good start. Thanks, Tommy Pauly On Aug 24, 2015, at 3:58 PM, Paul Hoffman paul.hoff...@vpnc.org wrote: Greetings. There was some general interest in having a standard way to modern elliptic

[IPsec] Discussing TCP Encapsulation of IPSec in Yokohama

Hello all, We’ll be having an informal meeting here in Yokohama to discuss TCP encapsulation for IPSec/IKEv2 (draft-pauly-ipsecme-tcp-encaps-00) tomorrow, Thursday, Nov 5, at 12pm. Anyone who’s interested in joining to discuss, please meet at the registration desk at noon! Thanks, Tommy

[IPsec] IKEv2 in iOS 9 and OS X El Capitan

be attending the meeting in Prague. Best, Tommy Pauly Core OS Networking, Apple___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Fwd: New Version Notification for draft-pauly-ipsecme-tcp-encaps-00.txt

Hello, I’ve just posted a new draft to specify how to transport IKEv2 and IPSec packets over a TCP connection in networks that block UDP. All comments and feedback are welcome! Best, Tommy Pauly > Begin forwarded message: > > From: internet-dra...@ietf.org > Date: September 10

Re: [IPsec] WG Interest in TCP Encapsulation

on these documents, we may end up with diverging implementations, or implementations that are not compatible with MOBIKE, etc. We believe that a standard is needed to define how implementations should handle this. Thanks, Tommy > On Sep 15, 2015, at 7:01 PM, Tero Kivinen <kivi...@iki.fi> wrote: &

[IPsec] WG Interest in TCP Encapsulation

ection. For clients that rely heavily on IKEv2, such as phones that use IKEv2 to to route VoIP calls over Wi-Fi back to carrier networks, working in such networks in critical. Please respond with your comments! Thanks, Tommy Pauly Apple___ IPsec mailing list

Re: [IPsec] WG Interest in TCP Encapsulation

Hi Paul, I encourage you to read the new draft, as I believe it addresses many of your concerns. It covers the potential new vulnerabilities (RST), as well as how to frame the datagrams in a stream along with an explanation of performance concerns. It also makes it clear that TCP should only

Re: [IPsec] WG Interest in TCP Encapsulation

Hi Valery, As Samy mentioned, this draft does allow for the traffic to looks like HTTPS traffic (using TLS over port 443), but doesn’t require it. It is about defining a standard way to add framing to IKEv2 and ESP when put over a TCP-based stream; the applications of this may vary in

Re: [IPsec] Split DNS in IKEv2 Configuration Payload

of interest in this topic, and if people would like to work on adopting it. Thanks! Tommy === A new version of I-D, draft-pauly-ipsecme-split-dns-00.txt has been successfully submitted by Tommy Pauly and posted to the IETF repository. Name: draft-pauly-ipsecme-split

Re: [IPsec] New revision of TCP Encapsulation draft

ps://www.ietf.org/internet-drafts/draft-pauly-ipsecme-tcp-encaps-02.txt> >> >> Please check it out, and provide feedback. >> >> >> Thanks. >> Samy. >> >> >> From: Yaron Sheffer < <mailto:yaronf.i...@gmail.com>yaronf.i...@gmail.co

Re: [IPsec] TCP Encapsulation draft

> On Dec 14, 2015, at 6:46 AM, Valery Smyslov wrote: > > Hi, Hi Valery, Thanks for your comments! Responses inline. > > I have some comments on the TCP Encapsulation draft. > > 1. The draft assumes that using TCP encapsulation is always pre-configured, > i.e. for each

Re: [IPsec] RFC 4307bis

:20 AM, Paul Wouters <p...@nohats.ca > <mailto:p...@nohats.ca>> wrote: > On Fri, 20 Nov 2015, Tommy Pauly wrote: > > On a broader note, many of the SHOULD algorithms (ENCR_AES_CCM_8, > PRF_AES128_CBC, AUTH_AES-XCBC) are > justified as being present for the pur

Re: [IPsec] RFC 4307bis

Hello Daniel, One minor typo: "PRF_AES128_CBC has been downgraded from SHOULD in RFC4307” should be "PRF_AES128_CBC has been downgraded from SHOULD+ in RFC4307" On a broader note, many of the SHOULD algorithms (ENCR_AES_CCM_8, PRF_AES128_CBC, AUTH_AES-XCBC) are justified as being present for

Re: [IPsec] meeting at IETF-95 ?

+1 to having a meeting at IETF 95. Thanks, Tommy > On Jan 12, 2016, at 6:56 AM, Paul Wouters wrote: > > > I hope we are scheduling a meeting for IETF-95. Last time we did not > meet and ended up meeting in the hallway. This time there are more > drafts being suggested and

Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-ikev2-compression-00.txt

> On Jan 11, 2016, at 8:19 AM, Tero Kivinen wrote: > > Yoav Nir writes: >> Second, as I understand it, those battery-powered devices tend to >> use 802.15.4 networks with 127-byte frames. There’s 6LoWPAN to >> provide fragmentation support, but that’s similar to using IKE’s >>

Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt

Here are my thoughts on the options for communicating the Implicit IV option in the proposal: - A new transform type is problematic, as pointed out by Valery and Paul already, because it adds complexity to the proposal structure for configuring and parsing. This seems to be the least desirable

[IPsec] New version of IKEv2 TCP Encapsulation draft

Hello all, I’ve just posted a new version of the IKEv2 and IPSec TCP Encapsulation draft. The changes include: - Making the use case (as a last resort if UDP is blocked) more clear in the introduction - Clarify connection establishment and teardown section (allowing a resumed connection to

Re: [IPsec] New Version Notification for draft-tran-ipsecme-ikev2-yang-00.txt

I agree that time intervals for IKE retransmits should be measured in milliseconds, not seconds. Thanks, Tommy > On Mar 28, 2016, at 4:31 PM, Daniel Migault > wrote: > > With the second as a unit. We cannot do it. However if we set it millisecond > we are fine.

Re: [IPsec] New version of IKEv2 TCP Encapsulation draft

arified. This should refer to the TLS NULL cipher, not ESP. > > 8. The draft is silent about ESP Sequence Numbers. I think a few words could > be added that while the ESP SN are unnecessary with TCP encapsulation, > the sender still must increnet it in every sent pack

[IPsec] Next steps on TCP Encapsulation for IKEv2

Hello, At our meeting yesterday, we agreed that we want one more revision of draft-pauly-ipsecme-tcp-encaps-03 before putting it up for working group adoption to clear up a few concerns. Here are the changes we’re planning: 1. Reconcile the length field size with 3GPP’s recommendation (sent

Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-07.txt

This version looks good to me! Seems ready for WGLC. —Tommy > On Apr 7, 2016, at 5:37 PM, Paul Wouters wrote: > > On Thu, 7 Apr 2016, internet-dra...@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a

Re: [IPsec] Next steps on TCP Encapsulation for IKEv2

. I > think TCP encapsulation of IKEv2/IPsec should be easily distinguishable from > other types of traffic on the same port. > > I propose we add a magic value at the start of a non-TLS TCP stream, > something very different from (0x16, 0x03, 0x01, 0x00). > > Yoav &g

Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04

Hi Valery, Responses inline. Thanks! Tommy > On Mar 5, 2016, at 2:00 AM, Valery Smyslov wrote: > > Hi Tommy, > > thank you for your comments. > I tend to agree with Paul that I find it unlikely, from an implementor’s standpoint, that many Initiators will choose

Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04

> On Mar 5, 2016, at 5:11 AM, Valery Smyslov wrote: > >> If there is no consensus about puzzles, perhaps we should leave that >> part out of the document? > > I had an impression that threre was a consensus when > the document was adopted by WG. In any case, I think that it

Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04

> On Mar 4, 2016, at 9:32 AM, Yoav Nir <ynir.i...@gmail.com> wrote: > >> >> On 4 Mar 2016, at 7:02 PM, Tommy Pauly <tpa...@apple.com> wrote: >> >> Hello Dave, >> >> I tend to agree with Paul that I find it unlikely, from an implemen

Re: [IPsec] Proposed wording for a revised charter

I would also like to see the draft for TCP encapsulation added as an item, since we’ve gotten a fair amount of support for it. For the purposes of the charter, it may be good to have a broader explanation of the goal—something to the effect that the working group should focus on making sure

Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04

Hello Dave, I tend to agree with Paul that I find it unlikely, from an implementor’s standpoint, that many Initiators will choose to implement the puzzle logic, especially ones that are running on mobile devices. It is unlikely that the phones will be able to solve the puzzles quickly enough

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, > >

Re: [IPsec] New version of TCP Encapsulation draft, request for adoption

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

Re: [IPsec] Quantum Resistance Requirements

Hi Scott, Great list! Responses inline. Best, Tommy > On Aug 11, 2016, at 3:00 PM, Scott Fluhrer (sfluhrer) > wrote: > > In Berlin, we decided to take up Quantum Resistance as a work item, and that > we should start talking about requirements. I’m starting this thread

Re: [IPsec] New version of draft-ietf-ipsecme-rfc4307bis-10.txt

Yes, this looks good! I think both RFCs in the columns makes sense. I agree that this looks ready for WGLC. Tommy > On Jul 20, 2016, at 1:40 PM, Paul Wouters wrote: > > On Wed, 20 Jul 2016, Tero Kivinen wrote: > >> In the end I think the best option would be to just include

Re: [IPsec] New charter proposal

Looks good to me as well. Thanks! Tommy Sent from my iPhone > On Jul 20, 2016, at 2:52 PM, Paul Wouters wrote: > > > > Sent from my iPhone > >> On Jul 20, 2016, at 2:45 PM, Tero Kivinen wrote: >> >> As we discussed in the meeting yesterday, we need to

Re: [IPsec] New charter proposal

> On Jul 20, 2016, at 5:12 PM, Valery Smyslov wrote: > > Hi, >> - Add Quantum Resistance for IKEv2 as new work item with milestone as >> Feb 2017 for IETF LC. > > This milestone looks a bit optimistic for me. Otherwise the updated chapter > looks good. The issue seems

Re: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-00.txt

ons of > the IETF. > >Title : TCP Encapsulation of IKE and IPSec Packets > Authors : Tommy Pauly > Samy Touati > Ravi Mantha > Filename: draft-ietf-ipsecme-tcp-encaps-00.txt &g

Re: [IPsec] IETF 96 IPsecME Agenda

> On Jul 7, 2016, at 12:23 PM, Paul Wouters wrote: > > On Thu, 7 Jul 2016, Waltermire, David A. (Fed) wrote: > This leaves 25 minutes extra. Are there any additional topics to discuss? >>> ESP? Yang? Others? >> >> Are you or one of the other authors available to discuss

Re: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document

provides a good starting >point for a WG document to do that. I agree that we can defer some of the >complexities around ID hiding to later solutions, in the interest of >simplicity and providing basic QR in the short term. Thanks, Tommy Pauly Apple > On Jul 4, 2016, at 9:40 AM, Paul Wo

Re: [IPsec] review for draft-ietf-ipsecme-tcp-encaps-01

Hi Daniel, Thanks for the in-depth review! I've incorporated your comments into a new update: https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-02 . Specific responses to your comments inline! Any other comments are welcome

Re: [IPsec] Review of draft-ietf-ipsecme-tcp-encaps-05

Hi Valery, Thanks so much for your comments! I have posted a new version of the draft here: https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-06 Responses inline. Best, Tommy > On Feb 2, 2017, at 4:13 AM, Valery Smyslov wrote: > > Hi, > > here is my review of

Re: [IPsec] Review of draft-ietf-ipsecme-tcp-encaps-05

Hi Valery, Thanks for the feedback! I'll clarify that the TCP Originator is the same as the original initiator of the first IKE SA, as well as fixing the typographical errors. If anyone else has more feedback, please chime in! I'll wait a day or so before updating the draft, to batch any

[IPsec] New version: draft-ietf-ipsecme-tcp-encaps-05

apsulation of IKE and IPsec Packets > Authors : Tommy Pauly > Samy Touati > Ravi Mantha > Filename: draft-ietf-ipsecme-tcp-encaps-05.txt > Pages : 21 > Date: 2017-01-23 >

Re: [IPsec] Working group last call for the draft-nir-ipsecme-eddsa-00

Thanks for sending out the corrected draft name, Tero. I think this draft is in good shape in general and we should move forward with it. The only thing that seems to need ironing out is the specific IANA hash value. I can see the argument either way: as the draft points out, 0 makes sense for

Re: [IPsec] Review of draft-ietf-ipsecme-tcp-encaps-05

Hello, I've posted a new draft with a fix for the TCP Originator vs Original Initiator explanation, and a couple typos. https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-07 I believe this addresses all outstanding comments! Thanks, Tommy > On Feb 7, 2017, at 9:44 AM, Tommy Pauly &

Re: [IPsec] Review of the draft-ietf-ipsecme-tcp-encaps-04

> On Jan 19, 2017, at 11:47 PM, Valery Smyslov wrote: > > HI Tero, > >> Actually Valery did raise good point, that for IKE this might cause >> issues. >> >> Now when I am thinking about this, I think that for IKE packets the >> response to the IKE request should go to the

Re: [IPsec] Mirja Kühlewind's Block on charter-ietf-ipsecme-10-00: (with BLOCK)

Hi Kathleen, > On Aug 31, 2016, at 6:53 PM, Kathleen Moriarty > <kathleen.moriarty.i...@gmail.com> wrote: > > Tommy, > > On Wed, Aug 31, 2016 at 10:30 AM, Tommy Pauly <tpa...@apple.com > <mailto:tpa...@apple.com>> wrote: >> >>> O

Re: [IPsec] Spencer Dawkins' No Objection on charter-ietf-ipsecme-10-00: (with COMMENT)

> On Aug 31, 2016, at 3:23 AM, Tero Kivinen wrote: > > Kathleen Moriarty writes: "There have been middle boxes blocking IKE negotiation over UDP. To make IKE work in these environments, IKE packets need to be encapsulated in a TCP tunnel. >>> >>> >>> "In a TCP

Re: [IPsec] Mirja Kühlewind's Block on charter-ietf-ipsecme-10-00: (with BLOCK)

> On Aug 31, 2016, at 6:41 AM, Mirja Kuehlewind (IETF) > wrote: > > Hi all, > > thanks for providing the reference to the draft. That was very helpful and > confirmed my initial assumption that you don’t want to ‚change‘ TCP. So this > work seems to be fine in this

[IPsec] New Version of Split DNS for IKEv2

rovide your input! Thanks, Tommy > Begin forwarded message: > > From: internet-dra...@ietf.org > Subject: New Version Notification for draft-pauly-ipsecme-split-dns-02.txt > Date: September 21, 2016 at 1:27:23 PM PDT > To: Tommy Pauly <tpa...@apple.com>, Paul Wouters <p

Re: [IPsec] I-D Action: draft-ietf-ipsecme-eddsa-00.txt

Hi Yoav, Thanks for posting this. The draft looks good, and we're eager to see this move along! If you have an implementation already supporting this, I'd be interested in testing interop. I think the reservation of the 0 IANA hash value for the "Identity" hash makes sense; since it seems

[IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt

aft is a work item of the IP Security Maintenance and Extensions of > the IETF. > >Title : TCP Encapsulation of IKE and IPsec Packets > Authors : Tommy Pauly > Samy Touati > Ravi Mantha >

Re: [IPsec] New version of TCP Encapsulation draft, request for adoption

> one TCP session allowed for a given SA? > >> -Original Message- >> From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Hu, Jun (Nokia - US) >> Sent: Friday, October 07, 2016 2:09 PM >> To: Tommy Pauly; Valery Smyslov; Yoav Nir >> Cc: IPsecME WG; Da

Re: [IPsec] New Version Notification for draft-mglt-ipsecme-diet-esp-02.txt

Hi Daniel, Thanks for sending this out! Definitely very interesting stuff. I like the new focus on how to compress UDP/TCP within Diet-ESP. Some of the introduction text could use some clarification/wordsmithing: IPsec/ESP has not been designed to reduce the networking overhead of the

Re: [IPsec] New version of TCP Encapsulation draft, request for adoption

; > > -Original Message- > From: IPsec [mailto:ipsec-boun...@ietf.org <mailto:ipsec-boun...@ietf.org>] > On Behalf Of Hu, Jun (Nokia - US) > Sent: Friday, October 07, 2016 2:09 PM > To: Tommy Pauly; Valery Smyslov; Yoav Nir > Cc: IPsecME WG; Daniel Migault

Re: [IPsec] draft-ietf-ipsecme-tcp-encaps-04.txt

Thanks for confirming! I appreciate all of your help in cleaning this part up! Tommy > On Dec 7, 2016, at 11:52 AM, Hu, Jun (Nokia - US) <jun...@nokia.com> wrote: > > Looks good to me > >> -Original Message- >> From: IPsec [mailto:ipsec-boun...@ietf

Re: [IPsec] [sunset4] ietf-nat64 - Internet VPN clients

or relying on the OS to provide that? > > > > Original message > From: Tommy Pauly <tpa...@apple.com <mailto:tpa...@apple.com>> > Date: 09/12/2016 17:32 (GMT+00:00) > To: "Heatley, Nick" <nick.heat...@ee.co.uk <mailto:nick.heat

Re: [IPsec] New Version of Split DNS for IKEv2

], > such as "local", "localhost", "invalid", etc. with the INTERNAL_DNS_DOMAIN is > part of the initiator's policy. Unless the initiator explicitly wish to > support some Special Use Domain Names, it SHOULD ignore INTERNAL_DNS_DOMAIN > attribu

Re: [IPsec] [sunset4] ietf-nat64 - Internet VPN clients

a change that needs to be made on the client behind the NAT64, and requires no protocol changes in IKE or knowledge on the server side. Thanks, Tommy Pauly > On Dec 9, 2016, at 9:03 AM, Heatley, Nick <nick.heat...@ee.co.uk> wrote: > > It is just the single NAT64 that is in questi

Re: [IPsec] Review of the draft-ietf-ipsecme-tcp-encaps-04

Hi Tero, Thanks for the comments! Responses inline. Best, Tommy > On Jan 11, 2017, at 7:04 AM, Tero Kivinen wrote: > > This draft should be quite ready for the WGLC, so I will start that > shortly, but here are comments from my chair review of the draft. > > Consider these

[IPsec] draft-ietf-ipsecme-tcp-encaps-04.txt

gt; directories. > This draft is a work item of the IP Security Maintenance and Extensions of > the IETF. > >Title : TCP Encapsulation of IKE and IPsec Packets > Authors : Tommy Pauly > Samy Touati >

Re: [IPsec] Comments on draft-ietf-ipsecme-tcp-encaps

> On Mar 19, 2017, at 6:47 AM, Eric Rescorla wrote: > > > > On Sat, Mar 18, 2017 at 11:29 PM, Yoav Nir > wrote: > Hi, Eric. > >> On 19 Mar 2017, at 4:04, Eric Rescorla > > wrote: >> >>

Re: [IPsec] Comments on draft-ietf-ipsecme-tcp-encaps

CE :) > > -Ekr > > > On Sun, Mar 19, 2017 at 11:25 AM, Tommy Pauly <tpa...@apple.com> wrote: > >> >> On Mar 19, 2017, at 6:47 AM, Eric Rescorla <e...@rtfm.com> wrote: >> >> >> >> On Sat, Mar 18, 2017 at 11:29 PM, Yoav Nir &

Re: [IPsec] [Curdle] New Version Notification for draft-ietf-curdle-pkix-04.txt

I've gone through my review of the draft as well, and I think this version looks good! Thanks, Tommy > On Apr 3, 2017, at 11:25 AM, David Schinazi wrote: > > Thanks for the update! > > I've reviewed -04 and I think the draft is ready to move forward. > > Regards, >

Re: [IPsec] AD review of draft-ietf-ipsecme-tcp-encaps

Hi Kathleen, Yes, this is referring to how the existing NAT detection works in IKEv2: https://tools.ietf.org/html/rfc7296 Section 2.23. NAT Traversal o The data associated with the NAT_DETECTION_SOURCE_IP notification is a SHA-1 digest of the SPIs (in the order they appear in the

Re: [IPsec] AD review of draft-ietf-ipsecme-tcp-encaps

Mar 9, 2017, at 10:48 AM, Kathleen Moriarty > <kathleen.moriarty.i...@gmail.com> wrote: > > On Thu, Mar 9, 2017 at 12:47 PM, Tommy Pauly <tpa...@apple.com > <mailto:tpa...@apple.com>> wrote: >> Hi Kathleen, >> >> Yes, this is referring to how t

Re: [IPsec] Mirja Kühlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS)

> On Apr 25, 2017, at 5:48 AM, Mirja Kühlewind wrote: > > Mirja Kühlewind has entered the following ballot position for > draft-ietf-ipsecme-tcp-encaps-09: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the

Re: [IPsec] regarding draft-ietf-ipsecme-tcp-encaps

> On Apr 25, 2017, at 2:15 PM, Joe Touch wrote: > > First, correcting the subject line (sorry - that looks like an erroneous > paste on my part). > > Also below... > > On 4/25/2017 1:59 PM, Yoav Nir wrote: >> Hi, Joe >> >> I haven’t been involved with this draft, but I don’t

Re: [IPsec] Ben Campbell's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS and COMMENT)

Hi Ben, Thanks for the comments! Your point about the line in Section 6 not making sense is definitely a good point. How about this text (changes in bold): If a TCP connection is being used to resume a previous IKE session, the TCP Responder can recognize the session using either the IKE SPI

Re: [IPsec] Mirja Kühlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS)

ESP in a stream, not relying on an outer protocol's details. I'm perfectly open to using another prefix value; if you have a suggestion for a longer value, that would be great! Thanks, Tommy > > -Ekr

Re: [IPsec] Ben Campbell's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS and COMMENT)

36 PM, Ben Campbell <b...@nostrum.com> wrote: >> >>> On Apr 26, 2017, at 12:50 PM, Tommy Pauly <tpa...@apple.com> wrote: >>> >>> Hi Ben, >>> >>> Thanks for the comments! Your point about the line in Section 6 not making >&g

Re: [IPsec] Mirja Kühlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS)

> On Apr 27, 2017, at 7:32 AM, Mirja Kühlewind wrote: > > See below > > On 27.04.2017 16:27, Eric Rescorla wrote: >> >>"This document leaves the selection of TCP ports up to >> implementations. It is suggested to use TCP port 4500, which >> is

Re: [IPsec] Mirja Kühlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS)

> On Apr 27, 2017, at 6:46 AM, Mirja Kühlewind wrote: > > One more side comment on the magic number: actually the magic number makes it > easy for network operator to identify IKE/IPSec traffic on any port and block > all packets that below to a flow that started with

Re: [IPsec] Mirja Kuehlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS)

Hello all, Here's some proposed text for: - Clarifying the configuration model around ports - Clarifying the role of the stream prefix - Expanding the TCP performance considerations. Changes are in bold. Thanks, Tommy --- 2. Configuration One of the main reasons to use TCP

Re: [IPsec] Mirja Kuehlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS)

ll let her respond to > most of Tommy's proposed text changes, but on the last one ... > > On Fri, Apr 28, 2017 at 12:05 PM, Tommy Pauly <tpa...@apple.com > <mailto:tpa...@apple.com>> wrote: > > 14. IANA Considerations > >This memo includes no request to IAN

Re: [IPsec] Mirja Kuehlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS)

> On May 8, 2017, at 5:49 AM, Mirja Kuehlewind (IETF) > wrote: > > Does the proposed text changes from Tommy still refer to 443 anywhere (lost > track a bit but I guess the appendix still does right)? > > Again I think we should talk about using 443 if that’s what’s

Re: [IPsec] Question about ipsecme-tcp-encaps

> On May 17, 2017, at 12:12 PM, Scott Fluhrer (sfluhrer) > wrote: > > > From: Yoav Nir [mailto:ynir.i...@gmail.com ] > Sent: Wednesday, May 17, 2017 2:54 PM > To: Scott Fluhrer (sfluhrer) > Cc: IPsecme WG (ipsec@ietf.org

Re: [IPsec] Should draft-ietf-ipsecme-tcp-encaps-10 update 7296 ?

> On Jun 1, 2017, at 4:17 PM, Paul Wouters <p...@nohats.ca> wrote: > > On Wed, 31 May 2017, Tommy Pauly wrote: > >> I've posted a new version of the draft that incorporates the changes >> discussed in this thread. Please review! >> https://datatracker.ietf

Re: [IPsec] Mirja Kuehlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS)

On May 12, 2017, at 3:25 PM, Tommy Pauly <tpa...@apple.com> wrote: > > > >> On May 8, 2017, at 5:49 AM, Mirja Kuehlewind (IETF) <i...@kuehlewind.net> >> wrote: >> >> Does the proposed text changes from Tommy still refer to 443 anywhere (lost &g

Re: [IPsec] qr-ikev2 interop test

Thanks for setting this up! I'll try an interop soon (this week I hope). However, some questions first: what values are you using for these? - PPK_SUPPORT notify code - PPK_IDENTITY notify code Also, I presume you're using PPK_ID_FIXED, not PPK_ID_OPAQUE? Thanks, Tommy > On Nov 13, 2017, at

Re: [IPsec] draft-pauly-ipsecme-split-dns

It seems like the conversation here stalled out a bit. From my perspective, the feeling in the working group is that the functionality described in the document for dealing with Split-DNS and DNSSEC is the best thing we can do given enterprise deployment models, as long as it is clear that

Re: [IPsec] Agenda for IETF 100

+ 1 to these proposals I'd also like to see the work on drafts like DIET-ESP (draft-mglt-ipsecme-diet-esp-04) be incorporated. I think we'll have some growing use cases for IPsec in constrained networks, and as that develops, extensions and modifications to the protocol to make IKEv2 and ESP

Re: [IPsec] Additional charter items 4/4: Mitigating privacy concerns

+1 to adding privacy text to the charter. This seems like it will be increasingly relevant if we’re doing host-to-host communication and we want to protect the privacy of various peers. —Tommy > On Feb 16, 2018, at 12:09 PM, Paul Wouters wrote: > > On Fri, 16 Feb 2018, Tero

Re: [IPsec] Genart last call review of draft-ietf-ipsecme-split-dns-12

Hi Christer, Thanks for the review! Some responses inline. Best, Tommy > On Aug 16, 2018, at 11:25 PM, Christer Holmberg > wrote: > > Reviewer: Christer Holmberg > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART)

Re: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-10.txt

similarly SHOULD NOT be whitelisted. > > Regards, > Dave > From: IPsec mailto:ipsec-boun...@ietf.org>> on > behalf of Tommy Pauly mailto:tpa...@apple.com>> > Sent: Wednesday, July 18, 2018 4:28:30 PM > To: IPsecME WG; Eric Rescorla > Subject: Re: [IPsec] I-D Ac

Re: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-11.txt

> On Jul 22, 2018, at 12:01 PM, Paul Wouters wrote: > > On Thu, 19 Jul 2018, Tommy Pauly wrote: > >>> Because you can have more then one INTERNAL_DNSSEC_TA for one domain. >>> Instead, it should read: >>> >>> Any INTERNAL_DNSS

Re: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-11.txt

> On Jul 19, 2018, at 2:09 PM, Paul Wouters wrote: > > On Thu, 19 Jul 2018, internet-dra...@ietf.org wrote: > >> Subject: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-11.txt > >> A diff from the previous version is available at: >>

Re: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-10.txt

org wrote: > > > 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 WG of > the IETF. > >Title : Split DNS Configuration for IKEv2 >

Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-tcp-guidelines-00.txt

Hi Valery, Thanks for sharing this! I agree with the points you bring up for MOBIKE (not changing the message ID, and needing to recalculate NAT detection payloads). Those are useful to clarify. Regarding retransmissions/puzzles/error handling, I agree with Paul that the recommendations being

Re: [IPsec] Shepherd Review of draft-ietf-ipsecme-split-dns-06

Hi David, I’ve updated the draft with your comments as version -07: https://www.ietf.org/id/draft-ietf-ipsecme-split-dns-07.txt <https://www.ietf.org/id/draft-ietf-ipsecme-split-dns-07.txt> Thanks, Tommy > On Feb 28, 2018, at 9:38 AM, Tommy Pauly <tpa...@apple.com> wrote

Re: [IPsec] RFC8229 (IKE over TCP) and retransmissions

Hi Valery, Thanks for bringing this up with the WG! I agree that retransmissions of IKE packets within the TCP stream may be pointless, and add to congestion. We do mention this for ESP packets over the TCP stream (Section 12.2 Added Reliability for Unreliable Protocols), but it doesn’t call

Re: [IPsec] Shepherd Review of draft-ietf-ipsecme-split-dns-06

res >> required for full conformance with the provisions of BCP 78 and BCP 79 have >> already been filed." >> >> I will send it forward once I hear from each of you. >> >> Thanks, >> Dave >> >>> -Original Message- >>> From: Pa

Re: [IPsec] Shepherd Review of draft-ietf-ipsecme-split-dns-06

Hi David, Thanks! I’ll work on this today and send an update. Tommy > On Feb 26, 2018, at 4:51 PM, Waltermire, David A. (Fed) > wrote: > > Authors, > > Overall the draft is almost ready to submit to the IESG once the following > few small issues are resolved. >

Re: [IPsec] Call for WG Adoptation for draft-boucadair-ipsecme-ipv6-ipv4-codes

Agreed with Valery that this is a fine starting point to define the problem, but we will need to iterate on the details. I do support adoption. Thanks, Tommy > On Oct 16, 2018, at 11:59 PM, Valery Smyslov wrote: > > Hi, > > after reading the draft's introduction, I think the problem

Re: [IPsec] Rename IKE_AUX?

I agree that IKE_AUX can be easily confused with IKE_AUTH. Similarly, IKE_INT looks a lot like the INIT from IKE_SA_INIT. I don't necessarily love IKE_PRE_AUTH, but it still seems preferable to the other options. You could also spell out "intermediate" to have IKE_INTERMEDIATE. This is still

Re: [IPsec] New Version Notification for draft-pwouters-ikev1-ipsec-graveyard-00.txt

Thanks for writing this up! Glad to get rid of IKEv1 =) I do have a question regarding whether the deprecations for the IKEv2 registry are appropriate for this document. RFC 8247 contains the recommendations for the which algorithms and DH groups are going away (SHOULD NOT, MUST NOT, etc), and

Re: [IPsec] NO_PROPOSAL_CHOSEN vs INVALID_SYNTAX

It does seem to a question open to interpretation by the implementation. I think you can make a good argument for NO_PROPOSAL_CHOSEN in both cases. If your implementation interprets things as always getting a list of valid proposal values based on the remote address or ID, then any unknown

Re: [IPsec] Adoption call for draft-hopps-ipsecme-iptfs

I've read the document and think this is good problem area to work on, and this document is a good starting place to adopt. Going forward, I would like to see more discussion and review of the use IP fragmentation (how often is that really needed, and is it worth the concerns stated in

Re: [IPsec] Clarifications and Implementation Guidelines for using TCP Encapsulation in IKEv2 draft

Hi Valery, Thanks for bringing this up again. Would you be interested in making this an RFC8229bis instead? I think it would be most useful for an implementer to fold some of these clarifications into the main text itself. How do you feel about that? Best, Tommy > On Apr 28, 2020, at 2:54

Re: [IPsec] rfc8229bis missing advise on error handling in IKE_INIT

> On Mar 19, 2021, at 12:36 PM, Paul Wouters wrote: > > > Hi, > > We have implemented TCP but are running in some issues where the RFC and > the bis draft does not give us clarify. > > If the IKE_INIT over TCP gets back an INVALID_KE, what is supposed to > happen? Is the responder expected

Re: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike

I support adoption of this work. The mechanism of specifying the authentication domain name and service parameters is sound, and the right direction. I do agree with Paul Wouter’s comments, and I think the parts of the document that deal with requirements for config requests need work. Ideally,

  1   2   >