Subject: RE: Comments on PANA Requirements I-D

From: <[email-masked]>
Date: Tue, 17 Jun 2003 14:15:21 -0500

Alper Yegin [[email-masked]] wrote:
>
>Thank you Raj for the feedback.
>My comments inlined below...
>
>> 1. "It is expected that future IP devices will have" - I guess IP
>>  devices include routers as well. Maybe it is better to mention
>>  IP end-hosts instead of IP devices.
>
>The PaC might be a router as well. For example, the border gateway router in
>a NEMO network.

Okay. I guess that is true and needs to be tackled by PANA. 

>> 2. s/The goal of the PANA is ... access/The goal of this document is
>>  to identify the requirements for a protocol that would be able to
>>  provide a link-layer agnostic and IPv4/IPv6 compatible
>>  client-server protocol which would allow a host be to be
>>  authenticated for network access.
>
>I think I should also change the last part to "... allow a host and network
>authenticate each other for network access". Or else, it sounds like all we
>care is one way authentication.

Your suggestion for rephrasing sounds good.

>>  c. Maybe you also need to add the term PANA
>>  PANA - The protocol between the host device and the access network
>>  agent for authentication.  While PANA is an acronym for Protocol
>>  for ... it is also the name for the protocol itself in the context
>>  of this draft.
>
>I'm not sure about this one, because the full name of the protocol already
>says "protocol for ....". Does this still leave ambiguity regarding what is
>PANA (name of the protocol, vs. name of the WG, vs. ...)

I know. But we tend to use PANA also as the name for a protocol (like
Diameter). So that was the reason for suggesting that PANA be not
only the acronym for the WG but also the name for the protocol
itself. Either way is fine.

>>  "it indirectly enables this by the virtue of carrying EAP"
>>  Rephrase as: "it enables this by virtue of selecting the appropriate
>>  EAP method."
>
>Selection of EAP method is not done by PANA, so I'd say:
>
>"It enables this by the virtue of carrying EAP and allowing appropriate EAP
>method selection."

Okay.

>
>> 
>>  The scope of the protocol does not include key distribution. Yet
>>  there is a lot of text explaining how it can be accomplished. I do
>>  not believe this is required in the I-D.
>
>Hmmm. We ended up doing this in the process of clarifying how PANA enables
>per-packet protection. I'd feel uncomfortable removing them, as it'd
>generate the same set of questions again...
>

Well.. we address this in the FAQ and we mention that this is out of
scope. So why go to such length in the draft justifying the reasons
for not including key distribution. Minimal text would suffice.

>> 
>>  d/Securing IPv6 router discovery and neighbor discovery protocols
>>  are within the scope of the IETF SEND Working Group.
>
>OK, I guess. 

When this document gets published, there may not exist WGs that are
referenced here. So in order to keep the text relevant it is better to
simply say it is out of scope rather than pointing where the work is
done. 

>> 10. Section 4.1.4
>>   "PaCI is used for access control and accounting in the network as"
>>   How is the PaCI used in accounting?
>
>No, it is the "binding between DI and PaCI" that is used for accounting. The
>network determines the usage by observing traffic generated with DI and then
>sends the bill to the user identified by PaCI.

Okay. But note that PANA has nothing to do with accounting.

>> 12. Section 4.5.2
>>   "   In case the clients cannot send explicit disconnect messages to the
>>  PAA, PAA can still detect their departure by relying on periodic
>>  authentication requests."
>> 
>>  This is a requirements I-D. So no reason to get into possible
>>  solutions to deal with Disconnect Indication.
>
>This was in response to the question "what happens if PaC cannot send a
>disconnect". I think this is informative, and not problematic. I'm inclined
>to keep it.

Okay. Then maybe the requirement can be better drawn from the problem
that is faced in access networks.

-Basavaraj

---

From: Alper Yegin <[email-masked]>
Date: Tue, 17 Jun 2003 13:53:01 -0700

> for not including key distribution. Minimal text would suffice.

The problem is, it is hard to capture the current picture in few sentences.
Saying key distribution/derivation is outside the scope of PANA is not
sufficient, imo. We somehow need to capture that PANA design does nothing
more than carrying EAP, and EAP provides key generation functionality. Also,
we need to capture that the keys EAP generates are not readily useful for
data protection, but then this is also not for PANA to worry about. The
relevant text draws a complete picture (from access authentication to
per-packet security), and in most of the cases it ends up pointing out what
is outside the scope of PANA.

Alper