MIPSHOP - Session - I

Date: 3/21/06 Time: 15.20 - 17.20

 

Chairs: Gabriel Montenegro and Stefano Faccin

Notes by: Srinivas Sreemanthula, Alex Petrescu, Basavaraj Patil and Greg Daley

Edited by: Stefano Faccin

 

 

Chairs (Stefano) Went over the agenda.

 

NEW CHARTER:

 

Approved with change in WG name to "Mobility for IP: Performance, Signaling and Handiff Optimization"

Work items addressed per revised charter:

i) Revise the spec of HMIPv6 (RFC4140) for security and streamlining.

ii) Revise FMIPv6 for security between MN-AR

iii) Application of FMIPv6 on link layers: 802.16 and 3GCDMA

iv) Improving MIPv6 RR via both cryptographically generated addresses and redit based authorization

v) Work on areas of mutual interest to IEEE 802.21 and MIPSHOP.

 

Chairs went over the timelines for the work items.

 

Yoshi: Is there a problem statement document for MIH services?

Stefano: Yes, there will be as informational document, even if not explicitly listed in charter.

Q: What is the draft-ietf-mipshop-mih-info-elements-XX.txt about?

A: Potential new IEs for mipshop related services. New Namespace for new IEs.

Q: one or two drafts for MIH services?

A: One draft in theory, may be split for ES/CS and one for IS if needed. Possible to have two different solutions, one for IS and one for ES/CS.

 

DOCUMENT STATUS:

 

Proposal for adoption of WG drafts:

draft-ietf-mipshop-fmipv6-rev.txt

draft-ietf-mipshop-fh802.16e.txt

draft-ietf-mipshop-3gfh.txt

draft-ietf-mipshop-cga-cba.txt

Will ask for consensus call for two weeks on the mailing list for acceptance of these documents.

 

Francis Dupont:  We should separate CGAs and CBA. Fate sharing for the technologies.

JAK: We should have one next generation protocol not two. if both are appropriate, we should have both.

Operator, wanting to deploy.

GM: Please send on mailing list to seed discussion.

 

PRESENTATIONS:

 

"Problem statement: Media Independent handover Signaling" (draft-hepworth-mipshop-mih-problem-statement-01.txt)

Robert Hancock presented on behalf of the draft author.

-          high level protocol architecture view in 802.21 and the relation to IETF

-          intention/focus of this draft to present the problem applicable to all MIH services from 802.21

-          basic protocol functions: transport and security

-          Make a generally useful solution, now initially targeted at 802.21. Not just for 802.1 services. End-result:  requirements analysis, which you would expect:

-          Reliability core security functions, integrity replay protection, etc.

-          Denial of service mitigation, etc.

-          additional protocol functions: discovery and proxy

-          what's next?

Qiaobing: Need the usage scenarios and network architectural discussion for IETF.

Robert: There is still some work needed to understand deployment scenarios but that should not stop us from carrying on the work based on current information available.

Qiaobing: make requirements part of 802.21 official documents. Lots of people interested in this.  Really should be made as part of the 802.21 draft and process.  May have own way of writing up the problem statements. Clear official list of 802.21 environments requirements would be good.

Robert: Want clear understanding of what the transport requirements are, and what the

MIH services are (how they act when carried over these protocols). Not waterfall cycle model: not trying to get it done autonomously first. But not waiting for requirements to be frozen first.

Qiaobing: In the charter: Layer three and above could mean other layers layer 4-7.  We need to have a very clear view of what the problem is.

Stefano: we will do the problem statement carefully.

 

"Requirements for Media Independent Information Services" draft-faccin-mih-infoserv-02.txt

 

Srinivas Sreemanthula presented.

-          high-level 802.21 framework

-          information services, usage scenarios and usage models

-          transport requirements

-          discovery and security requirements

-          Proxy Operation: mobile and single network node, could be proxies. Jari A. provided feedback, have been cleaned up in document. Other two forms are a part of the discovery service, redirection to another service (less obvious, equally required: but less easily canned in terms of standard protocol behavior).

-          This draft is a partly complete suggestion from people who are involved in 802.21.

-          Problem statement which this WG wants to work on it, needs statement here.

-          Need to work on boundary of IETF/IEEE work around the common header.

-          Need to work on what the actual requirements for Discovery and for Proxying behavior.  May require 802.21 and IETF convergence.

Behcet Sarikaya: about the exchanges, handover needs to be done in millisecond, can queries be done in time? Need to be done in every handover?

Srinivas: Done offline before handover.  Sensible way to do it, get information much before you need it.

Stefano: Need to do query before you handover if proactive, but also may need to do quickly.

Subir: are we doing new discovery mechanisms?

Stefano: that is not the intention, reuse existing mechanisms in IETF, define how to use them

Eric Njedjou: Discovery may be very linked to the way you do network deployment, may not be directly linked to handover, any work by the group on this?

