1 / 18

MOBIKE Protocol Development Status Overview

This document provides an overview of the development status of the IKEv2 Mobility and Multihoming Protocol (MOBIKE) as of November 9th, 2005. It discusses issues handled, closed, and ongoing, as well as implementation considerations and open issues for future development.

landgraf
Télécharger la présentation

MOBIKE Protocol Development Status Overview

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IKEv2 Mobility and Multihoming Protocol (MOBIKE) Pasi EronenIETF64 MOBIKE WGNovember 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 ofthese 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  (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  (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

More Related