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

[Yoshihiro Ohba <[e-mail]>]

On Thu, Nov 30, 2006 at 05:43:48PM +0200, Alper Yegin wrote:
> 
> 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 is no link-layer dependency in the PANA protocol itself but
there is some link-layer dependency in the entire PANA framework
including EP which can be link-layer devices according to
pana-framework I-D.  

Perhaps we can remove "with a minimum link-layer dependency" since
this I-D is about the PANA protocol itself.

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

OK.

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

OK.

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

I agree.

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

OK.

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

Yes (and there is similar comment from Victor).

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

OK.

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

OK.

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

OK.

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

OK.

Regards,
Yoshihiro Ohba

> 
> 
> Thank you.
> 
> Alper
> 
> 
> 
> > -----Original Message-----
> > From: Yoshihiro Ohba [mailto:[e-mail]]
> > Sent: Sunday, November 19, 2006 10:39 AM
> > To: [e-mail]
> > 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
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/pana
> 
> 

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