[BEHAVE] Comments on DCCP NAT

[Gorry Fairhurst <[e-mail]>]

Remi,

As I said, I think this is a useful document to produce. I do have a few 
comments on your draft, as below.

Gorry

---
The Abstract seems to be a little short on motivation. Could we ad 
something like the text from  Behave TCP to indicate who should read this:

    such as peer-to-peer applications
    and on-line games, to work consistently.  Developing NATs that meet
    this set of requirements will greatly increase the likelihood that
    these applications will function properly.

- I think it could ALSO be good to state up-front that these 
requirements resemble those recommended for TCP.
---
Section 4.2 (simultaneous open).

Simultaneous Open updates DCCP by adding a new packet type, DCCP-Listen. 
The  DCCP-Listen packet communicates the information necessary to 
uniquely identify a DCCP session. NATs may utilise the connection 
information (address, port, Service Code) to establish local forwarding 
state.
---
Section 4.3
- Not sure I understand the wording of the REQ-4 requirement.
---
Section 6
It could also be appropriate to indicate that the payload of a DCCP-Data 
packet is usually a natural transmission unit, rather than a byte-stream 
as in TCP. The size is therefore determined by the application using 
DCCP and can vary from packet to packet.
---

Two other things  that I had in mind both follow the rule of don't 
change the other end-to-end protocol header fields:

1) Partial Coverage.

It is worth saying something about partial coverage:

DCCP supports partial checksum coverage. A NAT MAY perform incremental 
changes to the packet checksum field, as for IETF-defined protocols. 
However, if it needs to recalulate a new checksum value it MUST use the 
method described in section 9.2 of RFC4340.

The Checksum Coverage field in the DCCP header determines the parts of 
the packet that are covered by the Checksum field.  This always includes 
the DCCP header and options, but some or all of the application data may 
be excluded as determined on a packet-by-packet basis by the 
application. A NAT SHOULD NOT modify the Checksum field in the packet 
header. Changing this value in the network violates the integrity 
assumptions at the receiver and may result in unpredictable application 
behaviour.

2) Service Codes.

DCCP specifies a Service Code as a 4-byte value (32 bits) that describes 
the application-level service to which a client application wishes to 
connect [RFC4340]. This value MUST NOT be modified by the NAT. 
Implementation and guidance on use of Service Codes by middleboxes, 
including NATs can be found in [draft-ietf-dccp-serv-codes-04.txt].

<Note: The SC document will be updated to reflect this, and will also 
update the caution that SC can not be guarenteed to be associated with 
the applications that they claim to describe>.
---

Editorial NiTs that you may like to take-up in the next revision:

---
Introduction:
" handling datagrams and flows for application using the:
                                               ^
- Insert "s".
---
Introduction:
"enables when either or both"...
  ^^^^^^^
- This seems like the wrong word. Are we say it is "needed"
----
Introduction:
"[I-D.fairhurst-dccp-behave-update]"
- this was renamed [draft-ietf-dccp-simul-open-00.txt].
---
Section 6
"   modifying the payload of DCCP packets present a significant"
                                                  ^
-Please insert "s" (the "presents" refers to the modification).
---
Section 8
"Both sides of the DCCP session need must be updated to use"
                                 ^^^^
- delete "need"?
"A method MUST be defined to negociate when to use tunnelling."
           ^^^^
- Is this a requirement or an assertion? (i.e. "MUST" or "must")
---
Section 9
"   paassive endpoint in the connection establishment."
      ^
- remove "a"
---
Section 9
- Since the last comment, simultaneous open IS a working group document, 
therefore "the DCCP working group is defining an update to DCCP that 
will support this mode".
---
Section 8
"   A DCCP transport-specific solution is specified by
     [I-D.phelan-dccp-natencap]."
- A procedural note: This was not proposed as a working group item, 
therefore it is only an example of one proposal - there could be others.
---
_______________________________________________
Behave mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/behave