MOBIKE WG meeting
Wednesday August 3, 2005, Paris
Notes taken by Lakshminath Dondeti and Maureen Stillman,
combined by Paul Hoffman
Introductory talk
Jari A: In May we resolved design issues. Pasi wrote a protocol
draft according to decisions made; it was reviewed and revised
version has been submitted.
Related documents are here FYI:
* devarapalli-mip4-mobike-connectivity -- MIPv4 approved WG (not
MOBIKE) item. Discussed in 3GPP, especially in relation to 3GPP-WLAN
interconnection May need liaison planning. Good to review in MOBIKE
also.
Paul H: we should coordinate with MIPv4 list. Pasi E: There is a
discussion underway in that group.
* dupont-mobike-transport Paul H: Please review, and we'll discuss
within a reasonable time
Paul H: It's fine to talk about non-WG documents as long as they
don't block WG doc progress. There are several other drafts like the
above two. Please see the agenda slides.
Pasi E on MOBIKE-Protocol-01:
(see the slides)
MOBIKE easy issues (Pasi Eronen):
21, 25, 29 are Editorial
26 Window size and latest update counter
Word "path" now used only in senses that include the route
23 : Separate payload types
30 : Protocol ID in notifications (to be in sync with the
ikev2-clarifications document)
24 NAT prevention needs clarification and a better name
Jari A.: Let's make some progress here by coming with some
decisions and we can get those confirmed on the list.
Francis D: dependency on 22
35, Version number (Skip the complexity now!)
37: Move MOBIKE supported notification from IKEv2_SA_INIT to AUTH
exchange
Allows per user policy about whether MOBIKE is allowed
Hannes: less fragmentation risk if added to AUTH
Jari A: Clarification req:
Tero: Can't fragment the first packet, because can't do
stateless IKEv2 exchange. Let's keep IKEv2_SA_INIT packet very
small and allow the stateless feature to be continued to be
supported. NAT-T may make the notification even larger.
Seems like there is consensus on this.
36: Unacceptable addresses.
Receiver might not know which address set was acceptable
Jari A: I had different thoughts on the list, but it is
clarified now and I am ok with this.
Pasi: This is a corner case anyway
27: Security and path testing
Sec considerations section needs text on path testing
Dependent on issue 34
Consensus calls: 35, 37 (Lakshminath: add comments from Tero as
text) and 36 mostly yes and no hands on oppose. All will be repeated
on the list.
22: close the issue, misunderstanding (Hannes)
MOBIKE issue 34 (Pasi Eronen):
(see the slides!) Discussion in the room:
Current protocol just does what IKEv2 NAT traversal does
This is another place where we upgrade a MAY to a MUST in IKE v2
Terminals that are totally idle sending keep alives consumes energy
Should we ask the BEHAVE WG anything? (Paul H says no, emphatically)
Only 2 people in the room have done an implementation with this
Suggestion: never time out; wait until you are under attack
When added to IKEv2, it was a corner case
if you care about it you implement the SHOULD
if you don't care then you don't implement the SHOULD
Path test is valuable independent of this issue. It is clear we need
this path testing feature regardless of this issue.
Relationship to Path test
with approach 1
there are more of these time periods ->
more need of separate exchange
if you want to do NAT detection in path testing ->
need separate exchange
with approach 3
fewer of these time periods
summary:
approach 1 and 3 both work
both have pros and cons
Tero agreed to write the summary to the list and send them
Want to see more discussion on the list;
security considerations for the path test exchange
Sense of how we support this corner case; do we want to drop it?
We know it will happen if the NAT rebooted or change mapping for
some reason
Ask on the list about implentations IKEv1 or IKEv2
Next steps (Jari A)
get rough consensus on technical issues
fix security considerations
clarify role of multihoming
3GPP2 has sent a liaison statement; we need to respond to it
Design document (Hannes)
mobike design 03
document update for this IETF
changed lots of text and organization
Difficult to follow the whole story; moved text to make it easier
to understand
missing pieces
selecting address (issue #20)
more details in the security consideration section
add design rationale for some issues that arise
readability - better structure for the doc -- new outline
Paul H: this tracks the IKEv2 clarifications document and can get
to the IESG after the protocol document (not by long)
People seem to like that
Way forward (Jari A and Paul H)
Close all open issues on the protocol document
We want to finish for real by September 15
Then have WG last call
At the same time as WG last call for the protocol finish the design
document
Read the docs now; don't wait.
|