I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-pana-pana-15
Reviewer: Spencer Dawkins
Review Date: 2007-6-14
IETF LC End Date: 2007-06-07 (my bad)
IESG Telechat date: 2007-06-21
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...
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/
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?) 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.
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...
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?
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/
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.
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?
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.
[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?
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
random value for the nonce is determined whether
Spencer (nit): determined in one of two ways, depending on whether
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"? which still seems odd to me - if
you're not the entity you claim to be, how could this not be true? Mumble.
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.
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...
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?
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...
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?
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art
