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 provides advice on the filtering of IPv4 packets based
on the IPv4 options they contain. Additionally, it discusses the
operational and interoperability implications of dropping packets
based on the IP options they contain.

Recommendations on Filtering of IPv4 Packets Containing IPv4 Options

This document provides an Architectural description and the Concept of
Operations of some optional advanced deployment scenarios for the
Identifier-Locator Network Protocol (ILNP), which is an evolutionary
enhancement to IP. None of the functions described here is required
for the use or deployment of ILNP. Instead, it offers descriptions of
engineering and deployment options that might provide either enhanced
capability or convenience in administration or management of ILNP-
based systems. This document defines an Experimental Protocol for the
Internet community.

Optional Advanced Deployment Scenarios for the Identifier-Locator Network Protocol (ILNP)

This document describes how the National Institute of Standards and
Technology (NIST) Secure Hash Standard family of algorithms can be
used with OSPF version 2's built-in, cryptographic authentication
mechanism. This updates, but does not supercede, the cryptographic
authentication mechanism specified in RFC 2328. [STANDARDS-TRACK]

OSPFv2 HMAC-SHA Cryptographic Authentication

This note specifies an experimental ICMPv6 message type used with the
Identifier-Locator Network Protocol (ILNP). The Identifier-Locator
Network Protocol (ILNP) is an experimental, evolutionary enhancement
to IP. This message is used to dynamically update Identifier/Locator
bindings for an existing ILNP session. This is a product of the IRTF
Routing Research Group. This document defines an Experimental Protocol
for the Internet community.

ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv6 (ILNPv6)

An Identifier/Locator addressing scheme can enable a new approach to mobile hosts and mobile networks. Identifier and Locator information is stored in Domain Name System (DNS) Resource Records. In our on-going work using the Identifier-Locator Network Protocol (ILNP), the DNS would be updated with new Locator values as hosts and/or networks move; new sessions would obtain the correct Locator(s) for a mobile host and/or mobile network from the DNS, in much the same way as currently happens for IP address resolution. However, this use of the DNS is not currently required for IP mobility. We examine the potential impact on DNS from using a naming approach to mobility.

/pdf/mobility-through-naming-impact-on-dns-4ztc1rf38d.pdf

R. Atkinson

Papers

Recommendations on Filtering of IPv4 Packets Containing IPv4 Options

Optional Advanced Deployment Scenarios for the Identifier-Locator Network Protocol (ILNP)

OSPFv2 HMAC-SHA Cryptographic Authentication

ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv6 (ILNPv6)

Mobility through naming: impact on dns