fixed some typos @ internet draft

3 files changed, 16 insertions, 16 deletions

diff --git a/draft-gsenger-secure-anycast-tunneling-protocol-02.html b/draft-gsenger-secure-anycast-tunneling-protocol-02.html
index 8b5e98d..80ab6c9 100644
--- a/draft-gsenger-secure-anycast-tunneling-protocol-02.html
+++ b/draft-gsenger-secure-anycast-tunneling-protocol-02.html
@@ -299,7 +299,7 @@ Tunneling from unicast hosts over anycast routers to other unicast hosts</h3>
   endpoint | using SATP    |  endpoint | using SATP    |  endpoint
 </pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b>&nbsp;Figure&nbsp;1&nbsp;</b></font><br /></td></tr></table><hr class="insert" />
 
-<p>In this scenario the payload gets encapsuleted into a SATP packet by a unicast host and gets transmitted to one of the anycast routers. It than gets decapsulated by the router. This router makes a routing descision based on the underlying protocol and transmits a new SATP package to one or more unicast hosts depending on the routing descition.
+<p>In this scenario the payload gets encapsuleted into a SATP packet by a unicast host and gets transmitted to one of the anycast routers. It than gets decapsulated by the router. This router makes a routing descision based on the underlying protocol and transmits a new SATP package to one or more unicast hosts depending on the routing decision.
 </p>
 <a name="anchor6"></a><br /><hr />
 <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
@@ -516,7 +516,7 @@ padding (OPTIONAL)</h3>
 
 <p>Padding of max 255 octets.
 None of the pre-defined encryption transforms uses any padding; for
-   these, the plaintext and encrypted payload sizes match exactly. Transforms are based on transforms of the SRTP protocol and these transforms might use the RTP padding format, so a RTP like padding is supported. If the padding count field is present, than the padding count field MUST be set to the padding lenght.
+   these, the plaintext and encrypted payload sizes match exactly. Transforms are based on transforms of the SRTP protocol and these transforms might use the RTP padding format, so a RTP like padding is supported. If the padding count field is present, than the padding count field MUST be set to the padding length.
 </p>
 <a name="anchor20"></a><br /><hr />
 <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
@@ -546,7 +546,7 @@ Encryption</h3>
 
 <p>Encryption is done in the same way as for <a class='info' href='#RFC3711'>SRTP<span> (</span><span class='info'>Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, &ldquo;The Secure Real-time Transport Protocol (SRTP),&rdquo; March&nbsp;2004.</span><span>)</span></a> [1]. This section will only discuss some small changes that HAVE TO be made. Please read  <a class='info' href='#RFC3711'>SRTP RFC3711 section 3-9<span> (</span><span class='info'>Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, &ldquo;The Secure Real-time Transport Protocol (SRTP),&rdquo; March&nbsp;2004.</span><span>)</span></a> [1] for details. 
 </p>
-<p>The least significant bits of SSRC are replaced by the sender ID and the rest is filled with zeros. For the SRTP SEQ the 16 least significant bits of the SATP sequence number are used and the 16 most significant bits of the sequence number replace the 16 least significant bits of the SRTP ROC.
+<p>The least significant bits of SSRC are replaced by the sender ID and the most significant bits are replaced by the mux. For the SRTP SEQ the 16 least significant bits of the SATP sequence number are used and the 16 most significant bits of the sequence number replace the 16 least significant bits of the SRTP ROC.
 </p><br /><hr class="insert" />
 <a name="srtp_vs_satp"></a>
 
@@ -579,7 +579,7 @@ Encryption</h3>
 <a name="rfc.section.5"></a><h3>5.&nbsp;
 Security Considerations</h3>
 
-<p>As SATP uses the same encrytion technics as <a class='info' href='#RFC3711'>SRTP<span> (</span><span class='info'>Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, &ldquo;The Secure Real-time Transport Protocol (SRTP),&rdquo; March&nbsp;2004.</span><span>)</span></a> [1], it shares the same security issues. This section will only discuss some small changes. Please read  <a class='info' href='#RFC3711'>SRTP RFC3711 section 9<span> (</span><span class='info'>Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, &ldquo;The Secure Real-time Transport Protocol (SRTP),&rdquo; March&nbsp;2004.</span><span>)</span></a> [1] for details.
+<p>As SATP uses the same encryption techniques as <a class='info' href='#RFC3711'>SRTP<span> (</span><span class='info'>Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, &ldquo;The Secure Real-time Transport Protocol (SRTP),&rdquo; March&nbsp;2004.</span><span>)</span></a> [1], it shares the same security issues. This section will only discuss some small changes. Please read  <a class='info' href='#RFC3711'>SRTP RFC3711 section 9<span> (</span><span class='info'>Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, &ldquo;The Secure Real-time Transport Protocol (SRTP),&rdquo; March&nbsp;2004.</span><span>)</span></a> [1] for details.
 </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">&nbsp;TOC&nbsp;</a></td></tr></table>
diff --git a/draft-gsenger-secure-anycast-tunneling-protocol-02.txt b/draft-gsenger-secure-anycast-tunneling-protocol-02.txt
index 994847f..0a63c6f 100644
--- a/draft-gsenger-secure-anycast-tunneling-protocol-02.txt
+++ b/draft-gsenger-secure-anycast-tunneling-protocol-02.txt
@@ -204,7 +204,7 @@ Internet-Draft  secure anycast tunneling protocol (SATP)    January 2008
    It than gets decapsulated by the router.  This router makes a routing
    descision based on the underlying protocol and transmits a new SATP
    package to one or more unicast hosts depending on the routing
-   descition.
+   decision.
 
 
 
