diff options
| -rw-r--r-- | internet-draft-satp.html | 2 | ||||
| -rw-r--r-- | internet-draft-satp.txt | 2 | ||||
| -rw-r--r-- | 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</h3> <a name="rfc.section.5.1"></a><h3>5.1. Replay protection</h3> -<p>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. +<p>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. </p> <a name="anchor25"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> 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 <section title="Security Considerations"> <t>As SATP uses the same encrytion technics as <xref target="RFC3711">SRTP</xref>, it shares the same security issues. This section will only discuss some small changes. Please read <xref target="RFC3711">SRTP RFC3711 section 9</xref> for details.</t> <section title="Replay protection"> - <t>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.</t> + <t>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.</t> </section> </section> <section title="IANA Considerations"> |