Hi, Alper,
Skipping stuff where we were mostly in sync before...
There is a confusion here, and let's see if we can improve the document to
prevent it.
There is either a secure channel (against eaves-dropping and spoofing)
prior
to running PANA (as in cdma2K and DSL networks), or one has to be
established after successful PANA authentication. IPsec is given as an
example protocol to establish such channel after PANA.
I was not getting this - you put your finger on the problem.
I think in your understanding IPsec was used even before PANA
authentication. But that's not what the document says.
If that's clear, then I'd propose a revision on the last sentence as:
In the absence of such a pre-established secure channel prior to running
PANA, one needs to be created after the successful PANA authentication
using a link-layer or network-layer cryptographic mechanism (e.g.,
IPsec).
Does this help?
This is MUCH clearer. "in conjunction with" didn't make the ordering nearly
as clear.
I think I'm done. And thanks. As you say, over the weekend.
Spencer
Alper
I'm sorry that I'm not making myself clearer here. What I'm trying to say
is
that the L2 cases you cite make total sense to me, but if it was common
to
set up IPsec SAa with arbitrary endpoints on the Internet, the world
would
be a different place. The use of IPsec seems to imply that the PANA
client
can easily have some ability to share a key (either symmetric or
asymmetric)
with the PAA. Maybe this is true, in the PANA case, but it's sure not
that
easy in the general case - that's why I'm confused.
As I'm typing this, I'm wondering if you would do better with a
recommendation that says basically
"PANA clients typically know whether their first-hop is L2-secure or not.
If
the PANA client is using a first-hop link that is not L2-secure, the PANA
client SHOULD use IPsec to establish a security association before the
first
PANA-based authentication".
If this sounds like a good idea, great; if it doesn't sound like a good
idea, I'd be more comfortable just dropping "or network-layer" and
"(e.g.,
IPsec)". But fortunately, you have two SEC ADs AND Russ who can tell me
that
I'm nuts, so you don't have to say it... and at least two of them have
demonstrated running code that they can tell me I'm nuts :-)
And thanks again. I'll be scribing (silently - scribes don't talk) on
this
IESG telechat and look forward to seeing this draft on the agenda.
Spencer
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
