Re: [Pana] IESG discussions on draft-ohba-pana-relay

Jari Arkko <jari.arkko@piuha.net> Thu, 30 June 2011 21:01 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: pana@ietfa.amsl.com
Delivered-To: pana@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 509A821F86C0 for <pana@ietfa.amsl.com>; Thu, 30 Jun 2011 14:01:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.314
X-Spam-Level:
X-Spam-Status: No, score=-102.314 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdtQNdcx2-4e for <pana@ietfa.amsl.com>; Thu, 30 Jun 2011 14:01:05 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id A26A221F86BF for <pana@ietf.org>; Thu, 30 Jun 2011 14:01:05 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 8BE5E2CEA0; Fri, 1 Jul 2011 00:01:04 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izZKL9XSFITR; Fri, 1 Jul 2011 00:01:03 +0300 (EEST)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 3424D2CC39; Fri, 1 Jul 2011 00:01:03 +0300 (EEST)
Message-ID: <4E0CE40F.10202@piuha.net>
Date: Thu, 30 Jun 2011 23:01:03 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.24 (X11/20101027)
MIME-Version: 1.0
To: Alper Yegin <alper.yegin@yegin.org>
References: <4DF04217.3080304@toshiba.co.jp> <6491375641982933760@unknownmsgid> <BANLkTinVZ2Bvd6A+znQTiB7X-P6XXh3Cow@mail.gmail.com> <4E037743.2060602@gridmerge.com> <4E037A9D.8080200@piuha.net> <021a01cc3246$0b890390$229b0ab0$@yegin@yegin.org>
In-Reply-To: <021a01cc3246$0b890390$229b0ab0$@yegin@yegin.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: draft-ohba-pana-relay@tools.ietf.org, 'Stephen Farrell' <stephen.farrell@cs.tcd.ie>, pana@ietf.org
Subject: Re: [Pana] IESG discussions on draft-ohba-pana-relay
X-BeenThere: pana@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Protocol for carrying Authentication for Network Access <pana.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pana>, <mailto:pana-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pana>
List-Post: <mailto:pana@ietf.org>
List-Help: <mailto:pana-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pana>, <mailto:pana-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jun 2011 21:01:06 -0000

I'm fine this version as well.

jari

Alper Yegin kirjoitti:
> I think importing text from the other one Stephen had suggested would be an
> improvement. Like this:
>
>
> 3. Security of Messages Sent between PRE and PAA
>
> PRE/PAA security is OPTIONAL since PANA messages are designed to be
> used in untrusted networks, but if cryptographic mechanism is
> supported, it SHOULD be IPsec. When the device characteristics preclude
> support for IPsec, an alternative mechanism such as DTLS [REF], or
> link-layer cryptographic security, etc. may be used instead. This section
> describes how IPsec [RFC4301] can be used for securing the PANA relay
> messages.
>
> Alper
>
>
>
>
>   
>> -----Original Message-----
>> From: Jari Arkko [mailto:jari.arkko@piuha.net]
>> Sent: Thursday, June 23, 2011 8:41 PM
>> To: Yoshihiro Ohba; pana@ietf.org
>> Cc: Stephen Farrell; draft-ohba-pana-relay@tools.ietf.org
>> Subject: IESG discussions on draft-ohba-pana-relay
>>
>> We discussed this draft today. The remaining Discuss was about how
>> mandatory we should make IPsec. You had discussed about a SHOULD with
>> Stephen. I suggested that while interoperability is useful and
>> mandatory-to-implement mechanisms are good for it, we also have to talk
>> about how much value we bring with a security mechanism. In this case
>> there are some issues like MITMs able to block PANA packets. However,
>> some of these vulnerabilities are not helped by relay - PAA security,
>> as
>> the relay can still do bad things, and because ARP/ND vulnerabilities
>> between the client and relay in any case make it possible to become a
>> MITM. Stephen had some suggested text that I agree with:
>>
>> "PRE/PAA security is OPTIONAL since PANA messages are designed to be
>> used in untrusted networks, but if cryptographic mechanism is
>> supported,
>> it SHOULD be IPsec."
>>
>> Jari
>>     
>
>
>