IETF-72, Dublin, USA TSVWG *FINAL*AGENDA* Monday July 28th, 2008 1520-1720 WG Chairs: James Polk Magnus Westerlund Lars Eggert Chairs Agenda Bashing 1520-1535 (15 min) NOTE WELL Document Status and Accomplishments Milestones Review Mentioned the following IDs draft-ietf-tsvwg-admitted-realtime-dscp-04.txt [Fred] I have done most of Bob's nits, but have stopped short of his suggestions on redefining what CAC means, as a means of justification for this effort [Bob] I wrote that note intending on answering most of what I envision will be asked [Lars] so, you wrote this in support of this effort? [bob] yes, I want the DSCP [Lars] and you are only anticipating the coming questions? [Bob] yes [Lars] then why don't we publish the ID and see if the questions you raise get asked, and if they do, we'll have a hint to answer them already, but let's not let this hold up the effort [Bob] ok [Magnus] hum for WG support of this effort 100% Hum against 0% draft-ietf-tsvwg-port-randomization-01.txt draft-ietf-tsvwg-udp-guidelines-08.txt * Michael - Applicability of Keying Methods for RSVP Security draft-ietf-tsvwg-rsvp-security-groupkeying-01.txt 1545-1555 (10 min) - background, goals and history - Significant changes to “RSVP Encryption” section - New title: “Applicability of IPsec for RSVP” - Initial work on applicability to GMPLS RSVP-TE - Work in progress - Complete re-structuring of the document - Added a summary table (see later) - Lots of editorial changes - Complete IPsec section - Key point: IPsec SA vs. RSVP SA - More work on RSVP-TE section - Discuss further cases - Goal: Ready for WG last call before next IETF [Ran] "use ESP with AH, which is in running code since 1995, and this problem goes away" * Bruce - RSVP-over-L3VPNs 1535-1545 (10 min) draft-ietf-tsvwg-rsvp-l3vpn-00.txt - Path messages sent by data senders - Receivers send Resv messages - forwarded back up the path to senders - Neither Paths nor Resvs are processed in P routers - Changes from -davie-02 to WG-00 - Mostly cleanup - Further coverage of controlling redistribution of PE addresses (next slide) - Beefed up security section - Admission control on PE-CE links would be useful - Small set of new mechanisms makes RSVP work in VRF context and solves router alert issue - Put VPN-IPv4 addresses in Path and Resv messages to enable correct VRF to be identified - Address Path messages directly to egress PE or ASBR - Admission control over backbone is optional, leverages existing techniques (RFC 4804) - No change to RFC4364 (MPLS/BGP VPN) protocols or operations - Draft has been stable for 2 IETF meetings, now close to complete, IOHO [Lars] who has read the ID? -- 5 [Dimitri] are we going to narrow down the options? [Bruce] yes, and interoperability occurs because if someone implements more options than another SP, the two will interoperate * Michelle - IANA Allocation Guidelines for TCP and UDP Port Numbers draft-ietf-tsvwg-iana-ports-00 1555-1610 (15 min) TSVAREA WG has taken this I-D as a working group document draft-ietf-tsvwg-iana-ports-00 - Changes since draft-cotton-tsvwg-iana-ports - Clarity of language and more detail - Port range descriptions (system, user, dynamic) - Title change - Section for IANA procedures (incl. revoke, xfer, etc.) - Port use recommendations (hints at IANA process) - Added DCCP updates to the appendix - Open Issues - Should services sharing a port require the same protocol? - e.g., DNS on TCP/UDP vs. TCP data / UDP sync - i.e., is a service a single app protocol or set? - Service name requirements - Syntax, “owned” by DNSSRV, TCPMUX, etc. - Need for a common discovery protocol? - vs. allocating UDP for every service? - akin to Apple's Bonjour (maybe simplified?) - Next Steps - Feedback on current version - Resolution of open issues - Socialization with other IETF Areas - Begin development of companion document - History of ports - How, when, to use ports - Is an assigned port really needed? - Other options - Port Experts - Port process slow due to learning curve - We need more experts - Volunteer - IESG officially designates - Review 3-5 applications per month - On AVERAGE review time = 10 minutes [Michelle] gave overview of what they are implementing now, including soliciting for more port reviewers - Review and Re-formatting of the port numbers registry - Will be seeking input from the working group on new format - XML Conversion - Revised application form for port-numbers [Dave Taylor] issue with contact information, mostly because the contact no longer works for the company listed [James P] said this is a bigger issue that just for ports, this is an IANA problem of defining "registrant" [Joe] agreed [Michelle] agrees as well, and will attempt to address in a future rev * Randy - SACK-IMMEDIATELY extension for SCTP 1610-1615 (5 min) draft-tuexen-tsvwg-sctp-sack-immediately-00 the Problem - The SCTP receiver normally delays SACKs. - This might result in reduced performance due to – The sender has not enough queued user data to send the remaining DATA chunks due to the Nagle algorithm. – The sending of a DATA chunk fills the congestion or receiver window. – The sender is in the SHUTDOWN-PENDING state. – The sender has reduced its RTO.Min such that a retransmission Timeout will occur if the receiver would delay its SACK. - To overcome this limitation the sender has to indicate to the receiver that it needs a SACK immediately. [Randy] this is harmless, since if you don't understand this, you ignore it [lars] thinks it's neat, but how useful is it? [Micheal] it matters, and should have been there since the beginning - since this is an optimization of 200ms per association - and if you have lots of associations, it adds up quickly * Randy - DTLS for SCTP 1615-1620 (5 min) draft-tuexen-tsvwg-dtls-for-sctp-00.txt - Why not just use basic TLS over SCTP? - TLS requires a reliable and in-sequence transport service provided by the transport layer. - TLS needs a TLS connection per bi-directional stream and can not be used in combination with PR-SCTP. See RFC 3436. - Hard to implement in OpenSSL. - Why not just use basic DTLS over SCTP? - DTLS assumes an unreliable services provided by the transport layer. - Provides an unreliable service to the DTLS user. - It may drop user messages, so it can not be used in combination with SCTP trying to provide a reliable service. - Even without DTLS dropping messages an attacker could force message drops... SCTP aware DTLS - It provides to the DTLS user all services provide by SCTP. - It makes use of SCTP-AUTH. - The shared secrets used for SCTP-AUTH are derived from the DTLS layer using key extraction described in draft-rescorla-tls-extractor-01.txt. - Prototype implementation for OpenSSL (supporting the 1-to-1 style socket API) available [Magnus] this is important, and others are wanting this to be done. How many have read this? The authors. We need to take this to the list * Randy - SCTP Stream Reset 1620-1625 (5 min) draft-stewart-tsvwg-sctpstrrst-00.txt - What types of reconfiguration? - Ability to add a stream - Ability to reset a stream to its initial value (0). - Ability to reset all streams to initial value (0). - Ability to reset the TSN and all streams. - Note that NO ability is provided to remove a stream. - So why do we want to do this? - Often times an application may use the TSN numbers stream sequence number for explicit application level tracking. - Being able to "reset" these values provides a "stream reusability" so that an application can "reuse" a stream for a new purpose. Thus conserving streams. - Some applications also may wish to start off with a small number of streams and may wish the ability to "grow" the number of streams dynamically. Currently this is not supported in RFC4960. [Lars] what about congestion control? [Randy] there's nothing about congestion control here [Lars] seems like a neat thing, but, what's the measurable improvement * Randy - Sockets API Extensions for SCTP 1625-1635 (10 min) draft-ietf-tsvwg-sctpsocket-17.txt Current Status - It took some time to finalize the features related to SCTP-AUTH (RFC 4895) required for DTLS over SCTP. - It is now feature complete. - Supports – RFC 4960 (Base protocol) – RFC 3758 (Partial reliability extension) – RFC 4895 (Authentication extension) – RFC 5061 (Dynamic address extension) - Other protocol extensions must provide their own socket API section. Open Issues (1) - Message retrieval not clearly defined. - Type and size of context field possibly not appropriate. - Clear statements about flags of the sctp_recvmsg() function regarding in/out nature. - Refine text for receivers using recv() like functions. - Refine text for applicable flags used in the struct sctp_sndrcvinfo provided in the SCTP_DEFAULT_SEND_PARAM socket option. - Add text regarding SCTP_PORT_REUSE. - Sequence of Notifications not specified. Open Issues (2) - Clean up field names of all structures * Preethi - Non-Renegable Sacks for SCTP 1635-1645 (10 min) draft-natarajan-tsvwg-sctp-nrsack-01.txt Reneging and SCTP - Retransmission queue (RtxQ) – Portion of send buffer containing copies of transmitted data - Receiver cannot reneg on cum-acked / delivered data - sender discards cum-acked data from rtxq - Receiver may reneg on gap-acked data - due to buffer overbooking - sender does not discard gap-acked data Proposal: NR-SACKs for SCTP - Peers negotiate NR-SACK capability at INIT time - Replace SACKs with NR-SACKs during transfer - Sender is expected to perform congestion and flow control as it would with SACKs - NR-SACKs contain non-renegable gap-ack blocks; sender can use NR-SACK info to free buffer - Questions - Is this acceptable as a working group document (just say yes)? * Bob's - Layered Encapsulation of Congestion Notification 1645-1655 (10 min) draft-briscoe-tsvwg-ecn-tunnel-01.txt exec summary - bring ECN IP in IP tunnel ingress [RFC3168] into line with IPsec [RFC4301] - all tunnels can behave the same, revealing full congestion info - only wire protocol processing, not marking or response algorithms - thorough analysis of implications: security, control, & management - guidance on specifying ECN behavior for new links, alternate PHBs - ideally fix egress too (currently only 'for discussion') why update ECN RFC3168 now? - sequence of standards actions led to perverse position - despite everyone’s best intentions - 2001: RFC3168 tunnel ingress specified cautiously due to security concerns - 2005: RFC4301 IPsec decided caution wasn't necessary - IETF Security Area decided 2-bit ECN covert channel can be managed - vestige of security no longer used by IPsec now limits usefulness of non-IPsec tunnels - already PCN "excess rate marking" says "doesn't work with 3168 tunnels" - anyway, copying of whole ECN field is simpler - general agreement on list with 'copy on encap' - concern on list (a year ago) over a couple of details - exception for in-path load regulators (resolved by removing it) - conceptual model from RFC2983 avoids need for exception - Appx D: Non-dependence of tunnelling on in-path load regulation - reconstructing precise cross-tunnel congestion metric (resolved) - Appx B: suggested precise cross-tunnel measurement technique - since replaced with really simple technique [for -02 after IETF-72] - that was 1 year ago - agreed to go dormant until PCN wire protocol clearer... - would like to request as WG item - PCN w-g needs to know if proposal is likely to happen - also implications for PWE3 (if using ECN) - will need IPsec to be happy that they aren't affected - also to discuss (here or on list): - should we change the egress at the same time? [Lars] Who read this ID? [room] 2 or 3 hands [Lars] we cannot hum to make a decision about making this a WG item as there is not enough in the room that had read the draft to make an informed opinion. * Anantha's - Effects of port randomization with TCP TIME-WAIT state draft-ananth-tsvwg-timewait-00.txt 1655-1705 (10 min) Our Experience with the Issue - We have had Port Randomization in place in our TCP stack for quite sometime. - There were some issues observed on the field which involved a TCP application (VXML) which exhibited the property of open/close of TCP connections at a faster rate. - This is a general problem whenever a randomly generated ephemeral port is chosen that was used for a recently closed connection which is lingering in the TIME-WAIT state on the server side. - The issue is referenced in draft-ietf-tsvwg-port-randomization but solutions offered would still suffer from this issue. - The solution is to have the client side not to re-use the same source port for about 2MSL time. Following approaches are described in the draft: - Bit Array and timers - Bit Array and Passive Timer - 2-Bit Array and Timers Moving forward? - The motivation for writing this memo is to document the important side effect of "stateless port randomization". - The solutions which we have has been tested, working well in the Internet for about a few years. - If the WG decides to move forward, should this be a separate draft or the ideas proposed in this draft be merged with the port randomization draft?