Please see clarifications sin-line,
Gorry
On 31/08/2010 20:14, Phelan, Tom wrote:
Hi Gorry,
Thanks for the close read and the comments. See inline...
Tom P.
-----Original Message-----
From: dccp-bounces@xxxxxxxx [mailto:dccp-bounces@xxxxxxxx] On Behalf
Of
Gorry Fairhurst
Sent: Tuesday, August 31, 2010 2:42 PM
To: 'dccp' working group
Cc: Phelan, Tom
Subject: Review in WGLC for draft-ietf-dccp-udpencap-02.txt.
I have read the latest version of this specification during the WGLC
and
believe this is an important topic to publish a document.
The current draft appears to have addressed issues I think were
important and would seem nearly ready for publication, however I do
have
some queries, as listed below.
Best wishes,
Gorry
---
Section 3.3
- I think some sections miss context on why the decision was made,
e.g.
in 3.3, please do say briefly why the WG chose to do this.
[TomP] I'm not sure what you mean here. Do you mean that we chose not
to support partial checksums?
GF: A sentence saying WHY the WG decided not to allow partial checksums
- i.e. at least to say DCCP requires a checksum of the DCCP protocol
data (and by default the DCCP applications payload), so UDP checksum
must not be disabled.
---
Section 3.3.1:
- Have you thought about whether this section should also reaffirm
that
the checksum value in the encapsulated DCCP header is always zero?
GF: I'd like to see the draft capture in a sentence WHY this decision
was made by the WG. For instance, this could be based on a need to
support traversal on NAT/NAPT middleboxes that modify the endpoint IP
addresses (and possibly ports) - these devices typically update the
outer (UDP) checksum but a device that is not aware of DCCP-in-UDP would
not know to also update an inner DCCP checksum.
- replace /Chesksums/ with /Checksums/
[TomP] I don't see a reason to say that receiver should verify that the
DCCP checksum is zero.
I've fixed the typo.
---
Section 6:
/The option is a binary one however; either allow all DCCP
applications or allow none./
- This seems a little harsh. The options based on the UDP-header are
as
stated. A firewall than interprets this specification could in
principle
look inside the UDP encaps and filter based on DCCP information.
It doesn't sound that implausible given the sophistication of many
current firewalls, however it would be extra complexity that would
need
to be justified. In my opinion, we should encourage this, so that
firewalls can open pin-holes for DCCP in the same way as they do for
other transports.
[TomP] Well, I do think that will be the case in many situations, and it
is the case with security implications, so I think it should be
mentioned. How about adding a parenthetical, "(unless the firewall
supports flexible deep packet inspection rules)".
GF: So, I wouldn't like the new text a lot more. It prejudges the way
firewalls are designed. I'd much prefer to invert the argument and say
three things:
* There are many behaviours for middleboxes acting as firewalls. This
depends in part on the protocols that they are configured to interpret.
* A firewall that only inspects the UDP header would only be able to
filter on the source, not on each DCCP connection or application using
DCCP ...
... on the ports point, I'm still unclear what port values you expect a
firewall to see when there are multiple DCCP-in-UDP endpoints behind a
NAPT, sharing an address - I expect these flows to be assigned different
ports based on the source.
* A firewall that is aware of this encaps may inspect the inner DCCP
header...
---
- I see the value of the IANA-specified destination port for a client
server app using a NAPT, where the NAPT changes only the src port as
it
leaves the client, and does this differently for each sender address
behind the NAPT. What is the expected port usage at the receiver? Does
it listen on the IANA port bound to any source port? Can you say more
here?
[TomP] So section 3.1 says:
Source and Dest(ination) Ports: 16 bits each
These fields identify the UDP ports on which the source and
destination (respectively) of the packet are listening for
incoming DCCP-UDP packets (normally both are the default port to
be assigned by IANA). Note that they do not identify the DCCP
source and destination ports.
I don't know that I see any necessary changes here, except it should
probably mention that the port values can be changed along the way by
NAPT boxes. You say, "Does it listen on the IANA port bound to any
source port?" I assume by this you mean will it accept an incoming
packet with any source port? Do we need to open this UDP can of worms?
GF: We don't need to open the can of worms, but it may be wise to
realise that if the intention is to travserse middleboxes that the ports
(in particular the src port from a "client") may be updated by a
middlebox, e.g. NAPT, and therefore a receiver should expect that one
(or both) ports may be different to the IANA assigned value.
---
References
- The references have not been split between normative and
informative,
the normative refs should have been agreed by the WGLC.
- I think the following are not normative to this specification:
RFC4787, RFC5597, RFC5238, RFC5596, RFC5595
[TomP] My first take was that these were normative, but I think I see
your point. I'll make them informative.
---
UPDATES Line?
- The document explicitly says this updates RFC 5762, but the boilere
text at the head of the ID does not identify this as an update.
Please
add a boiler plate line that explicitly states what is updated by
this
specification.
- Are there issues with an Experimental RFC updating a standards-track
RFC???
[TomP] I see your issue. We probably should not update a standards
track RFC with an experimental one. Does anyone have any advice?
Extends rather than updates? Adds capabilities to those specified in
RFC 5762?
GF: Understood, these words seem better, if this is published as EXP.
- Is this intended to update RFC 4340? - if so, same question as
above.
[TomP] It was not my intention to update RFC 4340.
----
Note:
/(default port awaiting IANA action)/
- As I understand the IETF procedure, this could now be allocated by
an
IANA request. I'm assuming this is a "registered" port, rather than a
"well-known" port?
- The RFC-to-be can then say this document allocates port XX for use
by
this method.
[TomP] OK
----
The following additional comments seem to be NiTs:
---
3. DCCP-UDP
/insert a UDP ([RFC0768]) /
^ ^
-The brackets around the citation seem odd to me.
[TomP] You mean '()' not '[]' right? I agree.
GF: OK
---
/and there are no other IP addresses embedded./
- There are no other IP addresses embedded in the encapsulation
header,
there could be in the DCCP application data, with all that implies.
[TomP] OK
---
| Application Data Area | Variable length (could be
0)
- I prefer straight /Application Data/
rather than /Application Data Area/
- but I recall both being used in RFC 4340, so I guess this is
personal
preference.
[TomP] RFC 4340 uses "Application Data Area" in the basic packet format
definition, so I'll stick with that.
---
--
Prof Gorry Fairhurst, School of Engineering, University of Aberdeen.
The University of Aberdeen is a charity registered in Scotland,
No SC013683.
