[Mip6] Minutes of MIP6 WG meeting from IETF65

Minutes of:
Mobility for IPv6 (mip6) WG
At: IETF65
March 20, 2006 (Dallas)

Chairs: Basavaraj Patil <basavaraj.patil@nokia.com>,
    Gopal Dommety <gdommety@cisco.com>

Credit for these minutes:
       1. Victor Fajardo (vfajardo at tari dot toshiba dot com
       2. Timothy Kniveton for being the Jabber scribe (tj at kniveton
       dot com)
       Jabber logs at:
       http://www.ietf.org/meetings/ietf-logs/mip6/2006-03-20.html

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

I. Chairs statements:

  1. Whats published
     - RFC 4238 
     - RFC 4285
  2. Whats in the editors Queue
     - mip6-firewall
     - mip6-mipv6-mib - standards
     - mip6-percfgkbm - standards
  3. Whats in IEST Evaluation
     - mip6-bootstrap-ps (info)
     - mip6-mipext-adavpi
  4. IESG Eval
     - mip6-ikev2-ipsec
  5. WG LC on mip6-cn-ipsec

  Comments:
     - HMAC-SHA1 in RFC4285 is 128-bit, why 128 and not 160 ?
       To be clarified by the authors.
     - HA reliability issue now has a design team
        a. problem document
        b. scope 
        c. solution

II. Presentations:

1. draft-ietf-mip6-v4traversal-01.txt  (Hesham Soliman)
   - joint working group item with NEMO
   - CoA address independence, bind IPv4 to IPv6 and vice versa
   - NAT traversal
   - 5 issues outstanding
  - No discussion on the mip6 alias
   Issue updates:
     a. Issue 58: Proxy ARP in HA
     b. Issue 62: Editorials
     c. Issue 64: Sending BU and BA in UDP tunnels
     d. Issue 63: Prefering IPv6 CoA when both v4 and v6 are available

   Outstanding:
     a. Issue 60 ligthweight keepalives
        Overview:
          - netbinding on 110 seconds w/c is cumbersome - ping like
      keep alive is needed
          - current keep alives relies on BU in the absence of traffic
          - need ligthweight version for small mobile devices
          - create ping-like mechanisms over UDP
        Comments:
          a. Neutral
             - NAT Binding alive on other working group (BEHAVE WG -
         NAT behavior),  can be inline with that work
          b. Pro 
             - because theres lifetime in the BU, not same as keep
         alive     
             - you must use the same UDP port so maybe not applicable to
             - expensive encryption
             - use only for keeping NAT bindings
          c. Against
             - do not think this is expensive
             - how about a lite BU ?
             - ecnryption may not be that expensive (Charles) if
               keep alives are very infrequent
             - maybe unecessary since other traffic can be used
               for keeping NAT binding, counter=for interoperability
     b. Issue 71: Use of the CoA option
        Overview:
          - use of CoA option requires the use of the HoA in the
      source address filed
          - This violates the format in RFC3775
        Comments:
          a. Against
             - Second bullet is wrong - there is no violation
          b. Pro
             - It is a violation since text on 3775 simply says
               "how to send BU"

- Dynamic detection of NAT in the HAs domain
   Overview:
     - current draft assumes that the HA is configured with presence of
   NAT in its domain
     - draft handles dynamic detection of the NA in the MN's domain
     - UNRESOLVED 
   Comments:
     a. Pro
       - super set scenario for flexibility
       - could be an extension if there is a strong need
       - more configuration makes it harder
       - not as costly
     b. Againts
       - no need for dynamic detection as a consensus
       - more complexity

2. draft-ietf-mip6-ikev2-ipsec, 2401bis - Update (Vijay Devarapalli)
   Overview:
     - Minor changes to address Jari Arkko's comments
     - Remove reference to EAP-ONLY-AUTHENTICATION Notificatin payload
     - should be pursued separately
     - The K-bit
         - do we still need the K-bit if we have MOBIKE ?
         - at least move it to separate section
         - discussion in the ML:
             - IKE SA is delete, associated IPsec SA are also delete,
   so updating IKE SA is important
             - does not make sense to use MIPv6 and MOBIKE at the same
               time
             - k-bit is easier in IKEv2 than IKEv1
   Comments:
     - cleanup k-bit issue (from Jari)
     - maybe out of scope ? - cannot say deprecate this flag
       in another doc, maybe say set or not but cannot say
       deprecate
     - no consensus to remove k-bit
     - make a statement regarding "if you use MOBIKE then dont
       use MIPv6". We need to be clear about it since there will
       be interoperability
          - what does mip6 want ? (jari)
          - we should do technical comparison before consensus
     a. Pro:
          - its fine to update 3775 because thats what we do
          - dont need to specify simulteneously use MOBIKE and MIPv6
            because it's just an opinion and you can make it work
            maybe information text somewhere
     b. Againts:
          - keep k-bit but clarify operations, not clear cause you need
            to know how to implement it
         - IPsec Selector Granularity
            - Cases
                - Fine grained selectors are supported
                     - tunnel mode SA for HoTi
                - Protocol level selectors are supported
                - Protocol selectors not available

3. draft-ietf-mip6-aaa-ha-goals-01 (Gerardo Giaretta)
   Overview:
     - Draft is fully reviewed
     - both split and integrated has been reviewed
     - has been updated in the latest version
     - Critical Portion:
         - G1.4 - AAA-HA interface SHOULD provide confidentiality since it
may
                  be used to transfer keying material - shared key generated
                  during EAP authentication
     - Unsure Porition:
         - G2.2 - HA should be able to query the AAH server to verfy MIPv6
                  service authorizaiton
                  Comments:
                       - Should'nt require solutions in this group
                  Reply from Author:
                       - Intent is to just list all the goals
         - G2.5 - HA MUST BE ABLE TO REQUEST THE aaaH server an
                  extension of the auth lifetime granted to the MN
         - G2.3 - 
                  Comments:
                       - AAAH server MAY enforce explicit operational
                         limitations and authorization
                       - Are you asking a doc fulfills the goals has to
contain
                         this spec ? maybe multiple docs - ansr: yes.
                       - What is the authorization protocol for use in
   this goal ? ansr: same as diameter - you can extend auth
   lifetime. Don't need to define new protocols since this is just a
   set of goals 
                       - Suggest remove 2.3 - difficult to do this in
   MIPv6, maybe use of this is logging that can be sent to HA but maybe
                         not possible in MIPv6
                       - What is the relationship with the EAP-EMSK ?
   needs to be discussed in EAP and followed by MIPv6
                       - John: what are the really things that you
   really need since DIME is working on a app for this
                       - Avi: issue with the work enforce
     - Main issues:
         - List requirements for AAA-HA interface
              - complete for split scenario
              - integrated scenario implies some MIPv6 attributes
   exchange from AAA to NAS
         - Should we broaden scope of the draft to encompass all AAA
   req for MIPv6 ? 
         Comments:
              - Intention: Get all AAA requirements
              - When is this avaialbe ? (john) - ansr: broaden scope
   first (raj) maybe next ietf
                but need more feedback

4. draft-ietf-mip6-bootstrapping-split-02 (Gerardo Giaretta)
   Overview:
    - WGLC last Dec
    - New ID available after WGLC
    - 2 open technical issues
         a. Use-ASSIGNED_HoA attribute
             - specifies a new IKEv2 notify message type in case the
   MN tries to perform HoA
               auto-conf but it is not allowed
             - proopsal during WGLC: the HA may raise
         b. DNS Update
             - some concerns: mobile should update only if trusted
               scalability issue if each MN has to established SA with the
DNS
             - no consensus to make the changes
             - DNS expert review requested
         c. MIP6_HOME_PREFIX attribute
             - draft specified attribute configuration in order to
   send Home prefix to the MN
             - no consensus
             - IKEv2/IPsec expert review requested
             Comments:
               - Do we want to ask expert if we want to have more
   prefixes ? ansr: try to
                 get some consensus in the ML on what to ask experts.
               - Configuraiton stuff in IKEv2 is not designed to do
   this ? ansr: thats why we ask experts for this
     - Next steps
         - authors request WG chairs for expert review
         - if more changes then new WGLC

5. Report on MIP6 operation with IKEv1 Interoperability test from TAHI
   (Shinta Sugimoto)
   Overview:
      - Interoperability testing in IKEv1 and MIPv6
      - Scenarios
           - K-bit = 0, results are in slides in the example message
sequence
           - K-bit = 1, results are in slides in the example message
sequence
      - Summary
           - rekeying in IPsec can be performed independely from MIPV6
   registration 
           - same with ISAKMP SA. However, ISAKMP SA sholud be closed
   when the MN changes its attachement

6. draft-sugimoto-mip6-homelan-access-00.txt (Shinta Sugimoto)
   Overview:
      - Seamless and secure access to home network
      - mip6 may fit well in this scenario, mip6 is assured to be
   connected to homelink
      - may rely on link-local communication to realize zero-conf
      - rfc3775 does not allow HA forwarding link-local traffic so
   propsed extension
           a. S flag - request link local home address, see slides for
   clarification on
              use of this flag
           b. link local multicast address option - allow MN to
   request for bypassing
              particular HA
           c. Alternate interafce ID option, valid only when S flag is
   set in the BU 
              message
           d. security considerations: exposure of net internals to
   third party, off-path eavsdropping

7. draft-dupont-ikev2-haassign-01.txt (Francis Dupont)
   Overview:
      - missing features for IKEv2 based solution
          - strong properties for care-of address
          - home agent assignment(==choice controlled by the home
         side): this document
      - security
          - basically secure (cant get Ss with a fake home agent)
          - default defense for DoS agains the hHA (stateless cookie)
          - defense for Dos against the mobile node
   Comments:
      - unknown from the chairs on how to proceed ? needs more
      discussion in the ML

8. draft-devarapalli-mip6-authprotocol-bootstrap (Vijay Devarapalli)
   Overview:
      - why ? current bootstrapping focus on IKEv2
          - Boostrapping HA
          - Home agent configuration
          - SA setup
          - RC4285 is an alternative to IPsec (and IKEv2 but does not
provide
            all the feateurs)
      - Reachability, no new mechanism, DNS update
   Comments:
      - Questions on why we need another bootstrapping protocol ? need to
have 
        further discussion on justifying the work

10. next steps for the WG
   Overview:
     - mip6 boostrapping, solution for split and integrated
     - v4/v6 tranversal
     - progress the location privacy for publication as information RFC
     - increase scope of doc AAA HA goals. doc to be last called in the WG
     - split the base protocol spec (mip6), i.e. sep route discovery etc.
   Comments:
     - give it time to have some implementation experience (question)
     - a few mistakes are there so we may want to take on the work also
       since there are dependencies (chair)
     - should be one document since its hard to keep track of the
     pieces (comment)

11. draft-chowdhury-mip6-radius-00.txt (Kuntal Chowdhury)
   Overview:
     - Bootstrap scenario for MIPv6 with RADIUS
     - covers the bootstrapping goals doc
     - split scenario
         - HA as a RADIUS client
         - RADIUS server may also instruct the HA to perform DNS
          update for the MN
     - integrated scenario
         - see goals
     - RADIUS attributes
         Comments:
             - should this work be in DIME or RADEXT ?
             - verify the neighbor case
             - add a mobile network prefix attribute
             - next steps, work in the goals people, maybe for the
           RADEXT group work

_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www1.ietf.org/mailman/listinfo/mip6