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

ic byte at the beginning of their > stream over TLS. This means that the inner protocol diverges depending on > which set of protocols are being used for the stream. I would prefer that > these be consistent if possible. > > Thoughts? > > Tommy > >> On Apr 5,

Re: [IPsec] EdDSA Signatures in IKE

No responses yet... Tero: What would it take to register an “identity” hash function for use with the EdDSA? Yoav > On 5 Apr 2016, at 11:09 AM, Yoav Nir wrote: > > Replying to myself... > > I’ve been told off-list that it didn’t make sense to introduce the hot, new >

Re: [IPsec] EdDSA Signatures in IKE

> On 7 Apr 2016, at 6:12 PM, Tero Kivinen wrote: > > Yoav Nir writes: >> Tero: What would it take to register an “identity” hash function for >> use with the EdDSA? > > I assume you mean new value for the RFC7427 Hash Algorithm registry? > That registry is by e

Re: [IPsec] EdDSA Signatures in IKE

; Sent: Friday, April 8, 2016 9:30 AM > To: Yoav Nir ; Tero Kivinen > Cc: IPsecME WG > Subject: Re: [IPsec] EdDSA Signatures in IKE > > "Identity" is the formally correct term, but I think "null" is much > clearer than "identity". Especially

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

> 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 "IK

Re: [IPsec] Status of draft-ietf-ipsecme-ddos-protection

Hi, On 26 May 2016, at 4:12 PM, Valery Smyslov wrote: > 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 > introduci

Re: [IPsec] Status of draft-ietf-ipsecme-ddos-protection

> On 31 May 2016, at 8:01 AM, Valery Smyslov wrote: > > 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 re

Re: [IPsec] Call for adoption on draft-pauly-ipsecme-tcp-encaps as an IPSecME WG document

> On 5 Jun 2016, at 7:58 PM, Paul Wouters wrote: > > On Sun, 5 Jun 2016, Waltermire, David A. (Fed) wrote: > >> This is the official call for adoption of >> https://datatracker.ietf.org/doc/draft-pauly-ipsecme-tcp-encaps/ as an >> IPSecME working group (WG) document. >> >> By adopting this d

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

Hi, Paul On 10 Jun 2016, at 5:42 AM, Paul Wouters wrote: > On Thu, 9 Jun 2016, Daniel Migault wrote: > >> Please find our new proposal with ESP using implicit IV [1]. We would like >> to present and discuss it at the next IETF meeting. > > I must understand it wrong... > > Aren't these IVs d

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

> On 10 Jun 2016, at 5:39 PM, Yaron Sheffer wrote: > > Hi, > > The document takes care to not define Implicit IV for AES-CBC, and I believe > the underlying reason is malleability of the encryption. The same would apply > to AES-CTR. So I would suggest to: > Exclude AES-CTR from this draft, o

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

