IETF-64 meeting of the MOBIKE (IKEv2 Mobility and Multihoming) WG
Wednesday, November 9th, 2005
1300-1610

Chairs: Paul Hoffman and Jari Arkko
Notes takers: Pete McCann and Shinta Sugimoto (merging and edits by Jari Arkko)

Mailing list and issue tracker: http://www.vpnc.org/ietf-mobike
Presentations: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=64

Agenda

Part I
Preliminaries
Remaining Protocol WGLC Issues
Design Draft Update
Next steps

Part II
Extensions and new work
PF_KEY for MOBIKE
Trigger API for MOBIKE
Transport Mode Usage Issues

WG Document Status (presented by Jari Arkko)
============================================

New revision of design document was published.  Still some work but it
is getting close to done.

Most of the effort recently has been discussing protocol document - it
went through WGLC. The plan is to get issues resolved and send it up
to IESG.

Related Work, WG members were requested to read and review
- mip4-mobike-connectivity-00.txt
- Transport mode extension
- pfkey-extension
- trigger-api

MOBIKE Protocol Document Status (presented by Pasi Eronen)
==========================================================

WGLC ended on Oct 19th.

Approx 16 people commenting, filed as 29 issues in the tracker.  Most
if not all issues were clarifications that did not change the
protocol.

Version 05 submitted on October 24th
Version 06.a snapshot on Monday (link sent via e-mail)

A lot of mailing list traffic in October, right before the cut-off.

Editorial issues handled in version -05
    Issue 47 More comments from Mohan
    Issue 48 Editorial comments from James
    Issue 49 Editorial comments from Maureen
    Issue 50 More editorial comments from Maureen
    Issue 53 Editorial comments from Pete
    Issue 62 Editorial comments from Francis
    Issue 65 Editorial comments from Jari
    Issue 66 Imprecise NAT explanation
    Issue 67 Certain vs. possible changed address
    Issue 69 RR requirements

Other issues handled in version -05
    Issue 44 NAT mapping changes and rekeying
    Issue 55 MOBIKE scope and limitations
    Issue 61 Version number, again
    Issue 57 Question about initiator decides
    Issue 63 Extensibility and payload

Issues handled in version 06.a
    Issue 45 Clarifications to security considerations
    Issue 46 Questions about additional addresses
    Issue 58 Deleting addresses
    Issue 72 More editorial comments from Tero
    Issue 59 Editorial comments from Tero
    Issue 54 Editorial comments Marcelo
    Issue 64 Editorial comments and questions from Stephane
    Issue 56 Ingress filtering compatibility
    Issue 68 Conformance requirements

Open issues:
    Issue 52 Security of address updates
    Issue 60 Addresses in IKE_SA_INIT/AUTH
    Issue 71 Failing RR

Pasi went through the issues that deserved more discussion:

Issue 44 - How to detect NAT mapping changes

  Rekeying the IKE_SA can lead the initiator to believe NAT mappings
  have changed.  Noted in document

Issue 55 - MOBIKE scope and limitations

  Re-writing sections 1.2 (Scope and Limitations) and 3.1 (Initial IKE
  Exchange).

Issue 61 - Version number, again

  Now says MOBIKE_SUPPORTED data field is set empty when sending, but
  ignored when receiving. Allows for future extensibility and version
  numbering

Issue 57 - Question about "initiator decides"

  Not reopening old issue. Hopefully design document answers the part
  about "why".

Issue 63 - Extensibility and payload

  Comment about what extensions we might want to do in the future. Pasi
  chose not to put this in the protocol document, might go into the
  design doc

Issue 56 - Ingress filtering compatibility

  -06.a now sasy explicitly that MOBIKE sends reply to same
  address/port from which the request came

Issue 68 - Conformance requirements

  Clarified in -06.a, but discussion continued; Pasi thinks it is now
  ok

Issue 51 - SPI Collisions

  Implementation Considerations - IP address is not a good identifier
  for a host. Not necessarily unique (NATs). Does not identify single
  host over time (DHCP). Can change (MOBIKE). Ownership not
  necessarily authenticated.

  For these reasons (remote IP, remote SPI) is not a good identifier
  for outbound IPSec SAs

