Subject: [Mip6] IETF69: MIP6 WG meeting minutes

From: Basavaraj Patil <[email-masked]>
Date: Fri, 24 Aug 2007 17:28:24 -0500

Minutes of:
Mobility for IPv6 (mip6) WG
At: IETF69 (Chicago)
TUESDAY, July 24, 2007 from 1520-1720

Chairs: Basavaraj Patil <[email-masked]>
    Gopal Dommety <[email-masked]>

Credit for these minutes:

1. Kilian Weniger ([email-masked])

2. Jabber scribe: T.J Kniveton ([email-masked])

====================================================

1. Agenda review, Blue sheets and volunteers for
   notes and Jabber                                               5 Mins

2. WG status and I-Ds update                                 10 Mins
----------------------
- Raj announces public Home Agent Service
  Refer to slides for details of HA service.

- Status of MIP6 WG
    - last meeting as MIP6 WG.

- Status of MEXT (jari)
    - charter approved at IESG
    - remaining thing is to select chairs

- Document status
    - RFCs published
        - draft-ietf-mip6-ikev2-ipsec (prop standard)
        - draft-ietf-mip6-privacy-ps (informational)
    - RFC ed queue
        - draft-ietf-mip6-dsmip-problem (informational)
    - IESG review
        - draft-ietf-mip6-bootstrapping-split (prop standard)
    - AD review
        - draft-ietf-mip6-cn-ipsec (experiremtal)
        - draft-ietf-mip6-bootstrapping-integrated-dhc (proposed standard)
            - waiting for draft-hiopt
    - new WG docs
        - haley-mip6-mh-signaling (
    - completed last call
        - whyauthdataoption
        - aaa-ha-goals
        - hiopt
        - vsm
        - experimental-messages
    - ready for WGLC
        - rfc4285bis
        - hareliability
        - nemo-v4traversal
    - misc
        - draft-ietf-nip6-radius (waiting for AAA-goals ID complÈtion)

* discussion
- Vijay: aaa-ha-goals document is far from complete. Basic stuff is missing.
- Raj: this doc is expired. Please send comments to ml.

3. Mobile IPv6 bootstrapping in split scenario
   I-D: draft-ietf-mip6-bootstrapping-split-06           15 Mins
   Vijay Devarapalli
-----------------------------------------
* presentation
- changes since last version:
    - anycast-based HA assignment removed during security AD
   review because it may be applied elsewhere too (not only MIPv6)
    - use of PKI/certificates was underspecified
    - what to do if HA does not respond to IKE_SA_INIT was underspecified
    - format of MIP6_HOME_PREFIX attribute had mistakes
    - clarifications on home address authz

* discussion
- jari: no DISCUSSes anymore. Doc is ready to progress

4. DHCP Option for Home Information Discovery in MIPv6
   I-D: draft-ietf-mip6-hiopt-05.txt            10 Mins
   Heejin Jang
--------------------------------------
* presentation
- changes since last version:
    - no HoA assignment support anymore
    - clarification of meaning of id-types
    - clarification of use of multiple HN identifier options
    - new fields in HN information option
    - deleted MN-NAI option in relay-forward msg

* discussion
- none

5. Binding Revocation for IPv6 Mobility
   I-D: draft-muhanna-mip6-binding-revocation-01.txt     15 min
   Ahmad Muhanna
-------------------------------------
* presentation
- motivation for binding revocation
- binding revocation msg format
- proposes to adopt as WG item and change charter

* discussion
- Greg: Why is this better than sending BA with lifetime 0?
    - Sri: you can't revoke all binding with single BA msg
    - Greg: don't see how this can be secure
    - Ahmad: in case of PMIP, there is no per-MN SA
- Vijay: Why revoke a specific CoA in case of monami6
    - Sri: just to revoke one particular flow
- Raj: You said motivation is maintenance etc. Now you say its for
monami6 to selective revoke flows. Those are other, more complicated
scenarios 
- Hesham: Not sure if this works, since MN can switch flow to other
BIDs. So this flow is not stopped. To revoke all flows, you don'T need
BID 
- Kuntal: Example were it makes sense to revoke single binding is,
e.g., in IMS scenarios
- Hesham: Clarification: I think there are many ways to revoke
particular flows. Don't think this should be done by MIP HA
- Vijay: we just need simple revocation mechanism based on MN
identifier or HoA. Not more (not revoke specific flows)
    - Raj: agree, that would be too complex
- alex: supports use of binding refresh request
- alex: another technical comment to be sent on the mailing list
- alex: proposes another code, that tells HA to keep sessions up when
MN wants that 
    - Raj: in such case MN should go find another HA
- Kuntal: Important use cases are handover and clear-up of ressources
on old gateway. Maintenance is rare use case
- Ruji: We can treat every binding of multiple binding as single
binding. Support revocation of one of multiple bindings of a MN
- ?: thinks this draft is useful
- TJ: this should be kept simple.

- Greg: binding revocation must be sent by entity that MN has binding with

- chairs: How many of WG think that we should do binding revocation
    - extension for MIP6?
    - yes: 8+
    - no: 0
- chairs:
    - Let's have discussion on ml and then decide about adoption
      of draft as WG doc

6. Firewall Recommendations for MIPv6
   I-D: draft-krishnan-mip6-firewall-01            15 min
   Suresh Krishnan
--------------------------------------
* presentation:
- different scenario: firewall protecting HA, MN, CN, respectively
- recommends which kind of traffic should not be blocked by firewalls
- Adopt as WG draft?

* discussion
- hesham: just to clarify, only some firewalls in enterprise networks
block ipsec. Not in public networks
- frank: your solution makes network less safe (let all IPsec traffic
to HA through).  
    - Suresh: but this is the HA service, you have to let this
    traffic through
- Alex: some operators don't want to allow RO due to security weaknessses
    - Suresh: that's why we separated rules for RO and for non-RO

- chairs: status of design team? Are they finished?
    - suresh: there is some stuff more forward looking, e.g.,
    - talking to firewall. This draft is the first/essential step
- Jari: the future stuff sounds a bit dangerous. Why not rely on
    - access mechanisms? Why need something specific for MIP6.
    - suresh: Hannes wants to extend existing ipv6 protocol for mip6
    - jari: this makes more sense

- jari: so question is whether we do the BCP for the firewall rules
  here or leave it for MEXT? You can work on that under current
  charter 

7. Mobile IPv6 Extension for Configuration Options
   I-D: draft-bharatia-mip6-gen-ext-01.txt           15 min
   Kuntal Chowdhury
-------------------------------------
* presentation:
- motivation: get configuration from home network
- idea: MN includes option in MIP6 BU to request list of host config
   options. BA contains config info. Config information format is
   re-used from DHCP

* discussion
- Frank: Why use MN-HA interaction? BU is not very flexible. Why not
use AAA? Tomorrow we have another service, then we again need to
change specification.
    - Kuntal: if new service shall be discovered, then we just
    need to define another option code. AAA doesn't work, since MN
    does not talk to AAA server
- Ruji: 1. on home link, this mechanism doesn't work. 2. in PMIP,
better to decouple binding signaling and address assignment. You an
use DHCP 
- Greg: we have SLP, DHCP, MIH, Router discovery. So why do we need to
another discovery protocol, which we have to secure etc.
    - Raj: we should discuss this on the ml
- hesham: I agree with greg. Same discussion about that for mip4 some
years ago and IESG was against.
    - Kuntal: this work is currently done in mip4
- kent: sees difference between mip4 and mip6 case, since we have a
bootstrapping mechanism in mip6. Why not use it?
    - Kuntal: you could add AAA attributes + DHCP relay
- Jari: we don't do anything here before we know what happens to the
mip4 document 
    - Henrik: agree. we can't just assume that mip4 and mip6 case
    are the same. Why not just use DHCP on link?

8. IP Tunneling Optimization in a Mobile Environment
   I-D: draft-haddad-mip6-tunneling-optimization-01    10 min
   Wassim Haddad
------------------------------------
* presentation
- motivation: reduce tunneling overhead
- idea: removing inner tunnel header in MIP, PMIP,...
- PAD translator, which is XOR of inner and outer header
- PAD translator is updated by HA when receiving BU

* discussion
- chairs: There is an IPR disclosure on this draft
- sri: is it compatible with existing header compression like rohc?
    - suresh: yes, can use Rohc on outer header
- alex: it can work. Good to mention that it has IPR. rohc is much
more powerful. 
    - suresh: rohc has different stands than this one
- alex: this is no longer MIP6. So is this an alternative to MIPv6?
    - suresh: this could be done below MIPv6
- Hesham: this is fantastic. Good idea. And IPR is defensive, right
    - suresh: yes
- greg: this is good. The killer application is maintaining 1500bytes
MTU. You can't do that with rohc. But may not work immediately with
all CN addresses 
- Henrik: should define term BT. First though on Bittorrent, bluetooth ;)

9. Interfacing between IKEv2/IPsec & MIPv6 by simple PF_KEY extensions
   I-D: draft-qi-mip6-ikev2-interfacing-00.txt        5 Min
   Yang Peng
---------------------------------
* presentation
- provide interface between IKEv2 and MIP6

* discussion
- chairs: this has to be discussed based on the MEXT charter

10. Next Steps        Chairs                         10 Mins
----------------------------
- upcoming WGLCs and submissions to IESG

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