[Mip6] Revised minutes of IETF61 WG meeting

[[e-mail]]

Minutes of MIP6 WG meeting
--------------------------

IETF61, Washington DC
Nov 12th, Friday 2004
9 AM - 1130 AM

Chairs: Basavaraj Patil and Gopal Dometty

Minutes provided by: Samita Chakrabarti and John Loughney 


1. Agenda bashing and WG doc status update
-------------------------------------------

- MIPv6  Socket API - completed last call - now on AD review
- Firewall issues I-D completed LC
- MIP6 MIB status: MIBdoctor pass1 completed; pass2 ongoing

- TAHI test suite will release version 3.0 in December which is fully
  compliant with RFC3775/3776
  URL: http://www.tahi.org/mipv6/

2. Auth I-D discussion
----------------------
   A consensus call on standardizing this I-D was held on the WG
   ML. Chairs believe consensus was to progress the I-D as a proposed
   standard. An issue tracker for the I-D has been created. Comments
   are welcome.

Thomas Narten: There is an appeal to the Consensus call result now. 
Consensus was rough, nice if it was clearer.
We don't formally vote.  Packing the room is something to look for,
but lurkers can be informed / posters can be uninformed. 
Counting company votes is dangerous.
 
Question / choices:
 1. Do not publish at all - has consequences for the relevance of the IETF
 2. Publish on standards track - sends signal that this has IETF support
 3. Publish as info - Does get IETF review & has been done in other
 cases, e.g. - 3GPP 

James K - has interoperability concerns, but if just for 3GPP2, then
its OK.  3GPP2 has come to the IETF, so we should do it.  Concerned
about standards track, because it might cause interoperability issues
due to multiple mechanisms.  Would like MIP community to work better
with 3GPP2. 

Thomas Narten - we've had a relationship for 3 years with 3GPP and
have engineer to engineer working, agrees that would be nice to have
with 3GPP2. 

Basavaraj - disagrees that there will be interop problems.  People who
want to deploy it are from 3gpp2, but could have wider possibly
applicability. Haven't heard about what the concerns of folks who
don't want this work to be standardized. 

Pervez Yegani - 3GPP2 needs this work, working with Thomas on liason
statement. Doesn't see an interop issue. 

James K - Explained twice already. IETF can specify two mechanisms,
but operator can deploy just one.  If you have a terminal that
supports both mechanisms, it may be confused which one can be used.
Problem is a deployment. 

Hesham - it's not an interop problem but a deployment problem.  In
similar circumstantes, sometimes a higher order mechanism is needed
for negotiation. Wants third option. 
 
Gopal - Disagrees with James.  We cannot control deployments.  This is
not 3GPP specific. 

Thomas - should be careful about calling it an interop problem.  Its
not black or white.  It might be that 3GPP2 wants to avoid the IPsec
mechanism.  There can be a cost with multiple mechanisms. 

Eric Nordmark - unwise to have multiple mechanisms; we will have to
implement both or circumstances will not work.  Thinks that some
assumptions are wrong.  If we have multiple mechanisms, then we should
have a good reason for this. 

Basavaraj - saying that the HA will need to implement both, terminal
will only need one. 

Jari Arkko - it doesn't have to be a weaker option. interop issue -
distintion is that 2 random nodes will authenticate to each other. 

Pete McCann - this mechanism is needed to interface with existing
credentials, removed IPsec from current architecture because IPsec /
IKE v1 cannot interface with existing credentials 

James - thinks we should go back to 3GPP2 and get them to find out
about what is needed for IKEv2 

Someone - wonder if this could be handled in IPv6 host or MIPv6 host.

Pervez - only argument we have heard against this is interoperability.
Don't we have rough consensus. 

Thomas - we don't vote, some people are debating the validity of the
consensus. 

Pervez - from the business perspective, saying it won't interoperate
isn't convincing. 

Basavaraj - doesn't see the benefit of publishing this as info.

Greg Daley - tried to stay out of this discussion.  Thinks we need
encryption between the HA & MN, but how to get the key?  Thinks we
should work on this, doesn't care about the status of the document,
but would like do work on this. We need an AS on this
mechanism. Concerned that the Security Area will barf on this. 

Thomas - 3GPP2 needs this soon, so we need to complete this.

