Subject: Comments on PANA Requirements I-D

From: <[email-masked]>
Date: Fri, 13 Jun 2003 17:11:10 -0500

Hello,

Below are my comments on the PANA requirements I-D which 
completed WG LC yesterday. I hope these will still be taken
into account.

-Basavaraj

I-D: draft-ietf-pana-requirements-06.txt

Review Comments:
----------------

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.

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. 

3. s/client's device/host device

4. s/agent device/agent

5. Section 1.
   a. s/to carry authentication methods/to carry authentication
   parameters

   b. d/The IETF PANA Working Group has been chartered with the...

   c. s/A higher-layer authentication is deemed necessary/A
   higher-layer authentication protocol is deemed necessary

   d. s/are not available for lack of technology/do not exist in terms
   of specifications or standards for a specific access technology 

   e. s/overall requirements/overall authentication and security
   requirements 

   f. s/The Working Group will not invent new security protocols and
   mechanisms but instead it will use the existing mechanisms./The
   intent is to not invent new security protocols and mechanisms but
   to reuse existing mechanisms such as EAP.

   g. s/the Working Group will not define new authentication/the
   requirements do not mandate the need to define

6. Section 3:

   PaC definition - Alternative proposal.
   a. PaC The client side of the protocol that resides in the host
   device which is responsible for providing the credentials to prove
   its identity for network access authorization. 
   
   b. PAA - s/The entity/The access network side entity of the
   protocol whose...

   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.

7. Section 4.1.1:
   "
   The current thinking is that a sufficient solution would be for
   PANA to carry EAP [EAP]. If the PANA WG decides that extensions to
   EAP are needed, it will define requirements for the EAP WG instead
   of designing such extensions. 
   "
   Current thinking becomes outdated pretty soon. So it is better to
   rephrase this sentence. Suggestion:
   EAP [EAP] is a candidate protocol that satisfies many of the
   requirements for authentication. PANA would be a carrier protocol
   for EAP.

   "it indirectly enables this by the virtue of carrying EAP"
   Rephrase as: "it enables this by virtue of selecting the appropriate
   EAP method."

   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. 

   d/Securing IPv6 router discovery and neighbor discovery protocols
   are within the scope of the IETF SEND Working Group.

8. Section 4.1.2
   PaC's 
   
   s/authorized to the device./authorized for the authenticated
   device.

9. Section 4.1.3
   s/then it can still/it can still

10. Section 4.1.4
    "PaCI is used for access control and accounting in the network as" 
    How is the PaCI used in accounting?

11. Section 4.2
    s/Providing address assignment functionality is outside the scope
    of/Assigning an IP address to the client is outside...

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.

13. Section 4.5.3

    "That is, there must be no IP routers between the two"
    
    One hop away may include scenarios where there is a routed network
    but the packets are tunnelled over the routed network. For example
    in the case of GPRS, the GGSN is the AR, and it can be considered
    to be one hop from the MN at the IP layer, but there exists a
    routed network between the MN and the GGSN.

    "A PaC MAY NOT be pre-configured with the IP address of PAA."
    Why not? This is one possible solution that should be okay.

14. Section 4.7
    The performance requirement is a bit difficult to quantify. So
    this requirement would cause some treading on water.

15. Section 6
    Move the change log to an appendix.

---

From: Alper Yegin <[email-masked]>
Date: Fri, 13 Jun 2003 16:48:32 -0700

Thank you Raj for the feedback.
My comments inlined below...

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

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

> 3. s/client's device/host device

"host" might be limiting since it excludes "router."

> 4. s/agent device/agent

Ok.
>  requirements do not mandate the need to define

Agreed to all.

>  its identity for network access authorization.

Ok.

>  b. PAA - s/The entity/The access network side entity of the

Ok.

>  for ... it is also the name for the protocol itself in the context

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

>  requirements for authentication. PANA would be a carrier protocol

OK.

>  Rephrase as: "it enables this by virtue of selecting the appropriate

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

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

>  are within the scope of the IETF SEND Working Group.

OK, I guess. 

>  s/authorized to the device./authorized for the authenticated

Ok.

>  s/then it can still/it can still

Ok.

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

>   of/Assigning an IP address to the client is outside...

Ok.

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

>   routed network between the MN and the GGSN.

Agreed.

>   Why not? This is one possible solution that should be okay.

OK, the current language is misleading. We meant there is no requirement
that PaC will be pre-configured with this information. Maybe I should
replace "MAY NOT" with "may or may not".

>   this requirement would cause some treading on water.

Yes, all it says is "think about performance too."

>   Move the change log to an appendix.

I'll remove it.

Alper