Subject: [v6ops] protocols without need for ALG ?

From: Toerless Eckert <[email-masked]>
Date: Thu, 30 Jul 2015 13:58:06 -0700

For autonomic networking (ANIMA WG), we are planning to rely only on IPv6 for initial
autonomic connectivity, and the question of connecting this (at least initially)
to IPv4 only NOC equipment came up. Alas, IPv6 support in transport seems to be still
weak on a range of commonly used NOC tools.

If i understand the NAT RFCs and behave output correctly, we primaerily
want ALGs to go the way of the dodo, so i was wondering if there might be
any crucial protocols between typical NOC equipment and network devices that
would require ALGs. And better of course:knowing which protocols would be fine
without ALG.

Are there any lists about this (eg: what requires ALG ?)

Wrt to what seems to be important between NOC and network devices:

   FTP     - NOK (requires ALG) - IMHO not a problem
   traceroute - ??  (initiated from v4 NOC) ??
   telnet  - OK 
   ping    - OK ?
   SSH/SCP - OK
   syslog  - OK
   TFTP    - OK ?
   radius  - OK ? (i ran some tests, seemed to be fine)
   diameter/tacacs+ - OK ?
   NTP     - OK ???

   For the following, that have extensible data-models (MIBs/OIDs, XML schema etc.),
   i can see that some NOC tools relying on them might not support data-models
   with IPv6, but that would be "fine" (aka: can't manage everything from such tools,
   but transport stack works):

   netconf - OK ?
   SNMP    - OK ?

Whats the next most important NOC<->network management protocols... ?

Thanks!
    Toerless

---

From: Owen DeLong <[email-masked]>
Date: Thu, 30 Jul 2015 14:07:23 -0700

> On Jul 30, 2015, at 13:58 , Toerless Eckert <[email-masked]> wrote:
> 

FTP should be long deprecated for the most part anyway, however, PASV
mode FTP (if you must use FTP) should be OK without need of an ALG.

>   traceroute - ??  (initiated from v4 NOC) ??

Should generally be OK. Requests must come from translated side of
the host pair. Responses can come from either side, but to be meaningful,
need to be responding from native side to translated side.

>   TFTP    - OK ?

Should be OK, depending on which side is client. (client has to be the
private address/translated side of the connection).

>   radius  - OK ? (i ran some tests, seemed to be fine)

Should be OK, again, assuming favorable directionality.

If RADIUS/TACACS server is on translated side and router is on native side,
then this will not work without an ALG or some other hackery.

>   NTP     - OK ???

Same directionality considerations apply here.

>   but transport stack works):

Should be OK, assuming favorable directionality.

HTTP
HTTPs
SMTP
IMAP

sFlow/cFlow/etc.

Owen

---

From: Joe Touch <[email-masked]>
Date: Thu, 30 Jul 2015 14:24:30 -0700

On 7/30/2015 2:07 PM, Owen DeLong wrote:
>> want ALGs to go the way of the dodo, 

NATs too, if we're taking requests...

...
> mode FTP (if you must use FTP) should be OK without need of an ALG.

FTP has security problems but anonymous mode access to files is still
used. As noted, PASV avoids the need for ALG in-band address translation.

All the listed protocols should be OK if the client is behind the NAT
(as noted) *or* if the NAT is configured to forward those services to a
particular private-side host.

Other ALG protocols not on your list:

	web:
		HTTP	(mostly to hijack initial login screens,
			somtimes to insert tracking or ads)

	teleconferencing/media:
		Apple iChat
		H.323
		MGCP (media gateway)
		RTSP (realtime streaming)
		SCCP (Cisco call signalling)
		SIP

	remote functions:
		RPC (Sun, Microsoft)
		SQL

	tunneling:
		PPTP

---

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 30 Jul 2015 14:43:48 -0700

Thanks, Owen

Wrt directionality: I was just wondering about embedded addresses or other
difficult stuff. I was assuming 1:1 stateless v4<->v6 NAT, aka:  "directionality"
should not be an issue... Right ?

Thanks for the other protocol list.

Cheers
    Toerless

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 31 Jul 2015 07:11:14 +0200 (CEST)

> private address/translated side of the connection).

