Subject: [Pana] Issue 72: Capability discovery during PAA discovery

From: Alper Yegin <[email-masked]>
Date: Tue, 27 Apr 2004 13:07:04 -0700

Proposed text changes for Issue 72. 
Comments welcome.

[1] 4.2 Discovery and Initial Handshake Phase

Change:

   PAA MAY enable NAP-ISP authentication separation by setting the
   S-flag of the message header of the PANA-Start-Request. Also, the
   PANA-Start-Request MAY contain zero or one NAP-Information AVP and
   zero or more ISP-Information AVPs to advertise the information on the
   NAP and/or ISPs.

To:

   Protection-Capability and PPAC AVPs MAY be optionally included in the
   PANA-Start-Request in order to indicate required and available
   capabilities for the network access. These AVPs MAY be used by the
PaC
   for assessing the capability match even before the authentication
   takes place. But these AVPs are provided during the insecure
discovery
   phase, there are certain security risks involved in using the
provided
   information. See section 11 for further discussion on this.      

   PAA MAY enable NAP-ISP authentication separation by setting the
   S-flag of the message header of the PANA-Start-Request. Also, the
   PANA-Start-Request MAY contain zero or one NAP-Information AVP and
   zero or more ISP-Information AVPs to advertise the information on the
   NAP and/or ISPs.

[2] 9.3.3 PANA-Start-Request (PSR)

Change:

   PANA-Start-Request (PSR) is sent by the PAA to the PaC. The PAA sets
   the transmission sequence number to an initial random value.  The
   received sequence number is set to zero (0).

         PANA-Start-Request ::= < PANA-Header: 2, REQ [SEP] >
                       [ Cookie ]
                       [ EAP-Payload ]
                       [ NAP-Information ]
                    *  [ ISP-Information ]
                    *  [ AVP ]

To:

   PANA-Start-Request (PSR) is sent by the PAA to the PaC. The PAA sets
   the transmission sequence number to an initial random value.  The
   received sequence number is set to zero (0).

         PANA-Start-Request ::= < PANA-Header: 2, REQ [SEP] >
                       [ Cookie ]
                       [ EAP-Payload ]
                       [ NAP-Information ]
                    *  [ ISP-Information ]
                       [ Protection-Capability]
                       [ PPAC ]
                    *  [ AVP ]

[3] Figure 10

Update two rows on Figure 10:

                          +-----------------------------------------+
                          |        Message                          |
                          |          Type                           |
                          +-----+-----+-----+-----+-----+-----+-----+
      Attribute Name      | PSR | PSA | PAR | PAN | PBR | PBA | PDI |
      --------------------+-----+-----+-----+-----+-----+-----+-----+
      Protection-Cap.     | 0-1 |  0  |  0  |  0  | 0-1 |  0  |  0  |
      PPAC                | 0-1 |  0  |  0  |  0  |  1  |  1  |  0  |
      --------------------+-----+-----+-----+-----+-----+-----+-----+

[4] Section 11:

Change:

   a) Discovery message exchange

   In general it is difficult to prevent a vulnerabilities of the
   discovery protocol since the initial discovery are unsecured. To
   prevent very basic attacks an adversary should not be able to cause
   state creation with discovery messages at the PAA. This is prevented
   by re-using a cookie concept (see [RFC2522] which allows the
   responder to be stateless in the first message exchange. Because of
   the architectural assumptions made in PANA (i.e. the PAA is the on
   the same link as the PaC) the return-routability concept does not
   provide additional protection. Hence it is difficult to prevent this
   threat entirely. Furthermore it is not possible to shift heavy
   cryptographic operations to the PaC at the first few messages since
   the computational effort depends on the EAP method. The usage of
   client-puzzles as introduced by [jb99] is under investigation.

   Resistance against blind DoS attacks (i.e. attacks by off-path
   adversaries) is achieved with sequence numbers and cookies.

   Since PAA and PaC are supposed to be one IP hop away, a simple TTL
   check can prevent off-link attacks. Furthermore, additional filtering
   can be enabled on the EPs. An EP may be able to filter unauthorized
   PAA advertisements when they are received on the access side of the
   network where only PaCs are connected.

To:

   a) Discovery message exchange

   In general it is difficult to prevent a vulnerabilities of the
   discovery protocol since the initial discovery are unsecured. To
   prevent very basic attacks an adversary should not be able to cause
   state creation with discovery messages at the PAA. This is prevented
   by re-using a cookie concept (see [RFC2522] which allows the
   responder to be stateless in the first message exchange. Because of
   the architectural assumptions made in PANA (i.e. the PAA is the on
   the same link as the PaC) the return-routability concept does not
   provide additional protection. Hence it is difficult to prevent this
   threat entirely. Furthermore it is not possible to shift heavy
   cryptographic operations to the PaC at the first few messages since
   the computational effort depends on the EAP method. The usage of
   client-puzzles as introduced by [jb99] is under investigation.

   Resistance against blind DoS attacks (i.e. attacks by off-path
   adversaries) is achieved with sequence numbers and cookies.

   Since PAA and PaC are supposed to be one IP hop away, a simple TTL
   check can prevent off-link attacks. Furthermore, additional filtering
   can be enabled on the EPs. An EP may be able to filter unauthorized
   PAA advertisements when they are received on the access side of the
   network where only PaCs are connected.

   In networks where lower-layers are not secured prior to running PANA,
   the capability discovery enabled through inclusion of 
   Protection-Capability and PPAC AVPs in PANA-Start-Request message is
   susceptible to spoofing. Therefore, usage of these AVPs during the
   discovery phase in such insecure networks is NOT RECOMMENDED.

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