RE: [Pana] Preliminary pana-pana draft (13a)

Yoshi,

Thanks a lot for the revision.

Here I have few comments and suggestions.

   By the virtue of enabling transport of EAP
   above IP, any authentication method that can be carried as an EAP
   method is made available to PANA and hence to any link-layer
   technology with a minimum link-layer dependency.  There is a clear

Alper> What's that dependency?

   There are components that are part of a complete secure network
   access solution but are outside of the PANA protocol specification,
   including IP address configuration, authentication method choice,
   data traffic protection, PAA-EP protocol, and PAA discovery.  PANA
   authentication output is used for creating access control filters.
   These components except for IP address configuration are described in
   separate documents (see [I-D.ietf-pana-framework],
   [I-D.ietf-pana-snmp] and [I-D.ietf-dhc-paa-option]).  The IP address
   configuration component may be specified in deployment-specific PANA
   applicability documents.  The readers are recommended to read the
   PANA Framework document [I-D.ietf-pana-framework] prior to reading
   this protocol specification document.

Alper> "IP address configuration" is not really part of a secure network
access solution. I'd recommend this re-write of the above paragraph:

   There are components that are part of a complete secure network
   access solution but are outside of the PANA protocol specification,
   including authentication method choice,
   data traffic protection, PAA-EP protocol, and PAA discovery.  PANA
   authentication output is used for creating access control filters.
   These components are described in
   separate documents (see [I-D.ietf-pana-framework],
   [I-D.ietf-pana-snmp] and [I-D.ietf-dhc-paa-option]).  
   The readers are recommended to read the
   PANA Framework document [I-D.ietf-pana-framework] prior to reading
   this protocol specification document.

      The protocol entity in the access network whose responsibility is
      to verify the credentials provided by a PANA client (PaC) and
      authorize network access to the access device associated with the
      client.  The PAA and the EAP authenticator (and optionally the EAP

Alper> I'd remove "associated with the client."

      session cannot be shared across multiple network interfaces.  Only
      one IP address of the PaC is allowed to be bound to a PANA session
      for simplicity.

Alper> i think we can remove the last sentence. Sure we don't explicitly
support multi-homed clients, but no need to explicitly limit to single-homed
either. Being silent is a better choice.

   The PAA MAY refrain from retransmitting the PANA-Start-Request
   message to maintain as less amount of state as possible in the
   handshake phase.  For this reason, the PaC MUST retransmit the PANA-
   Client-Initiation message until it enters the authentication and
   authorization phase by receiving a PANA-Auth-Request message from the
   PAA.

Alper> Just to add a bit more elaboration (to prevent questions), I can
recommend 

   In order to prevent potential DoS attacks, the PAA MAY refrain from 
   timeout-based retransmission of the PANA-Start-Request
   message in response to a PaC-initiated handshake. For this reason, 
   the PaC MUST retransmit the PANA-Client-Initiation message until it 
   enters the authentication and authorization phase by receiving 
   the first PANA-Auth-Request message from the PAA. 

   session, it MUST silently discard the message.  Transmission of this
   error request is made optional in case this behavior is leveraged for
   a DoS attack on the PAA.  A Nonce AVP MUST be included in the first

Alper> There is no more error message generation. Hence the sentence
starting with "Transmission of this..." shall be deleted.

   If IPsec is used between the PaC and the EPs, an IKE [RFC2409] IKEv2
   [RFC4306] or MOBIKE [RFC4555] run is needed following such a change.

Alper> This is not something for the base PANA specification to state. It's
for PANA-ipsec document. Let's remove the above paragraph.

   messages MUST be protected with an AUTH AVP.  The PAA may also need
   update the per-packet enforcement policies of the EPs, however, this
   is out of the scope of this document.

Alper> This last sentence shall be removed too. As you said, it's out of
scope.

   For other PANA messages, the source port MUST be set to a value
   chosen by the sender. and the destination port MUST be set to the

Alper> Remove "."

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

Alper> this shall be under the informative references.

Thank you.

Alper

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
> Sent: Sunday, November 19, 2006 10:39 AM
> To: pana@ietf.org
> Subject: [Pana] Preliminary pana-pana draft (13a)
> 
> is available at:
> 
> http://www.panasec.org/docs/editing/pana-spec.html
> 
> (Now we get 17 pages reduction.)
> 
> Please do sanity check to make sure that all resolutions discussed in
> IETF67 and over mailing list are reflected appropriately.  Diff from
> revision 12 is also available.
> 
> As soon as sanity check is done, I will submit a new revision (13)
> which is to be used for IETF last call.
> 
> Regards,
> Yoshihiro Ohba
> 
> _______________________________________________
> Pana mailing list
> Pana@ietf.org
> https://www1.ietf.org/mailman/listinfo/pana

_______________________________________________
Pana mailing list
Pana@ietf.org
https://www1.ietf.org/mailman/listinfo/pana