[secdir] SECDIR review of draft-ietf-nfsv4-rpcrdma-bidirection
Radia Perlman <radiaperlman@gmail.com> Mon, 30 January 2017 03:11 UTC
Return-Path: <radiaperlman@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD3E0127735; Sun, 29 Jan 2017 19:11:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwX8QhGPQBUV; Sun, 29 Jan 2017 19:11:08 -0800 (PST)
Received: from mail-ot0-x233.google.com (mail-ot0-x233.google.com [IPv6:2607:f8b0:4003:c0f::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E196126CD8; Sun, 29 Jan 2017 19:11:08 -0800 (PST)
Received: by mail-ot0-x233.google.com with SMTP id 32so75654374oth.3; Sun, 29 Jan 2017 19:11:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ApT4lIc+5+2MPVZc/MDn4iKJr14z0BnGwgxyinmqJGY=; b=RbxRvdL3CmsmqL0DnhMgLmk7XPjWQVP2NySxP5KrsZdtfDeAOlM/CaAj6mS8K7a5hV WuNtS68D75EDwNr48hzr4Ofj3xnBQ++Iu4x3NvxO2OMxzOdcC+FHbInX/6lq9G3kc4W7 1h/N4p3UmlXuRePLnzdQrjfOAZfKnr7wbINtuL5Zd3FG915cb0x6B1aXWApUEqTxHY4b xo0FT+LHpWOJ0llskDJtp/vI8IfwhqkCnoDU6df1pu1iGWhNyCRWnFKuq1BjeuN0K06s g2DKXFy/iGCgU2ntGUDqgfZJP4NRLj5ZUgcm7DfpySlScv0GtI8j/jIf154PygA7Qik+ 1LKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ApT4lIc+5+2MPVZc/MDn4iKJr14z0BnGwgxyinmqJGY=; b=tEZiv6XVJOK/NpcdvruYeOQ0RwKO5OP4aVLWBZN73Q2X9X662QxOVg0ZuhCQo1jrNG XeJyDu20sLqSkFuvPRF9stKPGQcGSoFdRQPoYJEIfm1mAXlEtJtlfAyleMeldB0DKs9O LJYK6ynKKSKyvLEDsFHyWd+Y8s94igIhaG5bh5hzaz12Ym/1K1XZ5JuWDG4uvr9WGvS8 qYEQ+B3LiAHGx7NUf3Itw2PYfyn8KUQenhysQry/tKw3+F0CDwbScjyhQoHPUsnf5OEE YB8db4V+bDpwMMkKpyhWSLkemuEfCAljyquqJkqkDD6RzOm+zzZw/HyqVwvVEGtoHR62 +kiw==
X-Gm-Message-State: AIkVDXLIul8cni8fpDe9X9o3xAvP8Sb+vLBUQG5JAnxf5oQi5/XUNE3F/SuYI/hF9qXfg455n7sa93xHUah9Ww==
X-Received: by 10.157.15.144 with SMTP id d16mr8502680otd.169.1485745867738; Sun, 29 Jan 2017 19:11:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.217.72 with HTTP; Sun, 29 Jan 2017 19:11:07 -0800 (PST)
From: Radia Perlman <radiaperlman@gmail.com>
Date: Sun, 29 Jan 2017 19:11:07 -0800
Message-ID: <CAFOuuo72ASH2f_n4dpanWDDtoyAH7gP-ckkW-sP6KTJdtjs=mA@mail.gmail.com>
To: The IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, draft-ietf-nfsv4-rpcrdma-bidirection.all@tools.ietf.org
Content-Type: multipart/alternative; boundary="001a113db17eac57080547472a93"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/a44yj8Tu4Dc9cDNgzUUSONaHPsc>
Subject: [secdir] SECDIR review of draft-ietf-nfsv4-rpcrdma-bidirection
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Jan 2017 03:11:10 -0000
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 concerns running NFS over RDMA (memory to memory access), and in particular running RPC requests “in both directions” (client to server – called forward direction – and callbacks from server to client called reverse direction). The RFC claims to describe current practice rather than to prescribe future practice, but it is intended to be Standards track, which is a little odd, but I guess documenting what is current practice and standardizing on it for the future is fine. In any case, RDMA is a high performance protected channel considered to be secure by its nature. If an RDMA protocol were run over a network tunnel, it would be the responsibility of the tunnel to implement authentication and encryption. And access rights of particular nodes and/or users is defined in higher layers of NFS, and so is unaffected by the fact that this is running over RDMA. Bottom line is there are no security considerations. The security considerations section refers readers to RFC5666bis (which is about NFS over RDMA generally rather than the specific issue of callbacks). This seems appropriate. If I were to make one comment it's that I don't like the terminology "backwards". I might have used "reverse". "Backwards" has a somewhat negative connotation, and it's slightly confusing when discussing "Backward Credits". I'd think a "backwards credit" would be taking away credits from someone. "Reverse credits" would be just as bad, but perhaps "reverse-direction credits" might be clear. Radia
- [secdir] SECDIR review of draft-ietf-nfsv4-rpcrdm… Radia Perlman
- Re: [secdir] SECDIR review of draft-ietf-nfsv4-rp… Chuck Lever