All,
Working primarily from the HTML diff, towards the end of Section 3,
the draft -03 text says in part:
The IPsec community generally prefers ESP with NULL encryption
over AH, but AH is required in some protocols; further, AH is
more appropriate when there are
On 02 Apr 2014, at 13:25 , Paul Hoffman wrote:
That was certainly not the intention.
OK.
[IMPORTANT NOTE: A previous employer of mine shipped IPv4/IPv6 routers
with forwarding silicon that could parse AH and any other IPv4/IPv6
options - at wire-speed for 10 Gbps interfaces - 10 years ago.
On 02 Apr 2014, at 16:17 , Paul Hoffman wrote:
Actually, yes. Looking in the archives,
I see you stating it in a few different threads.
Again, that's not what I said, but instead
what you have mis-read.
A general IPsec Requirements document ought to be addressing
all deployed use cases,
On 03 Mar 2014, at 17:53 , Paul Wouters wrote:
On Mon, 3 Mar 2014, RJ Atkinson wrote:
ESP-NULL offers the same protection as AH, ...
This sentence above is not true. ESP-NULL and AH provide
different security properties to the IP-layer.
AH protects all IP options, whereas ESP
I agree with Steve Kent's recent postings about this draft.
Ran
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
On 04 Jan 2012, at 00:49 , Nico Williams wrote:
Advising (and updating said advice as circumstances change)
use-IPsec protocol designers as to when to use ESP and/or
AH is something we should do.
This has already been done. More than once.
For a start, the latest IPsec RFCs contain
On 04 Jan 2012, at 09:18 , Bhatia, Manav (Manav) wrote:
There is no evidence of any recent change either to the operational
circumstances or to the available alternatives. So no update
is appropriate at this time.
One major recent change is the publication of WESP [RFC 5840]
and the
On 04 Jan 2012, at 13:46 , Paul Hoffman wrote:
On Jan 4, 2012, at 10:37 AM, RJ Atkinson wrote:
Neither WESP nor the other document provide a 100% reliable way
to parse-into/parse-past/deep-inspect ESP packets. One might
wish otherwise, but the reality is that there is no 100%
reliable
Earlier, Michael Richardson wrote:
Ran, as you've been rather inactive in IPsec,
Fair point.
I mostly watch without writing notes.
IPsec hasn't been paid work for me since 1995,
(and isn't paid work now -- just community service).
I suspect that some people might not know what
pieces of
Folks,
I mostly entirely agree with Michael Richardson's
analysis at the URL just below, namely that AH continues
to have utility -- but that utility is not VPN deployments.
Michael Richardson's note:
http://www.ietf.org/mail-archive/web/ipsec/current/msg07363.html
HISTORY
Important
On 02 Jan 2012, at 14:15 , Jack Kohn wrote:
In case of IPv4, which field in the IP header
are you most interested in protecting?
An IPv4 example would be validating the [FIPS-188]
IPv4 option, which can't be protected any other way.
That option is supported by a range of operating systems,
On 02 Jan 2012, at 18:25 , Jack Kohn wrote:
Similar IPv6 examples exist.
And i would like to know what those are.
What about IPv6?
As I noted, a range of examples exist for IPv6,
and another range of examples exist for IPv4.
If one is inclined to study further, one possible
starting
Earlier, Dan Harkins wrote, in part:
Honestly, if a WG is not paying attention to RFC 4301,
then what makes you think they're gonna pay attention
to a random individual submission ?
I don't have any particular love for AH but this effort
is really lacking in one thing: a problem to solve.
On 02 Jan 2012, at 19:21 , Jack Kohn wrote:
And last but certainly not the least, why cant somebody use ESP-NULL
in the tunnel mode to protect the IP headers (including FIPS-188 IP
option that i have never seen anyone ever using).
As noted originally, those options need to be seen and
their
On 02 Jan 2012, at 19:15 , Jack Kohn wrote:
I want to understand which extension header did you
specifically have in mind.
It isn't my job to write a document that isn't useful
or necessary.
I've supplied a subset of examples, which are sufficient
to illustrate that ESP with NULL encryption
On 02 Jan 2012, at 19:51 , Bhatia, Manav (Manav) wrote:
It doesn't need to because nobody uses it.
I know of multiple sites who have it deployed today.
The reason the above draft exists is because there were
many people (at least service providers) who said that
they did NOT want to use
On 02 Jan 2012, at 19:54 , Bhatia, Manav (Manav) wrote:
And most of these are considered dangerous and are generally discouraged.
http://tools.ietf.org/html/rfc6398
That RFC says the Router Alert Option might be abused
by malicious transit traffic in global public transit
networks,
17 matches
Mail list logo
