Subject: [Pana] pana-pana Issue222: Misc. comments on Section 4.3

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 27 Dec 2005 11:55:18 -0500

>
>4.3  Discovery and Handshake Phase
>
>   When a PaC attaches to a network, and it does not already know the
IP
>   address of the PAA, it MUST rely on dynamic discovery methods, such
>   as a multicast-based and a traffic-driven discovery.
>  
>
For clarity, I would create subtitles for each of the methods below, and

state above that the multicast method MUST be implemented, and that the 
other MAY (I believe that is what I read below as the basic guideline
here).

>   The PaCs and PAAs MUST implement multicast-based discovery where the
>   PaC sends a PANA-PAA-Discover message to a well-known
>   administratively scoped multicast address (To Be Assigned by IANA)
>   and UDP port (To Be Assigned by IANA).
>
>   The network administrator MUST configure the multicast scope such
>   that the discovery messages can reach only the designated PAA(s).
In
>   case the PAA(s) is on the same link as the PaC, the administratively
>   scoped multicast messages MUST not be forwarded by the routers.
>   Details of scope configuration are discussed in [RFC2365].
>
>   The PAA(s) that receive the discovery message MUST respond with a
>   unicast PANA-Start-Request message sent to the soliciting PaC.
>
>   Alternatively, the PaC MAY also choose to start sending data packets
>   before getting authenticated.  The EP in an access network that
>   implements PANA SHOULD drop such unauthorized packets upon receipt.
>   Additionally, the EP MAY also take this traffic as an indication of
>   unauthorized PaC and notify the PAA.  The EP-to-PAA notification
>   SHOULD be sent via [I-D.ietf-pana-snmp].  In response, the PAA
SHOULD
>   send an unsolicited PANA-Start-Request message to the PaC.  This is
>   called traffic-driven PAA discovery (an alternative to the PaC
>   explicitly soliciting for a PAA).  Deployment of this alternate
>   scheme is optional.
>
>   The EP-to-PAA notification MAY also be generated in response to
>   receiving a link-up event notification on the EP [I-D.ietf-dna-link-
>   information].
>
>   Alternative PAA discovery schemes may be designed (e.g., DHCP-based)
>   but they are outside the scope of this specification.
>
>   If the PaC knows the IP address of the PAA, it can send a unicast
>   PANA-PAA-Discover message and initiate the PANA exchange.
>  
>
Might want to mention this first. It basically says to me, "if you know 
the address you may skip this section" - something that I would rather 
know sooner than later.

>   When the PaC receives a PANA-Start-Request message from a PAA, it
>   responds with a PANA-Start-Answer message if it wishes to enter the
>   authentication and authorization phase.
>
>   There can be multiple PAAs in the access network and the PaC may
>   receive multiple PANA-Start-Request messages from those PAAs.  The
>   authentication and authorization result does not depend on which PAA
>   is chosen by the PaC.  By default the PaC MAY choose the PAA that
>   sent the first PANA-Start-Request message.
>
>   A PANA-Start-Request message MAY carry a Cookie AVP that contains a
>   random value generated by the PAA.  The random value is referred to
>   as a cookie.  The cookie is used for preventing the PAA from
resource
>   consumption DoS attacks by blind attackers which bombard the PAA
with
>   PANA-PAA-Discover messages.  By relying on a cookie mechanism the
PAA
>   can avoid per-PaC state creation until after the PaC can produce the
>   same cookie in its PANA-Start-Answer message. 
>
But the PAA-Discover still must be processed, so it should be
rate-limited.

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