IETF Logo Mail Archive

Re: [HOKEY] [IPsec] New I-D: draft-nir-ipsecme-erx-00

Qin Wu <sunseawq@huawei.com> Sat, 07 May 2011 00:42 UTC

Return-Path: <sunseawq@huawei.com>
X-Original-To: hokey@ietfa.amsl.com
Delivered-To: hokey@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F5FE07A2; Fri, 6 May 2011 17:42:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.714
X-Spam-Level:
X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001]
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 ZMvTRNy8PvK8; Fri, 6 May 2011 17:42:29 -0700 (PDT)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2D7E06B1; Fri, 6 May 2011 17:42:29 -0700 (PDT)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKS00DEDVAQVQ@szxga05-in.huawei.com>; Sat, 07 May 2011 08:42:26 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKS0046HVAPJT@szxga05-in.huawei.com>; Sat, 07 May 2011 08:42:26 +0800 (CST)
Received: from C863D63E94E7457 ([220.114.250.53]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LKS006EFVAOGE@szxml11-in.huawei.com>; Sat, 07 May 2011 08:42:25 +0800 (CST)
Date: Sat, 07 May 2011 08:42:53 +0800
From: Qin Wu <sunseawq@huawei.com>
To: Yoav Nir <ynir@checkpoint.com>, Yaron Sheffer <yaronf.ietf@gmail.com>
Message-id: <007301cc0c4f$b3c45540$ff5afea9@C863D63E94E7457>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
Content-type: multipart/alternative; boundary="Boundary_(ID_tWwmbNxaE4yr7NJCVV5ruA)"
X-Priority: 3
X-MSMail-priority: Normal
References: <006FEB08D9C6444AB014105C9AEB133F013ABE025E24@il-ex01.ad.checkpoint.com> <4DBF19F4.6050804@gmail.com> <95F1A883-8213-4A57-911B-E660E02A3117@checkpoint.com> <00a401cc09fd$b152ef00$46298a0a@china.huawei.com> <8CAC67D8-623B-4738-89B0-4A72C3C7AF95@checkpoint.com> <b94047babd6474117f7734354425dc0b.squirrel@www.trepanning.net> <BAE19B87-DE7A-4306-B3F0-D171580BCE57@checkpoint.com> <86c7cd758de89a6f640f8e55faff11ee.squirrel@www.trepanning.net> <F27D10DD-0B3A-4BA1-AF42-9D814C761804@checkpoint.com> <6c5908c5ea31d90ed1a8f96b57bf2d72.squirrel@www.trepanning.net> <FC252A0F-BCF3-458D-B2C1-68CCF64F583F@checkpoint.com> <4DC30B68.70202@gmail.com> <624EB8DD-96F6-422A-A2DE-B02A0507BF14@checkpoint.com>
Cc: ipsec@ietf.org, hokey@ietf.org
Subject: Re: [HOKEY] [IPsec] New I-D: draft-nir-ipsecme-erx-00
X-BeenThere: hokey@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: HOKEY WG Mailing List <hokey.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hokey>, <mailto:hokey-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hokey>
List-Post: <mailto:hokey@ietf.org>
List-Help: <mailto:hokey-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hokey>, <mailto:hokey-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 07 May 2011 00:42:30 -0000




    It seems to me RFC 4306/5996 took the concept a bit further than RFC 4301 ever intended (in fact I believe the text is new to RFC 5996). Presumably, when we talk about identity-based policy decisions, we refer to http://tools.ietf.org/html/rfc4301#section-4.4.3. This text (and the following section) explicitly allows for "bulk" policies that apply to "@example.com".com", i.e. anybody at that domain. And such coarse granularity may be sufficient in practice for inter-ISP traffic: ISP1 may be happy to provide secure connectivity to ISP2's customers and take a cut of the business, even if it doesn't know the exact identity of each customer and cannot contact them, bill them or log their names.

    So I would suggest that the draft should mention that no individual authenticated identity is available in the typical case (and this is unfortunately in conflict with RFC 5996), but the obscured identity provided in RADIUS Access-Accept can be used to make legitimate policy decisions.



  I'm not even sure of that. Qin, does ERP give us the domain name of the original authenticating server?  Do we even know if the user came from this-isp or that-isp?



    Thanks,
        Yaron


  [Qin]: Sure.

  The domain name of the original authenticating server you are talking about is actually home domain name.
  The peer bootstraps from the home domain at the first time and should know home domain name or home ER server name wherever it moves around.
  The peer learns local domain name through ERP message or other lower layer mechanism. Therefore the peer can identify which domain it move to.
  The local ER server and ER  authenticator can know domain name through realm part of KeyName-NAI TLV carried in the ERP message sent from the peer.
  Comparing realm part of KeyName-NAI and the domain which they belong to, they also can identify if the user come from home domain or local domain.








------------------------------------------------------------------------------


  _______________________________________________
  IPsec mailing list
  IPsec@ietf.org
  https://www.ietf.org/mailman/listinfo/ipsec

v2.8.7 | Report a Bug | By Email