From 6c9fac3bb2fac2e69458ea9f1d66c20b596acf24 Mon Sep 17 00:00:00 2001 From: Othmar Gsenger Date: Thu, 26 Apr 2007 21:29:25 +0000 Subject: must --- internet-draft-satp.txt | 238 +++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 203 insertions(+), 35 deletions(-) (limited to 'internet-draft-satp.txt') diff --git a/internet-draft-satp.txt b/internet-draft-satp.txt index 2cd33d1..4292da6 100644 --- a/internet-draft-satp.txt +++ b/internet-draft-satp.txt @@ -116,17 +116,17 @@ Internet-Draft secure anycast tunneling protocol (satp) March 2007 1. Introduction SATP is somehow a mixture of a generic encapsulation protocol like - GRE [1] and a secure tunneling protocol as IPsec [2] in tunnel mode. + GRE [3] and a secure tunneling protocol as IPsec [4] in tunnel mode. To save some header overhead it uses the encryption technices of SRTP - [3]. It supports peer to peer tunnels, where tunnel endpoints can be + [1]. It supports peer to peer tunnels, where tunnel endpoints can be any combination of unicast, multicast or anycast hosts, so it defines - a Host Anycast Service [4] - - - - + a Host Anycast Service [5] +1.1. Notational Conventions + The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC2119 [2]. @@ -345,7 +345,57 @@ Internet-Draft secure anycast tunneling protocol (satp) March 2007 datagram, so a packet gets discarded if there is a biterror in the payload -2.3. Fragmentation + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gsenger Expires September 2, 2007 [Page 7] + +Internet-Draft secure anycast tunneling protocol (satp) March 2007 + + +3. Using SATP on top of IP + +3.1. Fragmentation The only way of fully supporting fragmentation would be to synchronise fragments between all anycast servers. This is @@ -388,14 +438,20 @@ Internet-Draft secure anycast tunneling protocol (satp) March 2007 -Gsenger Expires September 2, 2007 [Page 7] + + + + + + +Gsenger Expires September 2, 2007 [Page 8] Internet-Draft secure anycast tunneling protocol (satp) March 2007 -3. Protocol specification +4. Protocol specification -3.1. Header format +4.1. Header format Protocol Format @@ -419,23 +475,23 @@ Internet-Draft secure anycast tunneling protocol (satp) March 2007 Figure 5 -3.2. sender ID +4.2. sender ID The sender ID is a 16bit unsigned integer. It HAS TO be unique for every sender sharing the same anycast address -3.3. sequence number +4.3. sequence number The sequence number is a 32 bit unsigned integer in network byte order. It starts with a random value and is increased by 1 for every sent packet. After the maximum value, it starts over from 0. This overrun causes the ROC to be increased. -3.4. payload +4.4. payload A packet of the type payload type (e.g. an IP packet). -3.5. padding (OPTIONAL) +4.5. padding (OPTIONAL) Padding of max 255 octets. None of the pre-defined encryption transforms uses any padding; for these, the plaintext and encrypted @@ -444,7 +500,7 @@ Internet-Draft secure anycast tunneling protocol (satp) March 2007 -Gsenger Expires September 2, 2007 [Page 8] +Gsenger Expires September 2, 2007 [Page 9] Internet-Draft secure anycast tunneling protocol (satp) March 2007 @@ -453,17 +509,17 @@ Internet-Draft secure anycast tunneling protocol (satp) March 2007 present, than the padding count field MUST be set to the padding lenght. -3.6. padding count +4.6. padding count 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. -3.7. payload type field +4.7. payload type field The payload type field defines the payload protocol. ETHER TYPE - protocol numbers are used. See IANA assigned ethernet numbers [5] . + protocol numbers are used. See IANA assigned ethernet numbers [6] . The values 0000-05DC are reserverd and MUST NOT be used. Some examples for protocol types @@ -478,10 +534,15 @@ Internet-Draft secure anycast tunneling protocol (satp) March 2007 Figure 6 -3.8. Encryption +4.8. Encryption + + Encryption is done in the same way as for SRTP [1]. This section + will only discuss some small changes that HAVE TO be made. Please + read SRTP RFC3711 section 3-9 [1] for details. SSRC is replaced by + the sender ID + + - Encryption is done in the same way as for SRTP [3]. This section - will only discuss some small changes that HAVE TO be made. @@ -495,32 +556,89 @@ Internet-Draft secure anycast tunneling protocol (satp) March 2007 +Gsenger Expires September 2, 2007 [Page 10] + +Internet-Draft secure anycast tunneling protocol (satp) March 2007 +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 + changes. Please read SRTP RFC3711 section 9 [1] for details. +5.1. Replay protection -Gsenger Expires September 2, 2007 [Page 9] + 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gsenger Expires September 2, 2007 [Page 11] Internet-Draft secure anycast tunneling protocol (satp) March 2007 -4. References +6. References - [1] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, - "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. - - [2] Kent, S. and R. Atkinson, "Security Architecture for the - Internet Protocol", RFC 2401, November 1998. +6.1. Normative References - [3] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. + [1] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. - [4] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting + [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + +6.2. Informational References + + [3] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, + "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. + + [4] Kent, S. and R. Atkinson, "Security Architecture for the + Internet Protocol", RFC 2401, November 1998. + + [5] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993. - [5] @@ -549,14 +667,64 @@ Internet-Draft secure anycast tunneling protocol (satp) March 2007 + +Gsenger Expires September 2, 2007 [Page 12] + +Internet-Draft secure anycast tunneling protocol (satp) March 2007 +URIs + [6] -Gsenger Expires September 2, 2007 [Page 10] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gsenger Expires September 2, 2007 [Page 13] Internet-Draft secure anycast tunneling protocol (satp) March 2007 @@ -612,7 +780,7 @@ Author's Address -Gsenger Expires September 2, 2007 [Page 11] +Gsenger Expires September 2, 2007 [Page 14] Internet-Draft secure anycast tunneling protocol (satp) March 2007 @@ -668,5 +836,5 @@ Acknowledgment -Gsenger Expires September 2, 2007 [Page 12] +Gsenger Expires September 2, 2007 [Page 15] -- cgit v1.2.3