@@ -535,7 +535,7 @@ Internet-Draft  secure anycast tunneling protocol (SATP)    January 2008
    the SRTP protocol and these transforms might use the RTP padding
    format, so a RTP like padding is supported.  If the padding count
    field is present, than the padding count field MUST be set to the
-   padding lenght.
+   padding length.
 
 4.8.  padding count (OPTIONAL)
 
@@ -573,10 +573,10 @@ Internet-Draft  secure anycast tunneling protocol (SATP)    January 2008
    read SRTP RFC3711 section 3-9 [1] for details.
 
    The least significant bits of SSRC are replaced by the sender ID and
-   the rest is filled with zeros.  For the SRTP SEQ the 16 least
-   significant bits of the SATP sequence number are used and the 16 most
-   significant bits of the sequence number replace the 16 least
-   significant bits of the SRTP ROC.
+   the most significant bits are replaced by the mux.  For the SRTP SEQ
+   the 16 least significant bits of the SATP sequence number are used
+   and the 16 most significant bits of the sequence number replace the
+   16 least significant bits of the SRTP ROC.
 
    Difference between SRTP and SATP
 
@@ -619,8 +619,8 @@ Internet-Draft  secure anycast tunneling protocol (SATP)    January 2008
 
 5.  Security Considerations
 
-   As SATP uses the same encrytion technics as SRTP [1], it shares the
-   same security issues.  This section will only discuss some small
+   As SATP uses the same encryption techniques as SRTP [1], it shares
+   the same security issues.  This section will only discuss some small
    changes.  Please read SRTP RFC3711 section 9 [1] for details.
 
 5.1.  Replay protection
diff --git a/draft-gsenger-secure-anycast-tunneling-protocol-02.xml b/draft-gsenger-secure-anycast-tunneling-protocol-02.xml
index 4b76189..f9ec30d 100644
--- a/draft-gsenger-secure-anycast-tunneling-protocol-02.xml
+++ b/draft-gsenger-secure-anycast-tunneling-protocol-02.xml
@@ -76,7 +76,7 @@
   endpoint | using SATP    |  endpoint | using SATP    |  endpoint 
                  </artwork>
        </figure>
-	      <t>In this scenario the payload gets encapsuleted into a SATP packet by a unicast host and gets transmitted to one of the anycast routers. It than gets decapsulated by the router. This router makes a routing descision based on the underlying protocol and transmits a new SATP package to one or more unicast hosts depending on the routing descition.</t> 
+	      <t>In this scenario the payload gets encapsuleted into a SATP packet by a unicast host and gets transmitted to one of the anycast routers. It than gets decapsulated by the router. This router makes a routing descision based on the underlying protocol and transmits a new SATP package to one or more unicast hosts depending on the routing decision.</t> 
 	    </section>
 
 	    <section title='Tunneling from unicast hosts to anycast networks'>
@@ -234,7 +234,7 @@ HEX
        <section title="padding (OPTIONAL)">
        <t>Padding of max 255 octets.
 None of the pre-defined encryption transforms uses any padding; for
-   these, the plaintext and encrypted payload sizes match exactly. Transforms are based on transforms of the SRTP protocol and these transforms might use the RTP padding format, so a RTP like padding is supported. If the padding count field is present, than the padding count field MUST be set to the padding lenght.</t>
+   these, the plaintext and encrypted payload sizes match exactly. Transforms are based on transforms of the SRTP protocol and these transforms might use the RTP padding format, so a RTP like padding is supported. If the padding count field is present, than the padding count field MUST be set to the padding length.</t>
        </section>
        <section title="padding count (OPTIONAL)">
        <t>The number of octets of the padding field. This field is optional. It's presence is signaled by the key management and not by this protocol. If this field isn't present, the padding field MUST NOT be present as well.</t>
@@ -246,7 +246,7 @@ None of the pre-defined encryption transforms uses any padding; for
 	<t>The authentication tag is RECOMMENDED and of configurable length. It contains a cryptographic checksum of the sender ID, sequence number and the encrypted portion, but not of the MKI. On sender side encryption HAS TO be done before calculating the authentication tag. A receiver HAS TO calculate the authentication tag before decrypting the encrypted portion.</t>
 	</section>
     <section title="Encryption">
-     <t>Encryption is done in the same way as for <xref target="RFC3711">SRTP</xref>. This section will only discuss some small changes that HAVE TO be made. Please read  <xref target="RFC3711">SRTP RFC3711 section 3-9</xref> for details. </t><t>The least significant bits of SSRC are replaced by the sender ID and the rest is filled with zeros. For the SRTP SEQ the 16 least significant bits of the SATP sequence number are used and the 16 most significant bits of the sequence number replace the 16 least significant bits of the SRTP ROC.</t>
+     <t>Encryption is done in the same way as for <xref target="RFC3711">SRTP</xref>. This section will only discuss some small changes that HAVE TO be made. Please read  <xref target="RFC3711">SRTP RFC3711 section 3-9</xref> for details. </t><t>The least significant bits of SSRC are replaced by the sender ID and the most significant bits are replaced by the mux. For the SRTP SEQ the 16 least significant bits of the SATP sequence number are used and the 16 most significant bits of the sequence number replace the 16 least significant bits of the SRTP ROC.</t>
    <figure anchor="srtp_vs_satp">
       <preamble>Difference between SRTP and SATP</preamble>
       <artwork>
@@ -275,7 +275,7 @@ None of the pre-defined encryption transforms uses any padding; for
     </section>
   </section>
     <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>
+     <t>As SATP uses the same encryption techniques 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 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 receiver. 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>