MIPSHOP
Notes:
Acknowledgements:
the chairs would like to thank the volunteer note takers (Pete McCann - best
minute taker in history, Behcet Sarikaya,
Simone Ruffino)
=========================================================================
Session
I
1.
Agenda review, Blue sheets and volunteers for taking notes and Jabber scribe 5 Mins
2. WG
status and I-Ds update:
No new WG
drafts adopted.
Gabriel
Montenegro announced he will step down as co-chair.
A
candidate exists for the co-chair position, more candidates are welcome.
3.
Using Cryptographically Generated Addresses (CGA) to secure HMIPv6 Protocol
(HMIPv6sec), draft-haddad-mipshop-hmipv6-security-04, Wassim Haddad
Quick
overview of the draft: removes reliance on CBID, Rt
Sol message signed with CGA, AR replies with unicast RtAdv containing a shared secret, encrypted with teh MN's CGA public key
AR sends
a PBU, MAP creates a binding entry, MN sends LBU. The MAP sends its own public
DH value and the hash of Ks in the BA message.
Next steps? Authors believe that this version is in good shape.
Adopt as
WG item? Gabriel asks what item on the charter does this fit: HMIP security
Stefano
suggested additional discussion on the mailing list is needed.
4.
Authenticating FMIPv6 Handovers, draft-haddad-mipshop-fmipv6-auth-01, Wassim
Haddad
Motivation:
Each time the MN switches, must send FBU.
ARs are only one hop away, infrastructure can
be trusted.
Requirements:
- pAR must ensure that an FBU
message is sent by a "legitimate" node
- The
target of the FBU message cannot be any node
- Avoid
creating new privacy issues betwen the MN and CN
-
Minimize new messages
Proposal
- MN
generates a 64-bit OWCH and sends teh tip to its
first AR in RtSol message signed with CGA. Such action is needed only at the beginning
AR sends a unicast RtAdv
message signed MN uses OWCH to XOR the HV
- pAR validates FBU message by decoding the nCoA and pCoA IIDs
then verifying if the nCoA IID belongs to the OWHC pAR sends HV
Vidya
Narayanan: how are signaling messages integrity protected? If there isn't a
signature or a MAC then you cannot detect that it was changed
Wassim:
What do you mean it was changed? Access
router is only one hop away
Vidya: should
be a requirement that message is integrity protected
Wassim:
infrastructure can be trusted
Vidya:
not a good assumption. We need to
integrity protect the FBU/FBA neither can exist without a key
Gabriel
Montenegro: Rajeev, what are the security requirements in FMIPv6?
Rajeev Koodli: would have to go back and look
Vidya: if
it's not there, it should be there
5.
Handover Keys Using AAA, draft-vidya-mipshop-handover-keys-aaa-02, Vidya
Narayanan
Presented
only the changes since
Two
reviews received (official MOBDIR and unofficial SECDIR)
Summary
of changes:
- Replay
protection mechanism using timestamps alone
-
Sequence number field removed, no need for both sequence number and timestamps
-
Timestamp allows stateless AAA server function
- Error
codes streamlined, shouldn't send error code when check on the MAC fails
- Fixed
IANA section, not filled out earlier
- Defined
"PRF"
- Other
minor changes
- Message
summary added for clarification
Remains
to be done:
- MAC option
to be pulled into RFC 4068bis
- Draft
will be revised after update of 4068bis
-
Technical work is mostly complete
-
Extensive reviews received
-
Appendixes to be submitted as RADEXT and DIME documents
- AVPs separated out from the document
- Satisfied
all criteria for adoption as a WG document
Adoption?
Jari
Arkko: Discussion about this in RADEXT and DIME?
Vidya:
no, hasn't gone through discussion yet. Talked offline with John Loughney, he said once WG has adopted the draft we can make
a formal request
Jari:
there have been other requests, not going too well, might be good to check
first before committing to work here
Vidya:
what kind of problems?
Jari:
would be useful to talk to RADEXT to get an early understanding if there is
some kind of problem
Vidya:
it's modeled after 3957 so hopefully won't be a problem
Jari: we
need to check
6.
Distributing a Symmetric FMIPv6 Handover Key using SEND,
draft-kempf-mipshop-handover-key-00.txt, James Kempf
Rajeev
presented in place of James.
SEND-based
handover key distribution draft; no major changes from the one presented to
MOBOPTS
The idea
is to use SEND to derive a secret key at the access router.
SEND: RSA
Key -> IPv6 CGA A1 : A1 DAD with CGA
Some
other point the MN sends RS from A1 with CGA option,
router sends RA with key encrypted with public key of A1
FBU
contains new MAC option using key
Changes:
- Draft
now specialized for FMIPv6 only
- New
title
- Mobile
node identity based on the CGA key
-
Handover key assigned based on the CGA key
- Allows
mobile node to configure multiple addresses with the same key
-
Authentication algorithm is configurable
Undergoing
review prior to becoming a WG document
Hesham
Soliman: the flags indicate a specific algorithm for the AR to generate the
key?
Rajeev:
no, it is the algorithm used in the MAC
Hesham:
how many bits?
Rajeev: 4
bits
7.
Fast Handovers for Mobile IPv6, draft-ietf-mipshop-fmipv6-rfc4068bis-00.txt,
Rajeev Koodli
Updates
- A few
editorial changes based on mailing list comments
- Include
a new option in FBU
- HKE:
AAA vs SEND
- AT:
Algorithm type
Issues
- Why not
use RFC 4285? Almost identical except
for HKE and AT fields
- Why do
we need HKE and AT in FBU/FBack
- Why
SPI=0 needed
Rajeev
argues that we need to differentiate between AAA and SEND methods
Resolution:
- Remove
HKE field?
- SPI set
to zero, the HKE is SEND-based
- If a
new HKE is to be defined, relies on reserving an SPI value. Is this a good
idea?
Remove
the AT field?
Yes, AT is
set by the key derivation mechanism (AAA, SEND)
Hesham:
wondering whether it's useful to include this in MIP signaling at all.
Rajeev:
when you send FBU with this option, how does the router know which type of key?
Hesham:
aren't these bits added specifically for fast handover?
Rajeev:
yes, it is going to be part of the FMIP option?
Hesham:
you've already told the router that you want to use SEND
Vidya:
based on what you did earlier to derive the key, (SEND vs. AAA) when you are
sending the FBU, you're either using
Hesham:
are you assuming the MN will use multiple methods at the same time?
Vidya: at
the time of FBU processing, the AR needs to find the key
Hesham:
the key should already be installed
Rajeev:
the AR could use AAA for some and SEND for others. Even using IP address alone
you should be able to find the key
Vidya: at
the time the key was established, you can use the SPI
Rajeev:
AAA based scheme uses NAI not IP address
Hesham:
you're going to map the NAI to an IP address, which the AR will know.
Rajeev:
so what should we do?
Vijay: in
SEND, can you go back to indexing the SA with SPI? That SA will tell you what
keys to use.
Vidya: it
can be done, but it was felt that it wasn't necessary since IP address is
available at the time. If MN ping-pongs, it would be nice to keep the key around and use the
valid Sas for as long as the lifetime is valid
Hesham:
don't think that would be a good reason. The AR is keeping state for a while.
That state could be address.
Vidya:
but you could be changing the IP address
Hesham:
you don't need two parameters for it
Rajeev:
Handover key exchange field can be one of the mechanisms, algorithm Type may
not be needed.
Agree to
keep HKE but remove AT field
8.
Hierarchical
Nothing
has changed in this one since the last one, but there were a number of issues raised which we can discuss.
Nothing too major so far but there are some
significant items.
5 issues:
1: Expand
security to include allowance for cases where the MN is not configured with a
certificate. Some people said other models should be supported: CGA, AAA with
IKEv2 + EAP. Update agreed was to use IKE and IPsec, you can use certs or AAA (default), CGA (optional). IKEv2 didn't exist when the draft came out.
2:
Scalability of dynamic MAP discovery?
3:
Integration of the AR in the signalling path to allow
for triggering AR functions like context transfer
4:
Tightening up the spec language, e.g., making sure that the HMIPv6 can be used
without mandating that the MN has a permanent HA
5: Clean
up spec to include some new functions that were added to MIPv6, decide what is
useful what is not.
Most
options do not require any new behavior, but it's useful to mention that in the
spec. A lot of the extensions already
say whether they apply to HMIPv6 or not.
Alex Petrescu: some of the issues e.g., issue 5 are already
dealt with by related protocols, what is the rationale of adding mobile
routers?
Hesham
Soliman maybe not we have to examine it
Alex:
there has been a lot of discussion in NEMO BOF/WG to see whether to apply with
HMIP
Hesham:
it's not relevant to HMIP
Alex: can
use prefix delegation or DHCP
Jari:
when you talk about new functions, are you talking about introducing new
features, or just describing how these could be used
Hesham:
it's not the intention to extend a lot, just add some text about how to
Jari: it
would be inappropriate to start designing new things
Hesham:
don't want to
George Tsirtisis an implicit assumption that new MIP6 options can
be used with HMIP, but it might need going back to those specs and adding it
Hesham:
yes
Behcet Sarikaya: Adding this new entity
called MAP, is there any interest in SDOs?
Hesham:
Don't think there's anything public about it.
Behcet: what is your gut feeling about adding new features that
will ultimately make routers more expensive
Hesham: I
have no feelings
Charlie perkins: Can you compare solution
of HMIPv6 without HA to just using a local HA?
Hesham:
the only extension is the neighbor discovery: there is just a single bit which
says this is an HMIP registration
Charlie:
so it still could be a MIP6 work item to find an HA and use it
Hesham:
not sure it is needed
Charlie: allocating
a local HA has some AAA security implications. All those things will come up
again.
Hesham:
if you find something missing from the current security associations let us
know
Thierry
Ernst: interaction with nemo, Global HA-HA
Hesham:
We might go to nemo and ask them prefix delegation, we could just reference the work
Alex: are
you aware that prefix delegation can be done with DHCP? Why are you working on
it here?
Hesham: I
am saying we can do this work, identify the need, then go to NEMO and ask them
how to do it.
Alex:
Prefix delegation is going on in DHC not NEMO
Hesham:
there are 2 drafts
Alex:
they are somewhat outdated. Come to the
NEMO WG, there will be a rechartering
9.
Applying Cryptographically Generated Addresses and Credit-Based Authorization
to
Christian
not present, Wassim presents instead
Previous
draft version:
-Two
modes, used together
- But
missing description of individual application
Protocol
now offers 3 modes
In the
old approach, MN had to acquire a permanent shared key Kbm
New
approach in the current draft
- Acquire
a permanent home keygen token initially
- Run C/O
address test upon handoff
Question:
should we allow CGA-based address ownership proof for the correspondent node
also?
Vidya:
question: hash doesn't have to be an HMAC
Wassim:
it was like this since the beginning
Gabriel:
mode selection for different modes, why would we have 3 instead of 1?
Wassim:
not all nodes will have CGA.
Jari: another
reason was that if we actually separate the two, it is more logical, whatever
happens in the future we could fit them together rather than pull them out
again. Different
optimization for CoA vs. HoA.
Gabriel:
if we had CGA based ownership for CN would that add additional modes?
Jari: my
personal opinion is that it should be able to run client and CN independently
10.
Media Independent Handovers: Problem Statement,
draft-hepworth-mipshop-mih-problem-statement-02.txt, Eleanor Hepworth
Presented
by Stefano Faccin
Based on
new 802.21 requirements
Reminder
on what is 802.21
Handover
enabling functions ("MIH Services")
From the
draft charter, mipshop will define the transport -
draft-ietf-mipshop-mih-info-elements
How to
use the common transport protocol for MIH services in IP networks - draft-ietf-mipshop-mih-support
What is
the common transport protocol
This
draft is a strawman problem statement for the mih-support charter item.
A
solution meeting the goals in the problem statement should be generally useful
Presented
the basic protocol functions, the components of a solution, the IEEE 802.21
Transport requirements, and the 802.21 security requirements
Summary /
what next: Draft contains a definition of the problem that mih-support
shall solve. The draft is a suggestion from people with 802.21 knowledge, and
incorporates requirements officially approved in IEEE 802.21
Comment:
we don't have a specific item in the charter for a problem statement, but we
decided in
mic: multiplexing: is this something
coming from .21?
Stefano:
no, the only official requirements are listed
mic: understand that there is a need to
provide multiplexing
Stefano:
3 services defined by 802.21, this problem statement goes a little beyond what
is in 802.21. There might be future
services that use the same transport
George:
the idea is to provide a transport service to 802.21, but 802.21 is quite
complex. Are we sure that we have all
the information to define a transport protocol? Do we need to define one at
all?
Stefano:
if there is something that exists, that would be great
Behcet: the idea is not to define a new transport layer
Stefano:
on the first question, there are a number of IEEE members in the room, several people have made a request to review the
802.21 docs
George:
you already have conflicting requirements such as large file transfer and low
latency
Stefano:
if during analysis we find conflicts we should report them to IEEE
George: including
remaining future proof to other services
Stefano:
yes, may be difficult
Qiaobing Xie: We should make clear that
transport we are talking about here is for MIH entities, otherwise scope is too
broad
Stefano:
agreed. We can make it clear in the PS
Subir Das: you said there would be a common MIH protocol header
Stefano:
802.21 is giving us a set of high-level information
elements. How do we define MIH protocol
header?
Stefano:
Discussion between IEEE and IETF on who should define the MIH protocol header. It needs to be done in collaboration
Subir: Then this WG is doing a bit more than just defining a transport.
Robert
Hancock: It is an excellent point that you are never transporting completely
opaque blobs. There needs to be an interface between the upper layers and the
transport.
Stefano: IEs will definitly be
transparent, but whether they are sent during Information or Event services may
be different transport handling
Subir: it is not just like a transport, we are also involved at the service
layer. It needs to be clarified whether
we are going to take on all this work?
Stefano:
current charter defines it?
Subir: maybe but we are doing more than defining transport.
Junghoon:
Have some issues about the layering. 802.21 defines
the common header. If MIPSHOP wants to
define a common header here, MIH can be delivered at layer 2 or layer 3. The
peer entities use the same layer 2 or layer 3. If one entity uses layer 2 and
another uses layer 3.
Stefano:
the intention is not to have 802.21 define the layer, we will collaborate.
Yoshi: Need some clarification on how you use the common transport protocol
on IP networks (note, the comment/discussion is more related to the mih-mipshop-info-elements draft in the charter mentioned on
slide 4 of the presentation then about the PS draft itself)
Stefano:
there is still open discussion on what exactly would be the contents of that
draft. Still an open question. It may turn out that we
don't need that draft.
Yoshi: then there is a chance that the code space may not be used
Stefano:
will be discussed.
11.
Design Considerations for MIH Transport,
draft-hepworth-mipshop-mih-design-considerations-00, Eleanor Hepworth
Presented
by Robert Hancock
Where
does this draft fit in?
It can
serve as an intermediate step between the problem statement and the actual
solutions drafts.
Designed to be solution-neutral.
Problem
boundary issues:
-
Thinking about the design of the common part -> possible fine-tuning of the
layer boundary location
-
Signaling peer identification: one peer will be the MN,
it's not clear how to identify the other end
- MIH
state management: the MIH may need to refresh, tear down, modify
state in a peer. Does the common part know about these distinctions or just
move data around?
-
Multiparty operation: if there are signaling 'chains' (proxy operation) does
the common part see the whole chain or just adjacent nodes? All of these have
knock-on effects for the functionality inside the 'black box' as well
Yoshi: on peer id: MIH discovery of the peer is one thing,
you might also need a set of services to distinguish the peer. Assumption is
that MIH peer node is discovered at transport level (e.g. IP address) but
capabilities are discovered at the MIH protocol level, not transport
Robert:
to identify the peer, discover needs to be sensitive to e.g. type of MIH
service being discovered. It may be that IS is in one
place and CS is in another place.
Yoshi: current assumption in 802.21 is to discover any MIH peer regardless of
services. Maybe node needs to talk to each MIH peer to find out which one has
the services.
Robert:
that might be a large number of peers.
There may be a wide tradeoff space between design choices. One way to
deal with it is to do nothing just discover all peers and let upper layers work
on it, this might not be the best solution.
Akbar
Raman: what kind of state are you referring to
Robert:
connections are state. E.g., do the MIH Information elements have default
lifetimes for refreshing the neighbor list, or do they automatically tear down
connections on handoff.
Qiaobing: call control plane.
2nd assumption: just moving data around.
You don't know lifetime of data. That is controlled by whoever created
information elements. Consumer of data needs to understand whether info is
still valid or not.
Robert:
don't let the MIH state depend on the transport state
Akbar: design considerations was biased towards the GIST proposal.
It has to be re-worked.
Robert:
it is not written to support GIST document, the GIST doc is written to conform
to the DC. Anyway, common thinking tends
to come across. The intent of having the DC draft is so that we can have a
discussion independent of the solution. Please speak up if you have specific
items in the DC that you think are wrong
Akbar:
one thing that is missing is to re-use existing protocols maybe not as future
proof, but might be faster
Robert:
once you get past some irreducible minimum of complexity, it becomes better to
define a new solution.
Behcet: Best way to resolve these concerns would be to have some
of your text go to different drafts
Robert:
maybe, the draft is not expected to have a long lifetime it is to get people
aware of the design problems without tying to a particular solution.
12.
Supporting Media Independent Handover Protocols with GIST,
draft-hancock-mipshop-gist-for-mih-00.txt, Robert Hancock
A strawman for how to solve the MIH problem with a protocol
called GIST (General Internet Signaling Transport) developed in NSIS, nearly
baked.
GIST is
NOT about path-coupled signaling, that is just one way to use it.
Design
slide: GIST is a wrapper around a set of transport and security protocols. It is able to discover peers, capabilities.
To support MIH, you would have to do something on message routing and a bit on
choosing particular security association
Basic
Transport/Security Functions
- GIST
encapsulates standard transport and [channel] security protocols
- Initial
set: TCP & TLS but extensible
- It defines
a 3-way handshake which does capability discovery and option negotiation which
is resistant to DoS and downgrade attacks
-
Handshake is integrated with peer discovery
- Options
for Discovery
0. explicit discovery outside of GIST
1. (preferred): discovery proxied by
first-hop AR based on selection criteria in Query message
1*:
enhancement of (1) to discover multiple MIH services with a single query
Conclusions:
-
Assertion: using GIST provides a quick and robust way to integrate a large body
of security and transport functionality for MIH support
- Key
open issues go back to problem space: what are the criteria for signaling peer
location, do we need to provide additional security mechanisms, how to fit the
MIH protocol suite into the NSIS extensibility framework
Akbar:
you consider discovery to be a main problem that GIST is going to help you
with. If we think about practically in
wireless networks today, discovery is not generally a problem. It's not clear why discovery is such an
intractable problem that we need such a complicated solution
Robert:
it's not that complicated
Akbar:
but you said there might be a lot of peers that you have to discover
Robert:
there may be features
John Loughney: In terms of traditional wireless systems,
provisioning is done out of band. In some cases services don't get used because
that out-of-band doesn't happen. In 802.21 with wandering to different networks
you might end up tunneling back to home network which isn't scalable.
Rajeev:
who makes decision about protocol, MIPSHOP or 802.21?
Stefano: the only thing that .21 can do is set requirements and ask
IETF to satisfy requirements
Rajeev:
so who is making the decision?
Stefano: mipshop
Robert:
if there is some enhancement needed we can ask another group to do it.
=========================================================================
Session
II
13.
Network initiated handovers problem statement, draft-melia-mipshop-niho-ps-00,
Telemaco Melia
We have mobile
initiated and network assisted solutions but a flexible framework to support
both network assisted and network initiated HOs
Functional
components needed are described in the draft
NIHO with
IEEE 802.21 ES, CS, IS are enablers for NIHO and network assisted HO
Network
selection MN sends signal measurements MM makes a decision
Handover
execution: MM sends link switch command
Feedback
is requested
George:
what is the suggestion? IETF will define the transport for 802.21. Now handover
control using 802.21 on which we do not have control at IETF
Telemaco:
this is PS, identifies the problem
Stefano:
suggests discussing offline together with authors of other PS drafts and
interested parties
16. AR
information for FMIPv6 Messages Over IP,
draft-zhang-mipshop-fmip-arinfo-00.txt, Sam Xia
Sam
presented the draft shortly and then asked if there is interest in MIPSHOP.
Issue:
how to build the AP-ID,AR_info
tuple for MN (acquired from NAR)
Presents
a general model for collection: router collect AP info, a centralized FE
collects them, redistributes them to routers that pass it to other routers
Question
to the WG: is AR info collection MIPSHOP scope ?
Akbar:
one comment on jabber in favour.
Stefano:
suggests discussing it during PS definition
14.
Symmetric-key Based IPv6 Addresses, draft-narayanan-pba-01.txt, Vidya Narayanan
Originally
meant for INT Area, may not fit MIPSHOP but presented here
Some
discussion with Jari and Stefano, maybe not in scope, but discuss to introduce
in PS. Goal: get some feedback and check if agree with problem
CGAs provide IP address authorization (proof of address ownership), AAA does
not.
Protocols
that benefit: NDP (especially proxy NDP), MIP,HMIP,FMIP,
LMM
Deploying CGAs in AAA-based
systems unlikely.
AAA does not provide IP address authentication, added complexity. More logical to use AAA generated keys
Propose
AAA-based IP address authorization
CGA and
AAA based address authorization have different useful properties.
CGA
public key based no infrastructure support is needed but computationally
expensive, currently defined in SeND
Mobile IP
HA can not perform proxy ND on CGA address
SBAs symmetric keys to generate IPv6 address
Address
generator shares a key with the verifier which is AP, HA, etc. and its agent
which is AAA server
Computationally
cheaper than CGA
Con:
verification limited to entities that possess the shared key
FFS:
interactions w/ SBA, use of SBA for proxy ND, AGK generation
Suresh:
how will be used in
Vidya: AR
go to AAA to verify address. It is a cons and is FFS.
Suresh:
AAA serve can give the public key so there is not much advantage over CGA
Vidya:
advantage is that HA is able to defend address without private key of MN
Suresh:
there are proposals as well
Jari:
there is value in discovering the problems in neighbour
discovery
15.
Transport of Media Independent Handover Messages Over
IP, draft-rahman-mipshop-mih-transport-00.txt, Akbar Rahman
MManager in the network, how to transport MIH from MN to MM. 802.21
already has session, so we reuse that pipes.
Proposal:
Encapsulation of MIH message in UDP. New port number must to be defined
Reliability'
Delivery with ACK, DEFINITION OF three separate timers for IS, ES and CS
Example of signaling given
Works for
v4 and v6, uses DHCP to discover MIH (draft-daniel-dhc-xxx)
nodes and IPSEC for secure messages
Comment
on GIST: more complex, more future proof, hear comments from the WG about that
Eric: why
DHCP is needed to discover MIH service? Why not use SLP?
Akbar:
because it was in the problem statement
Subir: Reliability is required?
Akbar: it
is optional
Subir: three timers, it is worth considering if are they required or not
Robert:
performance implications need to be addressed in the problem statement because reliability
would affect the performance
Vincent:
scope and architecture not clear. 802.21 provides
flexibility but you are providing one proper case and your treatment is narrow
and in the transport also your approach is narrow. Is your approach applicable
to all cases?
Akbar:
good question. There are many other cases which are covered in the draft.
George:
Things are more complex. Have you looked at NAT traversal?
Akbar: no
=========================================================================
Stefano:
Way forward for WG
Common
draft on a possible solution by working together would be good.
Potential
WG drafts
- draft-haddad-mipshop-hmipv6-security-04, Wassim Haddad:
discussion on ML on whether it should become WG draft
- draft-arkko-mipshop-cga-cba-04.txt: proposed as WG draft, to
be confirmed over ML
Discuss
MIH PS
- Need a
single PS at WG level
- Chairs
strongly suggest interested parties to work offline and produce common PS by
last week of August. Target is to have PS draft in WG last call by end of
September
- Chairs
encourage discussion along the lines of design principles ID to align
discussion and point of view