On Thu, 2 Nov 2017, Valery Smyslov wrote:
RFC7427 allows peers to indicate hash algorithms they support, thus
eliminating ambiguity in selecting a hash function for digital signature
authentication. However, recent advances in cryptography lead to a situation
when some signature algorithms hav
Valery Smyslov writes:
> Hi Tero,
>
> how about:
>
> RFC7427 allows peers to indicate hash algorithms they support, thus
> eliminating ambiguity in selecting a hash function for digital signature
> authentication. However, recent advances in cryptography lead to
> a situation when some signatur
Hi Tero,
how about:
RFC7427 allows peers to indicate hash algorithms they support, thus
eliminating ambiguity in selecting a hash function for digital signature
authentication. However, recent advances in cryptography lead to
a situation when some signature algorithms have several signature fo
Sahana Prasad writes:
> We could consider adding this item to the working charter :
>
> Explicitly negotiating different RSA versions (Specific case) :
If you want it to be considered as charter item, please provide text
suitable for charter.
--
kivi...@iki.fi
_
Hello,
We could consider adding this item to the working charter :
Explicitly negotiating different RSA versions (Specific case) :
According to section 3.2 of rfc-8247 (was rfc-4307 bis) ,it is mentioned
that :
" When the Digital Signature authentication method is used with RSA
signatur
> -Original Message-
> From: Paul Wouters [mailto:p...@nohats.ca]
> Sent: Saturday, October 28, 2017 10:28 PM
> To: Hu, Jun (Nokia - US/Mountain View)
> Cc: Valery Smyslov ; 'Tero Kivinen' ;
> ipsec@ietf.org
> Subject: Re: [IPsec] Agenda for IETF 100
&g
Hi,
A few years ago, we worked on fail-over, load balancing.. [1] and would be
happy to help.
Yours,
Daniel
[1]
https://tools.ietf.org/html/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-01
On Sun, Oct 29, 2017 at 2:55 AM, Valery Smyslov wrote:
> Hi,
>
> The problem with IKE Redirect is t
Hi,
The problem with IKE Redirect is that it requires IKE SA to be re-established
from scratch.
It consumes quite a lot of resources and takes noticeable amount of time.
Moreover, in some cases it could require human interaction (in case of some
EAP methods or if access to client's credentials r
On Sat, 28 Oct 2017, Hu, Jun (Nokia - US/Mountain View) wrote:
[HJ] why RFC 5685 (Redirect Mechanism for the Internet Key Exchange
Protocol Version 2 (IKEv2)) can't be used for this purpose?
The problem with IKE Redirect is that it requires IKE SA to be re-established
from scratch.
It consumes
> -Original Message-
> From: Valery Smyslov [mailto:sva...@gmail.com]
> > 1. Develop load sharing cluster solution for IKEv2/IPsec. The possible
> > charter
> > text:
> >
> > MOBIKE protocol [RFC4555] is used to move existing IKE/IPsec SA from
> > one IP address to another. However, in MO
Hi Jun,
1. Develop load sharing cluster solution for IKEv2/IPsec. The possible charter
text:
MOBIKE protocol [RFC4555] is used to move existing
IKE/IPsec SA from one IP address to another. However,
in MOBIKE it is the initiator of the IKE SA (i.e. remote access client)
that controls this proces
> From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Valery Smyslov
> 1. Develop load sharing cluster solution for IKEv2/IPsec. The possible charter
> text:
>
> MOBIKE protocol [RFC4555] is used to move existing
> IKE/IPsec SA from one IP address to another. However,
> in M
Hi Valery,
Absolutely, Diet-IKE would be a nice item have in the charter as well, but
this is a different item.
Currently the work on compressing esp has two items:
* draft-mglt-ipsecme-diet-esp defines how to esp.
* draft-mglt-ipsecme-ikev2-diet-esp-extension defines how peers agree on
using die
Hi Daniel,
probably we need to consider Diet-IKE too? Aa companion for Diet-ESP.
And what is draft-ipsecme-ikev2-extention? I cannot find such a draft...
Regards,
Valery.
We support the proposals and will publish updated the documents regarding
diet-esp and its associated IKEv2 extension. We bel
On Thu, 26 Oct 2017, Tero Kivinen wrote:
In last IETF we had people with items which we could add to charter,
so I want those people wanting to add things to charter to send an
email to the mailing list about what items they would like to propose
to the charter, and preliminary charter text for
Don't forget to add this as a BoF:
https://www.youtube.com/watch?v=FoUWHfh733Y
:)
X
On Fri, 27 Oct 2017, Daniel Migault wrote:
We support the proposals and will publish updated the documents regarding
diet-esp and its associated IKEv2 extension. We believe
draft-mglt-ipsecme-diet-esp and dra
We support the proposals and will publish updated the documents regarding
diet-esp and its associated IKEv2 extension. We believe
draft-mglt-ipsecme-diet-esp and draft-ipsecme-ikev2-extention could be a
good starting point.
The proposed text for the charter could be:
A growing number of use cases
+ 1 to these proposals
I'd also like to see the work on drafts like DIET-ESP
(draft-mglt-ipsecme-diet-esp-04) be incorporated. I think we'll have some
growing use cases for IPsec in constrained networks, and as that develops,
extensions and modifications to the protocol to make IKEv2 and ESP wo
Hi,
I think that the following items can be considered for the new charter.
1. Develop load sharing cluster solution for IKEv2/IPsec. The possible charter
text:
MOBIKE protocol [RFC4555] is used to move existing
IKE/IPsec SA from one IP address to another. However,
in MO
There used to be a special working group for multicast security. That has
closed, so IPsecME is the natural home for this work:
The Group Domain of Interpretation (GDOI - RFC 6407) is an IKEv1-based
protocol for negotiating group keys for both multicast and unicast uses. The
Working Group will
We will be meeting at Monday morning 09:30-11:00 for 1.5 hours. Our
main agenda item will be the rechartering text, i.e., our charter will
expire by the end of year, and we have most of our chartered work
already completed, or almost finished, so we need to decide what new
items (if any) we take to
21 matches
Mail list logo
