Re: [IPFIX] RFC 5101bis: Changes to MTI transport protocol and security

Hi, Gerhard,

Thanks for your reply; replies thereon inline...

On Apr 2, 2012, at 10:13 PM, Gerhard Muenz wrote:

> 
> Brian,
> 
> I think that it is reasonable to relax the MTI transports for IPFIX.
> 
> Looking at your e-mail, I would not call the MTI transports "mandatory transport protocols" because this sounds as if their usage is mandatory in the given context - which is not. The "optional transports" can be used as well.

Good point; will tighten up the language that goes into the document, should we make this change.

> If I understand correctly, you want to make TLS/TCP mandatory to implement, while the implementation of DTLS/SCTP shall become optional in RFC5101.

Yes -> the MTI protocols would be SCTP and TLS/TCP.

> What about implementations which already support DTLS/SCTP but not TLS/TCP? Will they become non-compliant?

Essentially, yes. (Are there currently working DTLS/SCTP implementations which don't support TLS/TCP?)

> What about implementations which will only be used in a "walled garden"? Do they need to implement TLS/TCP although it will never be used?

I would intend not; this depends on how/whether we can specify a deployment-scenario-dependent MTI.

> Is it actually necessary to specify any MTI transports, apart from SCTP-PR?
> 
> Isn't it sufficient to specify that TLS should or must be supported when TCP is implemented?
> 
> It makes much sense to strongly recommend (or mandate) the usage of encryption for any IPFIX transport over untrusted networks. Whether this is realized using TLS, DTLS, IPSEC or whatever is not important.

As I recall from the discussions of this issue in 5101 back in 2006-2007, the security area would not have been (and likely would still not be) happy with us defining a single MTI which did not provide any security; defining "security by tunnel" in the general case was not acceptable.

Therefore the proposal to separate the transport out by deployment requirements.

Thanks, and best regards,

Brian


> On 02.04.2012 13:37, Brian Trammell wrote:
>> Greetings, all,
>> 
>> Following up on the discussion at the WG meeting in Paris on Thursday, I wanted to outline in more detail a proposal to slightly modify the mandatory-to-implement transports for IPFIX.
>> 
>> We have a problem in interoperability testing (our big open issue for 5101bis): section 11.1 states that DTLS over SCTP MUST be implemented. DTLS over SCTP was finally published on the standards track as RFC 6083 in January 2011, but to my knowledge there still exist no implementations of this on which an IPFIX implementation could be built for interop testing. On the other hand, TLS over TCP was successfully interop'd as far back as 2006.
>> 
>> I would propose the following as a fix for this situation:
>> 
>> 1. SCTP [RFC4960] with partial reliability [RFC3578] is the mandatory transport protocol for IPFIX. This protocol is intended for use in typical "walled garden" flow collection infrastructures within a single administrative domain on closed/dedicated networks. These infrastructures are often built with legacy flow collection applications in mind (i.e. NetFlow over UDP), and provide security either through physical or virtual separation at layer 2, or via tunneling when necessary.
>> 
>> 2. TLS over TCP is the mandatory transport protocol for IPFIX where transport security is required. This protocol is intended for "open Internet" usage of IPFIX, across administrative domains or from remote sites to which a tunneled or physically secured network cannot be extended. Note that the most serious drawback for IPFIX over TCP -- full reliability leading to head-of-line blocking when transmitting at capacity -- is generally less of an issue in such circumstances, as these would usually be "post-mediator" applications, filtering or aggregating the data to be sent remotely.
>> 
>> 3. All other transport and transport security combinations are optional.
>> 
>> This would require new text in 5101bis to explain the differences in deployment requirements between "walled garden" and "open Internet" deployments. I spoke informally to one of the security ADs, and he indicated that personally did not consider defining SCTP and TCP/TLS as the mandatories  to be untenable, given the DTLS/SCTP situation.
>> 
>> We do have a problem in that a 5101bis implementation is now _technically_ not interoperable with an older 5101 implementation (5101bis uses TLS over TCP, 5101 DTLS over SCTP), but since DTLS over SCTP never worked this should not present a problem in practice.
>> 
>> 
Recent developments in TSVWG include the definition of UDP encapsulation of SCTP (WG item, to allow userspace implementation and transit of SCTP-unaware or SCTP-hostile middleboxes) and DTLS over UDP encapsulation of SCTP (individual draft http://tools.ietf.org/id/draft-tuexen-tsvwg-sctp-dtls-encaps-00.txt -- which appears to be targeted at solving a problem RTCWEB has). I believe this second draft may lead to easier implementation than the present DTLS over SCTP, as there already exist working DTLS over UDP implementations.
>> 
>> We could then define bindings for IPFIX over SCTP over DTLS over UDP in a separate, later draft for open-internet deployments which require the features of SCTP.
>> But I don't think this belongs in 5101bis (especially as it's still covered by a TSVWG individual draft).
>> 
>> Thoughts?
>> 
>> Best regards,
>> 
>> Brian
>> _______________________________________________
>> IPFIX mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/ipfix

_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix