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

Challenges face the Internet Architecture in order to scale to a greater number of users while providing a suite of increasingly essential functionality, such as multi-homing, traffic engineering, mobility, localised addressing and end-to-end packet-level security. Such functions have been designed and implemented mainly in isolation and retrofitted to the original Internet architecture. The resulting engineering complexity has caused some to think of 'clean slate' designs for the long-term future. Meanwhile, we take the position that an evolutionary approach is possible for a practical and scaleable interim solution, giving much of the functionality required, being backwards compatible with the currently deployed architecture, with incremental deployment capability, and which can reduce the current routing state overhead for the core network. By enhancing the way we use naming in the Internet Architecture, it is possible to provide a harmonised approach to multi-homing, traffic engineering, mobility, localised addressing and end-to-end packet-level security, including specific improvement to the scalability of inter-domain routing, and have these functions co-exist harmoniously with reduced engineering complexity. A set of proposed enhancements to the current Internet Architecture, based on naming, are described and analysed, both in terms of architectural changes and engineering practicalities.

/pdf/evolving-the-internet-architecture-through-naming-2gzpm7t1y5.pdf

Evolving the Internet Architecture Through Naming

Growth in the Internet has made us aware of the need for improved
authentication of routing information. RIP-2 provides for
unauthenticated service (as in classical RIP), or password
authentication. [STANDARDS-TRACK]

RIP-2 MD5 Authentication

This document describes common (i.e., version independent) engineering
details for the Identifier-Locator Network Protocol (ILNP), which is
an experimental, evolutionary enhancement to IP. This document is a
product of the IRTF Routing Research Group. This document defines an
Experimental Protocol for the Internet community.

Identifier-Locator Network Protocol (ILNP) Engineering Considerations

This document describes the authentication of Intermediate System to Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms.

/pdf/intermediate-system-to-intermediate-system-is-is-77eixkvrw1.pdf

Intermediate System to Intermediate System (IS-IS)

This note describes additional optional resource records for use with
the Domain Name System (DNS). These optional resource records are for
use with the Identifier-Locator Network Protocol (ILNP). This document
is a product of the IRTF Routing Research Group. This document defines
an Experimental Protocol for the Internet community.

/pdf/dns-resource-records-for-the-identifier-locator-network-54e7mzwrkb.pdf

R. Atkinson

Papers

Evolving the Internet Architecture Through Naming

RIP-2 MD5 Authentication

Identifier-Locator Network Protocol (ILNP) Engineering Considerations

Intermediate System to Intermediate System (IS-IS)

DNS Resource Records for the Identifier-Locator Network Protocol (ILNP)