Spencer,
Thank you again for helping us improve the document.
Please see below for my notes.
We had already revised the documents based on IETF LC comments and got on
the IESG agenda for the next week's call. Sorry, I wasn't aware of your
ongoing review and but I should have thought.
No problem though. We'll revise the document one more time based on your
feedback ASAP. Please see below and let us know.
> Summary: This document is almost ready for publication as a Proposed
> Standard. I do have some questions, but almost all involve either
> clarifications beyond nits or 2119 language. In general, this document is
> well-written, clean, and accessible for a non-specialist to understand.
>
> Comments
>
> OBTW, Alper's e-mail address seems to have changed since the draft was
> submitted...
Already taken care of on version 16.
>
> 2. Terminology
>
> Enforcement Point (EP):
>
> A node on the access network where per-packet enforcement policies
> (i.e., filters) are applied on the inbound and outbound traffic of
> access devices. The EP and the PAA may be co-located. EPs should
> prevent data traffic from and to any unauthorized client unless
> it's either PANA or one of the other allowed traffic types (e.g.,
>
> Spencer (nit): c/it's/that data traffic is/
OK.
>
> ARP, IPv6 neighbor discovery, DHCP, etc.)
>
> 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 ...."?
> Actually, I'm also not entirely sure
> how
> this would provide robustness against denial-of-service attacks, either,
> now
> that I'm thinking of it (I tend to visualize DoS attacks as "packet
> spraying", and DDoS botnets are certainly capable of overrunning almost
> any
> single receiver.
You are right that it is not a 100% protection. But we thought it can help
to some extent.
>
> 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?
> transmit the message on a timer. For this reason, the PaC MUST
> retransmit the PANA-Client-Initiation message until it receives the
> second PANA-Auth-Request message (not a retransmission of the initial
> one) from the PAA.
>
> It is possible that both the PAA and the PaC initiate the PANA
> session at the same time, i.e., the PAA unsolicitedly sends the
> initial PANA-Auth-Request message while the PaC sends a
> PANA-Client-Initiation message. To resolve the race condition, the
> PAA SHOULD silently discard the PANA-Client-Initiation message
>
> Spencer: this SHOULD seems odd. Why not a MUST - simply because you could
> process the PANA-Client-Initiation message and end up with at least one
> SA?
> Or is there something else going on?
I think MUST is fine. I don't remember intentionally making that a "SHOULD"
instead of a "MUST."
>
> received from the PaC after it has sent the initial PANA-Auth-Request
> message. The PAA uses the source IP address and the source port
> number of the PANA-Client-Initiation message to identify the PaC
> among multiple PANA-Client-Initiation messages sent from different
> PaCs.
>
> 4.2. Access Phase
>
> Once the authentication and authorization phase successfully
> completes, the PaC gains access to the network and can send and
> receive IP data traffic through the EP(s) and the PANA session enters
> the access phase. In this phase, PANA-Notification-Request and
> PANA-Notification-Answer messages with 'P' (Ping) bit set (ping
> request and ping answer messages, respectively) can be used for
> testing the liveness of the PANA session on the PANA peer. Both the
> PaC and the PAA are allowed to send a ping request to the
> communicating peer whenever they need to make sure the availability
>
> Spencer (nit): /need to make sure/need to ensure/
OK.
>
> of the session on the peer and expect the peer to return a ping
> answer message. The ping request and answer messages MUST be
> protected with an AUTH AVP when a PANA SA is available. A ping
> request MUST NOT be sent in the authentication and authorization
> phase, re-authentication phase and termination phase.
>
> 4.3. Re-authentication Phase
>
> When the PaC initiates re-authentication, it sends a
> PANA-Notification-Request message with 'A' bit set (a
>
> Spencer (nit): there are places in the text where the bit identifier is
> immediately expanded, and places where it is not, but I'm not sure from
> this
> sentence whether the 'A' bit determines whether the message is a
> re-authentication request message or not. If this could be a bit clearer,
> that would be great. If you make sure that all the bit identifiers are
> expanded, that would be great, too. I find the format "the 'R' (Request)
> bit" to be the most usable format for the expansion.
OK. We'll do that across the document.
>
> re-authentication request message) to the PAA. This message MUST
> contain the session identifier assigned to the session being
> re-authenticated. If the PAA already has an established PANA session
> for the PaC with the matching session identifier, it MUST first
> respond with a PANA-Notification-Answer message with 'A' bit set (a
> re-authentication answer message), followed by a PANA-Auth-Request
> message that starts a new EAP authentication. If the PAA cannot
> identify the session, it MUST silently discard the message. The
> first PANA-Auth-Request and PANA-Auth-Answer messages in the
> re-authentication phase MUST have 'S' bit cleared and carry a Nonce
> AVP.
>
> 6.2. PANA Message Header
>
> Message Type
>
> The Message Type field is two octets, and is used in order to
> communicate the message type with the message. The 16-bit address
>
> Spencer: message type space? This isn't an address, is it?
I think we can say "Message Type allocation is managed by IANA [ianaweb]."
>
> space is managed by IANA [ianaweb].
>
> 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."
> [RFC2234] specification, which is used to define the AVPs that MUST
> or MAY be present. The following format is used in the definition:
>
> Spencer: This shouldn't be 2119 language. Aren't you saying "define the
> AVPs
> for that PANA message type, and whether or not each AVP is Mandatory", or
> something like that?
Yes, that's better.
>
> 8.5. Nonce AVP
>
> The length of the nonces are determined based on the available
> pseudo-random functions (PRFs) and the degree of trust placed into
> the two PaC and the PAA to compute random values. The length of the
I just noticed the "two" above. I think it's extra.
> random value for the nonce is determined whether
>
> Spencer (nit): determined in one of two ways, depending on whether
OK.
>
> 1. The PaC and the PAA each are likely to be able to compute a
> random nonce (according to [RFC4086]). The length of the nonce
> has to be 1/2 the length of the PRF key (e.g., 10 octets in the
> case of HMAC-SHA1).
>
> 2. The PaC and the PAA each are not trusted with regard to the
> computation of a random nonce (according to [RFC4086]). The
> length of the nonce has to have the full length of the PRF key
> (e.g., 20 octets in the case of HMAC-SHA1).
>
> 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).
>
> 9. Retransmission Timers
>
> RT for each subsequent message transmission is based on the previous
>
> Spencer: is this "message retransmission"? If so, that might be clearer.
OK, we shall say so.
>
> value of RT:
>
> RT = 2*RTprev + RAND*RTprev
>
> 10.2. PANA Message Header
>
> As defined in Section 6.2, the PANA message header contains two
>
> Spencer: this sentence just LOOKS wrong ("two", but looks like three
> fields) - if it's off by one, that's a nit, but if it's not, it's more
> than
> a nit...
Yes, iana review caught that as well.
>
> fields that requires IANA namespace management; the Version, Message
> Type and Flags fields.
>
> 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.
>
> reserved for experimental messages. As these codes are only for
> experimental and testing purposes, no guarantee is made for
> interoperability between the communicating PaC and PAA using
> experimental commands, as outlined in [IANA-EXP].
>
> 10.3.1. AVP Code
>
> AVPs may be allocated following Designated Expert with Specification
>
> Spencer: is this "Designated Expert Review"? Not sure if this is a nit or
> not...
Yes, I think it should be " Designated Expert Review."
>
> Required [IANA] or Standards Action. AVPs with 'M' bit set MUST be
> allocated by Standards Action.
>
> 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.
Alper
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
