TSVWG IETF-75 (Stockholm) Thursday, July 30th, 2009 WG Chairs: James Polk Gorry Fairhurst Notetakers: Matt Zekauskas, Gorry Fairhurst 1. Agenda Bashing (Chairs) NOTE WELL Document Status and Accomplishments Milestones Review James asked for the current status of the I-D on RSVP extensions for emergency services. Magnus Westerlund (as AD): The RSVP extensions for emergency services I-D has been returned to the WG with comments. It will need to go through another WGLC and then IETF last call before resubmission. James: Francois has been trying to clear the discusses. Magnus Westerlund: This document had an usual state where 2/3 of the IESG did not vote, requiring a resubmission. The proxy RSVP documents have been stuck in "discuss" within the IESG, there has been some some progress, and some discussion of end-to-end usage. The document on port randomisation is now reaching WGLC. This now needs volunteers to read on this and some people to be document reviewers. The following people volunteered: Michael Tuexen James Polk Ken Ken Carlberg Please return all reviews by 1st September. Gorry commented that TSV had not done well in maintaining milestones and as a new chair, this was something that he wanted to really wanted to push. He requested all document authors to submit sensible and realistic milestones to the chairs for all TSV working group items. Magnus: There is a design team working on the IANA procedures for the port and service name registry. There has been lots of discussion, and we have found a way forward at this meeting. Gorry: What milestone would you like? Magnus: We expect draft submission by the end of 2009. There has been progress on DTLS over SCTP, based on michaels review. Bob had received comments on packet v. byte ECN, and has promised an updated draft. James noted that peer-to-peer SIP needed NAT-traversal and was looking for a suitable transport. SCTP over NATs is a work item in Behave. The current draft requests normative changes to SCTP. Magnus: Can we split the draft into two parts, one a BCP in Behave, one a small PS update in the TSV WG? Michael: OK. The chairs asked people to read and comment on Michael's MulTFRC draft -00 (not presented in this WG, but it was presented in ICCRG). 2. IETF-75 SCTP review 2.1 SCTP (Michael Tuexen) draft-ietf-tsvwg-sctpsocket-19.txt The socket API document will be changed so that future protocol extensions can be added without breaking existing applications. The next version should be feature-complete, and then will need review. draft-ietf-tsvwg-sctp-strrst-00.txt Stream reset has been implemented in BSD 8. This requires a socket API definition. draft-ietf-tsvwg-dtls-for-sctp-01.txt DTLS for SCTP is complete. There is an OpenSSL implementation. Work is needed to review the security section (e.g. from Ekr). After this, it will likely be ready for WGLC. Gorry: We would like more reviewers please. This is really simple to read. James: The chairs will help work with Ekr on a review. How many people had read this version? Gorry: This also needs a SecDir review at some stage. draft-tuexen-tsvwg-sctp-sack-immediately-02.txt [individual submission] RFC 4960 does not specify the IANA registration procedures for updating the registry allocation procedures for a new flag as a new PS. We would like to see an Internet Draft that specifies what IANA should do. James: This seems good to me. Magnus: This seems good as a PS. Three new new drafts are being prepared for future work: Implementation Considerations (not standards track) and PR-SCTP policy description (Informational) and the PS relating to work in Behave. The policy work was motivated by work in the IPFIX WG using a policy, which is not one in PR-SCTP RFC. Offers of help contributions are welcome. 3. Applicability of Keying Methods for RSVP Security (Michael Behringer) draft-ietf-tsvwg-rsvp-security-groupkeying Progress was presented and there had now been four reviewers who had sent their reviews to the mailing list. An updated draft had been prepared. James: How many people had read this? <5 people have read this and sent reviews> Gorry: Who would like to see a WGLC started on this document? The WG will now take this to LC. People who have commented prior to WGLC please quickly re-read and confirm this is ready for publication. 4. RSVP Extensions for Admission Priority (Francois) draft-ietf-tsvwg-emergency-rsvp There had been significant IESD comments on an earlier version. The document is now positioned as an RSVP mechanism, and not specifically targeted at emergency scenarios. The scope had been restricted to intra-domain use, in response to security concerns on the use of Router Alert (now in a separate document). The authors would like this to start WGLC. Janet: I have read this and it does what Francois says it does. Ashok: I think emergency was a misnomer. The extensions are generic, the new document is much better the way it is. James: Do we need to ask IESG specifically before another last call? Magnus: The WGLC can be done, but we should ask for IESG feedback before re-issuing the publication request. Gorry: OK. We shall start a WGLC for this I-D. I will shepherd. 5. Integrated Services Extension to Allow Multiple TSPECs (James Polk) draft-polk-tsvwg-intserv-multiple-tspec [individual submission] This is allows multiple TSpec to be offered to the network and allow network to indicate to receiver which can be granted. This allows the Resv to select the best option of those offered in the TSpecs. Three options were presented for implementing this at the last San Francisco IETF. The draft now suggests one way forward (the third) as decided by the WG. Ken Carlburg: What about multicast where there are heterogenous paths? James: This is not in the current draft, I had not thought about this. Ashok: This is a bit of a thorny case - as is the multiple sender case. Multicast requires choosing one TSpec. It should work, but it needs some more work. James: Can you help find suitable text? Ashok: Yes, I will send text. Bob: There seems some similarity with Quick-Start. This could be of interest, since it seems complimentary and one possible way to ease deployment. Gorry: Interesting, I have not looked at this. I will read this with Quick-Start in mind. The appendix captures the discussion at the previous IETF. Francois: I think you can remove everything that is not about the solution from the text. The appendix then says only why this was chosen. James: I will do this. Gorry: I would go with that: Keep the document clean and focus on one solution. This discussion needs only to be in the appendix, we could remove some of the detail before publication, but let's not worry about this now. Gorry: Does anyone have a problem with this design choice? If anyone had concerns, please do say so to me or to the list, otherwise it will be this way. Open issues. Lars asked how many TSpecs were allowed in a request. This was suggested as a possible candidate for a beat-down attack. James noted that any number of TSpecs can only setup one reservation. Magnus: There could be a packet amplification attack. If you only have one that TSpec that works, could this result in many messages coming back? Francois: I commented on the list. I think this opens up the possibility of a forged message to do more harm. However, a compromised neighbor already presents many issues. Magnus: In normal cases you have policies. Here, you can get a packet (DoS) attack on the control plane. Francois: If you have no RSVP neighbor protection, you can do many things. This is not a big issue, and we can define some limit. Magnus: The original comment came from Lars, he may like to take this up. You need to understand all attack vectors and study this. Ashok: It is harder to mount an application attack that it seems. There are network topology dependencies that would result in this case. Toby Moncaster (via Jabber): The fact there are more serious attacks available does not provide a reason not to prevent this. Francois: This motivates neighbour authentication. James: We will revise the security considerations. Gorry: Any more questions? Is this good for a WG document? Francois: It seems like the correct direction for a WG document. There are places that need work. Gorry: How many people had read this? <2 people> Gorry: There is currently not enough support to make this a WG work item, we need to get more eyes to read this, and we can then consider this. Please read the latest draft and comment on the list. 6. Multiple Preemption Priority Policy Element for RSVP (Francois) draft-lefaucheur-tsvwg-rsvp-multiple-preemption [individual submission] This is a new document that adds the flexibility to signal a different preemption level with multiple requests. It allows a higher preemption possibility at the base rate, and a system to gradually push-back at increasing levels of congestion. It allows changes to be made to existing and new reservations. This is a companion document to multi-tspec multi-flowspec document to extend the notion of preemption. Taj: Does this allow the value to change dynamically including adjustments to the encoding in mid-session, versus at the start of a session? Francois: Both are supported. It is a fluid model, and maintains adjustment on old versus new. Taj: If one session changes the application encoding, how do you negotiate this with the calling side? Francois: We need to translate this to SDP. With RSVP, both endpoints will have knowledge, each end could adjust as needed. It is interesting to contemplate if this should be fed back as SDP. This is a good question. The authors will revise the document. 7. RSVP Extensions for Flexible Resource Sharing (Ashok Narayanan) draft-narayanan-tsvwg-rsvp-resource-sharing [individual submission] This is a small extension to share reservation resources between 2 reservations that go to same destination. Call waiting can for example lead to double-booking on the link close to one end, with only one used. A call could ring at two places, but only one will pick up. This is not just a VoIP issue. We want to define a separate Reservation Sharing ID (RSID), allowing sharing to different destinations. Adrian Farrel: Uniqueness is needed in the RSID. I think this object can not be transparent. We need a way to specify how this field is globally unique. This controls which researvations shared, not how to share; there are security concerns and we need to specify sufficient to make sure different implementations do the same thing. Ashok: Agree: There is a uniqueness requirement, we can discuss options on the list. This seems a valid point. Adrian: Could use the IP address of the destination? Ashok: Yes, you could, but there may be problems and there are other options. We thought that it would be better not to define this, but we can discuss more. Magnus: Where does the discussion of symmetric NAT fit? Ashok: If you consider a VoIP/IPTV flow to a home. A symmetric NAT is at home. We change source. The session objects are now the same so we have a problem with the external addresses of the NAT. Magnus: This is called source-dependent NAT in Behave, I do not know how this effects TE. Francois: RSVP-TE may have a similar problem. They used a different approach that allowed sharing. Ashok: In TE they split options 1 and 2. The sender address is added as a part of the extended tunnel identified. I want to solve a different problem. 8. RSVP Process Adrian: I have a general process question to the Chairs: RSVP and RSVP-TE use the same protocol number. Can you please tell the routing area that this is being done? James: Which part of the routing area? Adrian: MPLS and CCAMP in particular. Magnus: It may be good to do this before WGLC in some cases, before it becomes a working group item, and anyway in last call. Adrian: It is important to know when it becomes a WG draft. Adrian: I have another process comment. Drafts that use a BNF syntax should provide a reference. The appropriate reference should be RFC 5511. All RSVP documents that uses BNF should point to this. 9. Layered Encapsulation of Congestion Notification (Bob Briscoe) draft-ietf-tsvwg-ecn-tunnel There were 5 reviews to the previous revision. I have just spoken at security area to make them aware of potential updates to RFC 4301. The draft is now at -03, but has been significantly rewritten now. One important technical change (optional alarm) and non-standards stuff has been moved to the end or deleted. David Black: I am not sure it is a good idea to say SHOULD log on these parameters. There is now more than one way to do ECN (e.g. 2-level congestion ECN, and we now have more uses for these bits). I think there should be generic text that says depending on how you use the ECN bits some of these transitions may be expected - and it may be appropriate how to log the transitions or raise alarms, but which are unexpected depends on intended use. the aim is to avoid later people having to face unreasonable obsticles. Bob: If we know of generic uses, we should not be configuring tunnels against specific alarms. David: ... and what about the new generic use, which we have not thought of yet? Bob: I know. The three levels in ECN was predicted in RFC 3168. Philip: The approach is when the new use is thought of you have new method. David: The stakes have been raised here since we are talking about updating RFC 4301. This is not to be done lightly. I doubt if we get two attempts, or necessarily one. The issue is that if you wish to run two levels of signaling through ECN, we need to do something. RFC 4301 is a security area document and we decide on this first. Bob: I think it only is an alarm. David: I am not sure about the two drops on not-ECT. We would need to figure-out how to express the case for that change for RFC 430 and whether these are needed for RFC 4301. Bob: I would argue more strongly that I would like to see the same functional behaviour for tunnels in different environments. David: This a compound case. It results from two mistakes - a tunnel configuration error and downstream congestion. Assuming that breakage is reporting congestion is not always going to be the right assumption. Bob: Correct, the draft proposes the safest option. David: You need to make the case for fixing this in RFC 4301. Bob: There is at least one change needed. Bob and David agreed to resolve these issues and then make a combined proposal to the list. Hopefully aiming at WGLC in December 2009. Gorry: The new organisation is more clear. This looks good for more review, please read and comment. 10. The UDP Tunnel Transport mode (Gorry Fairhurst) draft-fairhurst-6man-tsvwg-udptt-01 [individual submission] Some people in other WGs would like to change UDP for IPv6 to allow datagrams without any checksum operation. Use has been proposed for AMT and more recently this mode has been suggested for use in LISP. This may have transport implications. There are three options: - keep current behaviour (require UDP checksum for IPv6, RFC 2460) - allow UDP zero checksum (no checksum for the endpoint) - allow a new UDP mode (fixed checksum for a flow), called UDPTT There are two drafts relating to the last two proposals. The second draft looks at how you could do a checksum calculation once per flow, rather than per packet for tunnel use. There is a another minor revision forthcoming in a few weeks. It is only 10 pages long, and comments are welcome on the proposal and importantly on whether any change is appropriate. The aim is to start a discussion on this in 6man. Fred templin: Do middleboxes upset when udp length field does not match the packet length? Gorry: Sometimes. Middleboxes also often do not support UDP-Lite, which could otherwise be a candidate. Standard RFC2460 operation may also be the best way to go. Ashok: It seems to be accepted practice to set the checksum to 0 for IPv4. Gorry: IPv4 use of UDP zero checksum is however deprecated for new applications, although it is seen in the network. This is not so for IPv6. Ashok: I have more questions, but will take these to the list. James: This is important to TSV, since we maintain UDP. I'm going to ask for a longer presentation in Hiroshima on this. The TSV working group closed.