PROBLEM TO BE SOLVED: To solve the problem, wherein it is impossible for an electronic content information provider to provide commercially secure and effective method, for a configurable general-purpose electronic commercial transaction/distribution control system. SOLUTION: In this system, having at least one protected processing environment for safely controlling at least one portion of decoding of digital information, a secure content distribution method comprises a process for encapsulating digital information in one or more digital containers; a process for encrypting at least a portion of digital information; a process for associating at least partially secure control information for managing interactions with encrypted digital information and/or digital container; a process for delivering one or more digital containers to a digital information user; and a process for using a protected processing environment, for safely controlling at least a portion of the decoding of the digital information. COPYRIGHT: (C)2006,JPO&NCIPI

https://apps.dtic.mil/dtic/tr/fulltext/u2/a423264.pdf

Systems and Methods for Secure Transaction Management and Electronic Rights Protection

This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of-service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers.

/pdf/rtp-a-transport-protocol-for-real-time-applications-4rr13zq7f5.pdf

RTP: A Transport Protocol for Real-Time Applications

This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences.

/pdf/sip-session-initiation-protocol-1aatf18r7a.pdf

SIP: Session Initiation Protocol

This document describes an updated version of the "Security
Architecture for IP", which is designed to provide security services
for traffic at the IP layer. This document obsoletes RFC 2401
(November 1998). [STANDARDS-TRACK]

/pdf/security-architecture-for-the-internet-protocol-1x2l107p1d.pdf

Security Architecture for the Internet Protocol

Low-Power and Lossy Networks (LLNs) are a class of network in which
both the routers and their interconnect are constrained. LLN routers
typically operate with constraints on processing power, memory, and
energy (battery power). Their interconnects are characterized by high
loss rates, low data rates, and instability. LLNs are comprised of
anything from a few dozen to thousands of routers. Supported traffic
flows include point-to-point (between devices inside the LLN), point-
to-multipoint (from a central control point to a subset of devices
inside the LLN), and multipoint-to-point (from devices inside the LLN
towards a central control point). This document specifies the IPv6
Routing Protocol for Low-Power and Lossy Networks (RPL), which
provides a mechanism whereby multipoint-to-point traffic from devices
inside the LLN towards a central control point as well as point-to-
multipoint traffic from the central control point to the devices
inside the LLN are supported. Support for point-to-point traffic is
also available. [STANDARDS-TRACK]

/pdf/rpl-ipv6-routing-protocol-for-low-power-and-lossy-networks-59sbz5ta0b.pdf

RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks

This document describes an updated version of the Encapsulating
Security Payload (ESP) protocol, which is designed to provide a mix of
security services in IPv4 and IPv6. ESP is used to provide
confidentiality, data origin authentication, connectionless integrity,
an anti-replay service (a form of partial sequence integrity), and
limited traffic flow confidentiality. This document obsoletes RFC 2406
(November 1998). [STANDARDS-TRACK]

IP Encapsulating Security Payload (ESP)

This document describes an updated version of the IP Authentication
Header (AH), which is designed to provide authentication services in
IPv4 and IPv6. This document obsoletes RFC 2402 (November 1998).
[STANDARDS-TRACK]

IP Authentication Header

This document provides an architectural description and the concept of
operations for the Identifier-Locator Network Protocol (ILNP), which
is an experimental, evolutionary enhancement to IP. This is a product
of the IRTF Routing Research Group. This document defines an
Experimental Protocol for the Internet community.

Identifier-Locator Network Protocol (ILNP) Architectural Description

Internet users seek solutions for mobility, multi-homing, support for localised address management (i.e. via NATs), and end-to-end security. Existing mobility approaches are not well integrated into the rest of the Internet architecture, instead primarily being separate extensions that at present are not widely deployed. Because the current approaches to these issues were developed separately, such approaches often are not harmonious when used together. Meanwhile, the Internet has a number of namespaces, for example the IP address or the Domain Name. In recent years, some have postulated that the Internet's namespaces are not sufficiently rich and that the current concept of an address is too limiting. One proposal, the concept of separating an address into an Identifier and a separate Locator, has been controversial in the Internet community for years. It has been considered within the IETF and IRTF several times, but always was rejected as unworkable. This paper takes the position that evolving the naming in the Internet by splitting the address into separate Identifier and Locator names can provide an elegant integrated solution to the key issues listed above, without changing the core routing architecture, while offering incremental deployability through backwards compatibility with IPv6.

/pdf/ilnp-mobility-multi-homing-localised-addressing-and-security-1ul3ixtt9k.pdf

R. Atkinson

Papers

Security Architecture for the Internet Protocol

IP Encapsulating Security Payload (ESP)

IP Authentication Header

Identifier-Locator Network Protocol (ILNP) Architectural Description

ILNP: mobility, multi-homing, localised addressing and security through naming