Re: [v6ops] [BEHAVE] protocols without need for ALG ?

On 31-Jul-2015 06:37 am, Ca By <cb.list6@gmail.com> wrote: 
> 
> 
> On Thursday, July 30, 2015, Toerless Eckert <eckert@cisco.com <mailto:eckert@cisco.com>> wrote:
> 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.
> 
> 
> 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. 
> 
> The iphone can require ipv6 apps, so can anima. 
> 
> CB
>  
> 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

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.

>    telnet  - OK
>    ping    - OK ?
>    SSH/SCP - OK
>    syslog  - 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.

>    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 ?

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

> 
> Whats the next most important NOC<->network management protocols... ?
> 
> Thanks!
>     Toerless
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org <javascript:;>
> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave