1. IKEv2 Mobility and Multihoming Protocol (MOBIKE)
Pasi Eronen IETF64 MOBIKE WG November 9th, 2005

2. Document status overview
WGLC on ended on October 19th
Several reviews from outside WG, ~16 people commenting during last couple of months
Filed as 29 issues in tracker
Most issues were clarifications that did not change the protocol
Version 05 submitted on October 24th
Version 06.a snapshot on Monday

3. Mailing list in October
Hmm, I wonder when the draft cutoff date was?

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

5. Issues handled in –05 (cont.)
44 NAT mapping changes and rekeying
Rekeying the IKE_SA can lead the initiator to believe NAT mappings have changed
Noted in document
55 MOBIKE scope and limitations
Rewrote sections 1.2 (Scope and Limitations) and 3.1 (Initial IKE Exchange)
61 Version number, again
Now says MOBIKE_SUPPORTED data field is set empty when sending, but ignored when receiving

6. Issues closed without changes
57 Question about “initiator decides”
Basically, why we chose this approach instead of other alternatives
New version of design document hopefully clarifies reasoning
63 Extensibility and payload
Comment about what extensions we might want to do in the future

7. Issues handled in –06.a Clarifications & other editorial issues
45 Clarifications to security considerations
46 Questions about additional addresses
58 Deleting addresses
72 More editorial comments from Tero
59 Editorial comments from Tero
54 Editorial comments from Marcelo
64 Editorial comments and questions from Stephane
Some clarifications in –06.a, but need to check everything was done

8. Issues handled in –06.a (cont.)
56 Ingress filtering compatibility
Explicitly say that MOBIKE sends reply to same address/port the request came from
68 Conformance requirements
Clarified in –06.a, but discussion continued; I think this is now OK

9. 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)
51 SPI Collisions
For these reasons, (remote IP, remote SPI) is not a good identifier for outbound IPsec SAs
70 Non-SAD updates
For these reasons, IP address is not a good identifier for the “right peer” in SPD/PAD/etc.

10. Implementation considerations
RFC 2401 (and implementations reading it too literally) had problems in this area
MOBIKE could make them 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

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

12. 52 Security of address updates
Questions/comments about the security considerations text
Written before NO_NATS_ALLOWED was made mandatory (unless doing NAT-T)
Suggested heuristics to guess NAT status from address (e.g. “if RFC1918 address, assume NAT”)
My proposal:
Do not add address-based heuristics — better to detect NATs using NAT_DETECTION_*_IP
It seems no changes needeed

13. 60 Addresses in IKE_SA_INIT/AUTH
Current text:
When IKE_SA is established, responder takes addresses from IKE_SA_INIT exchange, except when doing NAT-T
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: NO_NATS_ALLOWED is moved to IKE_AUTH as well, so it’s encrypted

14. 71 Failing RR
Problem
Initiator requests moving traffic to new address (sends UPDATE_SA_ADDRESSES etc.)…
Responder starts RR…
…but the new path has already failed, so the 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)
Responder changes back to the previous address (doesn’t work in all situations)

15. 71 Failing RR (cont.)
Tero’s proposal: Clarify the text about triggering dead peer detection
Even if we have incoming packets, DPD can still happen if they don’t have the addresses we’re expecting

16. Next steps
Close remaining issues
Send to AD evaluation in 1–2 weeks

17. Backup slides

18. 71 (I2,R1) UPDATE_SA_ADDRESSES   (R1,I2) Ack (I2,R1) ESP traffic 
Sees traffic on (I1, R1) but not
on (I2, R1).
(I2,R1)  (lost)
(I1,R1) DPD falls back to (I1, R1) ->
(I1,R1) UPDATE_SA_ADDRESSES 
(I1,R1) Send ESP traffic 
(I1,R1) Sends RR ACK 
 (R1,I2) Ack
(path breaks)
(lost)  (R1,I2) Start RR
 (R1,I1) keeps sending ESP
(lost)  (R1,I2) Still trying RR
 (R1,I1) Replies to DPD
<- (R1,I1) Sends ACK
 (R1,I1) Still trying RR now new address
 (R1,I1) Starts new RR
 (R1,I1) ESP traffic