Hi, Alper,
(1) I've already pointed out to Mary that if I was late enough on the Last
Call review, it magically turned into the first review for this coming
telechat :-( Sorry!
(2) Because I started out with the Last Call review template, I didn't use
the "please wait for your AD before revising" boilerplate, but please be
guided by the ADs at this point.
Almost everything you propose works for me (if it works for the IESG). If
they are open for guidance, here's what I think we still have to talk about
(I deleted a lot of stuff that we agreed on).
4.1. Authentication and Authorization Phase
The PAA SHOULD limit the rate it processes incoming PANA-Client-
Initiation messages to provide robustness against denial-of service
(DoS) attacks. Details of rate limiting are outside the scope of
this specification.
Spencer: Two concerns here - why is this a SHOULD, instead of a MUST (why
would you NOT do this?), but more importantly, I'm not sure how you
normatively require PAAs to do something that isn't described (how would
you
know if the PAA is not doing this?)
You are right. It is meant to be a recommendation. Would we say "It is
recommended that the PAA limits the rate ...."?
This is actually a good TSV question, but what *I* was thinking was that
"rate limiting" is often described in more specific terms (like not sending
errors more than once per second, etc.). If there's a rate you have in mind,
it would be helpful for implementers to know that.
If the PAA wants to stay stateless in response to a
PANA-Client-Initiation message, it SHOULD NOT include an EAP-Payload
AVP in the initial PANA-Auth-Request message, and it SHOULD NOT re-
Spencer: both of these SHOULDs seem odd - aren't you just saying "if you
want to be stateless, here's how that works"? instead of normative
language...
Is using lower-case "should" sufficient?
I still think you're simply defining stateless operation. I'm thinking
"doesn't include"/"doesn't". Does that make sense?
7. PANA Messages
Every PANA message defined MUST include a corresponding ABNF
Spencer: this is probably not a 2119 MUST, I think.
I agree. We should use "must."
I'm thinking something like "PANA message definitions include a
corresponding ..." - sometimes it's just a definition, not so much a
requirement or command.
8.6. Result-Code AVP
PANA_AUTHENTICATION_REJECTED 1
Authentication has failed. When this error is returned, it is
assumed that authorization is automatically failed.
Spencer: this is not entirely clear to me. Is it saying "the requestor
can
assume that authorization has also failed"?
Yes, that's what we meant to say.
which still seems odd to me -
if
you're not the entity you claim to be, how could this not be true?
Mumble.
Yes, it is always true that if the authentication fails, the client cannot
be authorized for the service.
But see, the reverse is not true. Even if the authentication succeeds, the
authorization may fail for various reasons (e.g., joe is not allowed to
access the corporate network on the weekends).
That makes perfect sense to me. The text seems to be saying "well, the
authentication failed, but just in case, we checked authentication, too" -
that's what confused me.
10.2.2. Message Type
The Message Type namespace is used to identify PANA messages. Values
0-65,519 are for permanent, standard message types, allocated by IETF
Consensus [IANA]. This document defines the Message Types 1-4. See
Section 7.1 through Section 7.7 for the assignment of the namespace
in this specification.
The values 65,520 and 65,535 (hexadecimal values 0xfff0 - 0xffff) are
Spencer: is this two values, or a range of values? I'm confused by "and"
versus "-". Shouldn't these two clauses match?
True. We shall use "-" for both.
Now that I know what the sentence is saying, I'd even suggest "The range of
values ...", just so it's blindingly clear.
11. Security Considerations
An important element in assessing security of PANA design and
deployment in a network is the presence of lower-layer (physical and
link-layer) security. In the context of this document, lower-layers
are said to be secure if they can prevent eavesdropping and spoofing
of packets. Examples of such networks are physically-secured DSL
networks and 3GPP2 networks with cryptographically-secured cdma2000
link-layer. In these examples, the lower-layer security is enabled
even before running the first PANA-based authentication. In the
absence of such a pre-established secure channel, one needs to be
created in conjunction with PANA using a link-layer or network-layer
cryptographic mechanism (e.g., IPsec).
Spencer: is this saying that you expect people to be able to set up an SA
before they start doing PANA? Does that seem realistic?
There are such networks where some kind of lower-layer security exists
even
before L3 authentication. For example, in cdma2K networks, L2 is already
ciphered. Nevertheless, the mobile terminal is expected to get
authenticated
and authorized for the L3 services separately. And in DSL networks, there
is
already some level of physical security prior to running the L3 access
authentication.
Yeah, I understood the L2 cases - sorry for not being clearer. What I was
trying to ask was about people really setting up *IPsec* SAs before doing
PANA.
Thanks for the quick response, and again, I'm sorry my review was later than
it should have been. See you in Chicago?
Spencer
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
