Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3
RFC 4817
Yes
No Objection
Recuse
Note: This ballot was opened for revision 03 and is now closed.
Lars Eggert (was Discuss) No Objection
(Ross Callon; former steering group member) Yes
(Sam Hartman; former steering group member) Yes
I think this draft goes a long way to addressing one of my concerns with the requirement for traffic isolation in L3VPNs and L2VPNs configured automatically in an IP core. In these environments traffic isolation, rather than integrity or confidentiality is the mandatory to implement security service (see RFC 4031).
(Bill Fenner; former steering group member) No Objection
(Brian Carpenter; former steering group member) (was Discuss) No Objection
(Cullen Jennings; former steering group member) No Objection
(Dan Romascanu; former steering group member) No Objection
It would be good if the applicability discussion in Section 4 would refer to the fact that Section 3 places the method of assigning the Session ID and Cookie out of scope. Such an observation would be important to make explicitly, because in the absence of a method of assigning L2TPv3 cookies real life deploymentes would be very complex, IMO.
(David Kessens; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
> This document defines how to carry an MPLS label stack and its > payload over L2TPv3. This is in fact incorrect. It defines how to carry it over the L2TPv3 data encapsulation, not the entire protocol.
(Jon Peterson; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
From the SecDir Review by Donald E. Eastlake III: This document uses "PE" all over the place without defining it. There are multiple references to "ACL" and in one case "access lists" without much clarity as to exactly what these are. I assume they are filters on packet header fields.
(Ted Hardie; former steering group member) (was Discuss) No Objection
The document says:
While the Session
ID may be encoded and assigned any value (perhaps optimizing for
local lookup capabilities, redirection in a distributed forwarding
architecture, etc.), the Cookie MUST be selected as a
cryptographically random value [RFC4086], with the added
restriction that it not be the same as a recently used value for a
given Session ID.
Is there any guidance on what a reasonable value for retention might be,
given the "not be the same as a recently used value"?
(Mark Townsley; former steering group member) Recuse