There are ALGs for TFTP from multiple vendors, and I seem to remember I 
had problem performing TFTP download from behind a NAT, but I could be 
mistaken. This should be investigated further.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Owen DeLong <[email-masked]>
Date: Thu, 30 Jul 2015 22:38:56 -0700

> On Jul 30, 2015, at 22:11 , Mikael Abrahamsson <[email-masked]> wrote:
> 
> There are ALGs for TFTP from multiple vendors, and I seem to remember I had problem performing TFTP download from behind a NAT, but I could be mistaken. This should be investigated further.

You might need STUN or something like that, but you shouldn’t need an ALG.

Owen

---

From: Mark Smith <[email-masked]>
Date: Fri, 31 Jul 2015 15:40:24 +1000

I'm pretty sure you'd need an ALG for TFTP over NAT, as the file transfer
itself takes place over unspecified and unpredictable ports. This caused me
some grief in the past when trying to have a TFTP file transfer hold up a
dial on demand link.

Regards,
Mark.

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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 31 Jul 2015 07:42:31 +0200 (CEST)

> You might need STUN or something like that, but you shouldn’t need an 

Well, if STUN is needed then this should be documented as well. It makes 
the TFTP client more complicated and it would break connectivity for 
legacy devices.

---

From: "Heatley, Nick" <[email-masked]>
Date: Fri, 31 Jul 2015 07:23:07 +0000

>FTP should be long deprecated for the most part anyway, however, PASV mode FTP (if you must use FTP) should be OK without need of an ALG.

EPSV all the way.
On a client on IPv4 side you need EPSV mode set to avoid ALG.
On a server side on IPv4 it must be RFC2428 compliant i.e. to accept EPSV.

_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops
NOTICE AND DISCLAIMER
This e-mail (including any attachments) is intended for the above-named person(s).  If you are not the intended recipient, notify the sender immediately, delete this email from your system and do not disclose or use for any purpose.  
 
We may monitor all incoming and outgoing emails in line with current legislation. We have taken steps to ensure that this email and attachments are free from any virus, but it remains your responsibility to ensure that viruses do not adversely affect you. 

EE Limited
Registered in England and Wales
Company Registered Number: 02382161
Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9BW.

---

From: "Heatley, Nick" <[email-masked]>
Date: Fri, 31 Jul 2015 07:23:07 +0000

Same for me.

From: v6ops [mailto:[email-masked]] On Behalf Of Mark Smith
Sent: 31 July 2015 06:40
To: Mikael Abrahamsson
Cc: v6ops list; [email-masked]
Subject: Re: [v6ops] protocols without need for ALG ?

> There are ALGs for TFTP from multiple vendors, and I seem to remember I had problem performing TFTP download from behind a NAT, but I could be mistaken. This should be investigated further.

I'm pretty sure you'd need an ALG for TFTP over NAT, as the file transfer itself takes place over unspecified and unpredictable ports. This caused me some grief in the past when trying to have a TFTP file transfer hold up a dial on demand link.

Regards,
Mark.

> --
> Mikael Abrahamsson    email: [email-masked]<mailto:[email-masked]>
>
>
> [email-masked]<mailto:[email-masked]>

NOTICE AND DISCLAIMER

EE Limited

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 31 Jul 2015 12:19:06 +0000

> Wrt to what seems to be important between NOC and network devices:

Is there ever a case where IPsec is used to establish a secure connection to the NOC equipment? I don't know -- I just know that IPsec is one of the most common ALGs around.
Barbara

---

From: Joe Touch <[email-masked]>
Date: Fri, 31 Jul 2015 06:21:01 -0700

TFTP servers are typically reached at UDP port 69.

It does not use ports or addresses in-band and thus should not need an ALG.

Joe

> On Jul 31, 2015, at 12:23 AM, Heatley, Nick <[email-masked]> wrote:
> 
> Same for me.
>  
> Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9BW
> 
>  
>

---

From: Ca By <[email-masked]>
Date: Fri, 31 Jul 2015 06:37:28 -0700

> weak on a range of commonly used NOC tools.
Ehhh. For something as forward looking as anima , it is unfortunate that
you believe you will need to bring this technical debt with you.

