Molti documenti indicano che in QUIC risolve il problema dello spoofing IP da parte di un token generato dal server. In particolare, il server emette un token in modo che il client possa utilizzarlo per identificarsi, quindi il server risponderà solo a quelli con token validi.
Ma l'hacker non può solo alterare l'IP della connessione iniziale? Non otterrebbe lo stesso effetto dello spoofing IP del server DNS o NTP?
But can't the attacker just IP-spoof the initial connection? Wouldn't that achieve the same effect of IP spoofing of DNS or NTP server?
Il problema con lo spoofing IP in DNS o NTP non è che la risposta torni all'indirizzo IP falsificato invece del vero mittente, perché questo è vero anche se si contraffa l'indirizzo IP in un SYN TCP. Il problema invece è che spesso la risposta è molto più grande della richiesta e quindi un utente malintenzionato può utilizzare una piccola larghezza di banda con indirizzi IP falsificati per causare un ampio attacco di banda contro l'IP spoofato (cioè l'attacco di amplificazione).
TCP risolve questo problema avendo solo una piccola risposta a una piccola richiesta in modo che nulla venga amplificato. Purtroppo non riesco a trovare facilmente informazioni sulla dimensione effettiva del token dell'indirizzo sorgente in QUIC, ma spero che vengano presi in considerazione attacchi di amplificazione.
EDIT: grazie per paj28 per indicare un articolo dove il problema dell'amplificazione in QUIC è affrontato in maggiori dettagli: ... il client ciao sarà sempre più grande di, o uguale alla dimensione della risposta del server ... . Ciò significa che l'amplificazione attacca come il problema principale dello spoofing IP non funzionerà.
Dipende da cosa intendi con "IP spoofing problem"?
Il protocollo QUIC appartiene al livello di trasporto anziché il livello di rete .
L'attenuazione degli effetti dello spoofing può essere effettuata nel livello del tranport, così come è stato fatto in TCP, il client deve sia inviare che ricevere pacchetti per aprire un flusso di dati. Se il 3-way-handshake non è completo, il client non sarà in grado di parlare con l'applicazione. Ma questo non risolve veramente il problema. Lo spoofing IP è ancora in corso.
Credo che il "problema dello spoofing IP" non possa essere corretto nel livello di trasporto, perché non si riferisce al modo in cui i pacchetti viaggiano da A a B su Internet.
Se una applicazione può ricevere dati da indirizzi IP falsificati, e il protocollo di trasporto sottostante non protegge l'applicazione da questo, quindi dai un'occhiata a Steffen Ullrich s risposta per ulteriori spiegazioni su come questo rendere possibili attacchi di amplificazione.
Non possiamo impedire all'aggressore di inviarci pacchetti con sorgenti di origine contraffatte (l'ISP degli attaccanti può impedire loro di inviarli ma questo è un altro problema), possiamo solo mitigarne gli effetti.
Ci sono due principali scenari da proteggere.
L'introduzione del token risolve entrambi i problemi. Lo spoofer può inviare pacchetti "iniziali" tutto il giorno ma non possono eseguire altre azioni perché non ricevono mai il token.
Leggi altre domande sui tag ip-spoofing protocols