Stefano: Will specify which discovery protocols are usable, won't work on new protocols.

Srinivas: Not asking for a new discovery protocol, just the requirements as needed.

Ajoy: are we doing new security mechanisms?

Stefano: need to identify security solution, may reuse existing solutions

Ajoy: what about capwap DTLS?

Stefano: Not the place to talk about that yet, that's solution space.

Srinivas: Some mobility considerations for security that works with mobility MiTM/DOS/replay, independent on MIS payload. Capability to disable to security in some environments. Compatability with ES/CS services.

Subir Das:  Assumes Security means transport security

Stefano:  Means security of the protocol

Subir: IEEE Scope plus IETF security.

Srinivas: MIIS query request/response on top of security

Stefano: out of time, continue on list.

 

"Requirements for Media Independent Event/Command Services" draft-sreemanthula-es-cs-problem-02.txt

 

Srinivas Sreemanthula presented.

 

SS: draft 02, link in presentation slides.

 

    Discussion from earlier event and command services over the internet.

     How and why event and command services can be sent over the Internet.

 

 

    Security features as discussed before?

 

Q: Why is it a separate work item?

A: When we started, in MIPSHOP and IEEE, not sure if a lot of commonality was going to be available. Some differences which we'll show.

Event sources occur at link-layers.  Could be other sources in IETF.

Q: What kinds of events are these?

A: new 802.11 access point, 802.16 or cellular, etc.

Command services are complementary, conveying network selection and operation information to the peer in order to initiate network change.

Q: Any overlap with mobility signaling?

A: no. Two aspects where CS is different to mobility signaling: no address updates, and no tunneling.

 

Hesham: what is FW traversal for IPv6?

Srini: to enable transport to pass through FW

Stefano:  may need to traverse firewalls, so we just need to be able to design something to work with them.

Hesham: What does it mean to traversal?

Stefano: If you have a firewall need packets to get past

Hesham: Cheat the firewall?

Hesham: so that is a dynamic configuration of FW

Srini: that can be a solution. We are just identifying a requirement.

John Loughney: Whatever solution shouldn't be impeded by firewall traversal. Firewalls block traffic.

Hesham: John Says don't use ICMP.

Srinivas:  OK, we can say don't use ICMP, need to be able to pass firewalls. Please consider as a single work item

 

 "HMIPv6 security", draft-haddad-mipshop-hmipv6-security-02.txt

 

Suresh Krishnan presented. Draft covers security for HMIPv6. Presenter asked for adoption as WG draft.

Hesham: Specifies strong security today using IPSec, but want to introduce non infrastructure solution.

Charter calls for HMIPv6 security. Only one document listed in the charter for HMIPv6. Revised document includes security? Separate draft on security? AAA or this or both?

Hesham: Situation is that we wouldn't like to rely on existing HMIPv6. Will reissue soon, but may be worth adding anyway

Gabriel: not sure if we're ready to do that yet (not permanent)

JAK:  Proposal not tied to it.  Security protocols, take FMIPv6 security out of FMIPv6 base, but other protocols where do they fit? FMIPv6, SEND based keys and AAA based keys... May be worth doing same mechanism for HMIPv6.

Hesham: responding to this: Paris HMIPv6 IPSec, EAP/IKEv2 AAA aspect, etc. Default way is like this for nomads.  Don't have PKI dependencies.

BS:  Comment on what james says: not sure if IETF would accept....

Gabriel: similar to 3775/3776, both go in parallel.

Gabriel: will Send e-mail to list for discussion on HMIPv6, etc.

Gabriel: don't adopt yet at this time, need to define all the security aspects related to HMIPv6

Hesham: we could have separate documents.

 

"Optimizying MIPv6 with crypto-based identifiers (OMIPv6)", draft-dupont-mipshop-omipv6-00.txt

Fracis Dupont presented.

  

Wassim: Not another proposal for optimizing MIPv6, but replace CGA in OMIPv6. Possible problem in OMIPv6-CGA, an attacker may learn the first keygentoken, and may construct valid BUs. Also, IPR problem.

CBID is non routable Identifier, doesn't have IPR, allows us to solve both issues. Just replacing the CGA and fixing a security issue.

No comments.

 

END OF FIRST SESSION.

 

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

 

MIPSHOP - Session - II

Date: 3/22/06 Time: 9.00 - 11.30

 

Chairs: Gabriel Montenegro and Stefano Faccin

 

Chairs (Stefano) Went over today's agenda - 6 presentations.

 

 

"Changes to FMIPv6", draft-koodli-mipshop-rfc4068bis-00.txt

Rajeev koodli

 

Being revised for proposed standard.

Public implementations: fmipv6.org, Tarzan

Issue tracker: mipv4.org/issues/tracker/mipshop

-          Issue 10: SPI in FBU - need handover key between MN and PAR, include SPI in the FBU as an option

