concerns.
thanks,
Gabriel
- Original Message
> From: Russ Housley
> To: gabriel montenegro
> Cc: "ipsec@ietf.org"
> Sent: Tue, January 5, 2010 2:52:24 PM
> Subject: Re: [IPsec] Traffic visibility - consensus call
>
> Gabriel:
>
> > Some of us belie
--- Original Message
> From: Russ Housley
> To: gabriel montenegro
> Cc: "ipsec@ietf.org"
> Sent: Tue, January 5, 2010 1:11:19 PM
> Subject: Re: [IPsec] Traffic visibility - consensus call
>
> Gabriel:
>
> This is being discussed to resolve the concerns tha
Hi Russ,
I'd like to comment on your assumption below that:
> ...the ICV protection
> imposes a requirement that the end system check the WESP information that it
> does not need, and then discard the packet if the attacker altered it to the
> potential detriment of the middlebox"
The underly
, etc.
What we're seeing is: oh, ok, let's do it all over again.
- Original Message
> From: Paul Hoffman
> To: gabriel montenegro ; "ipsec@ietf.org"
>
> Sent: Tue, January 5, 2010 11:14:36 AM
> Subject: Re: [IPsec] Traffic visibility - consensus cal
Yes to both questions.
But I'd also like to question the process being followed. We've discussed these
points numerous times
in f2f meetings, on the mailing list, at virtual interims, etc. So I'm
surprised to see the already
established consensus being questioned all over again. Some of the arg
As I recall, folks expressed that if one were to use WESP for ESP-NULL, it
would be good to be able to use it for encryption as well to be able to use a
consistent packet format.
This was issue 84:
http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/84
Discussed at IETF 74 and 75 as well as on th
Just to make sure this does not fall through the cracks: we've submitted rev 09
last week to address
the AD review comments per discussion on the mailing list and at the virtual
interim.
- Original Message
> From: Yaron Sheffer
> To: Tero Kivinen ; "Grewal, Ken"
> Cc: "ipsec@ietf.or
Thanks Tero. Good catches. We'll address them in the upcoming revision.
> -Original Message-
> From: Tero Kivinen [mailto:kivi...@iki.fi]
> Sent: Monday, 24 August, 2009 6:03 AM
> To: ipsec@ietf.org
> Cc: draft-ietf-ipsecme-traffic-visibil...@tools.ietf.org; ipsecme-
> cha...@tools.ietf.or
beginning of the Rest of Payload Data (i.e., past the IV,
if present) within the encapsulated ESP header, inoctets.
Gabriel
>
>From: gabriel montenegro
>To: Yoav Nir ; Yaron Sheffer ;
>"ipsec@ietf.org"
>Sent: Monday, July 13, 2009 9:05:23 AM
>Subject: Re: [IPs
Hi Yoav,
Good catch, we say offset *to* what, but we don’t say *from* where.
Among the co-authors, we'd like to suggest this as a simple text change to
address this:
OLD:
HdrLen, 8 bits: Offset to the beginning of the Payload Data in
octets.
NEW:
HdrLen, 8 bits: Offset from the
on to drop the offending packet?
- Original Message
> From: Stephen Kent
> To: "Bhatia, Manav (Manav)"
> Cc: "ipsec@ietf.org" ; gabriel montenegro
> ; Tero Kivinen
> Sent: Tuesday, May 12, 2009 8:18:18 AM
> Subject: Re: [IPsec] Next Header field
Per my recollection, during the interim last week, Yaron clarified that even
though he had made
the suggestion to do away with the Next Header field, he did not feel strongly
about it.
His point is valid, though: if it is not found to be useful, then the field
should not be included.
Your po
I'll just comment on one item below:
> As the draft says this is mostly meant for stateful devices, and that
> has been the main goal for the document. The charter says:
>
> "A standards-track mechanism that allows an intermediary device, such
> as a firewall or intrusion detection system ..."
>
I'd like to ask the chairs to comment further about something
they (Paul) said during the virtual interim about Tero's
heuristics draft. From the minutes:
Paul said that we will discuss on the list before we
decide which direction we will go
What directions do you see possible? I can see
14 matches
Mail list logo