Greg - then we need to get people involved in it.  Concerned about
there is no ESP here.  Need a checklist for this.  Need strong
applicability statement on the features - multicast traffic might be
spoofed, etc. 

Gopal - if we do go info, we will have deployment, then future work
can be dependent on it.   

Thomas - thinks this will be an ongoing topic for discussion.

Pascal - thinks there is an impact on other MIP related topics.  We
will have 2 solutions on the handset. 

Thomas 
  How many people don't want it at all - noone
  Do this as a standards track - 9
  Publish as informational - 30

Greg Daily- Release this as an experimental doc, but work on it still.

Thomas Narten- reasonable to pub as info, but work on it still

Hesham - can't have a contract promising anything, shouldn't be a
problem releasing it as info.  

Thomas Narten - 3GPP2 would prefer standards track.

Pekka Savola - we cannot make a contract, publish as info/exp. because
of timing requirements, and then analyze the problem more. 


3. IKEv2 on MIP6 (Vijay Devarapalli)
-------------------------------------
I-D: draft-ietf-mip6-ikev2-ipsec-00.txt

RFC3776 describes IPsec on MIP6
Changes in IPsec architecture (2401bis), and IKEv2 

- New draft to incorporate these changes
- SPD and SAD config and packet formats
- required processing steps on the MN and HA
- describes the use of IKEv2

Key negotiation
- Manual keying must be supported
Dynamic keying though should be supported

Dynamic key shoud or may?

Comment - do you mean public key certificate?
- we have manual key for pre-shared key
Jari Arkko: The draft talks about how to use IKEv2 but this is optional- no
need to support it. In that case there is no issue.

SPD config
  New selectors
   Mobility header msg type
   ICMPv6 message type

If IPsec specifieds mobility header as a selector, then MIP6 should
support it. 

Question: How do you make interfaces of IKEv1 and IKEv2  work together
in IPsec? 
Vijay - The new IPsec will not be interoperable with the older one
Hesham Soliman - Are we going to step away from per-interface SPDs
                 Moving away from current interfaces is a good move.
Vijay - We still need to distinguish payloads in different cases,
tunnel, without tunnel etc.

PAD configuration
Peer auth data base provides a link bet key protocol and SPD

SAD config
Use of IKEv2 to negotiate keys
MN initiates IKEv2 exchange
Identity is included in IKE_AUTH

Use of EAP

- MN indicates it wants to use EAP by leaving IKE_AUTH field unfilled
IKE_AUTH should be done after EAP exchange
Issues
- takes 4 round trips instead of 2
- Should work with other EAP and AAA-HA interface
- Should we say HA MUST/MAY require this interface?

Home address configuration:
Must or May ?
Jim Kempf - It should be "SHOULD"
Erik N. - It looks like a bootstrapping solution. It should be linked
with bootstrap to have a single solution
Jari Arkko - thinks bootstrapping support here is a good thing.

4. Using IPsec to protect signaling between MN and CN (Francis Dupont)  
----------------------------------------------------------------------
I-D: draft-dupont-mipv6-cn-ipsec-01.txt

Presented at the last IETF
Idea : When you have IPsec bet, CN and MN, just use it Has some
details in the doc what is suitable. You need SA between CN and MN etc.

Question:
       - Should it be WG item ?

       - Seperate doc for the cookie-based COA test? (optional)

       - Implementations(already one, others?)

Vijay - Will support it to become WG doc

Jim Kempf - We should think about how it interacts with Mobike.
            We should make this as wg draft.
Suresh -   It should be a wg document

B Patil -  Anyone has objection to make it wg doc ?  If not we make it
as wg doc
No objection was raised at the meeting.

4a: (Francis Dupont)
-------------------
COA cookie test

- Initiated by CN , usable by CN which does not have built-in COA
  test/trust 
- A state cookie is used in order to avoid DOS attacks
- non-empty IANA consideration section

Next step:

Which RO protection mechanism do we need?

Vijay - it can be an optional care-of-addr test

WG item? More discussion needed before we make a wg doc.

Christian V: We had mailing list discussion but it modifies the way base
             spec does.
Jim Kempf - We should be more systematic in thinking about one solution or
             piecemeal soln