-          Issue 15: Tunnel between PAR-NAR - NAR can setup a tunnel - so we continue keep this as an option?

-          James: simplicity is motivation

-          Rajeev: agree, but there are cases and arguments for the use, need to go back and check the threads

-          Christian: MN does not send FNA

-          Parviz: do we need tunnelling, are other options like bicasting considered? more favorable to 3GPP.

-          Rajeev: this a specific problem to 3GPP.

-          Bechet: are there any considerations to interwork with FMIPv6

-          Rajeev: there is probably no need for explicit interworking but some material is avilable in 802.21 related drafts on how they interwork

-          Issue 16: PAR buffering packets

-          Remove provision for buffering on PrRtSol?

-          Parvez - Shallow buffering should be okay (few packets)

-          Christian: there are vulnerability issues due to buffering resource usage

-          Vidya: support it and mention security issues

-          Rajeev: so we can keep and mention the vulnerability issue

-          Issue 9: verify changes to REACHABLE state (to be discussed later)

-          James:this should be investigated in relevance to SEND and opti-dad

-          Rajeev: opti-dad impl has kernel dependency so we need to be keep this in mind

 

"Fast Handoff for 802.16", draft-jang-mipshop-fh80216e-02.txt

Heejin Jang

Draft presented, no questions.

 

"Fast MIPv6 for 3G-CDMA network", draft-yokota-mipshop-3gfh-02.txt

Hidetoshi Yokota

 

Informational draft for adoption of FMIPv6 in 3G CDMA: LLC can be simplified, bootstrapping parameters can be obtained in FMIPv6 operations.

Changes from draft 01:

-          consideration of delayed FBU

-          new option for "handover assist" instead of extending the LLA option.

Bicasting is better in predictive mode

Delayed FBU: two different FBU based on which link is used,

-          case 1: when pFBU is received after nFBU - discard

-          case 2: when pFBU is received before nFBU - use

Issues: NAR is resolved by PAR with new AP LLA - define new vendor option

Rajeev: base spec says new option can be defined, but need to mention link specific implementations can define their own options

Parvez: need to consider inter-technology cases to ensure inter-operability

Bechet: is there anything specific to 3g-cdma in the draft?

A: yes

C: some parties indicated interest in seeing a consolidation of this and solution for WiMAX. Also, in using this more in general so that other for a can take advantage of it (e.g. 3GPP for WLAN IW).

Gabriel: it should be defined as vendor-specific but call it something link-specific

 

"AAA Handover Keys", draft-vidya-mipshop-handover-keys-aaa-01.txt

Vidya Narayanan

 

Previously presented, this is a recap

-          goal is to establish the keys for FBU/FBAck

-          single roundtrip

Status

-          no open issues

-          previous discussion - IP address validation, issue handled at IP layer or PPP, mention as guidance and best practice

Accept draft as WG doc?

Gabriel: ML is a good place to continue the discussion

Parvez: are all latency issued considered here to involve AAA framework for handover?

Parvez: what is the trigger for the HKReq?

Vidya: no need for triggering (perhaps subnet change)

Parvez: can we do CT?

Vidya: not a good way to do distribute keys.

James: there is a draft that lists all the issues related to key distribution (Housley)

Kuntal: anytime we involve AAA, it is not real-time based on implementation experience

Vidya: It is not done at the time of handover

Yoshi: some relevance to hoakey BOF.

 

"DHCP Neighborhood Discovery", draft-jang-mipshop-nhdisc-00.txt

Heejin Jang

Use of DHCP for 802.21 MIH IS

Proposes two new DHCP options for the support

Srinivas: need to check against 802.21 requirements, common transport for all MIH services is very desirable, DHCP does not work for ES/CS

Stefano: what protocol would you use between DHCP and MIS server?              

Alper: DHCP relay can be used

Srini: this will be a proxy model for IS but there is also a direct model that needs to be supported for IS, it would be good if there is only one protocol at MN for MIH queries

Stefano: There is also a security association issue that DHCP server must establish SA with many information servers?

Alper: It is a problem even for MN

 

"Access Authentication Protocol in FMIP6", draft-jung-mipshop-access-auth-00.txt

Souhwan Jung

Link-layer auth not sufficient for MN-AR i/f

Rajeev: is there a reason why PrRt exchanges must be done before AAuthReq? Also nonce must be moved out of FBU to reduce the latency issues

Madjid: why does the MN have to trigger this? AAA could do it offline (since MN is pushing AAK to NAR via AAA).

Geraldo: EAP is pre-requirement?

Vidya: the assumption is that link-authentication is not sufficient for access (link) authentication. Not sure if there is a concern

Srini: protocol completion for AAA req from PAR and AAA resp to NAR need to be improved, latency should be considered

Rajeev: key is to do it outside of handover procedure

 

WG ADJOURNED