Subject: [Pana] Some comments about PANA drafts

From: [email-masked]
Date: Mon, 31 May 2004 12:41:17 +0300

Hi,

Here are some comments about PANA drafts based on a 
quick review. (I haven't followed the PANA mailing list 
for  some time, so my apologies if some of these issues 
have already been discussed here.)

Best regards,
Pasi

Comments about draft-ietf-pana-framework-00:

Section 10.2.2: First, let's say that I have some doubts about
whether anyone will actually implement this. It also seems that
there are not enough details about e.g. PANA would actually work
together with 802.11 and .11i state machines and procedures, but
maybe this isn't necessary in a "framework" document. (BTW, the
4-way handshake is started by the AP; bullet 4 in 10.2.2.2 seems
to assume otherwise.)

Comments draft-ietf-pana-pana-04:

The document would probably benefit from explaining the "big
picture" first, e.g. what PANA messages are sent in a typical
situation (something like Section 4.6), and only then specific
details such as contents of PANA SA, calculation of MAC AVP and
processing of the S-flag.

Section 4.1.5: Key derivation seems to assume that the integrity
protection algorithm needs at most 160 bit key (so if some new
algorithm later needs more, also the key derivation needs to be
updated).

Section 4.2: HMAC-SHA1 takes two parameters, not one

Section 6.3: Diameter uses SMI enterprise numbers for Vendor-Id;
does PANA use that also, or does it define its own number space?

Section 6.5.5 (Protection-Capability): Is it assumed that only a
single L2 mechanism can exist? Or that if multiple L2 mechanisms
are possible, the correct one can be determined from some L2
messages?

Section 6.5.13 (Provider-Identifier): What the client is
supposed to do with this information? (And usually the
enterprise numbers are used to identify vendors, not network
operators--but of course a network operator could get an
enterprise number as well...)

Section 7: The retransmission behavior seems quite complicated;
IMHO it would have been simpler to have one end (probably PaC)
to be responsible for all timer-based retransmissions.

Section 9: Overall, this section is quite heavy reading, and
it's not clear that someone not very familiar with PANA, EAP,
etc. can actually get a very accurate picture of the relevant
security properties of PANA. So this section would certainly
benefit from some editorial work.

Part a (discovery message exchange) should probably explain that
if including Protection-Capability and PPAC AVPs in PSR is not
recommended, why are they allowed at all (especially since it
seems the client won't actually need the information until PBR
anyway).

This section should also mention that any information in PANA
messages before PBR/PBA (such as ISP-Information) can be
spoofed, and the implications of that. (BTW, perhaps it would
have been a good idea to integrity protect all previous PANA
messages in PBR/PBA.)

It should be clarified what exactly is meant when it's said that
a network is already "secure" before PANA is run. E.g. it seems
that such networks should have reasonably reliable disconnect
indications? What about ppreventing IP address spoofing?

References: Some of the normative references should probably be
informative (e.g. EAP-TLS).

Comments about draft-ietf-pana-ipsec-03:

Section 5: What happens if there were two EAP authentications,
resulting in two AAA-Keys?

Section 8: The special rule for PANA_PORT should be included 
in Section 8.1 and 8.2, rather than described separately.
Also, inbound SPD/SAD entries don't contain outer IP addresses.

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana