Subject: Review of draft-ietf-behave-dccp-04

From: Christian Vogt <[email-masked]>
Date: Thu, 6 Nov 2008 14:07:41 +0200

Folks,

I was asked to review draft-ietf-behave-dccp-04 as input for IESG
evaluation, and I got three comments:

(1) On the abstract:

         Developing NATs that meet this set of requirements will greatly
         increase the likelihood that applications using DCCP will
         function properly.

     Sounds a bit like DCCP would work well only if we develop NATs. ;-)
     Better reword to:

         Ensuring that NATs meet this set of requirements will greatly
         increase the likelihood that applications using DCCP will
         function properly.

(2) On requirements 1 and 3:

         REQ-1: A NAT MUST have an "Endpoint-Independent Mapping"
         behavior for DCCP.

         REQ-3: If application transparency is most important, it is
         RECOMMENDED that a NAT have an "Endpoint-independent filtering"
         behavior for DCCP.  If a more stringent filtering behavior is
         most important, it is RECOMMENDED that a NAT have an
         "Address-dependent filtering" behavior.

     These requirements are general and not specific to DCCP.  Would it
     make sense to specify them in a separate RFC for NATs in general,
     independent of any specific transport protocol?

(3) On requirement 6:

         REQ-6: If a NAT includes ALGs, it MUST NOT affect DCCP.

     This requirement is not 100% clear.  I am assuming it means:  "If a
     NAT includes ALGs, the NAT MUST NOT affect DCCP packets that are
     processed by one of those ALGs."  Suggest to reword the requirement
     in this way.

- Christian

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

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Thu, 6 Nov 2008 14:23:27 +0200

>      independent of any specific transport protocol?

Whether it's of any use depends on the connection model (or lack thereof) of 
the transport protocol. I don't want to presume that this would make sense 
for all future transport protocols. In fact, it does not make sense for 
multicast UDP(-Lite) to me - which has its own document.

>      processed by one of those ALGs."  Suggest to reword the requirement

This reads worse to me. An ALG cannot "process" DCCP packets if it does not 
affect in any way. There is already a IESG discuss on this. What about this?

          REQ-6: If a NAT includes ALGs, they MUST NOT affect DCCP.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Christian Vogt <[email-masked]>
Date: Fri, 7 Nov 2008 13:00:19 +0200

Rémi -

> for all future transport protocols. [...]

I don't agree.  A reason for recommending endpoint-independent mapping  
and
filtering is to enable applications to refer each other to a host  
behind a NAT.
This is desirable independent of the transport protocol.

>          REQ-6: If a NAT includes ALGs, they MUST NOT affect DCCP.

Make it even clearer:

           REQ-6: If a NAT includes ALGs, the ALGs MUST NOT affect DCCP.

- Christian

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Fri, 7 Nov 2008 13:18:57 +0200

On Friday 07 November 2008 13:00:19 ext Christian Vogt, you wrote:
> and filtering is to enable applications to refer each other to a host
> behind a NAT. This is desirable independent of the transport protocol.

But whether this is useful depends on the transport protocol and/or connection 
model. It does help for unicast UDP (and UDP-Lite). It does help for TCP, 
only if simultaneous open is supported by the application, the operating 
system and the middleboxes. If does help for DCCP _only_ if the DCCP stack 
implements the simultaneous open option, which is _not_ in the baseline DCCP 
document.

It does not help with, e.g. multicast UDP. It does not mean anything for 
port-less protocol, including ICMP, proto-41, etc. It is insufficient for 
SCTP. Who knows how it applies to would-be future transports?

Besides, I think it's too late for a "factorized" BEHAVE specification. Good 
news: we have much of the baseline in the BEHAVE-UDP RFC. The other documents 
already borrow quite a lot from it, especially the general concepts and 
terminology.

>            REQ-6: If a NAT includes ALGs, the ALGs MUST NOT affect DCCP.

Right.

---

From: Christian Vogt <[email-masked]>
Date: Mon, 10 Nov 2008 09:39:31 +0200

Rémi,

endpoint independent mapping and filtering enables address referrals  
between
application instances (which use the same port number).  This  
advantage is
independent of the transport protocol and the connection model.  The
exceptions you are listing are special cases for NAT'ing in general,  
not only
with regard to the usefulness of endpoint independent mapping and  
filtering.

Anyway, I am fine with requiring endpoint independence in transport- 
specific
documents.

- Christian

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Mon, 10 Nov 2008 10:03:57 +0200

On Monday 10 November 2008 09:39:31 ext Christian Vogt, you wrote:
> between application instances (which use the same port number).  This
> advantage is independent of the transport protocol and the connection
> model.  The exceptions you are listing are special cases for NAT'ing
> in general, not only with regard to the usefulness of endpoint
> independent mapping and filtering.

I don't disagree... Lets say that endpoint independent mapping is one half of 
a solution. We need another half: either a "simultaneous hole punching" 
mechanism, (and/)or endpoint independent _filtering_. With neither of these, 
address referrals from endpoint independent mappings are essentially 
unusable.

As we have painfully learned in MMUSIC, this is not completely obvious. It 
works rather well for UDP, but it is poorly supported for TCP in the real 
world. And then DCCP had to be explicitly extended, as it did not support it 
at all.

If we assume that all IETF transports will support simultaneous hole punching, 
then yes, endpoint independent mapping.

---

From: Christian Vogt <[email-masked]>
Date: Mon, 10 Nov 2008 10:11:50 +0200

Rémi Denis-Courmont wrote:

> I don't disagree... Lets say that endpoint independent mapping is  
> one half
> of a solution. We need another half: either a "simultaneous hole  
> punching"
> mechanism, (and/)or endpoint independent _filtering_...

Maybe that was our misunderstanding:  Yes, we need both, endpoint- 
independent
mapping /and/ filtering.  But re-read my email; I in fact talked about  
both.

- Christian