You probably speaks about ideal developers. I speak about real people.
I've seen a few cases when people implemented a bunch of really
unnecessary things just because it was in standard.
We still agree, and your answer is still inconsistent. If you worry about
those type of developers, then
Paul Hoffman writes:
If a developer does not know how to read the IANA tables, we are all
in trouble. Nothing in the tables says you must implement every
thing in these tables, of course.
Then we are already in trouble. There is lots of developers who do not
know about the IANA tables, they
Valery Smyslov writes:
What about EAP Message format and magic numbers? Remove and just
reference RFC3748 (or IANA entry for EAP)?
No, those were left in because they came from an RFC, not from a
particular IANA registry where the names match what we have in IKEv2bis.
EAP numbers
Now talking only about the Tranform Type 4 - Diffie-Hellman Group
Transform IDs IANA registry.
Valery Smyslov writes:
Currently exact groups for numbers 1, 2, 14, 15, 16, 17 and 16 are not
defined in IANA.
For me this is inconsistent. Either change two abovementioned lines to:
1
I don't agree with you. Remember, when IKEv2 was being developed,
one of the motivations for single self-contained document was complaint
from implementers that having 3 RFC (2408, 2409, 2407) for IKEv1
was very inconvinient and provoked confusions that led to
interoperability
problems. Now
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.
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 : Wrapped ESP for Traffic Visibility
Author(s) : K. Grewal, et al.
At 2:43 PM +0200 11/30/09, Tero Kivinen wrote:
Unless anybody objects, I will be requesting IANA to make the change
next week.
Not only do I not object, I thank you for doing something I volunteered to do.
--Paul Hoffman, Director
--VPN Consortium
___
Hello,
I do not believe this is a reasonable activity to spend WG time on.
The reason is that for this proposal to be useful for more than a
small, specific, edge condition the following must apply:
- both sides MUST implement both client- and server-side EAP state
machines.
- both
Hi Tero,
Groups 1 and 2 were defined in RFC 2409 and repeating them in a
subsequent RFC does not change that. I suggest leaving the reference
to RFC 2409 for groups 1 and 2 (and 3 and 4 for that matter) that
currently exists today at http://www.iana.org/assignments/ipsec-registry,
as of 2315
Hello,
As can be inferred by my previous posting on EAP-only authentication,
I favor this particular method for mutual authentication.
I believe this is a general purpose exchange, useful for more than the
narrow focus of EAP-only, does not require extraneous encapsulations or
unnecessary
Hi everyone,
[WG co-chair hat off]
I believe this effort is misguided, and would be a waste of the WG time.
EAP was added to IKEv2 to provide legacy (a.k.a. password) authentication. In
the past it did not do it very well, but this is changing. We should improve
the use of EAP in IKEv2,
Hello Dan,
[WG co-chair hat off]
EAP-only authentication is a small IKE extension that does not change the
existing IKE architecture; neither does it change many of the extant
implementations. Given the right EAP methods, it would provide us exactly what
EAP was supposed to provide from day
From a developer point of view, I share the same opinion as Yaron about this
issue. Instead of creating new solutions, I personally think that it would
be better to offer guidlines on how to implement current solutions (i.e EAP)
and provide documents targeting implementers. This would create less
14 matches
Mail list logo
