[Pana] IETF67: Minutes of WG meeting

[Basavaraj Patil <[e-mail]>]

Minutes of:
Protocol for carrying Authentication for Network Access (pana)
At: IETF67
November 6, 2006 (San Diego, USA)

Chairs: Basavaraj Patil <[e-mail]>
    Alper Yegin <[e-mail]>

Credit for these minutes:
1. Victor Fajardo (vfajardo at tari dot toshiba dot com)
2. Also Wassim Haddad (wassim dot haddad at ericsson dot com)


############################################


1. PANA Spec WG Document Status

  - AD review completed
  - SECDIR review completed
  - Ready for WG last call
  - Revisions required before WG last call


2. PANA Protocol Revision (Issues and Resolution)

  Speaker: Yoshihiro Ohba

  - AD review after IETF last call
  - PANA is getting more simplified
  
  Comments:
     Alper : Waiting for external review on language tag usage in
     Notification AVP
     Mark  : Still waiting for input - will lookup

  - Issues discussion

  #1 Session-Id
     * Globally unique session id is not needed
     * Use 4-octed session-id field in the PANA header, remove session-id
avp
     * Session-id is asssinged by PAA in the PSR/PSA exchange
     * Therefore, UNKNOWN_SESSION_ID error can be removed

  #2 Stateless handshake
     * Simplification of the stateless handshake - Removal of L-bit ?
        - Need to keep a minimum state to be maintained (cookie, initial
seq) 
        - Adding PSR retransmission to this state is not a big issue
     * Solution: 
        - Remove distinction between stateless and stateful
        - Remove cookie avp
        - Remove L-flag
        - PSR re-transmission may be turned off if PAA wants to be stateless

   #3 Device-Id
     * Do we need Device-Id ? Is IP address enough ?
     * Solution:
        - Remove text for Device-Id determination in the spec,
          maybe define this scheme in other documents
        - Remove text from Section 2 of the spec
        - Remove Device-Id AVP

   #4 Bootstrapping Lower-layer
     * Bootstrapping functionality thould be removed
     * Solution:
        - Remove PCAP AVP

   #5 Post-PANA Address Configuration
     * PPAC should be removed from spec
     * List discussion:
        - IP address configuration is orthogonal and out of scope
        - Each address configuration has its own re-config notification
     * Solution:
        - Remove PPAC AVP
        - Remove appendix A

   #6 Network Selection
     * Can be better defined in separate ID
        - Use RADIUS operator ID in place of SMI vendor id (needs
discussion)
     * Solution:
        - Remove network selection functionality
        - Remove related network selection AVPs

   #7 Nonce AVP
     * Sometimes contained ins PAR/PAN or PSR/PSA, simplify
     * Solution:
        - Remove Nonce from PSR/PSA
        - Specify that Nonce is carried only in the first PAR/PAN exchange

   #8 Filtering excpetion
     * Needs text for describing that EP needs to pass certain
       IP packets that are exchange prior to PANA operation (i.e. DHCP)
     * Solution:
        - Added new text breifly mentioning this requirement

   Comments:
      Alper : We need to discuss with AD to clarify the proposed text
       Mark : Filtering discussion began with Device-Id discussion.
              Why do you need it ?
              Because this is filtering (blocking certain traffic)
              If you don't have Device-Id how do you know which traffic
              to block. So either the spec needs to define one mode of
              operation when the Device-Id is one form OR it is say that
              filtering outside the scope of the doc.
              EP may be multiples-hop away and not in the path where it
              is capable of blocking traffic.
       Jari : Propse text where EP is several hops away. Details what
              this traffic type is. Its one way of avoiding this question
        Raj : If EP is a bridge, it makes sense to allow DHCP and other
              traffic to pass. Need to have clarification of where the EP
              is located.
       Jari : The current text is only for hand waving or warning. It will
              not be easy to get all scenarios documented.
        Raj : Why not use IP level filtering
      Mark  : I'm happy with document as it is including IP filtering mode.
              But it has to be clear where the EP should be. Its
un-realistic
              to define how it works in every case.
      Alper : Even if the spec wants to concern itself with other cases,
              it is up to the EP to implement enforcement.
       Jari : But readers of the spec needs to understand how this works. EP
              enforcement is outside of the protocol but still part of the
              system
      Alper : How about putting the text in the framework document
       Mark : Framework document is informational. Suggest we pick one mode
              or scenario that can be described OR declare the topic as out
              of scope
      Alper : I prefer the second option
      Glen  : Its not impossible to specify the scenario regardless of the
              location of the EP but it is impossible to specify the traffic
              that passing through it.
       Raj  : The current text does not mean anything from implementation
              point of view.
      Jari  : Yes. One approach is to say that specific applicaitons of
              pana has to specify how that scenario happens, i.e. PANA-IPsec
              document
       Raj  : Do we make this out of scope ? Or spec should say something
      Jari  : At least one doc should say something. If its not in the spec
              then it becomes completely open to different interpretation.
     Subir  : I agree with glen. If EP is 15 hops way, it will not be
      able to filter. Depending on the architecture then just say
      which traffic will be blocked.
     Alper  : It does not matter whether it is authorized or not, that kind
              of traffic will have to go through the EP.
      Mark  : With this text how do you know which is authorized client ?
              I'm happy if the spec says at least one model, say IP. It
