Brian Swander writes:
> 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.
One of the things that disturb me here is that AH was not acceptable
because of the compl
On Mon, Dec 07, 2009 at 06:59:13PM -0500, Paul Moore wrote:
> > You could have PAD entries that set labels. We do that today in
> > OpenSolaris.
>
> I apologize, but I'm not familiar with OpenSolaris's IPsec - do you use the
> pad to assign labels when none are present (the fallback case) or do
Hi,
I am willing to review multiple versions of the draft, contribute text
and co-author it.
Thanks
Jyothi
-Original Message-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
Of Jean-Michel Combes
Sent: Tuesday, December 08, 2009 12:10 AM
To: Yaron Sheffer
Cc: ips
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 think, is that it
On Monday 07 December 2009 11:59:51 pm Steven Bellovin wrote:
> On Dec 7, 2009, at 5:26 PM, Paul Moore wrote:
> > 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
On Dec 7, 2009, at 5:26 PM, Paul Moore wrote:
> 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
I would like to coauthor IKE/IPsec high availability and load sharing.
Looks like a challenging and intereting problem.
Thanks
-ns murthy
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
Of Daniel Migault
Sent: Monday, December 07, 2009
Hi
Interested in coauthoring this draft.
Thanks
-ns murthy
-Original Message-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
Of Michael Richardson
Sent: Friday, December 04, 2009 8:49 AM
To: ipsec@ietf.org
Subject: Re: [IPsec] Proposed work item: Childless IKE SA
In general I find the OA&M options useful and, if the work item is accepted,
would like to be a reviewer.
Thanks,
--Joe
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Joy Latten wrote:
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
uses CI
On Thu, Dec 03, 2009 at 10:18:48PM -0500, Michael Richardson wrote:
> Dan Harkins wrote:
> > 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, unnece
Hi Nico,
If I understand you correctly, EAP crypto binding is what IKEv2 provides by
default, by including the EAP MSK into the IKE AUTH payload (RFC 4306, sec.
2.16 and 2.15). I believe what Dan is discussing is enabling secure
transmission of ID parameters over the EAP channel (sorry...), whi
Casey Schaufler wrote:
Jarrett Lu wrote:
Without rehashing the statements made in above discussion threads,
it's probably helpful to have a realistic interoperability expectation
for labeled systems. Defining label formats and security mechanisms in
various networking protocols is important.
13 matches
Mail list logo
