Subject: [BEHAVE] Endpoint-Independent Mappings found to be harmful if always imposed

From: Rémi Després <[email-masked]>
Date: Thu, 06 Nov 2008 18:58:41 +0100

Sorry for  reacting so late on draft-ietf-behave-dccp (now -04), but
better late than never.

1.

REQ-1 is:

'A NAT MUST have an "Endpoint-Independent Mapping" behavior for DCCP.'

This strong statement was originally made under the assumption that
external ports available in NATs were more numerous than necessary.

As sharing IPv4 global addresses becomes more and more necessary and as
port utilization in hosts has evolved, this
assumption is no longer appropriate everywhere.

2.

There has been a discussion in May on a possibility to authorize  more
sparing an use of available ports, but without conclusion then. It is
therefore appropriate to have it again now, before it is too late for
the DCCP draft.

The simple idea goes that way:

"A NAT MUST have an "Endpoint-Independent Mapping" behavior for all
outgoing connections except those that, because of their destination
ports when the mapping is established, are known to be compatible with
less port consuming mappings.

Well known ports reserved by IANA for the following applications are
known to be compatible with endpoint-dependent mappings: DNS, POP3,
IMAP, HTTP, HTTPS, SNMP."

Note that words are chosen so that,  although some of the  listed
applications concern more TCP than DCCP,   they remain valid in the
more
limited scope of DCCP, and so that the sentence could apply unchanged
to NAT
requirements for UDP, TCP and SCTP.

3.

Concerning the DNS, the point is particularly important because of the
behavior now recommended for resolvers to mitigate the *Kaminsky
vulnerability*. They use a new local port for each request, each
port necessitating a new mapping it each traversed NAT.

Regards,

RD

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

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Fri, 7 Nov 2008 09:33:01 +0200

> external ports available in NATs were more numerous than necessary.

Most importantly, this is the _only_ known way to do "bilateral" NAT 
traversal. DCCP simultaneous open, now in Working Group Last Call is relying 
on this. This is especially important for protocols such as DCCP that are 
clearly aimed at conveying RTP payloads, in which case NAT-to-NAT 
communication is preponderant.

> outgoing connections except those that, because of their destination ports
> when the mapping is established, are known to be compatible with less port
> consuming mappings. Well known ports reserved by IANA for the following
> applications are known to be compatible with endpoint-dependent mappings:
> DNS, POP3, IMAP, HTTP, HTTPS, SNMP."

This statement is EXACTLY THE SAME as the the current one. Because there is no 
such thing as DNS, POP3, IMAP, HTTP, HTTPS neither SNMP over DCCP.

> applications concern more TCP than DCCP,   they remain valid in the more
> limited scope of DCCP, and so that the sentence could apply unchanged to
> NAT requirements for UDP, TCP and SCTP.

And the ports list is ???

> vulnerability*. They use a new local port for each request, each port
> necessitating a new mapping it each traversed NAT.

First, we don't do DNS over DCCP. Second this is a non-argument anyway. In 
_real_ networks, behind a given NAT, all hosts will be using the same 
recursive DNS server. So all DNS queries are from NAT_IP:NAT_port to 
DNS_IP:53. Hence, whether you do endpoint-dependent mapping or not does not 
affect your port number requirements _at_all_.

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

---

From: Rémi Després <[email-masked]>
Date: Fri, 07 Nov 2008 16:07:18 +0100

Rémi,

Thanks for your comments.

More comments below.

Regards,

RD

Rémi Denis-Courmont   (1-12/1-31/200x) 11/7/08 8:33 AM:

1.
REQ-1 is:

- What has been related to the assumed port abundance is only the fact
that endpoint-independent mappings are imposed to _all_ mappings,
including those that clearly don't need it.

- IMU, simultaneous opens don't occur for DNS, POP3, IMAP, HTTP, HTTPS,
or SNMP.

This statement is EXACTLY THE SAME as the the current one.

