Re: [IPsec] WG Adoption call for draft-mglt-ipsecme-ikev2-diet-esp-extension
I agree that this should be adopted by the workgroup. I am already designing its use in UAS communications. On 11/27/23 13:35, Tero Kivinen wrote: This is two week adoption call for draft-mglt-ipsecme-ikev2-diet-esp-extension. If you support adopting this document as a working group document for IPsecME to work on, and then at some point publish this as an RFC, send comments to this list. This adoption call ends 2023-12-13. Note, that I do want to see people saying that they think this document is worth of working on, and that they plan to review and comment on it. If I only get one or two people (including authors :-) to say they support this work, then there is no point of work on this in WG. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-antony-ipsecme-beet-mode-00.txt
The original drafts were trying to do this for IPsec and HIP. But in '08, IPsec said no. So the anything related to IKE was dropped. Good that you are picking this up. I included Ari as I think he is the only one here that was involved with this effort (besides me). As you are looking at perhaps really making a BEET-bis, we are going to have to look at how this affects HIP's use. On 11/8/23 15:43, Antony Antony wrote: Thanks, Bob, for pointing this out! I overlooked the Appendix where BEET mode was defined, so I really appreciate the heads-up. I noticed we still need to get an IKEv2 notifier to use BEET mode with IKEv2. This draft will focus on that and refer to RFC 7402 for the BEET mode ESP protocol specifications. -antony On Mon, Nov 06, 2023 at 05:45:44AM -0500, Robert Moskowitz wrote: I should point out that BEET mode is defined in rfc 7402 This is the basis for the BEET code in the Linux kernel. It should incorporate everything in Pekka's older drafts. Note that I am a co-author of 7402, but the Ericsson team did all the heavy lifting. As defined in 7402 it is used in a few products. Some implementations, I have been told, are in US military use. Bob On 10/27/23 06:17, Antony Antony wrote: Hi, We've submitted a draft proposal to revive and standardize IPsec BEET mode, which is widely used but had its previous ID expire in 2009. This proposal also includes a suggestion for introducing IKE Notification for negotiation purposes. We'd appreciate your feedback on this ID. If you're aware of any more use cases for BEET mode, please share them. I would like to add a few more to the ID. The original ID emphasized mobility as use case, and we're considering whether to keep those aspects in the new proposal. If you use or likely to use BEET mode with mobility please share your thoughts. I'll be discussing these points at the upcoming IETF 118 meeting in Prague. -antony On Mon, Oct 23, 2023 at 09:08:05AM -0700, internet-dra...@ietf.org wrote: Internet-Draft draft-antony-ipsecme-beet-mode-00.txt is now available. Title: A Bound End-to-End Tunnel (BEET) mode for ESP Authors: Antony Antony Steffen Klassert Name:draft-antony-ipsecme-beet-mode-00.txt Pages: 21 Dates: 2023-10-23 Abstract: This document specifies a new mode for IPsec ESP, known as Bound End- to-End Tunnel (BEET) mode. This mode complements the existing ESP tunnel and transport modes, while enhancing end-to-end IPsec usage. It offers the characteristics of the tunnel mode but without its usual overhead. The BEET mode is designed to accommodate evolving applications of ESP, such as minimalist end-to-end tunnel, mobility and multi-address multi-homing. Additionally, this document proposes a new Notify Message, USE_BEET_MODE, for the Internet Key Exchange Protocol Version 2 (IKEv2) specified in [RFC7296], to facilitate BEET mode Security Association negotiation. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-antony-ipsecme-beet-mode/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-antony-ipsecme-beet-mode-00.html Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ 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] I-D Action: draft-antony-ipsecme-beet-mode-00.txt
I should point out that BEET mode is defined in rfc 7402 This is the basis for the BEET code in the Linux kernel. It should incorporate everything in Pekka's older drafts. Note that I am a co-author of 7402, but the Ericsson team did all the heavy lifting. As defined in 7402 it is used in a few products. Some implementations, I have been told, are in US military use. Bob On 10/27/23 06:17, Antony Antony wrote: Hi, We've submitted a draft proposal to revive and standardize IPsec BEET mode, which is widely used but had its previous ID expire in 2009. This proposal also includes a suggestion for introducing IKE Notification for negotiation purposes. We'd appreciate your feedback on this ID. If you're aware of any more use cases for BEET mode, please share them. I would like to add a few more to the ID. The original ID emphasized mobility as use case, and we're considering whether to keep those aspects in the new proposal. If you use or likely to use BEET mode with mobility please share your thoughts. I'll be discussing these points at the upcoming IETF 118 meeting in Prague. -antony On Mon, Oct 23, 2023 at 09:08:05AM -0700, internet-dra...@ietf.org wrote: Internet-Draft draft-antony-ipsecme-beet-mode-00.txt is now available. Title: A Bound End-to-End Tunnel (BEET) mode for ESP Authors: Antony Antony Steffen Klassert Name:draft-antony-ipsecme-beet-mode-00.txt Pages: 21 Dates: 2023-10-23 Abstract: This document specifies a new mode for IPsec ESP, known as Bound End- to-End Tunnel (BEET) mode. This mode complements the existing ESP tunnel and transport modes, while enhancing end-to-end IPsec usage. It offers the characteristics of the tunnel mode but without its usual overhead. The BEET mode is designed to accommodate evolving applications of ESP, such as minimalist end-to-end tunnel, mobility and multi-address multi-homing. Additionally, this document proposes a new Notify Message, USE_BEET_MODE, for the Internet Key Exchange Protocol Version 2 (IKEv2) specified in [RFC7296], to facilitate BEET mode Security Association negotiation. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-antony-ipsecme-beet-mode/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-antony-ipsecme-beet-mode-00.html Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ 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] Virtual interim about re-designing ESP?
I want to add support of constrained communications and taking diet-esp to the next step as we work in lpwan with SCHC as a protocol. The low byte overhead of DTLS makes it very attractive in constrained communications. How can we best pair SCHC with ESP for efficient use of limited resources. Also how to negotiate SCHC rules between parties. In the lpwan session we discussed secure channel for SCHC rule negotiation. ike-diet-esp is a great starting point with the potential challenges. Does this happen in IPsecme or lpwan? How to coordinate? A should also point out that SCHC provides ARQ and we are planning on adding FEC. This should be transparent to ESP, but is there any considerations for improved transmission reliablity? Bob On 11/22/22 13:29, Michael Richardson wrote: Steffen Klassert wrote: > at the last working group meeting in London, it was quite some interest > to work on a re-design of ESP to make it fit to the multi-cpu case, QoS > classes, HW offloads etc. I agree with your idea in the subject, of a virtual interim on this. > https://www.ietf.org/archive/id/draft-ponchon-ipsecme-anti-replay-subspaces-00.txt While there is a problem space section in this document, I found it a bit inadequate. I think that it is important to collect all of the challenges into a single set of goals. > The Google PSP Security Protocol (PSP) is another new 'ESP like' > protocol. There is some interest to standardize PSP, so the issues that > are solved there should also be considered when designing a new ESP > version. Most concepts that are used in PSP are taken from IPsec ESP, > so IMO this should be integrated into the IPsec protocol suite. It would be great to have the problems/challenges that this aims to solve, as well as the RAVSI concepts there too. > - What are the problems to solve? Let's get consensus on this aspect first. Maybe there are things that we might agree are out-of-scope, or are really implementation specific issues. That might mean a document be written, and the WG do a consensus call. > - How should the problems be solved? > Please let me know if there is interest, Thank you for bringing this up. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide ___ 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] [saag] AD review of draft-moskowitz-ipsecme-ipseckey-eddsa-02
On 11/7/22 09:07, Tero Kivinen wrote: Robert Moskowitz writes: Value Description Format description Reference 0 No key is present[RFC4025] 1 A DSA Public Key [RFC2536] Section 2 [RFC4025] 2 A RSA Public Key [RFC3110] Section 2 [RFC4025] 3 An ECDSA Public Key [RFC6605] Section 4 [RFC4025] TBD1 An EdDSA Public Key [RFC8080] Section 3 [ThisRFC] Adding the section numbers would be useful, as those documents define both DNSKEY and RRSIG resource records, so pointing to one of them helps. I like this second way. Does including the sec occur in any other registries? We will have to ask IANA; it does make sense as you say in this specific case. Yes. For example IKEv2 Transform Type 4 registry has section numbers for Recipient Tests: https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-8 We would need to get IANA signoff on this, IMO. With this presedent, I will follow what is in this registry, e.g.: [RFC6989], Sec. 2.1 Bob ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [saag] AD review of draft-moskowitz-ipsecme-ipseckey-eddsa-02
On 11/7/22 06:30, Tero Kivinen wrote: Robert Moskowitz writes: Value Description 1A DSA Public Key is present, in the format defined in [RFC2536] 2A RSA Public Key is present, in the format defined in [RFC3110] 3An ECDSA Public Key is present, in the format defined in [RFC6605] I can remove the reference column? It seems this is always called for. So either we accept the build errors that still result in a usable draft, or we make these entries two lines like: How about we cut the "is present" text. I do not think it gives any useful information. I mean if there is key in format defined in some rfc in this RR, then yes, the key is present, we do not need to repeat that. 0No key is present 1A DSA Public Key in the format defined in [RFC2536] 2A RSA Public Key in the format defined in [RFC3110] 3An ECDSA Public Key in the format defined in [RFC6605] Or we could even split the reference and format in different columns: Value Description Format description Reference 0 No key is present[RFC4025] 1 A DSA Public Key [RFC2536] Section 2 [RFC4025] 2 A RSA Public Key [RFC3110] Section 2 [RFC4025] 3 An ECDSA Public Key [RFC6605] Section 4 [RFC4025] TBD1 An EdDSA Public Key [RFC8080] Section 3 [ThisRFC] Adding the section numbers would be useful, as those documents define both DNSKEY and RRSIG resource records, so pointing to one of them helps. I like this second way. Does including the sec occur in any other registries? We will have to ask IANA; it does make sense as you say in this specific case. We would need to get IANA signoff on this, IMO. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Revising diet ESP to be SCHC compliant
We have discussed this on the list in the past, and it is past time, IMHO, to tackle this. First over in INTAREA there is workgroup adoption call for: draft-moskowitz-intarea-schc-ip-protocol-number This will assign an Internet Protocol Number to SCHC so it can be used E2E, acting on the layer that is typically the IPv4 Protocol or IPv6 Next Header. I.E., in this case, ESP. This can be used outside ESP, or inside ESP for tunnel mode. Though it may be that the endpoints are using SCHC themselves! Anyway, I am interested in working on updating diet-esp. I also think that ike-diet-esp will need updates as well, but that I can only provide comments. Bob ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-moskowitz-ipsecme-ipseckey-eddsa-01.txt
On 8/11/22 07:35, Tero Kivinen wrote: Robert Moskowitz writes: So I think the correct example should be: foo.example.com IN IPSECKEY (10 0 4 . 3WTXgUvpn1RlCXnm80gGY2LZ/ErUUEZtZ33IDi8yfhM= ) I will fix my example. Do you think I should have both examples: with and without gateway? More examples is usually better as long as they are correct :-) If you want more, then send them my way. Current IANA registry is: 0 No key is present [RFC4025] 1 A DSA key is present, in the format defined in [RFC2536] [RFC4025] 2 A RSA key is present, in the format defined in [RFC3110] [RFC4025] 3 An ECDSA key is present, in the format defined in [RFC6605] [RFC8005] Per Paul's request I am coming up that for EdDSA I would ask the following be added: 4 An EdDSA Public key is present, in the format defined in [RFC8080] [This] Note the addition of "Public" • So should 1 - 3 also have "Public" added? • Should 4 NOT have "Public" • Should text be added describing this registry to be for "Public" keys? The current wording is bit funny, but I think that it is talking about the host properties. I.e. the host having this IPSECKEY RR do have DSA key (both public and private keys), and the public key of that DSA key is given inside the IPSECKEY RR in format defined in RFC2536. My read of it. Perhaps the best wording would be 3 An ECDSA Public key in the format defined in [RFC6605] Whether we want to change the other entries to match is then separate issue, and as this registry is IETF Review, I think we need and draft or similar to change the wording. I.e., if we want to change the wording of other entries, then we could request that change in this document too. If this is the way you want it, as you are the IPsec IANA registries expert... Help me with the text, and when this draft is adopted by the workgroup I will put it into the draft-ietf-ipsecme- release. Then the wg can bash on it a bit during wglc. Bob ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Fwd: New Version Notification for draft-moskowitz-ipsecme-ipseckey-eddsa-02.txt
Here is the latest revision. Should this draft be adopted by the workgroup for 'proper' document advancing? thanks Bob Forwarded Message Subject: New Version Notification for draft-moskowitz-ipsecme-ipseckey-eddsa-02.txt Date: Wed, 10 Aug 2022 14:45:05 -0700 From: internet-dra...@ietf.org To: Robert Moskowitz , Tero Kivinen A new version of I-D, draft-moskowitz-ipsecme-ipseckey-eddsa-02.txt has been successfully submitted by Robert Moskowitz and posted to the IETF repository. Name: draft-moskowitz-ipsecme-ipseckey-eddsa Revision: 02 Title: EdDSA value for IPSECKEY Document date: 2022-08-10 Group: Individual Submission Pages: 4 URL: https://www.ietf.org/archive/id/draft-moskowitz-ipsecme-ipseckey-eddsa-02.txt Status: https://datatracker.ietf.org/doc/draft-moskowitz-ipsecme-ipseckey-eddsa/ Html: https://www.ietf.org/archive/id/draft-moskowitz-ipsecme-ipseckey-eddsa-02.html Htmlized: https://datatracker.ietf.org/doc/html/draft-moskowitz-ipsecme-ipseckey-eddsa Diff: https://www.ietf.org/rfcdiff?url2=draft-moskowitz-ipsecme-ipseckey-eddsa-02 Abstract: This document assigns a value for EdDSA Public Keys to the IPSECKEY IANA registry. The IETF Secretariat ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-moskowitz-ipsecme-ipseckey-eddsa-01.txt
On 8/10/22 16:45, Paul Wouters wrote: On Aug 10, 2022, at 16:07, Robert Moskowitz wrote: On 8/10/22 16:04, Paul Wouters wrote: Robert Moskowitz wrote: I think I could have the IANA Considerations have a fix for 1 - 3 as well as add 4. Please do. I talked to IANA and they agreed this was the easiest solution. Should it be: * public key * Public key * Public Key My preference is Public Key but I don’t feel strongly at all - either of these are fine for me. It is all about is it a Proper Noun or not. Well, in the end, it will be up to the RFC Editor! :) Here goes: Looks good, thanks ! Paul 4.1. IANA IPSECKEY Registry Update This document requests IANA to clarify the text in the "Algorithm Type Field" subregistry of the "IPSECKEY Resource Record Parameters" [IANA-IPSECKEY] registry to explicitly state this is for "Public" keys: Value Description Reference 1 A DSA Public key is present, in the format defined in [RFC2536] [RFC4025] 2 A RSA Public key is present, in the format defined in [RFC3110] [RFC4025] 3 An ECDSA Public key is present, in the format defined in [RFC6605] [RFC8005] Futher, this document requests IANA to make the following addition to the "IPSECKEY Resource Record Parameters" [IANA-IPSECKEY] registry: IPSECKEY: This document defines the new IPSECKEY value TBD1 (suggested: 4) (Section 3) in the "Algorithm Type Field" subregistry of the "IPSECKEY Resource Record Parameters" registry. Value Description Reference TBD1 (suggested value 4) [This] An EdDSA Public key is present, in the format defined in [RFC8080] == ___ 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: New Version Notification for draft-moskowitz-ipsecme-ipseckey-eddsa-01.txt
On 8/10/22 16:04, Paul Wouters wrote: Robert Moskowitz wrote: I think I could have the IANA Considerations have a fix for 1 - 3 as well as add 4. Please do. I talked to IANA and they agreed this was the easiest solution. Should it be: * public key * Public key * Public Key ?? Here goes: 4.1. IANA IPSECKEY Registry Update This document requests IANA to clarify the text in the "Algorithm Type Field" subregistry of the "IPSECKEY Resource Record Parameters" [IANA-IPSECKEY] registry to explicitly state this is for "Public" keys: Value Description Reference 1 A DSA Public key is present, in the format defined in [RFC2536] [RFC4025] 2 A RSA Public key is present, in the format defined in [RFC3110] [RFC4025] 3 An ECDSA Public key is present, in the format defined in [RFC6605] [RFC8005] Futher, this document requests IANA to make the following addition to the "IPSECKEY Resource Record Parameters" [IANA-IPSECKEY] registry: IPSECKEY: This document defines the new IPSECKEY value TBD1 (suggested: 4) (Section 3) in the "Algorithm Type Field" subregistry of the "IPSECKEY Resource Record Parameters" registry. Value Description Reference TBD1 (suggested value 4) [This] An EdDSA Public key is present, in the format defined in [RFC8080] ==___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-moskowitz-ipsecme-ipseckey-eddsa-01.txt
Paul, On 8/10/22 11:09, Paul Wouters wrote: On Aug 10, 2022, at 10:30, Robert Moskowitz wrote: I will fix my example. Do you think I should have both examples: with and without gateway? No. First because you are not tunneling and it doesn’t apply to you and second because it can only be set for IPSECKEY records in the reverse zones, not in any forward zones. Current IANA registry is: 0 No key is present [RFC4025] 1 A DSA key is present, in the format defined in [RFC2536] [RFC4025] 2 A RSA key is present, in the format defined in [RFC3110] [RFC4025] 3 An ECDSA key is present, in the format defined in [RFC6605] [RFC8005] Per Paul's request I am coming up that for EdDSA I would ask the following be added: 4 An EdDSA Public key is present, in the format defined in [RFC8080] [This] Note the addition of "Public" * So should 1 - 3 also have "Public" added? * Should 4 NOT have "Public" * Should text be added describing this registry to be for "Public" keys? I think it should have public and an errata could be filed for 1-3 ? Or we can draft a separate draft for encoding algo 14 (digital signatures) that also fixes up these entries ? Or this draft could fix them ? Maybe the chairs or AD could give guidance here I think I could have the IANA Considerations have a fix for 1 - 3 as well as add 4. I will work something up and share it here.. Thanks Bob! 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
Re: [IPsec] Fwd: New Version Notification for draft-moskowitz-ipsecme-ipseckey-eddsa-01.txt
Tero, Thanks for the review. On 8/9/22 11:46, Tero Kivinen wrote: Robert Moskowitz writes: This latest ver is in response to comments recieved. Please review Appendix A that I have the RR properly set up. I think the priority needs to be in decimal, and you are missing the gateway address. I.e., at least the 4025 has examples as follows: 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 192.0.2.38 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) where you have: foo.example.com IN IPSECKEY (a 0 4 3WTXgUvpn1RlCXnm80gGY2LZ/ErUUEZtZ33IDi8yfhM= ) The generic format from 4025 is: IN IPSECKEY ( precedence gateway-type algorithm gateway base64-encoded-public-key ) and also says: If no gateway is to be indicated, then the gateway type field MUST be zero, and the gateway field MUST be "." I missed that in my read of 4025. So I think the correct example should be: foo.example.com IN IPSECKEY (10 0 4 . 3WTXgUvpn1RlCXnm80gGY2LZ/ErUUEZtZ33IDi8yfhM= ) I will fix my example. Do you think I should have both examples: with and without gateway? I also have questions about the text added to specify this is for public key lookup. Please review how I have said this in the draft. Also the text for use in the IPSECKEY registry is at odds with the text for the current values. What to do? Instruct IANA to adjust the text for values 1 - 3 to match? What do you mean with this? Current IANA registry is: 0 No key is present [RFC4025] 1 A DSA key is present, in the format defined in [RFC2536] [RFC4025] 2 A RSA key is present, in the format defined in [RFC3110] [RFC4025] 3 An ECDSA key is present, in the format defined in [RFC6605] [RFC8005] Per Paul's request I am coming up that for EdDSA I would ask the following be added: 4 An EdDSA Public key is present, in the format defined in [RFC8080] [This] Note the addition of "Public" * So should 1 - 3 also have "Public" added? * Should 4 NOT have "Public" * Should text be added describing this registry to be for "Public" keys? Choise one (I hope!) Write text to go at the beginning that this is for public keys and remove the proposed such text for the eddsa value. I have not (yet) found any IANA registry that has such text, and any points would help this discussion. Bob ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Fwd: New Version Notification for draft-moskowitz-ipsecme-ipseckey-eddsa-01.txt
This latest ver is in response to comments recieved. Please review Appendix A that I have the RR properly set up. I also have questions about the text added to specify this is for public key lookup. Please review how I have said this in the draft. Also the text for use in the IPSECKEY registry is at odds with the text for the current values. What to do? Instruct IANA to adjust the text for values 1 - 3 to match? Write text to go at the beginning that this is for public keys and remove the proposed such text for the eddsa value. I have not (yet) found any IANA registry that has such text, and any points would help this discussion. Thank you Bob Forwarded Message Subject: New Version Notification for draft-moskowitz-ipsecme-ipseckey-eddsa-01.txt Date: Fri, 05 Aug 2022 05:29:44 -0700 From: internet-dra...@ietf.org To: Robert Moskowitz , Tero Kivinen A new version of I-D, draft-moskowitz-ipsecme-ipseckey-eddsa-01.txt has been successfully submitted by Robert Moskowitz and posted to the IETF repository. Name: draft-moskowitz-ipsecme-ipseckey-eddsa Revision: 01 Title: EdDSA value for IPSECKEY Document date: 2022-08-05 Group: Individual Submission Pages: 4 URL: https://www.ietf.org/archive/id/draft-moskowitz-ipsecme-ipseckey-eddsa-01.txt Status: https://datatracker.ietf.org/doc/draft-moskowitz-ipsecme-ipseckey-eddsa/ Html: https://www.ietf.org/archive/id/draft-moskowitz-ipsecme-ipseckey-eddsa-01.html Htmlized: https://datatracker.ietf.org/doc/html/draft-moskowitz-ipsecme-ipseckey-eddsa Diff: https://www.ietf.org/rfcdiff?url2=draft-moskowitz-ipsecme-ipseckey-eddsa-01 Abstract: This document assigns a value for EdDSA Public Keys to the IPSECKEY IANA registry. The IETF Secretariat ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-moskowitz-ipsecme-ipseckey-eddsa-00.txt
Michael, Thank you for the review. On 8/2/22 11:34, Michael Richardson wrote: Robert Moskowitz wrote: > I do need this expedited, as I do need to reference in my draft which, > hopefully, is in final IESG review process. > One particular point of review. Paul requested that I specifically say > this is for EdDSA Public Keys, as in drip, it ends up in the DNS HIP > RR. We don't want the initiated to think this is a place for private > keys... I have read it and it looks good. I would ask that there be an example of a public key in an appendix, and that private key be included. I will work with Adam on this. I suspect he has examples for me to include. Shouldn't you cite RFC4025 somewhere? You are right. I have that in drip-rid, and just did not copy over that text. Will be included in a -01 ver. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Fwd: New Version Notification for draft-moskowitz-ipsecme-ipseckey-eddsa-00.txt
Per Paul Wouters' request to separate the addition of EdDSA support to IPSECKEY, as needed in draft-ietf-drip-rid, here is a small draft for your review. I do need this expedited, as I do need to reference in my draft which, hopefully, is in final IESG review process. One particular point of review. Paul requested that I specifically say this is for EdDSA Public Keys, as in drip, it ends up in the DNS HIP RR. We don't want the initiated to think this is a place for private keys... Well that puts the IANA registry wording at odds with the other algorithms that do not call out which of the key pair goes here. Does that mean that the registry text for current algorithms needs updating? Or only the text of the doc says Public Key, where as the registry text leaves this out? Also, the capitalization. Is "Public Key" a proper noun and thus both word in caps? Only "Public", or neither? Thanks! Bob Forwarded Message Subject: New Version Notification for draft-moskowitz-ipsecme-ipseckey-eddsa-00.txt Date: Tue, 02 Aug 2022 05:07:10 -0700 From: internet-dra...@ietf.org To: Robert Moskowitz , Tero Kivinen A new version of I-D, draft-moskowitz-ipsecme-ipseckey-eddsa-00.txt has been successfully submitted by Robert Moskowitz and posted to the IETF repository. Name: draft-moskowitz-ipsecme-ipseckey-eddsa Revision: 00 Title: EdDSA value for IPSECKEY Document date: 2022-08-02 Group: Individual Submission Pages: 4 URL: https://www.ietf.org/archive/id/draft-moskowitz-ipsecme-ipseckey-eddsa-00.txt Status: https://datatracker.ietf.org/doc/draft-moskowitz-ipsecme-ipseckey-eddsa/ Html: https://www.ietf.org/archive/id/draft-moskowitz-ipsecme-ipseckey-eddsa-00.html Htmlized: https://datatracker.ietf.org/doc/html/draft-moskowitz-ipsecme-ipseckey-eddsa Abstract: This document assigns a value for EdDSA Public Keys to the IPSECKEY IANA registry. The IETF Secretariat ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] IETF114 scheduling
Right now, ipsecme is slotted together with tls. I guess they assume no overlap of interest? :) I do have interest in both, provided there is discussion of diet-esp at 114. I do have commitments working with the FAA on their TLS extension. Bob ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Comments: New Version Notification for draft-mglt-ipsecme-diet-esp-08
On 6/7/22 08:43, Daniel Migault wrote: On Tue, Jun 7, 2022 at 8:14 AM Robert Moskowitz wrote: Daniel, Back at it, now that ASTM is behind me... what will it take to bring this in line with SCHC. I don't know SCHC well enough to pick up the differences. We are basically balancing re-using a framework used / standardized by the IETF versus defining our own framework. So it is just to remain more aligned or coherent with what the IETF does. What will it take to add AES-GCM-12 to supported ciphers by IKE (and thus ESP)? For my use case, I have a hard time seeing why I need a 16-byte ICV. Even an 30 min operation with streaming video is a limited number of packets. I am going to talk to my contact at DJI to see what information they are willing to share... I think we do not enable compression of the signature as the security implications are too hard to catch. When an reduced ICV is needed, there is a need to define the transform. In your case rfc4106 seems to address your concern with a 12 and even 8 byte ICV. I was not clear. A 8750 IIV-AES-GCM-12 cipher... Bob On 5/16/22 16:47, Robert Moskowitz wrote: > Thanks, Daniel for the update. > > Now some comments. > > The necessary state is held within the IPsec Security Association and > > The document specifies the necessary parameters of the EHC Context to > allow compression of ESP and the most common included protocols, such > as IPv4, IPv6, UDP and TCP and the corresponding EHC Rules. > > Should any reference be made to cipher compression? At least > reference to 8750? Or since this is just the abs > > It also > defines the Diet-ESP EHC Strategy which compresses up to 32 bytes per > packet for traditional IPv6 VPN and up to 66 bytes for IPv6 VPN sent > over a single TCP or UDP session. > > > In UDP transport I am reducing 18 bytes (assuming cipher with zero > padding) to 4 bytes. Also worth noting here... > > > On the other hand, in IoT > communications, sending extra bytes can significantly impact the > battery life of devices and thus the life time of the device. The > document describes a framework that optimizes the networking overhead > associated to IPsec/ESP for these devices. > > > You say nothing about constrained comm links. This compression may > make ESP viable over links like LoRaWAN. > > ESP Header Compression (EHC) chooses another form of context > agreement, which is similar to the one defined by Static Context > Header Compression (SCHC). > > Reference rfc 8724. > > And more than 'similar"? Maybe "based on the one"? > > The context > itself can be negotiated during the key agreement, which allows only > minimal the changes to the actual ESP implementation. > > I don't get this. What only allows minimal changes? The key > agreement protocol or ECH? If the later then perhaps: > > The context > itself can be negotiated during the key agreement, which then needs > only > minimal the changes to the actual ESP implementation. > > More for introduction: > > Perhaps you can add that in transport mode, an SA may be for a single > transport/port to tune the ECH for that use and that multiple SAs > could be negotiated for this case. > > Question: Can a single IKE exchange produce multiple SAs? > > Here is my use case: > > Between the UA and GCS are two flows. One for Command and Control > (C2) the other streaming video. Both over UDP, but different ports. > So instead of having carry the UDP ports in all the messages, > negotiate separate SAs with the appropriate ECH. > > Ah, I see this in Sec 5. You should say something about this in the > intro. > > sec 4. > > EHC is able to compress any protocol encapsulated in ESP and ESP > itself. > > No really true per other claims. Does it offer compressing RTP? I > need that, probably, for my streaming video app. > > to compress any IP and transport protocol... > > And only TCP and UDP are shown, what about, say, SCTP? > > BTW, I note that you use 'IKEv2'. At this point is that really > needed? Should just IKE be enough? Has not IKEv1 been depreicated? > > 6. EHC Context > > > The EHC Context is defined on a per-SA basis. A context can be
Re: [IPsec] Comments: New Version Notification for draft-mglt-ipsecme-diet-esp-08
Daniel, Back at it, now that ASTM is behind me... what will it take to bring this in line with SCHC. I don't know SCHC well enough to pick up the differences. What will it take to add AES-GCM-12 to supported ciphers by IKE (and thus ESP)? For my use case, I have a hard time seeing why I need a 16-byte ICV. Even an 30 min operation with streaming video is a limited number of packets. I am going to talk to my contact at DJI to see what information they are willing to share... Bob On 5/16/22 16:47, Robert Moskowitz wrote: Thanks, Daniel for the update. Now some comments. The necessary state is held within the IPsec Security Association and The document specifies the necessary parameters of the EHC Context to allow compression of ESP and the most common included protocols, such as IPv4, IPv6, UDP and TCP and the corresponding EHC Rules. Should any reference be made to cipher compression? At least reference to 8750? Or since this is just the abs It also defines the Diet-ESP EHC Strategy which compresses up to 32 bytes per packet for traditional IPv6 VPN and up to 66 bytes for IPv6 VPN sent over a single TCP or UDP session. In UDP transport I am reducing 18 bytes (assuming cipher with zero padding) to 4 bytes. Also worth noting here... On the other hand, in IoT communications, sending extra bytes can significantly impact the battery life of devices and thus the life time of the device. The document describes a framework that optimizes the networking overhead associated to IPsec/ESP for these devices. You say nothing about constrained comm links. This compression may make ESP viable over links like LoRaWAN. ESP Header Compression (EHC) chooses another form of context agreement, which is similar to the one defined by Static Context Header Compression (SCHC). Reference rfc 8724. And more than 'similar"? Maybe "based on the one"? The context itself can be negotiated during the key agreement, which allows only minimal the changes to the actual ESP implementation. I don't get this. What only allows minimal changes? The key agreement protocol or ECH? If the later then perhaps: The context itself can be negotiated during the key agreement, which then needs only minimal the changes to the actual ESP implementation. More for introduction: Perhaps you can add that in transport mode, an SA may be for a single transport/port to tune the ECH for that use and that multiple SAs could be negotiated for this case. Question: Can a single IKE exchange produce multiple SAs? Here is my use case: Between the UA and GCS are two flows. One for Command and Control (C2) the other streaming video. Both over UDP, but different ports. So instead of having carry the UDP ports in all the messages, negotiate separate SAs with the appropriate ECH. Ah, I see this in Sec 5. You should say something about this in the intro. sec 4. EHC is able to compress any protocol encapsulated in ESP and ESP itself. No really true per other claims. Does it offer compressing RTP? I need that, probably, for my streaming video app. to compress any IP and transport protocol... And only TCP and UDP are shown, what about, say, SCTP? BTW, I note that you use 'IKEv2'. At this point is that really needed? Should just IKE be enough? Has not IKEv1 been depreicated? 6. EHC Context The EHC Context is defined on a per-SA basis. A context can be defined for any protocol encapsulated with ESP and for ESP itself. Should that be "any IP or Transport protocol"? To exclude layer 5 protocols (CoAP, RTP,,,)? Layer 5 protocols SHOULD be via standard SCHC with the SCHC Rule ID included... Or maybe 'typically'? As some layer 5 might be easy? RTP maybe? So this is it for this round of comments. I am looking at Appdx A and making a UDP example. Including IIV. Bob ___ 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] Fwd: New Version Notification for draft-moskowitz-lpwan-ipnumber-00.txt
Here is my draft for asking for an Internet Protocol Number assigned to SCHC as we have been discussing on both the Ipsecme and Tls lists. I also posted this to the lpwan list. I welcome comments and help (co-authors welcomed!). Bob Forwarded Message Subject: New Version Notification for draft-moskowitz-lpwan-ipnumber-00.txt Date: Fri, 03 Jun 2022 08:33:59 -0700 From: internet-dra...@ietf.org To: Robert Moskowitz A new version of I-D, draft-moskowitz-lpwan-ipnumber-00.txt has been successfully submitted by Robert Moskowitz and posted to the IETF repository. Name: draft-moskowitz-lpwan-ipnumber Revision: 00 Title: IP Number for SCHC Document date: 2022-06-03 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/archive/id/draft-moskowitz-lpwan-ipnumber-00.txt Status: https://datatracker.ietf.org/doc/draft-moskowitz-lpwan-ipnumber/ Html: https://www.ietf.org/archive/id/draft-moskowitz-lpwan-ipnumber-00.html Htmlized: https://datatracker.ietf.org/doc/html/draft-moskowitz-lpwan-ipnumber Abstract: This document requests an Internet Protocol Number assignment for SCHC so that SCHC can be used for IP independent SCHC of other transports such as UDP and ESP. The IETF Secretariat ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] diet-esp - How do you know?
On 5/24/22 17:26, Daniel Migault wrote: The IKE negotiation is for diet-esp is currently defined in a specific draft: https://datatracker.ietf.org/doc/draft-mglt-ipsecme-ikev2-diet-esp-extension/ I totally missed this draft. It should at least be referenced in ipsecme-diet-esp. I will have to go read it to see if it covers my concerns. I think you are suggesting that the architecture description details what is negotiated by IKEv2. Am I correct ? This is an arch doc? Does not read like one! I was thinking about explicit sections on IKE processes. But now that I know that there is an IKE draft, at least referencing it in the intro should cover things. Maybe. ;) Yours, Daniel On Tue, May 24, 2022 at 4:59 PM Robert Moskowitz wrote: In My Highly Biased Opinion,,, There should be a section on the IKE negotiation of diet-esp, specifically calling out how this is done. Especially the incoming SPI selection. Then there should be a section, perhaps sub-section of above, on incoming datagram processing to recognize a shortened SPI on the wire and pass it off to diet-esp processing. I keep thinking back to when we had fun writing 2410 and one implementor did not get the joke and did it wrong and would not interop in null mode with any other product. They were really not happy campers... On 5/24/22 16:47, Daniel Migault wrote: The issue only comes when a gateway wants to support all sizes of SPIs 0 - 1 - 2 - 3 - 4 bytes - which is very unlikely. For a deterministic lookup, I would suggest using IP addresses and the minimum allowed byted compressed SPI. If you use 2 - 3 bytes, the likelihood of collision might still be very low to support an additional signature check. Yours, Daniel On Tue, May 24, 2022 at 4:30 PM Robert Moskowitz wrote: That is the 'easy' part. What does the code do when it receives an ESP packet? How do it know that it is a diet-esp packet and apply the rules? Next Header just says: ESP. On 5/24/22 16:23, Daniel Migault wrote: This is correct. IKEv2 is used both to agree on the use of Diet-ESP as well as values to be used for the compression/decompression. Yours, Daniel On Tue, May 24, 2022 at 11:14 AM Paul Wouters wrote: On Sun, May 22, 2022 at 9:20 PM Robert Moskowitz wrote: I think there is something else I am missing here. How does the receiving system 'know' that the packet is a diet-esp packet? https://datatracker.ietf.org/doc/html/draft-mglt-ipsecme-ikev2-diet-esp-extension-02 It's negotiated with IKEv2. I guess the IKE stack has to signal this to the ESP implementation on what to expect when the policy is installed ? Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec -- Daniel Migault Ericsson ___ 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] diet-esp - How do you know?
In My Highly Biased Opinion,,, There should be a section on the IKE negotiation of diet-esp, specifically calling out how this is done. Especially the incoming SPI selection. Then there should be a section, perhaps sub-section of above, on incoming datagram processing to recognize a shortened SPI on the wire and pass it off to diet-esp processing. I keep thinking back to when we had fun writing 2410 and one implementor did not get the joke and did it wrong and would not interop in null mode with any other product. They were really not happy campers... On 5/24/22 16:47, Daniel Migault wrote: The issue only comes when a gateway wants to support all sizes of SPIs 0 - 1 - 2 - 3 - 4 bytes - which is very unlikely. For a deterministic lookup, I would suggest using IP addresses and the minimum allowed byted compressed SPI. If you use 2 - 3 bytes, the likelihood of collision might still be very low to support an additional signature check. Yours, Daniel On Tue, May 24, 2022 at 4:30 PM Robert Moskowitz wrote: That is the 'easy' part. What does the code do when it receives an ESP packet? How do it know that it is a diet-esp packet and apply the rules? Next Header just says: ESP. On 5/24/22 16:23, Daniel Migault wrote: This is correct. IKEv2 is used both to agree on the use of Diet-ESP as well as values to be used for the compression/decompression. Yours, Daniel On Tue, May 24, 2022 at 11:14 AM Paul Wouters wrote: On Sun, May 22, 2022 at 9:20 PM Robert Moskowitz wrote: I think there is something else I am missing here. How does the receiving system 'know' that the packet is a diet-esp packet? https://datatracker.ietf.org/doc/html/draft-mglt-ipsecme-ikev2-diet-esp-extension-02 It's negotiated with IKEv2. I guess the IKE stack has to signal this to the ESP implementation on what to expect when the policy is installed ? Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec -- Daniel Migault Ericsson ___ 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] diet-esp - How do you know?
That is the 'easy' part. What does the code do when it receives an ESP packet? How do it know that it is a diet-esp packet and apply the rules? Next Header just says: ESP. On 5/24/22 16:23, Daniel Migault wrote: This is correct. IKEv2 is used both to agree on the use of Diet-ESP as well as values to be used for the compression/decompression. Yours, Daniel On Tue, May 24, 2022 at 11:14 AM Paul Wouters wrote: On Sun, May 22, 2022 at 9:20 PM Robert Moskowitz wrote: I think there is something else I am missing here. How does the receiving system 'know' that the packet is a diet-esp packet? https://datatracker.ietf.org/doc/html/draft-mglt-ipsecme-ikev2-diet-esp-extension-02 It's negotiated with IKEv2. I guess the IKE stack has to signal this to the ESP implementation on what to expect when the policy is installed ? Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec -- Daniel Migault Ericsson ___ 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] diet-esp - How do you know?
Scott, That is my question/point. And if I understand diet-esp and lsb, then the 8-bit SPI maps to the full SPI in the SA is xx07? Ah, the *Receiver* picks the incoming SPIs. It has been so many years since I looked into the protocol/code that I lost sight of this. I had it reversed. Thus the receiver MUST be careful in selecting its incoming SPIs such that there is no collision. The draft needs to spell this out. And for a UAS Network Remote ID Service Provider, it would use a 2-byte transmitted SPI to allow for a reasonable number of UAS in service at any time... On 5/24/22 11:30, Scott Fluhrer (sfluhrer) wrote: I believe that the question is “when someone receives an IPsec packet, how do they determine the SA, assuming that they have negotiated both standard SAs (with 32 bit SPIs), and diet-esp (with shorter SPIs).” My initial assumption was that, as the receiver picks its incoming SPIs, that they pick them to allow unambiguous lookup. For example, if a diet-esp inbound SA has an 8 bit SPI of 07, that means that the implementation ensures that it does not have any standard inbound SAs with SPIs of the form 07. It might not be totally unreasonable if the diet draft spelled out a method for achieving this… *From:* IPsec *On Behalf Of *Paul Wouters *Sent:* Tuesday, May 24, 2022 11:14 AM *To:* Robert Moskowitz *Cc:* IPsecME WG *Subject:* Re: [IPsec] diet-esp - How do you know? On Sun, May 22, 2022 at 9:20 PM Robert Moskowitz wrote: I think there is something else I am missing here. How does the receiving system 'know' that the packet is a diet-esp packet? https://datatracker.ietf.org/doc/html/draft-mglt-ipsecme-ikev2-diet-esp-extension-02 It's negotiated with IKEv2. I guess the IKE stack has to signal this to the ESP implementation on what to expect when the policy is installed ? 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
Re: [IPsec] ESP Signally to higher layers
On 5/21/22 07:13, Michael Richardson wrote: Robert Moskowitz wrote: > This is an item that goes back to the beginning of ESP work: > Minimally, how does the higher level 'learn' that it is secure: Are you asking how *TCP* learns of this, or how an application with an open socket(2) learns of this? App TCP or UDP. > Encrypted/Authenticated/CrCed... ? > And as ESP has a seq#, how might it be convied to the higher layer? Do you mean replay counter here, or did you mean SPI? SPI SHOULD have no value to the higher layer. It is the actual Seq # that may be of value. Preferably, never, because it will get rekeyed, so really, whatever you want to do really needs to be communicated abstracted to the key daemon, who will do the right thing, and keep track of updates to the SPI# > Case in point: MAVlink has a 1-byte seq# in its payload. How might > this be provided by ESP? Now I think maybe you really do mean sequence/replay counter. Yes. > https://mavlink.io/en/guide/message_signing.html > So I have been thinking about this vis-a-vis diet-esp. What is the > mechanism/trigger that can best work across a number of higher layers > to inform of operating environment and values available (seq#)? > Is this done anywhere now? Doubtful. MAVlink does its own seq# processing, so if I squeeze it out in transporting the MAVlink packet, I need to rebuild it when passing it up to MAVlink. Now a formal SCHC layer SHOULD be able to do this. One would think. There are other layer 5 protocols with Seq #. Like RTP. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] ESP Signally to higher layers
Thanks Chris. Helps a bit. On 5/20/22 20:27, Christian Hopps wrote: Robert Moskowitz writes: This is an item that goes back to the beginning of ESP work: Minimally, how does the higher level 'learn' that it is secure: E2E or TE2TE? Encrypted/Authenticated/CrCed... ? And as ESP has a seq#, how might it be convied to the higher layer? Case in point: MAVlink has a 1-byte seq# in its payload. How might this be provided by ESP? https://mavlink.io/en/guide/message_signing.html So I have been thinking about this vis-a-vis diet-esp. What is the mechanism/trigger that can best work across a number of higher layers to inform of operating environment and values available (seq#)? Is this done anywhere now? If you're asking for a generic API mechanism in unix, for datagrams it would be recvmsg. Recvmsg uses a msghdr which can include control data (cmsghdr). That is the way that lower layer information associated with packets is passed up to the application. man recvmsg man cmsg I don't know if any ESP data is currently passed with this method though. Thanks, Chris. Bob ___ 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] diet-esp - How do you know?
I think there is something else I am missing here. How does the receiving system 'know' that the packet is a diet-esp packet? Protocol ID is ESP. That is all we have. Right after the IPv6 or IPv4 header comes the ESP header, but is it a regular ESP header with a 4-byte SPI or is it a dist-esp header with some other SPI size? How is this done? Is the source IP the 'key' that it is a diet-esp, and look at all the SAs associated with that source IP and hopefully find one that maps to at least the 1st byte or full 4 bytes? What is the logic trigger? And if it is the source IP, how might gateways and such mess things up. Or am I back to needing a SCHC protocol ID to put in the Next Header field rather than ESP? Confused here... Bob ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] ESP Signally to higher layers
This is an item that goes back to the beginning of ESP work: Minimally, how does the higher level 'learn' that it is secure: E2E or TE2TE? Encrypted/Authenticated/CrCed... ? And as ESP has a seq#, how might it be convied to the higher layer? Case in point: MAVlink has a 1-byte seq# in its payload. How might this be provided by ESP? https://mavlink.io/en/guide/message_signing.html So I have been thinking about this vis-a-vis diet-esp. What is the mechanism/trigger that can best work across a number of higher layers to inform of operating environment and values available (seq#)? Is this done anywhere now? Bob ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Comments: New Version Notification for draft-mglt-ipsecme-diet-esp-08
Thanks, Daniel for the update. Now some comments. The necessary state is held within the IPsec Security Association and The document specifies the necessary parameters of the EHC Context to allow compression of ESP and the most common included protocols, such as IPv4, IPv6, UDP and TCP and the corresponding EHC Rules. Should any reference be made to cipher compression? At least reference to 8750? Or since this is just the abs It also defines the Diet-ESP EHC Strategy which compresses up to 32 bytes per packet for traditional IPv6 VPN and up to 66 bytes for IPv6 VPN sent over a single TCP or UDP session. In UDP transport I am reducing 18 bytes (assuming cipher with zero padding) to 4 bytes. Also worth noting here... On the other hand, in IoT communications, sending extra bytes can significantly impact the battery life of devices and thus the life time of the device. The document describes a framework that optimizes the networking overhead associated to IPsec/ESP for these devices. You say nothing about constrained comm links. This compression may make ESP viable over links like LoRaWAN. ESP Header Compression (EHC) chooses another form of context agreement, which is similar to the one defined by Static Context Header Compression (SCHC). Reference rfc 8724. And more than 'similar"? Maybe "based on the one"? The context itself can be negotiated during the key agreement, which allows only minimal the changes to the actual ESP implementation. I don't get this. What only allows minimal changes? The key agreement protocol or ECH? If the later then perhaps: The context itself can be negotiated during the key agreement, which then needs only minimal the changes to the actual ESP implementation. More for introduction: Perhaps you can add that in transport mode, an SA may be for a single transport/port to tune the ECH for that use and that multiple SAs could be negotiated for this case. Question: Can a single IKE exchange produce multiple SAs? Here is my use case: Between the UA and GCS are two flows. One for Command and Control (C2) the other streaming video. Both over UDP, but different ports. So instead of having carry the UDP ports in all the messages, negotiate separate SAs with the appropriate ECH. Ah, I see this in Sec 5. You should say something about this in the intro. sec 4. EHC is able to compress any protocol encapsulated in ESP and ESP itself. No really true per other claims. Does it offer compressing RTP? I need that, probably, for my streaming video app. to compress any IP and transport protocol... And only TCP and UDP are shown, what about, say, SCTP? BTW, I note that you use 'IKEv2'. At this point is that really needed? Should just IKE be enough? Has not IKEv1 been depreicated? 6. EHC Context The EHC Context is defined on a per-SA basis. A context can be defined for any protocol encapsulated with ESP and for ESP itself. Should that be "any IP or Transport protocol"? To exclude layer 5 protocols (CoAP, RTP,,,)? Layer 5 protocols SHOULD be via standard SCHC with the SCHC Rule ID included... Or maybe 'typically'? As some layer 5 might be easy? RTP maybe? So this is it for this round of comments. I am looking at Appdx A and making a UDP example. Including IIV. Bob ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Comments on draft-mglt-ipsecme-diet-esp-07
On 5/12/22 11:58, Daniel Migault wrote: Hi Bob, I apologize for the delayed response. I am happy to go back to this document. Good and thank you. I also see a tunnel application, but that will be for later. First UDP Transport and UDP BEET mode. Yours, Daniel On Fri, May 6, 2022 at 5:02 PM Robert Moskowitz wrote: First read-through. Is there an implementation of this draft? yes we do have an implementation on contiki, as well as in python. The implementation is available here: https://bitbucket.org/sylvain_www/diet-esp-contiki You can also find a description of the implementation as well as some experimental measurements we performed there: https://www.researchgate.net/publication/316348221_Diet-ESP_IP_layer_security_for_IoT Obviously it being last published in '19 some drafts are now RFCs and thus need updating. Sure ;-) Page 5 at top: Non ESP fields may be compressed by ESP under certain circumstances, but EHC is not intended to provide a generic way outside of ESP to compress these protocols. How does EHC work with SCHC CoAP compression, rfc 8824? I would think this is a must work with... I agree that is something we should consider and probably clarify. Diet-ESP is not intended to provide some compression beyond what is being used for TS. I do not see CoAP as part of these TS, and as such, I would expect the compression associated to CoAP to be handled "after Diet-ESP". Not having read how SCHC compresses CoAP, I Assume that SCHC CoAP compresses also the UDP/IP part which ends in the compressed CoAP packet not being an IP packet. On the sender side, when IPsec is applied to such packet, there is a need that this compressed CoAP packet matches the SPD TS - unless these are set to ANY. So my first question would be how SCHC CoAP works with IPsec ? Most of the SCHC CoAP rfc deals with the CoAP headers, and any UDP consideration is out-of-scope. Even with UDP/DTLS, 8824 is silent. I think. So this draft can easily ignore CoAP. It took me a bit of reading to get to this point.. Assuming the compressed packet is protected by IPsec, only the ESP fields will be subject to compression. On the other hand, if IPsec requires some fields, there is probably a need to request Diet-ESP to compress what SCHC(CoAP) has not compressed to make IPsec work. As far as diet-esp is concerned any 8824 CoAP compression is just data payload. The SCHC RuleID is the first field either in the UDP data or the DTLS data. As depicted in Figure 1, the EHC Strategy - Diet-ESP in our case - and the EHC Context are agreed upon between the two peers, e.g. during key exchange. The EHC Rules are to be implemented on the peers and do not require further agreement. Can the EHC Strategy, Context, and Rules be static between two hosts? This is of interest to me with Network Remote ID where these will always be the same (I think so far) between the UA and Service Provider. In fact if aligned with SCHC, static is the norm which can be overridden during a key exchange. This approach would allow the key exchange to be unmodified to support diet-esp. Rules are static and require only to agree on a very small number of parameters via IKEv2. WHat I do not think we considered is the exchange of additional SCHC rules. I just asked this again in my latest missive. I think you need the IKE payloads. And I will somewhere have to do the matching HIP payloads. ;) With EHC, the agreement of the level or occurrence of compression is left the negotiation protocol (e.g. IKEv2), contradicting the signalization of the level of compression for a certain packet send over the wire. This is a sentence fragment and I don't get what is being said here. Taking out the comma delimited: With EHC, contradicting the signalization of the level of compression for a certain packet send over the wire. ? Good I will need to review the doc. This leads to multiple SAs, and thus, multiple SPIs for different levels of compression agreed with the EHC Context. This can lead to multiple... Sure, Thanks. I think If the sender detects the de-compression can not be guaranteed with a given EHC Context and EHC Strategy, it MUST NOT apply compression. If the sender detects that the de- ? Made it through sec 6, stopping for now a 6.1 where I will continue Monday? I see that with ESP Next Header compression and ony UDP in the SA, that SCHC for UDP is not needed so don't need an IP Protocol number for SCHC here. But what about SCHC for CoAP over UDP? I think there is a need to define which layers will compress the inner UDP, and this is likely to depend on the TS values. After more readin
[IPsec] IKE negotiation for diet-esp
The draft talks about the EHC Context to be exchanged via IKE, but I do not see this in the draft? Negotiating the whole Context may be quite a bit and needs to be thought out in a secure sense? But just negotiating a SCHC RuleID may be simplier. this could be the sole tie-in with SCHC as the actual SCHC RuleID never goes over the wire. The SPIs imply the RuleID. There could be some additional pieces like if the RuleID is for UDP-Transport, the UDP ports for the SPI pair could be sent so one RuleID could serve multiple UDP apps. But I kind of assume that as there is a code implementation, there is a good understanding of what is needed, but I don't see it in the draft. Pointers are appreciated. Bob ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] More comments on draft-mglt-ipsecme-diet-esp-07
Continuing at sec 6.1: Skipping 6.2 for now, as it will not be used for current use case (I realize I may have one for Manned Aircraft). Good til 7.2, then skipping 7.2 and 7.3 for now. I like 7.4 in that UDP gets compressed to zero bytes. And the way you have constructed diet-esp to include transport, a separate SCHC rule for transport is not needed. Now if the payload is CoAP, then things will be different. Per the rfc 8824. Skip 7.5 and 7.6 Sec 11: Security Parameter Index (SPI): Until Diet-ESP is not deployed outside the scope of IoT and small devices, r/ not / / ? What is that not doing there? Sequence Number (SN): If incremented for each ESP packet, the SN may leak some information like the amount of transmitted data or the age of the sensor. If 2 bytes of SN are sent using a counter, there is little to no leakage of sensor age. If little traffic from sensor then only 1 byte may be better for this purpose. I just don't see this as a risk if care is taken. You may want to say this. Finally where is the open source code available? You need a UDP app in transport mode example in App 1. :) If you get this draft active, I will work on providing that example. ;) thanks. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] For authors of draft-mglt-ipsecme-diet-esp
I am now up to sec 7.2 (skipping tunnel sec for 1st pass). How can I help getting this draft active? So far I don't have any comments beyond what I have posted to the list. Bob ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] rfc 8750 question
On 5/10/22 08:25, Paul Wouters wrote: On May 10, 2022, at 07:59, Robert Moskowitz wrote: 20 ENCR_AES_GCM_16 and what RFC 8750 defined: 30 ENCR_AES_GCM_16_IIV The only difference is a suffix "_IIV". Actually, I thought that was the implicit IV size. And thus this was some kind of AND condition of the base cipher AND implicit IV. It is. But it seems you don't include both ESP ciphers in your IKE payload to inform how ESP is encyphering. I really want the AES_GCM_12 used along with diet-esp. Those 4 bytes are important when you are dealing with an MTU of 64 bytes and only have a 26 byte UDP data packet. From RFC 8247: As the advantage of the shorter (and weaker) Integrity Check Values (ICVs) is minimal, the 8- and 12-octet ICVs remain at the MAY level. This explanation was not repeated in RFC8221, but the reason is the same. These weren’t really used or supported and kind of unwanted. Basically the authors of GCM really didn’t want shorter than 16 ICV but were pushed to include it. The advantage comes into play in diet-esp situations. With diet-esp in transport mode for a single UDP app, I can have a 2-byte SPI (server will have LOTS of clients). I COULD get by with a 1-byte SN, but that would only cover ~4 min of comm before advancing the implicit msb So that is one packet per second. That’s a lot of traffic. Does the ICV size really matter at that point? Is it causing you to go from 1 to 2 packets per second ? And this kind of kills LoRaWAN 64-byte MTU duty cycle. Drats. Though I am still investigating LoRaWAN. There are other UHF networks where this will work, and there are sat networks that some are looking to use. Paul so better a 2-byte SN and that gives word alignment for the ESP header (not really s important). Those 4 bytes in the ICV hurt. And the data is only valid for 1sec for the app. The lightweigt crypto (like Xoodyak) from the NIST LWC effort (workshop this week) looks more attractive, as I can easily only squeeze the 12 bytes out of the sponge for the tag... ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] rfc 8750 question
On 5/10/22 08:25, Paul Wouters wrote: On May 10, 2022, at 07:59, Robert Moskowitz wrote: 20 ENCR_AES_GCM_16 and what RFC 8750 defined: 30 ENCR_AES_GCM_16_IIV The only difference is a suffix "_IIV". Actually, I thought that was the implicit IV size. And thus this was some kind of AND condition of the base cipher AND implicit IV. It is. I really want the AES_GCM_12 used along with diet-esp. Those 4 bytes are important when you are dealing with an MTU of 64 bytes and only have a 26 byte UDP data packet. From RFC 8247: As the advantage of the shorter (and weaker) Integrity Check Values (ICVs) is minimal, the 8- and 12-octet ICVs remain at the MAY level. This explanation was not repeated in RFC8221, but the reason is the same. These weren’t really used or supported and kind of unwanted. Basically the authors of GCM really didn’t want shorter than 16 ICV but were pushed to include it. With diet-esp in transport mode for a single UDP app, I can have a 2-byte SPI (server will have LOTS of clients). I COULD get by with a 1-byte SN, but that would only cover ~4 min of comm before advancing the implicit msb So that is one packet per second. That’s a lot of traffic. Does the ICV size really matter at that point? Is it causing you to go from 1 to 2 packets per second ? FAA mandate that the Location/Vector information for the UA be updated at least once per second (similar in EU and Japan). Then there are a few other messages, like if the Operator moves, DHS (proxying through FAA) wants to know where the Operator is. Operators tend not to move as much as UA, so no 1/sec mandate there. Of course all this position data is suspect. Altitude can be off 10M due to the ionosphere action, but FAA really does not care. You do NOT want a replay of all those video meetings... Paul so better a 2-byte SN and that gives word alignment for the ESP header (not really s important). Those 4 bytes in the ICV hurt. And the data is only valid for 1sec for the app. The lightweigt crypto (like Xoodyak) from the NIST LWC effort (workshop this week) looks more attractive, as I can easily only squeeze the 12 bytes out of the sponge for the tag... ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] rfc 8750 question
On 5/10/22 01:37, Valery Smyslov wrote: Hi Bob, I just noticed that 8750 defines one algorithm number for aes-gcm: 30 | ENCR_AES_GCM_16_IIV| RFC 8750 But rfc 4106 defined 3: 18 for AES-GCM with an 8 octet ICV; 19 for AES-GCM with a 12 octet ICV; and 20 for AES-GCM with a 16 octet ICV. so for 8750, what is the ICV length? It's 16. You may guess it by comparing what RFC 4106 defined: 20 ENCR_AES_GCM_16 and what RFC 8750 defined: 30 ENCR_AES_GCM_16_IIV The only difference is a suffix "_IIV". Actually, I thought that was the implicit IV size. And thus this was some kind of AND condition of the base cipher AND implicit IV. Humpf. I really want the AES_GCM_12 used along with diet-esp. Those 4 bytes are important when you are dealing with an MTU of 64 bytes and only have a 26 byte UDP data packet. With diet-esp in transport mode for a single UDP app, I can have a 2-byte SPI (server will have LOTS of clients). I COULD get by with a 1-byte SN, but that would only cover ~4 min of comm before advancing the implicit msb, so better a 2-byte SN and that gives word alignment for the ESP header (not really s important). Those 4 bytes in the ICV hurt. And the data is only valid for 1sec for the app. The lightweigt crypto (like Xoodyak) from the NIST LWC effort (workshop this week) looks more attractive, as I can easily only squeeze the 12 bytes out of the sponge for the tag... ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] rfc 8750 question
I just noticed that 8750 defines one algorithm number for aes-gcm: 30 | ENCR_AES_GCM_16_IIV | RFC 8750 But rfc 4106 defined 3: 18 for AES-GCM with an 8 octet ICV; 19 for AES-GCM with a 12 octet ICV; and 20 for AES-GCM with a 16 octet ICV. so for 8750, what is the ICV length? Trying to figure out the packet size with diet-esp... thanks ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Comments on draft-mglt-ipsecme-diet-esp-07
First read-through. Is there an implementation of this draft? Obviously it being last published in '19 some drafts are now RFCs and thus need updating. Page 5 at top: Non ESP fields may be compressed by ESP under certain circumstances, but EHC is not intended to provide a generic way outside of ESP to compress these protocols. How does EHC work with SCHC CoAP compression, rfc 8824? I would think this is a must work with... As depicted in Figure 1, the EHC Strategy - Diet-ESP in our case - and the EHC Context are agreed upon between the two peers, e.g. during key exchange. The EHC Rules are to be implemented on the peers and do not require further agreement. Can the EHC Strategy, Context, and Rules be static between two hosts? This is of interest to me with Network Remote ID where these will always be the same (I think so far) between the UA and Service Provider. In fact if aligned with SCHC, static is the norm which can be overridden during a key exchange. This approach would allow the key exchange to be unmodified to support diet-esp. With EHC, the agreement of the level or occurrence of compression is left the negotiation protocol (e.g. IKEv2), contradicting the signalization of the level of compression for a certain packet send over the wire. This is a sentence fragment and I don't get what is being said here. Taking out the comma delimited: With EHC, contradicting the signalization of the level of compression for a certain packet send over the wire. ? This leads to multiple SAs, and thus, multiple SPIs for different levels of compression agreed with the EHC Context. This can lead to multiple... I think If the sender detects the de-compression can not be guaranteed with a given EHC Context and EHC Strategy, it MUST NOT apply compression. If the sender detects that the de- ? Made it through sec 6, stopping for now a 6.1 where I will continue Monday? I see that with ESP Next Header compression and ony UDP in the SA, that SCHC for UDP is not needed so don't need an IP Protocol number for SCHC here. But what about SCHC for CoAP over UDP? Anyway, stopping for now. More, I suspect, later. Oh, and NIST is having their 4th LWC workshop M-W, so I am busy with that too! Bob ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] ipsecme - New Meeting Session Request for IETF 114
I would like to be able to attend. My only other conflict is DRIP. My only pressing interest here is diet-esp. On 5/6/22 13:40, IETF Meeting Session Request Tool wrote: A new meeting session request has just been submitted by Tero Kivinen, a Chair of the ipsecme working group. - Working Group Name: IP Security Maintenance and Extensions Area Name: Security Area Session Requester: Tero Kivinen Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 30 Conflicts to Avoid: Chair conflict: tls acme i2nsf Technology overlap: cfrg lamps tls People who must be present: Yoav Nir Tero Kivinen Paul Wouters Resources Requested: Special Requests: - ___ 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] Transport ESP and SCHC
https://datatracker.ietf.org/doc/draft-moskowitz-drip-secure-nrid-c2/ now references diet-esp. I am ready to add my efforts on the diet-esp document. I DO want it to get a SCHC IP port number so SCHC can be the ESP Next Header value. Also so IP itself can use SCHC for the diet-ESP if needed where there is no below IP SCHC in action (and maybe even if). On 4/21/22 10:36, Daniel Migault wrote: The question we are asking ourselves is should we re-write the spec with SCHC. Yours, Daniel On Thu, Apr 21, 2022 at 9:58 AM Tero Kivinen wrote: Robert Moskowitz writes: > Yet in 8724, they define a in-band header: > > |--- Compressed Header ---| > > +-++ > > | RuleID | Compression Residue | Payload | > > +-++ > > How do you include this? This is especially needed with CoAP, rfc 8824. > > What is preconfigured is what does the RuleID instruct you to do with that > compression residue. > > A bit more on this. When above Transport as in 8824, the port number needs to > know how to process the RuleID. When below IP as in 9011, the MAC needs a > type assigned for SCHC to know to use the RuleID for IP/whatever expansion. > MAC types are not the IETF's problem. > > It takes something like ESP that sits below Transport, to change this. Thus > this COULD be an lpwan issue for introducing SCHC, or it could be an ipsecme > issue as as far as I can think, only ESP presents this issue. You might want to check the Diet ESP work that was done in the IPsecME WG few years back. It mostly died because there was not enough interest to work on the drafts or implementations. https://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp/07/ This is still in the IPsecME charter item so if there is interest to start working on this then IPsecME WG has space for it: A growing number of use cases for constrained networks - but not limited to those networks - have shown interest in reducing ESP (resp. IKEv2) overhead by compressing ESP (resp IKEv2) fields. The WG will define extensions of ESP and IKEv2 to enable ESP header compression. Possible starting points are draft-mglt-ipsecme-diet-esp, draft-mglt-ipsecme-ikev2-diet-esp-extension, draft-smyslov-ipsecme-ikev2-compression and draft-smyslov-ipsecme-ikev2-compact. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec -- Daniel Migault Ericsson ___ 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] Transport ESP and SCHC
I am reading diet-esp right now, and from what you said, will skip
minimal-esp at least for now, as I have too much else on my plate (as
you well know).
SCHC is explicitly called out in the Intro without referencing the
drafts of the time. To avoid any blocking drafts? Would you now have
8724 as a normative reference? I would think you would need that for
the IANA section to ask for the protocol number?
For my use case, it is ESP in transport, and most likely only with UDP
(but would not want to risk boxing UAs into that corner).
I will read some more, but I do think that the SCHC rule ID will be both
below to compress ESP, and above for the transport/application. But I
am suredly getting ahead of myself...
Bob
On 5/3/22 16:56, Daniel Migault wrote:
minimal esp describes how to implement a standard ESP in a constrained
environment with minimal options as well as variants to minimize the
impact of the implementation on the device.
diet-esp defines how to compress / decompress ESP. The description is
pretty much complete. We implemented it on Contiki. We were wondering
whether to adapt with SCHC. It would be cleaner in my opinion, but
that is just a thought.
Yours,
Daniel
On Tue, May 3, 2022 at 4:44 PM Robert Moskowitz
wrote:
Daniel and Tero,
How do diet-esp and minimal-esp intersect?
minimal-esp is, it seems ready for publication, so nothing really
changing it is possible.
But what does diet-esp do instead?
Squeezing down esp and adding support for SCHC ('easy' by adding
it as an IP Protocol) is of interest to me...
Bob
On 4/21/22 10:36, Daniel Migault wrote:
The question we are asking ourselves is should we re-write the
spec with SCHC.
Yours,
Daniel
On Thu, Apr 21, 2022 at 9:58 AM Tero Kivinen wrote:
Robert Moskowitz writes:
> Yet in 8724, they define a in-band header:
>
> |--- Compressed Header ---|
>
> +-++
>
> | RuleID | Compression Residue | Payload |
>
> +-++
>
> How do you include this? This is especially needed
with CoAP, rfc 8824.
>
> What is preconfigured is what does the RuleID instruct
you to do with that
> compression residue.
>
> A bit more on this. When above Transport as in 8824, the
port number needs to
> know how to process the RuleID. When below IP as in 9011,
the MAC needs a
> type assigned for SCHC to know to use the RuleID for
IP/whatever expansion.
> MAC types are not the IETF's problem.
>
> It takes something like ESP that sits below Transport, to
change this. Thus
> this COULD be an lpwan issue for introducing SCHC, or it
could be an ipsecme
> issue as as far as I can think, only ESP presents this issue.
You might want to check the Diet ESP work that was done in
the IPsecME
WG few years back. It mostly died because there was not enough
interest to work on the drafts or implementations.
https://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp/07/
This is still in the IPsecME charter item so if there is
interest to
start working on this then IPsecME WG has space for it:
A growing number of use cases for constrained networks -
but not
limited to those networks - have shown interest in
reducing ESP
(resp. IKEv2) overhead by compressing ESP (resp IKEv2)
fields. The
WG will define extensions of ESP and IKEv2 to enable ESP
header
compression.
Possible starting points are draft-mglt-ipsecme-diet-esp,
draft-mglt-ipsecme-ikev2-diet-esp-extension,
draft-smyslov-ipsecme-ikev2-compression and
draft-smyslov-ipsecme-ikev2-compact.
--
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--
Daniel Migault
Ericsson
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--
Daniel Migault
Ericsson
___
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] Transport ESP and SCHC
Daniel and Tero,
How do diet-esp and minimal-esp intersect?
minimal-esp is, it seems ready for publication, so nothing really
changing it is possible.
But what does diet-esp do instead?
Squeezing down esp and adding support for SCHC ('easy' by adding it as
an IP Protocol) is of interest to me...
Bob
On 4/21/22 10:36, Daniel Migault wrote:
The question we are asking ourselves is should we re-write the spec
with SCHC.
Yours,
Daniel
On Thu, Apr 21, 2022 at 9:58 AM Tero Kivinen wrote:
Robert Moskowitz writes:
> Yet in 8724, they define a in-band header:
>
> |--- Compressed Header ---|
>
> +-++
>
> | RuleID | Compression Residue | Payload |
>
> +-++
>
> How do you include this? This is especially needed with
CoAP, rfc 8824.
>
> What is preconfigured is what does the RuleID instruct you
to do with that
> compression residue.
>
> A bit more on this. When above Transport as in 8824, the port
number needs to
> know how to process the RuleID. When below IP as in 9011, the
MAC needs a
> type assigned for SCHC to know to use the RuleID for IP/whatever
expansion.
> MAC types are not the IETF's problem.
>
> It takes something like ESP that sits below Transport, to change
this. Thus
> this COULD be an lpwan issue for introducing SCHC, or it could
be an ipsecme
> issue as as far as I can think, only ESP presents this issue.
You might want to check the Diet ESP work that was done in the IPsecME
WG few years back. It mostly died because there was not enough
interest to work on the drafts or implementations.
https://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp/07/
This is still in the IPsecME charter item so if there is interest to
start working on this then IPsecME WG has space for it:
A growing number of use cases for constrained networks - but not
limited to those networks - have shown interest in reducing ESP
(resp. IKEv2) overhead by compressing ESP (resp IKEv2) fields. The
WG will define extensions of ESP and IKEv2 to enable ESP header
compression.
Possible starting points are draft-mglt-ipsecme-diet-esp,
draft-mglt-ipsecme-ikev2-diet-esp-extension,
draft-smyslov-ipsecme-ikev2-compression and
draft-smyslov-ipsecme-ikev2-compact.
--
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--
Daniel Migault
Ericsson
___
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] Transport ESP and SCHC
No question IMHO. It would fit into other SCHC rules in use. I will look at the draft; it has been a while. I have a real use case, but I will see what, other than 8750 gains are available for this use case. On 4/21/22 10:36, Daniel Migault wrote: The question we are asking ourselves is should we re-write the spec with SCHC. Yours, Daniel On Thu, Apr 21, 2022 at 9:58 AM Tero Kivinen wrote: Robert Moskowitz writes: > Yet in 8724, they define a in-band header: > > |--- Compressed Header ---| > > +-++ > > | RuleID | Compression Residue | Payload | > > +-++ > > How do you include this? This is especially needed with CoAP, rfc 8824. > > What is preconfigured is what does the RuleID instruct you to do with that > compression residue. > > A bit more on this. When above Transport as in 8824, the port number needs to > know how to process the RuleID. When below IP as in 9011, the MAC needs a > type assigned for SCHC to know to use the RuleID for IP/whatever expansion. > MAC types are not the IETF's problem. > > It takes something like ESP that sits below Transport, to change this. Thus > this COULD be an lpwan issue for introducing SCHC, or it could be an ipsecme > issue as as far as I can think, only ESP presents this issue. You might want to check the Diet ESP work that was done in the IPsecME WG few years back. It mostly died because there was not enough interest to work on the drafts or implementations. https://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp/07/ This is still in the IPsecME charter item so if there is interest to start working on this then IPsecME WG has space for it: A growing number of use cases for constrained networks - but not limited to those networks - have shown interest in reducing ESP (resp. IKEv2) overhead by compressing ESP (resp IKEv2) fields. The WG will define extensions of ESP and IKEv2 to enable ESP header compression. Possible starting points are draft-mglt-ipsecme-diet-esp, draft-mglt-ipsecme-ikev2-diet-esp-extension, draft-smyslov-ipsecme-ikev2-compression and draft-smyslov-ipsecme-ikev2-compact. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec -- Daniel Migault Ericsson ___ 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] Transport ESP and SCHC
On 4/20/22 05:42, Robert Moskowitz wrote: On 4/19/22 23:15, Benjamin Kaduk wrote: On Tue, Apr 19, 2022 at 11:09:26PM -0400, Robert Moskowitz wrote: Has there been any discussion about Transport ESP and SCHC from lpwan? https://datatracker.ietf.org/doc/draft-ietf-lpwan-architecture/ In Sec 5, the assumption is the security envelope is above UDP. e.g. DTLS and QUIC. No consideration for ESP Transport. RFC 8824 only deals with CoAP and not UDP. SCHC does not have an IP Protocol Number, thus I can't use it in ESP Next Header. The first "SC" is for "static context", i.e., you're supposed to just know, from an external (fixed/static) context, when the header compression is/isn't to be used. Since you "just know" when to use it, no in-band signaling such as IP protocol number is needed, at least in the original envisioned use cases. Yet in 8724, they define a in-band header: |--- Compressed Header ---| +-++ | RuleID | Compression Residue | Payload | +-++ How do you include this? This is especially needed with CoAP, rfc 8824. What is preconfigured is what does the RuleID instruct you to do with that compression residue. A bit more on this. When above Transport as in 8824, the port number needs to know how to process the RuleID. When below IP as in 9011, the MAC needs a type assigned for SCHC to know to use the RuleID for IP/whatever expansion. MAC types are not the IETF's problem. It takes something like ESP that sits below Transport, to change this. Thus this COULD be an lpwan issue for introducing SCHC, or it could be an ipsecme issue as as far as I can think, only ESP presents this issue. Do you think you can draw a boundary around your use case such that the "static context" would indicate when to (not) use the compression techniques? I can, except for the CoAP part which I have not plowed into yet. Only getting started on the actual transactions and thus what is needed from CoAP, and CBOR. I believe that the UDP header will compress to zero bytes, which is good... ___ 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] Transport ESP and SCHC
On 4/19/22 23:15, Benjamin Kaduk wrote: On Tue, Apr 19, 2022 at 11:09:26PM -0400, Robert Moskowitz wrote: Has there been any discussion about Transport ESP and SCHC from lpwan? https://datatracker.ietf.org/doc/draft-ietf-lpwan-architecture/ In Sec 5, the assumption is the security envelope is above UDP. e.g. DTLS and QUIC. No consideration for ESP Transport. RFC 8824 only deals with CoAP and not UDP. SCHC does not have an IP Protocol Number, thus I can't use it in ESP Next Header. The first "SC" is for "static context", i.e., you're supposed to just know, from an external (fixed/static) context, when the header compression is/isn't to be used. Since you "just know" when to use it, no in-band signaling such as IP protocol number is needed, at least in the original envisioned use cases. Yet in 8724, they define a in-band header: |--- Compressed Header ---| +-++ | RuleID | Compression Residue | Payload | +-++ How do you include this? This is especially needed with CoAP, rfc 8824. What is preconfigured is what does the RuleID instruct you to do with that compression residue. Do you think you can draw a boundary around your use case such that the "static context" would indicate when to (not) use the compression techniques? I can, except for the CoAP part which I have not plowed into yet. Only getting started on the actual transactions and thus what is needed from CoAP, and CBOR. I believe that the UDP header will compress to zero bytes, which is good... ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Transport ESP and SCHC
Has there been any discussion about Transport ESP and SCHC from lpwan? https://datatracker.ietf.org/doc/draft-ietf-lpwan-architecture/ In Sec 5, the assumption is the security envelope is above UDP. e.g. DTLS and QUIC. No consideration for ESP Transport. RFC 8824 only deals with CoAP and not UDP. SCHC does not have an IP Protocol Number, thus I can't use it in ESP Next Header. My application is Network Remote ID for Unmanned Aircraft Systems... Interested in any past discussions on this subject and any view about ESP and lpwan. Thanks Bob ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Can selected IPv6 Headers be part of Authenticated Data with ESP-GCM?
I have an interesting use case for a new IPv6 header that MAY be secure within the ESP payload, or MAY be exposed for inroute processing, but MUST be protected (authenticated data). My cursory review is not showing this is currently supported. Is it, our would I need to define a variant of the AES-GCM mode? Thanks ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] revisiting 3DES and -graveyard
Just as an aside thought about 3DES: perhaps you saw my questions to the CFRG list where I have exactly 64 bits to encrypt and no place for an IV or such. One of the serious suggestions WAS 3DES with 3 keys. For a number of reasons I am not offering that in the initial ID, rather AES-CFB16... But for only 64 bits to encrypt, 3DES is a consideration. Nah. (also it may change to exactly 96 bits to encrypt. They left out the UA Altitude and the FAA is not happy with that). Have a good weekend all! On 4/15/20 8:49 AM, Tero Kivinen wrote: Benjamin Kaduk writes: I see in https://datatracker.ietf.org/meeting/104/materials/minutes-104-ipsecme-00 that we didn't want to get rid of 3DES at that time. Do we have a sense for how quickly that will change, the scope of existing deployments, etc.? One of the problems is that we as an IETF give instructions to implementors, not to users. If we change 3DES MUST NOT, then all implementations out there who do implement 3DES, but where it is disabled in configuration by default are no longer conformant to the new RFC, as they do still implement 3DES. Anybody who puts 3DES in any of the new implementations or new releases of the current implementations are going against the SHOULD NOT in the current RFC. Meaning they most likely have some old legacy stuff they need to support which only supports 3DES and thats why they want to keep 3DES in their current releases as they want to be able to talk to those. I would wait bit more than 2.5 years before saying MUST NOT. In particular, would a general-purpose OS's implementation cause problems for its consumers if the next release dropped support? (Noting that consumers could stay on an old OS release to match the old algorithms, at least for a while.) Especially with consumers and general-purpose OS there is no option for using old OS release anymore. Most of those will automatically update to latest version, and there usually isn't any easy way to downgrade back to previous version when issues are found. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IPSECKEY Resource Record Parameter for EdDSA
On 10/11/19 5:44 AM, Michael Richardson wrote: Robert Moskowitz wrote: > At some point I am going to need one, as 8005 references IPSECKEY for > its RR and I am using EdDSA for the tm-rid work. I was surprised at the 8005 reference to IPSECKEY, since it seemed wrong that a IPSECKEY RR would point at some machine that was going to answer with HIP and not IKEv2... but now I see that you have your own RR, but share the algorithm numbers with IPSECKEY. there was an attitude to not maintain 2 separate number spaces. Now I have to live with that (how would I handle the ECDH Identities for HIP-DEX which I do not belive IKE has anything similar?) It seems that your tm-rid work can just amend this IANA registry. If you had a WG, you could ask for an early allocation. I don't think that the IPSEC WG chairs could ask for an early allocation for you at this point, alas. The way I see it, rfc 8420 'requires' this allocation. I suspect whatever works for 8420 will work for draft-moskowitz-hip-new-crypto. So I am being 'nice' and asking the owners of the IPSECKEY namespace to fix what I see as a shared problem. I really don't want to go down a path of having a tm-rid wg doing the allocation. Bob ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IPSECKEY Resource Record Parameter for EdDSA
On 10/11/19 5:26 AM, Michael Richardson wrote: Robert Moskowitz wrote: > Is there an update for EDDSA (RFC 8420) for the ipseckey RR? > https://www.iana.org/assignments/ipseckey-rr-parameters/ipseckey-rr-parameters.xhtml > IANA is not showing it, so perhaps it is in a draft somewhere? I haven't done this. It's marked IETF Review, so a document is needed (but necessarily standards track). What's your use case today? Surely not tm-rid? Yes it is tm-rid. Look for a revision to https://datatracker.ietf.org/doc/draft-moskowitz-hip-hhit-registries/ Any observer should have access to the HI on observing the HIT in the RemoteID Basic Message. This is needed to validate the signature in the Authentication Message. Only an authorized observer can query the USS for more information (as Stu alluded to) about the UAV. In the ASTM docs we cannot release yet (grumble) they propose both SAML and JSON for the query for these details by an authorized observer. Thus only the HI/HIT will be returned in the DNS query. RVS is normally restricted information. Bob ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IPSECKEY Resource Record Parameter for EdDSA
ok At some point I am going to need one, as 8005 references IPSECKEY for its RR and I am using EdDSA for the tm-rid work. Since we have a PK length field, that can separate Ed25519 from Ed448. Right now we are framing our hackathon effort so will just use something. Like 4. On 10/10/19 4:33 PM, Paul Wouters wrote: Not yet, Also my idea was the skip ECDSA (8-11) and only do one for DigitalSignatures (14) style pubkey (RFC 7427) Paul Sent from my iPhone On Oct 10, 2019, at 16:11, Robert Moskowitz wrote: Is there an update for EDDSA (RFC 8420) for the ipseckey RR? https://www.iana.org/assignments/ipseckey-rr-parameters/ipseckey-rr-parameters.xhtml IANA is not showing it, so perhaps it is in a draft somewhere? Thanks ___ 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] IPSECKEY Resource Record Parameter for EdDSA
Is there an update for EDDSA (RFC 8420) for the ipseckey RR? https://www.iana.org/assignments/ipseckey-rr-parameters/ipseckey-rr-parameters.xhtml IANA is not showing it, so perhaps it is in a draft somewhere? Thanks ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [Hipsec] HIT collision probability
On 05/05/2014 04:23 PM, Rene Struik wrote:
Hi Bob:
Let me clarify, the quantity p(k,n) below is the probability that k
randomly picked elements taken from an n-set are all different (i.e.,
no collision occurs). You may be looking for the probability of having
at least one collision, which is 1 - p(k,n).
I hope this helps.
that was it. I missed that smallish detail. thanks.
Rene
On 5/5/2014 4:19 PM, Robert Moskowitz wrote:
On 05/05/2014 03:32 PM, Rene Struik wrote:
Hi Bob:
The formula is roughly p(k,n)=1*(1-1/n)*(1-2/n)*...*(1 - {k-1}/n),
which can be approximated as roughly e^{-k^2/(2n)}, where n is the
size of the set one takes uniformly selected samples from and where
k is the number of drawn samples.
I am doing something wrong in LibreCalc with the formula:
=EXP(-(B6^2)/(2*C6))
Where B6 is the cell with K (3.86e+12) and C6 is n (2^96). I am
getting an answer of 99%.
Rene
On 5/5/2014 2:50 PM, Robert Moskowitz wrote:
On 05/04/2014 11:40 AM, Robert Moskowitz wrote:
What population of HIs is needed for a 1%, 10%, 50% probability of
a HIT collision?
I had the math once (like back in '99 or '00) and can't find it
(probably did not survive the Eudora to Thunderbird migration).
Thought I actually had this in a very early draft, but could not
find any such beast. Of course that would have been for HIPv1
HITs, not HIPv2.
Any help on the math would be appreciated. Also does it change
with PK algorithm or key length? (seems not to me).
Using the code at: http://en.wikipedia.org/wiki/Birthday_attack
and compiling and running it via:
http://www.compileonline.com/compile_cpp11_online.php
I get the following probablities for HIT collisions:
First the population of HITs (96 bits of hash) is: 7.9×10²^(8)
Then the probablities of collision are:
.01%3.98076e+12
.1%1.25911e+13
1%3.99066e+13
10%1.29209e+14
And thus if each person in the world (7B) had 5 endpoints with HITs
on them, the probablity
of a collision would be 10^-6 % (p=e-8, pop=3.98066e+10).
___
Hipsec mailing list
hip...@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec
--
email:rstruik@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--
email:rstruik@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
___
Hipsec mailing list
hip...@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec
