I am opposed to pursing this work at this time. The ongoing
discussion on the list suggests that the arguments put forth for WESP
use in the OSPFv3 context, the first concrete proposal outside of the
middlebox inspection context that motivated WESP, have not been
validated. The presentation
I think that there has been insufficient discussion of whether those
who wish to make use of IPsec to enforce mandatory access controls
require the facilities described by the folks who have proposed this.
At the WG meeting 2 weeks ago I made two observations:
- possible use of CIPSO for c
Jack,
Thanks for describing the additional selection criteria that must be
employed to avoid the problem I cited.
Given this more complete description of the selection criteria, I am
not convinced that that is a significant benefit for using WESP in
this context.
- Whether using WESP or j
At 12:19 AM +0300 11/30/09, Valery Smyslov wrote:
>>>For someone, who spent quite a lot of time working in this area, it is not
>>>difficult fo figure out what is really important and what is not. But, I
>>>think,
>>>a newcomer could be confused by a long list of all possible numbers.
>>
>>This an
For someone, who spent quite a lot of time working in this area, it is not
difficult fo figure out what is really important and what is not. But, I
think,
a newcomer could be confused by a long list of all possible numbers.
This answer is inconsistent, and that's the crux of the issue I have w
This work item will define the problem statement and requirements for a
solution that allows interoperable HA/LS device groups. Mixed-vendor clusters
are specifically out of scope; but single-vendor clusters should be fully
interoperable with other vendors' devices or clusters. The main challeng
This draft proposes an extensibility framework for WESP, as well as several
specific extensions.
Proposed starting point:
http://tools.ietf.org/id/draft-montenegro-ipsecme-wesp-extensions-00.txt.
Please reply to the list:
- If this proposal is accepted as a WG work item, are you committi
This work item proposes to extend IKEv2 (and IKEv1) so as to allow IPsec to be
used in environments that require Mandatory Access Control. It is envisioned
that this will be used by modern high-security operating systems, that go
beyond the currently supported Multilevel Security (MLS).
Propose
This work item proposes an IKEv2 extension to allow an IKE peer to quickly and
securely detect that its opposite peer has lost state. This is claimed to be
quicker than the current method, which is based on time outs.
Proposed starting point: http://tools.ietf.org/id/draft-nir-ike-qcd-05.txt or
This draft proposes a particular method for mutual authentication of IKEv2
peers using a short, low quality shared secret (a.k.a. "password"). The
proposal is to embed this method in the IKE exchange, rather than use EAP.
Proposed starting point:
http://tools.ietf.org/id/draft-harkins-ipsecme-s
This draft proposes an IKEv2 extension to allow the setup of an IKE SA with no
Child SA, a situation which is currently disallowed by the protocol.
Proposed starting point:
http://tools.ietf.org/id/draft-nir-ipsecme-childless-01.txt.
Please reply to the list:
- If this proposal is accepted a
This draft proposes an IKEv2 extension to allow mutual EAP-based authentication
in IKEv2, eliminating the need for one of the peers to present a certificate.
This applies to a small number of key-generating EAP methods that allow mutual
authentication.
Proposed starting point:
http://tools.ie
Hi everyone,
The following 7 messages request your input regarding the activities that were
proposed for the next phase of the IPsecME WG. This is an open process, and we
specifically request that you reply to the mailing list, rather than privately,
whether you are committing to review/author
13 matches
Mail list logo
