Protocol Action: 'SEcure Neighbor Discovery (SEND)' to Proposed Standard

2004-08-10 Thread The IESG
The IESG has approved the following document:

- 'SEcure Neighbor Discovery (SEND) '
as a Proposed Standard

This document is the product of the Securing Neighbor Discovery Working 
Group. 

The IESG contact persons are Margaret Wasserman and Thomas Narten.

Technical Summary

IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover
other nodes on the link, to determine the link-layer addresses of
other nodes on the link, to find routers, and to maintain
reachability information about the paths to active neighbors.  If not
secured, NDP is vulnerable to various attacks.  This document
specifies security mechanisms for NDP.  Unlike the original NDP
specifications, these mechanisms do not make use of IPsec.

Working Group Summary

The only major issue in the WG about this document was that both
Microsoft and Ericsson declared that they had IPR on CGA technology.
This issue was resolved after license conditions agreeable to the
WG participants and suited for public domain software were posted by
the respective companies. Before this, the WG briefly investigated an
alternative that would have required the configuration of hosts with
certificates, which might have resulted in deployment problems.

Another significant issue in the WG focused around the design of the
protocol and whether it should be based on IPsec AH or stand on its
own. After documenting the alternatives and comparing their pros and
cons, the consensus of the WG was to use an ND options based approach
instead of IPsec. The benefits of this were lack of impact on IPsec
architecture and implementations, and better ability to make security
decisions based on application state. This is important, for instance,
for co-existence of SEND and insecure ND on the same link.

A minor issue involved how to represent the authorization for routers to
route a certain prefix. The WG originally favored attribute certificates,
but since the PKIX WG was planning on defining an identity certificate
extension for this purpose, the WG decided to go with the IP address
range extension in draft-ietf-pkix-x509-ipaddr-as-extn-03.txt. Note that
this constructs a normative dependence on that draft, and it would be
helpful if we could get that draft to advance as quickly as possible
(or alterntively figure out a way to remove the normative dependence)
since there is a market window on how long before it becomes too late
for SEND to achieve widespread deployment, and having an officially
published RFC is important for implementors.

Protocol Quality

The basic protocol design has been implemented on Linux.  That
 implementation was used to fine tune the design, and the results of the 
fine tuning went into the final draft.

This document was reviewed for the IESG by Margaret Wasserman.


___
IETF-Announce mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf-announce


Protocol Action: 'Diameter Network Access Server Application' to Proposed Standard

2004-08-10 Thread The IESG
The IESG has approved the following document:

- 'Diameter Network Access Server Application '
as a Proposed Standard

This document is the product of the Authentication, Authorization and 
Accounting Working Group. 

The IESG contact persons are Bert Wijnen and David Kessens.

Technical Summary
 
   This document describes the Diameter protocol application used for
   Authentication, Authorization and Accounting (AAA) services in the
   Network Access Server (NAS) environment. This application
   specification, when combined with the Diameter Base protocol,
   Transport Profile, and Extensible Authentication  Protocol
   specifications, satisfies typical network access services
   requirements.

   Initial deployments of the Diameter protocol are expected to include
   legacy systems. Therefore, this application was carefully designed to
   ease the burden of protocol conversion between RADIUS and Diameter.
   This is achieved by including the RADIUS attribute space, and
   eliminating the need to perform many attribute translations.
 
Working Group Summary
 
   This document is the product of the aaa working group, and had wg
   consensuus.  Comments in IETF last call were addressed by the current
   document.
 
Protocol Quality
 
   This document was reviewed for the IESG by Randy Bush and Bert Wijnen


___
IETF-Announce mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf-announce


Protocol Action: 'Routing Policy Specification Language next generation (RPSLng)' to Proposed Standard

2004-08-10 Thread The IESG
The IESG has approved the following document:

- 'Routing Policy Specification Language next generation (RPSLng) '
as a Proposed Standard

This document has been reviewed in the IETF but is not the product of an
IETF Working Group. 

The IESG contact person is Bert Wijnen.

Technical Summary
 
 This memo presents a new set of simple extensions to the Routing
 Policy Specification Language (RPSL) enabling the language to also
 document routing policies for the IPv6 and multicast address families
 currently used in the Internet.
 
Working Group Summary
 
 This document is an AD sponsored document.
 The document was reviewed and worked on on a public mailing list
 ([EMAIL PROTECTED]).  

Protocol Quality
 
 This document was reviewed by Bert Wijnen for the IESG.


___
IETF-Announce mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf-announce


Protocol Action: 'UDP Encapsulation of IPsec Packets' to Proposed Standard

2004-08-10 Thread The IESG
The IESG has approved the following document:

- 'UDP Encapsulation of IPsec Packets '
as a Proposed Standard

This document is the product of the IP Security Protocol Working Group. 

The IESG contact persons are Russ Housley and Steve Bellovin.

Technical Summary

  This protocol specification defines methods to encapsulate and
  decapsulate IPsec Encapsulating Security Payload (ESP) packets inside
  UDP packets for the purpose of traversing Network Address Translators.
  ESP encapsulation can be used in both IPv4 and IPv6.  ESP
  encapsulation is used whenever negotiated by the Internet Key Exchange
  (IKE) protocol.

Working Group Summary

  The IPsec Working Group came to consensus on this document.

Protocol Quality

  This document was reviewed by Russell Housley for the IESG.


___
IETF-Announce mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf-announce