I would not say "exactly". It does convey information that is absent in
the current one.

Because there is no

- I do agree, of course,  that the proposed statement does deal with
non DCCP cases.

- But IMO it is nevertheless useful here pending its availability in
other RFCs (those on UDP and TCP in particular).

- The constraint is that contradiction with the remainder of the
document must be avoided, which IMU is satisfied.

- If the question marks are to say that other applications could be in
the list, Yes, certainly.

- But the point is not to have an exhaustive list, just a list of
_some  common applications_ for which endpoint-dependent mappings
(EDMs) can save a number of ports.

3.

- On this you are right: if the recursive DNS server used by all local
hosts is external to the NAT,  then EDM doesn't help (it only doesn't
hurt).

- But, if a recursive DNS server used by at least some hosts is with
them behind the NAT, this server will send queries to various other
(non recursive) DNS servers. In this case EDM does reduce the number of
used ports. Also right?

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Fri, 7 Nov 2008 17:46:42 +0200

On Friday 07 November 2008 17:07:18 ext Rémi Després, you wrote:
> that endpoint-independent mappings are imposed to _all_ mappings, including
> those that clearly don't need it. - IMU, simultaneous opens don't occur for
> DNS, POP3, IMAP, HTTP, HTTPS, or SNMP.

What does clearly not need simultaneous open for DCCP? The RTP/RTCP pair 
clearly does need it.

> DNS, POP3, IMAP, HTTP, HTTPS, SNMP."

The IANA port registry does not maintain the required informations for this 
for the time being.

>  - I do agree, of course,  that the proposed statement does deal with non
> DCCP cases. - But IMO it is nevertheless useful here pending its
> availability in other RFCs (those on UDP and TCP in particular).

The UDP and TCP RFCs are available. And they do the same as the DCCP draft.

---

From: Rémi Després <[email-masked]>
Date: Fri, 07 Nov 2008 17:56:30 +0100

Rémi Denis-Courmont   (1-12/1-31/200x) 11/7/08 4:46 PM:

You seem to imply that RTP/RTCP are used for DNS, POP3, IMAP, HTTP,
HTTPS, or SNMP.

Is this what you mean?

Which required informations?

Knowing which port numbers are reserved for listed applications is
enough from IANA.

IETF _is_ the place where applications are known.

It looks like you have read and answered a little fast.

It is  _the statement_ which is not available in these RFCs.

I  know (of course) that there are RFCs on UDP and TCP.

Now back to the substance.

As a matter of fact both RFC 4787 and RFC 5382 (UDP and TCP
respectively) ) have an explanation for the the systematic
endpoint-independent mapping, while your draft on DCCP has none.

The problem now is that the given explanation for UDP and TCP is IMU _not
technically right, or as a minimum very ambiguous_ :

'REQ-1:  A NAT MUST have an "Endpoint-Independent Mapping" behavior for
TCP.  Justification:  REQ-1 is necessary for UNSAF methods to work.'

If this means that, for UNSAF to work,  endpoint-dependent mapping must
be avoided whatever the application, this IMU is wrong.

Can you explain why,  if a NAT does endpoint-dependent mapping just
for outgoing connections going to port 80,  this prevents UNSAF to work?

If you can, you definitely have a point, and a clarification in your
draft would be welcome.

But if you can't, I definitely have a point, worth consideration in
Behave.

_Please don't ignore the question_.

RD

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Fri, 7 Nov 2008 19:15:28 +0200

On Friday 07 November 2008 18:56:30 ext Rémi Després, you wrote:
>  You seem to imply that RTP/RTCP are used for DNS, POP3, IMAP, HTTP, HTTPS,
> or SNMP. Is this what you mean?

Sorry, this question makes no sense to me.
(And your email formatting makes them very difficult to read to top it all)

>  Knowing which port numbers are reserved for listed applications is enough
> from IANA. IETF _is_ the place where applications are known.

Please point me to the list of port numbers that do not require endpoint 
dependent mapping at www.iana.org.

