[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 > Subject: Call for adoption of draft-abad-i2nsf-sd

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 managed by the "Zero

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

[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] Proposal for using Implicit IV for IKE

gt; > 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 wrote: >> >> >> Yoav Nir wrote: >>> Proposal #1: >>> ==

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

gt; 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 message in the room, here’s how

Re: [IPsec] Proposal for using Implicit IV for 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. > > > > > > From: Yoav Nir [mailto:ynir.i..

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 wrote: > > Hi, Daniel > > I think your text is confusing without the suggestion to use Message ID as a > nonc

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 > comments were written primarily for

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 - > https://tools.ietf.org/html/draft-spiriyath-ipsecme-dynamic-ipsec-pmtu-00 >

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 valu

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 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 “Reserved” in IANA just means

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, or you can go ind

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] 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 4/4: Mitigating privacy concerns

> On 16 Feb 2018, at 21:09, Tero Kivinen 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 control of the

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 o

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

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

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

opinion? 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 P

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 som

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

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

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

hich "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]

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

Re: [IPsec] [I2nsf] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03

> On 20 Nov 2018, at 17:14, Paul Wouters wrote: > > On Mon, 19 Nov 2018, Rafa Marin Lopez wrote: > >>> Based on the introduction and abstract of the draft, this document does two >>> things: >>> >>> 1) Specify a yang model for use with SDWAN + IKE + IPsec >>> 2) Define the desired modes and

Re: [IPsec] [I2nsf] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 (Section 1)

A couple of remarks (with no hats) If we’re bikeshedding the names, I think the difference is that in one case the two NSFs generate traffic keys between themselves, and in the other it is the controller that generates the keys for them. So how about “distributed keying” vs “centralized keying

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 s

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 came

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

> On 18 Dec 2018, at 17:19, Paul Wouters wrote: > > On Tue, 18 Dec 2018, paul.kon...@dell.com wrote: > >>> Well, I think it's a bit too complex for random implementer. >>> I'd prefer to classify all algorithms as follows: >>> >>> 1. Secure, required for interoperability >>> 2. Secure, not requ

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

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 entries)

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

uld > 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 ;

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

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

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 > draft-hopps-

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 understandabl

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 ther

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 lit

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

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

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 18:42,

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 wrote:

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

[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 https://www.ietf.org/mailman/listi

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

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] 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] multiple windows need multiple SPIs

