Subject: Re: PANA requirements draft

From: Alper Yegin <[email-masked]>
Date: Thu, 22 May 2003 12:07:27 -0700

Hello Pete,

Thank you for the review comments, and especially for the text!

I'll be updating the requirements drafts with these comments and the earlier
ones. It will be ready for the WG last call very soon.

Alper

On 5/22/03 9:36 AM, "Pete McCann" <[email-masked]> wrote:

> 
> Hi,
> 
> Here are my comments on the PANA requirements draft.  They are mainly
> editorial; I think this document is in pretty good shape.
> 
> -Pete
> 
> 
> Intoduction:
> 
>  IETF PANA Working Group has been chartered
> Should be:
>  The IETF PANA Working Group has been chartered
> 
> 
>  A higher-layer authentication is deemed necessary
>  when link-layer authentication mechanisms are either not available
>  for lack of technology or deployment difficulties, or not able to
>  meet the overall requirements, or when multi-layer (e.g., link-layer
>  and network-layer) authentication is needed.
> Should be:
>  A higher-layer authentication is deemed necessary
>  when link-layer authentication mechanisms are either not available
>  for lack of technology or deployment difficulties; when link-layer
>  authentication mechanisms are not able to meet the overall requirements;
>  or when multi-layer (e.g., link-layer and network-layer) authentication is
> needed. 
> 
> 
>  [USAGE] Internet-Draft describes the problem statement in detail.
> Should be:
>  The usage Internet-Draft [USAGE] describes the problem statement in detail.
> References in brackets should be used as parentheticals, not
> adjectives or nouns in the sentence.
> 
> 
>  As an example, Mobile IP Working Group has already defined such a
>  carrier for Mobile IPv4 [MIPV4]. Mobile IPv4 registration request
>  message is used as the carrier for authentication extensions (MN-FA
>  [MIPV4], or MN-AAA [MNAAA]) to receive forwarding service from the
>  foreign agents. In that sense, designing the equivalent of Mobile
>  IPv4 registration request messages for general network access is the
>  goal of this work, but not defining the equivalent of MN-FA or MN-
>  AAA extensions.
> Should be:
>  As an example, the Mobile IP Working Group has already defined such
>  a carrier for Mobile IPv4 [MIPV4].  A Mobile IPv4 registration request
>  message is used as a carrier for authentication extensions (MN-FA [MIPv4]
>  or MN-AAA [MNAAA]) that allow an FA to authenticate MNs before providing
>  forwarding service.  The goal of PANA is similar in that it aims to
>  define a network-layer transport for authentication information; however,
>  PANA will be decoupled from mobility management and it will rely on other
>  specifications for the definition of authentication payloads.
> 
> 
> Section 3 Terminology
> 
> 
>  Depending on the access
>  technology, identifier might contain any of IP address, link-
>  layer address, switch port number, etc. of a connected device.
>  PANA authentication agent keeps a table for binding device
>  identifiers to the PANA clients. At most one PANA client
>  should be associated with a DI on a PANA authentication agent.
> Should be:
>  Depending on the access
>  technology, the Device Identifier might contain any of IP address, link-
>  layer address, switch port number, etc. of a connected device.
>  A PANA authentication agent keeps a table for binding device
>  identifiers to the PANA clients. At most one PANA client
>  should be associated with a DI on a PANA authentication agent.
> 
> 
> Section 4 Requirements
> 
> 
> Section 4.1.1
> 
>  If PANA WG decides
>  that extensions to EAP are needed, it will define requirements for
>  the EAP WG instead of designing such extensions.
> Should be:
>  If the PANA WG decides
>  that extensions to EAP are needed, it will define requirements for
>  the EAP WG instead of designing such extensions.
> 
> 
>  are within the scope of IETF SEND Working Group.
> Should be:
>  are within the scope of the IETF SEND Working Group.
> 
> 
>  Providing capability of only PAA authenticating the
>  PaC is not sufficient.
> Should be:
>  Providing only the capability of a PAA authenticating the
>  PaC is not sufficient.
> 
> 
>  Certain type of service theft is possible when the DI is not
> Should be:
>  Certain types of service theft are possible when the DI is not
> 
> 
> Section 4.1.2
> 
> 
>  In addition to carrying authentication information, PANA MUST also
>  provide only a binary authorization to indicate whether the PaC is
>  allowed to access full IP services on the network (i.e., able to
>  send and receive any IP packets). Providing finer granularity
>  authorization, such as negotiating QoS parameters, authorizing
>  individual services (e.g., http vs. ssh), individual users sharing
>  the same device, etc. are outside the scope of PANA.
> The first sentence of this paragraph is awkwardly worded.  I think I
> see what you are trying to accomplish, but it might be too much to
> express in a single requirement.
> How about:
>  After a device is authenticated using PANA, it MUST be authorized
>  for Internet access.  That is, the core requirement of PANA is to
>  verify the identity of a device so that it may send and receive any
>  IP packets.  It may also be possible to provide finer granularity
>  authorization, such as authorization for QoS, individual services
>  (e.g., http vs. ssh), or individual users sharing the same device.
>  However, while a backend authorization infrastructure might provide
>  such indications to the PAA, explicit support for them is outside
>  the scope of PANA.  For instance, PANA is not required to carry any
>  indication of which services are authorized to the device.
> 
> 
> Section 4.1.3
> 
>  PAA MAY interact with backend
> Should be:
>  A PAA MAY interact with backend
> 
> 
> Section 4.1.4
> 
>  PAA MUST be able to create a binding between the PaC and the
>  associated DI upon successful PANA exchange.
> Should be:
>  A PAA MUST be able to create a binding between the PaC client
>  identifier and the associated DI upon successful PANA exchange.
> 
>  The keying material
>  required by the cryptographic methods needs to be stored as an
>  attribute of DI.
> Should be:
>  The keying material
>  required by the cryptographic methods needs to be indexed by
>  the DI. 
> 
> 
> 
> Section 4.3
> 
> 
>  EAP protocol itself imposes various requirements on its transport
>  protocols. 
> Should be:
>  The EAP protocol itself imposes various requirements on its transport
>  protocols. 
> 
>  These requirements are based on the nature of the EAP
>  protocol, and needs to be satisfied for correct operation.
> Should be:
>  These requirements are based on the nature of the EAP
>  protocol, and need to be satisfied for correct operation.
> 
> 
> Section 4.4
> 
>  Possible candidates include but not limited to COPS, SNMP, DIAMETER.
> Should be:
>  Possible candidates include but are not limited to COPS, SNMP, and DIAMETER.
> 
> 
>  This task is similar to what MIDCOM Working Group is trying to
>  achieve, 
> Should be:
>  This task is similar to what the MIDCOM Working Group is trying to
>  achieve, 
> 
>  The objective of using this protocol is to provide
> Should be:
>  The objective of using a PAA-to-EP protocol is to provide
> 
>  For example, if the
>  design is such that the EP allows the PANA traffic to bypass even
>  for unauthenticated PaCs, it should also allow and expect the PAA to
>  send the filtering information at the end of successful PANA without
>  EP ever sending a request.
> Should be:
>  For example, if the
>  design is such that the EP allows the PANA traffic to pass through even
>  for unauthenticated PaCs, the EP should also allow and expect the PAA to
>  send the filtering information at the end of a successful PANA exchange
> without
>  the EP ever sending a request.
> 
> 
> Section 4.5.1
> 
>  Protocol MUST support PaCs with multiple interfaces, and
> Should be:
>  PANA MUST support PaCs with multiple interfaces and
> 
>  In other words, PANA MUST not assume PaC
> Should be:
>  In other words, PANA MUST NOT assume the PaC
> 
> 
> Section 4.5.2
> 
>  Links MAY or MAY NOT provide disconnect indication.
> No need to capitalize MAY; this is not a requirement on PANA:
>  Links may or may not provide disconnect indication.
> 
> 
> Section 4.5.3
> 
>  That means, there must be no IP routers between two.
> Should be:
>  That is, there must be no IP routers between the two.
> 
>  Note that, this
>  does not mean they are on the same physical link.
> Unnecessary comma, should be:
>  Note that this
>  does not mean they are on the same physical link.
> 
>  Furthermore, two nodes on the same IP subnet does not
>  necessarily satisfy this requirement, as they can be more than one
>  hop away from each other [MULTILINK].
> Should be:
>  Furthermore, two nodes on the same IP subnet do not
>  necessarily satisfy this requirement, as they can be more than one
>  hop away from each other [MULTILINK].
> 
>  PAA can be on the NAS
> Should be:
>  A PAA can be on the NAS
> 
>  A PaC MAY not be pre-configured
> Should be:
>  A PaC MAY NOT be pre-configured
> 
>  Therefore PANA protocol
> Should be:
>  Therefore the PANA protocol
> 
> 
> Section 4.5.4
> 
>  PANA MUST not assume
> Should be:
>  PANA MUST NOT assume
> 
> 
>  PANA MAY provide a secure channel by
>  deploying a two-phase authentication. First phase can be used for
>  creation of the secure channel, and the second phase is for client
>  and network authentication.
> Is this pair of sentences really a requirement?  It sounds like
> protocol design.  Suggest removing them.  If you keep them, be sure to
> fix the missing article:
>  First phase can be used for
> Should be:
>  The first phase can be used for
> 
> 
> Section 4.6
> 
>  Though, PANA MUST
>  be able to co-exist
> Should be:
>  However, PANA MUST
>  be able to co-exist
> 
> 
> Section 4.7
> 
>  efficient handling of
>  authentication process.
> Should be:
>  efficient handling of
>  the authentication process.
> 
> 
> Section 4.9.2
> 
>  PANA MUST be robust against a class of DoS attacks such as blind
>  masquerade attacks through IP spoofing that swamp the PAA in
>  spending much resources and/or prevent legitimate clients' attempts
>  of network access.
> Should be:
>  PANA MUST be robust against a class of DoS attacks such as blind
>  masquerade attacks through IP spoofing that would swamp the PAA,
>  causing it to spend resources and prevent network access by legitimate
>  clients.
> 
> 
> 
> 
>