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

From: "Dan Wing" <[email-masked]>
Date: Thu, 7 Aug 2008 18:24:22 -0700

Behave is commencing a 2-week WGLC for "Network Address Translation (NAT)
Behavioral Requirements for DCCP",
<http://tools.ietf.org/html/draft-ietf-behave-dccp-01>.  The WGLC will end on
August 21.

Please send comments to the author and to Behave.

-d

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Eddie Kohler <[email-masked]>
Date: Fri, 08 Aug 2008 00:17:45 -0700

Dear BEHAVE/Remi,

Thanks for producing this document!  There are two requirements that are more 
strict than I would expect.

(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.

(1) REQ-6b: NATs that include ALGs MUST NOT insert data packets into or remove 
data packets from DCCP streams.

RATIONALE:  "Therefore, modifying the payload of DCCP packets presents a 
significant additionnal challenge in maintaining sane DCCP sequence numbers, 
if the size of the payload were altered."  =>  DCCP sequence numbers are 
per-packet, not per-byte, so changing the size of a payload requires NO 
sequence number changes whatsoever.  Inserting or removing data packets DOES 
require sequence number changes, and should be avoided.

"Moreover, DCCP provides natural packet boundaries, whereby TCP provides a 
byte stream.  As such, changing the size of a DCCP packet may cause additional 
problems at the application layer."  =>  This is a little contradictory, since 
ALGs by definition "understand" the application layer and can prevent problems 
there.

RFC4340's Middlebox Considerations section says:

    Modifying DCCP Sequence Numbers and Acknowledgement Numbers is more
    tedious and dangerous than modifying TCP sequence numbers.  ...
    We therefore recommend that middleboxes not
    modify packet streams by adding or removing packets.

    Note that there is less need to modify DCCP's per-packet sequence
    numbers than to modify TCP's per-byte sequence numbers; for example,
    a middlebox can change the contents of a packet without changing its
    sequence number.  (In TCP, sequence number modification is required
    to support protocols like FTP that carry variable-length addresses in
    the data stream.  If such an application were deployed over DCCP,
    middleboxes would simply grow or shrink the relevant packets as
    necessary without changing their sequence numbers.  This might
    involve fragmenting the packet.)

It would be nice for BEHAVE to not needlessly contradict this.

(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.

Eddie

---

From: "Phelan, Tom" <[email-masked]>
Date: Fri, 8 Aug 2008 10:28:06 -0400

Hi Remi,

Here are some comments.

Tom P.

Section 4.3:

"o  The filtering behavior for DCCP MAY be independent of the filtering
behavior for UDP."

Shouldn't that be "for UDP or any other protocol" or something similar.
Certainly it's acceptable for the DCCP filtering behavior to be
independent of TCP...

"REQ-4: A NAT MUST NOT respond to an unsolicited inbound DCCP-Listen
packet for at least 6 seconds after the packet is received."

What does "not respond" mean?  Not send the ICMP message? Not forward
the DCCP-Listen packet?  Both?  Maybe this could be clearer if it's
reworded in a positive vein -- "Upon receiving a DCCP-Listen packet a
NAT MUST..."

Section 5, REQ-5:

Is this saying that the "established connection idle timeout" cannot be
configured to be less than 2 hours 40 minutes?  I see this language is
stolen directly from behave-tcp, but I find it confusing.

Section 6:

The first paragraph seems inaccurate to me.  It's actually much easier
to modify the payload in DCCP than it is in TCP.  As long as the
modified packet remains within the PMTU, you don't have to do anything
to the DCCP header except adjust the checksum -- you certainly don't
need to modify the sequence numbers.  You would only need to modify the
sequence numbers if you added a packet.  Of course changing the packet
size *might* foul up the application, but the purpose of an ALG is to be
application-aware, and so it would be highly unlikely to do something
that would foul up the application.

I agree with the intent here -- no ALGS -- but I don't think your
argument justifies it.  Maybe something more along the line of no DCCP
applications currently need ALGs, so let's keep it that way.

Section 10:

Somehow I think an empty security considerations section isn't going to
fly :-).  I suppose you could start by referencing the behave-tcp
security issues and describe what's different here.

General:

Your use of RFC 4787 terms isn't identical to RFC 4787.  For example,
you use "endpoint independent mapping" and RFC 4787 uses
"endpoint-independent mapping" -- it makes it difficult to look up the
meaning of the terms.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Dan Wing
> Sent: Thursday, August 07, 2008 9:24 PM
> To: Behave WG
> Cc: [email-masked]; [email-masked]
> Subject: [dccp] WGLC: draft-ietf-behave-dccp-01
> 
> <http://tools.ietf.org/html/draft-ietf-behave-dccp-01>.  The WGLC will
end
> on

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 29 Aug 2008 17:50:26 -0700

BEHAVE's WGLC on draft-ietf-behave-dccp-01 has concluded.  Remi, please
integrate the comments received, publish -02, and I will request publication.

-d

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dan Wing
> Sent: Thursday, August 07, 2008 6:24 PM
> To: Behave WG
> Subject: [BEHAVE] WGLC: draft-ietf-behave-dccp-01
>