Erik -  Don't see how we tie in with RO cookie test.
        If the threat is third party bombing attack, then how does it help?
        What are the security requirements?

Jari - I'd rather have Charlie's draft do COA addr test. Also take a look at
       the draft we produced in Mobopts

5. AAA AND MOBILE IPV6 (Giaretta Gerardo)
-----------------------------------------
5.1	I-D: draft-giaretta-mip6-aaa-ha-goals-00.txt & 
	I-D: draft-yegin-mip6-aaa-fwk-00.txt    


Motivation:
Dynamic MIP6 conf
MN-HA sec association
AAA-HA interface
- Interface between AAA of the MSP and HA (HA is a kind of access server)

Basic security model

MN --------------------MSP AAA -----------------------HA

Usage scenario - bootstrapping  directly with HA

MN -----NAS------AAA-MSP-----HA

Junghoon - Given EAP exchange is there any network access server?
          We first need to have access through NAS then the second step
Ans:It is a direct interaction with HA

Pete M : We can separate out network access from MIP access. We should not
         tie them together.

Junghoon : What is the meaning of performing IKEv2 before network
           access service ? If a MN can access(like, performing IKEv2)
           the visted domain network without granting the network
           access, it can result in a possbile attack to that network.


 Usage scenario 2

MN --- NAS--------AAA-MSP -------------HA
<-------piggybacked
         MIp6 within
          EAP        -> <---AAA-HA ------>   A)

<-- PANA, L2
      DHCP
     extension->< RADIS/DIA-><---AAA-HA-->  B)


Hesham - Make it generic
Comment - Focus should not only focus AAA-HA protocol, but
         also NAS-MSP-AAA
Greg D - Did not read the draft. If you have security across
         NAS, AAA-MSP, HA- Do you already have security association
         between MSP and HA?

Hesham - This is a good way to use IPsec in MIP6

James - This solution is not going to work if you don't have AAA
infrastructure 

Usage scenario3
MN---------NAS_____________AAA-MSP -------HA
<IKE--------------------------><---AAA-HA--->
                               <--BU?------->

Goals:
Security, Accounting etc.

Next steps
Should we identify a protocol that fulfil the goals?
DIAMETER, RADIUS, SNMPv3

Similar draft by Alper on AAA-HA interfaces - Raj has sent
out the pointer to the slides. In the interest of time, the draft was
not presented. Raj described briefly the highlights of Alpers I-D.

Hesham : What is the requirement? - Should the requirements go to AAA, midco
m  ?
No reason to put requirement for midcom wg

James Kempf - likes this, would like to remind people that there are
hotspots without link security and authenticates via web page.  This
solution won't work if you don't have a AAA infra. 
Should we work on this?

Hesham Soliman  - what is the intention of this?

Basavaraj Patil - development requirements for AAA work.

5.2 MIPV6 AUTHORIZATION AND CONFIGURATION BASED ON EAP    
------------------------------------------------------
I-D: draft-giaretta-mip6-authorization-eap-02.txt   Giaretta Gerardo

someone - how to define aaa server between ha & aaa server?

Pasi Eronen - lots of info that would like to provision to user.  EAP
isn't the right approach. 

Jari Arkko - agrees with Pasi.  There are procedural issues as well as
technical.  This approach might not require AP changes, but changes to
EAP methods.  If you can re-use existing protocols, this is easier.
If you want to use EAP for new purposes, this is harder. 

James Kempf - would prefer to be minimalistic here.

Hesham Soliman  - agree we need to draw a limit, but there are 3
levels of auth typically. There is interest in leveraging AAA infra
for this. Doesn't think this will change EAP much. 

Next step
- Waiting for EAP wg feedback
- WG doc?

MN-HA Ipsec SA can be estblished from a shared secret using IKE with PSK auth
EAP method can be used to exchange PSK

Jari A- There are some other requirements in EAP methods.

5.3 APPLICATION MASTER SESSION KEY (AMSK) FOR MOBILE IPV6  
---------------------------------------------------------
I-D: draft-giaretta-mip6-amsk-00.txt Giaretta Gerardo

Jari Arkko - question on changes to EAP framework. As a whole, there
are more requirements than just on EAP methods, may be changing EAP
API. 

Hesham Soliman  - does EAP SIM produce an AMSK?

