Re: WGLC for dccp-udpencap

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Eddie,

Thanks for the comments.  I am in general agreement.  See inline for
specifics.

Tom P.

> -----Original Message-----
> From: dccp-bounces@xxxxxxxx [mailto:dccp-bounces@xxxxxxxx] On Behalf
Of
> Eddie Kohler
> Sent: Monday, September 20, 2010 12:45 PM
> To: dccp@xxxxxxxx
> Subject: Re:  WGLC for dccp-udpencap
> 
> Hello all,
> 
> I understand that WGLC for this draft has concluded, but in case
comments
> are
> useful, here are several.  I strongly approve of the document; it is a
> clean
> and useful spec and a good advance on prior versions, whether or not
these
> comments are addressed.  The only technical comment has to do with
> demultiplexing; this is important to address.
> 
> * Ports (section 3.1): I agree with those who have commented about the
> oddity
> of "normally both [souce & destination ports] are the default port to
be
> assigned by IANA".  I agree with Gorry & the document that it is
useful to
> have a default port.  But keeping the src&dst ports as the default is
> unnecessary and unlikely to hold.
> 
[TomP] Hmm.  People seem to like to assume that "normally" means that it
MUST be this way.  That wasn't the intention.

> I would change the explanation as follows.  Note the third paragraph,
set
> off
> with %%%.  This is new text.  I think we must mention demultiplexing
> (whether
> the UDP Ports are ignored for demultiplexing purposes), and I believe
that
> demultiplexing MUST consider UDP Ports as well as DCCP ports: there is
a
> risk
> that the same DCCP Source Port will be used by two endpoints behind a
NAT,
> as
> in the ASCII art diagram below.
> 
>    S1 --> UDP sport U1, DCCP sport D1,
>           UDP dport UX, DCCP dport DX
>               \
>                v      UDP sport U1, DCCP sport D1, UDP dport UX, DCCP
> dport DX
>               NAT =========================================> SERVER
>                ^      UDP sport U2*, DCCP sport D1, UDP dport UX, DCCP
> dport DX
>               /
>    S2 --> UDP sport U1, DCCP sport D1,
>           UDP dport UX, DCCP dport DX
> 
>    * To prevent ambiguity the NAT changes S2's UDP sport; all else
remains
> the
>      same; the NAT cannot reach into the DCCP header to change those
> ports.
>      If DCCP-STD were used with a DCCP-aware NAT, one of the DCCP
sports
> would
>      change.
> 
> BEGIN TEXT
> 
> Source and Dest(ination) Ports: 16 bits each
> 
> These fields identify the UDP ports used for the encapsulated DCCP
> connection.
>   Note that they do not identify the DCCP source and destination
ports.
> 
> A DCCP-UDP server (that is, an initially passive host that receives
> DCCP-Request packets [RFC 4340]) MAY reserve a UDP port number for all
> encapsulated DCCP connections.  In this case, DCCP-UDP packets
arriving at
> the
> server will have the same UDP Destination Port.  UDP port number XXX
has
> been
> registered with IANA for this purpose.  A DCCP-UDP client MAY use this
> port
> number as its UDP Source Port as well.  However, any DCCP-UDP endpoint
MAY
> use
> any UDP port numbers (as long as the active endpoint knows a valid UDP
> Destination Port on the passive endpoint).
> 
> %%% The identifier for a DCCP-UDP connection is the 6-tuple <source
> address,
> UDP Source Port, DCCP Source Port, destination address, UDP
Destination
> Port,
> DCCP Destination Port>, rather than a 4-tuple <source address, source
> port,
> destination address, destination port>. %%%
> 
> END TEXT
> 
[TomP] I didn't consider this case.  I'll update the draft.

> * Checksum (section 3.1): "This field is the Internet checksum of a
> network-layer pseudoheader and the UDP packet." -- Might be nice to
> mention
> here that 0 checksums aren't allowed, as well as in S3.3.
> 
[TomP] OK -- I think just to 3.3, say a zero checksum is invalid.

> * S3.3: It might be nice to refer to DCCP's Data Checksum option,
pointing
> out
> that, unlike the DCCP-Checksum header field, the Data Checksum option
MUST
> be
> processed as usual.
> 
[TomP] OK.

> Eddie
> 
> 
> On 09/18/2010 04:23 AM, Pasi Sarolahti wrote:
> > WG Last Call for draft-ietf-dccp-udpencap concluded some days ago.
> Thanks to everyone who commented! It's unclear to me if we have
conclusion
> on some of the discussed topics, namely:
> >
> > * The text on checksums and partial checksums
> >
> > * Security considerations and the text on firewalls
> >
> > * Discussion on source/destination port allocation and NAPT
> >
> > * Applicability of the Section 5.1 text
> >
> > Tom, do you think we have converged on these? Also, I'd like to see
some
> comments on Gerrit's review, to see to what degree there is agreement
on
> the issues.
> >
> > Assuming we have settled with the above topics, I think we need a
> revision based on the discussion, that would then be sent to the IESG.
> >
> > - Pasi
> >
> >
> > On Aug 27, 2010, at 9:16 PM, Pasi Sarolahti wrote:
> >
> >> This mail starts a working group last call for the UDP
encapsulation
> draft. The draft is available at http://www.ietf.org/internet-
> drafts/draft-ietf-dccp-udpencap-02.txt . Please read the draft and
send
> any comments to the DCCP mailing list. Also, if you think the document
is
> good to go forward, it will be helpful if you send a note about that
to
> the mailing list.
> >>
> >> The WGLC lasts for two weeks, until September 10.
> >>
> >> - Pasi
> >>
> >



[Index of Archives]     [Linux Kernel Development]     [Linux DCCP]     [IETF Annouce]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]

  Powered by Linux