nd IIV=1, there will need to be an ENCR_AES_CCM_16 >> with keylength=256 and no IIV attribute. >> >> """ >> >> [1] https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/ >> >> -Original Message- >> From: in

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

rsus an explicit IV > > > Please let us know if that address your purpose. > > BR, > Daniel > > On Fri, Jun 10, 2016 at 2:01 AM, Yoav Nir <mailto:ynir.i...@gmail.com>> wrote: > Hi, Paul > > On 10 Jun 2016, at 5:42 AM, Paul Wouters <mailto:p.

Re: [IPsec] Endless stream of NAT-T keepalive probes?

All three devices also run an SSL-VPN, so you can just go to https:// to see who owns them. The first one will also tell you the vendor as they didn’t customize the landing page… > On 22 Jun 2016, at 7:11 PM, Paul Wouters wrote: > > > Hi, > > One of my machines is seeing a continous stream

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

Hi, Mark > On 3 Jul 2016, at 9:08 PM, Mark McFadden wrote: > 3) The Internet Draft Currently under consideration is not the best starting > point as it assumes that post-quantum pre-shared keys are the preferred > solution for quantum resistance. This is not obviously the case; there are a

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

On 4 Jul 2016, at 12:44 PM, Paul Wouters wrote: > On Sun, 3 Jul 2016, Yoav Nir wrote: > >>> 3) The Internet Draft Currently under consideration is not the best >>> starting point as it assumes that post-quantum pre-shared keys are the >>> preferred solutio

Re: [IPsec] IETF 96 IPsecME Agenda

> On 7 Jul 2016, at 9:57 PM, Waltermire, David A. (Fed) > wrote: > > We are scheduled for 2pm - 4pm CEST on Tuesday, July 19th. The chairs need > to pull together an agenda for this meeting. Here is an early draft to get us > started: > > 10 minutes: agenda, WG status > > The following dra

Re: [IPsec] New charter proposal

+1 > On 22 Jul 2016, at 9:35 AM, Michael Richardson wrote: > > > New charter seems fine. > > (I am pessimistic about the milestones, but I suggest changing them as needed > rather than planning to take longer.) > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =-

Re: [IPsec] I-D Action: draft-ietf-ipsecme-safecurves-02.txt

t; This draft is a work item of the IP Security Maintenance and Extensions of > the IETF. > >Title : Curve25519 and Curve448 for IKEv2 Key Agreement > Authors : Yoav Nir > Simon Josefsson > Filename:

Re: [IPsec] I-D Action: draft-ietf-ipsecme-safecurves-02.txt

> On 8 Aug 2016, at 3:51 PM, Tero Kivinen wrote: > > Yoav Nir writes: >> Hi. >> >> New in this version: >> - A few textual changes in the Introduction (suggested by Tero) > > You seemed to skip my proposed changes for the IANA considerations > section

Re: [IPsec] 4307bis/7321bis key sizes

> On 23 Aug 2016, at 9:32 PM, Paul Hoffman wrote: > > On 23 Aug 2016, at 10:55, Paul Wouters wrote: > >> On Mon, 8 Aug 2016, Paul Wouters wrote: >> >> I haven't heard any objection to making 128 bit key sizes MUST- and >> 256 bit key sizes MUST. > > You can hear one now. > >> Answers that ag

Re: [IPsec] I-D Action: draft-ietf-ipsecme-safecurves-04.txt

TF. > >Title : Curve25519 and Curve448 for IKEv2 Key Agreement > Authors : Yoav Nir > Simon Josefsson > Filename: draft-ietf-ipsecme-safecurves-04.txt > Pages : 7 > Date: 2

Re: [IPsec] Stephen Farrell's Yes on charter-ietf-ipsecme-10-00: (with COMMENT)

Hi, Stephen > On 30 Aug 2016, at 4:38 PM, Stephen Farrell wrote: > I have a suggestion about this bit of work: > > "IKEv1 using shared secret authentication was partially resistance to > quantum computers. IKEv2 removed this feature to make the protocol > more usable. The working group will a

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

> On 31 Aug 2016, at 3:21 PM, Tero Kivinen wrote: > > Mirja Kuehlewind (IETF) writes: >> thanks for the reply. Very helpful background info. Maybe even put >> more information in the charter text. > > I think it belongs to the actual draft, not to the charter, perhaps we > should put the draft

Re: [IPsec] Mirja Kühlewind's No Objection on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)

Hi. See responses below > On 23 Sep 2016, at 10:11 PM, Mirja Kuehlewind wrote: > -- > COMMENT: > -- > > Some questions: > > 1) sec 7.1.2: If there is a puzzl

Re: [IPsec] Flexible multi-factor authentication

Hi. It seems that what you are looking for is a generic way to transport arbitrary strings from server to client and back again. While not specifically intended for that, both EAP-GTC and EAP-OTP (types 6 and 5 respectively) have been (ab)used for that purpose. Not sure if that has happened in

Re: [IPsec] Alexey Melnikov's No Objection on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)

> On 27 Sep 2016, at 2:42 PM, Valery Smyslov wrote: > > Hi Alexey, > > payload type for the Puzzle Solution Payload is specified in the last sentence > of Section 8.2: > > The payload type for the Puzzle Solution payload is . > > It is not included in the diagram in this section since the "N

Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)

On 27 Sep 2016, at 8:09 PM, Stephen Farrell wrote: > This is a nicely written document... thanks! > > - I vaguely recalled that puzzles and IPR rang a bell. Did > the WG consider [1]? If not, and if it helps, I'm fine with > making a 3rd party declaration on that and last call could be > done

Re: [IPsec] Interoperability problem concerning RFC 7427

> On 4 Oct 2016, at 17:11, Valery Smyslov wrote: > > Hi Tero, >> [This is bit old email, but I have not seen any replies to this, and I >> am sending this as implementor not as chair.] >> Valery Smyslov writes: >>> The problem is that RFC7427 doesn't provide any means to find out >>> what kind

Re: [IPsec] Interoperability problem concerning RFC 7427

Perhaps we (as in the working group) should schedule some time (15-20 minutes?) to discuss the options in Seoul. Understanding both RFC 7427 and PSS signatures when they are in certificates, but not PSS signatures when they are in AUTH payloads is a pretty egregious kind of wrongness, but if th

Re: [IPsec] Gen-ART Last Call review of draft-ietf-ipsecme-safecurves-04

Thanks for that. For some reason gmail sent this to the spam folder. Yoav > On 7 Oct 2016, at 20:32, Kathleen Moriarty > wrote: > > Orit, > > Thanks for the review, making sure the editor see this. > > Kathleen > > On Tue, Sep 27, 2016 at 5:30 PM, Orit Levin >

Re: [IPsec] Gen-ART Last Call review of draft-ietf-ipsecme-safecurves-04

Hi, Orit. I accepted most of your suggestions with a few exceptions below: > On 28 Sep 2016, at 0:30, Orit Levin wrote: > > I am the assigned Gen-ART reviewer for this draft. The General Area Review > Team (Gen-ART) reviews all IETF documents being processed by the IESG for the > IETF Chair.

Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-safecurves-05: (with COMMENT)

Hi, Stephen > > - Wouldn't it be good to encourage minimising re-use of > public values for multiple key exchanges? As-is, the text > sort-of encourages use for "many key exchanges" in > section 4. I don’t think so. Re-use reduces the computation cost of an IKE Responder (or TLS server) without

Re: [IPsec] [saag] trapdoor'ed DH (and RFC-5114 again)

I’m not entirely comfortable with calling something a MUST NOT when all we have is conjecture, but I have no love and no need of those DH groups. I don’t believe anyone else depends on these groups (at least in IPsec), so I’m fine with such a change. Yoav > On 17 Oct 2016, at 18:54, Daniel Mig

Re: [IPsec] [saag] trapdoor'ed DH (and RFC-5114 again)

> On 17 Oct 2016, at 19:19, Paul Wouters wrote: > > On Mon, 17 Oct 2016, Yoav Nir wrote: > >> I’m not entirely comfortable with calling something a MUST NOT when all we >> have is conjecture, > > It's a little more than conjecture. > > 1) It has been

Re: [IPsec] [saag] trapdoor'ed DH (and RFC-5114 again)

> On 18 Oct 2016, at 13:33, Tero Kivinen wrote: > > Yoav Nir writes: >> I’m not entirely comfortable with calling something a MUST NOT when all we >> have is conjecture, but I have no love and no need of those DH groups. > > Same here, and it also makes i

Re: [IPsec] [IANA #932374] Protocol Action: 'Curve25519 and Curve448 for IKEv2 Key Agreement' to Proposed Standard (draft-ietf-ipsecme-safecurves-05.txt)

Hi, Amanda This seems correct. Thanks. Yoav > On 20 Oct 2016, at 22:43, Amanda Baber via RT > wrote: > > Dear Authors: > > ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED > > We've completed the registry actions for the following RFC-to-be: > > draft-ietf-ipsecme-safecurves-05 > > We've

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

xtensions of > the IETF. > >Title : Using Edwards-curve Digital Signature Algorithm > (EdDSA) in the Internet Key Exchange (IKEv2) >Author : Yoav Nir > Filename: draft-ietf-ipsecme-eddsa-00.txt > Pages : 5 > Date

Re: [IPsec] New Version Notification for draft-xu-ipsecme-esp-in-udp-lb-00.txt

Hi, Xiaohu A few comments. Actually, they’re more like questions. How are IPsec SAs mapped to UDP pseudo-connections? Is it a 1:1 mapping between SPI and source port? If now, how do you deal with the packet reordering that the load balancer will do? IPsec requires ordered or nearly-ordered del

Re: [IPsec] New Version Notification for draft-xu-ipsecme-esp-in-udp-lb-00.txt

> On 2 Nov 2016, at 18:19, Michael Richardson wrote: > > > Yoav Nir wrote: >> 4 Why do we need a new port? What goes wrong if the >> packets go to port 4500? > > I think that TE/load-balancer in the network calculates the same tuple hash > and so takes

Re: [IPsec] New Version Notification for draft-xu-ipsecme-esp-in-udp-lb-00.txt

given traffic flow would be forwarded over a certain path and > therefore this is no disordering issue. As for why do we need a new port, I > had attempted to reply in another email. > > Best regards, > XIaohu > > 发件人: Yoav Nir [mailto:ynir.i...@gmail.com] > 发送时间: 20

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

s reserved soon? > > Thanks, > Tommy > >> On Oct 29, 2016, at 8:19 AM, Yoav Nir > <mailto:ynir.i...@gmail.com>> wrote: >> >> This version is similar to draft-nir-ipsecme-eddsa-01, with the following >> changes: >> Updated references >>

[IPsec] Resolving the Ed448 context issue in the EdDSA draft

Hi, all As mentioned in Tuesday's session, Ed448 and Ed25519ctx add a new parameter to the signature function: a context string. Setting this string to a different value for each application (where application could be "PKIX", "TLS", "IKE") leads to different results and thus a signature made i

Re: [IPsec] Resolving the Ed448 context issue in the EdDSA draft

gt; >> Yours, >> Daniel >> >> >> On Nov 16, 2016 1:35 PM, "Yaron Sheffer" > <mailto:yaronf.i...@gmail.com>> wrote: >> >> >> >>On 16/11/16 12:41, Paul Wouters wrote: >> >> >> >&g

Re: [IPsec] Resolving the Ed448 context issue in the EdDSA draft

But yes, I agree that IPsec, TLS and Curdle should come to the same conclusion either way. And I think that in light of existing deployment, Ed25519ctx *with* context is a very hard sell. Yoav > On 16 Nov 2016, at 15:32, Yoav Nir wrote: > > No, I think he means Ed448 an

Re: [IPsec] Take a stand for key hygine

Hi, Watson On 18 Nov 2016, at 9:18, Watson Ladd wrote: > Dear all, > > In reviewing the proceedings now online I noticed that someone is > proposing to support using the same key with multiple signature > algorithms. This is a bad idea that makes everyone sad. Showing that a > signature under o

Re: [IPsec] Take a stand for key hygine

> On 18 Nov 2016, at 5:38, Tero Kivinen wrote: > > Watson Ladd writes: >> I might be confused, but the slides in >> https://www.ietf.org/proceedings/97/slides/slides-97-ipsecme-signature-forms-ambiguity-in-ikev2-00.pdf >> seem to very clearly want something else. Apologies for my >> insufficient

Re: [IPsec] Take a stand for key hygine

3, that won’t make server owners happy. > > I think it is a good idea to raise this issue in TLS WG. > > Regards, > Valery. > > > > From: Yoav Nir <mailto:ynir.i...@gmail.com> > Sent: 19 ноября 2016 г. 7:21 > To: Tero Kivinen <mailto:kivi...@iki.fi&g

Re: [IPsec] Quantum Resistant IKEv2

> On 8 Dec 2016, at 1:43, Michael Richardson wrote: > > > Scott Fluhrer (sfluhrer) wrote: >> o There is the option listed in the draft, where we modify both the >> KEYMAT and SKEYSEED computations; stirring it into the KEYMAT implies > > I read through the three options, and I have difficulty

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

> On 9 Dec 2016, at 18:32, Bjoern A. Zeeb > wrote: > > On 9 Dec 2016, at 16:07, Bill Fenner wrote: > >> On Fri, Dec 9, 2016 at 8:41 AM, Heatley, Nick wrote: >> >>> Hi All, >>> >>> The sunset4 minutes suggest NAT64 SSID to become the default? >>> >>> Just checking, is there any summary on h

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

> On 9 Dec 2016, at 23:43, Michael Richardson wrote: > > > Yoav Nir wrote: >> To get this working, the DNS64 should be on the remote tunnel endpoint >> or behind it. And this will require that it has an IPv6 address and >> knows to do the NAT64 translation

Re: [IPsec] [Editorial Errata Reported] RFC7296 (4930)

This is factually true, and it dates back to RFC 5996 (but not 4306). It obviously doesn’t confuse anyone, so I guess it should be either “held for document update” Yoav > On 8 Feb 2017, at 17:55, RFC Errata System wrote: > > The following errata report has been submitted for RFC7296, > "Inte

Re: [IPsec] Comments on draft-ietf-ipsecme-rfc4307bis

One correction > On 15 Feb 2017, at 19:05, Paul Wouters wrote: > >>> Nit: You need only one of the public values and the complementary >>> private value from the other side. >> >> Right. > > Instead of this: >exchange provides keys for the session. If an attacker can retrieve >one

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

Almost there. You didn’t reverse the complementary public keys (g**b or g**a) instead of (g**a or g**b) > On 16 Feb 2017, at 20:35, Paul Wouters wrote: > > On Thu, 16 Feb 2017, internet-dra...@ietf.org wrote: > >> Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-16.txt > >> A diff f

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

Hi, Daniel. See my comments inline. Also see this pull request: https://github.com/ietf-ipsecme/drafts/pull/25 Unless I hear some push-back, I will submit this right before the deadline. Yoav > On 8 Mar 2017, at 20:49, Daniel Migault wrote: >

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

with a different meaning, assigning the next > available value (currently 5) seems appropriate. > > Thanks, > David > > >> On Mar 12, 2017, at 11:14, Yoav Nir > <mailto:ynir.i...@gmail.com>> wrote: >> >> Hi, Daniel. >> >> See my comment

Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT)

Hi. I’d like to address the second comment. > On 15 Mar 2017, at 3:33, Stephen Farrell wrote: > - ENCR_NULL IMO ought be MUST NOT - did the WG discuss > that explicitly? If so, can you provide a pointer to the > archive? If not, does it still have to be a MUST? I do > wonder who wants to u

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

Hi, Eric. > On 19 Mar 2017, at 4:04, Eric Rescorla wrote: > > [Now with the right address] > > I just finished reading this document. Some comments below. > > > - You have a uniform 16 bit length field followed by a 4 byte all-zeros >sentinel value to indicate that a packet is IKE rather

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

Hi Valery. > On 19 Mar 2017, at 11:24, Valery Smyslov wrote: > > Hi Eric, > >> - It seems like IKE associations can span TCP connections (S 6) >> so why not instead of doing UDP first then TCP, do happy eyeballs. > > I don't think it's a good idea. The TCP encapsulation has a lot of drawbacks

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

> On 19 Mar 2017, at 13:20, Valery Smyslov wrote: > > Hi Yoav, > >> > I don't think it's a good idea. The TCP encapsulation has a lot of >> > drawbacks in terms of performance (see Section > 12), so it is considered >> > as a last resort if UDP doesn't work. In general UDP (or no encapsulation

Re: [IPsec] Comments on draft-mglt-ipsecme-implicit-iv-02.tx

> On 19 Mar 2017, at 16:55, Eric Rescorla wrote: > > Overall: > I notice that you are using a construction different from that used > in TLS 1.3, which doesn't directly repeat nonces across associations. > > S 2. >This document does not consider AES-CBC ([RFC3602])as AES-CBC >requires t

Re: [IPsec] Comments on draft-mglt-ipsecme-implicit-iv-02.tx

> On 19 Mar 2017, at 19:30, Eric Rescorla wrote: > > > > On Sun, Mar 19, 2017 at 10:23 AM, Yoav Nir <mailto:ynir.i...@gmail.com>> wrote: > >> On 19 Mar 2017, at 16:55, Eric Rescorla > <mailto:e...@rtfm.com>> wrote: >> >> Overall: >

Re: [IPsec] Starting two week working group adoptation call for draft-mglt-ipsecme-implicit-iv

Not surprising (me being a co-author) but I support adoption. > On 29 Mar 2017, at 16:44, Tero Kivinen wrote: > > As discussed in the meeting, we are starting two week working group > adoptation call for the draft-mglt-ipsecme-implicit-iv. > > Please read the draft and send your comments to thi

Re: [IPsec] draft-ietf-ipsecme-eddsa-01 pre-hash SHOULD NOT or MUST NOT

> On 5 Apr 2017, at 16:26, Tero Kivinen wrote: > > Now the pre-hash algorithms are SHOULD NOT: > > The pre-hashed versions of Ed25519 and Ed448 (Ed25519ph and Ed448ph > respectively) SHOULD NOT be used in IKE. > > I think we could say MUST NOT be used. As it turns out they cannot be used,

Re: [IPsec] Can IPSec (RFC 5996) support tunnels with end point being (virtual) CPEs which has a set of workload attached (say Virtual Machines) all having virtual IP addresses?

Hi What Michael said. Additional comments within. On 13 Apr 2017, at 22:48, Michael Richardson wrote: > > > Linda Dunbar wrote: >> - To support this, one end point of the tunnel will be (virtual) CPEs >> which has a set of workload attached (say Virtual Machines). All having >> virtual IP ad

Re: [IPsec] Can IPSec (RFC 5996) support tunnels with end point being (virtual) CPEs which has a set of workload attached (say Virtual Machines) all having virtual IP addresses?

all preventing some sorts of traffic to the VM, but I don’t know much about it. Yoav > > Linda > -Original Message- > From: Yoav Nir [mailto:ynir.i...@gmail.com <mailto:ynir.i...@gmail.com>] > Sent: Thursday, April 13, 2017 4:42 PM > To: Linda Dunbar > Cc: IPs

Re: [IPsec] sharing key among multiple end points vs. Group Encryption Key - draft-abad-i2nsf-sdn-ipsec-flow-protectio

Hi, Linda > On 21 Apr 2017, at 0:40, Linda Dunbar wrote: > > Yoav, > > You said that it is a bad idea to have "sharing key among multiple points" as > introduced by draft-abad-i2nsf-sdn-ipsec-flow-protection. > > Isn't the "Group Encryption Key" of having a "Key Server" distributing the > ke

Re: [IPsec] informal ports and transport review of ipsecme-cha...@tools.ietf.org

Hi, Joe I haven’t been involved with this draft, but I don’t believe that last statement is correct: > On 25 Apr 2017, at 23:03, Joe Touch wrote: > >> >> This issue is really everyone circling around the elephant in the room. >> Part of this draft is designed to break through firewalls and >>

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

> On 26 Apr 2017, at 0:15, 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

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

> On 17 May 2017, at 20:39, Scott Fluhrer (sfluhrer) wrote: > > I’ve been looking over the draft, and I think I see a potential DoS attack > that does not appear to be addressed. I’m writing this to see if there is > something I missed (and if there isn’t, start discussion on how we might >

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

> On 17 May 2017, at 22:12, Scott Fluhrer (sfluhrer) wrote: > > > > > My TCP may be rusty, but I think Alice’s legitimate packet has the sequence > number to indicate it is retransmitting the byte that Bob already has. I > don’t know if that means that the new data overwrites the old data,

[IPsec] IPsec and SDN

Hi. This may be of interest to this working group. The I2NSF working group is meeting this afternoon at 13:30 On the agenda ([1]) there’s a 10-minute slot for controlling IPsec endpoints using SDN ([2]). I think this draft has two issues: Their IKE-less case (case #2) has session keys generate

Re: [IPsec] IPsec and SDN

devices without batteries restarting and getting the > same values and end up re-using the same counter for AEAD algorithms. > > Sent from my iPhone > > On Jul 18, 2017, at 10:29, Yoav Nir <mailto:ynir.i...@gmail.com>> wrote: > >> Hi. >> >> This may be of int

Re: [IPsec] IPsec and SDN

uss, > let me send some initial comments inline. > > >> El 18 jul 2017, a las 10:29, Yoav Nir > <mailto:ynir.i...@gmail.com>> escribió: >> >> Hi. >> >> This may be of interest to this working group. >> >> The I2NSF working group is

Re: [IPsec] draft-abad-i2nsf-sdn-ipsec-flow-protection

I mostly agree, but one point… > On 18 Jul 2017, at 17:06, Tero Kivinen wrote: > This I think is important question, i.e., what is the gain for not > running IKEv2 between the nodes? > Simpler gateway, less code, no PK operations, no need for random number generator. The counter-argument i

Re: [IPsec] draft-abad-i2nsf-sdn-ipsec-flow-protection

:34, Yaron Sheffer wrote: > > On 18/07/17 17:14, Yoav Nir wrote: >> I mostly agree, but one point… >> >>> On 18 Jul 2017, at 17:06, Tero Kivinen wrote: >> >> >>> This I think is important question, i.e., what is the gain for not >>> running

Re: [IPsec] [I2nsf] draft-abad-i2nsf-sdn-ipsec-flow-protection

> On 20 Jul 2017, at 9:56, Valery Smyslov wrote: > > Hi Gabriel, > > I think that at this point the discussion is not very productive. > I admit that I’m not very familiar with SDNs, so I have to > blindly trust you when you state that the SDN Controller > knows everything and is able to contro

[IPsec] I2NSF Virtual Interim meeting on IPsec and draft-abad

Hi folks. This message is cross-posted to both the IPsec list and the i2nsf list. During the F2F meeting in Prague it was apparent that there is a disconnect between the SDN people and the VPN people. ISTM that the best way to solve this is to hold a virtual interim meeting for longer than the

Re: [IPsec] I2NSF Virtual Interim meeting on IPsec and draft-abad

Sorry for the confusion, but it turns out that some key people can’t make it in August. I’ve updated the poll with dates in September. Thanks > On 28 Jul 2017, at 13:02, Yoav Nir wrote: > > Hi folks. > > This message is cross-posted to both the IPsec list and the i2nsf list.

[IPsec] I2NSF Virtual Interim meeting on IPsec and draft-abad [Doodle]

PRODID:-//Apple Inc.//Mac OS X 10.12.6//EN BEGIN:VEVENT TRANSP:OPAQUE DTEND:20170906T173000Z ORGANIZER;SCHEDULE-AGENT=CLIENT:MAILTO:mai...@doodle.com UID:1504713602039394...@doodle.biz DTSTAMP:20170808T210655Z LOCATION:It's virtual DESCRIPTION:Initiated by Yoav Nir\nThe I2NSF meeting in Pragu

[IPsec] Fwd: [I2nsf] Interface to Network Security Functions (i2nsf) WG Virtual Meeting: 2017-09-06

FYI. This meeting may be of interest to IPsecME participants. draft-abad-i2nsf-sdn-ipsec-flow-protection describes how to control IPsec implementations using an SDN controller. This includes automatic configuration of RFC 4301 data structures such as the SPD, PAD, and potentially the SAD. You

Re: [IPsec] [I2nsf] interim tomorrow

And now it is Sent from my Windows 10 phone From: Yoav Nir Sent: Wednesday, September 6, 2017 7:54 To: Michael Richardson Cc: i2...@ietf.org; ipsec-cha...@ietf.org Subject: Re: [I2nsf] interim tomorrow It can and it will. Later today… > On 6 Sep 2017, at 4:46, Michael Richardson wr

[IPsec] Reminder: I2NSF virtual interim meeting

Hi This is a reminder that the I2NSF virtual interim meeting will take place today/tonight in about two hours. Agenda and slides are here: https://datatracker.ietf.org/meeting/interim-2017-i2nsf-01/session/i2nsf More information such as Webex info is in the Agenda at the above link. The draft t

Re: [IPsec] Reminder: I2NSF virtual interim meeting

nk you, > Kathleen > > On Wed, Sep 6, 2017 at 9:58 AM, Yoav Nir wrote: >> Hi >> >> This is a reminder that the I2NSF virtual interim meeting will take >> place today/tonight in about two hours. >> >> Agenda and slides are here: >> https://da

Re: [IPsec] your example (like Gap) about IPSec VPN gateway deployed in shopping mall not aware of where the controller is.

Hi, Linda The reason I brought up the Gap was because they described their network in a Packet Pusher’s episode ([1]). And the solution for them was some vendor’s SD-WAN solution. As far as I can tell, each vendor’s SD-WAN solution is proprietary and non-interoperable with other vendors’ SD-WA

Re: [IPsec] [Technical Errata Reported] RFC5282 (5109)

Hi, David. Section 2.7 last paragraph: If an initiator proposes both normal ciphers with integrity protection as well as combined-mode ciphers, then two proposals are needed. One of the proposals includes the normal ciphers with the integrity algorithms for them, and the other propos

Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments

Dragan Grebovich wrote: Hi Tero I reviewed your heuristics draft and I believe it is interesting and doable, however: 1) I believe the actual implementation would require more code than current front-end hardware allows. The hardware we work with have a limited space for that much heuristics

Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments

Dragan Grebovich wrote: Yoav I apologize for not being clearer earlier. I was not suggesting any new/different policy enforcement. I believe/agree that traffic visibility will matter only to a subset of traffic, but that is enforced at each appliance level, or on a more granular (per interfac

Re: [IPsec] Feedback on the interim session's format

Tero Kivinen wrote: > > Can we live with push-to-talk? > > Push-to-talk works well for normal discussion, but it was > impossible to use when giving presentation, which meant that > I myself changed the setting to voice activated microphone > when I started my presentation, and then changed back t

Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments

gabriel montenegro wrote: >I'll just comment on one item below: > >> As the draft says this is mostly meant for stateful devices, and that >> has been the main goal for the document. The charter says: >> >> "A standards-track mechanism that allows an intermediary device, such >> as a firewall or i

[IPsec] Issue #22: simultaneous IKE SA rekeys

Hi all. Section 2.8.1 of the draft discusses what to do when Child SAs are rekeyed simultaneously by both peers. Issue #22 asks to clarify the same thing for simultaneous rekeying of IKE SAs. We've written a proposed additional section, that should be labeled 2.8.2. Since this specifies new

Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04

I support advancing this. I preferred allowing the redirect in IKE_AUTH as well, but it seems like the group consensus went against that. One textual comment: since we have section 7 describing a symmetric case (redirect by either peer), section 6.1 should be chagned to reflect that the REDIRE

Re: [IPsec] Query on IKEv2 SA

Hi Raghu. You are correct. It is not mandatory to delete an IKE SA without child SAs. The draft does not specify the complete behavior of all products that implement it. It describes a language (IKE) by which two implementations may "converse" If is perfectly valid to create an implementation w

Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04

pasi.ero...@nokia.com wrote: > > Vijay Devarapalli wrote: > > > I don't agree with the restriction that the original > gateway and the > > new gateway should have the same IDr. That is too restrictive. For > > example, it should be possible for gw1 to redirect the > client to gw2, > > with

Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04

Paul Hoffman wrote: > > At 1:07 PM -0800 3/11/09, Vijay Devarapalli wrote: > >There are environments where the client (e.g, Mobile IPv6 > MN, 3GPP I-WLAN client) always discovers the gateways they > need to attach to. They might get assigned different gateways > based on what service they want

Re: [IPsec] Redirect during IKE_AUTH (was Re: WG Last Call:draft-ietf-ipsecme-ikev2-redirect-04)

An Initiator MAY send an IDr in the IKE_AUTH request, to tell the peer which of its multiple identities you want to talk to. The 3GPP people like that functionality. It makes sense for there to be one gateway, you tell it which identity you're looking for, and then it redirects you to the prope

Re: [IPsec] is there any proposed solution to solve the anti-replay problem for IPsec pkts when subject to QOS classification

RFC 4306 specifically requires implementations to support multiple parallel child SAs. If you use a different SA for each QoS class, you should not have problems with the replay window From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Pr

Re: [IPsec] Ticket #9

Hi Kalyani. One way or the other, it has to be mandatory. The "dread" scenario is that one peer thinks the IKE SA is set up, while the other thinks that it is not. >From the discussion of Ticket #9, the consensus seems to be that with all >those child-SA specific reasons, the IKE SA is set up -

Re: [IPsec] Issue #2: Where does N(SET_WINDOW_SIZE) go?

Definitely From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Scott C Moonen Sent: Thursday, April 02, 2009 3:48 PM To: Yaron Sheffer Cc: IPsecme WG Subject: Re: [IPsec] Issue #2: Where does N(SET_WINDOW_SIZE) go? > From Appendix C: The sp

Re: [IPsec] Issue #12: Traffic selectors when rekeying vs. the packet that trigerred the rekeying

I agree with Tero. How about replacing this: The initiator sends SA offer(s) in the SA payload, a nonce in the Ni payload, optionally a Diffie-Hellman value in the KEi payload, and the proposed traffic selectors for the proposed Child SA in the TSi and TSr payloads. With this: The

Re: [IPsec] Issue #2: Where does N(SET_WINDOW_SIZE) go?

IKE SA, so setting up some properties of that as-yet-non-existant IKE SA seems premature to me. I think it should be in all but the IKE_SA_INIT exchange (and also not in unprotected informational) From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On

<    1   2   3   4   5   6   7   8   9   >