makes
              more sense because we have something implementors can act on.
     Subir  : We need to say what kind of message your blocking
      Jari  : But its not enough.
     Subir  : How do you know which traffic from the client your passing ?
      Jari  : This depends on where the EP is. I would really like to see
              implementable text that needs to be blocked, i.e. protocol
              number, types, icmp ranges etc.
     Alper  : I agree but the discussion goes back to the spec. It's best
              not to discuss this at all.
      Jari  : Leave text but needs to be specified in other architecture
     Alper  : How much details do we need in the spec ?
      Jari  : Only application should specify these cases
     Alper  : Definition of un-authorized client and the allowed traffic
              type can be found in other spec, just add ref to the those
              spec

   #9 EAP message duplication handling
     * Do we still need to specify eap message duplication ?
     * Soultion: It should be removed

   #10 IP source/dest address

   #11 UDP port number
     * Why not always use well-know port number for destination port ?
     * Discussion
        - Use of an ephemeral port number contained in a request
        - Makes firewall traversal for PANA more difficult
     * Soultion:
        - Response is same rule

   #12 AVP message allocation policy
     * Missing spec on how to allocate mandatory supported avp or
       new message
        - IANA namepsce would be needed
     * Discussion
        - Mandatory-to-support AVP or new message would require new a
          new version of PANA specification
     * Solution:
        - Add "Standard actions"

   #13 PANA-error-requiest
     * PER needs to contain info on on what caused an error
     * Add new new Failed-Message-Header AVP

   #14 Condition to terminate request re-transmission
     * Request re-transmission is terminated when protected PER
       for the request is recieved

   #15 Other changes
     * Result-code AVP changes
     * Protocol error result changes
     * Include number of experimental message type from 2 to 16

   Comments:
     Alper  : Once we converge these soultions and send it
              back to Mark
      Mark  : Make a short IETF last call after compilation
              of these changes

3. DHCP options for PAA (Lionel)

  Speaker: Lionel

  - Report on DHCP options for PAA
  - Defintion of new DHCP option to local PAA in access network
  - Status
     - WG last call on *-03 issued in IETF66
     - Prallel work in DHC WG and PANA WG
     - Work Completely done Sept 1, 2006
  - Output:
     - Draft passed WGLC on both DHC and PANA WG
  - AD Review:
     - Jari, Thomas, Bernard
     - Results provided on 10/10

   #1 Resolution of DHCP option in the PANA framework
     - Used only to discover PAA address ?
     - Dynamic mechanism to inform DHCP client that PANA MUST be used

   Comments:
      Jari  : Some warning on security issues is needed when
              trying to use this method

   #2 Behavior of the DHCP nodes and Pac
     - Add text to clarify that
       * PAC should request DHCP PAA Option
       * DHCP server should send a client with the PAA option

   #3 Security considerations
      - If PANA is used for turning pana on/off
         * implications for spoofed PAA address ?
         * Risk of bidding down attacks
      - Answer: related to issue #1
      - There is no specific security issue if it clearly
        states that the option is used only to discover the PAA
      - Add some text in the scurity seciton to explain
        the issues

   Comments:
      Jari  : I'm happy with all of these once all these text will appear
      Alper : Where not using this text as a mechanisms
      Jari  : This is just a warning when discovered PAA address is found
     Alper  : It is equivalient to unprotected discovery mechanism
      Jari  : Similar issues with other scheme and this is enough

   Next steps:
     - Provide revisions based on discussion
     - Move the draft forward to IETF last call

4. PANA in DSL networks

   - New draft which describes use of PANA in DSL networks
   - Once the PANA framework document was simplified, the
     PANA use cases for DSL an WLAN was removed
   - Done in version 07
   - This draft is a spin off from the framework draft
   - Focus on DSL networks migration from traditional
     PPP access model to pure IP base access environment

  Use case
   - Evolution of DSL architecture
      - Two steps ATM to Gig and PPP to IP based
   - IP session model introduced in DSL forum
   - Currently, there is no built-in authentcaion
     mechanism

  Why use PANA ?
   - Security requiremetns required in DSL forum

  Location of PAA and EP
   - PPP base where BRAS is in charge of CPE network access
   - In IP-Session based enviroment
       - Functionality may be provided by the PAA and EP
         in the BRAS
   - It is possible to have PAA and BRAS to be not collocated

  Localion of Pac
   - CPE can be an L2 bridge and the Pac should be implemented
     in the host
   - CPE can be an IPv6 router then PAC should be in the CPE
     and host
     
   Comments:
     Yoshi  : In IPv6 case, is the IP address is a global address ?
    Lionel  : IP address should be visible from the BRAS, can
              be global or local depending on topology

  Other contents
   - Consideration for IP address configuration

   Comments:
     Yoshi  : For post PANA address notification are you relying on
              the IPv4 DHCP notificaiton scheme. What about IPv6 ?
    Lionel  : For PPAC notification, rely on what is existing
    Voytek  : IP is discarded in IPv4 after Auth. How do you propose
              protecting this scarce resource in the pre-PANA address ?
    Lionel  : We can rely on private IP address post PANA address
    Voytek  : Even using private IP can still exhaust the address space
     Alper  : If we rely on private IP, IP address exhaustion attack
              should be dtectable and since it is a brute force
      Mark  : Security considration should say this
    Voytek  : Always use a DHCP server ? Or are there other methods
              specially for embedded devices ?
      Mark  : Are these address configuration assumptions need
              to be documented ?
     Alper  : Who's assuming that DHCP server is external ?
    Lionel  : From the DSL forum, it should be external
     Alper  : Is the DHCP server on the BRAS
     Mark   : Is there an attack here where we can deplete the IP addresses
?
              The class of DHCP server existing on the BRAS is not as
feature
              filled.

   Next steps:
    - Collect inputs from the group
    - What level of detail sufficient ?
    - Should the draft be a WG document ?


5. PANA API draft

   Comments:
       Raj  : Should this be a working group draft ?
              API documents are not necessarily  WG docs
      Mark  : Its not within the working group theme
       Raj  : Other groups have published APIs such as MIPv6

Recommend that the work be progressed. Chairs to find the opinion of
the WG via the ML. 


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