[Mipshop] MIPSHOP Session II minutes

Hello,

here are the draft minutes for Session II. please send
me any corrections/revisions.

Session II
----------
WEDNESDAY, November 8, 1300-1500

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

2. HMIP and FMIP Security Association
   Alper Yegin
   draft-yegin-hmip-sa-00                                10 Mins

   After EAP, NAS and MN share MSK
   HMIP-key derived from MSK
   SA distribution - on MAP side NAS will deliver the key to the 
   MAP using the SA
      - IPsec PSK
      - rfc4285
   for non EAP-based architecture you need to identify an 
   equivalent of the MSK
   same applies to FMIP

Lakshinath: NAS is an edge identity ....

(lost.... the minute taker was standing at the mike)

Vijay: this is different from what we have in MIPv6. I don't 
see a real optimization because you just authenticate with 
the MAP once

Alper: this is an optimization

Hesham: this can be better for FMIP because you don't want 
to use IKEv2 with each AR. With HMIPv6 you can use EAPoIKEv2 
and you handle change of MAP with overlapping MAPs. I don't 
see a problem in re-using keys. To re-use MIPv6 work you 
should do a pull model instead of push model

Alper: you can use this approach also in pull model
Hesham: you are assuming that the NAS understands and is 
aware of the MAP. If the are multiple MAPs, the NAS must be 
aware of the MAP the MN is going to choose

Ahmad: how the SPI is used? how is it communicated?
Alper: SPI=1 at initial EAP auth. 

3. Mobility Independent Services: Problem Statement
   Telemaco Melia
   draft-melia-mipshop-mobility-services-ps-01.txt       15 Mins

   ps -00 version submitted at the beginning of Sep
   how to transport signaling messages for MIH
   appendix for different mobility services support
   comments to ID-00
      - make it shorter
      - make it 802.21 related but this may be in contrast 
        with what already agreed in IETF #66
   version 01
      - removed appendix
      - more .21 specific
   three possible options
      - main body only (version 01)
      - main body plus all appendixes
      - main body plus one .21 specific appendix

Juan Carlos: some technical objections because the text has 
some non .21 related aspects that are not useful. Supporting 
James proposal

Telemaco: according to the charter we should stick to .21

Subir: we should stick to what .21 requests. One way is to 
describe the general problem and then describe what is .21 
but this may imply we don't have a clear understanding on 
what we need to specify

Behcet: 01 seems to be good

Daniel: not sure which is the proble. In the draft you jump 
to deployment scenarios and solutions
Telemaco: you need to transport mobility information from 
the mobile to the network and vice versa

Daniel: it's not clear the gap analysis and why current 
solutions cannot be used

Juan Carlos: the draft needs some improvements for people 
that do not know .21

Stefano: please send detailed comments on the mailing list
on how to improve the document

Stefano: we would like to adopt the PS draft as WG item. 
Is there any objection? (no objection) We'll ask the same 
question on the mailing list 

4. MIH design considerations
   Robert Hancock
   draft-hepworth-mipshop-mih-design-considerations-01   15 Mins

   DC draft to capture IETF expertise
   DC draft should help the design process
   draft stucture
   activity since 00 version
     - discussion about particular solutions characteristics
     - reflect the underlying issues in the DC draft
     - GIST presented for information at 802.21
   Problem Boundary Issues
   Routing and Discovery
   some major architectural options
     - full MN control
     - discovery details delegated to the nw
     - discovery of adjacent peer or full path

Jari: in the DHCP WG we discussed that DHCP has been approved 
in .21
Robert: not approval status yet in IETF, nor in .21 draft 
(where just L2 discovery is covered)

Vijay: a lot of discovery methos. are all these applicable?

Robert: some are inappropriate (e.g. DNS SRV). DHCP and mDNS 
may have a role

Subir: in .21 draft, the discovery can be done also in DHCP. 

?: there is another alternative to discover the IP address of 
.21 peer and it's the .21 L2

Stefano: we can capture that L2 can be used but this is out 
of the scope

