IETF-70, Vancouver, BC TSVWG *DRAFT*MINUTES* Thursday Nov 6th, 2007 0900-1130 Salon F WG Chairs: James Polk Magnus Westerlund Lars Eggert Chairs Agenda Bashing (15 min) NOTE WELL Document Status and Accomplishments Milestones Review Documents to have only Chair Comments on draft-larsen-tsvwg-port-randomization-02.txt draft-ietf-tsvwg-rsvp-proxy-approaches-02.txt draft-ietf-tsvwg-rsvp-proxy-proto-02.txt Lars Authors have finished a revision of the doc Main changes: - Included other possible randomization algorithms (as suggested by Mark Allman and Lars Eggert) - A number of changes were applied to make the document more transport-protocol-independent - Specific text was added on SCTP, RTP, and other transport protocols - Miscellaneous edits - Reviewers wanted. Any volunteers? * Francois - RSVP Extensions for Emergency Services (5 min) draft-ietf-tsvwg-emergency-rsvp-04.txt - Three different document - dime-qos-parameters - nsis-qspec, - tsvwg-emergency-rsvp - need to convey an overlapping set of QoS parameters - RPH-Priority - Admission Priority - currently do that in an inconsistent manner tsvwg-emergency-rsvp includes IANA request to provide numerical registry for RPH priority - via extending existing RPH registry - nsis-qspec, dime-qos-parameters and tsvwg-emergency-rsvp all point to this registry - nsis-qspec, dime-qos-parameters and tsvwg-emergency-rsvp will all: - only indicate that "higher value means higher priority" - no attempt to define what specific values should be used for what. - add a statement clarifying that a given Admission Priority is to be encoded with the same value in each of the three protocol spec - Proposal agreed by co-authors of three I-Ds and co-chairs of three WGs - Proposal posted on 3 WG lists for comments - draft-tsvwg-emergency-rsvp-04.txt already in line with the proposal *Lars - we're going to have a 1 week WGLC to get comments and move forward * Fred - DSCPs for Capacity-Admitted Traffic (10 min) draft-ietf-tsvwg-admitted-realtime-dscp-02.txt - went over doc history - ADMITTED-VOICE - uses EF PHB + capacity admission - Video classes with admission added: - Interactive real-time (conferencing and gaming) - Broadcast video - Multimedia conferencing (video conferencing). - Added text clarifying: - One expects this to be primarily useful on access links, as congestion is not a major issue on distribution or core links - Dave McDyson is sending text, and then Fred thinks this *Magnus asks who has read this version - only a few hands *Magnus also asked for people to review this soon *Bob and Lars exchanged about bringing this doc in line with PCN efforts, Lars thinks this will not be a problem. *Bob wants WGLC delayed about for PCN efforts to go through at the same time * Randy - SCTP Socket API (10 min) draft-ietf-tsvwg-sctpsocket-15.txt Supported RFCs - Basic SCTP: RFC 4960. - PR-SCTP extension: RFC 3758. - SCTP-AUTH extension: RFC 4895. - ADD-IP extension: RFC 5061. Deployment - FreeBSD 7.0 - Linux 2.6 kernel - Solaris 10 - HP-UX - AIX - Mac OS X (NKE, based on FreeBSD code) - socketapilib for sctplib "appears nearly every one but Microsoft" Status - Set of functions is very stable. - Support of generic functions widely available. - Some SCTP specific functions are not yet always implemented. - Not all socket options are available on all platforms. - Last change of a function signature is a year old… SCTP on FreeBSD - Implements all functions. - Supports almost all structures in the current form. - Experience with applications stressing the API: - MPI implementations. - RSerPool implementation. - Sigtran implementation. Upcoming Changes - Based on the results of a discussion at the last SCTP Interop with participation of FreeBSD, Linux and Solaris implementers. - Clarifications to some sections, removal of unused stuff. - Changing to some C structures. - need to have another rev, and then believe this doc is done * Randy - Non-Renegable Sacks for SCTP (10 min) draft-natarajan-tsvwg-sctp-nrsack-00.txt - SCTP SACK chunk carries cum ack, gap acks - Receiver may reneg on gap-acked data - due to buffer overbooking - sender does not discard gap-acked data - Receiver cannot reneg on delivered / cum-acked data - sender can discard cum-acked data - Proposal: - Negotiate NR-SACK capability at INIT time - Replace SACKs with NR-SACKs - Sender can use NR-SACK info to free buffer - (see draft for more on structure and use cases) *Lars asked how large a problem is this, is there a gain in implementing this? *Jan - we are working on quantifying this now *Dave Boreman - asked about lost packet *Jan - blocks should catch this *Dave - asked about losing the middle, what would be the consequences - does everything get reported *Jan - yes, unless a subset can do this *Randy - only report pieces that are lost - Is this draft ready to be a WG item? -Lars - this is clever, but more needs to be done before this can become a WG item; just do more and come back * Bob's - Byte and Packet Congestion Notification (10 min) draft-briscoe-tsvwg-byte-pkt-mark-01.txt - Summary - in any AQM propose SHOULD NOT give smaller packets preferential treatment - adjust for byte-size when transport reads NOT when network writes - favouring small packets, main change: - DoS vulnerability - small packet attacks push out larger packets - leaving most small packets to attack the next queue - & the next, & the next - DoS vulnerability similar to that of drop tail queues - AQM was partly about not locking-out large packets* - shouldn't add lock-out back again in the AQM algorithm - other changes - emphasized equal applicability to any AQM and to drop or ECN - e.g. PCN, RED (with drop or ECN) - restructured - pulled main recommendations together into the conclusions - moved a couple of lumps of text to appendices - fixed for (Floyd's) original motivations for Red's byte-mode drop protecting SYNs & pure ACKs more than equalizing small segment TCPs - added more examples of preferable transport approaches - tcpm-ecnsyn & tcpm-ackcc added to TFRC-SP etc - updated survey data (but no change since IETF-69 slides) - clarification & update throughout full diff at - long off-list discussions haven't resolved differences, but could - main points in favor of size-dependent drop: - control packets tend to be small (e.g. SYNs, pure ACKs) - so less drop of small packets gives performance win - already have mix of size-dependent (drop-tail) and size-independent drop - so doesn't reduce complexity by only having size-independent - apps have other (OS) incentives not to use small packets - main points in favour of size-independent drop - not all small pkts are control, so favouring all smallness creates unintended consequences - the more size-independent AQM, the less transport uncertainty over queue behaviours - mustn't provide incentives for new transports to use small data pkts - possible ways forward - focus only on PCN? - but still mileage in reaching consensus on RED too - unequivocal UPDATE to RFC2309 ('RED manifesto') - adjust for byte-size when transport reads NOT when network writes - previously gave both options with 'more research needed' - all known implementations don't do byte-mode drop anyway - retrospective tidy-up to RFC series - not reached consensus - wants to become a WG item *Sally - likes byte-mode better than packet-mode; talked about affects with drop-tail router (buffers) *Joe Touch - makes a point about whether the queues are based on bytes or slots *Bob - that's a research problem *Bruce Davie (author of 2309, which is Informational) - can't see there being consensus here, but documenting this discussion is useful * Bruce's - RSVP-over-L3VPNs (10 min) draft-davie-tsvwg-rsvp-l3vpn-01.txt - Admission control may be desired on CE<->PE links of layer 3 VPNs (RFC4364) - Running RSVP across these links presents several issues: - Need to associate RSVP messages (which contain C addresses) with appropriate VRF context when they arrive at PE across backbone customer address spaces may overlap - Need to intercept Path messages at egress PE but Router Alert IP option may not be visible/accessible - NB: Focus on admission control, not TE - May also wish to perform admission control for e2e flows in backbone - Clearly need some sort of aggregation for scalability and to avoid installation of per-customer state in P routers - Similar to other RSVP aggregation scenarios (e.g. RFC 3175, RFC 4804) - Need to support Inter-AS operation - 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 - New objects in Path, Resv etc. to identify appropriate VRF context during RSVP processing - Appear only in PE-PE messages, not outside provider's backbone - Control-plane approach to direct Path messages to egress PE for processing, avoiding need for Router Alert handling in data plane - RSVP over TE tunnels as per RFC 4804 if admission control over provider backbone required - Option A - just works - ASBRs operate like PEs - Option C - just works - Need an inter-AS tunnel if CAC required in core - Option B - In current draft, requires ASBRs to process Path, Resv messages and store state to enable reverse forwarding of Resvs - We have a plan to fix this issue in next rev - Filled out details of other message processing -ResvConf, ResvErr, ResvTear, PathErr, PathTear - Clarified that even when no CAC is performed, customer RSVP messages SHOULD be forwarded over backbone like other datagrams - Appendix A describes "roads not taken" - The VRF_ID described in current draft led to state storage in ASBRs even if CAC not needed - Solution: instead of VRF_ID, use a new VPNv4 PHOP type so that Resv can be forwarded directly from egress PE to ingress PE - Yakov Rekhter has suggested use of VPNv4 session type rather than VPN_Label object - Since labels and VPNv4 addresses map 1:1, seems like a small change - some seem to like this, while others do not - this still isn't settled, and needs addressing - Kumaki et al requested support for RSVP-TE from CEs - We think this is feasible, not yet done in draft - Summary - 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 enough VPN information 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 - Next rev should be near completion, IOHO *Lars - since this changes RSVP, and not L2VPN, he thinks TSVWG is the natural home for this work. He thinks this WGLC should be here, while letting the L3VPN WG gets notification for this *Magnus - hopes some L3VPN people will comment here *Lou Berger - asks if this is a problem to be solved? Lou thinks so. Lou thinks there should be a discussion about whether or not RSVP is the best way to do this (admitting there are no other drafts proposing solutions). *Lars - wants to ensure L3VPN WG will go with one solution, and if it's this one, this should live here in TSVWG. He doesn't want TSVWG to do this and L3VPN to suddenly change and come up with another solution. That would be a waste of cycles. * wants to know if this is RSVP or RSVP-TE (which would have other ramifications)? *Ferit Yegenoglu this ID solves a problem he wants to solve right now. Does the VPN session type limited to IPv4? *Bruce - no there is no limitation * Francois - A framework for RSVP Security using dynamic group-keying (15 min) draft-behringer-tsvwg-rsvp-security-groupkeying-01.txt [Michael had a baby last Sunday, so Francois stepped in] Where are we coming from? - Writing "Security Considerations" section for each new "RSVP extension for Foo" I-D (painfully) showed that: - Applicability of keying mechanisms for RSVP is not sufficiently documented - Existing key methods have limitations - New key methods (specifically "Dynamic Group Keying") could help alleviate/remove some limitations - Document Key Types as well as Key Provisioning Methods that may be used for RSVP Security - Discuss applicability of those to various deployment environments - In doing so, explicitly cover the more "interesting" cases: - Single-domain & Multi-domain - Non-RSVP hops - Notify messages (non hop-by-hop) - Subverted node - RSVP Authentication & RSVP Encryption - RSVP Aggregation (over Aggregate RSVP, over RSVP-TE, over PCN clouds,..) - Intended Status: Informational *Brian Wies (MSEC WG chair) - confirmed that this doc will determine if TSVWG thinks this ID is a good idea, then MSEC will consider draft-weis-gdoi-for-rsvp for advancement Changes from 00 to 01 - Refocused Scope to complement RFC4230(*) and avoid overlap - From "RSVP Security Framework" to "Applicability of Keying Methods" - Added discussion on relationship with RFC4230 - Added section on applicability to other RSVP Deployment Models: - RSVP Aggregation over Aggregate RSVP [RFC3175] [RFC4860] - RSVP Aggregation over RSVP-TE [RFC4804] - RSVP over PCN cloud - Started discussing applicability to RSVP Encryption - Added section on applicability to Notify - Added section on end-host considerations - Added text in Trust Model section to answer the "trust to do what?" question raised by Bob Briscoe on list Next Steps - Add discussion on issues & applicability to RSVP-TE & MPLS FRR environments - referencable by draft-fang-mpls-and-gmpls-security-framework - Expand discussion on RSVP Encryption Questions - What are the areas that need be added, expanded,…? - soliciting review and further input *Andrew - interested in RSVP authentication and RSVP over IPsec, and thinks this work should progress * commented they are very interested in this from their client's point of view, so the work should progress *Lars - thinks this can be argued to be within TSVWG's charter, and also thinks it's a good idea to have an Info doc discussing the various RSVP security options *Francois - this ID doesn't give recommendations as to what's the best way to do RSVP security, it informs various options. *Lars is fine with this *Francois - got confirmation from the chairs they will ping the mailing list for consensus to make this a WG item. * Lars - UDP Guidelines (15 min) draft-ietf-tsvwg-udp-guidelines-04.txt - discussed history - Quick Rundown of Changes - 3.1 Congestion Control Guidelines - new section 3.1.3 on UDP as a tunneling protocol needs review! - clarifications and editorial fixes to other sections - 3.2 Message Size Guidelines - clarify IPv4 vs. IPv6 and payload size calculation *Philip - what do you do if you have a call and you want it to run through a NAT (specifically payload fragments)? what do you do if that protocol is sending large packets? *Lars - options are rely in IP fragmentation or deal with it at the application *Philip - what if the application doesn't want to do this? *Lars - the application needs to change *Philip - should each protocol do this change different ways? *Lars - the application needs to do a MTU discovery mechanism *Philip - thinks there may be a need for a more general study of this in the IETF *Cullen - wants a new transport protocol that runs above UDP *Lars - this has nothing to do with this ID *Cullen agrees, and thinks this doc is great - 3.3 Reliability Guidelines - delay spikes and their impact on duplication detection - 3.4 Checksum Guidelines - clarifications on the purpose of the checksum *Magnus - need more text about tunneling, and when it is ok to set the checksum to zero *Gory - that discussion will be different for v4 and v6... - 3.5 Middlebox Traversal Guidelines - align keep-alive interval with ICE - clarify that keep-alives are only recommended for applications where loss of middlebox state interferes with primary purpose - 3.6 Programming Guidelines - new section - summarizes key differences between TCP and UDP sockets API - not intended to be a complete reference - section is getting long-ish; should not at much additional text - 3.7 ICMP Guidelines - new section - notes that applications can utilize ICMP messages delivered for their communication sessions - if they do, SHOULD be robust to transient reachability failures Status - need to incorporate some further off-list feedback on -04 - security considerations need to make some stronger recommendation on what solutions are preferred - clarify wording on why the MSL is appropriate to use as assumption for max. UDP packet lifetimes - should result in -05, probably after the holidays - what then? - (thanks all the reviewers) *Lars concluded we need beer to discuss the fragmentation issue We finished 20 minutes early ...wow