My suggeation is that you require ipv6 for this case. If you do not shed
this requirement now, you will carry it with you forever.

The iphone can require ipv6 apps, so can anima.

CB

> [email-masked] <javascript:;>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 01 Aug 2015 04:52:17 +1200

> you believe you will need to bring this technical debt with you.

Yes, but we assume that during the phasing-in of autonomic operations,
we will be forced to interface to legacy NOCs. Personally I think I
disagree with NAT46 and NAT64 as the way to handle this, but Toerless
is asking the right questions in order to have this debate over on the
Anima list.

    Brian

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

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 31 Jul 2015 10:44:21 -0700

On Sat, Aug 01, 2015 at 04:52:17AM +1200, Brian E Carpenter wrote:
> we will be forced to interface to legacy NOCs.

Right. It's just like siit-dc, just the opposite: We want to enable
the IPv6 only autonomic network (like they an IPv6 only DC) of course
to also encourage the IPv6 centric/only NOC but to get started also provide
a simple, isolated, and easily removed solution (hack ?) to connect to
legacy IPv4 NOC in our case (in siit-dc some legacy IPv4 (network)).

> Personally I think I
> disagree with NAT46 and NAT64 as the way to handle this

Actually i now think siit-eam is the easiest way - which i think is
an extension of stateless NAT64, but i don't claim i am using all
the terminology right.

> but Toerless

Right. once i'm back from PTO after next week...

Cheers
    toerless

-- 
---
Toerless Eckert, [email-masked]

---

From: 🔓Dan Wing <[email-masked]>
Date: Fri, 31 Jul 2015 11:41:40 -0700

On 31-Jul-2015 06:37 am, Ca By <[email-masked]> wrote: 
> 
> 
> On Thursday, July 30, 2015, Toerless Eckert <[email-masked] <mailto:[email-masked]>> wrote:
> Ehhh. For something as forward looking as anima , it is unfortunate that you believe you will need to bring this technical debt with you. 

+1.  Let's please kill ALGs.

See below.

> My suggeation is that you require ipv6 for this case. If you do not shed this requirement now, you will carry it with you forever. 
> 

FTP is a troublesome case.  All modern FTP clients default to using PASV -- IE 6 was the last holdout that didn't do PASV and thus broke with NAT or required an FTP ALG.  However,  PASV doesn't work with IPv6 servers which need EPSV.  So certain NAT46 and NAT64 cases will break unless there is an FTP ALG.  Hence, BEHAVE wrote RFC6384 which explains NAT64 case, but there isn't a document explaining the 464XLAT situation with FTP.  Better to just declare FTP dead.  Passive (both PASV and EPSV) are vulnerable to a connection theft (see http://cr.yp.to/ftp/security.html <http://cr.yp.to/ftp/security.html>).  For whatever it's worth, both Chrome and Firefox have open bugs to remove FTP from both of those browsers.

Instead of FTP, profile that anima has to use HTTP or HTTPS.

>    traceroute - ??  (initiated from v4 NOC) ??

OK.

>    TFTP    - OK ?

TFTP breaks if the NAT (or firewall) have Address and Port-Dependent Filtering behavior (defined at https://tools.ietf.org/html/rfc4787 <https://tools.ietf.org/html/rfc4787>#section-5).  This is because TFTP client sends a packet to the server's port 69, and the server's response is sent from an ephemeral port (rather than from port 69).  Some NATs and some firewalls change their filtering behavior if the destination port is 69, and because behavior changes based on the application (TFTP) many people would consider that to be an "ALG", although the NAT is not modifying the application payload, which is arguably the strict definition of an ALG.

Instead of FTP, profile that anima has to use HTTP or HTTPS.

>    but transport stack works):

