Subject: Re: [Pana] Issues 171-177 (AD-review, pana-fwk, section 1)

From: Mark Townsley <[email-masked]>
Date: Tue, 20 Dec 2005 11:18:53 +0100

Folks, I am just getting to the thread on my AD review responses on the
fwk doc, I wanted to review the pana-pana doc before getting here (and
this thread started on 10/26, 6 days after my baby was born, so didn't
make it to the top of the queue until just now).

Overall, thanks for the attention to the review comments. Only one
comment on responses: Personally, I think "server of PANA" that you
suggest doesn't sound right. Perhaps server for PANA? Or, if we are
really talking about code that may or may not be on a "PANA server" it
is a "PANA subsystem" that is on a "PANA server" "PAA" etc. In any case,
this is a very minor detail, not worth much more discussion on the matter.

- Mark

Yoshihiro Ohba wrote:

>>1.  Introduction
>>
>>  PANA (Protocol for carrying Authentication for Network Access) is a
>>  link-layer agnostic network access authentication protocol that runs
>>  between a node that wants to gain access to the network and a server
>>  on the network side.  PANA defines a new EAP [RFC3748] lower layer
>>  that uses IP between the protocol end points.
>>
>>  The motivation to define such a protocol and the requirements are
>>  described in [RFC4058].  Protocol details are documented in
>>  [I-D.ietf-pana-pana].  [I-D.ietf-pana-ipsec] describes use of IPsec
>>  for access control following PANA-based authentication.  IPsec can be
>>
>>
>>  used for per-packet access control, but nevertheless it is not the
>>
>>
>>    
>>
>"per-packet access control" - don't you mean per-packet "security" or
>some other word that captures authentication, confidentiality, etc.
>
>  Ohba: I think "per-packet ciphering" might be OK.
>
>  
>
>>  only way to achieve this functionality.  Alternatives include
>>  reliance on physical security and link-layer ciphering.
>>
>>    
>>
>...Particularly given this comparison.
>
>  
>
>>Separation
>>  of PANA server from the entity enforcing the access control is
>>
>>
>>    
>>
>s/PANA/the PANA
>
>  Ohba: OK.
>
>  
>
>>  envisaged as an optional deployment choice.
>>
>>    
>>
>You are talking about the PANA server before it is defined. After it is
>defined or by using some other wording for "PANA Server", this above
>sentence could read much easier as something like:
>
>The PANA Server [remember to define what that is] may or may not be
>co-located with the entity enforcing the per-packet access control function.
>
>  Ohba: OK.  BTW, the term "server" is already defined in the first
>  paragraph of Section 1, but it seems that the term "server" does not
>  automatically link to the term "PANA server".  So I think it is
>  better to replace the term "PANA server" with "server of PANA":
>
>  "
>  The server of PANA may or may not be co-located with the entity
>  enforcing the per-packet access control function.
>  "
>  
>

>  Note: I think it is better to revise the first paragraph of Section
>  1 to use the term "client" to represent the counterpart of the
>  server, something like:
>
>  "
>    PANA (Protocol for carrying Authentication for Network Access) is
>    a link-layer agnostic network access authentication protocol that
>    runs between a client that wants to gain access to the network and
>    a server on the network side.  PANA defines a new EAP [RFC3748]
>    lower layer that uses IP between the protocol end points.
>  "
>
>  
>
>>SNMP [I-D.ietf-pana-
>>  snmp] is chosen as the protocol to carry associated information
>>  between the separate nodes.
>>
>>
>>    
>>
>
>"By "separate nodes" I assume the PANA Server and "entity enforcing
>access control" ? How about something like: "When the PANA Server and
>Access Control functions are separate, SNMP is used to carry information
>between the two nodes."
>
>  Ohba: The suggested text looks good.  BTW, there was a discussion as
>  to whether SNMP is a mandatory protocol between the PANA Server and
>  Access Control functions, and it appears that SNMP is not a
>  mandatory protocol.  So we might further revise the text as:
>
>  "
>  When the server of PANA and per-packet access control functions are
>  separate, SNMP may be used to carry information between the two nodes.
>  "
>
>  
>
>>  PANA can be used in any access network regardless of the underlying
>>  security.  For example, the network might be physically secured, or
>>  secured by means of cryptographic mechanisms after the successful
>>  client-network authentication.
>>
>>
>>    
>>
>It "can" be, but "should" it be? This type of statement is a red flag
>for security ADs, just a warning.
>
>  Ohba: How about: "PANA is intended to be used ..."  (I personally
>  think that "should" is strong considering several EAP transports
>  defined over L2 such as IEEE 802.1X and IEEE 802.16e PKMv2.)
>
>  
>
>>  The PANA client, PANA authentication agent, authentication server,
>>  and enforcement point are the relevant functional entities in this
>>  design.  PANA authentication agent and enforcement point(s) can be
>>  placed on various elements in the access network (e.g., access point,
>>  access router, dedicated host).
>>
>>
>>
>>    
>>
>What about the "PANA Server" ? Is that really a PANA Authentication
>Server? I think you need to reorder this intro a bit. Define the
>relevant functional entities before talking about how to place them.
>
>  Ohba: I agree that PANA client, PANA authentication agent,
>  enforcement points are not defined in this section.  On the other
>  hand, the first sentence does not seem to important and can be
>  removed.  So we can revise the paragraph something like:
>
>  "
>  The server of PANA and per-packet access control functions can be
>  placed on various elements in the access network (e.g., access
>  point, access router, dedicated host).
>  "
>
>  Also, I think we can move this paragraph upward to the place where
>  relationship between the server of PANA and per-packet access
>  control function is discussed.
>
>
>  
>
>>  IP address configuration mechanisms vary as well.  Static
>>  configuration, DHCP, stateless address autoconfiguration are possible
>>  mechanisms to choose from.
>>
>>    
>>
>
>Please include a reference for DHCP and stateless address autoconfiguration
>
>  Ohba: OK.
>
>  
>
>>If the client configures an IPsec tunnel
>>  for enabling per-packet security, configuring IP addresses inside the
>>  tunnel becomes relevant, for which there are additional choices such
>>  as IKE.
>>
>>
>>    
>>
>Reference for IKE.
>
>  Ohba: OK.
>
>
>
>
>
>_______________________________________________
>Pana mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/pana
>
>  
>

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 19 Dec 2005 12:39:55 -0500

Hi Mark,

Thank you for the response.  

On this matter, we will revise sections 1 and 2 by using the terms
"server for PANA" and "client for PANA".

Regards,
Yoshihiro Ohba