Re: [pcp] Comparison of PCP authentication

Margaret Wasserman <mrw@lilacglade.org> Mon, 06 August 2012 23:09 UTC

Return-Path: <mrw@lilacglade.org>
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82A5821F8666 for <pcp@ietfa.amsl.com>; Mon, 6 Aug 2012 16:09:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -95.707
X-Spam-Level:
X-Spam-Status: No, score=-95.707 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivWuu6M5bpAZ for <pcp@ietfa.amsl.com>; Mon, 6 Aug 2012 16:09:13 -0700 (PDT)
Received: from ec2-23-21-76-251.compute-1.amazonaws.com (ec2-23-21-76-251.compute-1.amazonaws.com [23.21.76.251]) by ietfa.amsl.com (Postfix) with ESMTP id E980F21F865F for <pcp@ietf.org>; Mon, 6 Aug 2012 16:09:12 -0700 (PDT)
Received: from lilac-too.home (permutation-city.suchdamage.org [69.25.196.28]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id 55AB82002D; Mon, 6 Aug 2012 19:08:12 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Margaret Wasserman <mrw@lilacglade.org>
In-Reply-To: <BB72B80F-0622-4A5B-A985-79D8AED13E0B@apple.com>
Date: Mon, 06 Aug 2012 19:09:11 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <34A0574C-A57A-487F-B302-D0EA24C0E93E@lilacglade.org>
References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <D6D2DEED-C35A-45AB-8B72-96195C308DB9@yegin.org> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <BB72B80F-0622-4A5B-A985-79D8AED13E0B@apple.com>
To: james woodyatt <jhw@apple.com>
X-Mailer: Apple Mail (2.1084)
Cc: pcp@ietf.org
Subject: Re: [pcp] Comparison of PCP authentication
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Aug 2012 23:09:13 -0000

Another important point to consider, James.  Thanks!

Margaret

On Aug 6, 2012, at 7:03 PM, james woodyatt wrote:

> On Aug 6, 2012, at 13:02 , Margaret Wasserman <mrw@lilacglade.org> wrote:
>> 
>> Do you know what existing PANA implementations will do if the "Reserved" field at the start of the packet is non-zero? 
> 
> A related question might be what existing NAT-PMP implementations will do if they receive a message containing a PANA packet.  Assuming they comply with I-D.cheshire-nat-pmp-03, they will interpret the first two octets of a PANA message as an announcement request, and they will reply with the announcement response message shown below.
> 
>    0                   1                   2                   3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   | Vers = 0      | OP = 128 + 0  | Result Code                   |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   | Seconds Since Start of Epoch                                  |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   | External IP Address (a.b.c.d)                                 |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> If a PCP server needs to implement NAT-PMP too, then it can easily distinguish a NAT-PMP announcement request from a PANA message, but one wonders if a PANA client expecting to authenticate to such a server can deal with replies from a NAT-PMP server that knows nothing about either PCP or NAT-PMP.
> 
> 
> --
> james woodyatt <jhw@apple.com>
> member of technical staff, core os networking
> 
> 
> 
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp