Hi Spencer,
Mark said if we can revise the spec by Monday, he can pass the revision to
the IESG. Otherwise I guess either we miss this IESG call or do your
revision along with IESG one...
> >> 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.
Sorry, I have no specific recommendation. This is merely saying "remember to
use rate limiting." If you think this is not worth saying because it is
obvious and in the absence of any specific guidance not that useful, we can
remove it. I'd not have any issues with that.
If we cannot decide now, let's take it to IESG review and decide there.
> >> 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?
That's better.
>
> >> 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.
Certainly better!
>
> >> 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.
You mean "we checked authorization"? The latter is "authorization."
How about:
PANA_AUTHENTICATION_REJECTED 1
Authentication has failed. When authentication fails, authorization
is automatically considered to have failed.
Sorry, I couldn't come up with anything better...
>
>
> >> 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.
Good idea.
>
>
> >> 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.
I cannot point at a concrete case like the L2 ones.
I can only say we don't prevent such scenarios.
> Thanks for the quick response, and again, I'm sorry my review was later
> than
> it should have been. See you in Chicago?
Not a problem at all! See you in Chicago.
Alper
>
> Spencer
>
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
