gli ALG come hackers-target nella transazione IPv4/IPv6 per comprendere le implicazioni insite nella fase di transazione da IPv4 ad IPv6 e' determinante conoscere la definizione di protocollo, a seguire UN PROTOCOLLO E' L'INSIEME DELLE REGOLE CHE DEFINISCONO IL FORMATO, LA SINTASSI E LA SEMANTICA DEI MESSAGGI. pertanto, per definizione, 2 protocolli distinti avranno almeno una delle 3 proprieta' che risulta diversa. in particolare l'IPv6 e' stato progettato sulla base di IPv4, ma e' differente in tutti e 3 gli aspetti; cosi' da un lato c'e' la necessita' di migrare ad IPv6 e dall'altro c'e' la comodita' di continuare ad usare IPv4. RFC 1705 << The reasons for change from IP to IPng can be described in terms of problems for which the current IP will simply become inadequate and unusable in the near future (~2-4 years). >> RFC 2766 << ........ In time, it is expected that Internet growth and a need for a plug-and-play solution will result in widespread adoption of IPv6. >> per mitigare gli efetti negativi, in particolare il ritardo nell'adozione generalizzata di IPv6, la IETF ha posto particolare attenzione al favorire a tutti i livelli la relativa compatibilita' tra i 2 IP, in parte con la numerazione, in parte con il formato degli headers, in parte con altri meccanismi, soluzioni, standard, best pratice e quant'altro. cosi sono stati definiti "IPv6 Addressing Architecture" [RFC4291], "TRANS-MECH" [RFC2893], "SIIT" [RFC2765], "NAT-PT" [RFC2766], "BIS" [RFC2767], "TRT" [RFC3142] e "BIA" [RFC3338] che danno il quadro delle raccomandazioni di IETF per le conversioni tra IPs. e con cio' si e' giunti al punto che la migrazione diventa "appetibile"; in particolare per alcuni casi "semplici", quelli in cui la presenza di una data particolarita' in IPv6 lo renda talmente superiore da generare un ritorno economico. ma per far comunicare 2 stack TCP/IP distinti e diversi ci vuole "qualcosa" che esegua la traslazione, in mancanza di questi "qualcosa" IPv6 e' destinato ad essere adottato tra 20 anni. RFC 1933 << The key to a successful IPv6 transition is compatibility with the large installed base of IPv4 hosts and routers. Maintaining compatibility with IPv4 while deploying IPv6 will streamline the task of transitioning the Internet to IPv6. >> RFC 2767 << ....... In order to advance the transition smoothly, it is highly desirable to make the availability of IPv6 applications increase to the same level as IPv4. Unfortunately, however, this is expected to take a very long time. >> immediatamente si creano nuovi problemi, il primo e piu' ovvio e' che ALMENO una parte degli hosts, per lungo tempo sara' IPv4 ED IPv6 "capable"; quantomeno gli apparati di rete, se non anche i "computers normali". RFC 1933 << The mechanisms in this document are designed to be employed by IPv6 hosts and routers that need to interoperate with IPv4 hosts and utilize IPv4 routing infrastructures. We expect that most nodes in the Internet will need such compatibility for a long time to come, and perhaps even indefinitely. >> RFC 2766 << There is expected to be a long transition period during which it will be necessary for IPv4 and IPv6 nodes to coexist and communicate. A strong, flexible set of IPv4-to-IPv6 transition and coexistence mechanisms will be required during this transition period. ............. By combining SIIT protocol translation with the dynamic address translation capabilities of NAT and appropriate ALGs, NAT-PT provides a complete solution that would allow a large number of commonly used applications to interoperate between IPv6-only nodes and IPv4-only >> RFC 2767 << In the especially initial stage of the transition from IPv4 to IPv6, it is hard to provide a complete set of IPv6 applications. This memo proposes a mechanism of dual stack hosts using the technique called "Bump-in-the-Stack" in the IP security area. The mechanism allows the hosts to communicate with other IPv6 hosts using existing IPv4 applications. >> dal che emergono diverse questioni, 3 su tutte : a) lo spazio di risoluzione dei nomi, essendo distinto tra i 2 protocolli, DEVE replicare nei casi di host dual-stack l' HOSTNAME E "bind"-arlo a 2 indirizzi che pur "simili" [RFC4291], sono anche, necessariamente e per definizione, diversi; il che implica una ambiguita' in quanto il comportamento "complessivo" dell'host e' dipendente dall'ordine di arrivo delle risposte e dall'ordine in cui vengono interpretate. RFC 1933 << When an IPv4-compatible IPv6 addresses is assigned to an IPv6/IPv4 host that supports automatic tunneling, both A and AAAA records are listed in the DNS. The AAAA record holds the full IPv4-compatible IPv6 address, while the A record holds the low-order 32-bits of that address. The AAAA record is needed so that queries by IPv6 hosts can be satisfied. The A record is needed so that queries by IPv4-only hosts, whose resolver libraries only support the A record type, will locate the host. >> draft-ietf-biw-00.txt << A BIW translator has a DNS ALG that is similar to the one described in NAT-PT. The DNS ALG is cited as the source of several problems with NAT-PT. However, the DNS ALG in a BIW translator is less troublesome, since it only handles queries generated by a single IPv4-only host. The DNS ALG in a NAT-PT must handle all queries that pass between the IPv4 and IPv6 domains. >> b) le "imperfezioni" negli stack non pienamente "ISO-OSI compliant" (ovvero : tutti quelli di uso comune) si DEVONO riflettere anche in uno stack che sottostia ai requisiti del modello ISO-OSI per renderli compatibili; cosi' come nei flussi attivi la velocita' di trasmissione complessiva dipende dall'elemento piu' lento della catena, anche nella conformazione dei protocolli la "bonta' complessiva" dipende dal peggiore di essi. RFC 2765 << The potential existence of stateless IP/ICMP translators is already taken care of from a protocol perspective in [IPv6]. However, an IPv6 node that wants to be able to use translators needs some additional logic in the network layer. >> c) se fino ad ora i dati venivano incapsulati con una certa "sintassi", e con IPv6 se ne usa "un'altra", ci devono essere dei punti in cui alcune imprecisioni/ambiguita' sono ammesse, necessariamente. RFC 2765 << One of the differences between IPv4 and IPv6 is that in IPv6 path MTU discovery is mandatory but it is optional in IPv4. This implies that IPv6 routers will never fragment a packet - only the sender can do fragmentation. >> RFC 1933 << The encapsulating node could view encapsulation as IPv6 using IPv4 as a link layer with a very large MTU (65535-20 bytes to be exact; 20 bytes "extra" are needed for the encapsulating IPv4 header). The encapsulating node would need only to report IPv6 ICMP "packet too big" errors back to the source for packets that exceed this MTU. However, such a scheme would be inefficient for two reasons: 1) It would result in more fragmentation than needed. IPv4 layer fragmentation should be avoided due to the performance problems caused by the loss unit being smaller than the retransmission unit [11]. 2) Any IPv4 fragmentation occurring inside the tunnel would have to be reassembled at the tunnel endpoint. For tunnels that terminate at a router, this would require additional memory to reassemble the IPv4 fragments into a complete IPv6 packet before that packet could be forwarded onward. The fragmentation inside the tunnel can be reduced to a minimum by having the encapsulating node track the IPv4 Path MTU across the tunnel, using the IPv4 Path MTU Discovery Protocol [8] and recording the resulting path MTU. The IPv6 layer in the encapsulating node can then view a tunnel as a link layer with an MTU equal to the IPv4 path MTU, minus the size of the encapsulating IPv4 header. Note that this does not completely eliminate IPv4 fragmentation in the case when the IPv4 path MTU would result in an IPv6 MTU less than 576 bytes. (Any link layer used by IPv6 has to have an MTU of at least 576 bytes [4].) In this case the IPv6 layer has to "see" a link layer with an MTU of 576 bytes and the encapsulating node has to use IPv4 fragmentation in order to forward the 576 byte IPv6 packets. ............... The handling of other types of ICMP error messages depends on how much information is included in the "packet in error" field, which holds the encapsulated packet that caused the error. Many older IPv4 routers return only 8 bytes of data beyond the IPv4 header of the packet in error, which is not enough to include the address fields of the IPv6 header. More modern IPv4 routers may return enough data beyond the IPv4 header to include the entire IPv6 header and possibly even the data beyond that. If the offending packet includes enough data, the encapsulating node may extract the encapsulated IPv6 packet and use it to generating an IPv6 ICMP message directed back to the originating IPv6 node, as shown below: >> SE esistono dei traduttori "quasi ottimali" per quanto riguarda il FORMATO dei messaggi, RFC 2765 << One way of viewing the translator, which might help clarify why applications do not need to know that a translator is used, is to look at the information that is passed from the transport layer to the network layer. If the transport passes down an IPv4 address (whether or not is in the IPv4-mapped encoding) this means that at some point there will be IPv4 packets generated. In a dual node the generation of the IPv4 packets takes place in the sending node. In an IPv6-only node conceptually the only difference is that the IPv4 packet is generated by the translator - all the information that the transport layer passed to the network layer will be conveyed to the translator in some form. That form just "happens" to be in the form of an IPv6 header. When an IPv4-to-IPv6 translator receives an IPv4 datagram addressed to a destination that lies outside of the attached IPv4 island, it translates the IPv4 header of that packet into an IPv6 header. It then forwards the packet based on the IPv6 destination address. The original IPv4 header on the packet is removed and replaced by an IPv6 header. Except for ICMP packets the transport layer header and data portion of the packet are left unchanged. >> RFC 3142 << .....As the TRT system reside in transport layer, it is not possible for the TRT system to translate protocols that are not known to the TRT system. >> JOIN-Team << There's a potential danger of the abuse of a TRT-server as a relay on IP-level. Theoretically it might be possible to use the TRT-server for Denial of Service- (DoS) or Distributed Denial of Service-attacks (DDoS). A malicious client could use it to spoof its address and send packets to IPv4-hosts via the TRT-server. >> E contemporaneamente, esistono protocolli di livello superiore al 3 che NON rispettano "il proprio mandato" sconfinando nei livelli inferiori RFC 2765 << The applications that have been modified to work on a dual node already have the mechanisms to determine whether they are communicating with an IPv4 or an IPv6 peer. Thus if the applications need to modify their behavior depending on the type of the peer, such as ftp determining whether to fallback to using the PORT/PASV command when EPRT/EPSV fails (as specified in [FTPEXT]), they already need to do that when running on dual nodes and the presense of translators <----- presenCe does not add anything. >> ALLORA esistono dei casi in cui la mera traslazione di formato e' insufficiente; e' necessario interagire anche col payload ovvero con la sintassi. pertanto esiste NAT-PT che fa' affidamento sulla presenza di ALG per la trasformazione sintattica. RFC 2766 << Application Level Gateway (ALG) [NAT-TERM] is an application specific agent that allows a V6 node to communicate with a V4 node and vice versa. Some applications carry network addresses in payloads. NAT-PT is application unaware and does not snoop the payload. ALG could work in conjunction with NAT-PT to provide support for many such applications. >> questi ALG sono, a mio parere, il punto focale su cui un hacker dovrebbe indagare per sovvertire le regole di funzionamento previsto di un network ibrido IPv4/IPv6. RFC 2766 << .......This requires no changes to end nodes and IP packet routing is completely transparent [NAT-TERM] to end nodes. It does, however, require NAT-PT to track the sessions it supports and mandates that inbound and outbound datagrams pertaining to a session traverse the same NAT-PT router. You will note that the topology restrictions on NAT-PT are the same with those described for V4 NATs in [NAT-TERM]. Protocol translation details specified in [SIIT] would be used to extend address translation with protocol syntax/semantics translation. ........ ......... A fundamental assumption for NAT-PT is only to be use when no other native IPv6 or IPv6 over IPv4 tunneled means of communication is possible. In other words the aim is to only use translation between IPv6 only nodes and IPv4 only nodes, while translation between IPv6 only nodes and the IPv4 part of a dual stack node should be avoided over other alternatives. .......... Since NAT-PT performs address translation, applications that carry the IP address in the higher layers will not work. In this case Application Layer Gateways (ALG) need to be incorporated to provide support for those applications. This is a generic problem with NAT and it is fully described in [NAT-TERM]. >> perche'. ipv6.com << Limitations of Application level Gateways An application-level gateway does have drawbacks which limits its functionality, they are: Delay due to the amount of time it can take to inspect packets. Many applications are not designed for ALGs e.g Email , Web Speed and Routing issues Application level gateways does not serve as a good choice ,if the application protocol embed IP addressing >> supponiamo che i casi di FTP e DNS siano definitivamente risolti con un ALG FTPoverIP4 <--> FTPoverIPv6, un secondo per il "doppio" DNS e di procedere imperterriti nel mescolare risorse IPv4 e risorse IPv6. prima o poi, saltera' fuori che anche il protocollo NETBIOS o IRC o altro voglia essere traslato e che si ripresenti un caso analogo a quello dell'FTP e che questa tendenza sia in continua crescita proprio per l'inclusione di nuove "nicchie appetibili" alla transazione verso IPv6. 2 esempi di ALG IPv4/IPv4 comunemente implementati sui firewalls da JUNOS << Id Address Comment 16 0063b148 DNS 1 0063cc9c FTP 6 00639a08 HTTP 2 0064a068 RSH 59 004f7938 H245 60 0051465c Q931 61 0051de9c RAS 71 00d5bb3c SCCP 72 00d699d4 MGCP_UA 73 00d699d4 MGCP_CA 5 00872814 PORTMAPPER 63 00db4f94 SIP 64 00650e28 SQLNETV2 65 006522a8 TALK 29 00652968 TFTP 62 00649754 REAL 11 0064d06c RTSP 66 00652c10 VDO 67 00653050 XING 68 00865e24 MSRPC_EPM >> piu' o meno corrispondenti ai "fixup" di IOS << class inspection_default inspect ftp inspect h323 h225 inspect h323 ras inspect rsh inspect rtsp inspect sqlnet inspect skinny inspect sunrpc inspect xdmcp inspect sip inspect netbios inspect tftp inspect http >> ovvero ci sara' una "corsa" all' ALG, prima in sordina e poi con le fanfare TUTTI i produttori di sw, funzionante o meno che sia, tenteranno di vendere ALG per il PROPRIO applicativo/protocollo, quantomeno. Polycom << Polycom's IPv6 ALG solution will provide seamless migration and support between existing IPv4 and IPv6 networks and components, including Polycom's industry leading MGC and VSX product lines. The IPv4 -IPv6 ALG will convert the media and control messages between the two standards, enabling IPv6 and IPv4 conferencing components to communicate directly with one another. This solution will be applicable for H.323 and SIP and can work in a mixed IPv4, IPv6 environment. This solution will not require additional hardware upgrades to the Polycom MGC, VSX products or legacy endpoints and will work with IPv4 or IPv6 endpoints and MCUs. >> draft-ietf-v6ops-3gpp-analysis-08.txt << SIP and SDP transition has to be made in an SIP/SDP Application Level Gateway. The ALG has to change the IP addresses transported in the SIP messages and the SDP payload of those messages to the appropriate version. In addition, there has to be interoperability for DNS queries; see section 2.4 for details. >> ma gia' ora gli ALG IPv4/IPv4 sono punti deboli, nei firewalls : Linksys << Product: AG310, Annex A ....... Firmware Version 1.00.04 ....... - Fixed issue with SIP ALG ..... >> Cisco << Note: The September 24, 2008 IOS Advisory bundled publication includes twelve Security Advisories. ......... * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sip.shtml ............ RTSP applications use the well-known port 554 with TCP (rarely UDP) as a control channel. The security appliance only supports TCP, in conformity with RFC 2326. This TCP control channel is used to negotiate the data channels that will be used to transmit audio/video traffic, depending on the transport mode that is configured on the client ......... Because RFC 2326 does not require that the client and server ports must be in the SETUP response message, the security appliance will need to keep state and remember the client ports in the SETUP message. QuickTime places the client ports in the SETUP message and then the server responds with only the server ports. ................. Restrictions and Limitations The following restrictions apply to the inspect rtsp command: The security appliance does not support multicast RTSP or RTSP messages over UDP. PAT is not supported with the inspect rtsp command. The security appliance does not have the ability to recognize HTTP cloaking where RTSP messages are hidden in the HTTP messages. The security appliance cannot perform NAT on RTSP messages because the embedded IP addresses are contained in the SDP files as part of HTTP or RTSP messages. Packets could be fragmented and the security appliance cannot perform NAT on fragmented packets. With Cisco IP/TV, the number of NATs the security appliance performs on the SDP part of the message is proportional to the number of program listings in the Content Manager (each program listing can have at least six embedded IP addresses). You can configure NAT for Apple QuickTime 4 or RealPlayer. Cisco IP/TV only works with NAT if the Viewer and Content Manager are on the outside network and the server is on the inside network. Media streams delivered over HTTP are not supported by RTSP application inspection. This is because RTSP inspection does not support HTTP cloaking (RTSP wrapped in HTTP). >> una babele di ALG, spesso malfatti, invadera' le host-farm; con una motivazione sensata in termini economici : mantenere il funzionante E renderlo IPv6 compatibile. immaginiamo ora un firewall posto a difesa di una risorsa, come un server HTTP-over-IPv4 che, per esser reso "IPv6 compatible", venga affiancato da un ALG "ad hoc" (e concedendo che questo non sia pieno di bug): fino ad ora il firewall stesso e' stato messo in condizione di ispezionare il payload, ma dal momento in cui ANCHE un "ad hoc" ALG-host lo faccia come suo unico scopo di esistenza? i flussi IPv6 saranno inoltrati all' ALG SENZA ispezione di livello "application" NEL firewall (altrimenti esso stesso diverrebbe l' ALG-host IPv4/IPv6 in AGGIUNTA alle attuali funzioni di ALG IPv4/IPv4). quindi se arriva un pkt IPv6 questo sara' diretto all' ALG IPv4/IPv6, se invece e' IPv4 all' host; cosi' come nel caso opposto: un pkt IPv4 destinato ad un server IPv6 "saltera'" l' ispezione del firewall per essere analizzato altrove, PRIMA di giungere a destinazione. ma, allora, saranno necessarie il doppio di trigger-rules negli IDS/IPS e 1000 altri dettagli andranno esattamente calibrati .......... LA COMPLICAZIONE AUMENTA; AD OGNI ALG IPv4/IPv6 che sia aggiunto in una data host-farm vengono introdotti, quantomeno, percorsi IP distini a seconda della tipologia della sorgente, quella incontrollabile, quella in mano agli hackers cattivi. RFC 2766 << One of the most important limitations of the NAT-PT proposal is the fact that end-to-end network layer security is not possible. Also transport and application layer security may not be possible for applications that carry IP addresses to the application layer. This is an inherent limitation of the Network Address Translation function. Independent of NAT-PT, end-to-end IPSec security is not possible across different address realms. The two end-nodes that seek IPSec network level security must both support one of IPv4 or IPv6. >> ma supponiamo pure che la complicazione aggiuntiva sia governata e governabile. dato un lasso di tempo sufficiente e posto che la complessita' non abbia rappresentato un ostacolo insormontabile, gli ALG saranno decine, in una tipica farm. quanto efficienti? quanto error-prone? quanto affidabili? ciascuno avra' la propria "misura" : dai minimali ai veramente complessi (immaginate il porting di un Tivoli, Oracle o qmail), il proprio costo, supporto (o mancanza di) e cosi' via. una batteria di proxies specializzati in conversioni di formato E di sintassi. e la semantica? anche la semantica risente dell' introduzione degli ALG? probabilmente no, se non in rari casi, quelli che un hacker sfrutta. RFC 2766 << A number of IPv4 fields have changed meaning in IPv6 and translation is not straightforward. For example, the option headers semantics and syntax have changed significantly in IPv6. Details of IPv4 to IPv6 Protocol Translation can be found in [SIIT]. >> il numero di protocolli trasportati over-IP e' tale da GARANTIRE la presenza di errori, debolezze e vulnerabilita' in molti di essi. una parte sara' semplicemente sostituita velocemente dalle controparti IPv6, una parte restera' com'e' per "indegnita' ad essere riscritta" (cioe' la correzione delle debolezze per riscrittura del sw non e' conveniente) ed una parte (credo consistente, ma si vedra') di questi protocolli VORRA' essere resa utilizzabile ANCHE da sitemi IPv6. che le "debolezze" di questi protocolli NON vengano corrette dagli ALG e' scontato, sarebbe in contrasto con la loro stessa esistenza, quindi saranno mantenute. ed altre ne saranno aggiunte per entropia, anche se le legge di Murphy non fosse vera. l'esplorazione di questo "territorio" e' del tutto inadeguata al bisogno prossimo venturo; c'e' un intero nuovo mondo in cui giocare a guardie-e-ladri via internet. la scoperta delle debolezze, la loro classificazione, la conoscenza delle contromisure; tutto porta a concludere che ci sara' ampio spazio per "interagire coi dettagli" in questa categoria di application-proxies. have fun $witch