Jari: not sure it is out of the scope. We should focus on the 
problem definition in order to understand what is out of scope

Juan Carlos: about routing? is it IP routing?

Robert: it's signaling routing from one peer to another, not 
IP routing

Alper: is this doc informative or normative? Requirements?

Stefano: informative

5. Mobile and Wireless Neighborhood Discovery using DHCP 
   Alper Yegin                  
   draft-jang-mipshop-nhdisc-00.txt                       5 Mins

   DHCP for 802.21 IS (Alper)
   IS trasnport = DHCP
   IS client/server = DHCP client/server
   define new DHCP options
   where is the DHCP server?
     - by default in the serving network but it can be also 
       in centralized location or in the home network or in the 
       target nw
   you can rely also on the DHCP security
   this is configuration and DHCP is for that
   it's only for IS, not ES or CS

?: .21 provides three services. Do you think it would not be 
better to have a common protocol for all three of them?

Alper: ES and CS might have a common protocol and there may be 
link layer protocols

?: this is a problem statement document issue. Do we need to 
handle IS only or also ES and CS?

Yoshi: in .21 no requirement to use a single transport for 
all three services

Subir: requirement from .21 is for a transport protocol of MIH 
and not for particular services. Are only configuration 
information or more than that? I think that there are information 
like cost that are not configuration

Alper: it's configuration/information  

Subir: DHCP is for network parameters and not provider 
information

Stefano: this is once again related to the PS and I hope Yoshi 
or official LS can clarify that

6. Transport of Media Independent Handover Messages 
   Over IP  
   Akbar Rahman 
   draft-rahman-mipshop-mih-transport-01.txt             10 Mins

Yoshi: what is the proxy?
Juan Carlos: we are not passing the information at the IP 
layer all the way down. The Proxy just take out the information 
and deliver to the MN using L2 .21 but we want to leave this 
open for now

   DHCP to discover the Mobility Manager
   UDP as MIH transport between MN and MM
   IPsec for security

?: what defines the retransmission protocol?
Juan Carlos: .21 will do the retransmissions

Yoshi: it's not a proxy, it's a point of service because it's 
terminating a transaction and creating a new one

John: people will put NATs wherever they want. With UDP you 
will run in NAT problems. Now SIP is required to use TCP and 
UDP is optional

Stefano: you assume that the sessions are initiated by the MN 
but this may not be true for ES/CS. You are assuming the NATs
maintain the state for a long time and this is not true

Alex: if the MN must be reachable, then you need to solve the
NAT problem

?: it's not a session, it's an individual transaction

7. HMIPv6 Security Next Steps
   Chairs                                                15 Mins

   Proposal: use of EAPoIKEv2 is sufficient to progress
   HMIPv6 as a proposed standard 

Vidya: I agree. Do we need a document for SPD entries like 
rfc3776?
Vijay: we should be able to re-use what we have defined for 
MIP6. Assumption is to point to that but we can 

Jari: there is a need for some level of details. If this work 
cannot use the MIP6 document, the doc has some problems

Alper: why we don't use rfc4285 in HMIPv6?
Jari: is anything that we need to do? 
Alper: we should at least ack that it can be used

Jari: 4285 is not PS and we are doing PS 

Vijay: This does not mean we drop all work on HMIPv6 security
WG needs to decide if we still want to do another separate 
solution

James: I think it's sufficient EAPoIKEv2
Vidya: agree we don't need another option. If we look at 
futuristic options, not sure mipshop is the right place to 
do it

Vijay: We'll go with that assumption and we need to modify 
the charter. Any objections?

8. Next Steps
   Chairs                                                15 Mins

   WGLC on rfc4068bis 

Vidya: not sure it's ready for WGLC
James: there are still couple of issues in FMIP

   adopt draft-soliman-mipshop-4140bis-01 as WG item
   draft on CGA/CBA to IESG
   adopt draft-melia-mipshop as WG item
   DT to work on the solution

Jari: are you completing the PS draft before the DT?
Stefano: we would like to have a new revision before setting 
up the DT

_______________________________________________
Mipshop mailing list
Mipshop@ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop