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

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 11 Sep 2008 18:19:03 +0300

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?

> (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
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 12 Sep 2008 10:06:47 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Rémi Denis-Courmont
> Sent: Thursday, September 11, 2008 8:19 AM
> To: Eddie Kohler
> Cc: [email-masked]; Behave WG
> Subject: Re: [BEHAVE] [dccp] WGLC: draft-ietf-behave-dccp-01
> 
> 	Hello,
> 

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