From b0683b2447e6041488ae9e7d4db065276d4531fc Mon Sep 17 00:00:00 2001 From: Othmar Gsenger Date: Fri, 27 Apr 2007 18:32:09 +0000 Subject: i --- internet-draft-satp.html | 2 +- internet-draft-satp.txt | 2 +- internet-draft-satp.xml | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/internet-draft-satp.html b/internet-draft-satp.html index db03d1f..ee7278c 100644 --- a/internet-draft-satp.html +++ b/internet-draft-satp.html @@ -574,7 +574,7 @@ Security Considerations

5.1.  Replay protection

-

Replay protection is done by a replay list. Every anycast receiver has it's own replay list, which SOULDN'T be syncronised, because of massive overhead. This leads to an additional possible attack. A attacker is able to replay a captured packet once to every anycast reciever. This attack is considered of be very unlikely, because multiple attack hosts in different loactions are needed to reach the seperate anycast receivers and the number of replays is limited to the count of receivers - 1. Such replays might also happen because of routing problems, so a payload protocol HAS TO be robust against a small number of duplicated packages. The window size and position HAS TO be syncronised between multible anycast receivers to limit this attack. +

Replay protection is done by a replay list. Every anycast receiver has it's own replay list, which SHOULDN'T be syncronised, because of massive overhead. This leads to an additional possible attack. A attacker is able to replay a captured packet once to every anycast reciever. This attack is considered of be very unlikely, because multiple attack hosts in different loactions are needed to reach the seperate anycast receivers and the number of replays is limited to the count of receivers - 1. Such replays might also happen because of routing problems, so a payload protocol HAS TO be robust against a small number of duplicated packages. The window size and position HAS TO be syncronised between multible anycast receivers to limit this attack.


 TOC 
diff --git a/internet-draft-satp.txt b/internet-draft-satp.txt index 9209ff3..0772e90 100644 --- a/internet-draft-satp.txt +++ b/internet-draft-satp.txt @@ -626,7 +626,7 @@ Internet-Draft secure anycast tunneling protocol (SATP) April 2007 5.1. Replay protection Replay protection is done by a replay list. Every anycast receiver - has it's own replay list, which SOULDN'T be syncronised, because of + has it's own replay list, which SHOULDN'T be syncronised, because of massive overhead. This leads to an additional possible attack. A attacker is able to replay a captured packet once to every anycast reciever. This attack is considered of be very unlikely, because diff --git a/internet-draft-satp.xml b/internet-draft-satp.xml index 01f717c..7dca65d 100644 --- a/internet-draft-satp.xml +++ b/internet-draft-satp.xml @@ -270,7 +270,7 @@ HEX
As SATP uses the same encrytion technics as SRTP, it shares the same security issues. This section will only discuss some small changes. Please read SRTP RFC3711 section 9 for details.
- Replay protection is done by a replay list. Every anycast receiver has it's own replay list, which SOULDN'T be syncronised, because of massive overhead. This leads to an additional possible attack. A attacker is able to replay a captured packet once to every anycast reciever. This attack is considered of be very unlikely, because multiple attack hosts in different loactions are needed to reach the seperate anycast receivers and the number of replays is limited to the count of receivers - 1. Such replays might also happen because of routing problems, so a payload protocol HAS TO be robust against a small number of duplicated packages. The window size and position HAS TO be syncronised between multible anycast receivers to limit this attack. + Replay protection is done by a replay list. Every anycast receiver has it's own replay list, which SHOULDN'T be syncronised, because of massive overhead. This leads to an additional possible attack. A attacker is able to replay a captured packet once to every anycast reciever. This attack is considered of be very unlikely, because multiple attack hosts in different loactions are needed to reach the seperate anycast receivers and the number of replays is limited to the count of receivers - 1. Such replays might also happen because of routing problems, so a payload protocol HAS TO be robust against a small number of duplicated packages. The window size and position HAS TO be syncronised between multible anycast receivers to limit this attack.
-- cgit v1.2.3