Issue 70 Non-SAD updates

  Jari: should highlight the bad implications of SPI collisions. If
  implementations don't implement 2401 correctly, traffic might be
  sent over the wrong SA and using the wrong keys

  This will be a part of the implementation considerations.  This is a
  bug based on interpretation of RFC2401, but Mobike could make it
  worse.  2401bis has this right (but many implementation details are
  beyond the scope of the spec).

  Added "Implementation Considerations" appendix to point out that
  implementors should be extra careful in this area

  No objections.

Issue 52 - Security of address updates

  Questions/comments about the security considerations text from
  Tuomas Aura. Raised before NO_NATS_ALLOWED was made mandatory
  (unless doing NAT-T).  Suggested heuristics to guess NAT status from
  address.

  Pasi's proposal: Do not add address-based heuristics: better to
  detect NATs using NAT_DETECTION_*_IP. It seems no changes needed.

  No objections.

Issue 60 - Addresses in IKE_SA_INIT/AUTH

  Current text: responder takes addresses from IEK_SA_INIT exchange,
  except when doing NAT-T (change to port 4500). When doing NAT-T,
  initiator could move to port 4500, thus, addresses taken from 1st
  IKE_AUTH.

  Tero's proposal: use 1st IKE_AUTH even when not doing NAT-T. Side
  benefit is that NO_NATS_ALLOWED can be moved to IKE_AUTH.

Issue 71 - Failing RR

  Problem: Initiator requests moving traffic to new address (sends
  UPDATE_SA_ADDRESSES) but responder requires return routability, but
  the new path has already failed, then responder does not get a reply

  When there's no attack, either of these should happen: Initiator
  notices the situation and can change to some other address
  (preferable) or Responder changes back to the previous address (doesn't
  work in all situations).

  Tero's proposal: clarify text about triggering dead peer detection
  We might trigger DPD if they don't have the addresses we're
  expecting

  Mohan: How would it receive the packet?
  Pasi: responder is sending packets 

  Picture of call flow discussed.

  Updated IKE SA but hasn't moved the traffic
  If the new path fails at exactly the right time, it could happen

  Jari: What happens with the failing RR exchange?  If you do that to
  the 2nd address, it works.  You have to do another one, can't use
  the same nonce.  Pasi: when initiator notices the new path doesn't
  work, it retries Do a return routability on the old path

  Tero Kivinen: If the address is changed, then must start over
  return-routability. Jari: After this explanation, I am happy with
  prooposed solution

  Mohan: if responder is going to do return routability, does he
  update the sa with the remote address? Pasi: yes

  No objections.

Next steps

  Close remaining issues.  Send to AD evaluation in 1-2 weeks.

  Jari: Should take it to the list.  In the room people don't have objections.

  Pasi: Would not like this to be another WGLC.  Jari: Last calls are
  just that: they are not recurring.

  Stephane Beaulieu: Are we automatically changing to 4500? Pasi: yes,
  if both implementations support NAT-T. Stephane Beaulieu: There are
  a couple of places in the draft that contradict that.

Design Draft (Tero Kivinen)
===========================

Only 2 people have read it (including Tero).

Question: Do we need to send this at the same time as the protocol
draft?  Jari: it is enough to have some version of it available by the
time IESG evaluates protocol document. Tero would like to have them at the
same time, will clarify the background.