SNMP often contains IP addresses (e.g., IP address of configured interfaces) which can confuse a management system that isn't aware of NAT.  We certainly don't want an ALG to fiddle with SNMP, though, that would be a nightmare.  Polling SNMP across a firewall or NAT is problematic or impossible (and ALG can't fix that).

-d

> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Fri, 31 Jul 2015 19:13:59 +0000

>		SCCP (Cisco call signalling)

Also, include LDAP, DNS and Netbios ALGs to the list.

Senthil

---

From: Tore Anderson <[email-masked]>
Date: Fri, 31 Jul 2015 22:17:16 +0200

* Toerless Eckert

> > Yes, but we assume that during the phasing-in of autonomic
> > operations, we will be forced to interface to legacy NOCs.
> 
> to also encourage the IPv6 centric/only NOC but to get started also
> provide a simple, isolated, and easily removed solution (hack ?) to
> connect to legacy IPv4 NOC in our case (in siit-dc some legacy IPv4
> (network)).

Yep, but be aware that with SIIT you will need to identify all
the IPv6 endpoints you want the IPv4-only NOC folks to be able to
access. These endpoints need either to be provisioned with an
IPv4-translatable IPv6 address (traditional SIIT), or get an IPv4
mapping provisioned on the protocol translator (SIIT-DC style
deployment with EAMs). You could also use Stateful NAT64 (RFC6146)
with statically configured BIB entries to accomplish pretty much the
same thing as the SIIT-DC approach, but you do get a lot of superfluous
baggage that way (all the stateful connection/session tracking stuff).

Anyway if the IPv6-only autonomic network is very dynamic in nature
and/or have a large number of managed endpoints that must be reachable
from the IPv4-only NOC, that requirement could possibly be problematic.

BTW you asked about traceroute, and I don't think anyone answered, so:
ICMPv6 packets originated by IPv6 hops behind the translator (that are
not provisioned with an IPv4-translatable IPv6 address) will appear as
originating from a "random" IPv4 address (which could repeat multiple
times in the path). That could possibly be confusing to NOC staff, so
I'd suggest giving the RFC6791 addresses descriptive PTR records in DNS
("this-apparent-ipv4-hop-really-represents-an-ipv6-router-in-the-autonomic-network-see-rfc6791.example.com").

> an extension of stateless NAT64, but i don't claim i am using all

Let me know if you want some help or pointers on how to set up a
stateless translator for testing purposes. Or you could use one of
mine, as it works just as well over the public internet too (as long as
the IPv6 endpoints you want to manage are numbered with globally
reachable addresses). I'd be happy to assist.

Tore

---

From: Michael Richardson <[email-masked]>
Date: Fri, 31 Jul 2015 16:31:44 -0400

Toerless Eckert <[email-masked]> wrote:
    > radius - OK ?

Classic RADIUS has an MD5 based authenticator which depends upon the IP address.
It can sometimes be made to work through NAPTs, but in general it doesn't.
Newer mechanisms get rid of this, replacing it all with DTLS, which doesn't
care, but the classic stuff is pretty widespread.
On the other hand, it is easily proxied from IPv6 to IPv4 should the
radius server be unable to speak IPv6.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Mark Smith <[email-masked]>
Date: Sat, 1 Aug 2015 09:45:13 +1000

> It does not use ports or addresses in-band and thus should not need an ALG.

Hmm, to my mind, an "ALG" is necessary if something about the protocol
needs to be understood e.g., look for/change in-band ports or
addresses, and possibly set up corresponding state or temporary access
list/firewall permissions for related traffic.

In the case of TFTP, it is the "TID"s:

"The transfer identifiers (TID's) used by
   TFTP are passed to the Datagram layer to be used as ports; therefore
   they must be between 0 and 65,535.  The initialization of TID's is
   discussed in the section on initial connection protocol."

" A
   requesting host chooses its source TID as described above, and sends
   its initial request to the known TID 69 decimal (105 octal) on the
   serving host.  The response to the request, under normal operation,
   uses a TID chosen by the server as its source TID and the TID chosen
   for the previous message by the requestor as its destination TID.
   The two chosen TID's are then used for the remainder of the transfer."

I think a server could choose to continue to use 69 as its TID for the
full transfer, however in my case it didn't. I still remember it today
because I was only able to get around the unpredictable TID selection
on both ends by using just host IP addresses, which had some risks
because it was a very coarse way of selecting "interesting"
dial-on-demand traffic to hold the link up.

So if in Toerless's scenario it is stateless 1:1 translation between
IPv4 and IPv6, then I don't think an ALG would be necessary for TFTP.
However, if the translation is stateful because translation between
IPv4 and IPv6 isn't 1:1, then I think an ALG is necessary to set up a
mapping of some form.

Regards,
Mark.

> This e-mail (including any attachments) is intended for the above-named
> person(s).  If you are not the intended recipient, notify the sender
> immediately, delete this email from your system and do not disclose or use
> for any purpose.
>
> We may monitor all incoming and outgoing emails in line with current
> legislation. We have taken steps to ensure that this email and attachments
> are free from any virus, but it remains your responsibility to ensure that
> viruses do not adversely affect you.
>
> EE Limited

---

From: Joe Touch <[email-masked]>
Date: Fri, 31 Jul 2015 17:46:35 -0700

Hi, Mark,

>    The two chosen TID's are then used for the remainder of the transfer."

Ahh, right - I forgot that TFTP doesn't stick to the same UDP port pair.
It works a bit like FTP in that it "hands off" the transfer to the
server port indicated by the server-side TID after the initial request.

> full transfer, however in my case it didn't.

It never will. The first packet is supposed to have a destination TID of
69 but the rest of the session uses TIDs chosen by each end.

	client sends sTID=X, dTID=69 on UDP sPORT=X dPORT=69
	
	server replies with sTID=Y, dTID=X on UDP sPORT=Y dPORT=X,
	which is where the rest of the transfer stays until a new TID
	is selected.

> I still remember it today

I'm not sure what you were doing; "using just host IP addresses" doesn't
fix the issue because TFTP still wants to pick TIDs, and the UDP ports
vary when the TIDs do.

> IPv4 and IPv6 isn't 1:1, then I think an ALG is necessary to set up a

So first let me backtrack - TFTP requires an ALG to work through a NAT
even when the client is on the private side. The return traffic content
needs to be inspected to be able to update the private:public
translation entry.

I.e., this won't work with stateless 1:1 *or* stateful 1:1 without an
ALG. I can't imagine how to make sense of it safely in a non-1:1 case.

Note that the whole point of TFTP is to be used on a LAN only. It has
zero security, and it's easily possible that the translation entry could
inadvertently affect some other UDP translation entry.

Joe

---

From: Mark Smith <[email-masked]>
Date: Sat, 1 Aug 2015 12:50:13 +1000

Hi Joe,

> server port indicated by the server-side TID after the initial request.

If I recall correctly, FTP uses TCP port 20 on one of the ends of the
file transfer, so that's the fixed port you can match on if you need
to.

>         which is where the rest of the transfer stays until a new TID

I haven't thought much about it, however I was thinking that the
combination of client address and TID would uniquely identify the file
transfer, so the server could still use TID 69 if it chose to.
However, I missed the bit in the RFC about both ends randomly choosing
the TID when I skimmed through it earlier.

> fix the issue because TFTP still wants to pick TIDs, and the UDP ports

The issue was that only certain types of traffic were both allowed to
trigger a dial on the dial-on-demand link and to hold it up. Matching
on UDP port 69 would bring up the link at the start of the TFTP
transfer, however the subsequent TFTP traffic wouldn't match on UDP
port 69 of course, so the d-on-d link would be torn down fairly
quickly (we had low value tear down timers to reduce cost and
contention for dial (ISDN) ports). So the only way I could "identify"
the TFTP traffic to keep the call up was to go down a layer, and match
on the IP addresses of the known sources/destinations of the TFTP
transfer. Of course, that isn't really selective at all, so any
traffic to or from those TFTP source/dest addresses would bring
up/hold up the d-on-d link. Fortunately the TFTP clients were routers,
so traffic directly to them was more controlled and limited than if
they had been general purpose hosts.

> ALG. I can't imagine how to make sense of it safely in a non-1:1 case.

I was thinking that stateless 1:1 translation between IPv4 and IPv6
addresses in the IP headers would work without an TFTP ALG, as long as
the UDP Ports/TIDs could be ignored, as there are no IP addresses in
the TFTP packets that would need to be translated.

1:1 IPv4 to IPv6 addressing for an Anima network may not be possible
to require however, so an ALG for TFTP might be unavoidable.

> inadvertently affect some other UDP translation entry.

For many years it was the only way to upload firmware and
configuration into a certain vendor's routers, and usually they were
remote!

Regards,
Mark.