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
: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
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
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 IP
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 i
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
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
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
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
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 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:
>
> |--- Compress
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
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
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
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
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
so
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
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
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
: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
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
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
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
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
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
___
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
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
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
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
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.
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
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 hea
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
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
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
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
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
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:
>
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
aps? 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
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
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
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
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
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
: 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
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
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
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 request
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
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
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
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
53 matches
Mail list logo