>  As a matter of fact both RFC 4787 and RFC 5382 (UDP and TCP respectively)
> ) have an explanation for the the systematic endpoint-independent mapping,
> while your draft on DCCP has none.

The draft has a normative dependency on BEHAVE-UDP and DCCP simultaneous-open.

>  Can you explain why,  if a NAT does endpoint-dependent mapping just  for
> outgoing connections going to port 80,  this prevents UNSAF to work? If you
> can, you definitely have a point, and a clarification in your draft would
> be welcome. But if you can't, I definitely have a point, worth
> consideration in Behave.

No I can't. I cannot predict what DCCP port 80 will (if ever) be used for.
Plonk.

---

From: Rémi Després <[email-masked]>
Date: Fri, 07 Nov 2008 19:00:50 +0100

>> for outgoing connections going to port 80,  this prevents
UNSAF to

>> work? If you can, you definitely have a point, and a
clarification

>> in your draft would be welcome. But if you can't, I definitely
have

>> a point, worth consideration in Behave.

> No I can't. I cannot predict what DCCP port 80 will (if ever) be
used

> for. Plonk.

This question was for NATs in general, not for DCCP in particular.

Anyway, I do get the point that you don't want to go on with this
discussion.

Fair enough.

RD

---

From: "Saikat Guha" <[email-masked]>
Date: Fri, 7 Nov 2008 19:59:32 -0500

On Thu, Nov 6, 2008 at 12:58 PM, Rémi Després <[email-masked]> wrote:
>[...]
> As sharing IPv4 global addresses becomes more and more necessary and as port
> utilization in hosts has evolved, this assumption is no longer appropriate
> everywhere.

Jumping in a bit late; apologies if my understanding is dated but
didn't see a clarification in the discussion to my question below. ...

If I understand correctly, the concern about too few ports stems from
with *port-overloading* and not endpoint-mapping.

Endpoint-independent mapping only says you should use the port you
used _last time_ for that internal address-port pair. (i.e. that
address-port already has an external port which the NAT should reuse,
reducing pressure on external ports). While port-overloading says once
an external ip-port has been allocated to an internal address-port
pair, another internal address-port pair should not be mapped to that
external address-port pair ... which is what creates the pressure on
external port.

Imagine a NAT algorithm that performs the mapping for 64K internal
hosts each with 64K ports, to a single external IP and 64K external
ports as follows.

IA : Internal host number 0..64K
IP : Internal port
EA : (fixed) Mapped external address
EP : Mapped external port

EP = (IA + IP) mod 64K

So internal host-port 1:100 *always* gets external address-port EA:101
and internal host-port 2:100 always gets external address-port EA:102
... hence this NAT is endpoint-independent mapping.

The only limitation is that Host 1 using local port 102 cannot talk to
the same destination as host 2 using local port 100. But host 1 has
the option of using port 103 to talk to the same destination. Wouldn't
such a weakening of the port-overloading requirement allow NATs to be
endpoint-independent as well as support a massive number of hosts
behind it?

-- 
Saikat

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 7 Nov 2008 17:49:19 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Saikat Guha
> Sent: Friday, November 07, 2008 5:00 PM
> To: Rémi Després
> Cc: Dan Wing; Dave Thaler; Rémi Denis-Courmont; Behave WG
> Subject: Re: [BEHAVE] Endpoint-Independent Mappings found to 
> be harmful if always imposed
> 

Yes, such port overloading would allow using ports much more efficiently.
There are two proposals to do this on the table:

* draft-wing-behave-dynamic-tcp-port-reuse is similar to what you describe.
It uses a timer as the heuristic to determine if the port should be
overloaded.  

* The other technique, which I believe is only described in email, is to use
the port number as the heuristic to determine if the port should be
overloaded.

We might want to pick one, or combine them, or make it experimental, or
abandon the idea if it is too offensive to promote by publishing an RFC.

-d