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

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.

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

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

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?

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.

Thanks,
Gerhard


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