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.xml | 27 +++++++++++++++++++++------ 1 file changed, 21 insertions(+), 6 deletions(-) (limited to 'internet-draft-satp.xml') diff --git a/internet-draft-satp.xml b/internet-draft-satp.xml index d657c48..db3a229 100644 --- a/internet-draft-satp.xml +++ b/internet-draft-satp.xml @@ -6,6 +6,7 @@ + ]> @@ -48,6 +49,9 @@
SATP is somehow a mixture of a generic encapsulation protocol like GRE and a secure tunneling protocol as IPsec in tunnel mode. To save some header overhead it uses the encryption technices of SRTP. 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 +
+ 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. +
This section gives an overview of possible usage scenarios. Please note, that the protocols used in the figures are only examples and that SATP itself does not care about either transport protocols or encapsulated protocols. Routing is not done by SATP and each implemetation MAY choose it's own way of doing this task (e.g. using functions provided by the operating system). SATP is used only to encapsulate and encrypt data. @@ -115,7 +119,7 @@ Network A has multiple routers, that act as gateway/tunnel endpoints to another network B. This is done to build a redundant encrypted tunnel connection between the two networks. All tunnel endpoints of network A share the same anycast address and all tunnel endpoints of network B share another anycast address. When a packet from network A gets transmitted to network B, it first arrives on one of network A's border routers. Which router is used is determined by network A's internal routing. This router encapsulates the package and sends it to the anycast address of the network B routers. The SATP packet arrives at one of network B's routers and gets decapsulated and routed to it's destination within network B.
- +
SATP does not depend on which lower layer protocols is used, but it's most likely used on top of IP or UDP. This section should only discuss some issues on IP and UDP in combination with anycasting and tunnels. @@ -157,12 +161,14 @@ Tunneling of IPv6 over IPv4 with RTP payload When using UDP no flow control or retransmission is done, neither by UDP nor anytun. The encapsulated protocol HAS TO take care of this tasks if needed. UDP however has a checksum of the complete UDP datagram, so a packet gets discarded if there is a biterror in the 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.
-
+
@@ -223,16 +229,25 @@ HEX
- Encryption is done in the same way as for SRTP. This section will only discuss some small changes that HAVE TO be made. + Encryption is done in the same way as for SRTP. This section will only discuss some small changes that HAVE TO be made. Please read SRTP RFC3711 section 3-9 for details. SSRC is replaced by the sender ID
+
+
+ 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. +
- + + &rfc3711; + &rfc2119; + + &rfc2784; &rfc2401; - &rfc3711; &rfc1546; - + -- cgit v1.2.3