Re: [Softwires] [Gen-art] Gen-ART review of draft-ietf-softwire-hs-framework-l2tpv2-10

Carlos Pignataro wrote:
> WG,
>
> On 12/22/2008 7:49 PM, Black_David@emc.com 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
>> black_david@emc.com        Mobile: +1 (978) 394-7754
>> ----------------------------------------------------
>>
>>     
>
>   

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires