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

From: Toerless Eckert <[email-masked]>
Date: Sat, 1 Aug 2015 02:33:03 -0700

On Fri, Jul 31, 2015 at 10:17:16PM +0200, Tore Anderson wrote:
> 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).

The autonomic addressing plan proposed so far is that we'd have
very few eg; /112 prefixes (eg: one per so-called registrar),
and then eg: 16 bit of serial number. So you can see how easy this
would map with siit-eam. 

> 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).

Is there a Yang model for 4146 so i can beter understand what the
intended operator experience is ? ;-))

Yes, it does mention "static configured mapping" in three places in the
text, and i see in Cisco IOS implementation also the ability to
configure 1:1 IPv4<->IPv6 mappings, and i therefore guess that these
are the "static configured mappings" of 4146, but what i can't find
is any explanation why the operations of such entries would have
to be stateful at all. What would those 4146 entries do different than
stateless siit-eam /32 <-> /128 entries, and whats the "benefit" ? 

But obviously, in a network with 50,000 IPv6 nodes with ULAs,
i wouldn't want to set up an orchestration to configure 50,000
1:1 entries, even stateless, but rather a single /16 <-> /112
(or a few similar slightly longer prefixes). 

> 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).

Thanks.

> 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").

Yepp. Haven't gotten around to all DNS recommendations, but given how
i am trying to see that full stateless mapping will suffice i hopefully
won't run intot hese problems.

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

Sure, please send me pointers offline, i'll take a look! 

Cheers
    Toerless

---

From: Tore Anderson <[email-masked]>
Date: Sun, 2 Aug 2015 17:24:56 +0200

* Toerless Eckert

> stateless siit-eam /32 <-> /128 entries, and whats the "benefit" ?

Well, one implementation I tested (Cisco ASR1K) allowed these 1:1
IPv4<->IPv6 mappings in Stateful NAT64 mode. However I noticed that it
did install session table entries for every connection made towards the
statically mapped IPv4 address. Not sure if those session table entries
were ever used for anything though.

Another implementation (Jool) would allows adding static BIB entries in
Stateful NAT64 mode, but it requires you to also include the ports used
- so if you wanted to do a full 1:1 mapping between an IPv4 address and
an IPv6 address you'd have to add 64k static BIB entries in order to
make traffic to arbitrary ports work...

> (or a few similar slightly longer prefixes). 

Indeed, if the IPv6 destinations are nicely aggregatable in a small
prefix like a /112 SIIT with an EAM sounds like exactly what you want.
I'll follow up off-list.

Tore

---

From: Joe Touch <[email-masked]>
Date: Tue, 4 Aug 2015 10:47:06 -0700

Hi, Mark,

On 7/31/2015 7:50 PM, Mark Smith wrote:
...
> 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.

FTP has two modes. Active mode uses a fixed server port (21) for
commands and a fixed client port (20) for each data transfer.

Passive mode uses a fixed server port (21) and let's the server tell the
client the server's port for each subsequent transfer. Passive mode
won't work when the client is behind a NAT because the server can't call
the client on a known port.

In passive mode, the ports are sent back from the server in-band. It
works when the client is on the private side of a NAT because the client
still calls the server.

In-band port numbers are used only in passive mode. You'd think that
would mean that passive mode would require translation, but it's because
of the direction of the use of the ports that translation isn't required.

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

Yes, it *could*, and that'd be a decision totally up to the server.
However, the server code would need to know when it can 'reuse' that
number. By the current spec, the TIDs are not reused (for some time
period) regardless of address, which simplifies servers state.

Note that there might be another reason for this. Booting might occur
from a temporary address or even a shared address, so there might be a
benefit to not needing to avoid reuse of that one port to that one address.

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

I really don't think you want to run TFTP through anything that isn't
local (see below).

...
>> 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.
> 
> For many years it was the only way to upload firmware and
> configuration into a certain vendor's routers, and usually they were
> remote!

People used to leave their front doors unlocked too, but those days are
over. IMO, TFTP ought to be blocked through anything that indicates
"off-lan" access.

(even though TFTP is still widely used, e.g., in UEFI)

Joe

---

From: "ietfdbh" <[email-masked]>
Date: Tue, 4 Aug 2015 17:58:17 -0400

RFC2962 includes a detailed description of the requirements and
   limitations for an implementation of an SNMP Application Level
   Gateway.  It also discusses other approaches to exchange SNMP packets
   across conflicting addressing realms.

David Harrington
[email-masked]
+1-603-828-1401
> -----Original Message-----
> From: Behave [mailto:[email-masked]] On Behalf Of Toerless
> Eckert
> Sent: Thursday, July 30, 2015 4:58 PM
> To: [email-masked]; [email-masked]
> Subject: [BEHAVE] protocols without need for ALG ?
> 
> 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
> 
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Mark Andrews <[email-masked]>
Date: Wed, 05 Aug 2015 18:36:34 +1000

In message <[email-masked]>, Joe Touch writes:
> Hi, Mark,
> 
> On 7/31/2015 4:45 PM, Mark Smith wrote:
> > On 31 July 2015 at 23:21, Joe Touch <[email-masked]> wrote:
> >> 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.
> > 
> > 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."
> 
> 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.
> 
> 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
> > 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.
> 
> 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.
> 

Actually it is to provide a *Trivial* File Transfer Protocol that
works over UDP.  If it was LAN only it would be LFTP.  TFTP works
fine over inter-continental links.  Been there, done that.

> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Wed, 5 Aug 2015 09:57:17 -0700

> fine over inter-continental links.  Been there, done that.

It *can* work anywhere, but its lack of security and congestion control
are good reasons not to use it outside protected environments.

Further, it was "trivial" back when TCP was thought to be comparatively
huge; reasonable implementations of TCP are very small and memory isn't
anywhere near as limited.

Joe