Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3
draft-ietf-mpls-over-l2tpv3-03
Yes
(Ross Callon)
No Objection
(Bill Fenner)
(Brian Carpenter)
(Cullen Jennings)
(David Kessens)
(Jon Peterson)
(Lars Eggert)
(Magnus Westerlund)
Recuse
(Mark Townsley)
Note: This ballot was opened for revision 03 and is now closed.
Ross Callon Former IESG member
Yes
Yes
()
Unknown
Sam Hartman Former IESG member
Yes
Yes
(2006-10-24)
Unknown
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 IESG member
No Objection
No Objection
()
Unknown
Brian Carpenter Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
(2006-10-25)
Unknown
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 IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(2006-10-25)
Unknown
> 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 IESG member
No Objection
No Objection
()
Unknown
Lars Eggert Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Magnus Westerlund Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2006-10-24)
Unknown
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 IESG member
(was Discuss)
No Objection
No Objection
(2006-10-24)
Unknown
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 IESG member
Recuse
Recuse
()
Unknown