Subject: [Gen-art] Gen-ART Review of draft-ietf-pana-pana-15

From: Spencer Dawkins <[email-masked]>
Date: Thu, 14 Jun 2007 22:32:01 -0500

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: "Alper Yegin" <[email-masked]>
Date: Sat, 16 Jun 2007 02:01:26 +0300

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.

> OBTW, Alper's e-mail address seems to have changed since the draft was

Already taken care of on version 16.

> Spencer (nit): c/it's/that data traffic is/

OK.

> 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

You are right that it is not a 100% protection. But we thought it can help
to some extent.

> want to be stateless, here's how that works"? instead of normative

Is using lower-case "should" sufficient?

> 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."

> Spencer (nit): /need to make sure/need to ensure/

OK.

> bit" to be the most usable format for the expansion.

OK. We'll do that across the document.

> Spencer: message type space? This isn't an address, is it?

I think we can say "Message Type allocation is managed by IANA [ianaweb]."

> Spencer: this is probably not a 2119 MUST, I think.

I agree. We should use "must."

> for that PANA message type, and whether or not each AVP is Mandatory", or

Yes, that's better.

>    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.

> Spencer (nit): determined in one of two ways, depending on whether

OK.

> assume that authorization has also failed"? 

Yes, that's what we meant to say.

> which still seems odd to me -
> if

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).

> Spencer: is this "message retransmission"? If so, that might be clearer.

OK, we shall say so.

> fields) - if it's off by one, that's a nit, but if it's not, it's more

Yes, iana review caught that as well.

> versus "-". Shouldn't these two clauses match?

True. We shall use "-" for both.

> Spencer: is this "Designated Expert Review"? Not sure if this is a nit or

Yes, I think it should be " Designated Expert Review."

> 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

---

From: Spencer Dawkins <[email-masked]>
Date: Fri, 15 Jun 2007 23:17:38 -0500

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).

> 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.

> 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?

> 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.

> 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.

> 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.

> already some level of physical security prior to running the L3 access

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

---

From: "Alper Yegin" <[email-masked]>
Date: Sat, 16 Jun 2007 12:34:33 +0300

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...

> >> normatively require PAAs to do something that isn't described (how
> would
> >> you

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.

> "doesn't include"/"doesn't". Does that make sense?

That's better.

> corresponding ..." - sometimes it's just a definition, not so much a

Certainly better!

> authentication failed, but just in case, we checked authentication, too" -

You mean "we checked authorization"? The latter is "authorization."

How about:

      Authentication has failed.  When authentication fails, authorization
	is automatically considered to have failed.

Sorry, I couldn't come up with anything better...

> values ...", just so it's blindingly clear.

Good idea.

> > and authorized for the L3 services separately. And in DSL networks,
> there
> > is

I cannot point at a concrete case like the L2 ones.
I can only say we don't prevent such scenarios.

> it should have been. See you in Chicago?

Not a problem at all! See you in Chicago.

Alper

---

From: Spencer Dawkins <[email-masked]>
Date: Sat, 16 Jun 2007 06:22:17 -0500

Hi, Alper,

(adding the security ADs as a heads-up on the last item in this note, just 
because we're less than a week away from the telechat date for this 
document).

> revision along with IESG one...

As long as you're talking to Mark, we're good.

I think we're well within the range of what the IESG can do with RFC Editor 
notes (as things turned out, I think my original review comments could have 
been handled this way, although sending the RFC Editor a clean draft is 
always less error-prone).

Again, thanks for the quick feedback.

> If we cannot decide now, let's take it to IESG review and decide there.

Actually, if Jari is happy, I'm happy. This is why your TSV Advisor gets the 
big bucks :-)

> Sorry, I couldn't come up with anything better...

I'm still struggling with "automatically" (this is a lot less technical than 
you think!). "is also considered to have failed" seems more accurate to me, 
but this isn't a big deal.

> I can only say we don't prevent such scenarios.

Well, yeah, but that's like saying SIP doesn't prevent the use of IPsec, 
either.

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

---

From: "Alper Yegin" <[email-masked]>
Date: Sat, 16 Jun 2007 22:47:15 +0300

Spencer,

Thanks for the quick responses -- over the weekend!

> but this isn't a big deal.

That sounds good.

> >> >> Spencer: is this saying that you expect people to be able to set up
> an
> >> SA
> >> > There are such networks where some kind of lower-layer security
> exists
> >> > even

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 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?

Alper

---

From: Spencer Dawkins <[email-masked]>
Date: Sat, 16 Jun 2007 15:13:54 -0500

Hi, Alper,

Skipping stuff where we were mostly in sync before...

> example protocol to establish such channel after PANA.

I was not getting this - you put your finger on the problem.

>   using a link-layer or network-layer cryptographic mechanism (e.g.,

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 17 Jun 2007 06:12:32 -0400

On Sat, Jun 16, 2007 at 02:01:26AM +0300, Alper Yegin wrote:

(snip)

> Yes, that's what we meant to say.

To be clearer, shouldn't "the requestor" read "the PaC"?  This is
because the PaC is the entity that receives Result-Code AVP.

Yoshihiro Ohba

---

From: Mark Townsley <[email-masked]>
Date: Mon, 18 Jun 2007 11:54:48 +0200

Spencer Dawkins wrote:
> Hi, Alper,
>
> (adding the security ADs as a heads-up on the last item in this note, 
> just because we're less than a week away from the telechat date for 
> this document).
>
>
>> Hi Spencer,
>>
> I think we're well within the range of what the IESG can do with RFC 
> Editor notes (as things turned out, I think my original review 
> comments could have been handled this way, although sending the RFC 
> Editor a clean draft is always less error-prone).
Right, I prefer to get documents as close to finished before the IESG 
reads it, as well as before it goes to the RFC Editor. Editor's notes 
are not something I like to rely on for more than a few tweaks. Given 
the speed in which Spencer, Yoshi and Alper seemed to be operating here, 
I thought that a new version by today would be a reasonable goal to 
shoot for. I'll let the IESG know that the new version is out.

Thanks,

- Mark