> On 4 Aug 2020, at 2:34, William Allen Simpson > wrote: > > On 8/3/20 4:17 AM, Michael Rossberg wrote: >> Unfortunately I develop systems for a customer who uses DS for some (maybe >> non-technical) >> reason. > > Helpful to not use abbreviations. DS = storage Data Servers? AWS Directory

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 (MUST/SHO

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 https://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-paramet

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

s 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

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

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

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

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 sti

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

[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 https://www.ietf.org/mailman/list

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

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 l

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 c

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 perhaps n

[IPsec] The ESP Echo Protocol document for IPsecME

Hi, folks At IETF 119, Jen Likova presented [1] the ESP Echo Protocol draft [2]. The conversation in the room was lively, but did not look like the kind of consensus that we just confirm on the list. So rather than starting an adoption call now, we’d like to encourage people to discuss it on t

[IPsec] Issue #199 - Section 7.4 is mostly wrong

Hi all This issue is about some of the wording of section 7.4. I don't agree that this is mostly wrong, but I think the group's energies are better spent elsewhere. Section 7, in its entirety is about alternative solutions that were not adopted. I think we can either delete the whole section, o

[IPsec] QCD applicability (issues #198 and #201)

Hi all An issue that has come up on this mailing list, and also in Beijing, is what implementations should assume either of the two roles (token maker and token taker). The current text is in section 9.1, and is summarized as follows: o For remote-access clients it makes sense to implement

Re: [IPsec] Question about DH retry for IKEv2

Hi Gaurav. In IKEv2, we don't call them cookies any more, but IKE SPIs. Since you're initiating, you start with just the initiator IKE SPI (not a pair), and the message ID for the first message is zero, not 1. IKE SA INIT messages always have message ID zero. I would bet that many implementati

[IPsec] Failure Detection - Issue #200

Hi all. Issue #200 is about some text in section 8 ("Interaction with Session Resumption"). The text says that a rebooted peer (and thus a defunct SA) may go undetected for the lifetime of the SA. However, RFC 5996 says that at some point, a peer that did not receive incoming traffic on a part

Re: [IPsec] Failure Detection - Issue #200

Reminder... On Dec 26, 2010, at 11:38 AM, Yoav Nir wrote: > Hi all. > > Issue #200 is about some text in section 8 ("Interaction with Session > Resumption"). The text says that a rebooted peer (and thus a defunct SA) may > go undetected for the lifetime of the SA. Ho

[IPsec] Issue #202: Token makers generating the same tokens without synchronized DB

Greetings. We have just submitted version -03 of the draft. This closes issues, #198, #199, #200, and #201. Which leaves us with just one issue: #202 = Issue #202: Token makers generating the same tokens without synchronized DB Section 10.4 of the draft has a use-case where a cluster

Re: [IPsec] Question about TS construction on IKEv2 initiator

Hi Gaurav There's a 1-octet field called "Number of TSs", so there can be at most 255 traffic selectors for each of initiator and responder. And yes, as many selectors are allowed as you need to describe your policy. In practice, some implementations can't handle complex policies, and require

Re: [IPsec] IPsec on ubuntu linux server 8.04

Hi Kaushal. This mailing list is about the IKE and IPsec protocols, not some particular implementation. IIRC on Ubuntu you can install either StrongSwan or racoon, with StrongSwan being the default on recent versions. I suggest you seek support either at the StrongSwan site ( http://www.stron

Re: [IPsec] IKEv2 Diffie Hellman retry logic

1. Yes 2. No. In that case, the correct response in NO PROPOSAL CHOSEN. 3. That is not correct processing. First the responder should match the SA payload to its own policy. If a match it found, the responder can compare the DH group in the matched proposal to the one in the KE payload Th

Re: [IPsec] draft-welter-ipsecme-ikev2-reauth-02

Hi Keith. Generally, the process goes something like this: - You write a draft (done!) - You present it on the mailing list (done!) - Usually, you ask for a time slot to present at a face-to-face meeting (not mandatory, but helps). The best is if you present it yourself, but if you don't plan to

Re: [IPsec] WG Last Call on draft-ietf-ipsecme-failure-detection

I'd like to also point out that Scott and Keith have pointed out some nits in the spec (on the 12th and 19th of January respectively), which will also be included in the final version. Yoav On Jan 27, 2011, at 6:42 PM, Paul Hoffman wrote: > This message closed out the WG LC. There remains one

Re: [IPsec] WG Last Call on draft-ietf-ipsecme-failure-detection

Hi Keith. Thanks for the comments. My responses inline. On Jan 19, 2011, at 2:36 AM, Keith Welter wrote: 1. The last paragraph of section 2 seems to be making an argument against supporting QCD. Would it be possible to add a counterpoint or to reword the paragraph? When I got to the end of

Re: [IPsec] I-D Action:draft-ietf-ipsecme-failure-detection-03.txt

Hi Scott. Thanks for your comments. My replies inline. On Jan 12, 2011, at 10:45 PM, Scott C Moonen wrote: Comments on the draft, mostly editorial in nature: (1) There are still some blockquotes that start with excessive first-line indents, eg., the three quotes on page 5. Those are intentio

Re: [IPsec] I-D Action:draft-ietf-ipsecme-failure-detection-03.txt

On Jan 30, 2011, at 10:00 AM, Yoav Nir wrote: (13) Page 8, the last line is an orphan. Not sure what you mean. It says "In any case, the lack of a QCD_TOKEN notification MUST NOT be taken" and then continues on the next page. OK. Now that Yaron has helped me figure out what an &

[IPsec] Failure Detection - issue #202

Hi all. Following last week's conf call, Scott Moonen has proposed text to resolve issue #202. The idea is to remove section 9.4 entirely, and change section 9.2 as follows: OLD: 9.2. QCD Token Transmission A token maker MUST NOT send a QCD token in an unprotected message for an exist

[IPsec] Fwd: Failure Detection - issue #202

Adding the IPsec list. Begin forwarded message: From: Frederic Detienne mailto:f...@cisco.com>> Date: February 1, 2011 9:37:33 PM GMT+02:00 To: Paul Hoffman mailto:paul.hoff...@vpnc.org>> Cc: Yoav Nir mailto:y...@checkpoint.com>>, Pratima Sethi mailto:pse...@cisco.co

Re: [IPsec] I-D Action:draft-ietf-ipsecme-ipsecha-protocol-03.txt

Hi Yaron I think this addresses the issues well. However, there is one more thing. Section 3 is currently in skeleton form and needs to be expanded a lot. For example, RFC 6027 says the following: o It requires multiple parallel SAs, for which the peer has no use. Section 2.8 of [RFC59

Re: [IPsec] Failure Detection - issue #202

w draft. Thanks for all the work done so far! > > --Paul Hoffman On Feb 11, 2011, at 11:54 AM, IETF I-D Submission Tool wrote: > > A new version of I-D, draft-ietf-ipsecme-failure-detection-04.txt has been > successfully submitted by Yoav Nir and posted to the IETF reposito

[IPsec] Putting issue #202 to rest

Hi all. Last week, I submitted version -05 of the failure detection draft. The last two versions both revolved around rewriting section 9.2 I hope this version is something all of us can live with. If I don't get any objections by this week-end, I will close issue #202, and ask Paul & Yaron to

[IPsec] HOKEY draft draft-ietf-hokey-rfc5296bis

Hi all I have just read the subject draft, and found this in section 6 (and similar text in the introduction): Note that to support ERP, lower-layer specifications may need to be revised. Specifically, the IEEE802.1x specification must be revised to allow carrying EAP messages of the n

Re: [IPsec] HOKEY draft draft-ietf-hokey-rfc5296bis

On Mar 6, 2011, at 11:25 AM, Yoav Nir wrote: > > There's peer-initiated ERP (which would require peer-initiated IKE?) and > multiple simultaneous operations. I think it may come to a somewhat larger > draft. Sorry. peer=remote access client, so peer-initiated IKE is th

[IPsec] SHA-512/256

Hi all RFC 4868 specifies some HMAC-SHA2 algorithms for IPsec: 12AUTH_HMAC_SHA2_256_128 [RFC4868] 13AUTH_HMAC_SHA2_384_192 [RFC4868] 14AUTH_HMAC_SHA2_512_256 [RFC4868] Last year some researchers working for Intel published

Re: [IPsec] HOKEY draft draft-ietf-hokey-rfc5296bis

On Mar 7, 2011, at 5:58 PM, Tero Kivinen wrote: > Yoav Nir writes: >> A bigger problem is that this text says that IKEv2 needs to be >> updated, but there is no draft for this update, nor has there been >> any message to this list about this proposed change. >>

Re: [IPsec] New Version Notification for draft-kivinen-ipsecme-ikev2-minimal-00

I also agree that this draft is useful, and I support its going forward, either as a WG document or as an individual document. While data communications may originate from either side (sensor notifies controller, controller queries sensor, controller sends command to actuator), I think it is r

Re: [IPsec] I-D Action:draft-ietf-ipsecme-failure-detection-06.txt

Hi all. This version includes remarks by Magnus Nyström. To see the differences, follow this link: http://tools.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-failure-detection-06 Yoav On Mar 10, 2011, at 10:15 PM, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > di

Re: [IPsec] New Version Notification for draft-kivinen-ipsecme-ikev2-minimal-00

Hi Tero. IKEv2 has an underlying assumption that peers are always available to respond (for example to liveness check). If you're doing a special profile for minimal implementation that are not always available (because they're in a low-power mode), you should also profile the server that talks

[IPsec] PSK with IKEv2

Hi all Yesterday, the IESG has started last call on three documents: - draft-harkins-ipsecme-spsk-auth-03 - draft-shin-augmented-pake-03 - draft-kuegler-ipsecme-pace-ikev2-05 All three seek to improve the authentication in IKEv2 when using pre-shared keys, as compared with RFC 5996. The IPsecME

Re: [IPsec] Proposal for the secure password authentication method problem

On Apr 12, 2011, at 3:17 PM, Tero Kivinen wrote: > This kind of framework would allow using any of the secure password > authentication methods in a way where they can co-exist in the same > implementation. If the implementation is done properly, then it might > be even possible to make it so that

[IPsec] New I-D: draft-nir-ipsecme-erx-00

Hi. Qin and I have just posted the subject draft. The title is "An IKEv2 Extension for Supporting ERP", although it has nothing to do with enterprise resource planning. This draft brings the ERP extension for EAP, which is developed by the Hokey group into the IKEv2 authentication exchange, a

Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00

On May 2, 2011, at 11:54 PM, Yaron Sheffer wrote: > [Responding to IPsec only:] > > Hi Yoav, > > thanks for the new draft. I'm afraid one needs to read RFC5296bis before > commenting, but here's a few questions anyway: > > - Sending the domain in the IKE_SA_INIT response obviously contradicts

Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00

On May 4, 2011, at 4:50 AM, Qin Wu wrote: >>> - I am missing the "authenticated peer identity", which I would assume >>> should arrive from the AAA server. This should be the basis of RFC4301 >>> policy decisions on the IKE gateway. Does ERP provide this identity? >> >> The EAP-Initiate/Re-aut

Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00

On May 4, 2011, at 9:18 AM, Qin Wu wrote: > Hi, > - Original Message - > From: "Yoav Nir" > To: "Qin Wu" > Cc: > Sent: Wednesday, May 04, 2011 1:30 PM > Subject: Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00 > > >> >>

  1   2   3   4   5   6   7   8   9   >