Introduction and terminology

  Tero thinks the introduction is good enough, and does not require
  more work Do we need the terminology section at all?  Can we get rid
  of some terms?  (one of Pasi's questions) Keep some terms?

  Jari: It may be possible to remove some terms, but might imply that
  remaining terms need to change.  "Working address pair" implies L2
  telling you it is ok.  Hannes: Added many terms in a previous
  version to make things clear.  What is a path, what is an
  operational path.  Jari's document on shim6 was quite useful.  We
  should leave many of those terms.  Synchronize them with the main
  protocol document if they are not synchronized.

  Tero: Quite a lot of terms are used in only 1 or 2 places.  Agree
  they do make some things easier to understand.

Scenarios

  The design draft lists the basic scenarios, where the protocol
  should work In case we remove some terms this might need some
  changes

Scope

  Mostly ok no changes needed

Design Considerations

  Some sections had quite a big re-write: 
  - Choosing addresses
  - NAT Traversal

  Some might still need some work
  - Return routability
  - IPSec Tunnel and Transport mode

  Should be ok:
  - Scope of SA changes
  - Zero address set functionality

Protocol Detail Issues

  New or rewritten:
  - Updating address list
  - Path testing and window size

  Should be ok:
  - Indicating support for mobike
  - Message presentation

Additional Sections

  Do we need more text on simultaneous movement?

  Jari: Part of the process is about having the right set of things to
  talk about Let's make it too small rather than too lengthy Tero: in
  this text there were cases of simultaneous movement

Old sections rewritten to other sections
  - Changing a preferred address and multi-homing support
  - Storing a single or multiple addresses

Add text about issue 71 probably in RR

Summary

  Might still need some work (Terminology, scenarios, scope, and perhaps
  some new sections)

  Most of the text should be ready. Are we ready to WGLC now?  Maybe
  it would make people read it.

  Jari: I hope the question applies after you have updated the doc?
  Tero: Yes.

  Jari: Would be good to get it done in the same timeframe as the
  protocol doc

  Hannes: Because this document is a justification for the work, would be good to
  get input from outside the group to verify that.

  Pasi: Agree/disagree.  We need to make sure the design document
  explains the design in a reasonable way, so that we have some
  archival doc.  We don't want to open it up to people outside the
  working group to reset our design process.

  Jari: Right we are not redesigning anything, we are documenting the design.

  Tero: If someone suggests a new option, we might revise the design
  document to say why not.

  Jari: actually disagree: it is important that we scope the discussion tightly.
  There are an infinite number of things we could have done, do we really want
  to add an explanation for each one?  This should just document what the thinking
  was.  It may not even have consensus given a new set of people.  Of course
  if we get new information like "this is a bad idea" maybe in some cases we
  can include that but we should be careful.

  Mohan: As Pasi said, it's too late to change the protocol document.

  Hannes: I was misunderstood I was only talking about editorial changes

  Someone: I found the document quite helpful. Terms were useful too.

  Tero: That's good the one person that read it found it helpful

  Jari: Looks like consensus among the people who have read it (1
  person).


Future extensions
=================

Jari: Some discussion seemed to use the phrase "open issue #x".  If we
decide to do something new, it will be for a particular purpose not to
revisit the protocol design choices.

Application Programming Interface to a Trigger Database for MOBIKE (Hannes Tschofenig)
======================================================================================

draft-schilcher-mobike-trigger-api-02.txt

Motivation

MOBIKE has to maintain an address list for all available interfaces
Many events for changing the address set are outside the scope of
MOBIKE, e.g., 802.21. These information have to be combined with higher
layer information

Scope of the MOBIKE work discussed.

Proposal related to Mobile IP, NSIS, whatever other internal host component.

Features:

- Define an API to insert these information (so-called triggers) into a DB.

- Triggers can be provided to MOBIKE and other higher layer protocols.

- Offered services are quite similar to MIH, but can be extended for
  other protocols PF_TRIGGER IF is analogye to PF_KEY (based on BSD
  routing socket API).

MaureenStillman: are you talking about using what was talked about in
MIPSHOP?  Info, Command, Event?  Your word "database" = information
service?  Hannes: There is probably room for terminology. Only talking
about API.  What is there in the end host is someone else's
business. Maureen: So why do you need a trigger database, why can't
you talk an MIH event?  Hannes: DB is just conceptual, you could put
this in one box if you want. Could have used better terms. Didn't want
to stick exactly with the .21 work: there is not a strict dependency.

Jari: I have a similar question: don't fully understand.  Today we
already have some interfaces like IP can tell the application.  Are
you proposing an overall API that can cover & Transfer information for
all possible things like ND, DNA, .21, etc?  Or what? Hannes: That's right.

Mohan: Linux has netlink sockets.  Hannes: Very much related, but it
is an enhancement there might be more information.  How do we deliver
information to upper layers? Mohan: Depending on what information.

Pasi: This is collecting information from different places, when
should MOBIKE change from one address to another, isn't this exactly
what Mobile IP has to do as well? Hannes: True, have mentioned it in
Mobile IP as well.  Not aware that they are working on a specific
solution as well.  NSIS has similar problems.  Pasi: some OSes have
API that have mobility today.  Linux/symbian/windows have something
already existing.  Hannes: It is a problem that many vendors come up
with different solutions.

Bill Sommerfield: Not familiar with everything in MIH 802.21, seems in
the same space as existing PF_ROUTE interface.  This deals with
manipulating IP routing as well as get info about interfaces up/down.
It might be interesting to integrate with PF_ROUTE. Hannes: That has
been suggested.  We tried it with PF_KEY.

Greg Daley: The space is worthwhile, you are doing a disservice by
using the term trigger (remember trigtran?)  Information flow isn't
direct to MOBIKE.  A database seems like a passive entity.  You need
an active entity to control what is being passed up.  If you say
database it is just a repository.  Draft-iab-link-information is very,
very careful about which info to pass up and what to do with it.
Hannes: I know the document.  Agree that we probably didn't use the
best terminology it came from EU-funded project.  Because we used
PF_KEY ... you can register to get some events back.  Greg: It
becomes a path/route/connectivity change service, might be coming
through DNA.  (plug)

Someone: Agree should be done.  Relationship to past work in mobile
IP, some people have been working on PF_MOBILITY.  Others are thinking
about it, may be commonality.

Mohan: Quick check 3549 already discusses netlink services available
in linux. Greg Daley: I used 3549 netlink sockets to implement DNA.
Hannes: If someone is interested in further discussion please comment.


MOBIKE Extensions for PF_KEY (Hannes Tschofenig)
================================================

draft-schilcher-mobike-pfkey-extensions-01.txt

Extensions to PF_KEY: PF_KEY interface to access SAD (RFC 2367) does
not have dynamic address update supported. This is one of the core
features in MOBIKE, and a new message has to be defined.

   SADB_X_ADDRUPDATE
   

Access to SPD, which is not supported in current version of PF_KEY
Needed for example in transport mode for traffic slector updates
Question: extend PF_KEY vs. define a new interface for SPD?

Algorithm IDs have to be specified. Some extensions are needed.

Conclusion: Extension to PF_KEY is needed. Procedure on PF_KEY
extension is difficult.  RFC 2367 is not what is used today, more than
just updating to RFC 2367 with regard to MOBIKE functionality is
needed.

Someone: PF_KEY is interface to keys, would prefer a new interface.
Pasi: If you are using Linux IPSec, it doesn't necessarily use PF_KEY.
There is PF_KEY emulator.  What's in the RFC doesn't do half of what
people want.  Hannes: Then what should we do?  Let vendors do whatever
they want?

Jari: Main question is not just what the IETF wants to do in this
space, does anyone care?  Tried to do something about it 10 years ago,
no one cared.  What's important is whether people who implement this
would ever use what we defined.  If we have implementers coming in
telling us they want a new interface, we should think about that.  We
have PF_KEY extension in the charter, personally think it needs to be
done with a bigger PF_KEY effort if any.

Bill Sommerfield: Historically, every so often, there is some energy
spun up, but no one gets around to writing PF_KEYv3 document.  Jari:
Not enough, someone would have to use it.  Bill: Right, problem is
getting all the various cats herded.  Would be interested, but there
is too much other work.

Tero: most implementers are going to use their own APIs anyway.  If we have a 
      workable PF_KEY stuff, then there would be emulation layers like Linux 2.6.
      We did have a PF_KEY emulation layer about 10 years ago, it was removed
      because nobody used it.

Transport mode discussion (Mohan Partsarathy)
=============================================

Summary of what happened on the mailing list
There are 4 different things:
- SCTP
- Mobile IPv6
- IP-in-IP tunnel + transport mode SA
- TCP/UDP + transport mode SA

SCTP case
  SCTP (RFC 2960) supports multi-homing. SCTP just picks one address. It
  also returns a transport address list that can be used by ULP.
  
  Destination (and source address) of a packet can change due to various reasons
    - Apps can change the primary path at any time
    - Retransmission SHOULD use a different destination address from last time
    - SACKs to duplicate data may be transmitted using different address from the source
    - HEARTBEATS
  
  SCTP dynamic Address Configuration
  (draft-ietf-tsvwg-addip-sctp-12.txt) is sitting in RFC editor's queue.
  
  SCTP usage in IKEv1
    RFC 3554 describes SCTP usage with IPSec for IKEv1. Not a commonly used feature.
  
  SCTP in IKEv2
    Presumably would use MOBIKE.
  
  SCTP and MOBIKE usage:MOBIKE allows only initiator to change the
  addresses of the SA. MOBIKE uses only one pair at a time. Issues:
    - Similar problem exists in shim6 WG (shim6-SCTP interaction)
    - Either side of the SCTP association can change the path anytime
    - conflicting with MOBIKE?
    - SCTP HEARTBEAT vs. IKEv2 PATH_TEST conflict?
  
Mobile IPv6 use case

  MN HA use transport-mode SA for protecting the BU and BAcks.  Use
  case 1 (Francis' draft): Use MOBIKE to add the home address as
  alternate address (using ADDITION_ALADDRESS_IPv6 Notification)

  Use case 2: MIPv6 has built-in support for this.

Use of IPSec Transport mode for dynamic routing (RFC3884)

  This use case was closed as Issue 7. IKEv2 supports transport mode
  for tunnels. MOBIKE support should be similar to NAT-T support for
  IPSec protected IP-IP/L2TP tunnel.

  Mobility case: Do we update the tunnel endpoints and traffic
  selectors if mobility is needed?

  Tero: As a designed of NAT-T, whether works with transport mode is an accident.
  Mohan: The whole point of L2TP over IP was this.

  Jari: Seems like L2TP inside is just another protocol, issues with
  NAT-T and transport mode is going to be quite similar.

  Multi-homing support case: There are two possible models: Model 1 -
  Single IP-IP tunnel. Model 2 - Multiple IP-IP tunnel.  Routing
  protocols making their own decisions, MOBIKE doing its own thing.
  Potentially a bad interaction similar to SCTP?

  Pasi: Since IKEv2 doesn't create or manage IP-in-IP tunnels, MOBIKE
  shouldn't do that either.  If there is a need to create a tunnel,
  MOBIKE is not the way to do that.  Mohan: If I have a manually
  configured tunnel, IKE would still work for the outer addresses.
  Pasi: If my IP address changed, and I can fix using MOBIKE, doesn't
  mean the IP tunnel moves.

  Mohan: ...  Pasi: If MOBIKE change the address in transport mode,
  MOBIKE mods the traffic selectors, they no longer match the IP-in-IP
  packets.  We need to modify both the TS in the SA and the part that
  handles the tunnel.  For SCTP this could work in theory because it
  has a mechanism.  Mohan: But if you don't change it it will still
  work.  Pasi: The part that does IP-in-IP still uses the same
  address, doesn't match the TSs of the SA.  In transport mode you
  only have address in one place.

  Conclusion: IPSec acts like a  "shim" layer in the context of multi-homing.
  Cases:
  - SCTP: ?
  - MIPv6: Nothing special needed in MOBIKE itself
  - IP-IP tunnel + transport mode: RFC 3884 use case may be more common.
  Interaction with routing layer needs to be studied.
  - TCP + transport mode: Does not seem to be an interesting case?

  Jari: Is there anyone who would use any of these cases?  Maybe there's not a lot
  to be done? No one speaking.

  Maureen Stillman: problem is that there are not SCTP people here.  We need to
  get more information. Promises to ask.
  Jari: Right. Thank you.

End of the meeting
==================