Note taker: Martin Stiemerling (stiemerling@nw.neclab.eu) Transport Area Open Meeting IETF-76, Hiroshima, Japan FRIDAY, November 13, 2009 1300-1515 Afternoon Session I+II Chairs: Magnus Westerlund Lars Eggert Agenda Bashing Note Well State of the Area 15 minutes Generic UDP Encapsulation Pasi Sarolahti and Jukka Manner 15 minutes Alain Durand: some point cross nat box, you have to deal with that. look at teredo, which essential does this. in the end UDP encaps will be much more complex. Jukka: had long discussion with this. main issue keep alive. have implementation, works fine, but doesn't have keep alives. relaying on inner protocols. need to figure out whether inner protocol has stopped finished transmitting. Jana Iyengar: if we go down this track, we should consider what current transport protocol do. see sctp over udp. Tim Shepard: It an appealing ide. However, it is not that easy. Still need to check if native works or not. Seems to need protocol specific handlign of cases. Still need to invent mechanism and write a document. Thus, whats the gain. Second point, what if both end-points are behind NATs? Then you still need support of rendevous. Great, if there was a generic one. You would need a pretty compelling reason to drive the deployement of them. If we take all these mechanism needs this gets pretty complicated. Third point, actually we already have this. We have IPv6 and Teredo. If your protocol works over IPv6 then use Teredo even if only having IPv4 connectivity. That would make all the automatic. Alain Durand: Follow up on Tim's comment. Even if you don't like IPv 6 you need to reinvent 95% of Teredo for a generic UDP encapsulation. Even if you don't have any IPv6 related support. And Teredo is quite complex. Martin Stiemerling: have different tool sets, but why are people outside the ietf are still starting their own X-over-UDP protocols? Tim S.: HIP folks tried teredo and it just worked. The Cross-Layer Negotiation Problem Janardhan Iyengar 30 minutes (on slide "Concurrent Protocol Initialization") Flemming Andreasen: wondering how to get the negotiations working in the first place (e.g., one side tcp-only the other dccp-only) Janardhan: no need to add overhead for communication protocol. Flemming: previous was try and error, this is part of the message exchange. how is the neg exchange performed, if both sides use different protocols J: no using any of the protocols shown to do negotiation Hannes Tschofenig: agrees with problem statement. solution is difficult and not many protocols coming up every day. web community runs everything over http, not a huge variation. sip does it as well. some examples from openid. J: rare cases were standard solutions won't work. (missed). Hannes T.: alternative exchange mechanism. dime working group uses DNS to find services Paul Hoffmann: how I understand the presentation is going before going to communicate. if this is successful, do you except the underlying protocol to be less complex J: this is additional overhead. you can package the protocol possibilities. Hannes: how much do you actually optimise. let speak diameter authenticator server discovery. J: what you mentioned is explicit out of band negotiation. lot of problems with that approach Hannes: do not agree with that problems. DNS updates not a problem, as used by traditional servers, not end hosts. you trying to replace SIP answer/offer handshake. Magnus Westerlund: you're running away. SIP case is different, you wouldn't do Offer/answer exchange over this, rather if SIP/UDP or SIP/TCP or SIP/FOO to reach the sip server. J: when I want to sent IM. How do I figure out what protocol? XMPP or SIP? Hannes: should use grobj protocol. Their starting point was identifier offered. Were reasoning about this identifier means (IP, email, etc) Andrew McGregor: Lot of commonalities with GROBJ, also with HIP and SHIM6. Love that graph representation. J: Didn't include multi-path protocols, where issues becomes squared or cubed. (on slide "Negotiation Across Contexts") Bob: Relationships can represent quite a different things. Encapsulation in higher layer. Data plane/control plane confusion. J: What you ultimately want to build is a stack that provide encapsulation. What can be composed into a stack can also be used for encapsulating. (end of presentation) Magnus: How sensitive are these mechanism to security attacks? J: By exposing all this information your making it easier. Paul H.: yes it makes it fast. but multi-round trip protocol probing is already high (see in email). Start TLS are the bane in SMTP world and due to backwards compatibility you often get no security. Exposing that directly is a benefit. I haven't seen anything about caching in the presenation. It is a relevant question to look into. Because if you can cache you reduce the cost of extra round trip needed to prevent man in the middle to downgrade. J: The end goal is to have zero round trip negotiation where you can piggyback actual protocol negotiations. However, we clearly need to look at the security angle of the mechanism. Flemming: Why isn't this an app problem. Every single node/app needs DNS entry. But not all will have a DNS entry. Important to bound the problem. J: Want negotion the communication style. keep coming with new protocols, etc. there is stuff happening above http, we are not thinking about them right now. Negotiation is a cross layer process Flemming: negotiation between end points might not help, as there are middleboxes. J: overlapping with grobj objects. Flow Label as a Transport-Layer Nonce Steven Blake 10 minutes Mat Ford: What is the status of this doc? Steve: individual doc Mat: last time I have looked at IPv6 traffic there were quite many non-zero flow labels. What is setting those? Steve: Agree, also looking for traces different host OS (Windows, Linux, BSD) Mat: Comment on the NAT considerations. Do not start pros and cons of things we do not have. basic idea simple and some utility to me, so let's stay simple Mat: Comment from Joe about IPv6 NAT. comment a year ago. IPv6 NAT still not going Tim: If a tcp connection is open and is using this, machine goes down, comes up again, i.e., new tcp connection but other end is half-open. TCP syn as same IP+port but different flow label, might also get silently discarded. Steve: Not TCP expert, need to check this. Tim: somebody needs to send a reset. need to check where one end crashes Andrew: If you reboot, should see new initial flow label. should ignore if socket is half open. Magnus: This is an issue if you don't accept creating new flows. Magnus: commenting on multipath TCP. Skip mptcp for now, as now answer from mptcp soon Issues with IP Address Sharing draft-ford-shared-addressing-issues-01 Alain Durand 15 minutes Stuart Cheshire: (missed) was about attack Alain: Same IP, different port, no idea to know whether it is the same person session ended at 14:51.