> -----Original Message----- > From: behave-bounces@xxxxxxxx > [mailto:behave-bounces@xxxxxxxx] On Behalf Of Rémi Denis-Courmont > Sent: Thursday, September 11, 2008 8:19 AM > To: Eddie Kohler > Cc: dccp@xxxxxxxx; Behave WG > Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-dccp-01 > > Hello, > > Le vendredi 8 août 2008 10:17:45 Eddie Kohler, vous avez écrit : > > (1) REQ-6: If a NAT includes ALGs, it MUST NOT affect DCCP. > > > > (2) REQ-13: If a NAT translates a DCCP packet, it MUST NOT > modify its > > DCCP service code value. > > > > In both cases a related, less stringent requirement would be more > > reasonable IMHO. > > Both were discussed on several occasions in the meetings. I > heard some voices > in favor of the strict statements, and none against it. As far as I > understand, BEHAVE-TCP did not forbidding ALGs because of existing > deployments; not an issue with DCCP (is it?). > > I am rather reluctant to changing this. What do the WG > (chairs) have to say? Eddie, If there is a DCCP application that needs an ALG, and which cannot utilize the STUN/ICE procedures as outlined by draft-rosenberg-mmusic-ice-nonsip-01.txt, we would like to hear about it. We already know what harm ALGs bring -- they slow or prevent protocol extensions, ALGs cause additional breakage in the end-to-end model, they require protocols to allow a man-in-the-middle (reducing security because the signaling has to be sent without integrity protection), and force the network topology to be constrained so that the signaling channel and the data channel traverse the same NAT. The reason for the 'MUST NOT do ALG' is because we want to avoid burdening DCCP protocols with these characteristics. The IETF learned the mistake of non-Passive FTP (which requires an FTP ALG) and there have been significant efforts underway to make SIP not need an ALG (draft-ietf-mmusic-ice) and to make RTSP not need an ALG (draft-ietf-mmusic-rtsp-nat). -d > > (2) REQ-13: This one is less important. The RFC4340 text says: > > > > The Service Code field in DCCP-Request packets provides > information > > that may be useful for stateful middleboxes. With > Service Code, a > > middlebox can tell what protocol a connection will use without > > relying on port numbers. Middleboxes can disallow > connections that > > attempt to access unexpected services by sending a > DCCP-Reset with > > Reset Code 8, "Bad Service Code". Middleboxes should > not modify the > > Service Code unless they are really changing the > service a connection > > is accessing. > > > > One can imagine useful ALG middleboxes that would change a > connection's > > service, and therefore its Service Code, and I don't see > what's gained by a > > "MUST NOT" requirement. This is speculative however. > > The document is dealing with address translators *only*. I > see no valid reason > for a NAT to change the service code. This text was > purposedly put there so > implementors would not alter the service code as if it were > extra source port > number entropy - that would break, for instance RTP over DCCP. > > -- > Rémi Denis-Courmont > http://git.remlab.net/cgi-bin/gitweb.cgi?p=vlc-courmisch.git;a=summary > _______________________________________________ > Behave mailing list > Behave@xxxxxxxx > https://www.ietf.org/mailman/listinfo/behave
