Hello,
Here are some comments on this draft for IETF LC. There are some
editorial nits, some errors that might be considered editorial but
there is a serious issue with the Security Considerations that I think
needs addressing.
I'll start with the security issue since it's the most serious
At 2:22 PM -0700 5/26/10, Dan Harkins wrote:
>I would advise a DISCUSS on this draft until this has been worked out.
Can you say more about what you mean by "worked out"? More text in the Security
Considerations? If so, at least an outline would be helpful. Or maybe you mean
one or more chan
Hi Paul,
What I said was:
"I think there has to be a top-down analysis of RFC 4301 and how this
scheme impacts it. Each part of RFC 4301 that cannot be supported
or can only be supported in a limited manner must be spelled out and
the impact of the lack, or limit, of support h
Hi Dan,
Thanks for reviewing this document. Responding to your main point:
The need to correlate the client's EAP and IKE identity is not new to
this protocol. It has to be done in exactly the same manner, for exactly
the same reasons, in today's IKEv2. This is what IKEv2-bis says about it:
Hi Yaron,
I see your point. IKEv2-bis completely punts the issue and so you
want to too. If that's your tact you might want to mention _how_ an
implementation is supposed to interoperate with a AAA server, like
an RFC that defines this behavior. If there is no RFC to define the
behavior you w
