Re: [IPsec] New Version Notification for draft-pwouters-ikev1-ipsec-graveyard-00.txt
On Tue, 12 Mar 2019, Tommy Pauly wrote: Thanks for writing this up! Glad to get rid of IKEv1 =) We just need PPK and Labeled IPsec as RFC and then we are go :) I do have a question regarding whether the deprecations for the IKEv2 registry are appropriate for this document. RFC 8247 contains the recommendations for the which algorithms and DH groups are going away (SHOULD NOT, MUST NOT, etc), and it seems like an update to that document or similar would be more appropriate to discuss marking deprecation. I might have misunderstood Tero, but this what we said before: Paul: > I'm happy to write a separate diediedie document, but it would sort of Paul: > break the cycle of our IKE and ESP/AH document updates? Tero: Writing separate die-die-die document would be faster, and I do not Tero: think we have yet any pending changes for the algorithms we have in Tero: 8221 and 8247 waiting to be done. While it should update 8221/8247 (I'll add it for the next revision), I think Tero is right that this isn't the regular cycle of algorithm update using bis documents. It would be a bit overkill to already replace those two documents, especially because the "diff" would really not be very informative, because it would only show what are currently MAY algorithms that are not shown in 8221/8247 at all because they didn't change. And since we are not changing anything else, we wouldn't show anything else in the columns. So I think doing this "out of series" is a better solution. But I didn't instruct IANA to put [this document] in the ESP and IKEv2 reference columns for those algorithms, which we should do as well as adding the DEPRECATED column [insert Tero sitting at a table with "An extra column is wrong - CHANGE MY MIND"] poster. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] IETF 104 presentations
I am now setting up the agenda for IETF 104, so if you have any presentation etc you want to present there (and I have not yet sent email to you about it), send requests to us chairs as soon as possible (i.e., before the end of THIS week i.e., before 2019-03-15). -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux-02
This document has been stable for some time, and I think it is ready to go forward. Because of that I will start one week long WG adoptation call for this draft which will expire end of next week (2019-03-22). If you have any reasons why this should not be adopted as WG document, send email to the list as soon as possible. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] The IPSECME WG has placed draft-smyslov-ipsecme-ikev2-aux in state "Call For Adoption By WG Issued"
The IPSECME WG has placed draft-smyslov-ipsecme-ikev2-aux in state Call For Adoption By WG Issued (entered by Tero Kivinen) The document is available at https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-aux/ ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] New Version Notification for draft-pwouters-ikev1-ipsec-graveyard-00.txt
Thanks for writing this up! Glad to get rid of IKEv1 =) I do have a question regarding whether the deprecations for the IKEv2 registry are appropriate for this document. RFC 8247 contains the recommendations for the which algorithms and DH groups are going away (SHOULD NOT, MUST NOT, etc), and it seems like an update to that document or similar would be more appropriate to discuss marking deprecation. Best, Tommy > On Mar 11, 2019, at 11:39 AM, Paul Wouters wrote: > > > As we discussed on the list and in Bangkok, we were going to submit a > document to deprecrate IKEv1 and various old skool algorithms using > a [DEPRECATED] column in the IANA registry. > > I wrote a first draft to do this... > > Paul > > -- Forwarded message - > From: > Date: Mon, Mar 11, 2019 at 2:35 PM > Subject: New Version Notification for > draft-pwouters-ikev1-ipsec-graveyard-00.txt > To: Paul Wouters > > > > A new version of I-D, draft-pwouters-ikev1-ipsec-graveyard-00.txt > has been successfully submitted by Paul Wouters and posted to the > IETF repository. > > Name: draft-pwouters-ikev1-ipsec-graveyard > Revision: 00 > Title: Deprecation of IKEv1 and obsoleted algorithms > Document date: 2019-03-11 > Group: Individual Submission > Pages: 6 > URL: > https://www.ietf.org/internet-drafts/draft-pwouters-ikev1-ipsec-graveyard-00.txt > Status: > https://datatracker.ietf.org/doc/draft-pwouters-ikev1-ipsec-graveyard/ > Htmlized: > https://tools.ietf.org/html/draft-pwouters-ikev1-ipsec-graveyard-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-pwouters-ikev1-ipsec-graveyard > > > Abstract: >This document deprecates Internet Key Exchange version 1 (IKEv1) and >additionally deprecates a number of algorithms that are obsolete. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-hopps-ipsecme-iptfs-00.txt
> On Mar 12, 2019, at 10:39, Valery Smyslov wrote: > > Hi Chris, > >> There are other ways to skin this cat though. :) >> >> One option is that instead of sending a new CC info report on the interval >> timer expiry if we haven't received a >> response "ack" yet, we simply update the data (last seq num seen, drop count >> and timestamp) we sent >> previously to be current, keep the message ID the same and resend the >> message. Would changing the data in >> the message prior to resending be preferable? > > No, all retransmissions of IKE message with the same Message ID must be > binary identical. Perhaps we could relax this requirement for this particular message though. This seems like a simple tightly-focused semantic change which gets us past the roadblock. FWIW, regarding retransmission and message IDs, one thing I considered was not even using the message ID at all (e.g., let it be 0) but this seemed too radical as a first approach. :) If there really is no way to work around this, I suppose we just require retransmissions of CC info reports until they are ACKd or things are torn down b/c of drops (i.e., normal INFO exchange). It does feel like we are adding fragility here that isn’t really needed though. It makes the functioning of the unidirectional tunnel depend more heavily on the reverse direction traffic working when that isn’t actually needed for the tunnel to operate. Thanks, Chris. > > Regards, > Valery. > >> Thanks, >> Chris. > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-hopps-ipsecme-iptfs-00.txt
> On Mar 12, 2019, at 10:34, Valery Smyslov wrote: > > Hi Chris, > >> Sure, I'm definitely open to changes, and in particular with the congestion >> info report. This is just the first >> draft. :) >> >> So my reading of IKEv2 indicated that one way notifications were supported, >> not that they were *only* to be >> used for unprotected error notification though. Yes, they are currently only >> used for errors, but again I didn't >> read they were restricted to that use alone. > > No, unidirectional notifications cannot be used in regular IKE SAs. The > reason is that both peers must have common view > on the next Message ID to be used in each direction. If unidirectional > message with Message ID N is lost, its sender will never know > that > and think he can safely use Message ID N+1 for the next exchange, while the > receiver will discard N+1, since > N is not received yet (I assume for simplicity that IKE window size is 1). > This simply won't work. > > In current IKEv2 unidirectional messages are exceptions and can only be sent > unencrypted outside > any existing IKE SA. Ok. Perhaps we could look into extending their usefulness? >> The reason I did not want to make the report sending reliable is that they >> are continuously sent on an >> relatively short interval. It didn't make a lot of sense to be re-sending a >> possibly growing queue of reports >> repeatedly, when the latest one would do. > > Then send them over IPsec. Unfortunately this would require bi-directional tunnels, which we don’t want to require. More in the reply to the other email... Thanks, Chris. > > Regards, > Valery. > >> Thanks, >> Chris. >> >> >> >>> On Mar 11, 2019, at 11:43 AM, Valery Smyslov wrote: >>> >>> Hi, >>> We utilize a send only (i.e., no response expected) IKEv2 INFORMATIONAL exchange (37) to transmit the congestion information using a notification payload of type TFS_CONGEST_INFO (TBD). The The Response bit should be set to 0. As no response is expected the only payload should be the congestion information in the notification payload. This very much violates the state machine model of IKEv2, and I would not be in favour of this without strong arguments of why requiring a response (even if empty) is harmful. >>> >>> Strongly agree. Actually, one-way notifications are only defined >>> in IKEv2 for unprotected error notifications when no IKE SA exists >>> (like INVALID_IKE_SPI notifications). They simply don't work >>> for regular IKEv2 traffic. >>> >>> Regards, >>> Valery. >>> Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec >>> >>> ___ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> > > > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt
Hi Chris, > There are other ways to skin this cat though. :) > > One option is that instead of sending a new CC info report on the interval > timer expiry if we haven't received a > response "ack" yet, we simply update the data (last seq num seen, drop count > and timestamp) we sent > previously to be current, keep the message ID the same and resend the > message. Would changing the data in > the message prior to resending be preferable? No, all retransmissions of IKE message with the same Message ID must be binary identical. Regards, Valery. > Thanks, > Chris. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt
Hi Chris, > Sure, I'm definitely open to changes, and in particular with the congestion > info report. This is just the first > draft. :) > > So my reading of IKEv2 indicated that one way notifications were supported, > not that they were *only* to be > used for unprotected error notification though. Yes, they are currently only > used for errors, but again I didn't > read they were restricted to that use alone. No, unidirectional notifications cannot be used in regular IKE SAs. The reason is that both peers must have common view on the next Message ID to be used in each direction. If unidirectional message with Message ID N is lost, its sender will never know that and think he can safely use Message ID N+1 for the next exchange, while the receiver will discard N+1, since N is not received yet (I assume for simplicity that IKE window size is 1). This simply won't work. In current IKEv2 unidirectional messages are exceptions and can only be sent unencrypted outside any existing IKE SA. > The reason I did not want to make the report sending reliable is that they > are continuously sent on an > relatively short interval. It didn't make a lot of sense to be re-sending a > possibly growing queue of reports > repeatedly, when the latest one would do. Then send them over IPsec. Regards, Valery. > Thanks, > Chris. > > > > > On Mar 11, 2019, at 11:43 AM, Valery Smyslov wrote: > > > > Hi, > > > >>We utilize a send only (i.e., no response expected) IKEv2 > >>INFORMATIONAL exchange (37) to transmit the congestion information > >>using a notification payload of type TFS_CONGEST_INFO (TBD). The The > >>Response bit should be set to 0. As no response is expected the only > >>payload should be the congestion information in the notification > >>payload. > >> > >> This very much violates the state machine model of IKEv2, and I would > >> not be in favour of this without strong arguments of why requiring a > >> response (even if empty) is harmful. > > > > Strongly agree. Actually, one-way notifications are only defined > > in IKEv2 for unprotected error notifications when no IKE SA exists > > (like INVALID_IKE_SPI notifications). They simply don't work > > for regular IKEv2 traffic. > > > > Regards, > > Valery. > > > >> Paul > >> > >> ___ > >> IPsec mailing list > >> IPsec@ietf.org > >> https://www.ietf.org/mailman/listinfo/ipsec > > > > ___ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
