Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-performance

> On 14 Nov 2023, at 19:46, Michael Richardson wrote: > > > Yoav Nir wrote: >> - Although it is implied, it should be stated explicitly that >> TS_MAX_QUEUE does not mean no more child SAs with these TS ever. As >> some child SAs get deleted and perha

Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-performance

> On 13 Nov 2023, at 12:31, Sahana Prasad wrote: > > Hello, > > I've read the draft and support its adoption. To clarify, the draft is already adopted since July 2021. The question now is whether it is ready to proceed to publication. > Specifically, we (at Red Hat) have use cases where

Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-performance

Hi. I’ve read the draft. Overall, it’s similar to a non-standardized solution we did at Check Point several years ago, so I agree that it is a solution that works. Of course, since there *are* a bunch of working implementations, that is not particularly insightful. With a lot of flows, it’s

[IPsec] Scheduling for London

Hi, folks. As you know, we have a 90-minute session on Wednesday, November 9th at 15:00. In addition to all the document status and solemn recitation of the Note Well, we have so far received 4 requests for agenda time: From Hang Shi about draft-ls-6man-ipcomp-exclude-transport-layer, a

[IPsec] Tomorrow's SAAG meeting

Hi all In case you missed it, tomorrow's SAAG meeting will feature an "Introduction to IPSec" (yes! with a capital S) by Paul Wouters. See you all there Yoav ⁣Sent from my phone ​___ IPsec mailing list IPsec@ietf.org

Re: [IPsec] Cost-efficient quantum-resistant DoS protection

> On 10 Nov 2021, at 16:41, Michael Richardson wrote: > > > Yoav Nir wrote: >>>> Tero Kivinen wrote: >>>>>> Even without surpassing the 64KB limit, this must be a concern. >>>>>> IKEv2's cookie mechanism and puzzles try to incre

Re: [IPsec] Cost-efficient quantum-resistant DoS protection

> On 1 Nov 2021, at 13:07, Valery Smyslov wrote: > > Hi Michael, > >> Tero Kivinen wrote: Even without surpassing the 64KB limit, this must be a concern. IKEv2's cookie mechanism and puzzles try to increase the cost of the attacker per each connection. Now, an attacker must

[IPsec] Publication has been requested for draft-ietf-ipsecme-ikev2-intermediate-07

Yoav Nir has requested publication of draft-ietf-ipsecme-ikev2-intermediate-07 as Proposed Standard on behalf of the IPSECME working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-intermediate

Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic

[no hats] I don’t want to start (or resume) a religious holy war about uppercase MUSTs, but they’re usually about protocol compliance. What people should (not SHOULD) do with their systems is not subject to requirements language, because the IETF does not engineer administrators. What? You are

Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic

ote: > > > I sent substantive comments on this draft to the list on May 6th of this > year. They were not addressed so they apply to this WGLC. > > Dan. > > On 6/26/21 1:38 AM, Yoav Nir wrote: >> Hi, all. >> >> Although this draft is really new,

Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic

Forgot to add a link to the draft: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev1-algo-to-historic/ <https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev1-algo-to-historic/> > On 26 Jun 2021, at 11:38, Yoav Nir wrote: > > Hi, all. > > Although this draft

[IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic

Hi, all. Although this draft is really new, having been submitted in April of this year, its predecessor draft has been under discussion since March of 2019. This begins a 2-week WGLC. Please read the draft and post comments to the list. Since this is rather new, short messages in the vein of

Re: [IPsec] [Cryptography] Direct public confirmation from Dr. Rogaway (fwd)

gy is not encumbered at all so, yea, let's do it. > > If an individual draft was to appear would the WG adopt it as a work item? Up to the WG, but I would support it. Yoav > > regards, > > Dan. > > On 2/28/21 1:47 PM, Yoav Nir wrote: >> IIRC the license has all

Re: [IPsec] [Cryptography] Direct public confirmation from Dr. Rogaway (fwd)

IIRC the license has allowed OCB to be used for TLS for several years. They haven’t taken it up. There are no AES-OCB ciphersuites inhttps://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-4

Re: [IPsec] [Last-Call] New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt

> On 31 Oct 2020, at 15:12, tom petch wrote: > > On 30/10/2020 22:42, Tero Kivinen wrote: >> Roman Danyliw writes: >> It seems to me that the IANA entries for IKEv2 are incomplete. >> RFC8247 does a fine job of specifying algorithms and adding >> information such as status

Re: [IPsec] Preliminary minutes from the IETF 108 IPsecME WG Meeting

Hi. I uploaded a PDF version to the meeting materials. Also added a list of action items for the chairs. Comments are welcome on that part as well. https://www.ietf.org/proceedings/108/minutes/minutes-108-ipsecme-00 Yoav

Re: [IPsec] Teaser for pitch talk at IETF 108

> On 24 Jul 2020, at 23:42, Michael Rossberg > wrote: > > Wiliam, Yoav, > > thanks for the comments, I’ll try to elaborate in a single mail as you are > heading in a similar direction. > >> RFC 6311 allows multiple members in a cluster of IPsec gateways to have >> independent parallel SAs

Re: [IPsec] Teaser for pitch talk at IETF 108

Hi, Michael. Thanks for bringing this to the group. > On 22 Jul 2020, at 13:26, Michael Rossberg > wrote: > > > We have been analyzing issues ESP has in current data-center networks and > came to > the conclusion that changes in the protocol could significantly improve its > behavior. Some

[IPsec] Agenda Uploaded

Please note that the times given are UTC. https://www.ietf.org/proceedings/108/agenda/agenda-108-ipsecme-00 Yoav___ IPsec mailing list IPsec@ietf.org

Re: [IPsec] ipsecme - Requested session has been scheduled for IETF 108

send your request to the chairs. Valery has already sent three requests; no need to re-send them. Tero & Yoav > On 3 Jul 2020, at 3:20, IETF Secretariat wrote: > > Dear Yoav Nir, > > The session(s) that you have requested have been scheduled. > Below is the schedul

Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane)

[talking as another individual and co-author of RFC7296, not as the other chair] > On 18 Jun 2020, at 21:03, Tero Kivinen wrote: > > [talking as individual and one of RFC7296 authors, not as WG chair]. > > Toerless Eckert writes: >> On Wed, Jun 17, 2020 at 08:55:12PM -0400, Paul Wouters

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

[With chair hat on] Yes, the charter says that we are to make a guidance document. If the working group feels that it’s better to put the specification and guidance in a single document, we can work on that and clear it with the ADs. Charters can be modified. Yoav > On 29 Apr 2020, at

[IPsec] Holding a virtual interim meeting. Or not

Hi all. As you know, the in-person IETF meeting in Vancouver has been cancelled. There is a reduced schedule for virtual meetings [1], but it does not include IPsecME. The IESG chair has published a recommended schedule [2] for the working groups to hold virtual meetings in April instead of

Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane)

> On 26 Feb 2020, at 19:56, Michael Richardson wrote: > > > Yoav Nir wrote: >> The draft says “IPsec tunnel mode is required ”, so it’s not >> transport. What goes in the TS payloads? > > TSi=HostA-LL/128, TSr=HostB-LL/128, Protocol = GRE(47) or IPIP(41) If

Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane)

The draft says “IPsec tunnel mode is required ”, so it’s not transport. What goes in the TS payloads? > On 26 Feb 2020, at 3:20, Michael Richardson wrote: > > >> Michael: Yoav talked about the non-GRE case. > > In the non-GRE case, then it's just IPIP-over-IPSEC-transport mode. > Which is

Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane)

Hi, Toerless. I trimmed below most of your background info. > On 24 Feb 2020, at 21:50, Toerless Eckert wrote: > > [hope its fine to cross-post ipsec and ipsecme given how one is concluded, > but may have > more long-time subscribers] ipsec is this group’s mailing list. I don’t know that

[IPsec] Publication has been requested for draft-ietf-ipsecme-ipv6-ipv4-codes-04

Yoav Nir has requested publication of draft-ietf-ipsecme-ipv6-ipv4-codes-04 as Proposed Standard on behalf of the IPSECME working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ipv6-ipv4-codes

Re: [IPsec] [Last-Call] Last Call: (Postquantum Preshared Keys for IKEv2) to Proposed Standard

Hi, Paul > On 11 Dec 2019, at 20:03, Paul Hoffman wrote: > > On 11 Dec 2019, at 8:23, Salz, Rich wrote: > >> We are seeing a flurry of these kind of “post quantum protection” things. > > This is the only one I have seen that is a method, not a new key exchange > algorithm. It is

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

I have read the -01 version of this draft. I believe it addresses a useful use case and that the solution presented there is a good starting point. I support its adoption. Yoav > On 26 Oct 2019, at 18:17, Tero Kivinen wrote: > > So this is fast (one week) adoption call for the >

