[ipv6-tf] 6to4 - cienie i blaski

[Bartek Gajda]

Grzegorz Banasiak wrote:
> Lukasz Stelmach wrote:
> 
> [..]
> 
>> Wiem, ze sie powtorze ale czemu nie 6to4?
> 
> 
> Z Panem Lukaszem prowadzilem korespondencje odnosnie 6to4, ale moze 
> powtorze sie w szerszym gronie.
> 
> 6to4 jest ciekawym mechanizmem przejsciowym, ktore moze stanowic 
> uzupelnienie brokera. Jezeli operator dysponuje brokerem (w polskich 
> realiach - stworzyl go samemu lub akceptuje warunki sixxs), to czemu nie 
> mialby rownolegle uruchomic 6to4, nawet na tych samych maszynach? Jezeli 
> brokera nie ma, to moze zaczac od 6to4.
> 
> Zalety:
> - bardzo prosta "implementacja" (tak naprawde - konfiguracja) po stronie 
> ISP,
> - mechanizm dostepny na roznych systemach operacyjnych uzytkownikow, w 
> tym pod windows, gdzie przy wlaczonej usludze 6to4 interfejs tunelujacy 
> sam sie konfiguruje, jezeli system znajdzie na ktoryms interfejsie adres 
> publiczny.
> 
> Watpliwosci:
> - wsparcie dla uzytkownikow o publicznym lecz zmiennym adresie IPv4 
> klopotliwe: prefiks 2002:adres_IPv4::/48 uzytkownika sie zmienia (czyli 
> zmiennosc IPv4 pociaga za soba zmiennosc IPv6), a w niektorych 
> konfiguracjach potrzebne dodatkowe "oskryptowanie" (wspominal o tym 
> Lukasz).  na pierwszy rzut oka windows na zmiane publicznego adresu v4 
> reaguje bez angazowania i informowania uzytkownika - sprawdzalem tylko 
> przez reczna zmiane adresu na interfejsie Ethernet.
> 
> Wady (w stosunku do brokera):
> - klopotliwa kontrola dostepu do uslugi. jesliby operator chcial 
> zastosowac pozadana regule "nieznane blokuj", to musialby 
> zaimplementowac wlasciwie czesc funkcjonalnosci brokera, a w przypadku 
> zmiennych adresow IPv6 cos w rodzaju sixxsowego heartbeata. pozostaje 
> zatem dopuszczenie calych blokow adresow,
> - brak wplywu na relay 6to4, ktorym wraca ruch skierowany na adresy 
> produkcyjne v6. generalnie odbywa sie to przez _jakis_ relay w swiecie. 
> jezeli takowy relay pada, a ISP, ktory za niego odpowiada nadal radosnie 
> rozglasza 2002::/16, to operator moze sie tylko slodko usmiechnac do 
> uzytkownika i czekac,
> - operator z uruchomionym relayem 6to4 _musi_ rozglaszac w BGP prefiks 
> 2002::/16 (_nie wolno_ mu rozglaszac czegokolwiek "more specific"), wiec 
> bedzie sciagac zupelnie obcy ruch na swoj relay 6to4. tego ruchu 
> oczywiscie jest bardzo malo, ale nie kazdy operator sie na sam fakt 
> zgodzi, bo np. ma taka a nie inna polityke routingu,
> - 6to4 daje mniejsze mozliwosci jesli chodzi o sledzenie trendow niz 
> broker.

no wlasnie, pozostaje kwestia zarzadzania dostepem oraz zagadnienia dot. 
bezpioczenstwa - patrz RFC 3964 "Security Considerations for 6to4 ":


    As the 6to4 router must accept traffic from any other 6to4 router or
    relay, a certain requirement for trust is implied, and there are no
    strict constraints on what the IPv6 packet may contain.  Thus,
    addresses within the IPv4 and IPv6 headers may be spoofed, and this
    leads to various types of threats, including different flavors of
    Denial of Service attacks.

    The 6to4 specification outlined a few security considerations and
    rules but was ambiguous as to their exact requirement level.
    Moreover, the description of the considerations was rather short, and
    some of them have proven difficult to understand or impossible to
    implement.

[...]

    There are mainly four classes of potential problem sources:

    1.  6to4 routers not being able to identify whether relays are
        legitimate

    2.  Wrong or impartially implemented 6to4 router or relay security
        checks

    3.  6to4 architecture used to participate in DoS or reflected DoS
        attacks or made to participate in "packet laundering", i.e.,
        making another attack harder to trace

    4.  6to4 relays being subject to "administrative abuse" e.g., theft
        of service or being seen as a source of abuse.

    The first is the toughest problem, still under research.  The second
    can be fixed by ensuring the correctness of implementations; this is
    important.  The third is also a very difficult problem, impossible to
    solve completely; therefore it is important to be able to analyze
    whether this results in a significant increase of threats.  The
    fourth problem seems to have feasible solutions.

pozdrawiam,
Bartek

> 
> pzdr,
>