-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> "Dan" == Dan Harkins writes:
>>> 2. solves the specific problem it is aimed at poorly-- doubling
>>> of the number of messages, requiring writing and testing of new
>>> state EAP state machines that are, otherwise, unnecessary; and,
I believe that this is a useful extension to IKEv2.
I am willing to review drafts, and I might co-author.
Thanks,
-Amjad
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
I am also supporting this extension. I am at least willing to review drafts,
probably add text.
Regards,
Daniel
On Mon, Dec 7, 2009 at 2:36 PM, Amjad Inamdar (amjads) wrote:
> I believe that this is a useful extension to IKEv2.
> I am willing to review drafts, and I might co-author.
> Thanks,
>
I will also review this document.
Regards,
Daniel
On Fri, Dec 4, 2009 at 4:17 AM, Michael Richardson wrote:
> Yaron Sheffer wrote:
>
>> This work item will define the problem statement and requirements for a
>> solution that allows interoperable HA/LS device groups. Mixed-vendor
>> clusters are
On Fri, 2009-12-04 at 12:46 -0600, Nicolas Williams wrote:
> On Fri, Dec 04, 2009 at 01:39:46PM -0500, Dan McDonald wrote:
> > The bigger point being missed by this thread, I think, is that it
> > seems that any work in multi-level security needs to deal with
> > successful interoperability. If i
On Fri, 2009-12-04 at 13:39 -0500, Dan McDonald wrote:
> On Fri, Dec 04, 2009 at 12:09:50PM -0600, Joy Latten wrote:
>
>
>
> > I believe they are becoming more mainstream. For example, SELinux and
> > Simplified Mandatory Access Control (SMACK) in Linux Operating System
> > and Mandatory Integri
I am interested in WESP extensibility proceeding as a chartered work item.
I will commit to reviewing the draft, and providing text. I don't need to be
a co-author.
bs
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Yaron
Sheffer
Sent: Sunday, November 29, 2009 9:2
Brian,
I wasn't sure, form your brief description, whether you envisioned
any crypto protection for this version of WESP. If not, then this
added info is not protected and might be modified en route. This
seems like a possibly dangerous feature, as it says that we are
causing an intermediate
0 - option data does not change en-route. This option is
included in the WESP ICV computation.
We'll be using this flag, so this option will always be integrity protected.
I'm not sure what you mean by effecting key distribution.
In the integrity only case, the intermediaries can still see
Hi,
After a discussion on the scope of this draft, I decided to change my
opinion regarding what I said during the IETF meeting: now, I am ready
to review the draft but no more to contribute to it.
Best regards.
JMC.
2009/11/29 Yaron Sheffer :
> This work item will define the problem statement
At 6:24 PM + 12/7/09, Brian Swander wrote:
0 - option data does not change en-route. This option is
included in the WESP ICV computation.
We'll be using this flag, so this option will always be integrity protected.
integrity protected for checking by the end system, but not
verifiable
In case it wasn't clear for the earlier WESP discussions, we need this to also
work with simple transport mode: i.e. not just transport mode inside tunnels
terminating at various infrastructure, and not just in tunnel mode.
The transport nesting from 2401 doesn't give us what this extension pr
Hi Michael,
Here's some figures from I-Ds to illustrate what I'm talking about.
Some of the overhead is because both of these are technically client-
server protocols but IKEv2 is initiated by the initiator/client and
EAP is initiated by the responder/server (due to fact that it's design
was
On Mon, Dec 07, 2009 at 10:10:15AM -0600, Joy Latten wrote:
> > The proposed work item is, at first glance anyways, too SELinux-
> > specific.
> >
> > Note that SMACK encodes its labels as CIPSO labels, so a scheme that
> > uses CIPSO can possibly be used in SMACK and non-SMACK environments, and
>
On Monday 07 December 2009 11:10:15 am Joy Latten wrote:
> On Fri, 2009-12-04 at 12:46 -0600, Nicolas Williams wrote:
> > On Fri, Dec 04, 2009 at 01:39:46PM -0500, Dan McDonald wrote:
> > > The bigger point being missed by this thread, I think, is that it
> > > seems that any work in multi-level se
Nicolas Williams wrote:
...snip...
- A separate I-D for adding labeling information to certificates.
Are you suggesting that you'd label a certificate? I suspect what
you're talking about is including what labels a user/device supports and
the clearance attribute in the RFC 3281 update
(ht
At 7:50 PM + 12/7/09, Brian Swander wrote:
In case it wasn't clear for the earlier WESP discussions, we need
this to also work with simple transport mode: i.e. not just
transport mode inside tunnels terminating at various infrastructure,
and not just in tunnel mode.
The transport nesting
Paul,
From your comments it seems as though an IP option would be
preferable, as it is not IP-sec-specific, and it an be protected if
needed, in the IPSec context, e.g., via tunneling.
Steve
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org
On Mon, Dec 07, 2009 at 04:37:50PM -0500, Paul Moore wrote:
> At the SELinux Developer's Summit a few months ago there was a bit of a
> general discussion about DOIs and label representation between myself (Linux
> labeled networking), Dave Quigley (labeled NFS, added to CC) and Casey
> Schaufle
On Monday 07 December 2009 05:16:26 pm Stephen Kent wrote:
> Paul,
>
> From your comments it seems as though an IP option would be
> preferable, as it is not IP-sec-specific, and it an be protected if
> needed, in the IPSec context, e.g., via tunneling.
Exactly. Since the option would be immuta
On Mon, Dec 07, 2009 at 04:40:05PM -0500, Sean Turner wrote:
> Nicolas Williams wrote:
> ...snip...
> > - A separate I-D for adding labeling information to certificates.
>
> Are you suggesting that you'd label a certificate? I suspect what
> you're talking about is including what labels a user/d
On Monday 07 December 2009 04:51:10 pm Nicolas Williams wrote:
> On Mon, Dec 07, 2009 at 04:37:50PM -0500, Paul Moore wrote:
> > I've mentioned all of this before, but my main fundamental concern with
> > the proposed labeled IPsec spec is that not everyone who wants labeled
> > networking wants I
On Mon, Dec 07, 2009 at 05:53:59PM -0500, Paul Moore wrote:
> > But this is not a reason to oppose labelled IPsec. It's a reason to
> > want an extended IP packet labelling standard.
>
> Why spend the time and effort to develop two specifications (not to mention
> the actual implementations) whe
On Mon, 2009-12-07 at 15:02 -0600, Nicolas Williams wrote:
> On Mon, Dec 07, 2009 at 10:10:15AM -0600, Joy Latten wrote:
> > > The proposed work item is, at first glance anyways, too SELinux-
> > > specific.
> > >
> > > Note that SMACK encodes its labels as CIPSO labels, so a scheme that
> > > use
On Monday 07 December 2009 06:20:31 pm Dan McDonald wrote:
> On Mon, Dec 07, 2009 at 05:53:59PM -0500, Paul Moore wrote:
> > > But this is not a reason to oppose labelled IPsec. It's a reason to
> > > want an extended IP packet labelling standard.
> >
> > Why spend the time and effort to develop t
On Mon, 2009-12-07 at 16:37 -0500, Paul Moore wrote:
> On Monday 07 December 2009 11:10:15 am Joy Latten wrote:
> > On Fri, 2009-12-04 at 12:46 -0600, Nicolas Williams wrote:
> > > On Fri, Dec 04, 2009 at 01:39:46PM -0500, Dan McDonald wrote:
> > > > The bigger point being missed by this thread, I
On Mon, Dec 07, 2009 at 06:59:13PM -0500, Paul Moore wrote:
> On Monday 07 December 2009 06:20:31 pm Dan McDonald wrote:
> > On Mon, Dec 07, 2009 at 05:53:59PM -0500, Paul Moore wrote:
> > > Why spend the time and effort to develop two specifications (not to
> > > mention the actual implementations
Nicolas Williams wrote:
On Mon, Dec 07, 2009 at 04:40:05PM -0500, Sean Turner wrote:
Nicolas Williams wrote:
...snip...
- A separate I-D for adding labeling information to certificates.
Are you suggesting that you'd label a certificate? I suspect what
you're talking about is including what la
On Mon, 2009-12-07 at 18:41 -0600, Nicolas Williams wrote:
> On Mon, Dec 07, 2009 at 06:59:13PM -0500, Paul Moore wrote:
> > On Monday 07 December 2009 06:20:31 pm Dan McDonald wrote:
> > > On Mon, Dec 07, 2009 at 05:53:59PM -0500, Paul Moore wrote:
> > > > Why spend the time and effort to develop
On Monday 07 December 2009 07:41:21 pm Nicolas Williams wrote:
> On Mon, Dec 07, 2009 at 06:59:13PM -0500, Paul Moore wrote:
> > On Monday 07 December 2009 06:20:31 pm Dan McDonald wrote:
> > > On Mon, Dec 07, 2009 at 05:53:59PM -0500, Paul Moore wrote:
> > > > Why spend the time and effort to deve
30 matches
Mail list logo
