As with the other document, I also support adoption. (Still
unsurprisingly since I'm a co-author :-P )
David
On Fri, Dec 8, 2023 at 9:28 AM William Atwood
wrote:
> I support adoption of this draft. It will be useful for the secure
> exchanges in ANIMA environments (i.e., everything!),
I also support adoption. (Unsurprisingly since I'm a co-author :-) )
David
On Fri, Dec 8, 2023 at 9:27 AM William Atwood
wrote:
> I support adoption of this draft. It will be useful for the secure
> exchanges in ANIMA environments (i.e., everything!), especially in
> constrained environments.
I'm having a hard time imagining why anyone would want to use
NO_NATS_ALLOWED with TCP encapsulation. If you're encapsulating in TCP it
means that there is something on path even worse than a NAT, right?
Perhaps we could simply say you MUST NOT use NO_NATS_ALLOWED with TCP
encaps?
David
On Thu,
Hi,
I have read and reviewed the last few revisions of the draft and I believe it
is ready for publication.
I also implemented Implicit IV for ChaCha20-Poly1305 and it was pretty
straightforward.
Thanks,
David Schinazi
> On Jun 18, 2018, at 09:17, Daniel Migault wrote:
>
> as a
Thanks for the update, authors! I've reviewed -03 and it looks great to me.
David
> On May 9, 2018, at 13:09, internet-dra...@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the IP Security Maintenance and
roblem statement and potential solution in London.
I would personally recommend not deciding on its addition to the charter until
this has been discussed.
Thanks,
David Schinazi
> On Mar 4, 2018, at 12:18, Tero Kivinen <kivi...@iki.fi> wrote:
>
> There was very little discus
Hi Yoav, responses inline.
> On Feb 16, 2018, at 10:25, Yoav Nir wrote:
>
>> On 16 Feb 2018, at 20:13, Tero Kivinen wrote:
>>
>> 1) It's not possible to run a server that obfuscates IKEv2/IPsec using
>> TLS.
>>
>> Today thanks to RFC 8229 it is
Hi Paul,
Regarding the original email, I'm not a fan of (1) as then implementations
have to handle receiving two different FQDN IDr's for example.
Having something like (2) where the new notify can only appear once
and it explicitly is there to select the key sounds best IMHO.
Regarding the
mechanism to IKEv2 that allows the initiator to only send
IDi/IDr to known entities (e.g. that possess a shared secret).
Thanks,
David Schinazi
> On Nov 16, 2017, at 22:35, mohamed.boucad...@orange.com wrote:
>
> Dear Tero,
>
> It seems that you missed this text for the addr
I suspect that there was a typo and Yoav meant to include the flags for
proposal 2:
| Next Payload (8 bits) | Flags (8 bits) | Fragment Counter (16 bits) | Message
ID (32 bits) |
In that case I do prefer option 2 as it doesn't add much complexity and allows
fragmentation.
David
> On Nov
.
I had written up a proposed solution here:
https://www.ietf.org/mail-archive/web/ipsec/current/msg11575.html
<https://www.ietf.org/mail-archive/web/ipsec/current/msg11575.html>
Regardless of the solution, I think there is value in adding these items to the
charter.
Thanks,
David Sc
anything.
> On Aug 16, 2017, at 09:50, Christopher Wood <christopherwoo...@gmail.com>
> wrote:
>
> On Wed, Aug 16, 2017 at 9:34 AM, Paul Wouters <p...@nohats.ca> wrote:
>> On Mon, 14 Aug 2017, David Schinazi wrote:
>>
>>> [DS] I think "showin
Thanks Paul, responses inline.
> On Aug 11, 2017, at 18:23, Paul Wouters <p...@nohats.ca> wrote:
>
> On Fri, 11 Aug 2017, David Schinazi wrote:
>
>> 1) Active man-in-the-middle attack against the initiator
>> An attacker that can intercept and spoof packets can
rties of the current
draft, it also does not leak any information to any party that does not possess
PPK, and it mitigates the attack vectors discussed above.
What are your thoughts?
Thanks,
David Schinazi
Apple
___
IPsec mailing list
IPsec@ietf.org
Thanks for the update!
I've reviewed -04 and I think the draft is ready to move forward.
Regards,
David Schinazi
> On Mar 28, 2017, at 15:43, Daniel Migault <daniel.miga...@ericsson.com> wrote:
>
> Hi,
>
> Thank you Jim for the update. Here is the version resulting from
Hello all,
I strongly support adoption of this document.
I have read it and implemented it.
The document reads well, and allows independent implementations.
I personally think Implicit IV is a great step forward for IKEv2/IPsec, even
outside of IoT.
Regards,
David Schinazi
> On Mar 29, 2
Hello all,
I strongly support the WG adoption of this draft.
Regards,
David Schinazi
> On Mar 29, 2017, at 14:17, IETF Secretariat <ietf-secretariat-re...@ietf.org>
> wrote:
>
>
> The IPSECME WG has placed draft-mglt-ipsecme-implicit-iv in state
> Call For Adopti
Yoav,
The diff looks good to me.
Based on the discussion in this thread, it looks like there is consensus
to not use 0 as the value for Identity.
Would it make sense to reflect that in the document?
The "IANA Considerations" section currently states:
IANA is requested to assign a new value from
me
>> consensus on this. At this point, I'm mildly in favor of a new value (5).
>>
>> Thanks,
>> Tommy
>>
>>> On Feb 9, 2017, at 4:40 AM, Tero Kivinen <kivi...@iki.fi> wrote:
>>>
>>> Ah I noticed that my last call email had wrong d
Tero,
I've reviewed this draft. I support it and believe it is ready to move forward
towards becoming a standards-track RFC. Also, would it make sense to ask
IANA for early assignment of the code point? Using 0 sounds reasonable to me.
Minor typo in the introduction:
"we define a new value
You'll need to play DNS games if the VPN server if IPv4-only
(or if your VPN config gives you a server IPv4 address to connect to).
In that case you'll need to query the DNS64 server for the NAT64 prefix.
Apple's IKEv2 client uses an OS-provided API to synthesize an IPv6 address
from the
+ 1
David
> On Jan 13, 2016, at 14:51, Yoav Nir wrote:
>
> I believe around that time CFRG and TLS will be done with the signatures
> document and rfc4492bis respectively, so we could proceed and finish
> draft-ietf-ipsecme-safecurves.
>
> So count me as a +1 as well.
22 matches
Mail list logo