From 363fbc6ae3ce73f35a9c845d756034991f06e8be Mon Sep 17 00:00:00 2001 From: Othmar Gsenger Date: Wed, 23 Jan 2008 15:25:48 +0000 Subject: new draft --- ...senger-secure-anycast-tunneling-protocol-01.xml | 31 ++++++++++++---------- 1 file changed, 17 insertions(+), 14 deletions(-) (limited to 'draft-gsenger-secure-anycast-tunneling-protocol-01.xml') diff --git a/draft-gsenger-secure-anycast-tunneling-protocol-01.xml b/draft-gsenger-secure-anycast-tunneling-protocol-01.xml index 92183db..68c0a4b 100644 --- a/draft-gsenger-secure-anycast-tunneling-protocol-01.xml +++ b/draft-gsenger-secure-anycast-tunneling-protocol-01.xml @@ -202,23 +202,15 @@ Tunneling of IPv6 over IPv4 with RTP payload - -
- The sender ID is a 16 bit unsigned integer. It HAS TO be unique for every sender sharing the same anycast address
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.
-
- A packet of the type payload type (e.g. an IP packet). -
-
- 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. +
+ The sender ID is a 16 bit unsigned integer. It HAS TO be unique for every sender sharing the same anycast address
-
- 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. +
+ The MUX (multiplex) field is a 16 bit unsigned integer. It is used to destinguish multible tunnel connections.
The payload type field defines the payload protocol. ETHER TYPE protocol numbers are used. See IANA assigned ethernet numbers . The values 0000-05DC are reserverd and MUST NOT be used. @@ -234,14 +226,25 @@ HEX 86DD IPv6 + +
+
+ A packet of the type payload type (e.g. an IP packet). +
+
+ 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. +
+
+ 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. +
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.
- -
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. 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.
-- cgit v1.2.3