Re: [secdir] SecDir review of draft-ietf-nsis-tunnel-11

[Charles Shen <[e-mail]>]

Thanks Yaron, please see inline.

On Sun, Jun 20, 2010 at 7:46 AM, Yaron Sheffer <[e-mail]> wrote:
> [Removed the IESG.]
>
> Hi Charles,
>
> please see my comments inline.
>
> Thanks,
>    Yaron
>
> On 06/20/2010 06:52 AM, Charles Shen wrote:
>>
>> Hi Yaron, thank you for your careful review. Please see comments inline.
>>
>> On Sun, Jun 13, 2010 at 3:58 AM, Yaron Sheffer<[e-mail]>
>>  wrote:
>> > I have reviewed this document as part of the security directorate's
>> > ongoing effort to review all IETF documents being processed by the IESG.
>> > These comments were written primarily for the benefit of the security
>> > area directors.  Document editors and WG chairs should treat these
>> > comments just like any other last call comments.
>> >
>> > This draft discusses the problem of NSIS messages (particularly, QoS
>> > reservation flows) being encapsulated into various IP tunneling
>> > protocols,
>> > which prevent the correct QoS setup from being performed. The draft
>> > proposes
>> > a solution for NSIS tunnel-aware tunnel endpoints, which basically adds
>> > an
>> > NSIS signaling flow between the tunnel endpoints, but outside of the
>> > tunnel.
>> >
>> > General
>> >
>> > The draft presents the problem, and the solution, reasonably well.
>> >
>> > The draft goes for the "no new security issues" approach. I think this
>> > is
>> > incorrect, and in fact a number of security issues should be analyzed
>> > and
>> > possibly resolved. In addition, as a complete outsider to NSIS, I have
>> > identified one major unspecified piece, leading me to believe that the
>> > draft
>> > has not had enough review.
>> >
>> > Security
>> >
>> > The main security issue is that the draft fails to consider
>> > security-oriented tunnels. IPsec tunnels (and the commonly used
>> > GRE-over-IPsec) provide security services: normally encryption and
>> > integrity
>> > protection with ESP, less commonly integrity-protection only with AH,
>> > ESP
>> > with null encryption, or the new WESP (RFC 5840). The proposed solution
>> > raises at least three major security issues related to these tunnels:
>> >
>> > 1. A so-called covert channel that results from NSIS flows in the
>> > protected
>> > networks directly triggering NSIS protocol exchanges in an unprotected
>> > network (i.e. between the tunnel endpoints). Please see Appendix B.1 of
>> > draft-ietf-tsvwg-ecn-tunnel-08 for treatment of a similar issue.
>> >
>>
>> With regard to this specific draft, I see the problem as a more
>> generic issue which exists also for other protocols (e.g., RSVP)
>> requiring per-hop processing to interact with IPSec. E.g., RFC4302
>> mentions that "NOTE: Use of the Router Alert option is potentially
>> incompatible with use of IPsec. Although the option is immutable, its
>> use implies that each router along a packet's path will "process" the
>> packet and consequently might change the packet.". I think that
>> mentioning of this potential incompatibility will be beneficial. But I
>> don't quite see how "limiting the bandwidth of the covert channel" as
>> discussed in Appendix B.1 of draft-ietf-tsvwg-ecn-tunnel-08 can be
>> applied here. Please correct me if I were wrong.
>>
> You can say this solution is incompatible with IPsec and be done with it.
> Otherwise, there is a "covert channel
> <http://en.wikipedia.org/wiki/Covert_channel>" - someone can create spurious
> NSIS signaling flows within the protected network, just to create signaling
> in the outside network, which then someone else is monitoring. For highly
> secure networks, this would be seen as a way to smuggle information out of
> the network, and you would want to rate-limit this channel.
>>

That makes sense. My understanding is that the rate-limit does not
complete solve the problem, but does reduce the potential harm.


>> > 2. A more serious interaction in the other direction: unprotected NSIS
>> > flows
>> > outside the tunnel interact with NSIS flows in the protected networks
>> > and
>> > inside the tunnel, and so, an attacker in the unprotected network can
>> > possibly influence QoS behavior in protected networks.
>> >
>> > 3. A practical result of (2) is that the NSIS protocol stack on the
>> > tunnel
>> > endpoint is now exposed to unprotected networks and therefore suddenly
>> > becomes security-critical.
>> >
>>
>> IMHO, if we have a segment of the path which is compromised, the QoS
>> of the rest of the path segments (and the end-to-end QoS) can be
>> easily affected anyway, whether you have a tunnel segment in the path
>> or not. Therefore, it doesn't seem to me as a new threat introduced by
>> this document per se. But it will certainly also be helpful to mention
>> this scenario in the security considerations section.
>
> What I'm saying in #3 is that any security vulnerability (e.g. buffer
> overflow) in the NSIS stack is suddenly exposed to the big bad Internet,
> even when the customer may have expected all their traffic to be protected
> by a VPN gateway, where the VPN software is normally the only software that
> needs to be hardened.

I agree. What I had been thinking is that compromise of other nodes
(non-tunnel end-points) may similarly affect end-to-end QoS signaling,
even if the end-to-end path includes a secure tunnel.

>>
>> > Non-Security
>> >
>> > The draft defines extra UDP encapsulation in some cases ("the tunnel
>> > entry-point inserts an additional UDP header"), but the format
>> > (specifically, the port number) is not specified. This omission is
>> > strange,
>> > because the protocol cannot be implemented in the absence of this
>> > information!
>> >
>>
>> To me this is an intended feature. The mechanism does not require a
>> pre-allocated fixed UDP port, but allows the port to be dynamically
>> chosen and conveyed during the tunnel flow/session binding operations.
>>
> Sure, I missed this point. Can you please mention it explicitly.
>

Sure!

Thanks

Charles