From 169ee1d383222d745d7f1ec76b2010c7a19807a7 Mon Sep 17 00:00:00 2001 From: Othmar Gsenger Date: Mon, 18 Jun 2007 16:17:27 +0000 Subject: I-D anytun some typos --- internet-draft-satp.txt | 28 ++++++++++++++-------------- internet-draft-satp.xml | 14 +++++++------- 2 files changed, 21 insertions(+), 21 deletions(-) diff --git a/internet-draft-satp.txt b/internet-draft-satp.txt index c0ce3e9..4fa19e3 100644 --- a/internet-draft-satp.txt +++ b/internet-draft-satp.txt @@ -89,10 +89,10 @@ Table of Contents 4.3. sequence number . . . . . . . . . . . . . . . . . . . . . 9 4.4. payload . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.5. padding (OPTIONAL) . . . . . . . . . . . . . . . . . . . . 9 - 4.6. padding count . . . . . . . . . . . . . . . . . . . . . . 10 + 4.6. padding count (OPTIONAL) . . . . . . . . . . . . . . . . . 10 4.7. payload type field . . . . . . . . . . . . . . . . . . . . 10 - 4.7.1. MKI . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 4.7.2. authentication tag . . . . . . . . . . . . . . . . . . 10 + 4.7.1. MKI (OPTIONAL) . . . . . . . . . . . . . . . . . . . . 10 + 4.7.2. authentication tag (RECOMMENDED) . . . . . . . . . . . 10 4.8. Encryption . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5.1. Replay protection . . . . . . . . . . . . . . . . . . . . 12 @@ -406,8 +406,9 @@ Internet-Draft secure anycast tunneling protocol (SATP) June 2007 to occure very frequently, the encapsulated protocol can do a retransmission and all fragments will arrive at the new server. - If the payload ip headers's Don't Fragment (DF) bit is set, than the - DF bit of the outer ip header HAS TO be set as well. + If the payload type is IP and the ip headers's Don't Fragment (DF) + bit is set, than the DF bit of the outer IP header HAS TO be set as + well. 3.2. ICMP messages @@ -441,7 +442,6 @@ Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - Gsenger Expires December 20, 2007 [Page 8] @@ -505,11 +505,11 @@ Gsenger Expires December 20, 2007 [Page 9] Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - format, so a RTP like padding is supported. If padding field is - present, than the padding count field MUST be set to the padding - lenght. + 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. -4.6. padding count +4.6. padding count (OPTIONAL) 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 @@ -534,12 +534,12 @@ Internet-Draft secure anycast tunneling protocol (SATP) June 2007 Figure 6 -4.7.1. MKI +4.7.1. MKI (OPTIONAL) The MKI (Master Key Identifier) is OPTIONAL and of configurable length. See SRTP Section 3.1 [1] for details -4.7.2. authentication tag +4.7.2. authentication tag (RECOMMENDED) The authentication tag is RECOMMENDED and of configurable length. It contains a cryptographic checksum of the sender ID, sequence number @@ -629,7 +629,7 @@ Internet-Draft secure anycast tunneling protocol (SATP) June 2007 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 + 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 @@ -676,7 +676,7 @@ Internet-Draft secure anycast tunneling protocol (SATP) June 2007 6. IANA Considerations The protocol is intended to be used on top of IP or on top of UDP (to - be compatible with NAT routers), so UDP and IP protocol numberes have + be compatible with NAT routers), so UDP and IP protocol numbers have to be assiged by IANA. diff --git a/internet-draft-satp.xml b/internet-draft-satp.xml index 9b65f16..83886c2 100644 --- a/internet-draft-satp.xml +++ b/internet-draft-satp.xml @@ -167,7 +167,7 @@ Tunneling of IPv6 over IPv4 with RTP payload
The only way of fully supporting fragmentation would be to synchronise fragments between all anycast servers. This is considered to be too much overhead, so there are two non perfect solutions for these problems. Either fragmentation HAS TO be disabled or if not all fragments arrive at the same server the ip datagramm HAS TO be discarded. As routing changes are not expected to occure very frequently, the encapsulated protocol can do a retransmission and all fragments will arrive at the new server. - If the payload ip headers's Don't Fragment (DF) bit is set, than the DF bit of the outer ip header HAS TO be set as well. + If the payload type is IP and the ip headers's Don't Fragment (DF) bit is set, than the DF bit of the outer IP header HAS TO be set as well.
ICMP messages MUST be relayed according to rfc2003 section 4. This is needed for path MTU detection. @@ -211,9 +211,9 @@ Tunneling of IPv6 over IPv4 with RTP payload
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 padding 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 lenght.
-
+
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.
@@ -230,10 +230,10 @@ HEX 86DD IPv6 -
+
The MKI (Master Key Identifier) is OPTIONAL and of configurable length. See SRTP Section 3.1 for details
-
+
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.
@@ -270,11 +270,11 @@ 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 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. + 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.
- The protocol is intended to be used on top of IP or on top of UDP (to be compatible with NAT routers), so UDP and IP protocol numberes have to be assiged by IANA. + The protocol is intended to be used on top of IP or on top of UDP (to be compatible with NAT routers), so UDP and IP protocol numbers have to be assiged by IANA.
-- cgit v1.2.3