Jari Arkko - I think so.

6 DIAMETER MOBILE IPV6 BOOTSTRAPPING APPLICATION USING PANA  
-----------------------------------------------------------
I-D: draft-jee-mip6-bootstrap-pana-00.txt
I-D: draft-tschofenig-mip6-bootstrapping-pana-00.txt

Junghoon Jee, Hannes Tschofenig

PANA is used between MN and HA
Used to bootstrap mip6-auth

Pac <<<PANA message exch----> HA

Does wg think PANA is appropriate to deliver bootstrapping info ?

New DIAMETER bootstrapping scenario?

James K - PANA can work with EAP. Has a problem defining PANA to go
beyond 1st hop link. ICMP often doesn't work after 1st hop.
Yoshihiro Ohba - PANA is based on UDP
James - OK, so I guess that is not a problem.

7. MOBILE IPV6 BOOTSTRAPPING ARCHITECTURE USING DHCP    
----------------------------------------------------
I-D: draft-ohba-mip6-boot-arch-dhcp-00   Yoshihiro Ohba


Model 1 - DHCP server AAA-MS client
Model 2 - NAS as AAA-MS client

Draft describes how this arch map to bootstrapping scenario

James Kempf - Ralph Droms mentioned that backending DHCP server into
AAA server is not a good idea. Same problem about NAS pushing stuff
into DHCP server. OK to put Home Address into DHCP server.  Concerned
about the complications & bittleness of this. 


8. BOOTSTRAP CONTROL FUNCTION MECHANISM FOR MOBILE IPV6 BOOTSTRAP
-----------------------------------------------------------------
I-D: draft-deng-mip6-bootstrap-bcf-00.txt Hui Deng
- Introduced new network element (BCF)

      AAA           ------- HA1
         |          |
MN -----BCF --------  ---- HA2
                    |
                    --------- HA3



Discuss on list with rest of the bootstrapping stuff. Possible design
team issue. 

9. PRECOMPUTABLE BINDING MANAGEMENT KEY KBM FOR MOBILE IPV6
-----------------------------------------------------------
    I-D: draft-ietf-mip6-precfgkbm-01.txt
    Vijay Devarapalli

- Proceed with this document.

10. IMPROVEMENT OF RETURN ROUTABILITY PROTOCOL
----------------------------------------------
    I-D: draft-qiu-mip6-rr-improvement-00.txt
    Jianying ZHOU

DOS attack, session hijacking, movement halting attack
Problem HOTI/COTI - independent of COA and HoA

use HOA in COTI and COA in HOTI for authentication and signals

Christian V.- Even if you combine the two, the attacker will have
           ability to attack

Yes - but it is much more difficult, as it needs to know both addr

Erik - If we do this, we can't keep the same home keygen when COA changes

Jari - What's the point becuase the packets are flying by anyway and has
        same limitation that Erik mentioned

11. Next steps for WG
---------------------

- Bring closure to Auth and Identifier
- Taking transition problem as wg doc
- DT for bootstrapping
- Revise charter based on privacy bar bof


12. Multihoming in MIP6
-----------------------
Thierry Ernst
I-Ds: draft-montavont-mobileip-multihoming-pb-statement-02.txt
         draft-ernst-generic-goals-and-benefits-00.txt

Motivation for multihoming
Applied to fixed hosts, mobile hosts and routers

Seeking sense from the room

Shall we include support multiple interfaces in MIP6 WG ?

Thomas Narten: A problem statement for multihoming is required
               first. Multi-homing working group is working on
               different issues - so the problem statement document
               would indicate the non-mobility cases and carefully
               consider the mobility cases. Once we identify those,
               we can then consider whether and what this group needs
               to address.

Gabriel: I have a question: if you are going to characterize the
	multihoming problem then are you also going to consider the
	case in which you have multiple IPv4 as well as multiple IPv6
	addresses? Will get hairy, but at least mentioning might be in
	order. 

13. Load Balance for Distributed Home Agents in Mobile IPv6
----------------------------------------------------------
   I-D: draft-deng-mip6-ha-loadbalance-02.txt
   Hui Deng

Loadalancing for MIP6 was presented.

The question to the WG is whether loadbalancing is a problem that
needs to be tackled in this WG.











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