Nicolas Williams writes:
On Wed, Oct 14, 2009 at 02:36:20PM +0300, Tero Kivinen wrote:
Yes. That was what I tried to say. Do you think my already changed
sentence is ok, or do we need to explain it more.
Well, the heuristics will benefit from the information cached for the
TCP/UDP flow
Tero Mononen writes:
Overall comments:
The draft contains quite a lot of background information (what you are
trying to achieve on technical point of view, what were the
alternative solutions considered). Part of this background is also
available on WESP draft.
Making this
Submitted now a new version of the heuristics draft, which includes
changes from Williams, Mononen, Richardson, Graveman and Moononen.
This should now include all changes that were requested, if I missed
some, send me a note.
Draft can already be found from the ietf repository
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Maintenance and Extensions Working
Group of the IETF.
Title : Heuristics for Detecting ESP-NULL packets
Author(s) : T. Kivinen, D.
They are at http://www.ietf.org/proceedings/09nov/minutes/ipsecme.txt; please
let Yaron or I know if you find any errors.
FWIW, Gabriel got them to us almost immediately after the meeting, so the
lateness is the fault of your WG chairs, not of the minutes-taker.
--Paul Hoffman, Director
--VPN
We earlier agreed in issue #50 to make the KEr in Section 1.3.2 (Rekeying IKE
SAs with the CREATE_CHILD_SA Exchange) mandatory:
-- HDR, SK {SA, Nr, KEr}
Note that this is not in the current draft, but will be in the next one.
So, what happens if the responder does
The 4th paragraph of section 3.3 says If an algorithm that combines encryption
and integrity protection is proposed, it MUST be proposed as an encryption
algorithm and an integrity protection algorithm MUST NOT be proposed. This
means that an integrity protection algorithm can only be proposed
On Mon, Nov 23, 2009 at 04:32:43PM -0800, Paul Hoffman wrote:
The second sentence seems wrong. Proposed rewording:
For example,
[AEAD] specifies additional formats based on authenticated
encryption, in which the integrity algorithm is an inherent
part of the combined algorithm; in
At 8:12 PM -0500 11/23/09, Dan McDonald wrote:
On Mon, Nov 23, 2009 at 04:37:22PM -0800, Paul Hoffman wrote:
This has flummoxed a few reviewers. Tables such as those in section 3.3.2
are already out of date because things have been added since RFC 4306. I
propose that we remove all these
On Mon, Nov 23, 2009 at 08:37:32PM -0500, Dan McDonald wrote:
SNIP!
The warning and URL is the critical part.
are the critical part, - uggh, mustn't press Send so quickly.
Dan
___
IPsec mailing list
IPsec@ietf.org
At 8:37 PM -0500 11/23/09, Dan McDonald wrote:
On Mon, Nov 23, 2009 at 05:27:36PM -0800, Paul Hoffman wrote:
Can you move 'em to an appendix, with a permanent URL reference to the IANA
up-to-date versions?
As long as you mean an appendix that clearly says 'these were in RFC 4306
but are now
Hi Paul,
Please add to Issue #123 a list of the affected tables. For example, I wouldn't
imagine the list of notification types moving away, even though it's already
been extended by IANA. Similarly for the stuff in Sec. 3.6, which is strongly
related to descriptive text.
Thanks,
And this is exactly the table that I claim needs to remain in the spec. A list
of errors - even if partial! - is essential to understanding a protocol.
Thanks,
Yaron
-Original Message-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
Paul Hoffman
13 matches
Mail list logo