Re: [IPsec] Éric Vyncke's Discuss on draft-ietf-ipsecme-implicit-iv-07: (with DISCUSS and COMMENT)

Hi, Éric. Please see inline. > On 11 Oct 2019, at 10:02, Éric Vyncke via Datatracker > wrote: > > Éric Vyncke has entered the following ballot position for > draft-ietf-ipsecme-implicit-iv-07: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses

[IPsec] Heads up: IDR meeting on Wednesday

Hi This may be of interest to IPsec folks. The IDR working group is meeting tomorrow and has several IPsec-related items on its agenda: Secure EVPN - where BGP is used instead of IKEv2 to key IPsec and distribute policy. BGP Signaled IPsec Tunnel Configuration - where IKEv2 is configured by

Re: [IPsec] [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt

ld > act in this situation to ensure that the consistence of the > network is preserved despite all the possible delays etc. > > Regards, > Valery. > > > From: Rafa Marin Lopez > Sent: Monday, July 22, 2019 6:11 PM > To: Valery Smyslov > Cc: Rafa Marin Lopez ; Yoav Nir ;

Re: [IPsec] [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt

Hi, Valery [no hats] Thanks for that. I think this demonstrates that the current document is not enough and we will need some follow-up documents explaining when to use either case. I don’t think it’s very useful for the controller to distribute a policy (SPD entries) but no SAs (SAD

Re: [IPsec] [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt

Thanks for getting this done and published. We will wait with requesting publication until the I2NSF session next week. Between now and then, please re-read the draft and send a message to the list is something is seriously wrong. Barring any such shouting, we will request publication right

Re: [IPsec] NO_PROPOSAL_CHOSEN vs INVALID_SYNTAX

In the days when I had an IKEv2 implementation, NO_PROPOSAL_CHOSEN was the go-to error code for everything the Responder didn’t like; wrong algorithms, wrong transforms (like transport instead of tunnel), unknown peer, INVALID_SYNTAX meant something like malformed packet. > On 20 Jun 2019, at

Re: [IPsec] On marking algorithms obsolete in IANA registries

Hi, Paul I think we need an RFC to at least categorize the algorithms, unless we want the IANA registry to have stuff like “SHOULD-“ and “MAY+: > On 18 Dec 2018, at 6:14, Paul Wouters wrote: > > > Recently we had a discussion about mapping IANA entries to a yang model, > and the question

Re: [IPsec] replacing PSKs: CFRG and PAKE

Hi, Valery > On 12 Dec 2018, at 11:02, Valery Smyslov wrote: > >>> I see this as a social issue, not a technical one. We can't prevent >>> administrators from being careless, either with PSKs or with passwords. >> >> We can make more secure deployments easier. >> >> If the only change on the

[IPsec] Heads Up: I2NSF Meeting Today

Hi all FYI: The I2NSF working group is meeting today immediately after IPsecME and in the same room (convenient!) We are going to spend some time on SDN-based IPsec Flow Protection [1]. We have had some discussion in the past about Case #2, which is about provisioning traffic keys (in the

Re: [IPsec] Yoav's Comments (was RE: Call for WG Adoptation for draft-boucadair-ipsecme-ipv6-ipv4-codes)

fy which "stuff" in 5739 you are referring to? > > The draft updates RFC7296 because it updates the behavior specified in > Section 3.15.4 of that RFC. > > Cheers, > Med > >> -Message d'origine- >> De : IPsec [mailto:ipsec-boun...@ietf.org] De la

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

I believe the final document should address the stuff in RFC 5739. Also, I’m not sure you need to update 7296 to add some new code points. Neither of these is a barrier for adoption. I have read the draft and support its adoption. Yoav > On 13 Oct 2018, at 3:09, Tero Kivinen wrote: > > Our

Re: [IPsec] [Technical Errata Reported] RFC7634 (5441)

This errata proposes to add the following sentence to section 4 of RFC 7634 : As with other transforms that use a fixed-length key, the Key Length attribute MUST NOT be specified. This sentence is correct. If this came up as a suggestion during WG

Re: [IPsec] Modp-12288 and Modp-16384

Hi. Since my message got lost in the overtime, I’ll say it again here. AFAIK there is very little usage of anything beyond 4096-bit groups. I don't sense a need for 16K. Engineering should be about creating what people need (or at least want). I haven’t heard anyone say they would like to

Re: [IPsec] Modp-12288 and Modp-16384

> On 18 Jul 2018, at 19:08, Graham Bartlett (grbartle) > wrote: > > Hi Tero > > I've no issues per se with this, but as per our chat in London, most VPN > consumers pick the group with the highest number (of course group24 is more > secure than group21, 24 is bigger than 21 ...!).. Hasn’t

Re: [IPsec] [I2nsf] How about simplified IKE? RE: IPsec Flow Protection @I2NSF

> On 17 Jul 2018, at 11:38, Rafa Marin-Lopez wrote: > Regarding the question about smart objects, I do not understand why a > constrained device cannot be a flow-based NSF. > I don’t think IOT devices are going to be NSFs. There is no hard definition for what a smart object is, but

Re: [IPsec] How about simplified IKE? RE: IPsec Flow Protection @I2NSF

ion? Issues? > > Linda Dunbar > >   <> > From: IPsec [mailto:ipsec-boun...@ietf.org <mailto:ipsec-boun...@ietf.org>] > On Behalf Of Yoav Nir > Sent: Monday, July 16, 2018 3:11 PM > To: IPsecME WG mailto:ipsec@ietf.org>> > Subject: [IPsec] IPsec Flow Prote

[IPsec] IPsec Flow Protection @I2NSF

Hi. I’d like to draw you attention to the agenda of the I2NSF working group: https://datatracker.ietf.org/meeting/102/materials/agenda-102-i2nsf-00 The I2NSF working group will meet on Wednesday after lunch. On the

Re: [IPsec] INITIAL_CONTACT in IKEv1

SA(SPI AA) —> NOT > DELETED When IC is received. > > For outgoing traffic from PEER-B, if SPI AA is chosen from SADB, will it NOT > get dropped at PEER-A with INVALID_SPI. > So does it not make sense to delete all IPSec SA’s when IC is received. > > Regards > Riyaz &

Re: [IPsec] INITIAL_CONTACT in IKEv1

> On 12 Jun 2018, at 11:53, riyaz talikoti wrote: > > Hi All, > Need help with couple of questions related to INITIAL_CONTACT in IKEv1 > > 1. Is it NOT wrong to send INITIAL_CONTACT notification in QUICK MODE? > Will it NOT end up in deleting the IKE SA(Phase 1 SA) which is being created > as

Re: [IPsec] Clarification on my comments during the WG about possible KE payloads > 64k

Hi, Scott. That was me. When they started talking about about PQC a decade ago, they mentioned algorithms like McEliece with public keys around 1MB. Not that this is a deal-killer. If necessary, we would come up with an IKE extension to have “jumbo-sized payloads” that had 24-bit lengths. IKE

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

> On 16 Feb 2018, at 21:09, Tero Kivinen <kivi...@iki.fi> wrote: > > Yoav Nir writes: >>> 2) The privacy of the initiator's identity in the presence of a man in >>> the middle attacker is not protected. >>> >>> Today an attacker with full c

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

> On 16 Feb 2018, at 20:13, Tero Kivinen wrote: > > This item does not have charter text yet, we do have text which > explains what the problem is, but I think it requires some > reformatting to fit as charter text. > > The problem description is: > >

Re: [IPsec] Additional charter items 3/4: Labeled IPsec

> On 16 Feb 2018, at 20:06, Tero Kivinen wrote: > > This charter text was not ready during the IETF 100, we just had very > short description about the item, and I think most of the people did > not really understand it. > > The proposed charter text for this item is: > >

Re: [IPsec] Candidate charter text is now in wiki

> On 9 Feb 2018, at 18:40, Paul Wouters wrote: > > On Wed, 7 Feb 2018, Tero Kivinen wrote: > >> It depends. If we do not take the item as official working group >> chartered item, there are still few different options. You can either >> get it processed as AD sponsored draft,

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

Sorry. Resending with the correct To: and CC: lists > On 31 Jan 2018, at 7:04, Yoav Nir <ynir.i...@gmail.com> wrote: > > Hi. > > I don’t see anything wrong with the suggestion (it’s just adding “to indicate > NONE” in the last sentence). However: > A value marked “R

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

Hi. I don’t see anything wrong with the suggestion (it’s just adding “to indicate NONE” in the last sentence). However: A value marked “Reserved” in IANA just means that IANA should not assign it. It does not mean that it cannot appear in the protocol. Using a zero in a field to indicate no

Re: [IPsec] Dynamic PMTUD over IKEv2

> On 23 Jan 2018, at 12:29, Shibu Piriyath wrote: > > Hi All, > > We have come up with a proposal for discovering Path MTU between IPsec > head-ends dynamically using IKEv2 messages. > Please review the draft - >

Re: [IPsec] Secdir last call review of draft-ietf-ipsecme-eddsa-04

> On 27 Nov 2017, at 16:09, Adam Montville wrote: > > Reviewer: Adam Montville > Review result: Ready > > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These >

Re: [IPsec] Proposal for using Implicit IV for IKE

Oh, and if you’re updating the draft anyway, you should update the references now that 8221 and 8247 have been published. Yoav > On 15 Nov 2017, at 10:30, Yoav Nir <ynir.i...@gmail.com> wrote: > > Hi, Daniel > > I think your text is confusing without the suggest

Re: [IPsec] Proposal for using Implicit IV for IKE

> so I presume we need to grab one of reserved bits in IKE header flags > > for this purpose. I admit it looks complicated, but I cannot come up > > with a simpler solution (except for not using IIV in IKEv2 at all). > > > > Regards, > > Valery

Re: [IPsec] Proposal for using Implicit IV for IKE

this case also. > > Regards, > Valery. > > From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Yoav Nir > Sent: Monday, November 13, 2017 5:35 AM > To: IPsecME WG > Subject: [IPsec] Proposal for using Implicit IV for IKE > > Hi. > > So following Daniel’s mes

Re: [IPsec] Proposal for using Implicit IV for IKE

| > Message ID (32 bits) | > > In that case I do prefer option 2 as it doesn't add much complexity and > allows fragmentation. > > David > > >> On Nov 13, 2017, at 10:51, Michael Richardson <mcr+i...@sandelman.ca> wrote: >> >> >> Yoav Nir <ynir.

[IPsec] Proposal for using Implicit IV for IKE

Hi. So following Daniel’s message in the room, here’s how I think we can make this work. The IKE header has a “Message ID” field that is a counter. It’s tempting to use this as a counter, same as we use the replay counter in IPsec. However, as Tero pointed out on Jabber, each such message ID

Re: [IPsec] Agenda for IETF 100

There used to be a special working group for multicast security. That has closed, so IPsecME is the natural home for this work: The Group Domain of Interpretation (GDOI - RFC 6407) is an IKEv1-based protocol for negotiating group keys for both multicast and unicast uses. The Working Group will

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

Hi, Paul > On 19 Sep 2017, at 1:31, Paul Wouters wrote: > > On Mon, 18 Sep 2017, Linda Dunbar wrote: > >> If we need to use IPsec tunnels to connect a group of CPE devices, (as shown >> in the figure I sent earlier), do you still need DNS? Or the Key >> management will be

[IPsec] Fwd: Call for adoption of draft-abad-i2nsf-sdn-ipsec-flow-protection

FYI Following the virtual interim earlier this month, we are now calling for adoption of the draft in I2NSF. All discussion of that draft should take place on the I2NSF list. Yoav > Begin forwarded message: > > From: Yoav Nir <ynir.i...@gmail.com> > Subject: Call for adop

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

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’

Re: [IPsec] Reminder: I2NSF virtual interim meeting

a host to > enter the code. > > Thank you, > Kathleen > > On Wed, Sep 6, 2017 at 9:58 AM, Yoav Nir <ynir.i...@gmail.com> wrote: >> Hi >> >> This is a reminder that the I2NSF virtual interim meeting will take >> place today/tonight in about two hours. >>

[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

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

[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

[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 Prague

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 <ynir.i...@gmail.com> wrote: > > Hi folks. > > This message is cross-posted to both the IPs

[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] 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

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

:34, Yaron Sheffer <yaronf.i...@gmail.com> 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 <kivi...@iki.fi> wrote: >> >> >>> This I think is important question, i.e

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

Re: [IPsec] IPsec and SDN

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

Re: [IPsec] IPsec and SDN

nst things like 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 <ynir.i...@gmail.com > <mailto:ynir.i...@gmail.com>> wrote: &

[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

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

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

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

> On 26 Apr 2017, at 0:15, Joe Touch <to...@isi.edu> 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 ha

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

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

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?

There might also be a firewall 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 >

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

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

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

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

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

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

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

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

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?

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

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

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

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:

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

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

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

> On 9 Dec 2016, at 23:43, Michael Richardson <mcr+i...@sandelman.ca> wrote: > > > Yoav Nir <ynir.i...@gmail.com> 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

  1   2   3   4   5   6   7   >