headers
The IESG | 8 Aug 2006 01:27
Picon
Favicon

Protocol Action: 'IKE and IKEv2 Authentication Using ECDSA' to Proposed Standard

The IESG has approved the following document:

- 'IKE and IKEv2 Authentication Using ECDSA '
    <draft-ietf-ipsec-ike-auth-ecdsa-06.txt> 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 Russ Housley.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-auth-ecdsa-06.txt

Technical Summary

   This document describes how the Elliptic Curve Digital Signature
   Algorithm (ECDSA) may be used as the authentication method within the
   Internet Key Exchange (IKE) and Internet Key Exchange version 2
   (IKEv2) protocols.  ECDSA may provide benefits including computational
   efficiency, small signature sizes, and minimal bandwidth compared to
   other available digital signature methods.  This document adds ECDSA
   capability to IKE without introducing any changes to existing IKE
   operation.

Working Group Summary

   This document is an individual submission.  It was discussed in the
   IPsec Working Group, but that working group was closed before reaching
   consensus on this document.  Thus, it is not affiliated with any IETF
   Working Group.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tero Kivinen | 8 Aug 2006 14:26
Picon
Picon
Favicon

Protocol Action: 'IKE and IKEv2 Authentication Using ECDSA' to Proposed Standard

The IESG writes:
> The IESG has approved the following document:
> 
> - 'IKE and IKEv2 Authentication Using ECDSA '
>     <draft-ietf-ipsec-ike-auth-ecdsa-06.txt> as a Proposed Standard
> 
> Note to IANA
> 
>    The registry is http://www.iana.org/assignments/ipsec-registry [IANA-IKE],
>    and the section within the registry is "IPSEC Authentication Methods".
>    The three new additions are:
> 
>       Method                                        Value
>       ------                                        -----
>       ECDSA with SHA-256 on the P-256 curve           9
>       ECDSA with SHA-384 on the P-384 curve          10
>       ECDSA with SHA-521 on the P-512 curve          11
> 
>    The registry is http://www.iana.org/assignments/ikev2-parameters
>    [IANA-IKEv2], and the section within the registry is "IKEv2
>    Authentication Method".  The three new additions are:
> 
>       Method                                        Value
>       ------                                        -----
>       ECDSA with SHA-256 on the P-256 curve           9
>       ECDSA with SHA-384 on the P-384 curve          10
>       ECDSA with SHA-521 on the P-512 curve          11

As the currently allocated numbers in the IKEv2-parameters for the
"IKEv2 Authentication Method" are completely different that IKEv1, and
(Continue reading)

Permalink | Reply | 0 comments |
headers
The IESG | 21 Aug 2006 17:16
Picon
Favicon

Last Call: 'An Architecture for Provider Provisioned CE-based Virtual Private Networks using IPsec' to Informational RFC (draft-ietf-l3vpn-ce-based)

The IESG has received a request from the Layer 3 Virtual Private Networks
WG to consider the following documents:

- 'Applicability Statement for Provider Provisioned CE-based Virtual
    Private Networks using IPsec '
    <draft-declercq-l3vpn-ce-based-as-00.txt> as an Informational RFC
- 'An Architecture for Provider Provisioned CE-based Virtual Private
    Networks using IPsec '
    <draft-ietf-l3vpn-ce-based-03.txt> as an Informational RFC

These documents were a product of first the PPVPN WG, and later the L3VPN
WG. They passed WG Last Call, but have not been actively discussed in the
WG for some time. There is little interest to work on CE-based VPN
problems within the WG today. The L3VPN WG is being rechartered to reflect
this, and these documents are being advanced as Informational for the
historical record.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg <at> ietf.org or ietf <at> ietf.org mailing lists by 2006-09-04.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-declercq-l3vpn-ce-based-as-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-ce-based-03.txt

_______________________________________________
IETF-Announce mailing list
IETF-Announce <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tero Kivinen | 22 Aug 2006 12:41
Picon
Picon
Favicon

Comments to draft-declercq-l3vpn-ce-based-as-00.txt

This document really should expand CE when it is used first time in
the abstract... 

> 13. QoS, SLA
> 
>    In addition to the VPN service (reachability and security) from the
>    SP, the VPN customer may want to acquire QoS features for its VPN.
>    Dependent on the business scenario, the SLA will be provided by the
>    VPN SP or by the Network Provider.
> 
>    Note that the fact that customer IP packets are encapsulated (and
>    possibly encrypted) at the CE devices has an impact on the QoS
>    treatment of the IP packets: QoS-related information inside the
>    customer IP packets may become invisible.
> 
>    An eventual translation of QoS-related fields (e.g. DSCP) in the
>    inner IP header to QoS-related fields in the outer IP headers need to
>    be done at the CE-level and configured as such by the SP. Also the
>    'policing' rules (e.g. certain customers not being allowed to use
>    certain QoS values, etc.) need to be configured by the SP in the CE
>    devices. The security infrastructure of the CE device must prevent
>    the customer from messing with this provider-controlled
>    configuration.
> 
>    The CE-CE tunneling applied in Provider Provisioned CE-based IPsec
>    VPNs easily meets the DSCP transparency requirements of [REQS].

Note, that if packets having different QoS parameters are put inside
one IPsec SA tunnel, and the packets are really processed differently
by the network, this may cause the responder to drop all low priority
(Continue reading)

Permalink | Reply | 0 comments |

Gmane