Subject: [BEHAVE] NAT & Applications

From: RJ Atkinson <[email-masked]>
Date: Wed, 26 Nov 2008 09:47:43 -0500

At least in the IPv4 world, NAT devices are extremely widely
deployed.  Whether or not an application (protocol) designer
or implementer likes that, the deployed reality includes NAT
boxes all over the place.

It seems to me that application (protocol) designers might
find it useful to have a couple of informational documents
widely available:

1) NAT Considerations in Application Protocol Design

   This would provide guidance to application protocol designers
   on things that generally work better (e.g. use DNS names in
   on-the-wire protocols, rather than IP addresses) and also
   things that are known not to work well (e.g. FTP's practice
   of having separate control and data channels, passing IP
   addresses raw through the control channel protocol).

   Perhaps such a document exists and I've overlooked it ?

2) An abstracted C-language networking API specification

   A Java programmer colleague has pointed out that Java
   (and some other languages) offers much more abstracted
   networking APIs to application authors.  These use, for
   example, a fully-qualified domain name and service name,
   rather than a SockAddr, IP address, transport protocol name,
   and transport protocol port number.  This person noted that
   it would be a lot easier to create applications in C if
   a more abstracted API set were openly specified, so that
   various implementers could make that available (either as
   a kernel API or as a library).  This could also help with
   matters relating to Dynamic DNS, mobility, or multi-homing.
   It likely would encourage application coders to use an
   implementation strategy that is more likely to work through
   various kinds of middleboxes.  I gather some OS implementations
   offer such APIs on a proprietary basis.  It would be nice
   to have some openly specified API set of this sort.

I'm unsure whether any of these fit within any IETF WG charter,
but they could be done as individual submissions since neither
would need to be standards-track to be useful.

Perhaps I've overlooked such documents or I-Ds that already exist ?

Yours,

Ran
[email-masked]

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

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Wed, 26 Nov 2008 16:56:39 +0200

>    Perhaps such a document exists and I've overlooked it ?

Google points to RFC3235.

> Perhaps I've overlooked such documents or I-Ds that already exist ?

Not that I know. But as much as I am convinced hiding sockaddr could help IP 
version transition, I am heavily unconvinced about it helping NAT traversal 
in any meaningful way. I mean, I doubt programmers call getsockname() just 
for fun.

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

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 26 Nov 2008 10:21:51 -0500

On  26 Nov 2008, at 09:56, Rémi Denis-Courmont wrote:
> RFC-3235.

Thanks.  It seems a bit dated, somewhat IPv4-centric
(e.g. there is no mention of IPv6 at all), and it seems
to pre-date a number of developments in the IPsec world
(e.g. NAT traversal specifications).

Perhaps it is time for an update after 6 years ?

Cheers,

Ran

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 26 Nov 2008 16:28:45 +0100

> Perhaps it is time for an update after 6 years ?

Or maybe we should be more ambitious? If done right a new API could  
provide transparent TLS/IPsec negotiation as well as (try to) use  
multiple addresses, which could solve the "intial failure" case in  
shim6.

Note that I'm not advocating building in all these functions  
immedialy, just define a new interface in such a way that these  
functions can be implemented at some point in the future and then  
applications that use this API (or library) can start making use of  
these functions without having to be updated.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 26 Nov 2008 12:18:31 -0500

On  26 Nov 2008, at 11:32, Michael Richardson wrote:
>  And they regularly fail if reverse DNS lookup is "slow" or wrong, and
> it's damn hard to turn that lookup off in commodity JVM libraries,
> particularly if SSL is layered on top.
>  (I write from experience)

Interesting and useful data.

Some thoughts to ponder:

1) I did not propose to eliminate the current C-language APIs,
    I just proposed supplement them.

    In practice, BSD Sockets interfaces will never go away;
    far too much code relies upon those APIs.

    I am told that Java also has some low-level networking APIs,
    which I am also told are not commonly used by application  
developers.

2) Most non-Java applications will have the same exact issue
    if *any* DNS lookup is slow or wrong.

    So the question is I raised is whether we really want to make
    application writers go through the process of gethostbyname(),
    getservbyname(), and sundry other steps required by the BSD
    Sockets API -- or whether we want to simplfy their work and
    encourage use of more properly abstracted names by offering
    a cleaner, more abstracted API as an alternative.

3) Very few non-IETF users can distinguish between "DNS down",
    "DNS slow", and "network down".

    One of the lessons I have learned, mostly during my days in
    network engineering at a multi-continent residential broadband ISP,
    is that, for nearly all Internet users, "DNS slow" or "DNS down"
    is identical to "Internet down".  Our customer support call
    volumes reporting "Internet down" rose very very quickly anytime
    any DNS anomaly occurred -- rose faster than some fibre cuts even.

So while I think you make a solid case for tweaking the commodity
JVM library implementations a bit, I don't think that directly
speaks to the question of supplementing BSD Sockets with a cleaner,
more abstracted C-language API.

Cheers,

Ran
[email-masked]

---

From: Keith Moore <[email-masked]>
Date: Wed, 26 Nov 2008 14:05:18 -0500

>   to have some openly specified API set of this sort.

I have seen a few of these, and have attempted to write such APIs in the
past.  However, I have not found them very useful.  There has almost
always been some special case or another that I've had to code for,
which required digging down into lower level data structures - say to
bind to a specific source port, or to override RFC 3484 address
selection policy (because it's fundamentally broken and unfixable), or
to handle SRV and MX records for the protocols that require it (and NOT
for those that don't).  Some protocols absolutely require DNS (and not
other forms of name lookup), while for other protocols the friendly
thing to do is to use the default kind of lookup that the OS provides.

That, and I'm extremely leery about increasing the degree to which
protocol engines implicitly use DNS.  My experience is that DNS is
extremely fragile in practice (as in, very sensitive to configuration
errors, registrar conflicts, server failures, and link failures).  Fail
over to alternate servers is slow.  And I have no idea how much
disruption is currently caused by attacks, but the potential for attacks
concerns me quite a bit.  So, failing a much improved standard API for
DNS lookup, I think it's better to keep DNS lookups explicit and to
allow apps to roll their own code to do this if they need to.
(if nothing else, do the DNS lookups in a separate thread so that the
main thread doesn't block)

That, and the common DNS lookup APIs suck rather badly, in part because
they try to make things too simple.  Waiting an arbitrary amount of time
for a DNS lookup to complete doesn't make sense in a GUI application.
So I don't think simplifying things further makes sense, at least not in
a C programming environment.

I'm not claiming it can't be done, but rather, that the value in having
an API that hides the underlying details is marginal.

I'd actually proffer an argument in the opposite direction:  Lack of a
widely understood and very versatile/flexible API for network I/O in
some languages (among other factors) encourages people to keep using C
for network protocol implementations, despite the widely known hazards
associated with implementing network protocols using a language that
does little type checking and no bounds checking.

Keith

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Wed, 26 Nov 2008 15:30:41 -0500

It does seem like 3235 could be updated to reflect 5389, ICE, etc.

There's also 5128 as a p2p apps overview (more current practice than
strict recommendations) and draft-ietf-sipping-nat-scenarios.  But
neither is an update to 3235.

Bruce