Re: [BEHAVE] [dccp] WGLC: draft-ietf-behave-dccp-01

> -----Original Message-----
> From: behave-bounces@ietf.org 
> [mailto:behave-bounces@ietf.org] On Behalf Of Rémi Denis-Courmont
> Sent: Thursday, September 11, 2008 8:19 AM
> To: Eddie Kohler
> Cc: dccp@ietf.org; Behave WG
> Subject: Re: [BEHAVE] [dccp] 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@ietf.org
> https://www.ietf.org/mailman/listinfo/behave

_______________________________________________
Behave mailing list
Behave@ietf.org
https://www.ietf.org/mailman/listinfo/behave