Carlos Pignataro wrote:
WG,
On 12/22/2008 7:49 PM, [email protected] said the following:
After a lengthy private discussion with Carlos, and some
serious "quality time" spent with RFC 2661 ;-), here's
where I think the two major issues from my Gen-ART review
of this draft stand:
(1) AVP for softwire profile of L2TPv2. I'm no longer
convinced that a new AVP is needed, but the specification
of the profile needs significant clarification and cleanup.
For completeness, I do not think that significant cleanup is needed, but
rather that some localized editorial clarifications of context might
help the reader. In any case, one of the big decisions in this
discussion is that there's no new "softwire AVP", and some fall out is
that S5.1.1.X can use more specific descriptions.
For example, what happens if a softwire implementation of
L2TPv2 happens to receive an OCRQ message?
For example, draft-ietf-softwire-hs-framework-l2tpv2 specifies that:
in the Softwire context, the voluntary tunneling model applies
...
Since L2TPv2 compulsory tunneling model does
not apply to Softwires, it should not be requested or honored.
...
In the Softwire "Hub and Spoke" model, the Softwire Initiator (SI)
assumes the role of the LAC Client
And more notably:
No outgoing or analog calls are permitted.
So, if a softwire implementation of L2TPv2 happens to receive an OCRQ
message, it needs to CDN it (as strongly hinted though not explicitly
spelled out; for a versatile and variation-rich protocol as L2TP a this
seems a self-evident exception protocol paths for softwire). The
fall-through protocol definition lies in RFC2661 (the doc says "as
defined in [RFC2661]"), and that scenario is the same as "if a full
RFC2661 implementation of L2TP not configured for outgoing calls
receives an OCRQ message".
That was certainly my thinking here... If OCRQ functionality is not
supported, send a CDN.
This has also
turned up a topic that needs to be covered in the Security
Considerations section - a brief discussion of the security
consequences of the recommendation not to hide AVPs.
Right, this is one new thing that came up, from looking into the Random
Vector AVP. The document is recommending not to hide AVPs, from the very
original text. But, I think, the document "MAY" allow AVP hiding
(instead of describing the consequences of not hiding).
I see no problem updating the security considerations to point out the
weaknesses of the hiding mechanism with 2009 knowledge vs. the 1999
state of the art when L2TP first made it from draft to RFC.
- Mark
(2) RFC 5405 and UDP. In addition to referencing RFC 5405,
a recommendation for L2TPv2 use of PMTUD will be added.
We will describe all the changes when we post an updated version of the
document.
Thanks,
--Carlos.
Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
[email protected] Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
