[IPsec] Draft minutes from the 2009-05-05 interim meeting
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[IPsec] Draft minutes from the 2009-05-05 interim meeting
Please review the minutes and let us know if there are any omissions or inaccuracies. Please DO NOT use this thread to comment on the actual issues.
--Paul Hoffman
IPsecME WG interim meeting
2009-05-05
Agenda was bashed
Roadmap hasn't been updated recently, but is expected to be soon, then maybe WG LC
IPv6 considerations: waiting for a rev from Pasi, then Paul will take it to IPv6 folks
(Content from slides not reflected here.)
Traffic Visibility
Gabriel Montenegro
#104: Paul asked if this is additional integrity check
A: no
#93: Gabriel asked if people feel strongly about the next header field
No one said they felt so
Dan McDonald: I would prefer tunnel mode packets to have IPv[46], just like regular ESP. Less separate codepaths.
Yaron: Let's close #84 first
Form of next header will be based on #93
Heuristics
Dan McDonald
Yaron asked everyone to read this sometime soon
Does anyone care about SCTP?
Hannes: depends on the WG
NSMurthy: are these two documents alternate proposals?
This is about supporting legacy operating system platforms
Paul said that the pseudocode was quite readable
Tero: For SCTP, this is just one of the ways to do the checks
Others can check deeper if they want
Yaron: Should we have something in the pseudocode about amount of confidence you have gained?
Tero: We have that, but there is no limit set
Session Resumption
Yaron Sheffer
Major change: went to two round trips
Slide 5: only blue is really needed in the ticket
Red is "interesting" that is optional
Certificates are optional depending on whether or not you want it in the state
If the initiator wants to to change internal IP address, need to renegotiate
Pasi: Blue things are kept as state and might be regenerated
Black items are negotiated freshly
Maybe need a new issue on change of ports
Paul asked there was any opinions on two round trips
Hannes likes it
Michael believes 2RTT is necessary
Yaron asked for mobile folks to speak about necessity of 1RTT
No response
Gabriel: Question on the address assignment. The example refers to IKE address assignment, but would there be any issues with "regular" address assignemnt (DHCP, RA-based)?
Yoav: the "regular" address assignment affects the IP address of the client as seen by the gateway (or not - it may be behind NAT), and the change of external IP is allowed by the draft
Dan: Good point Yoav. If client's address (behind a NAT or not) changes, the non-IKE address assignment protocol will have to deal.
Jean-Michel Combes: slide 7, it is said SG should store IDr in ticket but in slide 5, IDr is "black" ... is it normal?
(Missed Yaron's response)
Gabriel: Pasi had a draft on bypassing PK operations in certain EAP-based auth exchanges, what is the implication with resumption (assuming such an approach were resurrected)?
Redirect
Vijay Devarapalli
Changes after the 2nd WG Last Call
Draft is ready to go
Still one open issue
Pasi agrees that we can drop #3
Tero points out that the server doesn't need to allow client to do another auth
Will fix text to match wording in 4739 about "last" IKE_AUTH
Will submit last draft today
Paul explained the next steps
IKEv2bis
Paul Hoffman
Issue #9:
Tero: it's really about the IKE SA failing. Should recommend what the initiator should do.
Paul: we don't want to mandate that, there are cases when you don't want to retry.
Paul: please write the rationale, rather than the "what to do".
Issue #12:
Pasi: If it's a new MUST, I want to know that it's really essential.
Issue #26:
Tero: we have covered some of these.
No further discussion.
Issue #57:
Paul will retry to paste the text into 3.3.2 or 3.3.3.
Issue #58:
Tero and Paul: yes, add to doc.
Adjourned after about 90 minutes
Attendees:
Dan McDonald
Dave Wierbowski
Gabriel Montenegro
Jean-Michel Combes
Jouni Korhonen
Key Grewal
Manv Bhatia
Michael Richardson
NS Srinivasa Murthy
Pasi Erornen
Paul Hoffman
Qiu Ying
Richard Graveman
Sheila Frankel
Tero Kivenen
Thomas Narten
Vijay Devarapalli
Yaron Sheffer
Yoav Nir
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.