Brian Swander writes:
> AH alone isn't good enough. We need solutions that also work with
> end-to-end encryption.
Then we are not talking about ESP-NULL traffic anymore, thus it falls
outside the scope of our WESP charter:
- A standards-track mechanism that allows an intermediary device, such
At 5:20 PM + 12/9/09, Brian Swander wrote:
AH alone isn't good enough. We need solutions that also work with
end-to-end encryption.
bs
I think you are saying that it is a goal of those who are proposing
the WESP extension work item to move beyond the original, stated
goals of WESP, and
AH alone isn't good enough. We need solutions that also work with end-to-end
encryption.
bs
-Original Message-
From: Tero Kivinen [mailto:kivi...@iki.fi]
Sent: Tuesday, December 08, 2009 3:26 AM
To: Brian Swander
Cc: Stephen Kent; ipsec@ietf.org
Subject: Re: [IPsec] Proposed work
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
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
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
extension proposal
does.
bs
-Original Message-
From: Brian Swander
Sent: Monday, December 07, 2009 10:25 AM
To: 'Stephen Kent'
Cc: ipsec@ietf.org
Subject: RE: [IPsec] Proposed work item: WESP extensibility
0 - option data does not change en-route. This option is
incl
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
] Proposed work item: WESP extensibility
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 s
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
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
WESP already helps middleboxes and the options for in-band monitoring,
error notification, etc are valuable. Additional options proposed by
Brian look interesting and should be considered.
For now I commit to reviewing but might also contribute some
text to the draft, as time permits.
I am interested in WESP Extension and would like to co-author it. Our
interest in WESP extensions are to ease IPsec deployment within Intranet
security AND Middle Boxes. We expect WESP would be able to provide Network
administrators information related on IPsec and Middleboxes interactions.
Regard
Yaron Sheffer wrote:
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.
I am not interested in any further extensions to WESP.
In particular,
I will be interested in reviewing this and might also contribute some
text to the draft.
Jack
On Sun, Nov 29, 2009 at 10:50 PM, Yaron Sheffer wrote:
> This draft proposes an extensibility framework for WESP, as well as several
> specific extensions.
>
>
>
> Proposed starting point:
> http://tool
I would like to review further versions of this draft and be interested in
contributing text.
regards,
Min
On Sun, 29 Nov 2009 19:18:59 +0200, Yaron Sheffer wrote:
This draft proposes an extensibility framework for WESP, as well as several
specific extensions.
Proposed starting point:
(Apologies if this is a dupe. I sent it out yesterday, but it still hasn't
shown up on the list yet, so I figured I better resend from a different
account).
Here is another WESP extension that we are interested in.
Packet Contents Option
0 1 2
[mail snipped]
> - If this proposal is accepted as a WG work item,
> are you committing to review multiple versions of the draft?
Yes
> - Are you willing to contribute text to the draft?
Yes
> - Would you like to co-author it?
Yes
I believe the OAM extension described in the draft is useful and
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
19 matches
Mail list logo
