From fernando.gont.netbook.win@gmail.com Wed Jun 1 11:53:51 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A91B9E06C0 for ; Wed, 1 Jun 2011 11:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 LbK+FRjf3LLq for ; Wed, 1 Jun 2011 11:53:51 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id E2919E07F4 for ; Wed, 1 Jun 2011 11:52:38 -0700 (PDT) Received: by ywp31 with SMTP id 31so54054ywp.31 for ; Wed, 01 Jun 2011 11:52:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=K3jzr7gN/n+AeqH6Pek29wAVXyORp/OOhjz7t8Lv3QQ=; b=RrJOzP3Ony1y4uwZWRz6GkuPiyBEYeGO5pKZ3SYpwWCZzUY0hinU6WmO/jzFmxGsuU f6CgGziuBIMSOzOazfVCuzCP6Qq4gBFN7PeuNkrzgOOLCyyRKaZ6ad7UhJaCF+dXNzi1 6zkKxCIukHhm3V3LVB4tqQ5rInexYw9UBxoBk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=soqV0MvcsC949DghfO0s7psb5zSxpAkQ+4hXQfTy3hPuF6McAw3pEnfp2ev97DOTdt 6aO8yth/BNwvm/OPiDt0V6+fV9yLk/jufoK3MZ0glHCoXGfafDJhkNUZtVMzowLGoZx/ pI8UNomEt7vfJqQ3qjzQZskmoKP65J6AImlCU= Received: by 10.101.213.31 with SMTP id p31mr4983357anq.139.1306954358310; Wed, 01 Jun 2011 11:52:38 -0700 (PDT) Received: from [192.168.123.103] ([190.48.203.155]) by mx.google.com with ESMTPS id f2sm870143ani.19.2011.06.01.11.52.35 (version=SSLv3 cipher=OTHER); Wed, 01 Jun 2011 11:52:37 -0700 (PDT) Sender: Fernando Gont Message-ID: <4DE68A71.7040909@gont.com.ar> Date: Wed, 01 Jun 2011 15:52:33 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: Preliminary report on flow label hash algorithms References: <4DE5CA6F.6080803@gmail.com> In-Reply-To: <4DE5CA6F.6080803@gmail.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 18:53:51 -0000 On 06/01/2011 02:13 AM, Brian E Carpenter wrote: > In summary: the algorithm suggested in the Appendix to > draft-ietf-6man-flow-3697bis-04 doesn't perform very well > on real packets, and I have an improved version to suggest. Sorry if I'm missing something: Any reasons for which you chose a different algorithm from the one described in draft-gont-6man-flowlabel-security? The algorithm in the aforementioned I-D has already been well tested for randomizing TCP port numbers, timestamps, and sequence numbers. -- and I don't think there's a real need to reinvent the wheel. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From narten@us.ibm.com Wed Jun 1 13:43:29 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA72E0875 for ; Wed, 1 Jun 2011 13:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, 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 e5kiAoTb-ksI for ; Wed, 1 Jun 2011 13:43:28 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by ietfa.amsl.com (Postfix) with ESMTP id 387F6E0973 for ; Wed, 1 Jun 2011 13:42:47 -0700 (PDT) Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e1.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p51KVAue014612 for ; Wed, 1 Jun 2011 16:31:10 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p51KgZR6093490 for ; Wed, 1 Jun 2011 16:42:39 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p51KgY16029394 for ; Wed, 1 Jun 2011 16:42:34 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-76-138-57.mts.ibm.com [9.76.138.57]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p51KgXr0029304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Jun 2011 16:42:33 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p51KgVud023906; Wed, 1 Jun 2011 16:42:32 -0400 Message-Id: <201106012042.p51KgVud023906@cichlid.raleigh.ibm.com> To: Brian E Carpenter Subject: Re: Multiple addresses [was Node Requirements: Elevating DHCPv6 from MAY to SHOULD] In-reply-to: <4DE55815.3080702@gmail.com> References: <4DE3F87A.5060502@globis.net> <4DE40821.9030205@gmail.com> <4DE420E2.6010207@globis.net> <4DE5536D.9050906@globis.net> <4DE554F9.20603@globis.net> <4DE55815.3080702@gmail.com> Comments: In-reply-to Brian E Carpenter message dated "Wed, 01 Jun 2011 09:05:25 +1200." Date: Wed, 01 Jun 2011 16:42:31 -0400 From: Thomas Narten Cc: Ray Hunter , ipv6@ietf.org, Ralph Droms X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 20:43:29 -0000 Brian E Carpenter writes: > Ray, > Without going into details: how about turning this into > draft-hunter-v6ops-something and having the debate over in v6ops? > I think that would be useful, personally. Actually, let me suggest something else. Before spending a whole lot of time on this topic, is there anyone else who thinks there is a problem here that needs solving? The last thing we (as a group) need to do is spend time on a non-problem. Personally, I don't see the issue here. I think the problem as stated is a non-problem. And to be honest, this is the first time I have heard anyone suggest what you describe is a real problem. So I wonder whether anyone else thinks there is a problem here that needs fixing. To the point: > > Ray Hunter wrote: > >> It's definitely going to become an operational FAQ, unless it is very > >> clear whether/how a network operator can force equivalent use of > >> DHCPv4 static address assignment for both source and destination > >> addresses via DHCPv6 (possibly by turning off SLAAC for assignment of > >> GUA on an interface via a flag, or via RFC3484 bis), and how to > >> achieve this effect for all nodes on a link, without resorting to > >> local configuration. So I may as well be the first to ask. A fine way to deal with this problem is not advertise any prefixes in RAs for stateless address autoconfiguration. The network operator is in control here. They decide how/whether DHCP and/or SLAAC is used. Why is this not sufficient? Thomas From rdroms.ietf@gmail.com Wed Jun 1 14:10:27 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 290A6E08B6 for ; Wed, 1 Jun 2011 14:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, 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 0Qo6SpbleWvA for ; Wed, 1 Jun 2011 14:10:24 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id BAD41E08AF for ; Wed, 1 Jun 2011 14:10:24 -0700 (PDT) Received: by qyk7 with SMTP id 7so121758qyk.10 for ; Wed, 01 Jun 2011 14:10:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=oaAvDwEPLLYKEm5xOJDbZEgX20YJ8F2rYVIYZTIr/PA=; b=d91fwnxSOmjj4SHdEnv/bGdyGAN0r3k69AVbb+np0wLZVWjd6FESty9CJOhY6UXAUQ d5MUqHj/1wPvzfIfyhSCJ+VM2WHS/7vxtokvR38UNqCXgkWab+hjM/KhGoXwjR1zF+RD yVpqWTtGbDNkTIZESEhIjrID+MlhlCWFiTTBU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=CXsQs7/vh/GAQCUlPP9H/YHwT450ozgj5HSpseMqKC7rWEcKDxR6nCRnDNfIkz4HlT YK2XRiFWCBtwdfnsND56mU63z4W+VQmKWnkMv3M/o90WI9IEiCHSaecL14C3pCzPcXfy wFHZbeIlbQZ4A4GOe2Z2nLMLV0YXfKOIDHQVk= Received: by 10.229.114.200 with SMTP id f8mr5644463qcq.68.1306962624070; Wed, 01 Jun 2011 14:10:24 -0700 (PDT) Received: from bxb-rdroms-8711.cisco.com (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id j18sm913405qck.39.2011.06.01.14.10.21 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2011 14:10:22 -0700 (PDT) Subject: Re: Multiple addresses [was Node Requirements: Elevating DHCPv6 from MAY to SHOULD] Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <201106012042.p51KgVud023906@cichlid.raleigh.ibm.com> Date: Wed, 1 Jun 2011 17:10:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DE3F87A.5060502@globis.net> <4DE40821.9030205@gmail.com> <4DE420E2.6010207@globis.net> <4DE5536D.9050906@globis.net> <4DE554F9.20603@globis.net> <4DE55815.3080702@gmail.com> <201106012042.p51KgVud023906@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1084) Cc: Ray Hunter , ipv6@ietf.org, Ralph Droms , Brian E Carpenter X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 21:10:27 -0000 On Jun 1, 2011, at 4:42 PM 6/1/11, Thomas Narten wrote: > Brian E Carpenter writes: >=20 >> Ray, >=20 >> Without going into details: how about turning this into >> draft-hunter-v6ops-something and having the debate over in v6ops? >=20 >> I think that would be useful, personally. >=20 > Actually, let me suggest something else. >=20 > Before spending a whole lot of time on this topic, is there anyone > else who thinks there is a problem here that needs solving? The last > thing we (as a group) need to do is spend time on a non-problem. >=20 > Personally, I don't see the issue here. I think the problem as stated > is a non-problem. And to be honest, this is the first time I have > heard anyone suggest what you describe is a real problem. So I wonder > whether anyone else thinks there is a problem here that needs fixing. I don't think there is a problem worth fixing. >=20 > To the point: >=20 >>> Ray Hunter wrote: >>>> It's definitely going to become an operational FAQ, unless it is = very >>>> clear whether/how a network operator can force equivalent use of >>>> DHCPv4 static address assignment for both source and destination >>>> addresses via DHCPv6 (possibly by turning off SLAAC for assignment = of >>>> GUA on an interface via a flag, or via RFC3484 bis), and how to >>>> achieve this effect for all nodes on a link, without resorting to >>>> local configuration. So I may as well be the first to ask. >=20 > A fine way to deal with this problem is not advertise any prefixes in > RAs for stateless address autoconfiguration. The network operator is > in control here. They decide how/whether DHCP and/or SLAAC is used. I recently wrote: Use of SLAAC is controlled by the A bit in the Prefix = Information option. If the A bit is zero, the host will not configure = an address on the receiving interface using SLAAC. =20 The M bit in an RA gives a hint that DHCPv6 service is available. The = host behavior is not entirely controlled by the M bit; a host can choose = to run DHCPv6 independent of the setting of the M bit. A reasonable = host might not bother with DHCPv6 if the M bit is 0; at the same time, a = reasonable host might go ahead with DHCPv6 if it doesn't receive any = Prefix Information options with the A bit set to one. >=20 > Why is this not sufficient? Sounds sufficient to me... - Ralph >=20 > Thomas=09 From brian.e.carpenter@gmail.com Wed Jun 1 15:09:11 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 463ACE08E8 for ; Wed, 1 Jun 2011 15:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.61 X-Spam-Level: X-Spam-Status: No, score=-102.61 tagged_above=-999 required=5 tests=[AWL=-0.971, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1, 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 NEjbO2KUOxpg for ; Wed, 1 Jun 2011 15:09:10 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id DE56BE070A for ; Wed, 1 Jun 2011 15:09:10 -0700 (PDT) Received: by pwi5 with SMTP id 5so251699pwi.31 for ; Wed, 01 Jun 2011 15:09:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6Ox8gpxYI+Wv3fVjxcblp5Xc/vuMdU9UgOhpjMwXwu0=; b=x21WKiFutbqVQEExWk2IK0lLoS0ws2nb/EjyFxLkDZXfbHrk4LeU8S9cY4wi/U5png MqqTbJ8gPacnUm2HO6OcZLLB+UNjyO4V7qQCDutr+kYYLRAqb4sRjkD6dBr9aLXDezW1 Kz6Hg2IlGcxqmfMym7XG+I6NB8dwP43norEMM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=l6ecYQeDu8Il/6IvM7cHyQT9Wda8FEcxa3hmJcuEZNCqOq9mjYYjQY6skafC8M45SI jwk7ih/uUb2XYZ1yLaa7u6fQb3HWAxirypQ6ieb+f3sPKItClmunWIkUmURT/xFX7si4 TLvBK8lFL/r2VVgRpMKO330tip06GNLpt/uQM= Received: by 10.68.41.9 with SMTP id b9mr8412pbl.84.1306966150660; Wed, 01 Jun 2011 15:09:10 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id o2sm1424082pbj.49.2011.06.01.15.09.08 (version=SSLv3 cipher=OTHER); Wed, 01 Jun 2011 15:09:09 -0700 (PDT) Message-ID: <4DE6B87F.8030902@gmail.com> Date: Thu, 02 Jun 2011 10:09:03 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fernando Gont Subject: Re: Preliminary report on flow label hash algorithms References: <4DE5CA6F.6080803@gmail.com> <4DE68A71.7040909@gont.com.ar> In-Reply-To: <4DE68A71.7040909@gont.com.ar> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 22:09:11 -0000 Fernando, My to-do list included running your algorithm against the same datasets. However, I just looked at your draft again and it seems to be underspecified - you do not define what functions F and G are. And I think it's stateful, because of the statement "if(three-tuple is unique)". All we are discussing is a non-normative suggested algorithm, so this is not critical for the draft to go forward IMHO. Brian On 2011-06-02 06:52, Fernando Gont wrote: > On 06/01/2011 02:13 AM, Brian E Carpenter wrote: >> In summary: the algorithm suggested in the Appendix to >> draft-ietf-6man-flow-3697bis-04 doesn't perform very well >> on real packets, and I have an improved version to suggest. > > Sorry if I'm missing something: Any reasons for which you chose a > different algorithm from the one described in > draft-gont-6man-flowlabel-security? > > The algorithm in the aforementioned I-D has already been well tested for > randomizing TCP port numbers, timestamps, and sequence numbers. -- and I > don't think there's a real need to reinvent the wheel. > > Thanks, From fernando.gont.netbook.win@gmail.com Wed Jun 1 16:19:44 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3EF8E0815 for ; Wed, 1 Jun 2011 16:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 8lqurBkvmu1c for ; Wed, 1 Jun 2011 16:19:44 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id E4142E07EC for ; Wed, 1 Jun 2011 16:19:43 -0700 (PDT) Received: by gxk19 with SMTP id 19so163447gxk.31 for ; Wed, 01 Jun 2011 16:19:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=1SP2mMPPKxnHHszD/Z+yBxPAAyEErlud2PV5CgvEWG0=; b=QuWOVQLzgbiZZqTP/tzNSpzlzic9CKve5ETveAOImpCXjw24EGT/spM7afVWKn3rhG AjUo0nWM5FruhiSLkT4NwZt5oWahvj+bCIRZYPO5Is3B099KTKDRm9ZQIOsKqewie5PI jmfuurAGyp8k35/894eUn0C7c63vyzsLRPvrg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=Ukj5eQ+KZxL/O0KNnI7JqHcH1rpj25xCgNm7YxToaot6M9eCoKQjNUEBKkW0V1Zg1V AFS1YFzKG4LrHjsXlP9Dn8xABpNLpnyAPza5IpWH0y2hDmsPITPqsBuheuuXIy2Au2Po iDz3xu8sqgd5e+N7q8iDRFfkUqVNrcCgPcEcw= Received: by 10.91.156.10 with SMTP id i10mr110389ago.67.1306970383071; Wed, 01 Jun 2011 16:19:43 -0700 (PDT) Received: from [192.168.123.103] ([190.48.203.155]) by mx.google.com with ESMTPS id c26sm40359ana.21.2011.06.01.16.19.39 (version=SSLv3 cipher=OTHER); Wed, 01 Jun 2011 16:19:41 -0700 (PDT) Sender: Fernando Gont Message-ID: <4DE6C909.9020903@gont.com.ar> Date: Wed, 01 Jun 2011 20:19:37 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: Preliminary report on flow label hash algorithms References: <4DE5CA6F.6080803@gmail.com> <4DE68A71.7040909@gont.com.ar> <4DE6B87F.8030902@gmail.com> In-Reply-To: <4DE6B87F.8030902@gmail.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 23:19:44 -0000 Hi, Brian, On 06/01/2011 07:09 PM, Brian E Carpenter wrote: > My to-do list included running your algorithm against the > same datasets. However, I just looked at your draft again and > it seems to be underspecified - you do not define what functions > F and G are. To some extent, this was intentional. -- Although I do agree I should have noted (non-normatively) that MD5 would be a good choice for F(). As for G(), one could use MD5(), or even something simpler. > And I think it's stateful, because of the statement > "if(three-tuple is unique)". Not sure what you mean. The specs themselves argue that a flowid shouldn't be reused if it's already in use. So one could envision that the flowid used for a communication instance is stored in the corresponding TCB, and that's how it is checked. Anyway, the same algorithm could be used without performing that check, and simply having faith in the algorithm on the fact that collisions will not occur. :-) > All we are discussing is a non-normative suggested algorithm, > so this is not critical for the draft to go forward IMHO. It looks like such an algorithm would belong to a separate document -- particularly if the suggestion is going to be "non-normative". i.e., a separate document could evaluate different algorithms, in a similar way we have done so for transport protocol port number randomization. -- BTW, still wondering what could be a sensible way forward for draft-gont-6man-flowlabel-security. Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From brian.e.carpenter@gmail.com Wed Jun 1 17:01:23 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD15FE0715 for ; Wed, 1 Jun 2011 17:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=-0.920, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1, 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 8td92aiyO353 for ; Wed, 1 Jun 2011 17:01:22 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id ACB36E065B for ; Wed, 1 Jun 2011 17:01:22 -0700 (PDT) Received: by pwi5 with SMTP id 5so285157pwi.31 for ; Wed, 01 Jun 2011 17:01:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5O3nfGPeqdhLtQd33Dv63g7+oaf+bmRu8ImOQ58Swk4=; b=fDgIHmcDQN7AyDzam69EV7qFrOU9wBvY3jsBGLZPWEg2uQoTCBfJTWj59OJ9RtYFQN a6TLNiKIBDx2e91m7B1FHKj1er9CutYRUOCW0dcswZf5EVJcRn0BI+RgF+pN/nZBucKn rJAVNj8B7YcnpcfqDc8/Sk+GWPY/oNQr2Cvdo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=fWc/SSgjBAEK+4HPC7ZNl/PQIjf3ZJmden3Hoapz8r3Qy3AzLVHCkY6vUVF5qihjuO t8aR2rhNnPfDuQBAiSAS0DBRnUaXk2d73DyuE+vTNCPRijllHwoMyVXSbry8nbxvAJWk k3Ns5VWRb9tTYdGoDkTkFjvd/DfeEv6UQLYCY= Received: by 10.68.16.100 with SMTP id f4mr42024pbd.57.1306972882212; Wed, 01 Jun 2011 17:01:22 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id m9sm59748pbd.39.2011.06.01.17.01.20 (version=SSLv3 cipher=OTHER); Wed, 01 Jun 2011 17:01:21 -0700 (PDT) Message-ID: <4DE6D2D4.8040905@gmail.com> Date: Thu, 02 Jun 2011 12:01:24 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fernando Gont Subject: Re: Preliminary report on flow label hash algorithms References: <4DE5CA6F.6080803@gmail.com> <4DE68A71.7040909@gont.com.ar> <4DE6B87F.8030902@gmail.com> <4DE6C909.9020903@gont.com.ar> In-Reply-To: <4DE6C909.9020903@gont.com.ar> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 00:01:24 -0000 On 2011-06-02 11:19, Fernando Gont wrote: > Hi, Brian, > > On 06/01/2011 07:09 PM, Brian E Carpenter wrote: >> My to-do list included running your algorithm against the >> same datasets. However, I just looked at your draft again and >> it seems to be underspecified - you do not define what functions >> F and G are. > > To some extent, this was intentional. -- Although I do agree I should > have noted (non-normatively) that MD5 would be a good choice for F(). > > As for G(), one could use MD5(), or even something simpler. OK. >> And I think it's stateful, because of the statement >> "if(three-tuple is unique)". > > Not sure what you mean. The specs themselves argue that a flowid > shouldn't be reused if it's already in use. That was RFC3697. RFC3697bis is more relaxed about this point, because it isn't an essential property for load balancing. If uniqueness is a hard requirement, you're definitely forced into a stateful model, but that is out of scope for 3697bis. > So one could envision that > the flowid used for a communication instance is stored in the > corresponding TCB, and that's how it is checked. > > Anyway, the same algorithm could be used without performing that check, > and simply having faith in the algorithm on the fact that collisions > will not occur. :-) Or that they don't matter too much... >> All we are discussing is a non-normative suggested algorithm, >> so this is not critical for the draft to go forward IMHO. > > It looks like such an algorithm would belong to a separate document -- > particularly if the suggestion is going to be "non-normative". i.e., a > separate document could evaluate different algorithms, in a similar way > we have done so for transport protocol port number randomization. Yes, the topic is quite complex and I can think of many more tests I could run, if my time was infinite. All we really need for now is a not-completely-lame algorithm as an illustration for 3697bis. > -- BTW, still wondering what could be a sensible way forward for > draft-gont-6man-flowlabel-security. What I have learnt doing these tests is that it's complex (as noted) and maybe it's too soon to know the best approach. Brian From kauer@biplane.com.au Wed Jun 1 17:36:22 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A055E0758 for ; Wed, 1 Jun 2011 17:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 O6fmtWifEqay for ; Wed, 1 Jun 2011 17:36:16 -0700 (PDT) Received: from syd-srv03.ezyreg.com (syd-srv03.ezyreg.com [117.58.251.4]) by ietfa.amsl.com (Postfix) with ESMTP id 8C352E08BD for ; Wed, 1 Jun 2011 17:36:15 -0700 (PDT) Received: from igw.biplane.com.au ([203.26.128.2] helo=[192.168.1.202]) by syd-srv03.ezyreg.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QRvtV-0007Wl-Dr for ipv6@ietf.org; Wed, 01 Jun 2011 20:36:13 -0400 Subject: Re: Ra-Guard evasion (new Internet-Drafts) From: Karl Auer To: IETF IPv6 In-Reply-To: <4DE674CC.2000402@gont.com.ar> References: <4DE674CC.2000402@gont.com.ar> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-GLagp0677s7Tocdj1s+4" Date: Thu, 02 Jun 2011 10:36:12 +1000 Message-ID: <1306974972.5839.185.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - syd-srv03.ezyreg.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - biplane.com.au X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 00:36:22 -0000 --=-GLagp0677s7Tocdj1s+4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2011-06-01 at 14:20 -0300, Fernando Gont wrote: > * "IPv6 Router Advertisement Guard (RA-Guard) Evasion", available at: > http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-00.txt Section 1, second para: "of identifying" should be "to identify" Section 1, third para: "had so far been" should be "have so far been" Section 1, third para: "deemed as appropiate" should be "deemed appropriate" Section 1, fourth para: The techniques could *probably* be exploited. And maybe mention DHCPv6 here as well...? Section 2.1, first sentence is missing words or something. No legitimate what? Section 2.1 first para: should be "simply ignoring". Suggest leaving "simple", "simply" etc out of such sentences. It might not be simple at all. Section 2.1 second para: should be "implement" not "implements" Page 6: This might be a silly thought, but why would the implementation need to do fragment reassembly? All it needs to do is locate RAs, whether they are in fragments or not. It has all the info it needs in the fragment with the RA. That is, it passes earlier packets, but if a fragment arrives with an RA in it, it checks the RA. The destination might end up with a partial packet, but it will never get the damaging fragment, and will eventually discard the partial. End of Section 2.2: "it should be obvious" - well, it isn't :-) Definitely expand on precisely why. Regards, K. PS: Responding on this list, rather than NANOG - is that OK? --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 --=-GLagp0677s7Tocdj1s+4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk3m2vwACgkQMAcU7Vc29od0cwCfcemADvp/+XJweKvtMZ+5srsE kucAoNLNBPqYfaVfR/pEnqzcpqqD1y99 =RAL6 -----END PGP SIGNATURE----- --=-GLagp0677s7Tocdj1s+4-- From stephen.farrell@cs.tcd.ie Sat Jun 4 09:54:04 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93F86E06B9; Sat, 4 Jun 2011 09:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 s6gU-EdC3jVT; Sat, 4 Jun 2011 09:54:04 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id E01BAE06B2; Sat, 4 Jun 2011 09:54:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 20B58171D91; Sat, 4 Jun 2011 17:54:00 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1307206438; bh=ZNv1PzZdQgCkhfWeprDHLp+p HqWZY5nSGvhTAoUJvSs=; b=a7/DTDvZUEAVjktgVI++zu/ee6AImye5r7VDKJnY Cy7p6yMMqBbOSSdN8nGdELcTZkIGWRU+cesUJzko6BRFDjX1MiCLHDgPPUTORHCP lGCbyYi4N9IwEGWB5eUt2gjfP4xGGDU7FcmTkyz877ET0Tv1zs7IBY4kuN+SMre0 QJJasZSEr19y8B7cG2hsTd1w1yND4f/+3KdaCX2DcQ1DmMsAE/HDUz5Wz5+/ioIQ r6PQaZQB5nHuLQwmrOxw4889ZVAoHCAyOBIbgXWarHfxypmYrzXQVtQuiOJN3wFo cCltyseGiNyYZ3Ya3ICwZxSx//J91NFCt9vAAPa07doF6Q== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 71PooJeNHN6f; Sat, 4 Jun 2011 17:53:58 +0100 (IST) Received: from [10.87.48.9] (unknown [86.45.54.169]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id D391F171C03; Sat, 4 Jun 2011 17:53:55 +0100 (IST) Message-ID: <4DEA6323.4070302@cs.tcd.ie> Date: Sat, 04 Jun 2011 17:53:55 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: "saag@ietf.org" , ipv6@ietf.org, v6ops@ietf.org Subject: ITU-T SG17 IPv6 security work items liaison X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 04 Jun 2011 11:00:10 -0700 Cc: "Turner, Sean P." , Eliot Lear X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2011 16:54:04 -0000 Hi all, We received a liaison [1] from ITU-T saying they're planning to start a couple of work items on the security of IPv6. As far as we know, they envisage developing a "technical guideline on deploying IPv6" and "Security Management Guideline for implementation of IPv6 environment in telecommunications organizations." Bear in mind that they're just starting so they know about as much as we would just before a BoF or something like that. I think we'd like to respond to them that that's great, and we'll be interested in their results, but can they *please* come back to us before saying something should be changed so's we can talk about it. If you've comments or ideas on that, please respond to this in the next week. At that point, we'll get some help translating this into liaison-speak (thanks Eliot:-) and send the result to these lists for a quick check before shipping it off to the ITU-T folks. Cheers, S. [1] https://datatracker.ietf.org/liaison/1047/ From john@jlc.net Sat Jun 4 20:10:53 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC5D11E8088; Sat, 4 Jun 2011 20:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 3wHeI-wCxaHm; Sat, 4 Jun 2011 20:10:52 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2F211E8077; Sat, 4 Jun 2011 20:10:46 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id ED3AA33C21; Sat, 4 Jun 2011 23:10:45 -0400 (EDT) Date: Sat, 4 Jun 2011 23:10:45 -0400 From: John Leslie To: Stephen Farrell Subject: Re: ITU-T SG17 IPv6 security work items liaison Message-ID: <20110605031045.GK88250@verdi> References: <4DEA6323.4070302@cs.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DEA6323.4070302@cs.tcd.ie> User-Agent: Mutt/1.4.1i Cc: "Turner, Sean P." , v6ops@ietf.org, ipv6@ietf.org, "saag@ietf.org" , Eliot Lear X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 03:10:53 -0000 Stephen Farrell wrote: > > We received a liaison [1] from ITU-T saying they're > planning to start a couple of work items on the > security of IPv6. As far as we know, they envisage > developing a "technical guideline on deploying IPv6" > and "Security Management Guideline for implementation > of IPv6 environment in telecommunications > organizations." Bear in mind that they're just starting > so they know about as much as we would just before a > BoF or something like that. > > I think we'd like to respond to them that that's great, > and we'll be interested in their results, but can they > *please* come back to us before saying something should > be changed so's we can talk about it. I don't think that's quite right. We should welcome their studying security issues; but I think we need to _strongly_ encourage them to start from draft-ietf-6man-node-req-bis when it becomes an RFC -- since it has _significant_ changes from RFC 4294 (and an ITU-T study based on RFC4294 will be of rather limited value). Furthermore, ITU-T should NOT propose "changes" to IPv6 protocol or the Node Requirements. The language there should talk of documenting security "concerns" or "issues" or whatever term seems neutral enough; and list as the next step exchanging ideas of what "changes" might help. Clearly, ITU-T is entirely justified in publishing recommendations of what level of security-related-trust to place in IPv6 packet forwarding: but any protocol _changes_ are outside their bailiwick. (As an aside, IETF should resist most proposals for change until IPv6 sees widespread deployment -- deploying to a moving target is just TOO risky.) -- John Leslie From fred@cisco.com Sat Jun 4 23:10:28 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B6E21F849E; Sat, 4 Jun 2011 23:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 8H3oCAwa3c5W; Sat, 4 Jun 2011 23:10:28 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC5921F849C; Sat, 4 Jun 2011 23:10:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1273; q=dns/txt; s=iport; t=1307254228; x=1308463828; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=E+G5E4waGRozGgDTvx/8cuWzmvINw4JL+cVxXGBxqHY=; b=jkOfpEIAA67lx14v9243aKouM1YKn+9NoHflHuVfQjdB1p68WOFS1f1G GCk6sRNvIM888qaQBInQBiTRY7HfytSMOcbckfZUmNijScA+VIhTFwxra CLxgaPhrNF+nc0v4ckNFRakyJo8MoNOmhyvkyhPsCYrkfWiswIA7l2HSu Q=; X-IronPort-AV: E=Sophos;i="4.65,321,1304294400"; d="scan'208";a="459906997" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 05 Jun 2011 06:10:26 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p556ALrJ003107; Sun, 5 Jun 2011 06:10:26 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Sat, 04 Jun 2011 23:10:26 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Sat, 04 Jun 2011 23:10:26 -0700 Subject: Re: [v6ops] ITU-T SG17 IPv6 security work items liaison Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <4DEA6323.4070302@cs.tcd.ie> Date: Sat, 4 Jun 2011 23:10:11 -0700 Message-Id: References: <4DEA6323.4070302@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "Turner, Sean P." , v6ops@ietf.org, ipv6@ietf.org, "saag@ietf.org" , Eliot Lear X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 06:10:28 -0000 On Jun 4, 2011, at 9:53 AM, Stephen Farrell wrote: > I think we'd like to respond to them that that's great, > and we'll be interested in their results, but can they > *please* come back to us before saying something should > be changed so's we can talk about it. That seems like a reasonable proposal.=20 There a, of course, several proposed sets of security guidelines for = IPv6 floating in the breeze. If you want my druthers, I would like to = see a comprehensive security *architecture*. Steve Kent wrote to me last = month, on another topic, saying > I do have a few comments about the discuss of secruity, in general. I = see that you used the CIA model for describing security = requirements/services. Although this is a commonly used model, I find it = inferior to the model that was developed by ISO in the mid 80's (ISO = 7498-2). It might be worthwhile to look at the ISO model he suggests as a = possible starting point.=20 To my mind, anything resembling a security architecture will identify = threats at the physical, link, network (LAN and IP), transport, and = applications layers, and make recommendations for addressing them - and = not start from the premise of a global federated identity, which doesn't = exist.= From tena@huawei.com Sat Jun 4 23:25:16 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0354111E808C; Sat, 4 Jun 2011 23:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 kTTktb-9HJnn; Sat, 4 Jun 2011 23:25:15 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5DB11E8072; Sat, 4 Jun 2011 23:25:15 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMB002S70I0M9@usaga02-in.huawei.com>; Sun, 05 Jun 2011 01:25:13 -0500 (CDT) Received: from TingZousc1 ([10.212.246.21]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LMB00KSJ0HW7G@usaga02-in.huawei.com>; Sun, 05 Jun 2011 01:25:12 -0500 (CDT) Date: Sat, 04 Jun 2011 23:25:03 -0700 From: Tina Tsou Subject: RE: [v6ops] ITU-T SG17 IPv6 security work items liaison In-reply-to: To: 'Fred Baker' , 'Stephen Farrell' Message-id: <020601cc2349$530f5400$f92dfc00$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcwjR4ZQpJGdiSiJTVadap3krXe/CwAAbBaw References: <4DEA6323.4070302@cs.tcd.ie> Cc: "'Turner, Sean P.'" , ipv6@ietf.org, v6ops@ietf.org, 'Eliot Lear' , saag@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 06:25:16 -0000 Hi, RFC 4775 is the process to follow. We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Fred Baker Sent: Saturday, June 04, 2011 11:10 PM To: Stephen Farrell Cc: Turner, Sean P.; v6ops@ietf.org; ipv6@ietf.org; saag@ietf.org; Eliot Lear Subject: Re: [v6ops] ITU-T SG17 IPv6 security work items liaison On Jun 4, 2011, at 9:53 AM, Stephen Farrell wrote: > I think we'd like to respond to them that that's great, > and we'll be interested in their results, but can they > *please* come back to us before saying something should > be changed so's we can talk about it. That seems like a reasonable proposal. There a, of course, several proposed sets of security guidelines for IPv6 floating in the breeze. If you want my druthers, I would like to see a comprehensive security *architecture*. Steve Kent wrote to me last month, on another topic, saying > I do have a few comments about the discuss of secruity, in general. I see that you used the CIA model for describing security requirements/services. Although this is a commonly used model, I find it inferior to the model that was developed by ISO in the mid 80's (ISO 7498-2). It might be worthwhile to look at the ISO model he suggests as a possible starting point. To my mind, anything resembling a security architecture will identify threats at the physical, link, network (LAN and IP), transport, and applications layers, and make recommendations for addressing them - and not start from the premise of a global federated identity, which doesn't exist. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From fred@cisco.com Sat Jun 4 23:33:41 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8955711E808C; Sat, 4 Jun 2011 23:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, 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 ZyAWNNSOAZEj; Sat, 4 Jun 2011 23:33:40 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6CA11E8072; Sat, 4 Jun 2011 23:33:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1585; q=dns/txt; s=iport; t=1307255620; x=1308465220; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=gBI06pG8hja0PoRnlP78Ei2x232f8DDCsM2JN7aXahQ=; b=gLEckFLJxIGOLx3ipwVvBPhVAXX1gxndLw/JV0iOTfMewyopSg0VG7ng ZXFXXeUpnVBqJ6cDwxOy/j0Tf33lnPk1T0878KfjIgUVLTQvPjHy/WEMV i104iuQAFo26xVAL8BMxPoJ/QLjlfYJMx+14SoyuUqnJYEq5iF4RIv8ON g=; X-IronPort-AV: E=Sophos;i="4.65,321,1304294400"; d="scan'208";a="330349821" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 05 Jun 2011 06:33:40 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p556XYgD019240; Sun, 5 Jun 2011 06:33:39 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Sat, 04 Jun 2011 23:33:40 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Sat, 04 Jun 2011 23:33:40 -0700 Subject: Re: [v6ops] ITU-T SG17 IPv6 security work items liaison Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Sat, 4 Jun 2011 23:33:24 -0700 Message-Id: <1B36FABA-D389-4804-A45B-8F49BD7D8ECB@cisco.com> References: <4DEA6323.4070302@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "Turner, Sean P." , 6man Mailing List , IPv6 Operations Working Group , Eliot Lear , saag@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 06:33:41 -0000 BTW, in case it wasn't clear, I think the IETF should do that = architecture. On Jun 4, 2011, at 11:10 PM, Fred Baker wrote: >=20 > On Jun 4, 2011, at 9:53 AM, Stephen Farrell wrote: >=20 >> I think we'd like to respond to them that that's great, >> and we'll be interested in their results, but can they >> *please* come back to us before saying something should >> be changed so's we can talk about it. >=20 > That seems like a reasonable proposal.=20 >=20 > There a, of course, several proposed sets of security guidelines for = IPv6 floating in the breeze. If you want my druthers, I would like to = see a comprehensive security *architecture*. Steve Kent wrote to me last = month, on another topic, saying >=20 >> I do have a few comments about the discuss of secruity, in general. I = see that you used the CIA model for describing security = requirements/services. Although this is a commonly used model, I find it = inferior to the model that was developed by ISO in the mid 80's (ISO = 7498-2). >=20 > It might be worthwhile to look at the ISO model he suggests as a = possible starting point.=20 >=20 > To my mind, anything resembling a security architecture will identify = threats at the physical, link, network (LAN and IP), transport, and = applications layers, and make recommendations for addressing them - and = not start from the premise of a global federated identity, which doesn't = exist. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From arturo.servin@gmail.com Sun Jun 5 13:31:04 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A34221F84BC; Sun, 5 Jun 2011 13:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 1gmi-9yfQfRU; Sun, 5 Jun 2011 13:31:03 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id DCBC521F84BB; Sun, 5 Jun 2011 13:30:59 -0700 (PDT) Received: by wyb29 with SMTP id 29so2873179wyb.31 for ; Sun, 05 Jun 2011 13:30:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=JhPE23+t/7g7fRBD7ic0InIjd0Ip/qZ8bHxVe6CqBUA=; b=mo+YtVdGIqwjxyPWBBTOSSxIfWbPu6A86dNtxTqyKECRu+MtSJBIMYoXVRH8EmIOBW vvhZ755aO489tA/rKl4RrQl2yD6s9yhOxOSVRxY+DEpwlCiMpypoiloTy9mgu+cD8ihJ 4jlAwMezf+ernZj4WBiXhl4tODfmIokZmE7Ks= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=Qg/zxP9mxtVjNY0tzA192wyWjN5C9iy1rXZKdnlbVX/w6fyjjiv85uOS8wwuS3S+vn j1NNbnVSsti8E/DpczqSWfVbeEIFYe5wIwD6Hn8Xj/hI68eG/cYRYAqPHQpAdREirBE9 cc6MoxNgrtUMkZopx++H2PSIXP6dgfftHlKAE= Received: by 10.227.57.148 with SMTP id c20mr4231397wbh.54.1307305858776; Sun, 05 Jun 2011 13:30:58 -0700 (PDT) Received: from [10.225.103.220] ([83.111.212.208]) by mx.google.com with ESMTPS id o38sm2424267wba.3.2011.06.05.13.30.56 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 05 Jun 2011 13:30:58 -0700 (PDT) Subject: Re: ITU-T SG17 IPv6 security work items liaison Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Arturo Servin In-Reply-To: <20110605031045.GK88250@verdi> Date: Sun, 5 Jun 2011 17:30:54 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DEA6323.4070302@cs.tcd.ie> <20110605031045.GK88250@verdi> To: IPv6 Operations , ipv6@ietf.org X-Mailer: Apple Mail (2.1084) Cc: "Turner, Sean P." , saag@ietf.org, Eliot Lear , Stephen Farrell X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 20:31:04 -0000 I do not see why the ITU has to start from zero. There are = several (or some at least) very good RFC and I+D documents related to = IPv6 security. I think we should recommend them to ITU, it is good that = they let us know, it would be better if they use our work as a = foundation. just my 20 cents -as On 5 Jun 2011, at 00:10, John Leslie wrote: > Stephen Farrell wrote: >>=20 >> We received a liaison [1] from ITU-T saying they're >> planning to start a couple of work items on the >> security of IPv6. As far as we know, they envisage >> developing a "technical guideline on deploying IPv6" >> and "Security Management Guideline for implementation >> of IPv6 environment in telecommunications >> organizations." Bear in mind that they're just starting >> so they know about as much as we would just before a >> BoF or something like that. >>=20 >> I think we'd like to respond to them that that's great, >> and we'll be interested in their results, but can they >> *please* come back to us before saying something should >> be changed so's we can talk about it. >=20 > I don't think that's quite right. We should welcome their studying > security issues; but I think we need to _strongly_ encourage them to > start from draft-ietf-6man-node-req-bis when it becomes an RFC -- = since > it has _significant_ changes from RFC 4294 (and an ITU-T study based > on RFC4294 will be of rather limited value). >=20 > Furthermore, ITU-T should NOT propose "changes" to IPv6 protocol > or the Node Requirements. The language there should talk of = documenting > security "concerns" or "issues" or whatever term seems neutral enough; > and list as the next step exchanging ideas of what "changes" might = help. >=20 > Clearly, ITU-T is entirely justified in publishing recommendations > of what level of security-related-trust to place in IPv6 packet > forwarding: but any protocol _changes_ are outside their bailiwick. >=20 > (As an aside, IETF should resist most proposals for change until > IPv6 sees widespread deployment -- deploying to a moving target is > just TOO risky.) >=20 > -- > John Leslie > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From arturo.servin@gmail.com Sun Jun 5 15:28:13 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C87F7228007 for ; Sun, 5 Jun 2011 15:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] 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 1Ik+xOhs4PAL for ; Sun, 5 Jun 2011 15:28:13 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7F521F84F7 for ; Sun, 5 Jun 2011 15:28:12 -0700 (PDT) Received: by wwa36 with SMTP id 36so2164542wwa.13 for ; Sun, 05 Jun 2011 15:28:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to:x-mailer; bh=ApPDyyeWlX5qd7CfOU3SYQvSwEdHJUeoBrALcuadsRM=; b=hZQsGFsEstV31tszOSpTMi6qnh1Z54y1kmRkkMIz1Eq/tzcc0+tZ/bOXB/XYR+MzNU +/M7PaHrq9FjD7EhaqU2W9H+oU58fDzci3tdMCgMR1b1GJy06xgied6zFLoslyFRFd7Z paZBHvrNi5u+5Jz3m5RWiL8HQvP4baJPK8UMw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=UlJDXYHQzKgd90f4W1aTTFKfbyjVq1yjOvZPGKcX/DYh263Bw8YEq2Kj/iQqt5ejGg K8a4WB+sXm466jS8Pu+1hIyLWfMRCD+4LlpdytocWnum+djWlYzc2sHxb/Poz26mE+Hs 7BObVxiXL56vVm8TbBU4h5/Lm4ZKN/VBAEgxM= Received: by 10.216.232.146 with SMTP id n18mr4016873weq.93.1307312891689; Sun, 05 Jun 2011 15:28:11 -0700 (PDT) Received: from [10.225.103.220] ([83.111.212.208]) by mx.google.com with ESMTPS id d7sm1991589wek.21.2011.06.05.15.28.09 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 05 Jun 2011 15:28:11 -0700 (PDT) Subject: Re: New I-D: Neighbor Discovery and IPv6 Extension Headers (draft-gont-6man-nd-extension-headers) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-5-440689703 From: Arturo Servin In-Reply-To: <4DE556A9.2050702@gont.com.ar> Date: Mon, 6 Jun 2011 02:28:07 +0400 Message-Id: <1B9CD0F7-9B70-412D-8A36-AE551D84DB28@gmail.com> References: <4DE556A9.2050702@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1084) Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 22:28:13 -0000 --Apple-Mail-5-440689703 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Fernando, Some comments. Minor, typos, etc. I think you missed the reference to RFC 6105, this is the same = problem with the reference than = http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-00.txt May be it is just me and the excess of caffeine but the third = paragraph of section 1 is a bit long and hard to understand. I would = recommend some rephrasing.=20 Other: In section 2. I think it has to be a MUST instead of SHOULD. In section 3, I think you should add a paragraph saying that = even with the filtering rules described in = http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-00.txt there = is a important cost in complexity and performance for devices performing = those filters (l2-switches, IDS/IPS/FWS, etc.) Regards, -as On 1 Jun 2011, at 00:59, Fernando Gont wrote: > Folks, >=20 > I have just published a new Internet-Draft > (draft-gont-6man-nd-extension-headers) entitled "Security Implications > of the Use of IPv6 Extension Headers with IPv6 Neighbor Discovery". >=20 > The I-D is available at: > http://tools.ietf.org/id/draft-gont-6man-nd-extension-headers-00.txt >=20 > The Abstract of the I-D is: > ---- cut here ---- > IPv6 Extension Headers with Neighbor Discovery messages can be > leveraged to circumvent simple local network protections, such as > "Router Advertisement Guard". Since there is no legitimate use for > IPv6 Extension Headers in Neighbor Discovery messages, and such use > greatly complicates network monitoring and simple security > mitigations such as RA-Guard, this document proposes that hosts > silently ignore Neighbor Discovery messages that use IPv6 Extension > Headers. > ---- cut here ---- >=20 > Note: A closely related (and just published) I-D is > draft-gont-v6ops-ra-guard-evasion-00, which is aimed at the v6ops wg > (rather than 6man). >=20 > Any comments on any of these I-Ds will be very welcome. >=20 > Thanks! >=20 > Best regards, > --=20 > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail-5-440689703 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Some = comments.

Minor, typos, = etc.

I think you missed the reference = to RFC 6105, this is the same problem with the reference than http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-00.txt

May be it is just me and the = excess of caffeine but the third paragraph of section 1 is a bit long = and hard to understand. I would recommend some = rephrasing. 

= Other:

In section 2. I think it has to = be a MUST instead of SHOULD.

In = section 3, I think you should add a paragraph saying that even with the = filtering rules described in http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-00.txt&nbs= p;there is a important cost in complexity and performance for devices = performing those filters (l2-switches, IDS/IPS/FWS, = etc.)

Regards,
-as

=


On 1 Jun 2011, at 00:59, = Fernando Gont wrote:

Folks,

I have just published a new = Internet-Draft
(draft-gont-6man-nd-extension-headers) entitled = "Security Implications
of the Use of IPv6 Extension Headers with IPv6 = Neighbor Discovery".

The I-D is available at:
http://tools.ietf.org/id/draft-gont-6man-nd-extension-headers-00.txt

The Abstract of the I-D is:
---- cut here ----
=   IPv6 Extension Headers with Neighbor Discovery messages can = be
  leveraged to circumvent simple local network = protections, such as
  "Router Advertisement Guard". =  Since there is no legitimate use for
  IPv6 = Extension Headers in Neighbor Discovery messages, and such use
=   greatly complicates network monitoring and simple = security
  mitigations such as RA-Guard, this document = proposes that hosts
  silently ignore Neighbor Discovery = messages that use IPv6 Extension
  Headers.
---- cut = here ----

Note: A closely related (and just published) I-D = is
draft-gont-v6ops-ra-guard-evasion-00, which is aimed at the v6ops = wg
(rather than 6man).

Any comments on any of these I-Ds will = be very welcome.

Thanks!

Best regards,
--
Fernando = Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP = Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 = FFF1



------------------------------------------------------= --------------
IETF IPv6 working group mailing = list
ipv6@ietf.org
Administrative Requests: = https://www.ietf.org/mailman/listinfo/ipv6
----------------------------= ----------------------------------------

<= /body>= --Apple-Mail-5-440689703-- From lear@cisco.com Mon Jun 6 03:06:38 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2A911E80F0; Mon, 6 Jun 2011 03:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 IQUBFjuXwGao; Mon, 6 Jun 2011 03:06:37 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 54F0711E808C; Mon, 6 Jun 2011 03:06:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=7439; q=dns/txt; s=iport; t=1307354797; x=1308564397; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=1uYQGLju7XRr6KKlj3vz0+0SQKDvRvj2ZAbOgZXNl/s=; b=GahtMpq8ogb0webfuD430Y2xoxLU/tlN5idcn4rBommQvea4m5s4Fnkw 70GfGyb3RIcYM1SRs/SJgqzLv7tb38a+9s+OMuga/O0qaNYdYgXFCh21H HDTmwv17WklLiSdrGN3StGg53spGmknl9efnmHMKDLUPKnirG9zy91x3X w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALul7E1Io8UQ/2dsb2JhbABThEqhcHetV40JkBmFF4EKBJB5jzw X-IronPort-AV: E=Sophos;i="4.65,325,1304294400"; d="scan'208,217";a="92408112" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-1.cisco.com with ESMTP; 06 Jun 2011 10:06:05 +0000 Received: from dhcp-10-55-89-175.cisco.com (dhcp-10-55-89-175.cisco.com [10.55.89.175]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p56A62MF020755; Mon, 6 Jun 2011 10:06:02 GMT Message-ID: <4DECA68A.6080305@cisco.com> Date: Mon, 06 Jun 2011 12:06:02 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Arturo Servin Subject: Re: ITU-T SG17 IPv6 security work items liaison References: <4DEA6323.4070302@cs.tcd.ie> <20110605031045.GK88250@verdi> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/alternative; boundary="------------070307020309060605080903" Cc: IPv6 Operations , ipv6@ietf.org, saag@ietf.org, "Turner, Sean P." , Stephen Farrell X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 10:06:38 -0000 This is a multi-part message in MIME format. --------------070307020309060605080903 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Arturo, On 6/5/11 10:30 PM, Arturo Servin wrote: > I do not see why the ITU has to start from zero. There are several (or some at least) very good RFC and I+D documents related to IPv6 security. I think we should recommend them to ITU, it is good that they let us know, it would be better if they use our work as a foundation. There are several specific areas of interest that you can view at https://datatracker.ietf.org/documents/LIAISON/file1228.pdf. The chairman and vice-chairman of the ITU's security area, SG17, are informing us that two of their working groups which the ITU-T calls Questions will be taking on new work relating to IPv6. Let's review the two work items: The first thing to note is that X.ipv6-secguide is targeted to be a deployment guide. We need more of these for IPv6 and we should welcome the ITU-T's involvement. The second document, X.mgv6 is meant to be "management guidelines for implementation of IPv6". We provide a fair amount of this sort of guidance in our collective works. Also, the difference between implementation guidance and normative statements can be very narrow. Therefore, this is the area most likely to have overlap. The best way to address that overlap is to communicate effectively through the liaison process, and perhaps to also participate directly in the meetings, when possible. Here the chairman and vice-chairman of SG17 have recognized that the IETF is an important player in the work to be done. While no response has been requested, it would be wise for us to provide the relevant related work so, as you say, the ITU-T doesn't attempt to start from scratch. I hasten to point out that they are by no means starting from scratch, but we should still provide them relevant guidance. So what is relevant guidance? That can take several different forms: 1. Direct participation in the Study Group meetings. Study Group meetings are open to Member States and Sector Members. ISOC is a Sector Member. The IETF on its own is not. 2. Concise and relevant liaison statements. As this work is just beginning, we can point to not only the published RFCs that are relevant, and they include not only RFC 4294 and draft-ietf-6man-node-req-bis (and we can reference this as a work in progress, and in fact invite comment), but also relevant portions of other RFCs, particular their relevant Security Considerations sections. 3. Informal consultations with ITU-T participants. Believe it or not, this is often the most effective way to contribute. At the same time we should invite SG17 to provide us any feedback on our works, especially when they discover any of the following: * A security problem; * An obstacle to deployment; or * An interoperability problem. While this solicitation should not be limited to the ITU-T, that organization has a reach into the developing world that quite frankly we do not, and they may spot issues that relate to certain environments. Hope this helps, Eliot --------------070307020309060605080903 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Arturo,

On 6/5/11 10:30 PM, Arturo Servin wrote: 
	I do not see why the ITU has to start from zero. There are several (or some at least) very good RFC and I+D documents related to IPv6 security. I think we should recommend them to ITU, it is good that they let us know, it would be better if  they use our work as a foundation.


There are several specific areas of interest that you can view at https://datatracker.ietf.org/documents/LIAISON/file1228.pdf.  The chairman and vice-chairman of the ITU's security area, SG17, are informing us that two of their working groups which the ITU-T calls Questions will be taking on new work relating to IPv6.

Let's review the two work items:

The first thing to note is that X.ipv6-secguide is targeted to be a deployment guide.  We need more of these for IPv6 and we should welcome the ITU-T's involvement.

The second document, X.mgv6 is meant to be "management guidelines for implementation of IPv6".   We provide a fair amount of this sort of guidance in our collective works.  Also, the difference between implementation guidance and normative statements can be very narrow.  Therefore, this is the area most likely to have overlap.  The best way to address that overlap is to communicate effectively through the liaison process, and perhaps to also participate directly in the meetings, when possible.

Here the chairman and vice-chairman of SG17 have recognized that the IETF is an important player in the work to be done.  While no response has been requested, it would be wise for us to provide the relevant related work so, as you say, the ITU-T doesn't attempt to start from scratch.  I hasten to point out that they are by no means starting from scratch, but we should still provide them relevant guidance.  So what is relevant guidance?  That can take several different forms:

  1. Direct participation in the Study Group meetings.  Study Group meetings are open to Member States and Sector Members.  ISOC is a Sector Member.  The IETF on its own is not.
  2. Concise and relevant liaison statements.  As this work is just beginning, we can point to not only the published RFCs that are relevant, and they include not only RFC 4294 and draft-ietf-6man-node-req-bis (and we can reference this as a work in progress, and in fact invite comment), but also relevant portions of other RFCs, particular their relevant Security Considerations sections.
  3. Informal consultations with ITU-T participants.  Believe it or not, this is often the most effective way to contribute.
At the same time we should invite SG17 to provide us any feedback on our works, especially when they discover any of the following:
  • A security problem;
  • An obstacle to deployment; or
  • An interoperability problem.
While this solicitation should not be limited to the ITU-T, that organization has a reach into the developing world that quite frankly we do not, and they may spot issues that relate to certain environments.

Hope this helps,

Eliot
--------------070307020309060605080903-- From stephen.farrell@cs.tcd.ie Mon Jun 6 04:41:41 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56DA211E80F8; Mon, 6 Jun 2011 04:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 KcGkv6PgkxUu; Mon, 6 Jun 2011 04:41:40 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2D04211E80D6; Mon, 6 Jun 2011 04:41:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 5A76C171C18; Mon, 6 Jun 2011 12:41:39 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1307360497; bh=HGQZCafMYnnf4+ cQeY11uzwY5tWANiICFL/8uDkNxpc=; b=uuju7tFoXlq6V7j4TQGbUxhLmSXQ/P EzPwhIvHKGeDqINtSypNv6oimK3d1264ZRpmnMZgK6mu/toqCVoYeo5o4jBlxIeG DZ4Mmul6h47NwGgIwUUQw2PKwvJO91Qt1H+K0hpviG1crqV5iWiP1qNFALBqagHQ s8EZmA5IVcYa6pTsmj6VO9h4LoGxTLG0m7avfJ3+inkTDfUoGWZa1iWijSLBqwse WjLWBORn/Q59GfcpiXn6TtsKkX1CmzGfnN2JmS5gZxKVa1X4FxUvbjcO3H63Jcaw LbosmpcuFhP2F+AMMwgM2UhGpFoU6zxkl1ToBOjXBNgrrldZfhl5O+QA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id o8oaWcScZvBj; Mon, 6 Jun 2011 12:41:37 +0100 (IST) Received: from [10.87.48.9] (unknown [86.42.182.86]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 2C0D8171C17; Mon, 6 Jun 2011 12:41:35 +0100 (IST) Message-ID: <4DECBCEE.6070108@cs.tcd.ie> Date: Mon, 06 Jun 2011 12:41:34 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Arturo Servin Subject: Re: ITU-T SG17 IPv6 security work items liaison References: <4DEA6323.4070302@cs.tcd.ie> <20110605031045.GK88250@verdi> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 06 Jun 2011 04:54:57 -0700 Cc: IPv6 Operations , ipv6@ietf.org, Eliot Lear , saag@ietf.org, "Turner, Sean P." X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 11:41:41 -0000 On 05/06/11 21:30, Arturo Servin wrote: > > I do not see why the ITU has to start from zero. What Eliot said. > There are several (or some at least) very good RFC and I+D documents related to IPv6 security. Sure. Feel free to send RFC numbers and we'll include some in the draft response that we'll circulate in a while. (So no need to spam everyone with those, just sending your suggestions to Eliot, Sean and I will be enough.) Thanks, S. > I think we should recommend them to ITU, it is good that they let us know, it would be better if they use our work as a foundation. > > just my 20 cents > -as > > > On 5 Jun 2011, at 00:10, John Leslie wrote: > >> Stephen Farrell wrote: >>> >>> We received a liaison [1] from ITU-T saying they're >>> planning to start a couple of work items on the >>> security of IPv6. As far as we know, they envisage >>> developing a "technical guideline on deploying IPv6" >>> and "Security Management Guideline for implementation >>> of IPv6 environment in telecommunications >>> organizations." Bear in mind that they're just starting >>> so they know about as much as we would just before a >>> BoF or something like that. >>> >>> I think we'd like to respond to them that that's great, >>> and we'll be interested in their results, but can they >>> *please* come back to us before saying something should >>> be changed so's we can talk about it. >> >> I don't think that's quite right. We should welcome their studying >> security issues; but I think we need to _strongly_ encourage them to >> start from draft-ietf-6man-node-req-bis when it becomes an RFC -- since >> it has _significant_ changes from RFC 4294 (and an ITU-T study based >> on RFC4294 will be of rather limited value). >> >> Furthermore, ITU-T should NOT propose "changes" to IPv6 protocol >> or the Node Requirements. The language there should talk of documenting >> security "concerns" or "issues" or whatever term seems neutral enough; >> and list as the next step exchanging ideas of what "changes" might help. >> >> Clearly, ITU-T is entirely justified in publishing recommendations >> of what level of security-related-trust to place in IPv6 packet >> forwarding: but any protocol _changes_ are outside their bailiwick. >> >> (As an aside, IETF should resist most proposals for change until >> IPv6 sees widespread deployment -- deploying to a moving target is >> just TOO risky.) >> >> -- >> John Leslie >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > From Marcus.Williams@ed.gov Mon Jun 6 05:58:59 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D517E11E8133; Mon, 6 Jun 2011 05:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 HhOUReTY2FiE; Mon, 6 Jun 2011 05:58:58 -0700 (PDT) Received: from exprod8og109.obsmtp.com (exprod8og109.obsmtp.com [64.18.3.98]) by ietfa.amsl.com (Postfix) with ESMTP id C5F7211E813A; Mon, 6 Jun 2011 05:58:50 -0700 (PDT) Received: from eduptcexmr01.ed.gov ([160.109.63.134]) (using TLSv1) by exprod8ob109.postini.com ([64.18.7.12]) with SMTP ID DSNKTezPCDt5UDjv8KpyC7/7hKf9QEZqoPtb@postini.com; Mon, 06 Jun 2011 05:58:58 PDT Received: from eduptcexhb02.ed.gov (eduptcexhb02.ed.gov [165.224.52.34]) by eduptcexmr01.ed.gov (8.13.8/8.13.8) with ESMTP id p56CwkdX002512 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Mon, 6 Jun 2011 07:58:46 -0500 Received: from EDUPTCEXMB02.ed.gov ([165.224.52.20]) by eduptcexhb02.ed.gov ([165.224.52.34]) with mapi; Mon, 6 Jun 2011 07:58:46 -0500 From: "Williams, Marcus (Contractor)" To: Stephen Farrell , Arturo Servin Date: Mon, 6 Jun 2011 07:58:43 -0500 Subject: RE: [v6ops] ITU-T SG17 IPv6 security work items liaison Thread-Topic: [v6ops] ITU-T SG17 IPv6 security work items liaison Thread-Index: AcwkPt1LDZw3bbl2TWqChG/iXIKbYgACZ7YA Message-ID: References: <4DEA6323.4070302@cs.tcd.ie> <20110605031045.GK88250@verdi> <4DECBCEE.6070108@cs.tcd.ie> In-Reply-To: <4DECBCEE.6070108@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 06 Jun 2011 06:34:18 -0700 Cc: IPv6 Operations , "ipv6@ietf.org" , Eliot Lear , "saag@ietf.org" , "Turner, Sean P." X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 12:59:00 -0000 > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Stephen Farrell > Sent: Monday, June 06, 2011 7:42 AM > Sure. Feel free to send RFC numbers and we'll include > some in the draft response that we'll circulate in a > while. (So no need to spam everyone with those, just > sending your suggestions to Eliot, Sean and I will be > enough.) There are a number of RFCs including 4291 already referenced in this NIST S= pecial Publication 800-119, Guidelines for the Secure Deployment of IPv6: http://csrc.nist.gov/publications/PubsDrafts.html#800-119 Marcus Williams, CISSP From brian@innovationslab.net Mon Jun 6 07:37:52 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B793A11E8146; Mon, 6 Jun 2011 07:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 8Mzo-6UisH1Q; Mon, 6 Jun 2011 07:37:52 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4EDB511E8152; Mon, 6 Jun 2011 07:37:52 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 4B43088178; Mon, 6 Jun 2011 07:37:50 -0700 (PDT) Received: from clemson.jhuapl.edu (unknown [128.244.243.28]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 59F0B1369461; Mon, 6 Jun 2011 07:37:49 -0700 (PDT) Message-ID: <4DECE639.5000508@innovationslab.net> Date: Mon, 06 Jun 2011 10:37:45 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Jari Arkko , Ralph Droms Subject: Request To Advance:draft-ietf-6man-flow-ecmp-02.txt X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, iesg-secretary@ietf.org, Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 14:37:52 -0000 Jari & Ralph, On behalf of the 6MAN Working Group, the chairs request the advancement of: Title : Using the IPv6 flow label for equal cost multipath routing and link aggregation in tunnels Author(s) : B. Carpenter, S. Amante Filename : draft-ietf-6man-flow-ecmp-02.txt Pages : 10 Date : 2011-05-02 as a Best Current Practice. The Working Group Last Call ended on January 21, 2011 and this version addresses all comments/issues raised. Regards, Brian Haberman & Bob Hinden From brian@innovationslab.net Mon Jun 6 07:37:52 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF2AB11E8154; Mon, 6 Jun 2011 07:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 D+jpej3bO7tl; Mon, 6 Jun 2011 07:37:52 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED6011E8151; Mon, 6 Jun 2011 07:37:52 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 4425B8816E; Mon, 6 Jun 2011 07:37:47 -0700 (PDT) Received: from clemson.jhuapl.edu (unknown [128.244.243.28]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 6AA6E1369461; Mon, 6 Jun 2011 07:37:46 -0700 (PDT) Message-ID: <4DECE635.6000206@innovationslab.net> Date: Mon, 06 Jun 2011 10:37:41 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Jari Arkko , Ralph Droms Subject: Request To Advance: draft-ietf-6man-flow-update-06.txt X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: iesg-secretary@ietf.org, ipv6@ietf.org, Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 14:37:52 -0000 Jari & Ralph, On behalf of the 6MAN Working Group, the chairs request the advancement of: Title : Rationale for update to the IPv6 flow label specification Author(s) : Shane Amante Brian Carpenter Sheng Jiang Filename : draft-ietf-6man-flow-update-06.txt Pages : 13 Date : 2011-05-12 as an Informational document. The Working Group Last Call ended on April 4, 2011 and this version addresses all comments/issues raised. Regards, Brian Haberman & Bob Hinden From brian@innovationslab.net Mon Jun 6 08:07:42 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2786F11E8163; Mon, 6 Jun 2011 08:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 uBQ8Lf-2xcF9; Mon, 6 Jun 2011 08:07:41 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id C585811E8137; Mon, 6 Jun 2011 08:07:41 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 4D5198816E; Mon, 6 Jun 2011 07:37:53 -0700 (PDT) Received: from clemson.jhuapl.edu (unknown [128.244.243.28]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 7CFDA1369461; Mon, 6 Jun 2011 07:37:52 -0700 (PDT) Message-ID: <4DECE63C.10109@innovationslab.net> Date: Mon, 06 Jun 2011 10:37:48 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Jari Arkko , Ralph Droms Subject: Request To Advance: draft-ietf-6man-flow-3697bis-04.txt X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: iesg-secretary@ietf.org, ipv6@ietf.org, Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 15:07:42 -0000 Jari & Ralph, On behalf of the 6MAN Working Group, the chairs request the advancement of: Title : IPv6 Flow Label Specification Author(s) : Shane Amante Brian Carpenter Sheng Jiang Jarno Rajahalme Filename : draft-ietf-6man-flow-3697bis-04.txt Pages : 15 Date : 2011-05-12 as a Proposed Standard. The Working Group Last Call ended on April 1, 2011 and this version addresses all comments/issues raised. Regards, Brian Haberman & Bob Hinden From rja.lists@gmail.com Mon Jun 6 09:39:09 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C25A21F84BF for ; Mon, 6 Jun 2011 09:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 h3llPaLfDEl1 for ; Mon, 6 Jun 2011 09:39:08 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8D68F21F84BE for ; Mon, 6 Jun 2011 09:39:08 -0700 (PDT) Received: by vxg33 with SMTP id 33so3675062vxg.31 for ; Mon, 06 Jun 2011 09:39:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:to:mime-version:x-mailer; bh=DTU7Y0acAv22OT3elEy2t8SOKGnwO2qz3bCasLzAMaE=; b=nzqRm7lVwzGNo8MpUf/cBqV1DkHmG180yHI1Fo7gOi06KQnN4WHIE+MkMl/A3Ggeyi 8vWABfZ1/cVGpLAViYJHR3Uw3EVSxGFlq7m1p1L6YlIgbrQqAq3tgd8lDXjoUhzenwtf r6zWqsiRbAbFliztjoMf3lDCBsXOrC+ujibTs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=F3q+DPUReI98YkLiiDoRGTwi22+KhDJmSR+kACAIXzseZmWQEgeX3r17VwAWvVhsxR zOyUj6Al6aHrXR6+Pe35A2snZy4pnyoI09wB4vy8W6EYLlmCiSqQr3sAybnkB2V4OBM8 w/SBXBHpciGx4/JoRAC3MyAgVAhWtwcdYayDY= Received: by 10.52.38.4 with SMTP id c4mr210192vdk.232.1307378347731; Mon, 06 Jun 2011 09:39:07 -0700 (PDT) Received: from [10.30.20.7] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id c1sm899125vdu.5.2011.06.06.09.39.06 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 06 Jun 2011 09:39:07 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Preliminary report on flow label hash algorithms Date: Mon, 6 Jun 2011 12:39:04 -0400 Message-Id: To: ipv6@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 16:39:09 -0000 I would be reluctant to advocate use of a hash algorithm as computationally expensive as MD5() for generating an IPv6 Flow Label. My sense is that a thoughtful implementer likely would choose the least computationally expensive algorithm that would suffice to generate a Flow Label value suitable for load-balancing purposes. As a use case, one might consider some sort of content server with very large numbers of short-lived TCP sessions. If an expensive algorithm (e.g. MD5()) were used in that case, then the effort to compute the flow label might be am interesting fraction of "new TCP session creation" overhead. In turn, this might impair the scalability of that content server. In any event, I'm quite comfortable with Brian's current approach to document a possible algorithm that ought to suffice without mandating any particular algorithm. This really is a situation where the details are best left to implementers (since no interoperability issue would arise from different implementations using different algorithms). Yours, Ran From bob.hinden@gmail.com Mon Jun 6 16:22:19 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 261241F0C4A for ; Mon, 6 Jun 2011 16:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 PeIdS6grofBF for ; Mon, 6 Jun 2011 16:22:18 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBFE1F0C44 for ; Mon, 6 Jun 2011 16:22:18 -0700 (PDT) Received: by pwi5 with SMTP id 5so2633336pwi.31 for ; Mon, 06 Jun 2011 16:22:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=JGLZ33W0iMvJhyU6R6/pOh1P941AcQtlAsum/HjEdQY=; b=Ji9OJEJpOM7F3xWXbvkfXYbXQYge1G39xir+Zcm12/xy6bAsNOvB+J94w8be9STTIO z0E1wAFd0HvIN7VzHKciVhIzTN66gWyOzhfYBfKIjb5PGXyMshuEKL39quBVSd0qvv8o t1Vjcag162U2PBAWIYWxtesVtOP83uQAsd6mc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=MsGhmG9uMxkqUl14p6dPid01cWWeJZvpPNxeCvEy519QB+9zTKTbFzcJjs3I2wTPlt fH8bRFQNcRg2Y2EFTbgEHQIGxHBuV7N0CT1UgMrLlmCpXlzGt/8HpsFDIJGj9WtT5SyG JL7NAH3KSHHDO0VVnMcqn7PHwkZKtL1HJInXE= Received: by 10.142.250.25 with SMTP id x25mr862113wfh.195.1307402537645; Mon, 06 Jun 2011 16:22:17 -0700 (PDT) Received: from [172.16.224.217] ([209.97.127.34]) by mx.google.com with ESMTPS id x1sm4004893pbb.66.2011.06.06.16.22.15 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 06 Jun 2011 16:22:16 -0700 (PDT) Subject: Re: Preliminary report on flow label hash algorithms Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: Date: Mon, 6 Jun 2011 16:22:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: RJ Atkinson X-Mailer: Apple Mail (2.1084) Cc: ipv6@ietf.org, Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 23:22:19 -0000 Ran, On Jun 6, 2011, at 9:39 AM, RJ Atkinson wrote: >=20 > I would be reluctant to advocate use of a hash algorithm > as computationally expensive as MD5() for generating an > IPv6 Flow Label. =20 >=20 > My sense is that a thoughtful implementer likely would > choose the least computationally expensive algorithm > that would suffice to generate a Flow Label value=20 > suitable for load-balancing purposes. =20 >=20 > As a use case, one might consider some sort of content server=20 > with very large numbers of short-lived TCP sessions. If an > expensive algorithm (e.g. MD5()) were used in that case,=20 > then the effort to compute the flow label might be am > interesting fraction of "new TCP session creation" overhead. > In turn, this might impair the scalability of that content > server. I suppose one could precompute a bunch ahead of time, but I agree with = your comment. It's a good point. >=20 > In any event, I'm quite comfortable with Brian's current > approach to document a possible algorithm that ought to > suffice without mandating any particular algorithm. > This really is a situation where the details are best > left to implementers (since no interoperability issue=20 > would arise from different implementations using different > algorithms). I also agree. Bob From brian.e.carpenter@gmail.com Mon Jun 6 16:44:27 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D75D21F0C50 for ; Mon, 6 Jun 2011 16:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.68 X-Spam-Level: X-Spam-Status: No, score=-102.68 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619, 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 x2gc5e7cmHyG for ; Mon, 6 Jun 2011 16:44:27 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF141F0C46 for ; Mon, 6 Jun 2011 16:44:27 -0700 (PDT) Received: by gwb20 with SMTP id 20so2151835gwb.31 for ; Mon, 06 Jun 2011 16:44:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=f3IOUm/5VNHDvzdDwvpCCthrjHw9dqivl7IbS0HHHNk=; b=u9qBhP+TbHI1I1gC1vZsQocDXz4cXcDDB3DCLGd47+Dj47xKfNjSimFqnQePfxH8Ra TZY2teCLkOn0HH/dnX6Jy04w/1D1cZ98KuhXcbKaAcpQoVN1n/yJG63Mac50ux7CNWXF l7e1ulEk7jLOcbF6XI/0FJXibuUtR8Jlp99BY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=Uyxj+enlDKErLEJGWnzGZiB2ZfabJhML5LFVBI9NWKpjywHTQQ3jPljSlYc8QuKWO8 i6Qm+BzjmQGq7k+I+0kMLwlz2zQLfmYAv5ygK/QsRWszmc6nS/O44+2xJhzQXLzQ9VD6 rkd8NP2Of28/+XfTHvHkli9SG0KTl/9WKAdvM= Received: by 10.101.161.5 with SMTP id n5mr4150185ano.131.1307403866892; Mon, 06 Jun 2011 16:44:26 -0700 (PDT) Received: from [10.71.2.198] ([12.68.183.2]) by mx.google.com with ESMTPS id w19sm3639524anf.38.2011.06.06.16.44.23 (version=SSLv3 cipher=OTHER); Mon, 06 Jun 2011 16:44:25 -0700 (PDT) Message-ID: <4DED6650.7080705@gmail.com> Date: Tue, 07 Jun 2011 11:44:16 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Bob Hinden Subject: Re: Preliminary report on flow label hash algorithms References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, RJ Atkinson X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 23:44:28 -0000 below... On 2011-06-07 11:22, Bob Hinden wrote: > Ran, > > On Jun 6, 2011, at 9:39 AM, RJ Atkinson wrote: > >> I would be reluctant to advocate use of a hash algorithm >> as computationally expensive as MD5() for generating an >> IPv6 Flow Label. >> >> My sense is that a thoughtful implementer likely would >> choose the least computationally expensive algorithm >> that would suffice to generate a Flow Label value >> suitable for load-balancing purposes. >> >> As a use case, one might consider some sort of content server >> with very large numbers of short-lived TCP sessions. If an >> expensive algorithm (e.g. MD5()) were used in that case, >> then the effort to compute the flow label might be am >> interesting fraction of "new TCP session creation" overhead. >> In turn, this might impair the scalability of that content >> server. > > I suppose one could precompute a bunch ahead of time, but I agree with your comment. It's a good point. > >> In any event, I'm quite comfortable with Brian's current >> approach to document a possible algorithm that ought to >> suffice without mandating any particular algorithm. >> This really is a situation where the details are best >> left to implementers (since no interoperability issue >> would arise from different implementations using different >> algorithms). > > I also agree. > I sort of agree, if we're talking about my proposed replacement algorithm However, I would want to weaken the language in the appendix to make it clear that better algorithms can and will be found - I've had to break off my experiments for a few weeks due to travel, but there is a lot of scope for improvement. Anyway, let's see what the AD thinks. Brian From brian.e.carpenter@gmail.com Mon Jun 6 16:47:18 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAD4021F84C4 for ; Mon, 6 Jun 2011 16:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.83 X-Spam-Level: X-Spam-Status: No, score=-102.83 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619, 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 7UMNqVs19IM8 for ; Mon, 6 Jun 2011 16:47:18 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id E809B21F8449 for ; Mon, 6 Jun 2011 16:47:17 -0700 (PDT) Received: by gyf3 with SMTP id 3so2266982gyf.31 for ; Mon, 06 Jun 2011 16:46:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=OaspaW+0iStc0ICfjQpwcbFZ4wHbucQ9wwyx+j3449U=; b=Vu3WRz+xhAmw/V8Q8W0Nfo2BnWpClC4i3k0R0/OgzdF0kg9/wZyLOJvbscUgLDM/MF AorF0DgoUamRJLJ3iJwoD5RKXO+B2E/NFakCZi4ycGbLZlED3tpe79eQ7RIeixv34J8M 7bDkQjV3POasRy+JMbjfQDOf+yqZxGL8qQFB0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=kn67q7OlFX60wUo2/ErQJg86pL3Upj4Mke/fdSsFXEVmQaBTgCvdrIQmx3+YDKepP3 4/0cwIJVzNXoH4mcRtCUEzCC8sfi55W/8U7LRwyAJfj+7/UOSYNSUWhuQorUEYRJ7Br0 ZovKfOJhqwos5UrCTaHsLNADZicsEPKlmNkGo= Received: by 10.236.105.145 with SMTP id k17mr7168267yhg.123.1307404010351; Mon, 06 Jun 2011 16:46:50 -0700 (PDT) Received: from [10.71.2.198] ([12.68.183.2]) by mx.google.com with ESMTPS id 26sm892189yhs.77.2011.06.06.16.46.48 (version=SSLv3 cipher=OTHER); Mon, 06 Jun 2011 16:46:49 -0700 (PDT) Message-ID: <4DED66E6.40809@gmail.com> Date: Tue, 07 Jun 2011 11:46:46 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian Haberman Subject: Re: Request To Advance: draft-ietf-6man-flow-3697bis-04.txt References: <4DECE63C.10109@innovationslab.net> In-Reply-To: <4DECE63C.10109@innovationslab.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Ralph Droms , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 23:47:19 -0000 For the AD's information - the suggested hash algorithm in Appendix A definitely needs to be revised. It isn't normative so it can be taken care of a little later, along with any AD comments. Regards Brian Carpenter On 2011-06-07 02:37, Brian Haberman wrote: > Jari & Ralph, > On behalf of the 6MAN Working Group, the chairs request the > advancement of: > > Title : IPv6 Flow Label Specification > Author(s) : Shane Amante > Brian Carpenter > Sheng Jiang > Jarno Rajahalme > Filename : draft-ietf-6man-flow-3697bis-04.txt > Pages : 15 > Date : 2011-05-12 > > as a Proposed Standard. The Working Group Last Call ended on April 1, > 2011 and this version addresses all comments/issues raised. > > Regards, > Brian Haberman & Bob Hinden > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From fernando.gont.netbook.win@gmail.com Tue Jun 7 06:32:00 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E1011E8101; Tue, 7 Jun 2011 06:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_LOW=-1] 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 YbodLpky5zOb; Tue, 7 Jun 2011 06:31:59 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 556CA11E808E; Tue, 7 Jun 2011 06:31:59 -0700 (PDT) Received: by gxk19 with SMTP id 19so2638489gxk.31 for ; Tue, 07 Jun 2011 06:31:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=Gs/07prDImCcX7YegUVdeujV3T0/S0uzggVg7GZJej0=; b=NUF+z20w5mwP4OXwXwKEBZf9WFcgCGFnpzKkkFGNodHPEQzbtieJkN4DuR7Ic4ZU6R btg6xBbwkEAN50xEySR4YpTNUJwAxmtTcTbDYyUEd+Hlm6orz1XL7UOZnuqQOC9Nrfyy I3LkbuK0/C3Rf4OuQko4dtsSATv2N5xgqtfwI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=c71AKdoXA6PEXOwiqk4ueAoH3jPSqvbdAppM70USwO9/HW2UcAoqC05P8ELegsHw2P 6Oe2SWgeJJSvpuJgra1Duidj6/KI97UqInoTptUhB4vSCqT+NIDNYLYBo/0ZMZnu9Alm eb7Uyy+putwYdU1pePgKDSvUIZtzPmllzM0GE= Received: by 10.101.2.25 with SMTP id e25mr4862704ani.28.1307453518777; Tue, 07 Jun 2011 06:31:58 -0700 (PDT) Received: from [192.168.1.102] ([190.190.97.123]) by mx.google.com with ESMTPS id w19sm4069026anf.38.2011.06.07.06.31.52 (version=SSLv3 cipher=OTHER); Tue, 07 Jun 2011 06:31:57 -0700 (PDT) Sender: Fernando Gont Message-ID: <4DED7DB2.6080802@gont.com.ar> Date: Mon, 06 Jun 2011 22:24:02 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: John Leslie Subject: Re: ITU-T SG17 IPv6 security work items liaison References: <4DEA6323.4070302@cs.tcd.ie> <20110605031045.GK88250@verdi> In-Reply-To: <20110605031045.GK88250@verdi> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, ipv6@ietf.org, Eliot Lear , "saag@ietf.org" , "Turner, Sean P." , Stephen Farrell X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 13:32:00 -0000 On 06/05/2011 12:10 AM, John Leslie wrote: >> I think we'd like to respond to them that that's great, >> and we'll be interested in their results, but can they >> *please* come back to us before saying something should >> be changed so's we can talk about it. > > I don't think that's quite right. We should welcome their studying > security issues; but I think we need to _strongly_ encourage them to > start from draft-ietf-6man-node-req-bis when it becomes an RFC -- since > it has _significant_ changes from RFC 4294 (and an ITU-T study based > on RFC4294 will be of rather limited value). While I have not read the latest version of the aforementioned I-D, I don't think it address (nor should it) the security implications of IPv6. As a simply example, while there has been some work on the security implications of transition/co-existence technologies, I don't think there have been e.g. best practices published on e.g. how to filter them (in those environments in which the use of technologies such as Teredo is undesirable). Additionally, I don't think there has been much work on which tools could be used (and how) to perform network monitoring (e.g., use NDPMon to monitor ND-based attacks). > Clearly, ITU-T is entirely justified in publishing recommendations > of what level of security-related-trust to place in IPv6 packet > forwarding: but any protocol _changes_ are outside their bailiwick. Agreed. However (and with no clue about what ITU-T is planning to work on) I guess there's room for recommendations on what stuff to filter, specific features that should be enabled/disabled, etc. > (As an aside, IETF should resist most proposals for change until > IPv6 sees widespread deployment -- deploying to a moving target is > just TOO risky.) While I do see some value in this point (and I'm aware there are many that share this point of view), I think this argument does not necessarily apply to security. If a flaw is identified, and there's a concrete proposal to mitigate it, I don't think it would be a good idea to resist to *this* type of change/update. Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando.gont.netbook.win@gmail.com Tue Jun 7 19:18:01 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1B111E809D for ; Tue, 7 Jun 2011 19:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.956 X-Spam-Level: X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_NJABL_PROXY=1.643] 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 ZaeBSiwQKubH for ; Tue, 7 Jun 2011 19:18:01 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id ED5DB11E807C for ; Tue, 7 Jun 2011 19:18:00 -0700 (PDT) Received: by gyf3 with SMTP id 3so28945gyf.31 for ; Tue, 07 Jun 2011 19:18:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=Yn6gTSmU2DBOLRLcTvYHCmqPMfLs08zaXN/GtJlAYV8=; b=LyUIdDG++RsDd4lXLfPfTzpWfdhWZicqWQ21hC1SCk0oSyL40RV1BnEe6AqdBpAUeQ N9Vv4a+e48hz3/8lpS6pchtfBPSY/Dfbqatyuy+gMzLRAbmlyHsd/yQxviHGwAROBg44 YRMIAls1oKQSQgFoH36iYCyjUJT0JNo472xq4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=q+ORihJ/Py1ZQbhr1YT6+tg431gJPVi38sZaNuV4sbOSoVPywZrN4RtPR8LAfh9crt 9iSG7szpLko+FCtg9XRbIXIKHZTq98rqGeWLAjbs31lKvCoZQunLUJVOlxjXvlkh6ahq gGQn1ziVmZ3pCQA2vgvpGiUkbnV8KR7fnOvr0= Received: by 10.91.80.20 with SMTP id h20mr74980agl.149.1307499480381; Tue, 07 Jun 2011 19:18:00 -0700 (PDT) Received: from [192.168.123.103] ([190.48.238.249]) by mx.google.com with ESMTPS id w1sm85510anh.3.2011.06.07.19.17.57 (version=SSLv3 cipher=OTHER); Tue, 07 Jun 2011 19:17:59 -0700 (PDT) Sender: Fernando Gont Message-ID: <4DEEDBD3.5040502@gont.com.ar> Date: Tue, 07 Jun 2011 23:17:55 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Arturo Servin Subject: Re: New I-D: Neighbor Discovery and IPv6 Extension Headers (draft-gont-6man-nd-extension-headers) References: <4DE556A9.2050702@gont.com.ar> <1B9CD0F7-9B70-412D-8A36-AE551D84DB28@gmail.com> In-Reply-To: <1B9CD0F7-9B70-412D-8A36-AE551D84DB28@gmail.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 02:18:01 -0000 Hi, Arturo, Thanks so much for your feedback! -- Please find my responses inline... On 06/05/2011 07:28 PM, Arturo Servin wrote: > I think you missed the reference to RFC 6105, this is the same problem > with the reference > than http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-00.txt Good grief! -- There was an error in the xml source which resulted in the reference not being included. I'll fix this in the next rev of the I-D. > May be it is just me and the excess of caffeine but the third paragraph > of section 1 is a bit long and hard to understand. I would recommend > some rephrasing. With a bit more caffeine, it was parsable to me :-) . Anyway, I've worked a little bit on the paragraph, to improve it. This is the resulting text: ---- cut here ---- Since there is no current legitimate use for IPv6 Extension Headers in IPv6 Neighbor Discovery packets, and avoiding their use in such packets would greatly simplify the monitoring and mitigation of Neighbor Discovery attacks, this document proposes that hosts silently ignore Neighbor Discovery messages that employ IPv6 Extension Headers. ---- cut here ---- > Other: > > In section 2. I think it has to be a MUST instead of SHOULD. I'd probably agree with you but will leave this one for discussion... > In section 3, I think you should add a paragraph saying that even with > the filtering rules described > in http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-00.txt there > is a important cost in complexity and performance for devices performing > those filters (l2-switches, IDS/IPS/FWS, etc.) This is a very good point. Will craft some text about this and include it in the next revision of the I-D. Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando.gont.netbook.win@gmail.com Wed Jun 8 01:36:38 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B39DC11E8111; Wed, 8 Jun 2011 01:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.956 X-Spam-Level: X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_NJABL_PROXY=1.643] 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 V+Mo7kXGuC2H; Wed, 8 Jun 2011 01:36:38 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 25D2311E809C; Wed, 8 Jun 2011 01:36:38 -0700 (PDT) Received: by gxk19 with SMTP id 19so137699gxk.31 for ; Wed, 08 Jun 2011 01:36:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=/74x3nA5p9xC0Rt7Q/i1x3BAzTSOxjjgKxl1riGTZxg=; b=Zt8FMZIH7E4ZfvdpC+Jqhy5d6ZYn73P8A6JD0d1o9lUyO87VBVnmYOxFfVC2/Eit+v Bktp6WG4fqgQ3ODhezL1wydGPFYp8GL/AwKN/QJKeTtwOaIp0d9I3+vLQNZVgXOOjNPl utYlq+PjqgYPlVQOJQVTWzZPoclko0rvFXDyQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=JT0RIs2LarK++Pkkb7EdpclHKmhEq+UvtwxyV4gvzkplMTGrZs/Dc3bGRvqRrzUpJ6 HcRPzJJIMakINzRQcAuzRdvESe87jUzgYOLCTILNdfNNFv378asBQ0T9bVZONSzhdA00 Q10jwaDG19JlmyAQxHUHbCZqc9+7YdvcjWx5Y= Received: by 10.91.26.23 with SMTP id d23mr368746agj.73.1307522197524; Wed, 08 Jun 2011 01:36:37 -0700 (PDT) Received: from [192.168.123.103] ([190.48.238.249]) by mx.google.com with ESMTPS id c21sm339717ana.50.2011.06.08.01.36.33 (version=SSLv3 cipher=OTHER); Wed, 08 Jun 2011 01:36:35 -0700 (PDT) Sender: Fernando Gont Message-ID: <4DEF3461.8040502@gont.com.ar> Date: Wed, 08 Jun 2011 05:35:45 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Pekka Savola Subject: Re: [v6ops] Ra-Guard evasion (new Internet-Drafts) References: <4DE6DD93.507@gont.com.ar> <4DE7D813.3050700@gont.com.ar> <201106021939.p52Jd8rI002414@cichlid.raleigh.ibm.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , IPv6 Operations , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 08:36:38 -0000 Hi, Pekka, On 06/06/2011 07:43 AM, Pekka Savola wrote: >> RA-Guard is not a perfect solution to RA spoofing. It never will >> be. It has limitations (and always will). ND packets that using >> extension headers or fragmentation are just one specific example. > > This has happened with radvd. You mean that at some point radvd was sending fragmented IPv6 traffic, even when it was "unexpected"? > There was one individual who very strongly insisted (by filing and > bugging about that in a bug report at Red Hat Bugzilla) that he must be > able to advertise his whole /48, i.e., 64K prefix information options. > That resulted in the implementation fragmenting packets at the IP > layer. Transport layer would fragmentation to multiple RAs would have > been possible as well but there was no point in implementing that. I > solved the "problem" by restricting radvd send buffer size to 1452B, so > both are prevented. I wouldn't be sad to see the RA transport/IP layer > fragmentation go. This is a good datapoint to have (i.e., radvd never sending fragmented ND traffic) -- I will try to include a note about this in the next rev of the I-D. Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From cabo@tzi.org Wed Jun 8 02:12:01 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E962511E8166; Wed, 8 Jun 2011 02:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, 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 ZFZE1UgRQNIe; Wed, 8 Jun 2011 02:12:01 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 2073B11E814E; Wed, 8 Jun 2011 02:11:59 -0700 (PDT) Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p589BoCA021782; Wed, 8 Jun 2011 11:11:50 +0200 (CEST) Received: from [192.168.217.101] (p5B3E605E.dip.t-dialin.net [91.62.96.94]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 62A6DE45; Wed, 8 Jun 2011 11:11:50 +0200 (CEST) Subject: Re: [v6ops] Ra-Guard evasion (new Internet-Drafts) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <4DEF3461.8040502@gont.com.ar> Date: Wed, 8 Jun 2011 11:11:49 +0200 Content-Transfer-Encoding: 7bit Message-Id: <93280B67-ACFC-4C5A-BDDC-98686D8FB670@tzi.org> References: <4DE6DD93.507@gont.com.ar> <4DE7D813.3050700@gont.com.ar> <201106021939.p52Jd8rI002414@cichlid.raleigh.ibm.com> <4DEF3461.8040502@gont.com.ar> To: Pekka Savola X-Mailer: Apple Mail (2.1084) Cc: Thomas Narten , IPv6 Operations , IPv6 WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 09:12:02 -0000 >> restricting radvd send buffer size to 1452B (that obviously doesn't prevent fragmentation in all cases...) Gruesse, Carsten From alexandru.petrescu@gmail.com Thu Jun 9 09:58:41 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE59811E8190 for ; Thu, 9 Jun 2011 09:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 1S5FwCsm6D+l for ; Thu, 9 Jun 2011 09:58:41 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id E257D11E818A for ; Thu, 9 Jun 2011 09:58:40 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p59GwcSB004786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 9 Jun 2011 18:58:38 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p59GwbBV009660; Thu, 9 Jun 2011 18:58:38 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [132.166.133.178] (is010173.intra.cea.fr [132.166.133.178]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p59GwbjK016444; Thu, 9 Jun 2011 18:58:37 +0200 Message-ID: <4DF0FBBD.1070109@gmail.com> Date: Thu, 09 Jun 2011 18:58:37 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Comment on rpl-routing-header draft References: <37E3AA7855F5AB4B8220815B379D1ACE064DCF74DB@dlee02.ent.ti.com> <37E3AA7855F5AB4B8220815B379D1ACE064DCF74E5@dlee02.ent.ti.com> <81F856BA-79E9-464F-9452-80E79B68F671@cisco.com> <201104261256.p3QCucF4014183@cichlid.raleigh.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 16:58:41 -0000 Le 27/04/2011 01:39, Reddy, Joseph a écrit : > > Hi Thomas > > Since RPL protocol is intended to operate in networks with > constrained devices and lossy, low-bandwidth links, there is a > desire to not require IP-in-IP tunnelling that is usually used for > inserting routing headers. Hm? IP-in-IP tunnelling is not used to insert routing headers. (do you mean that because of some perception tunnels are too big for low-bandwidth links and hence Routing Headers should be used? In terms of bytecount I think a Routing Header takes about the same number of bytes than adding a Base Header (i.e. use IP-in-IP tunnelling).) > This is detailed in the draft > http://tools.ietf.org/html/draft-hui-6man-rpl-headers-00 The draft says: > However, where LLNs are severely constrained in resources, IP-in-IP > tunneling may not be the most favorable solution. Use of IP-in-IP > requires datagrams to carry two IPv6 headers, increasing header > overhead and associated communication and memory requirements. Try to evaluate how much overhead is that: compare the size in bytes of one (not two) Base Headers (40bytes) to the size of a Routing Header containing one address (24bytes). HEaders of an IP-in-IP packet vs RH packet are like this: Base+IP-in-IP: 80bytes. Base+RH: 64bytes. ----------------------- 16bytes difference, potentially saved by preferring RH. Minimal MTU is 1280bytes. Saving 16byte is little worth the trouble. Alex > but I realize now this draft expired recently. Perhaps this can be > revived as it is helps to improve the applicability of RPL protocol. > > -Joseph > > -----Original Message----- From: Thomas Narten > [mailto:narten@us.ibm.com] Sent: Tuesday, April 26, 2011 5:57 AM To: > Reddy, Joseph Cc: Jonathan Hui; 'ipv6@ietf.org' Subject: Re: Comment > on rpl-routing-header draft > >> In the most common usage of this header, the border router inserts >> a source routing header with the full set of intermediate nodes >> before forwarding it towards the destination within the RPL >> network. > > and then. > >> Yes, we do not use IP-in-IP tunneling and instead simply insert >> the RH head= er in the packet. > > What specification are you following that says do this? > > Routing headers (as designed and specified) are inserted by an > originating node (whether the original sender or a tunnel entry > point). If you have a middle node insert this header to an existing > packet, no suprise things are not going to work. > > Thomas > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From brian@innovationslab.net Thu Jun 9 10:51:16 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 891B011E812C for ; Thu, 9 Jun 2011 10:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.74 X-Spam-Level: X-Spam-Status: No, score=-100.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 tpyxB5BPrUSW for ; Thu, 9 Jun 2011 10:51:15 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id B29A811E80BA for ; Thu, 9 Jun 2011 10:51:14 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 77970881F0 for ; Thu, 9 Jun 2011 10:51:14 -0700 (PDT) Received: from tigers.local (unknown [75.94.92.25]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id DA074130002 for ; Thu, 9 Jun 2011 10:51:13 -0700 (PDT) Message-ID: <4DF10776.5090301@innovationslab.net> Date: Thu, 09 Jun 2011 13:48:38 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: IPv6 WG Mailing List Subject: Agenda requests for IETF 81 X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 17:51:16 -0000 All, Scheduling and registration have opened for the 81st IETF meeting in Quebec City. The chairs are now soliciting requests for agenda time during the 6MAN WG slot. If you wish to present, please send the chairs: - Topic - Presenter - Time requested - draft name As with previous meetings, we will give preference to WG work items, topics actively discussed on the mailing list, and then new topics. Please have these requests to the chairs NO LATER THAN 9:00pm GMT on July 6, 2011. Regards, Brian & Bob From night@nist.gov Thu Jun 9 07:28:15 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C80C611E80DE for ; Thu, 9 Jun 2011 07:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4] 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 XPFj5m2E2tMi for ; Thu, 9 Jun 2011 07:28:14 -0700 (PDT) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by ietfa.amsl.com (Postfix) with ESMTP id 7981011E808B for ; Thu, 9 Jun 2011 07:28:14 -0700 (PDT) Received: from [127.0.0.1] (81-140.antd.nist.gov [129.6.140.81]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id p59ERs8d025962; Thu, 9 Jun 2011 10:28:04 -0400 Message-ID: <4DF0D86A.4030305@nist.gov> Date: Thu, 09 Jun 2011 10:27:54 -0400 From: Stephen Nightingale User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: nav6tf@ipv6forum.com, "usgv6-testing@nist.gov" , USGV6-LABS , IPv6 TWG , "nav6tf@ipv6forum.com" , ipv6@ietf.org, "fedv6-deploy@nist.gov" Subject: FINAL REMINDER: USGv6 Version 2.0 Call For Community Input References: <4DCD753C.3010205@nist.gov> In-Reply-To: <4DCD753C.3010205@nist.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: night@nist.gov X-Mailman-Approved-At: Thu, 09 Jun 2011 14:25:13 -0700 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 14:28:15 -0000 Final Reminder for input to the USGv6 revision process. Call for Comments closes tomorrow June 10, 2011. Structure and Content of USGv6 Profile Version 2.0 will be the principal component of Monday's meeting at NIST. Stephen Nightingale. usgv6-project@antd.nist.gov On 5/13/2011 2:15 PM, Stephen Nightingale wrote: > Original announcement at: http://www.antd.nist.gov/usgv6/index.html > Together with the Comments spreadsheet, text of USGv6 version 1.0, and > the testing documents. > ====================== > > USGv6 Version 2.0 Call For Community Input > > In response to OMB directives the National Institute of Standards and > Technology (NIST) developed the initial versions of the USGv6 Profile > and Testing Program. After multiple draft, public comment and revision > cycles, version 1 of the USGv6 Profile was published in July 2008. The > USGv6 Testing Program was developed in a similar fashion and became > operational in November 2009. > > While the initial version of the profile and testing program defined the > processes for evolving to future technical requirements and tests, to > date the USGv6 program has chosen to favor stability of the > specifications over yearly 'maintenance' updates. This approach allowed > vendor products and the test program to mature to the point that we have > multiple accredited test labs, a more complete set of standard test > specifications and numerous products with USGv6 capabilities that have > been tested for conformance and interoperability. This approach also > facilitated the development of other initiatives and policies (e.g., > Federal Acquisition Regulations and new OMB USG IPv6 Adoption > Directives) that leverage the USGv6 program. > > Having gained 2+ years of practical experience in the use of the USGv6 > program, and given the development of some new IETF specifications of > particular significance to the USGv6 program, we feel it is time to > develop version 2 of the USGv6 Profile. From the perspective of NIST > there are several key issues that we would like to address in the next > version of the profile, including: > > Generalize the scope and applicability of the profile. > > There is nothing inherently 'Governmental' about the profile or > testing system, and we are aware of other user communities who have > adopted aspects of the USGv6 program either by reference or duplication. > We welcome broader use and adoption of the profile by groups outside the > USG and solicit input from such organizations as to how we can structure > version 2 of the profile to better suit their needs and/or actually > produce a single joint profile. > > Improve the utility of the profile as a tool for specifying > procurement requirements. > > The profile attempts to serve two audiences, purchasers and > suppliers of IPv6 capabilities. Our experience to date is that the level > of detail of version 1 of the profile might be a barrier to use by > purchasers. We seek input from purchasers/users as to how to make the > profile easier to use as a requirements check-list. > > Revise the concept / terms of 'device type' to make it clear that > the profile addresses the definition of sets of capabilities, from which > many product configurations can be instantiated and specified. > > Revise the profile testing sections to reflect the subsequent > development of the Testing Program and its guidance documents. > > Restructure the Network Protection Device section to better > accommodate the typical composition of products in this space. > > Review all IETF specifications cited in the profile to evaluate > errata and revised specifications that might impact USGv6 requirements. > > Examples might include: > Adopting the new IKEv2bis specification RFC 5996. > Adopting the new OSPFbis specification RFC 5340. > Revisiting the status of the various cryptographic algorithms > cited in version 1. > > Review the status of NIST recommendations, in particular those > capabilities marked SHOULD+ (S+) in version 1 of the profile, to > evaluate which, if any, should advance to MUST (M). > > Review the state of IETF specification and the industry to see if > any new capabilities/specifications should be added to the profile that > were not in version 1. > > The issues noted above capture some of our broad observations from 2 > years of experience in the development and operation of the USGv6 > program. We assume that the broader community also has similar input and > observations that should be considered before developing the first draft > of version 2. Thus NIST plans to pursue the development of version 2 of > the USGv6 profile as follows: > > Solicit community input and comment prior to the development of the > 1st draft of USGV6-v2. > Use the current profile and testing system as the basis / > reference for your comments. > Please submit comments using the provided spread sheet. > Completed comment sheets should be emailed to > usgv6-project@antd.nist.gov by COB June 10, 2011. > > NIST will review all received input and formulate a draft version 2 > of the profile that will be distributed for public comment in September > 2011. > > NIST will review and address all comments received and publish the > revised USGv6-V2 Profile before the end of 2011. > > Note that if a second public comment period is warranted, we would > conduct it such that it would not extend the target date above. If you > have any questions or comments about this process, please send them to: > usgv6-project@antd.nist.gov. > > We look forward to your input and participation. > > > _______________________________________________ > Nav6tf mailing list > Nav6tf@ipv6forum.com > http://lists.ipv6forum.com/mailman/listinfo/nav6tf > From samita.chakrabarti@ericsson.com Thu Jun 9 16:16:34 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF021F0C4C for ; Thu, 9 Jun 2011 16:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 ZUwdEmnU1lTb for ; Thu, 9 Jun 2011 16:16:33 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6035B1F0C4A for ; Thu, 9 Jun 2011 16:16:28 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p59NFu3d006481 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Jun 2011 18:16:25 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.2.108]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Thu, 9 Jun 2011 19:15:33 -0400 From: Samita Chakrabarti To: Erik Nordmark , "ipv6@ietf.org" Date: Thu, 9 Jun 2011 19:15:32 -0400 Subject: RE: Neighbor Unreachability Detection is too impatient Thread-Topic: Neighbor Unreachability Detection is too impatient Thread-Index: AcwZeh/869gvfvDMRzGtKIgBmEZBLANfzXPA Message-ID: <16D60F43CA0B724F8052D7E9323565D71E6607EFE3@EUSAACMS0715.eamcs.ericsson.se> References: <4DDAAB85.8000103@acm.org> In-Reply-To: <4DDAAB85.8000103@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 23:16:34 -0000 =20 I support this draft. Allowing > 3 retransmit is useful even for low-power= nodes as it saves power of processing/signalling for rebuilding the NCEs f= or sleepy nodes. It'll be good to specify a default MAX_*_CAST_SOLICIT value and a max-value= in the draft for the deployment/implementation when there is no default al= ternative router in the link. This will save some additional signaling traf= fic noise in the event of misconfiguration.=20 -Samita -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Eri= k Nordmark Sent: Monday, May 23, 2011 11:46 AM To: ipv6@ietf.org Subject: Neighbor Unreachability Detection is too impatient This draft proposes to change the requirement that NUD can not retransmit m= ore than three times, so that NUD can be more robust against temporary netw= ork outages. Comments? Erik -------- Original Message -------- Subject: New Version Notification for draft-nordmark-6man-impatient-nud-00.txt Date: Mon, 23 May 2011 11:43:16 -0700 From: internet-drafts@ietf.org To: nordmark@cisco.com CC: nordmark@cisco.com A new version of I-D, draft-nordmark-6man-impatient-nud-00.txt has been suc= cessfully submitted by Erik Nordmark and posted to the IETF repository. Filename: draft-nordmark-6man-impatient-nud Revision: 00 Title: Neighbor Unreachability Detection is too impatient Creation date: 2011-05-23 WG ID: Individual Submission Number of pages: 5 Abstract: IPv6 Neighbor Discovery includes Neighbor Unreachability Detection. That function is very useful when a host has an alternative, for instance multiple default routers, since it allows the host to switch to the alternative in short time. This time is 3 seconds after the node starts probing. However, if there are no alternatives, this is far too impatient. This document proposes an approach where an implementation can choose the timeout behavior to be different based on whether or not there are alternatives. =20 The IETF Secretariat -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From internet-drafts@ietf.org Fri Jun 10 03:16:54 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00D011E80A2; Fri, 10 Jun 2011 03:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 rUqXK1wIgVIH; Fri, 10 Jun 2011 03:16:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3B511E80A5; Fri, 10 Jun 2011 03:16:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-rfc3484-revise-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110610101654.26396.61851.idtracker@ietfa.amsl.com> Date: Fri, 10 Jun 2011 03:16:54 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 10:16:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the= IETF. Title : Update to RFC 3484 Default Address Selection for IPv6 Author(s) : Arifumi Matsumoto Jun-ya Kato Tomohiro Fujisaki Filename : draft-ietf-6man-rfc3484-revise-03.txt Pages : 11 Date : 2011-06-10 RFC 3484 describes algorithms for source address selection and for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. This document specifies a set of updates that modify the algorithms and fix the known defects. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-rfc3484-revise-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rfc3484-revise-03.txt From fernando.gont.netbook.win@gmail.com Fri Jun 10 15:08:28 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0678711E81D4; Fri, 10 Jun 2011 15:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.778 X-Spam-Level: X-Spam-Status: No, score=-2.778 tagged_above=-999 required=5 tests=[AWL=0.822, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 VBDMongDPP5D; Fri, 10 Jun 2011 15:08:27 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 36C5411E8104; Fri, 10 Jun 2011 15:08:27 -0700 (PDT) Received: by ywp31 with SMTP id 31so1575568ywp.31 for ; Fri, 10 Jun 2011 15:08:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:subject:x-enigmail-version:content-type :content-transfer-encoding; bh=LJCWCqhfSC5IVj+XF4amDXXNRadXPhy6uZBxNmXWyMg=; b=xiYuAAAVVC6C10wdipLGs2PCgK3CiLo2CUXAl0ufAxQehXbk9zsq9Kj/xbJBrh35yV JT/hTeZlW7TH9JDllLIlA9+hJE9tR/QAMLtcEOMvyrL4e9cE0y3ji0dHqf8hOknokFCp O0kMqQvTFZ7h8l+2Iy4xChMd3vQt58F9RfkKM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; b=OgV8nakN1z7z7KCF4P/eNz6MetGamVjm4OdWItWgKxc1bRezqoZGb5+IKajn8LXSjI MbLZKuJewajClfgn17ZuDjeN0yoUQfF4nC90FtWzjrO1exCNJ6HbeAttDZCkMJ8k/yA2 gwVrZgStSCt6jwYwpEN94zdh7F0IlblpDdQUc= Received: by 10.91.173.11 with SMTP id a11mr3623443agp.105.1307743706675; Fri, 10 Jun 2011 15:08:26 -0700 (PDT) Received: from [192.168.123.103] ([190.48.244.18]) by mx.google.com with ESMTPS id x33sm2946286ana.22.2011.06.10.15.08.24 (version=SSLv3 cipher=OTHER); Fri, 10 Jun 2011 15:08:26 -0700 (PDT) Sender: Fernando Gont Message-ID: <4DF291D0.7080707@gont.com.ar> Date: Fri, 10 Jun 2011 18:51:12 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: IPv6 Operations , "ipv6@ietf.org" Subject: Question regarding Ra-Guard evasion (ND and extensio headers) X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 22:08:28 -0000 Hi, Some folks have expressed (both on-list and off-list) that they would prefer a less agressive solution for the RA-Guard evasion vulnerability. So I'd like to hear comments about the possible alternatives.. The current I-Ds (draft-gont-6man-nd-extension-headers and draft-gont-v6ops-ra-guard-evasion) basically take this approach: * Prohibit use of extension headers in ND messages. A host implementation must not produce these packets, and must discard them if it receives them * This results in a RA-Guard implementation that is as simple as possible (it only has to look at the header following the fixed IPv6 header). A more relaxed approach would be as follows: * Extension headers are allowed with ND messages. * If the packet is fragmented, the upper-layer header (ICMPv6 in this case) must be present in the first fragment (i.e., hosts must not generate packets that violate this requirement, and must discard them if they receive them). * Possibly have the RA-Guard box enforce a limit on the maximum number of extension headers that it will process (e.g., if after jumping to the, say 10th header the upper-layer header is not found, drop the packet) * This approach is less aggressive than the one proposed in the aforementioned I-Ds (i.e., more flexibility), but of course would also mean that the RA-Guard implementation would need to follow the header chain, thus leading to increased complexity, and possible performance issues. Any comments/thoughts will be very much appreciated. Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From jari.arkko@piuha.net Fri Jun 10 15:46:09 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7028B11E80BF for ; Fri, 10 Jun 2011 15:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.438 X-Spam-Level: X-Spam-Status: No, score=-102.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 MDuKSYluF7Xp for ; Fri, 10 Jun 2011 15:46:08 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id B43CD11E8094 for ; Fri, 10 Jun 2011 15:46:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 1E4952CC3C; Sat, 11 Jun 2011 01:46: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 kCe8PG5Ji-I2; Sat, 11 Jun 2011 01:46:03 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 3372E2CC3B; Sat, 11 Jun 2011 01:46:03 +0300 (EEST) Message-ID: <4DF29EAA.1060103@piuha.net> Date: Sat, 11 Jun 2011 01:46:02 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: draft-ietf-6man-rpl-routing-header@tools.ietf.org, IETF IPv6 Mailing List Subject: AD review of draft-ietf-6man-rpl-routing-header Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 22:46:09 -0000 I have reviewed this draft. I have a number of comments, most of which are at this point questions and discussion items. The comments are included below in three categories: technical comments, editorial comments, and comments relating to feedback from other people that may not been fully handled yet. In general, the draft is well written and largely ready to move to a Proposed Standard RFC. However, there are a couple of issues that we need to discuss: MTU requirements, recommendations to consider alternative designs that exist only as Internet Drafts, and the feasibility of the loop check. I also need to apologize that it has taken far too long for me to do this review. There's no good excuse, but I've had some number of other documents in the queue this spring, day job requirements, and I knew I needed to review this document carefully. The rpl-option draft is next on my reading queue, probably reviewed by Monday. Technical: ======= > links within a RPL domain SHOULD have > a MTU of at least 1280 + 40 (outer IP header) + SRH_MAX_SIZE (+ > additional extension headers or options needed within RPL domain) > octets. > I thought that 6LOWPAN was an important link layer for the application of RPL. Yet, RFC 4944 specifies a MTU of 1280 octets. The above requirement seems to be in contradiction with what is available on 6LOWPAN. Am I missing some extension of 6LOWPAN that changes the MTU, or some other link layer that is expected to be used with RPL? If I'm not missing anything, wouldn't this cause a problem? It would seem that either you cannot run RPL on 6LOWPAN, run 6LOWPAN on non standard MTU values (and we know MTU negotiation is difficult), or you have to change the expectations of other nodes in the IPv6 Internet about the minimum assured MTU. Please clarify/resolve/tell me what I am missing. > A common network configuration for a RPL domain is that all nodes > within a LLN share a common prefix. The SRH introduces the CmprI, > CmprE, and Pad fields to allow compaction of the Address[1..n] vector > when all entries share the same prefix as the IPv6 Destination > Address field of the packet carrying the SRH. So all segments are treated based on how many bytes they have in common with the destination address. But the destination address keeps changing as we go through the intermediate hops. Is it necessary to clarify that the comparison/shared prefix is with the final destination address, NOT the address that happens to be in the destination address field currently? > In very specific cases, IPv6-in-IPv6 tunneling may be undesirable due > to the added cost and complexity required to process and carry a > datagram with two IPv6 headers. [I-D.hui-6man-rpl-headers ] describes > how to avoid using IPv6-in-IPv6 tunneling in such specific cases and > the risks involved. > This sounds like a recommendation to do something in a draft that has not been through the working group and approved as the something that is a sound practice. Unless the reference is normative, I think it is inappropriate to refer to an Internet draft in this manner. What I would recommend is to (1) change the "... SHOULD use IPv6-in-IPv6 tunneling ..." statement to a MUST in this draft, (2) remove the above text, and (3) make the corresponding changes to Section 5. Then we can take hui-6man-rpl-headers through the working group and provide a second, more light-weight approach that extends what we have RFC-to-be-draft-ietf-6man-rpl-routing-header. (FWIW, I think the problem begins when one adds the first byte to a packet somewhere along the route. It does not not matter so much how many bytes one adds, just the SRH or also the IP header. Most of the complications on MTUs and so one start at that point. In any case, SRHs may not be trivially small either. Assuming 64-bit prefix compression an SRH for 4 hops would be 40 bytes.) > If such addresses appear more than once and are separated by at least > one address not assigned to that router, the router MUST drop the > packet and SHOULD send an ICMP Parameter Problem, Code 0, to the > Source Address. > ... > else if 2 or more entries in Address[1..n] are assigned to > local interface and are separated by at least one > address not assigned to local interface { > discard the packet > } > The text and the code appear to disagree about whether to send an ICMP Parameter Problem message. Please align. I assume that an ICMP message is needed. > Because this document specifies that SRH is only for use within a RPL > domain, such attacks cannot be mounted from outside the RPL domain. > As described in Section 5 , RPL Border Routers MUST drop datagrams > entering or exiting the RPL domain that contain a SRH in the IPv6 > Extension headers. > This is good, and I think the security considerations are sufficient. However, I would be happier if the draft also recommended that by default, non-RPL routers and firewalls should drop packets with SRH. This would help ensure that SRH does not accidentally enter any network and expose some vulnerability. The practical effect that I'm looking for is, for instance, not having my Linux kernel process SRH unless I've configured it to use RPL. Editorial: ====== > In the above scenario, datagrams traveling from source, S, to > destination, D, have the following packet structure: > > > +------+------+------+--------//-+ > | IPv6 | IPv6 | IPv6 | Packet | > | Src | Dst | SRH | Payload | > +------+------+------+--------//-+ > This figure is not as clear as it could be. Are the src and dst field referring to the IPv6 header fields? Would this picture be better if you showed the IPv6 header explicitly? Please clarify. > CmprE 4-bit unsigned integer. Number of prefix octets > from the segment that are elided. For example, a > SRH carrying a full IPv6 address in Addresses[n] > sets CmprE to 0. > I understood the definition CmprI, but I do not understand this, at least not at the point of the above text. What is "the segment" that you are referring to above? SRH carries multiple segments. Please clarify. Little further down it becomes clear that CmprE refers to the compression of the last segment. Please make this clear already in the above text. Comments relating to feedback from others: ============================ The ADs have received a question from Joseph Reddy, who was asking if the set of addresses in the SRH should also include the source address of the node inserting the SRH. His justification for this was the need to be able to send an ICMP error back to this node. Do we have an answer? In April, Thomas Narten made some comments on the list and I didn't think that the discussion finished with any conclusion. Are his concerns (e.g., from his e-mail on April 29th) valid or not valid? I would like the working group to conclude this issue one way or the other. I refer to his comments regarding the feasibility of the loop check in particular. His e-mail is at http://www.ietf.org/mail-archive/web/ipv6/current/msg13887.html FWIW I agree with Thomas' editorial comment on Section 2 clarity. That should be easy to fix. Jari From ipng@69706e6720323030352d30312d31340a.nosense.org Fri Jun 10 18:15:53 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB98F11E809A; Fri, 10 Jun 2011 18:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.295 X-Spam-Level: X-Spam-Status: No, score=-1.295 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_13=0.6] 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 L7CoqFyfD9aJ; Fri, 10 Jun 2011 18:15:53 -0700 (PDT) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by ietfa.amsl.com (Postfix) with ESMTP id B98E39E8027; Fri, 10 Jun 2011 18:15:52 -0700 (PDT) Received: from 219-90-139-83.ip.adam.com.au ([219.90.139.83] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QVCne-0003VG-05; Sat, 11 Jun 2011 10:45:42 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 9213F3B338; Sat, 11 Jun 2011 10:45:40 +0930 (CST) Date: Sat, 11 Jun 2011 10:45:37 +0930 From: Mark Smith To: Fernando Gont Subject: Re: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers) Message-ID: <20110611104537.40918bcd@opy.nosense.org> In-Reply-To: <4DF291D0.7080707@gont.com.ar> References: <4DF291D0.7080707@gont.com.ar> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.4; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 01:15:54 -0000 Hi Fernando, On Fri, 10 Jun 2011 18:51:12 -0300 Fernando Gont wrote: > Hi, > > Some folks have expressed (both on-list and off-list) that they would > prefer a less agressive solution for the RA-Guard evasion vulnerability. > So I'd like to hear comments about the possible alternatives.. > > The current I-Ds (draft-gont-6man-nd-extension-headers and > draft-gont-v6ops-ra-guard-evasion) basically take this approach: > > * Prohibit use of extension headers in ND messages. A host > implementation must not produce these packets, and must discard them if > it receives them > * This results in a RA-Guard implementation that is as simple as > possible (it only has to look at the header following the fixed IPv6 > header). > If changing host implementations is an option, then a simpler idea might be to have RAs come from a source address from within a well-known range of link-local addresses. The 11th to 16th bits (or more) after the fe80 in the link local address could be used to indicate the type of address e.g. fe80::/16 - hosts and "legacy untyped" link local address use fe81::/16 - neighbor discovery address resolution fe82::/16 - router functions e.g. RAs, ICMPv6 redirects fe83::/16 - dhcpv6 server functions fe84::/16 - RIP messages and next-hops fe85::/16 - OSPF messages and next-hops fe86::/16 - IS-IS next hop fe87::/16 - BGP messages and next-hops etc. (I'm not sure if the routing protocol ones would be useful) so a device acting as a router, a dhcpv6-server and an host would have 3 link local addresses, using each different one for the corresponding function as a source address e.g. fe80::1 - normal link-local unicast communications fe81::1 - neighbor discovery address resolution functions fe82::1 - router related functions (RAs, ND redirects) fe83::1 - dhcpv6 server related functions I'd think "RA guard" type filtering would then be pretty easy in layer 2 devices, as these bits have a fixed location in the IPv6 header, and the filtering would be a binary match on a 16 bit value. For a switch interface facing a router, the switch would only accept fe80::16, fe81::/16 and fe82::/16 link local source addresses. For a switch interface facing a host, the switch would only accept fe80::16 and fe81::/16. Some IPv6 switches today are able to implement basic ACLs including source IPv6 addresses, so once the devices providing these functions are using these typed source addresses, there would be an option of implementing this sort of checking today for a number of people. I think the key advantage to this idea is that very little intensive packet checking has to occur before a forward/drop decision can be made. Hosts would have to implement these checks too. Until they're implemented in the IPv6 stack, an interim option would be to use the host's IPv6 firewall to perform these source address type checks. E.g., to only accept RAs from an allowed router, check the RA came from a link-local address with fe82::/16 in it's source address. I think the only outstanding issue might be is whether existing IPv6 implementations will allow or accept non-fe80::/16 link local source and destination addresses addresses until their IPv6 stacks are updated. I think it is possible that they would, as long as they aren't checking the values of the 54 zero bits between /10 and /64 in today's link local addresses. I don't have access to much of a test environment at the moment as I'm between jobs, so I'm limited to what I can test with a few Linux boxes. Encoding a device type or function in network layer addresses isn't a new idea, IIRC in appletalk they had clients use the lower 0 - 127 node addresses and servers use the higher 128 - 255 addresses on a cable number. Regards, Mark. > > A more relaxed approach would be as follows: > * Extension headers are allowed with ND messages. > * If the packet is fragmented, the upper-layer header (ICMPv6 in this > case) must be present in the first fragment (i.e., hosts must not > generate packets that violate this requirement, and must discard them if > they receive them). > * Possibly have the RA-Guard box enforce a limit on the maximum number > of extension headers that it will process (e.g., if after jumping to > the, say 10th header the upper-layer header is not found, drop the packet) > * This approach is less aggressive than the one proposed in the > aforementioned I-Ds (i.e., more flexibility), but of course would also > mean that the RA-Guard implementation would need to follow the header > chain, thus leading to increased complexity, and possible performance > issues. > > Any comments/thoughts will be very much appreciated. > > Thanks! > > Best regards, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From ipng@69706e6720323030352d30312d31340a.nosense.org Fri Jun 10 18:51:41 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B236311E80DF; Fri, 10 Jun 2011 18:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.595 X-Spam-Level: X-Spam-Status: No, score=-1.595 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 e6T8UdeDT78w; Fri, 10 Jun 2011 18:51:41 -0700 (PDT) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by ietfa.amsl.com (Postfix) with ESMTP id A569811E80A3; Fri, 10 Jun 2011 18:51:38 -0700 (PDT) Received: from 219-90-139-83.ip.adam.com.au ([219.90.139.83] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QVDMJ-0005OJ-6e; Sat, 11 Jun 2011 11:21:31 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id BA3A93B338; Sat, 11 Jun 2011 11:21:30 +0930 (CST) Date: Sat, 11 Jun 2011 11:21:30 +0930 From: Mark Smith To: Mark Smith Subject: Re: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers) Message-ID: <20110611112130.1ad58133@opy.nosense.org> In-Reply-To: <20110611104537.40918bcd@opy.nosense.org> References: <4DF291D0.7080707@gont.com.ar> <20110611104537.40918bcd@opy.nosense.org> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.4; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 01:51:41 -0000 On Sat, 11 Jun 2011 10:45:37 +0930 Mark Smith wrote: > Hi Fernando, > > > On Fri, 10 Jun 2011 18:51:12 -0300 > Fernando Gont wrote: > > > Hi, > > > > Some folks have expressed (both on-list and off-list) that they would > > prefer a less agressive solution for the RA-Guard evasion vulnerability. > > So I'd like to hear comments about the possible alternatives.. > > > > The current I-Ds (draft-gont-6man-nd-extension-headers and > > draft-gont-v6ops-ra-guard-evasion) basically take this approach: > > > > * Prohibit use of extension headers in ND messages. A host > > implementation must not produce these packets, and must discard them if > > it receives them > > * This results in a RA-Guard implementation that is as simple as > > possible (it only has to look at the header following the fixed IPv6 > > header). > > > > If changing host implementations is an option, then a simpler idea > might be to have RAs come from a source address from within a well-known > range of link-local addresses. The 11th to 16th bits (or more) after > the fe80 in the link local address could be used to indicate the type > of address e.g. > > fe80::/16 - hosts and "legacy untyped" link local address use > fe81::/16 - neighbor discovery address resolution > fe82::/16 - router functions e.g. RAs, ICMPv6 redirects > fe83::/16 - dhcpv6 server functions > fe84::/16 - RIP messages and next-hops > fe85::/16 - OSPF messages and next-hops > fe86::/16 - IS-IS next hop > fe87::/16 - BGP messages and next-hops > etc. > > (I'm not sure if the routing protocol ones would be useful) > > so a device acting as a router, a dhcpv6-server and an host would > have 3 link local addresses, using each different one for the ^ should be 4, realised that there probably would be value in having a separate category for neighbor discovery address resolution while writing the email, a few similar related errors below. > corresponding function as a source address e.g. > > fe80::1 - normal link-local unicast communications > fe81::1 - neighbor discovery address resolution functions > fe82::1 - router related functions (RAs, ND redirects) > fe83::1 - dhcpv6 server related functions > > I'd think "RA guard" type filtering would then be pretty easy in layer > 2 devices, as these bits have a fixed location in the IPv6 header, and > the filtering would be a binary match on a 16 bit value. For a > switch interface facing a router, the switch would only accept > fe80::16, fe81::/16 and fe82::/16 link local source addresses. should have been fe80::/16, fe81::/16, fe82::/16 and fe83::/16 > For a > switch interface facing a host, the switch would only accept fe80::16 fe80::/16 > and fe81::/16. Some IPv6 switches today are able to implement basic > ACLs including source IPv6 addresses, so once the devices providing > these functions are using these typed source addresses, there would be > an option of implementing this sort of checking today for a number of > people. I think the key advantage to this idea is that very little > intensive packet checking has to occur before a forward/drop decision > can be made. > > Hosts would have to implement these checks too. Until they're > implemented in the IPv6 stack, an interim option would be to use the > host's IPv6 firewall to perform these source address type checks. E.g., > to only accept RAs from an allowed router, check the RA came from a > link-local address with fe82::/16 in it's source address. > > I think the only outstanding issue might be is whether existing IPv6 > implementations will allow or accept non-fe80::/16 link local > source and destination addresses addresses until their IPv6 stacks are > updated. I think it is possible that they would, as long as they aren't > checking the values of the 54 zero bits between /10 and /64 in today's > link local addresses. I don't have access to much of a test environment > at the moment as I'm between jobs, so I'm limited to what I can test > with a few Linux boxes. > > Encoding a device type or function in network layer addresses isn't a > new idea, IIRC in appletalk they had clients use the lower 0 - 127 node > addresses and servers use the higher 128 - 255 addresses on a cable > number. > > > Regards, > Mark. > > > From pch-b2B3A6689@u-1.phicoh.com Sat Jun 11 01:10:13 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 214C711E8078; Sat, 11 Jun 2011 01:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.299 X-Spam-Level: X-Spam-Status: No, score=-8.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] 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 jrwcqzuWfqiC; Sat, 11 Jun 2011 01:10:12 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDAE11E8081; Sat, 11 Jun 2011 01:09:43 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QVJG6-0001gzC; Sat, 11 Jun 2011 10:09:30 +0200 Message-Id: To: Fernando Gont Subject: Re: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers) From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com In-reply-to: Your message of "Fri, 10 Jun 2011 18:51:12 -0300 ." <4DF291D0.7080707@gont.com.ar> Date: Sat, 11 Jun 2011 10:09:15 +0200 X-Mailman-Approved-At: Sat, 11 Jun 2011 01:14:49 -0700 Cc: IPv6 Operations , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 08:10:13 -0000 In your letter dated Fri, 10 Jun 2011 18:51:12 -0300 you wrote: >A more relaxed approach would be as follows: >* Extension headers are allowed with ND messages. >* If the packet is fragmented, the upper-layer header (ICMPv6 in this >case) must be present in the first fragment (i.e., hosts must not >generate packets that violate this requirement, and must discard them if >they receive them). >* Possibly have the RA-Guard box enforce a limit on the maximum number >of extension headers that it will process (e.g., if after jumping to >the, say 10th header the upper-layer header is not found, drop the packet) >* This approach is less aggressive than the one proposed in the >aforementioned I-Ds (i.e., more flexibility), but of course would also >mean that the RA-Guard implementation would need to follow the header >chain, thus leading to increased complexity, and possible performance >issues. Strikes me as a bad tradeoff. This requires all L2 switches to parse IPv6 extension headers at wire speed. So, some of them will get it wrong. And the only benefit menioned in the discussion so far is the need to send RAs large enough that they need to be fragmented. Another benefit would be that you don't have to change host software. From bob.hinden@gmail.com Sat Jun 11 08:02:15 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E2C21F84B9; Sat, 11 Jun 2011 08:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_BEZEQINT_B=0.763, 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 M8mhRNIgKjOt; Sat, 11 Jun 2011 08:02:15 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id E748E21F84B6; Sat, 11 Jun 2011 08:02:14 -0700 (PDT) Received: by pwi5 with SMTP id 5so1766029pwi.31 for ; Sat, 11 Jun 2011 08:02:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=trqkdDY7nYdLGbQnJDjULwsKj299c4iYmimqGrFvOTY=; b=rtg96Bd2GmnxpZLEMdMtikOYW3/yCrLaueqq5bEYo+H3pcF+sLzhj6/3EA7Hg8uwJ9 KravY4beQwJt59w0DCnnrkRfqlop5wCNtWuclxHJjcpaflezpFSt7GMm6tzRCX4lZ12z HYc6tlCr/5z/eQYc7Sj2EMjt0+cneLMXQCGEQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=vDxj5lNJ5vNJRvkd3pkD4TBixvIG/jl90B/B32QMDcV34YFzNgP3KfTcaqqPsl4HLR Hj6lUUPQAyIZ5/jQqL0GaO0RaqijC/ZnkOE1nOzJDNQRdeC5juhiH3s/2qhp8KFUtLK/ nZlr0CPRWu/AmB7vd/ggmX9h6ZyIBB/wKVYeY= Received: by 10.143.92.21 with SMTP id u21mr664116wfl.399.1307804534511; Sat, 11 Jun 2011 08:02:14 -0700 (PDT) Received: from [192.168.4.204] (bzq-218-39-93.cablep.bezeqint.net [81.218.39.93]) by mx.google.com with ESMTPS id k4sm3188467pbl.43.2011.06.11.08.02.10 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 11 Jun 2011 08:02:13 -0700 (PDT) Subject: Re: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: <4DF291D0.7080707@gont.com.ar> Date: Sat, 11 Jun 2011 18:02:04 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4B579A55-9973-4454-9BD5-256094ED3FC3@gmail.com> References: <4DF291D0.7080707@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1084) Cc: "ipv6@ietf.org" , IPv6 Operations , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 15:02:15 -0000 Fernando, On Jun 11, 2011, at 12:51 AM, Fernando Gont wrote: > Hi, >=20 > Some folks have expressed (both on-list and off-list) that they would > prefer a less agressive solution for the RA-Guard evasion = vulnerability. > So I'd like to hear comments about the possible alternatives.. >=20 > The current I-Ds (draft-gont-6man-nd-extension-headers and > draft-gont-v6ops-ra-guard-evasion) basically take this approach: >=20 > * Prohibit use of extension headers in ND messages. A host > implementation must not produce these packets, and must discard them = if > it receives them > * This results in a RA-Guard implementation that is as simple as > possible (it only has to look at the header following the fixed IPv6 > header). What is a use case where extension headers would be used in ND (ICMPv6) = messages? Same for Fragmentation? =20 I am having a hard time thinking of any, so I like your approach. = Unless I am missing something. Thanks, Bob >=20 >=20 > A more relaxed approach would be as follows: > * Extension headers are allowed with ND messages. > * If the packet is fragmented, the upper-layer header (ICMPv6 in this > case) must be present in the first fragment (i.e., hosts must not > generate packets that violate this requirement, and must discard them = if > they receive them). > * Possibly have the RA-Guard box enforce a limit on the maximum number > of extension headers that it will process (e.g., if after jumping to > the, say 10th header the upper-layer header is not found, drop the = packet) > * This approach is less aggressive than the one proposed in the > aforementioned I-Ds (i.e., more flexibility), but of course would also > mean that the RA-Guard implementation would need to follow the header > chain, thus leading to increased complexity, and possible performance > issues. >=20 > Any comments/thoughts will be very much appreciated. >=20 > Thanks! >=20 > Best regards, > --=20 > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From fernando.gont.netbook.win@gmail.com Sun Jun 12 04:00:10 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8669011E8096; Sun, 12 Jun 2011 04:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_LOW=-1] 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 wIEz2Nn1P2bq; Sun, 12 Jun 2011 04:00:10 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0FF11E8092; Sun, 12 Jun 2011 04:00:09 -0700 (PDT) Received: by wyb29 with SMTP id 29so3071870wyb.31 for ; Sun, 12 Jun 2011 04:00:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=hR6Bglf5ujR84G7P4qrRuCBes8RLK2zK4+zrUKHbJuw=; b=oOT6a7x73b8Hr5O0BC0qA9CKTR8BWzUlusfoUr/RQHFYmam4qAEqQu2CenDJVjRAYA M3VEBT7kb3Mb9tb/HqETD/NOwZ9Fb/+APCrv9KUivxoZUTBcMbD6e2wDYhx/4NLYDYh7 kIrlhvG+HASukt35VLWFjBg5thiKT8lTvg0rE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=RXUaw483BbSEcJ5nkY+OApxav/sqSH49BEgU8rB/nofeIpzdlgyu0YdZR5eKDkjvkQ CYxT2glwDt4UprwoFK54NJSk8jzwB+riHtyhzSN+uh6SHOB535nOH1AvBbX34WcxMKZR RoQGWM5LinLah8TzkMMtattg7DzhdgMhEUb6I= Received: by 10.216.30.206 with SMTP id k56mr1561890wea.29.1307876408212; Sun, 12 Jun 2011 04:00:08 -0700 (PDT) Received: from [192.168.101.204] ([213.174.121.108]) by mx.google.com with ESMTPS id gb6sm3409060wbb.0.2011.06.12.04.00.06 (version=SSLv3 cipher=OTHER); Sun, 12 Jun 2011 04:00:07 -0700 (PDT) Sender: Fernando Gont Message-ID: <4DF3D711.6@gont.com.ar> Date: Sat, 11 Jun 2011 17:58:57 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Mark Smith Subject: Re: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers) References: <4DF291D0.7080707@gont.com.ar> <20110611104537.40918bcd@opy.nosense.org> <20110611112130.1ad58133@opy.nosense.org> In-Reply-To: <20110611112130.1ad58133@opy.nosense.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 11:00:10 -0000 Hi, Mark, On 06/10/2011 10:51 PM, Mark Smith wrote: >> If changing host implementations is an option, then a simpler idea >> might be to have RAs come from a source address from within a well-known >> range of link-local addresses. The 11th to 16th bits (or more) after >> the fe80 in the link local address could be used to indicate the type >> of address e.g. This might help with attack vectors based on forged RAs, but not with other vectors (e.g., forged Neighbor Advertisements). Also, your proposal modifies the addressing architecture -- while this is not "per se" a bad thing this is a more radical change than the one proposed in my I-D (which, as far as legitimate traffic is concerned, is a no-op, since extension headers with ND are not used for any legitimate purpose). >> (I'm not sure if the routing protocol ones would be useful) >> >> so a device acting as a router, a dhcpv6-server and an host would >> have 3 link local addresses, using each different one for the > ^ > should be 4, realised that there probably would be value in having a > separate category for neighbor discovery address resolution while > writing the email, a few similar related errors below. If you don't prevent the use of extension headers for ND (in particular, of the Fragment Header) it's still very painful to perform any kind of monitoring on the Neighbor Discovery traffic (e.g., with NDPMon and the like). >> and fe81::/16. Some IPv6 switches today are able to implement basic >> ACLs including source IPv6 addresses, so once the devices providing >> these functions are using these typed source addresses, there would be Note that this would also require an update to routers (which might not be possible), and would also imply a rather radical change for the ops people (which, imo, at this point in time would be a bad thing). But there seems to be an even more substantial problem: this seems to require a flag day. i.e., how do hosts tell if they are receiving "traditional" RAs because they are under attack, or because the network has not yet been upgraded to implement your proposal? >> an option of implementing this sort of checking today for a number of >> people. I think the key advantage to this idea is that very little >> intensive packet checking has to occur before a forward/drop decision >> can be made. If extension headers are prohibited, you only need to look at fixed locations in the packet (IPv6 "Next Header", and then ICMP type). >> Hosts would have to implement these checks too. Until they're >> implemented in the IPv6 stack, an interim option would be to use the >> host's IPv6 firewall to perform these source address type checks. E.g., >> to only accept RAs from an allowed router, check the RA came from a >> link-local address with fe82::/16 in it's source address. But the RA-Guard box would still need to deal with the "traditional" RAs, since there might be legacy hosts that would react to them. >> I think the only outstanding issue might be is whether existing IPv6 >> implementations will allow or accept non-fe80::/16 link local >> source and destination addresses addresses until their IPv6 stacks are >> updated. I think it is possible that they would, as long as they aren't >> checking the values of the 54 zero bits between /10 and /64 in today's >> link local addresses. Oh, yes, they do. :-) KAME discards such packets. Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando.gont.netbook.win@gmail.com Sun Jun 12 04:00:15 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7441E11E80E2; Sun, 12 Jun 2011 04:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_LOW=-1] 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 Bv-9zKwne3Dr; Sun, 12 Jun 2011 04:00:15 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6959F11E80E1; Sun, 12 Jun 2011 04:00:14 -0700 (PDT) Received: by wwa36 with SMTP id 36so2673992wwa.13 for ; Sun, 12 Jun 2011 04:00:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=nfyNU9RYt1dFv51WNHmWVZL4KVlseTpCJpZQ65ZOCwc=; b=Y+CTGiAmeSK6KTUiXuUJMANPBhzNZVFG9MNq/Ng5C9jinvLXv9pkWATkDr0K7S635j cRL1Go/EFevvGvgw6kAfHyb51fYIKYzSPnjQBM+dwF5HZHh4HEHm6PNmNvlOyFKPzGJV KuM5k7omwx9NzdsATsyrz6BGfcZKn18GefayA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=Tmc06Z3o9eTzh/A52YdOcTQWDFmM5DPaMRl1PGqGyFGLZCxXncc9U3RD4RVKSD8PXV vCBJ9n+m2GuLBygqP6cFr+0b+BnbZHYnk8HhJo/9fKWnNR/L3jzgHWbATijXC6HW1cyl ZFNyxsQmWpRemaRNHA1HdrAykNFrlh/aOIu+I= Received: by 10.227.182.74 with SMTP id cb10mr3986866wbb.48.1307876413579; Sun, 12 Jun 2011 04:00:13 -0700 (PDT) Received: from [192.168.101.204] ([213.174.121.108]) by mx.google.com with ESMTPS id c17sm3406527wbh.29.2011.06.12.04.00.11 (version=SSLv3 cipher=OTHER); Sun, 12 Jun 2011 04:00:13 -0700 (PDT) Sender: Fernando Gont Message-ID: <4DF3DAA0.5090206@gont.com.ar> Date: Sat, 11 Jun 2011 18:14:08 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Philip Homburg Subject: Re: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers) References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 11:00:15 -0000 On 06/11/2011 05:09 AM, Philip Homburg wrote: >> * Possibly have the RA-Guard box enforce a limit on the maximum number >> of extension headers that it will process (e.g., if after jumping to >> the, say 10th header the upper-layer header is not found, drop the packet) >> * This approach is less aggressive than the one proposed in the >> aforementioned I-Ds (i.e., more flexibility), but of course would also >> mean that the RA-Guard implementation would need to follow the header >> chain, thus leading to increased complexity, and possible performance >> issues. > > Strikes me as a bad tradeoff. This requires all L2 switches to parse IPv6 > extension headers at wire speed. So, some of them will get it wrong. +1 > And the only benefit menioned in the discussion so far is the need to send > RAs large enough that they need to be fragmented. Actually, you can get the same benefit with no fragmentation: just send multiple RAs. > Another benefit would be that you don't have to change host software. I think that, in practice, this is less of an issue. In may cases, this could be an automatic "security update". In others, the hosts may be connected to networks that do not yet support v6, and by the time v6 is deployed on these networks, the corresponding OSes will have already been updated/upgraded. Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando.gont.netbook.win@gmail.com Sun Jun 12 04:00:18 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C3B11E80EE; Sun, 12 Jun 2011 04:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_LOW=-1] 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 zGlYrnlsSVYF; Sun, 12 Jun 2011 04:00:17 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 21B4A11E80E7; Sun, 12 Jun 2011 04:00:16 -0700 (PDT) Received: by wwk4 with SMTP id 4so1868399wwk.1 for ; Sun, 12 Jun 2011 04:00:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=UUmqf+IzgAQXU2Nh21mcxOn6T/2mfIym7bKoeR9rEU4=; b=h8rF+K7Zp4ZZiPhKA4+DrWOlT5jB9jii2yAXsT0NmMbTyQ6TOk38W4SN89vzP9hwBd CrrXFfFz6dPOacn/n+eIijSnb0Qhh4jDbZL19+agh8k2+RWHQoXlQWwOhfW5YlW/ZBbz 2T378T1vL0PLzZOTzYPnHXrsCossNot3mcNcI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=AsGwWNZjcxutCyl42dJvuXK3o3EYxCJKy1AvPFl1jqI07w3tSYA5eeeyqi/ICoPwzQ NB1VW2/7Pv+aFPAsjNnY9nd9EDlVnltC9nyaIlAzA8YP5QaXtWvguG5T8w4nUMZgnucw em5yUo32+bTb5kTNJZo5H5KknTx4p6+ch4G/g= Received: by 10.227.160.11 with SMTP id l11mr3910270wbx.1.1307876416189; Sun, 12 Jun 2011 04:00:16 -0700 (PDT) Received: from [192.168.101.204] ([213.174.121.108]) by mx.google.com with ESMTPS id o19sm3407147wbh.21.2011.06.12.04.00.15 (version=SSLv3 cipher=OTHER); Sun, 12 Jun 2011 04:00:15 -0700 (PDT) Sender: Fernando Gont Message-ID: <4DF3F91A.2080109@gont.com.ar> Date: Sat, 11 Jun 2011 20:24:10 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Bob Hinden Subject: Re: [v6ops] Question regarding Ra-Guard evasion (ND and extension headers) References: <4DF291D0.7080707@gont.com.ar> <4B579A55-9973-4454-9BD5-256094ED3FC3@gmail.com> In-Reply-To: <4B579A55-9973-4454-9BD5-256094ED3FC3@gmail.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 11:00:18 -0000 Hi, Bob, On 06/11/2011 12:02 PM, Bob Hinden wrote: >> * Prohibit use of extension headers in ND messages. A host >> implementation must not produce these packets, and must discard >> them if it receives them * This results in a RA-Guard >> implementation that is as simple as possible (it only has to look >> at the header following the fixed IPv6 header). > > What is a use case where extension headers would be used in ND > (ICMPv6) messages? I am told that AH could potentially be used with ND. Also, that some high-security sites might want to use CALIPSO with ND. And that there's always the possibility that somebody could come up with with an ND extension/feature that requires IPv6 extension headers. I personally think that when it comes to possible extensions to ND, most of them could be implemented with ND options (rather than extension headers). As for AH or CALIPSO, from my perspective (and if anything) I'd argue that the I-D could require that hosts include a configuration switch that can enable the processing of ND packets with extension headers (such configuration knob would default to "off/disable") -- i.e., for the general case (and by default), ND packets are not allowed to include IPv6 extension headers.. but if you have a specific scenario in which you'd need them (unlikely, from my perspective), you can override this policy such that they are accepted. > Same for Fragmentation? As far as I can tell from Pekka's note, at least radvd does not support fragmentation with ND. So the only *potential* use case is sending (probably insane) amounts of information in RAs -- but you can always send the same amount of information using multiple RAs. > I am having a hard time thinking of any, so I like your approach. I believe the approach currently outlined in the I-Ds keeps things simple and allows for simple RA-guard implementation and ND-monitoring tools like NDPMon. And that's the approach I would prefer to pursue. However, since some had brought up possible alternatives, I wanted others to weigh in. Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From Ted.Lemon@nominum.com Mon Jun 13 15:44:39 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7BD21F8491; Mon, 13 Jun 2011 15:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 dbXsOIHujFSJ; Mon, 13 Jun 2011 15:44:35 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id CE9D921F8492; Mon, 13 Jun 2011 15:44:34 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTfaS0fvgg+1R8c/ywz0EFpIW3DEOwxD6@postini.com; Mon, 13 Jun 2011 15:44:34 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 4BF15F8042; Mon, 13 Jun 2011 15:44:33 -0700 (PDT) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 41788190058; Mon, 13 Jun 2011 15:44:33 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from kali.ddns.nominum.com (64.89.225.121) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 13 Jun 2011 15:44:33 -0700 Subject: Re: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers) MIME-Version: 1.0 (Apple Message framework v1237.1) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <4DF69180.6050902@inex.ie> Date: Mon, 13 Jun 2011 15:44:32 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: <701DCBC2-E1B6-420A-B258-504589335A20@nominum.com> References: <4DF291D0.7080707@gont.com.ar> <4DF69180.6050902@inex.ie> To: Nick Hilliard X-Mailer: Apple Mail (2.1237.1) Cc: IPv6 Operations , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 22:44:39 -0000 On Jun 13, 2011, at 3:38 PM, Nick Hilliard wrote: > dhcpv6 suffers from exactly the same problem. Are there plans to = introduce dhcpv6-guard? Nobody's proposed it. From stephen.farrell@cs.tcd.ie Mon Jun 13 16:09:32 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDEF8228011; Mon, 13 Jun 2011 16:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.183 X-Spam-Level: X-Spam-Status: No, score=-106.183 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, 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 LQo6OWhbZy3L; Mon, 13 Jun 2011 16:09:32 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id A3152228010; Mon, 13 Jun 2011 16:09:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 10013171C57; Tue, 14 Jun 2011 00:09:28 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1308006564; bh=2M+MRdBDcYEi+w uymS+lhd6/LQM/EloQMaEtcwOBKK0=; b=XocrV9AIVVQ53tuk/v7lL8rFH88TDm PyDbEB4R/N2TPwGux3n8DMoLN7Pc4j2UECg5iceaSfE3qgISHMpFndoNka2zVwh7 ptRUU3kq/HUfLz14+UoU8Km5sPp6pNb9CAh2NV2PgY7Nmo2PfPDp8Ri533EpZe8F VwUSLd6pmiTULnHpKYykYDb+JFFWqnLDAAJpVRpirlr67R4+5Ndc7C2ggQxKU6QI BTtAhtTRaAu3fSrMttGii8ILx/9yL8IH+P9KldYJfJjC+2WWnYwwqAydL2mTUuWJ t1bN8I1zkyrnmdDuEJb/uoukxtLnEUu8cxAH/fnxP+lMUPo7RCe5Mzkg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id TV7xFrezEjkZ; Tue, 14 Jun 2011 00:09:24 +0100 (IST) Received: from [10.87.48.10] (unknown [86.42.18.245]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 3E613171C2D; Tue, 14 Jun 2011 00:09:24 +0100 (IST) Message-ID: <4DF69899.2050606@cs.tcd.ie> Date: Tue, 14 Jun 2011 00:09:13 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Stephen Farrell Subject: Re: [saag] ITU-T SG17 IPv6 security work items liaison References: <4DEA6323.4070302@cs.tcd.ie> In-Reply-To: <4DEA6323.4070302@cs.tcd.ie> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org, ipv6@ietf.org, "saag@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 23:09:33 -0000 All, Thanks for the feedback on this liaison. Eliot (mostly) and I (a bit) have tried to capture all that in the text below. Please send any comments on that (with specific alternative text) in the next week and then we'll shoot it on to them. RFC 3514 does have some words about IPv6 - should I add that as a reference? :-) Thanks, Stephen. From: IETF Security Area To: Study Group 17, Questions 2 and 3 Title: Work on Security of IPv6 FOR ACTION The IETF thanks Study Group 17 for its liaison LS-206 "Liaison on IPv6 security issues". As the world transitions to IPv6, new opportunities and challenges and challenges arise. SG17's new focus on deployment and implementation considerations reflects this reality. We would like to bring to your attention the following work which we believe may prove a useful basis for both X.ipv6-secguide and X.mgv6: * RFC 4294 – "IPv6 Node Requirements" (N.B., this work is currently under revision) * draft-ietf-6man-node-req-bis (work in progress) – "IPv6 Node Requirements RFC 4294-bis" * RFC 4864 – "Local Network Protection for IPv6" * RFC 6092 – "Recommended Simple Security Capabilities in Customer Premise Equipment (CPE) for Providing Residential IPv6 Internet Service" * RFC 6105 – "IPv6 Router Advertisement Guard" * RFC 6106 – "IPv6 Router Advertisement Options for DNS Configuration", §7 in particular. As you are aware, every RFC contains a Security Considerations section. In developing either a implementation or deployment guide, contributors are strongly encouraged to review the RFCs and Internet-Drafts that support any underlying function. In addition, we bring to your attention the following IETF Working Groups that are working on security-related work of IPv6: Working Group Purpose Mailing list address Name 6man IPv6 Maintenance ipv6@ietf.org savi Source Address Validation savi@ietf.org Improvements dhc Dynamic Host Configuration dhcwg@ietf.org v6ops IPv6 Operations v6ops@ietf.org opsec Operational Security opsec@ietf.org Capabilities for an IP Network In addition to the above working groups, the Security Area of the IETF maintains a mailing list for general discussion, saag@ietf.org. We encourage and invite open and informal discussion in these or other relevant IETF fora on this very important topic. As with all IETF working groups, any and all interested parties can choose to directly contribute via the mailing lists above. As in other areas, the Security Area of the IETF invites SG17 to bring any new-found concerns about IETF protocols to our attention so that as and when we revise our documents we can make appropriate amendments to IETF protocols. In particular, as this planned work matures, we would welcome hearing about it in more detail, perhaps via an invited presentation at a saag meeting or via review of draft documents as may be appropriate. From stephen.farrell@cs.tcd.ie Mon Jun 13 17:01:28 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4ED321F8479; Mon, 13 Jun 2011 17:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.137 X-Spam-Level: X-Spam-Status: No, score=-106.137 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, 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 bF9AVgqOyG62; Mon, 13 Jun 2011 17:01:28 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id C8A9321F8478; Mon, 13 Jun 2011 17:01:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id EADA1171C57; Tue, 14 Jun 2011 01:01:23 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1308009683; bh=5brO03To29fhYd a07P2lJXC4KlbotzYy3H/AyOFPMvI=; b=qZt/PET7ZAxj8DkKgTGHIbGJ9tTFzM LKMYDCrZHssLdzupGCVfsRd7F6o0i9OrdgEZgCXBQa5YPb14k/Cv/CaaAoGh5N0l BPrSZx4k+LxZnLdYQ9jQ2a4J0uAHW6s/+6G9RelCis4qK5goaj5htY1CUTjnC5O3 zW9tG/n7Ki513g1FWAVLDpdSK5fXpJpoiF6Y7zE0kL6wyBZEe1VXRiiI9yZea2gB 7Guc0YOoX+BgSvxsQdYj1Wfcmbm0fppenhd4WHrLnIuwoOxHt5g7CTueKATRBLPF 48lEEW+Jr0FFL+tAVKthdOAcKJOgVKo5rMWGQNcn57Za3tHhiWPN24mg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id UIGQ1gVqZRlH; Tue, 14 Jun 2011 01:01:23 +0100 (IST) Received: from [10.87.48.10] (unknown [86.42.18.245]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 6417A171C2D; Tue, 14 Jun 2011 01:01:23 +0100 (IST) Message-ID: <4DF6A4D2.9060306@cs.tcd.ie> Date: Tue, 14 Jun 2011 01:01:22 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Russ Housley Subject: Re: [saag] ITU-T SG17 IPv6 security work items liaison References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org, ipv6@ietf.org, "saag@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 00:01:28 -0000 Thanks Russ, will make those changes. S. On 14/06/11 00:57, Russ Housley wrote: > Stephen: > > Comments below. > > Russ > > >> From: IETF Security Area >> To: Study Group 17, Questions 2 and 3 >> Title: Work on Security of IPv6 >> >> FOR ACTION >> >> The IETF thanks Study Group 17 for its liaison LS-206 "Liaison on IPv6 >> security issues". As the world transitions to IPv6, new opportunities >> and challenges and challenges arise. SG17's new focus on deployment and > > s/and challenges and challenges/and challenges/ > s/new// > >> implementation considerations reflects this reality. We would like to >> bring to your attention the following work which we believe may prove a >> useful basis for both X.ipv6-secguide and X.mgv6: >> >> * RFC 4294 – "IPv6 Node Requirements" (N.B., this work is currently >> under revision) > > Why not just reference the bis document? > >> * draft-ietf-6man-node-req-bis (work in progress) – "IPv6 Node >> Requirements RFC 4294-bis" >> * RFC 4864 – "Local Network Protection for IPv6" >> * RFC 6092 – "Recommended Simple Security Capabilities in Customer >> Premise Equipment (CPE) for Providing Residential IPv6 Internet >> Service" >> * RFC 6105 – "IPv6 Router Advertisement Guard" >> * RFC 6106 – "IPv6 Router Advertisement Options for DNS >> Configuration", §7 in particular. >> >> As you are aware, every RFC contains a Security Considerations section. >> In developing either a implementation or deployment guide, contributors >> are strongly encouraged to review the RFCs and Internet-Drafts that >> support any underlying function. >> >> In addition, we bring to your attention the following IETF Working >> Groups that are working on security-related work of IPv6: >> >> Working Group Purpose Mailing list address >> Name >> >> 6man IPv6 Maintenance ipv6@ietf.org >> savi Source Address Validation savi@ietf.org >> Improvements >> dhc Dynamic Host Configuration dhcwg@ietf.org >> v6ops IPv6 Operations v6ops@ietf.org >> opsec Operational Security opsec@ietf.org >> Capabilities for an IP >> Network >> >> In addition to the above working groups, the Security Area of the IETF >> maintains a mailing list for general discussion, saag@ietf.org. We >> encourage and invite open and informal discussion in these or other >> relevant IETF fora on this very important topic. As with all IETF >> working groups, any and all interested parties can choose to directly >> contribute via the mailing lists above. >> >> As in other areas, the Security Area of the IETF invites SG17 to bring >> any new-found concerns about IETF protocols to our attention so that as >> and when we revise our documents we can make appropriate amendments to >> IETF protocols. In particular, as this planned work matures, we would >> welcome hearing about it in more detail, perhaps via an invited >> presentation at a saag meeting or via review of draft documents as may >> be appropriate. > > From fernando.gont.netbook.win@gmail.com Mon Jun 13 19:04:04 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7F8521F85B5; Mon, 13 Jun 2011 19:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 y6sqItt+jzCt; Mon, 13 Jun 2011 19:04:03 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id EFA1821F85B0; Mon, 13 Jun 2011 19:04:02 -0700 (PDT) Received: by wyb29 with SMTP id 29so4131316wyb.31 for ; Mon, 13 Jun 2011 19:04:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=Kj/7qrMuzXyGd4+3Q1fZJ5x7MHvhu+NzEY13BkZNomM=; b=RZNxU27bDKox+nL7MKSlTv91MiWX6gGI5m1W1xSuqVMAkMJl00pA7O23duAxf1lmO1 9BZ36fQJgfNz/KBcZcxP1r/ArmrI+73bR7JETewshrm1ykAMIYsYrNc9lR1JamEy0QcX GJzJED5dhrDjMUDhNVzHXl/VdzG1lxZMVvZ84= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=wAKbEljEe2apg+KRZxUJ8J+p3YqFwHi0Mj9JrQIz9iuTRDKukMQc5o+y3gcEjipKs4 Ky4ZmD6eqi2sjc8pygZPdCtZFzmTbDvcOfcaxleWdtsA3uVBp2vsxIuYsu5u9Mh8GehW DpFMZHTSr1+aJqeEDyf4um9/xxuD3ye1gFBoE= Received: by 10.216.136.67 with SMTP id v45mr124432wei.106.1308017042002; Mon, 13 Jun 2011 19:04:02 -0700 (PDT) Received: from [172.18.16.182] ([81.253.1.188]) by mx.google.com with ESMTPS id m8sm4648212wbh.62.2011.06.13.19.04.00 (version=SSLv3 cipher=OTHER); Mon, 13 Jun 2011 19:04:01 -0700 (PDT) Sender: Fernando Gont Message-ID: <4DF6B804.4040703@gont.com.ar> Date: Mon, 13 Jun 2011 22:23:16 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Nick Hilliard Subject: Re: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers) References: <4DF291D0.7080707@gont.com.ar> <4DF69180.6050902@inex.ie> In-Reply-To: <4DF69180.6050902@inex.ie> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 02:04:04 -0000 On 06/13/2011 07:38 PM, Nick Hilliard wrote: > On 10/06/2011 22:51, Fernando Gont wrote: >> * This results in a RA-Guard implementation that is as simple as >> possible (it only has to look at the header following the fixed IPv6 >> header). > > dhcpv6 suffers from exactly the same problem. Agreed. This is noted in the I-D, by the way. > Are there plans to introduce dhcpv6-guard? This is something that vendors should answer. As long as there are implementations that may try DHCPv6 even if no RA is received, DHCPv6 should be implemented/deployed along RA-Guard, or else attackers will switch to teh DHCPv6 vector, and RA-Guard will be circumvented this way. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From swmike@swm.pp.se Mon Jun 13 21:20:07 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358C31F0C3E; Mon, 13 Jun 2011 21:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 RAeyN+-FLWml; Mon, 13 Jun 2011 21:20:02 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id AC2B11F0C35; Mon, 13 Jun 2011 21:20:01 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 6089E9C; Tue, 14 Jun 2011 06:19:58 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 5B2F69A; Tue, 14 Jun 2011 06:19:58 +0200 (CEST) Date: Tue, 14 Jun 2011 06:19:58 +0200 (CEST) From: Mikael Abrahamsson To: Ted Lemon Subject: Re: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers) In-Reply-To: <701DCBC2-E1B6-420A-B258-504589335A20@nominum.com> Message-ID: References: <4DF291D0.7080707@gont.com.ar> <4DF69180.6050902@inex.ie> <701DCBC2-E1B6-420A-B258-504589335A20@nominum.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Operations , Nick Hilliard , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 04:20:07 -0000 On Mon, 13 Jun 2011, Ted Lemon wrote: > On Jun 13, 2011, at 3:38 PM, Nick Hilliard wrote: >> dhcpv6 suffers from exactly the same problem. Are there plans to introduce dhcpv6-guard? > > Nobody's proposed it. I'd be surprised if implementations of this wouldn't also have some kind of idea or concept of "client ports" and "server ports"? -- Mikael Abrahamsson email: swmike@swm.pp.se From bob.hinden@gmail.com Mon Jun 13 21:51:54 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39B9B11E8132; Mon, 13 Jun 2011 21:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_BEZEQINT_B=0.763, 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 pA8WQ1nMPHJp; Mon, 13 Jun 2011 21:51:53 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id D38A411E80BE; Mon, 13 Jun 2011 21:51:52 -0700 (PDT) Received: by wwk4 with SMTP id 4so3173310wwk.1 for ; Mon, 13 Jun 2011 21:51:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=6AThwAjNBVwPIKrUgpuFEpb/oXzGgDCcnmzweIpCl+Y=; b=NV3Qq92MVq0LJRz9+0UOFrFG20XgQ1OlawVA9896fKvBJ+SGYB1MPl6A9UZpQz+bhf GYbHxuoQe1pmqKTfhfA1Z4VTrXsKO8UKpgUWkhweRYrkNSEMJTUHIefMK5Abbvyh9S6u CziJVwgJMkI+N1l8fWDTRmbG/zWlu/5JzJQwc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=Kxho02N5kcfl28ZqEuMuPQJMjWGd5N7avksGSVy2VcIOyY0xTg7CFcujz7xHAVW67t j1Q5pqte8yl0jfy59w/po6+CXHVLLKatULLejgrzARwH9zXCDRQ0h/bAdHbw0bGiPkpo RWCteZJatH0jaxGP1FVvonGDmidwVujGB3TSc= Received: by 10.227.196.193 with SMTP id eh1mr5937739wbb.12.1308027098894; Mon, 13 Jun 2011 21:51:38 -0700 (PDT) Received: from [192.168.4.127] (bzq-218-39-93.cablep.bezeqint.net [81.218.39.93]) by mx.google.com with ESMTPS id fl19sm4717598wbb.49.2011.06.13.21.51.37 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 13 Jun 2011 21:51:38 -0700 (PDT) Subject: Re: [v6ops] [saag] ITU-T SG17 IPv6 security work items liaison Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Bob Hinden In-Reply-To: Date: Tue, 14 Jun 2011 07:51:35 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <22C01597-E89D-4200-8251-2F3979ABB0B6@gmail.com> References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> To: Russ Housley X-Mailer: Apple Mail (2.1084) Cc: ipv6@ietf.org, v6ops@ietf.org, Bob Hinden , "saag@ietf.org" , Stephen Farrell X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 04:51:54 -0000 Russ, On Jun 14, 2011, at 2:57 AM, Russ Housley wrote: > Stephen: >=20 > Comments below. >=20 > Russ >=20 >=20 >> From: IETF Security Area >> To: Study Group 17, Questions 2 and 3 >> Title: Work on Security of IPv6 >>=20 >> FOR ACTION >>=20 >> The IETF thanks Study Group 17 for its liaison LS-206 "Liaison on = IPv6 >> security issues". As the world transitions to IPv6, new = opportunities >> and challenges and challenges arise. SG17's new focus on deployment = and >=20 > s/and challenges and challenges/and challenges/ > s/new// >=20 >> implementation considerations reflects this reality. We would like = to >> bring to your attention the following work which we believe may prove = a >> useful basis for both X.ipv6-secguide and X.mgv6: >>=20 >> * RFC 4294 =96 "IPv6 Node Requirements" (N.B., this work is = currently >> under revision) >=20 > Why not just reference the bis document? >=20 >> * draft-ietf-6man-node-req-bis (work in progress) =96 "IPv6 Node >> Requirements RFC 4294-bis" The draft could also say that the working group has reached consensus = and has submitted it to the IESG for publication on 25 May 2011. Bob >> * RFC 4864 =96 "Local Network Protection for IPv6" >> * RFC 6092 =96 "Recommended Simple Security Capabilities in = Customer >> Premise Equipment (CPE) for Providing Residential IPv6 Internet >> Service" >> * RFC 6105 =96 "IPv6 Router Advertisement Guard" >> * RFC 6106 =96 "IPv6 Router Advertisement Options for DNS >> Configuration", =A77 in particular. >>=20 >> As you are aware, every RFC contains a Security Considerations = section. >> In developing either a implementation or deployment guide, = contributors >> are strongly encouraged to review the RFCs and Internet-Drafts that >> support any underlying function. >>=20 >> In addition, we bring to your attention the following IETF Working >> Groups that are working on security-related work of IPv6: >>=20 >> Working Group Purpose Mailing list address >> Name >>=20 >> 6man IPv6 Maintenance ipv6@ietf.org >> savi Source Address Validation savi@ietf.org >> Improvements >> dhc Dynamic Host Configuration dhcwg@ietf.org >> v6ops IPv6 Operations v6ops@ietf.org >> opsec Operational Security opsec@ietf.org >> Capabilities for an IP >> Network >>=20 >> In addition to the above working groups, the Security Area of the = IETF >> maintains a mailing list for general discussion, saag@ietf.org. We >> encourage and invite open and informal discussion in these or other >> relevant IETF fora on this very important topic. As with all IETF >> working groups, any and all interested parties can choose to directly >> contribute via the mailing lists above. >>=20 >> As in other areas, the Security Area of the IETF invites SG17 to = bring >> any new-found concerns about IETF protocols to our attention so that = as >> and when we revise our documents we can make appropriate amendments = to >> IETF protocols. In particular, as this planned work matures, we would >> welcome hearing about it in more detail, perhaps via an invited >> presentation at a saag meeting or via review of draft documents as = may >> be appropriate. >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From stephen.farrell@cs.tcd.ie Tue Jun 14 00:20:04 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D899611E8111; Tue, 14 Jun 2011 00:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.423 X-Spam-Level: X-Spam-Status: No, score=-105.423 tagged_above=-999 required=5 tests=[AWL=-0.820, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, 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 NFC4dtBetRgx; Tue, 14 Jun 2011 00:20:03 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 39E2011E8070; Tue, 14 Jun 2011 00:20:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 5114715356B; Tue, 14 Jun 2011 08:19:56 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h=date :subject:from:x-mailer:message-id:content-type :content-transfer-encoding:mime-version:in-reply-to:references :received:received:x-virus-scanned; s=cs; t=1308035995; bh=2883g 9CmH7gUGjXVhpis5QtP7w9of6b9492MzLkdFx8=; b=GYUhs7mKtMTfTjB89UNZG IjQnCGr3w5fi3aNWPWmnMSIRIZMMbZpuLBvGaUxsC/p+XQGGWzlxD5wzBilYfUgW GTx9N/O1JQAVcrHOz6jOCMZa3xrECCkIpgj1UxMPkyhn98LS/myOwYMXj5Ot1FEr 5qltKMkd3hkLfxjsB59SaEY7huvTJa1CHd1KLR2zPu8QyTpYT1D2inmDIodxHZ8Z 99I/dM5xcOiMMOENkiW4OjHlmrN0PgRy3htmvq73O3nAU7kfM5sdieQDZOjZGr6v JYYb+qpfVSu9XoyryHhWt2xXXLgjKhCtMnGkQcVxS/uG8RcmbXbyVilKXwgNCNQA A== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id Pjz+6LKmtmjs; Tue, 14 Jun 2011 08:19:55 +0100 (IST) Received: from [10.87.48.6] (unknown [86.42.18.245]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id C321A15356A; Tue, 14 Jun 2011 08:19:54 +0100 (IST) References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> <22C01597-E89D-4200-8251-2F3979ABB0B6@gmail.com> In-Reply-To: <22C01597-E89D-4200-8251-2F3979ABB0B6@gmail.com> Mime-Version: 1.0 (iPhone Mail 8H7) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: X-Mailer: iPhone Mail (8H7) From: Stephen Farrell Subject: Re: [v6ops] [saag] ITU-T SG17 IPv6 security work items liaison Date: Tue, 14 Jun 2011 08:19:52 +0100 To: Bob Hinden Cc: Bob Hinden , "v6ops@ietf.org" , Russ Housley , "saag@ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 07:20:05 -0000 On 14 Jun 2011, at 05:51, Bob Hinden wrote: > Russ, >=20 > On Jun 14, 2011, at 2:57 AM, Russ Housley wrote: >=20 >> Stephen: >>=20 >> Comments below. >>=20 >> Russ >>=20 >>=20 >>> From: IETF Security Area >>> To: Study Group 17, Questions 2 and 3 >>> Title: Work on Security of IPv6 >>>=20 >>> FOR ACTION >>>=20 >>> The IETF thanks Study Group 17 for its liaison LS-206 "Liaison on IPv6 >>> security issues". As the world transitions to IPv6, new opportunities >>> and challenges and challenges arise. SG17's new focus on deployment and= >>=20 >> s/and challenges and challenges/and challenges/ >> s/new// >>=20 >>> implementation considerations reflects this reality. We would like to >>> bring to your attention the following work which we believe may prove a >>> useful basis for both X.ipv6-secguide and X.mgv6: >>>=20 >>> * RFC 4294 =E2=80=93 "IPv6 Node Requirements" (N.B., this work is curre= ntly >>> under revision) >>=20 >> Why not just reference the bis document? >=20 >>=20 >>> * draft-ietf-6man-node-req-bis (work in progress) =E2=80=93 "IPv6 Node >>> Requirements RFC 4294-bis" >=20 >=20 > The draft could also say that the working group has reached consensus and h= as submitted it to the IESG for publication on 25 May 2011. Will do, S >=20 > Bob >=20 >=20 >>> * RFC 4864 =E2=80=93 "Local Network Protection for IPv6" >>> * RFC 6092 =E2=80=93 "Recommended Simple Security Capabilities in Custo= mer >>> Premise Equipment (CPE) for Providing Residential IPv6 Internet >>> Service" >>> * RFC 6105 =E2=80=93 "IPv6 Router Advertisement Guard" >>> * RFC 6106 =E2=80=93 "IPv6 Router Advertisement Options for DNS >>> Configuration", =C2=A77 in particular. >>>=20 >>> As you are aware, every RFC contains a Security Considerations section. >>> In developing either a implementation or deployment guide, contributors >>> are strongly encouraged to review the RFCs and Internet-Drafts that >>> support any underlying function. >>>=20 >>> In addition, we bring to your attention the following IETF Working >>> Groups that are working on security-related work of IPv6: >>>=20 >>> Working Group Purpose Mailing list address >>> Name >>>=20 >>> 6man IPv6 Maintenance ipv6@ietf.org >>> savi Source Address Validation savi@ietf.org >>> Improvements >>> dhc Dynamic Host Configuration dhcwg@ietf.org >>> v6ops IPv6 Operations v6ops@ietf.org >>> opsec Operational Security opsec@ietf.org >>> Capabilities for an IP >>> Network >>>=20 >>> In addition to the above working groups, the Security Area of the IETF >>> maintains a mailing list for general discussion, saag@ietf.org. We >>> encourage and invite open and informal discussion in these or other >>> relevant IETF fora on this very important topic. As with all IETF >>> working groups, any and all interested parties can choose to directly >>> contribute via the mailing lists above. >>>=20 >>> As in other areas, the Security Area of the IETF invites SG17 to bring >>> any new-found concerns about IETF protocols to our attention so that as >>> and when we revise our documents we can make appropriate amendments to >>> IETF protocols. In particular, as this planned work matures, we would >>> welcome hearing about it in more detail, perhaps via an invited >>> presentation at a saag meeting or via review of draft documents as may >>> be appropriate. >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 From tjc@ecs.soton.ac.uk Tue Jun 14 00:25:07 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E61B611E8088; Tue, 14 Jun 2011 00:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 75e3ObBSLDbD; Tue, 14 Jun 2011 00:25:07 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 7494711E8087; Tue, 14 Jun 2011 00:25:06 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p5E7P13m019120; Tue, 14 Jun 2011 08:25:01 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p5E7P13m019120 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1308036301; bh=rBVPClm7597qoSZdBvmzEvZaziE=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=MZY+HJ1oabiVIjGx4hhw/N4mK9/xMoNhjxeuSYSMZCI3+xDWkZDgmkccFvljLhktt n+O+kIH+o2C6ncNGUaTprt5umbpyNDhGt4KJpQe3XeoGLFNbbo/Qk0YcoB/uYn0lmF iHJ/nNYpCpg4IU4cC5naEW0leKYG9DauUol3dNM0= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id n5D8P10521301716oi ret-id none; Tue, 14 Jun 2011 08:25:01 +0100 Received: from [192.168.1.14] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p5E7NbqT021992 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 14 Jun 2011 08:23:37 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) Subject: Re: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers) From: Tim Chown In-Reply-To: <4DF6B804.4040703@gont.com.ar> Date: Tue, 14 Jun 2011 08:23:37 +0100 Content-Transfer-Encoding: 7bit Message-ID: References: <4DF291D0.7080707@gont.com.ar> <4DF69180.6050902@inex.ie> <4DF6B804.4040703@gont.com.ar> To: IPv6 Operations , 6man X-Mailer: Apple Mail (2.1084) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=n5D8P1052130171600; tid=n5D8P10521301716oi; client=relay,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: p5E7P13m019120 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 07:25:08 -0000 On 14 Jun 2011, at 02:23, Fernando Gont wrote: >> Are there plans to introduce dhcpv6-guard? > > This is something that vendors should answer. As long as there are > implementations that may try DHCPv6 even if no RA is received, DHCPv6 > should be implemented/deployed along RA-Guard, or else attackers will > switch to teh DHCPv6 vector, and RA-Guard will be circumvented this way. I am aware of it being on the roadmap for one significant router vendor. But that model is familiar from IPv4. Tim From stephen.farrell@cs.tcd.ie Tue Jun 14 04:07:41 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 971D311E8097; Tue, 14 Jun 2011 04:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.045 X-Spam-Level: X-Spam-Status: No, score=-106.045 tagged_above=-999 required=5 tests=[AWL=0.554, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 7lRRCT9lnv74; Tue, 14 Jun 2011 04:07:40 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id C9C7F11E8071; Tue, 14 Jun 2011 04:07:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id B1308171C03; Tue, 14 Jun 2011 12:07:18 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1308049638; bh=BR372cB96WaTSt J2eDtWqWz7b9GALC6jcCwc47ovgKg=; b=CIliRfxuv9AVgQ458vvKDKCI0SWR49 j1S6c21C/Z3gmv+Hg/SV4ToP93TDUARCbT3aj/TPilMLPES59RW6nJSHojfH0yqp DzTvfZ6aWY5gVHoLcYFfveHBOMPTv45y94UWlMINuh67BIb5go/UHFtWBQRCSmYB m+njLBm/Fp1IyS/1oGLL9MrDuMXYrk2idNFbP4S0m/6WWUi5qUjyA7Pj0EMjAfxG WKt9wkMxsno7B6UuQswtMkKUV9x8ol2Dw9ZDbCVoX8xqYs6hUjaDSK4nBvWaCvPU zh7vIcbki6nCFs4pznmo9AWk4RHM6ypHLJANq5jQm/IkQVZVYQRmwFdQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id bB+PEJkkE4sb; Tue, 14 Jun 2011 12:07:18 +0100 (IST) Received: from [134.226.36.137] (stephen-samy.dsg.cs.tcd.ie [134.226.36.137]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 63DD7171C01; Tue, 14 Jun 2011 12:07:17 +0100 (IST) Message-ID: <4DF740E5.4030309@cs.tcd.ie> Date: Tue, 14 Jun 2011 12:07:17 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Nick Hilliard Subject: Re: [v6ops] [saag] ITU-T SG17 IPv6 security work items liaison References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> <4DF73138.6010009@inex.ie> In-Reply-To: <4DF73138.6010009@inex.ie> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org, ipv6@ietf.org, "saag@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 11:07:41 -0000 Thanks Nick, I'll add that unless someone tells me its a bad plan. Its a fairly fresh I-D, but I guess it looks pretty relevant all right. S. On 14/06/11 11:00, Nick Hilliard wrote: > On 14/06/2011 00:09, Stephen Farrell wrote: >> * RFC 6105 – "IPv6 Router Advertisement Guard" >> * RFC 6106 – "IPv6 Router Advertisement Options for DNS >> Configuration", §7 in particular. > > maybe mention draft-gont-v6ops-ra-guard-evasion? It's not a strategic > focused document, but gives specific advice on a specific issue which is > relevant to ipv6 lan deployments. > > Nick > From Ted.Lemon@nominum.com Tue Jun 14 07:03:53 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485439E8005; Tue, 14 Jun 2011 07:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 ygEgEoEEbwUG; Tue, 14 Jun 2011 07:03:52 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5429E8004; Tue, 14 Jun 2011 07:03:52 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTfdqRwbnD7ctk63xaJZ4HxIMzpqyOkFJ@postini.com; Tue, 14 Jun 2011 07:03:52 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 5E26DF8063; Tue, 14 Jun 2011 07:03:51 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 506B419005D; Tue, 14 Jun 2011 07:03:51 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([169.254.1.65]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0289.001; Tue, 14 Jun 2011 07:03:51 -0700 From: Ted Lemon To: Nick Hilliard Subject: Re: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers) Thread-Topic: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers) Thread-Index: AQHMKhrK4nfvsQF/6k2M3T/2n95cnZS8hGgAgAC48QD//6Y4Zw== Date: Tue, 14 Jun 2011 14:03:50 +0000 Message-ID: <7D140A8C-6EB2-4EC8-8852-8BEBF9C311F9@nominum.com> References: <4DF291D0.7080707@gont.com.ar> <4DF69180.6050902@inex.ie> <4DF6B804.4040703@gont.com.ar>,<4DF75328.6060109@inex.ie> In-Reply-To: <4DF75328.6060109@inex.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Operations , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 14:03:53 -0000 On Jun 14, 2011, at 5:26 AM, "Nick Hilliard" wrote: > probably vendors aren't going to do much about dhcp6-guard unless there i= s a standard to work towards. I'd offer to help out, but my dhcpv6-fu is Can you come to the dhcwg meeting and talk with us about the problem?= From suresh.krishnan@ericsson.com Tue Jun 14 08:34:24 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2F311E813E; Tue, 14 Jun 2011 08:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.21 X-Spam-Level: X-Spam-Status: No, score=-106.21 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, 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 egDgaaoeXu04; Tue, 14 Jun 2011 08:34:23 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 82CAB11E80B0; Tue, 14 Jun 2011 08:34:21 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p5EFYDKn017018 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Jun 2011 10:34:14 -0500 Received: from [142.133.10.107] (147.117.20.214) by eusaamw0711.eamcs.ericsson.se (147.117.20.179) with Microsoft SMTP Server id 8.3.137.0; Tue, 14 Jun 2011 11:34:13 -0400 Message-ID: <4DF77E98.8030300@ericsson.com> Date: Tue, 14 Jun 2011 11:30:32 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Stephen Farrell Subject: Re: [saag] ITU-T SG17 IPv6 security work items liaison References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> In-Reply-To: <4DF69899.2050606@cs.tcd.ie> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" , "ipv6@ietf.org" , "saag@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 15:34:25 -0000 Hi Stephen, Please consider adding the following RFCs to the list. RFC3756 IPv6 Neighbor Discovery (ND) Trust Models and Threats RFC4890 Recommendations for Filtering ICMPv6 Messages in Firewalls RFC4942 IPv6 Transition/Co-existence Security Considerations RFC5157 IPv6 Implications for Network Scanning Thanks Suresh On 11-06-13 07:09 PM, Stephen Farrell wrote: > All, > > Thanks for the feedback on this liaison. Eliot (mostly) > and I (a bit) have tried to capture all that in the > text below. Please send any comments on that (with > specific alternative text) in the next week and then > we'll shoot it on to them. > > RFC 3514 does have some words about IPv6 - should I > add that as a reference? :-) > > Thanks, > Stephen. > > From: IETF Security Area > To: Study Group 17, Questions 2 and 3 > Title: Work on Security of IPv6 > > FOR ACTION > > The IETF thanks Study Group 17 for its liaison LS-206 "Liaison on IPv6 > security issues". As the world transitions to IPv6, new opportunities > and challenges and challenges arise. SG17's new focus on deployment and > implementation considerations reflects this reality. We would like to > bring to your attention the following work which we believe may prove a > useful basis for both X.ipv6-secguide and X.mgv6: > > * RFC 4294 – "IPv6 Node Requirements" (N.B., this work is currently > under revision) > * draft-ietf-6man-node-req-bis (work in progress) – "IPv6 Node > Requirements RFC 4294-bis" > * RFC 4864 – "Local Network Protection for IPv6" > * RFC 6092 – "Recommended Simple Security Capabilities in Customer > Premise Equipment (CPE) for Providing Residential IPv6 Internet > Service" > * RFC 6105 – "IPv6 Router Advertisement Guard" > * RFC 6106 – "IPv6 Router Advertisement Options for DNS > Configuration", §7 in particular. > > As you are aware, every RFC contains a Security Considerations section. > In developing either a implementation or deployment guide, contributors > are strongly encouraged to review the RFCs and Internet-Drafts that > support any underlying function. > > In addition, we bring to your attention the following IETF Working > Groups that are working on security-related work of IPv6: > > Working Group Purpose Mailing list address > Name > > 6man IPv6 Maintenance ipv6@ietf.org > savi Source Address Validation savi@ietf.org > Improvements > dhc Dynamic Host Configuration dhcwg@ietf.org > v6ops IPv6 Operations v6ops@ietf.org > opsec Operational Security opsec@ietf.org > Capabilities for an IP > Network > > In addition to the above working groups, the Security Area of the IETF > maintains a mailing list for general discussion, saag@ietf.org. We > encourage and invite open and informal discussion in these or other > relevant IETF fora on this very important topic. As with all IETF > working groups, any and all interested parties can choose to directly > contribute via the mailing lists above. > > As in other areas, the Security Area of the IETF invites SG17 to bring > any new-found concerns about IETF protocols to our attention so that as > and when we revise our documents we can make appropriate amendments to > IETF protocols. In particular, as this planned work matures, we would > welcome hearing about it in more detail, perhaps via an invited > presentation at a saag meeting or via review of draft documents as may > be appropriate. > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From stephen.farrell@cs.tcd.ie Tue Jun 14 17:32:34 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8B71F0C5C; Tue, 14 Jun 2011 17:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.125 X-Spam-Level: X-Spam-Status: No, score=-106.125 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, 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 7HrSUHMbfnGN; Tue, 14 Jun 2011 17:32:33 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8021F0C52; Tue, 14 Jun 2011 17:32:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 57F1615356D; Wed, 15 Jun 2011 01:32:25 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-type:in-reply-to:references:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1308097944; bh=hm1ypKE3WAatZ8Py/YHfyYJh V7QSXt//EGcxhiHf36M=; b=pQbq8nUS8l9leztQT5v1eIfT+jMfMxr3ki6J5zeN ppamvXPtwDbwtONnidLBHABaC9ukuOQDlkLoZMqGvpLk3tn2um1kBe3ziYk3zI4n jXz0xlsx38N/Ppw7Qq9Xmfo9IamFeC900s9GMWa3hM+VAOh6fIJaotnu2tB60sPc xW0o/lv9iiTBx7jN09yfrSaCwiKQP7S/3bHiGbrYYcYD2aqrO1X6MeO/KznI9QyP wOiz0ym5rQzT4rlJ0hXxXoPtuGx7lQbfK73TAELgSRU989MUHG9DEofGcj5zIrp3 p+Hm3JkpcfkTDtMCD79tNUR77CW5gIAxoYAbhCWTCiPr+Q== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id st0l0XVxzUVQ; Wed, 15 Jun 2011 01:32:24 +0100 (IST) Received: from [10.87.48.10] (unknown [86.46.27.52]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id D98F415356C; Wed, 15 Jun 2011 01:32:22 +0100 (IST) Message-ID: <4DF7FD96.9010700@cs.tcd.ie> Date: Wed, 15 Jun 2011 01:32:22 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Joe Touch Subject: Re: [saag] [v6ops] ITU-T SG17 IPv6 security work items liaison References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> <4DF73138.6010009@inex.ie> <4DF740E5.4030309@cs.tcd.ie> <4DF7FA0D.6040201@isi.edu> In-Reply-To: <4DF7FA0D.6040201@isi.edu> X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------020404050002030007000507" Cc: v6ops@ietf.org, Nick Hilliard , ipv6@ietf.org, "saag@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 00:32:34 -0000 This is a multi-part message in MIME format. --------------020404050002030007000507 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Joe, Fair point about the draft-gont document. I've taken it out for now. Which was the 6man I-D you meant? There are now two referenced thanks to recent comments and both are draft-ietf-6man so have presumably been adopted by the WG. My current version is attached following today's edits in case that helps. I've still not included rfc 3514 but the more iterations this takes, the more I'm getting more tempted:-) Thanks, S. On 15/06/11 01:17, Joe Touch wrote: > Hi, all, > > It'd be useful to wait until these docs (this v6ops one and the 6man one > it refers) are adopted by the relevant WGs before noting them in > recommendations to external parties, IMO. > > Some of the recommendations in these documents are akin to "if I didn't > expect it, it's an attack", which I feel makes our protocols too brittle > unless we are in a situation of known security compromise via other > indicators. The latter doc (6man) also silently discards legitimate > packets (complicating debugging), and ends up deprecating the entire > extension header feature of IPv6 for all IPv6 signaling protocols - > which seems like a bad idea overall. > > I'd prefer to see the relevant WGs endorse these as useful ways forward > before adding them to this list. > > Joe > > On 6/14/2011 4:07 AM, Stephen Farrell wrote: >> >> Thanks Nick, >> >> I'll add that unless someone tells me its a bad plan. >> Its a fairly fresh I-D, but I guess it looks pretty >> relevant all right. >> >> S. >> >> On 14/06/11 11:00, Nick Hilliard wrote: >>> On 14/06/2011 00:09, Stephen Farrell wrote: >>>> * RFC 6105 – "IPv6 Router Advertisement Guard" >>>> * RFC 6106 – "IPv6 Router Advertisement Options for DNS >>>> Configuration", §7 in particular. >>> >>> maybe mention draft-gont-v6ops-ra-guard-evasion? It's not a strategic >>> focused document, but gives specific advice on a specific issue which is >>> relevant to ipv6 lan deployments. >>> >>> Nick >>> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag > --------------020404050002030007000507 Content-Type: text/plain; name="ituipv6lia.txt" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="ituipv6lia.txt" From: IETF Security Area To: Study Group 17, Questions 2 and 3 Title: Work on Security of IPv6 FOR ACTION The IETF thanks Study Group 17 for its liaison LS-206 "Liaison on IPv6 security issues". As the world transitions to IPv6, new opportunities and challenges arise. SG17's focus on deployment and implementation considerations reflects this reality. We would like to bring to your attention the following work which we believe may prove a useful basis for both X.ipv6-secguide and X.mgv6: * RFC 4294 – "IPv6 Node Requirements" (N.B., this work is currently under revision as draft-ietf-6man-node-req-bis, submitted to the IESG for approval on 2011-05-25) * draft-ietf-6man-node-req-bis (work in progress) – "IPv6 Node Requirements RFC 4294-bis" * RFC 4864 – "Local Network Protection for IPv6" * RFC 4942 - "IPv6 Transition/Coexistence Security Considerations" * RFC 6092 – "Recommended Simple Security Capabilities in Customer Premise Equipment (CPE) for Providing Residential IPv6 Internet Service" * RFC 6105 – "IPv6 Router Advertisement Guard" * RFC 6106 – "IPv6 Router Advertisement Options for DNS Configuration", §7 in particular. As you are aware, every RFC contains a Security Considerations section. In developing either an implementation or deployment guide, contributors are strongly encouraged to review the RFCs and Internet-Drafts that support any underlying function. In addition, we bring to your attention the following IETF Working Groups that are working on IPv6 security-related work: Working Group Purpose Mailing list address Name 6man IPv6 Maintenance ipv6@ietf.org savi Source Address Validation savi@ietf.org Improvements dhc Dynamic Host Configuration dhcwg@ietf.org v6ops IPv6 Operations v6ops@ietf.org opsec Operational Security opsec@ietf.org Capabilities for an IP Network In addition to the above working groups, the Security Area of the IETF maintains a mailing list for general discussion, saag@ietf.org. We encourage and invite open and informal discussion in these or other relevant IETF fora on this very important topic. As with all IETF working groups, any and all interested parties can choose to directly contribute via the mailing lists above. As in other areas, the Security Area of the IETF invites SG17 to bring any new-found concerns about IETF protocols to our attention so that as and when we revise our documents we can make appropriate amendments to IETF protocols. In particular, as this planned work matures, we would welcome hearing about it in more detail, perhaps via an invited presentation at a saag meeting or via review of draft documents as may be appropriate. --------------020404050002030007000507-- From fred@cisco.com Tue Jun 14 17:42:37 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54D821F8542; Tue, 14 Jun 2011 17:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.754 X-Spam-Level: X-Spam-Status: No, score=-110.754 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 BjYh4GmzLyLD; Tue, 14 Jun 2011 17:42:36 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6C97921F8541; Tue, 14 Jun 2011 17:42:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=219; q=dns/txt; s=iport; t=1308098556; x=1309308156; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=Z/RESjri8B8J6elnS7oB+jzBCx5V7NSIkXFMNCI4P8Q=; b=Gain37CwW6NXckQ3uB15n1eweBu2kDijkjBnqYfzLO/+RpAJdJyFfEic qH/yu/qyf6px5CRtxxJXUDoAFc5OrWahi0Jvfpm/FIO9VOP1QlWojStHY b+03EYfEbizNp6Ktv6dTKUpWaiOXRMT/YbiZu3UPGb7jIuNhk7JnEy0oo k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMj/902rRDoI/2dsb2JhbABSplF3iHOhLp44hiYEhxWKNIRZizU X-IronPort-AV: E=Sophos;i="4.65,368,1304294400"; d="scan'208";a="465551729" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 15 Jun 2011 00:42:34 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5F0gTVE030497; Wed, 15 Jun 2011 00:42:34 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Tue, 14 Jun 2011 17:42:34 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Tue, 14 Jun 2011 17:42:34 -0700 Subject: Re: [saag] ITU-T SG17 IPv6 security work items liaison Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <4DF77E98.8030300@ericsson.com> Date: Tue, 14 Jun 2011 17:42:18 -0700 Message-Id: References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> <4DF77E98.8030300@ericsson.com> To: Suresh Krishnan X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" , "ipv6@ietf.org" , "saag@ietf.org" , Stephen Farrell X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 00:42:38 -0000 On Jun 14, 2011, at 8:30 AM, Suresh Krishnan wrote: > RFC5157 IPv6 Implications for Network Scanning Personally, I think that RFC has been overtaken by events. Network scans = have been reported in the wild.= From stephen.farrell@cs.tcd.ie Tue Jun 14 18:02:11 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5821F0C65; Tue, 14 Jun 2011 18:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.903 X-Spam-Level: X-Spam-Status: No, score=-105.903 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4, 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 5EtotTQsjj7q; Tue, 14 Jun 2011 18:02:10 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 91D1B1F0C61; Tue, 14 Jun 2011 18:02:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 875E015356D; Wed, 15 Jun 2011 02:02:03 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1308099723; bh=Mj2C9ZnZ69N5v0 UR7zepE5rS2tIrBtpD/aIBFkclXrI=; b=1P9h3C9rJYdTOHdmCCtUtc43CJlsrc +wtzP4tEkZbqA+rQfYpu1s5VYtcK/AXOvyHC8wkSYiCrDtM1MrDiHlB9TNJSjkok 9L+CN8TiBIVjvtP5fz6jEQy8DCHm5oe2KvHOe3cwXDWFrOv6lDQLq/CVCrZW57ZY LD/GQoJS16qQ4FPna4she1X1SIUtUBNdFiBtGyRqpywKazPpWDNXHAkwiUdzp5bO O7aLIDfel+UdfAvtYVtZOuMf6kr2Aq8ztfkol2jF/F/blHPVLoksZ4STQmJCGIHA 4jcMTaTilXO86ksmo3rR1EzNr7ftZCzS8+JmBmCz+/Zk6AU7L/UUBLDA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id rJIjJSlGLEuV; Wed, 15 Jun 2011 02:02:03 +0100 (IST) Received: from [10.87.48.10] (unknown [86.46.27.52]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 5361B15356B; Wed, 15 Jun 2011 02:02:00 +0100 (IST) Message-ID: <4DF8047D.9000209@cs.tcd.ie> Date: Wed, 15 Jun 2011 02:01:49 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Fred Baker Subject: Re: [saag] ITU-T SG17 IPv6 security work items liaison References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> <4DF77E98.8030300@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , "ipv6@ietf.org" , Suresh Krishnan , "saag@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 01:02:11 -0000 All, On 15/06/11 01:42, Fred Baker wrote: > > On Jun 14, 2011, at 8:30 AM, Suresh Krishnan wrote: > >> RFC5157 IPv6 Implications for Network Scanning > > Personally, I think that RFC has been overtaken by events. Network scans have been reported in the wild. Ok, that's not currently included and given its not clear (to me at least) I'm gonna leave it out. I think we've accumulated enough references at this point - its never going to be a complete list and even if it attempted to be such, it'd probably be so long as to be useless. So I'm no longer taking additional reference recommendations unless a whole bunch of people say the same thing and otherwise I'm gonna stick with the current list as sent in a reply to Joe Touch a few minutes ago. If there're text edits that are *needed* then I'll take those for a couple of days more but I reckon we've iterated enough here. Thanks for all the help with this, I think we're done now basically. Cheers, S. From tjc@ecs.soton.ac.uk Wed Jun 15 02:45:37 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B00F121F8489; Wed, 15 Jun 2011 02:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[AWL=2.499, BAYES_00=-2.599, 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 OTP3JbvN7e+s; Wed, 15 Jun 2011 02:45:36 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1BE21F84DE; Wed, 15 Jun 2011 02:45:34 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p5F9iNF5030547; Wed, 15 Jun 2011 10:44:23 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p5F9iNF5030547 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1308131063; bh=ZmTv3KiCfclrWyN5WvZkuPEk1ts=; h=References:In-Reply-To:Mime-Version:Cc:From:Subject:Date:To; b=Lr9LLzGKMi7Pl+TSo9GKXoMS92/zjfH2RffRFdMqh1pw048cdM8SAyThjI2irA6wZ tAV1FKD9MAUUvLWX/KVzSKNkVb4gTTCVGA07jUznprfdoM2dUow0GRAJTJlzbCM8iM NY0Tl/8Zljq877cIv9w45M07I40dRkp/3eBL9Fps= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id n5EAiN0521310575Og ret-id none; Wed, 15 Jun 2011 10:44:23 +0100 Received: from cerf.ecs.soton.ac.uk (cerf.ecs.soton.ac.uk [152.78.69.39]) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p5F9iE7U028888 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 15 Jun 2011 10:44:15 +0100 References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> <4DF77E98.8030300@ericsson.com> <86015668-D0FC-4D85-B078-74E6AB096D56@ecs.soton.ac.uk> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-17--888627372 Message-ID: From: Tim Chown Subject: Re: [v6ops] [saag] ITU-T SG17 IPv6 security work items liaison Date: Wed, 15 Jun 2011 10:44:14 +0100 To: Fred Baker X-Mailer: Apple Mail (2.1084) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=n5EAiN052131057500; tid=n5EAiN0521310575Og; client=relay,ipv6; mail=; rcpt=; nrcpt=6:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: p5F9iNF5030547 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: "v6ops@ietf.org" , Stephen Farrell , "ipv6@ietf.org" , Suresh Krishnan , "saag@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 09:45:37 -0000 --Apple-Mail-17--888627372 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 15 Jun 2011, at 01:42, Fred Baker wrote: >=20 > On Jun 14, 2011, at 8:30 AM, Suresh Krishnan wrote: >=20 >> RFC5157 IPv6 Implications for Network Scanning >=20 > Personally, I think that RFC has been overtaken by events. Network = scans have been reported in the wild. I just re-read the abstract and conclusion to 5157, and I think = everything stated there still applies. The bit where we stated that we'd not seen traditional network scanning = at our own site (to ::1, ::2, etc) is the part that has = changed - we could now say there is some evidence of such activity. But = that doesn't invalidate the advice to - for example - not have your = DHCPv6 pools start with ::1, or the observation that attackers = will look at other ways to glean addresses, with some discussion of = those. The interesting newly discussed issue since 5157 was published is the = possible impact on ND caches of scanning dark space, should such sweeps = reach the target subnet/link. WRT the ITU-T doc, I agree it's probably not needed. Tim --Apple-Mail-17--888627372 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On = Jun 14, 2011, at 8:30 AM, Suresh Krishnan wrote:

RFC5157 IPv6 Implications for Network = Scanning

Personally, I think that RFC has been = overtaken by events. Network scans have been reported in the wild.

I = just re-read the abstract and conclusion to 5157, and I think everything = stated there still applies.

The bit where we = stated that we'd not seen traditional network scanning at our own site = (to <prefix>::1, <prefix>::2, etc) is the part that has = changed - we could now say there is some evidence of such activity. =  But that doesn't invalidate the advice to - for example - not have = your DHCPv6 pools start with <prefix>::1, or the observation that = attackers will look at other ways to glean addresses, with some = discussion of those.

The interesting newly = discussed issue since 5157 was published is the possible impact on ND = caches of scanning dark space, should such sweeps reach the target = subnet/link.

WRT the ITU-T doc, I agree it's = probably not = needed.

Tim

= --Apple-Mail-17--888627372-- From lear@cisco.com Wed Jun 15 08:10:49 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4811011E80DC; Wed, 15 Jun 2011 08:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 08MdA-6Q18xq; Wed, 15 Jun 2011 08:10:48 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 07D2811E8117; Wed, 15 Jun 2011 08:10:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=646; q=dns/txt; s=iport; t=1308150648; x=1309360248; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=2c/Ay7D0sEraqeWcowjTYMYOVsjeqe/n+VpClTuipdo=; b=h0EGVtRlNS90wnM2wft3DcfmBVo0VHuV3j0ahp1mwEpuMhj8Cxcpzf9f Wh8ZMW10qbtGz8ww84xg2nzY6ftcQe1Y04ukzRiJXftPNMVjHgh/V0kW9 fVQbIkjbBQHSTHNYQ4smdTXM4V+okxAyUaeDo3T3RJ3STd15XrqzNqxms Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOPK+E2Q/khM/2dsb2JhbABSEIQ5ogh3qTuNK5EQgSuDcYEKBJFOjzs3 X-IronPort-AV: E=Sophos;i="4.65,370,1304294400"; d="scan'208";a="94113869" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 15 Jun 2011 15:10:42 +0000 Received: from dhcp-10-61-101-58.cisco.com (dhcp-10-61-101-58.cisco.com [10.61.101.58]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5FFAfst016460; Wed, 15 Jun 2011 15:10:42 GMT Message-ID: <4DF8CB71.3060806@cisco.com> Date: Wed, 15 Jun 2011 17:10:41 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Joe Touch Subject: Re: [saag] [v6ops] ITU-T SG17 IPv6 security work items liaison References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> <4DF73138.6010009@inex.ie> <4DF740E5.4030309@cs.tcd.ie> <4DF7FA0D.6040201@isi.edu> In-Reply-To: <4DF7FA0D.6040201@isi.edu> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, Nick Hilliard , ipv6@ietf.org, "saag@ietf.org" , Stephen Farrell X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 15:10:49 -0000 Joe, A suggestion just on this one point: > I'd prefer to see the relevant WGs endorse these as useful ways > forward before adding them to this list. > It is good for the IETF to provide the ITU's membership an opportunity to comment either formally via the liaison process or informally as individuals before work is finalized, just as we would like that opportunity. So long as we are clear on the status of the work, and the work can reasonably be construed as relevant, it's okay to mention it. Now, how should one apply my advice (which is what this is) to your suggestion? Regards, Eliot From alexandru.petrescu@gmail.com Thu Jun 16 07:12:24 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCF8411E816D for ; Thu, 16 Jun 2011 07:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 Ysdc1mO6KoSJ for ; Thu, 16 Jun 2011 07:12:24 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.144]) by ietfa.amsl.com (Postfix) with ESMTP id 7776211E80FD for ; Thu, 16 Jun 2011 07:12:23 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p5GECLKq015471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 16 Jun 2011 16:12:21 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p5GECKRE006728 for ; Thu, 16 Jun 2011 16:12:21 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [132.166.133.178] (is010173.intra.cea.fr [132.166.133.178]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p5GECKNk004419 for ; Thu, 16 Jun 2011 16:12:20 +0200 Message-ID: <4DFA0F44.6030802@gmail.com> Date: Thu, 16 Jun 2011 16:12:20 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: AD review of draft-ietf-6man-rpl-routing-header References: <4DF29EAA.1060103@piuha.net> In-Reply-To: <4DF29EAA.1060103@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 14:12:25 -0000 IPv6 6MAN WG, I take advantage of this AD message to post comments about this draft. Le 11/06/2011 00:46, Jari Arkko a écrit : [...] >> In very specific cases, IPv6-in-IPv6 tunneling may be undesirable >> due to the added cost and complexity required to process and carry >> a datagram with two IPv6 headers. [I-D.hui-6man-rpl-headers >> ] >> >> >> describes how to avoid using IPv6-in-IPv6 tunneling in such >> specific cases and the risks involved. > > This sounds like a recommendation to do something in a draft that has > not been through the working group and approved as the something that > is a sound practice. Unless the reference is normative, I think it is > inappropriate to refer to an Internet draft in this manner. > > What I would recommend is to (1) change the "... SHOULD use > IPv6-in-IPv6 tunneling ..." statement to a MUST in this draft, I can say that I agree with the direction of using IPv6-in-IPv6 tunnelling in this context, and avoid the use of RH. But even then, I think there still some things unclear about the use of IPv6-in-IPv6 in the draft. (for example it makes no sense to encapsulate when both S and D are under same BR, figure on Page 6, despite text saying "datagrams travel from S to D through BR1. [...] BR1 encapsulates received datagrams unmodified using IPv6-in-IPv6 and [...]"). Second, intuitively, using IP encapsulation on BR in order to connect BR and the RPL network to the Internet dangerously approaches to a number of existing methods of achieving same: Mobile IP, or a pure tunnel broker, etc. These methods should be reused, otherwise I need to understand why designing new methods. Third, there is a very strong lack of architectural perspective here about BRs, tunnels and the rest of Internet nodes. There is no suggestion about who are the RPL nodes (below BR) talking to? If we assume that the BR does IP-in-IP encapsulation, then is it still possible that nodes below BR still can talk to any other node in the Internet? Do we need to modify these nodes to support IP-in-IP encapsulation when talking to nodes below BR? > (2) remove the above text, and (3) make the corresponding changes to > Section 5. Then we can take hui-6man-rpl-headers through the working > group and provide a second, more light-weight approach that extends > what we have RFC-to-be-draft-ietf-6man-rpl-routing-header. This makes sense to me. I support this approach as long as it implies more clarification on the IP-in-IP encapsulation as well. > (FWIW, I think the problem begins when one adds the first byte to a > packet somewhere along the route. It does not not matter so much how > many bytes one adds, just the SRH or also the IP header. Most of the > complications on MTUs and so one start at that point. In any case, > SRHs may not be trivially small either. Assuming 64-bit prefix > compression an SRH for 4 hops would be 40 bytes.) I agree with a thing above: modifying packets on-route has strong consequences on some things such as MTU and, additionally, on the assumed security mechanism be it IPsec. IPsec is not specified to work with any other routing header than what exists already. draft says: > Because this document specifies that SRH is only for use within a RPL > domain, such attacks cannot be mounted from outside the RPL domain. Ok, how about attacks mounted from _inside_ the RPL domain? Do you think they can't exist? Thus, do you agree that any this draft's RH is fully insecure? >> If such addresses appear more than once and are separated by at >> least one address not assigned to that router, the router MUST drop >> the packet and SHOULD send an ICMP Parameter Problem, Code 0, to >> the Source Address. > ... > >> else if 2 or more entries in Address[1..n] are assigned to local >> interface and are separated by at least one address not assigned to >> local interface { discard the packet } > > The text and the code appear to disagree about whether to send an > ICMP Parameter Problem message. Please align. I assume that an ICMP > message is needed. > >> Because this document specifies that SRH is only for use within a >> RPL domain, such attacks cannot be mounted from outside the RPL >> domain. As described in Section 5 >> , >> >> >> RPL Border Routers MUST drop datagrams entering or exiting the RPL >> domain that contain a SRH in the IPv6 Extension headers. > > This is good, and I think the security considerations are > sufficient. No, I don't think so (sorry). A new RH type is not understood by existing IPsec, hence unprotected. Besides, the Security Section seems to assume there can be no attack from within the RPL network to another node within that same network. I think this perspective is not good. > However, I would be happier if the draft also recommended that by > default, non-RPL routers and firewalls should drop packets with SRH. I could agree to this but... hmmm, it is so disapointing when packets can't travel from everywhere to everywhere else because being dropped by an entry in a table-driven non-protocol filter. > This would help ensure that SRH does not accidentally enter any > network and expose some vulnerability. The practical effect that I'm > looking for is, for instance, not having my Linux kernel process SRH > unless I've configured it to use RPL. Makes sense to me. Alex > > Editorial: ====== > >> In the above scenario, datagrams traveling from source, S, to >> destination, D, have the following packet structure: >> >> >> +------+------+------+--------//-+ | IPv6 | IPv6 | IPv6 | Packet | >> | Src | Dst | SRH | Payload | +------+------+------+--------//-+ > > This figure is not as clear as it could be. Are the src and dst field > referring to the IPv6 header fields? Would this picture be better if > you showed the IPv6 header explicitly? Please clarify. > > >> CmprE 4-bit unsigned integer. Number of prefix octets from the >> segment that are elided. For example, a SRH carrying a full IPv6 >> address in Addresses[n] sets CmprE to 0. > > I understood the definition CmprI, but I do not understand this, at > least not at the point of the above text. What is "the segment" that > you are referring to above? SRH carries multiple segments. Please > clarify. > > Little further down it becomes clear that CmprE refers to the > compression of the last segment. Please make this clear already in > the above text. > > Comments relating to feedback from others: > ============================ > > The ADs have received a question from Joseph Reddy, who was asking if > the set of addresses in the SRH should also include the source > address of the node inserting the SRH. His justification for this was > the need to be able to send an ICMP error back to this node. Do we > have an answer? > > In April, Thomas Narten made some comments on the list and I didn't > think that the discussion finished with any conclusion. Are his > concerns (e.g., from his e-mail on April 29th) valid or not valid? I > would like the working group to conclude this issue one way or the > other. I refer to his comments regarding the feasibility of the loop > check in particular. His e-mail is at > http://www.ietf.org/mail-archive/web/ipv6/current/msg13887.html FWIW > I agree with Thomas' editorial comment on Section 2 clarity. That > should be easy to fix. > > Jari > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From jeanmichel.combes@gmail.com Thu Jun 16 10:13:32 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8AE611E8190; Thu, 16 Jun 2011 10:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.12 X-Spam-Level: X-Spam-Status: No, score=-103.12 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, 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 MOZy-VvtwQba; Thu, 16 Jun 2011 10:13:32 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id DCBC311E81EB; Thu, 16 Jun 2011 10:13:31 -0700 (PDT) Received: by ywp31 with SMTP id 31so1246731ywp.31 for ; Thu, 16 Jun 2011 10:13:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DCbxoJLeVhmeEYEMgTJMQVTJDsOlqNdJNkG0OLfWjmw=; b=L4Eu4TCWwS+OBR06nwLAGDHFPYfY8gebWdGnlkuJLnadBuzraFP5rPvQB1RpdO/53X CBrnZgVlXMJLLFoM+nW8DkFkiBY2rVF47BbMseP9Q6hbK9rdIfxszce0PYaOkLOAt8sj oYEGaDmLZH0sHkWR5RgLpjRYpaMMgAS+TVfmE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rU41GUtbaHAwgtbGAa/1iVSG5oNsEidJM4YL2Adwavaj6jOXE+HIcUREtu7dH8vu4y JCkaQF4QUH/cS7Zm/maZOWmGDiONUAFfsUGKYpGfDyhUbBsEsoj8Mf8Rhr+Z7Ao4CgFC u6PY+tdmXiUq+KNyktIIUWFp7r9DNNHspw0Cs= MIME-Version: 1.0 Received: by 10.236.44.39 with SMTP id m27mr1714210yhb.92.1308244410965; Thu, 16 Jun 2011 10:13:30 -0700 (PDT) Received: by 10.147.83.20 with HTTP; Thu, 16 Jun 2011 10:13:30 -0700 (PDT) In-Reply-To: <4DF291D0.7080707@gont.com.ar> References: <4DF291D0.7080707@gont.com.ar> Date: Thu, 16 Jun 2011 19:13:30 +0200 Message-ID: Subject: Re: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers) From: Jean-Michel Combes To: Fernando Gont Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Operations , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 17:13:32 -0000 Hi, I've read quickly these two drafts. Here are some comments/questions: o draft-gont-v6ops-ra-guard-evasion IMHO, this draft should update RFC 6105 (If so, RFC6105 reference should move from Informative References section to the Normative References one). Just a comment about your example for the fragmentation case with 2 Destination extensions: from RFC2460 (section 4.1), this only occurs when there is also a Routing Header extension, so I have to add a RH in your example (better chance to get a fragmentation :)) o draft-gont-6man-nd-extension-headers IMHO, this is not a good idea to forbid the use of IPv6 extension with NDP messages, especially when the reason is partially based on implementation issues (i.e. the implementation is not able to process an IPv6 packet): today, there is no real use of Extension header with NDP but, tomorrow, if we need such an use for a solution, what will happen? Regarding the fragmentation, is it not possible for the RA-Guard device to reassemble the fragments and so to be able to check whether this a RA message or not? Thanks in advance for your reply. Best regards. JMC. 2011/6/10 Fernando Gont : > Hi, > > Some folks have expressed (both on-list and off-list) that they would > prefer a less agressive solution for the RA-Guard evasion vulnerability. > So I'd like to hear comments about the possible alternatives.. > > The current I-Ds (draft-gont-6man-nd-extension-headers and > draft-gont-v6ops-ra-guard-evasion) basically take this approach: > > * Prohibit use of extension headers in ND messages. A host > implementation must not produce these packets, and must discard them if > it receives them > * This results in a RA-Guard implementation that is as simple as > possible (it only has to look at the header following the fixed IPv6 > header). > > > A more relaxed approach would be as follows: > * Extension headers are allowed with ND messages. > * If the packet is fragmented, the upper-layer header (ICMPv6 in this > case) must be present in the first fragment (i.e., hosts must not > generate packets that violate this requirement, and must discard them if > they receive them). > * Possibly have the RA-Guard box enforce a limit on the maximum number > of extension headers that it will process (e.g., if after jumping to > the, say 10th header the upper-layer header is not found, drop the packet) > * This approach is less aggressive than the one proposed in the > aforementioned I-Ds (i.e., more flexibility), but of course would also > mean that the RA-Guard implementation would need to follow the header > chain, thus leading to increased complexity, and possible performance > issues. > > Any comments/thoughts will be very much appreciated. > > Thanks! > > Best regards, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From jeanmichel.combes@gmail.com Thu Jun 16 10:16:16 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB7511E823D; Thu, 16 Jun 2011 10:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.402 X-Spam-Level: X-Spam-Status: No, score=-103.402 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 iKSpJH6FeqlW; Thu, 16 Jun 2011 10:16:14 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1CF11E8232; Thu, 16 Jun 2011 10:16:06 -0700 (PDT) Received: by gxk19 with SMTP id 19so1247670gxk.31 for ; Thu, 16 Jun 2011 10:16:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=k9ND3wuRCnGHY9SssvANQ9nmt5BKmHeQ1ZoMGE2u/UE=; b=DV1sHVYBaDVveKUOBzm9G+ykwGjkEi92uc6Lh9mmKjfeA7hN7mR01tqPb+82MDkRux 4zFWfG3g3s0qV3AS+3oBMJjtyzp+O+n6pxAvllxh3/I3Twt035ZSFRwN14adur2GOL3n 8sHpnVLGdPBqwR4ZcURsaHTAH7bBRkZ8eczu0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=T6WkKiPRoXMXsEzPxk2SIrsLGII6rRxL1S/SueLh5pMR2fJwgn9TzimitlImIoL7zo PgtgC3CbJz8CESkIOx86lSi3Y59rjcdy2McvU9hDQcAYMfCK6Hzg3LKuDcKZZFc8yR0a vYlOA4JKhu4yQsSr1cf7pD/DemcnQSO8BxxOg= MIME-Version: 1.0 Received: by 10.151.92.2 with SMTP id u2mr1423711ybl.209.1308244563225; Thu, 16 Jun 2011 10:16:03 -0700 (PDT) Received: by 10.147.83.20 with HTTP; Thu, 16 Jun 2011 10:16:03 -0700 (PDT) In-Reply-To: References: <4DF291D0.7080707@gont.com.ar> <4DF69180.6050902@inex.ie> <701DCBC2-E1B6-420A-B258-504589335A20@nominum.com> Date: Thu, 16 Jun 2011 19:16:03 +0200 Message-ID: Subject: Re: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers) From: Jean-Michel Combes To: Mikael Abrahamsson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations , Nick Hilliard , "ipv6@ietf.org" , Ted Lemon X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 17:16:16 -0000 Hi, Regarding DHCP SAVI, this is not the main goal of this solution but a side effect. Best regards. JMC. 2011/6/14 Mikael Abrahamsson : > On Mon, 13 Jun 2011, Ted Lemon wrote: > >> On Jun 13, 2011, at 3:38 PM, Nick Hilliard wrote: >>> >>> dhcpv6 suffers from exactly the same problem. =A0Are there plans to >>> introduce dhcpv6-guard? >> >> Nobody's proposed it. > > > > I'd be surprised if implementations of this wouldn't also have some kind = of > idea or concept of "client ports" and "server ports"? > > -- > Mikael Abrahamsson =A0 =A0email: swmike@swm.pp.se > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From arturo.servin@gmail.com Thu Jun 16 12:46:36 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1514D11E8248; Thu, 16 Jun 2011 12:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] 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 hUzoqxHcLXX0; Thu, 16 Jun 2011 12:46:35 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id D308811E8205; Thu, 16 Jun 2011 12:46:34 -0700 (PDT) Received: by qyk38 with SMTP id 38so163283qyk.10 for ; Thu, 16 Jun 2011 12:46:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=gVKk+zGpYOdVOm4USOuo1rcibgEwxg0TrlYS79ATUzE=; b=QLLvaNSBiO8kE1zwTEk0+G0a9elQfcLSIrGsG/3xfUuWtZfxnvIzekmPiukup/2Cpn LoxSTcv14RsJq+3YEBLL4RK6MH6DC/M2Tn5L5V5G9Y486tBguTVopdKFnobjqiSacMSL xQgv7ONBleMJLLOh3lWJy1s8LWCBgyIALIMTM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=kcU5SF2X5L1cxIRJ8Kb8moeVnDSVxdfVbTB1fIaMQQlGxNRkCGzbt8c8dxbGBXTGS3 zxOuwfER5o8T6YHpFHD56M7Ii8Io/Y8WR/x70Xps8PLiuvsg33DLqmR1/BVr3vFFqbm4 0PlB8lw7l13lMz+izkMIH0WdRIrClx+cPeIuY= Received: by 10.224.211.67 with SMTP id gn3mr1046501qab.16.1308253594154; Thu, 16 Jun 2011 12:46:34 -0700 (PDT) Received: from 85-7-200.lacnic.net.uy ([200.7.85.188]) by mx.google.com with ESMTPS id u15sm1353982qcq.0.2011.06.16.12.46.30 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 16 Jun 2011 12:46:33 -0700 (PDT) Subject: Re: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Arturo Servin In-Reply-To: Date: Thu, 16 Jun 2011 16:46:27 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <351EBA42-0077-4AAD-8D4C-D2880B81FBC6@gmail.com> References: <4DF291D0.7080707@gont.com.ar> To: Jean-Michel Combes X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 19:46:36 -0000 Jean-Michel, On 16 Jun 2011, at 14:13, Jean-Michel Combes wrote: > Hi, >=20 > I've read quickly these two drafts. Here are some comments/questions: >=20 > o draft-gont-v6ops-ra-guard-evasion >=20 > IMHO, this draft should update RFC 6105 (If so, RFC6105 reference > should move from Informative References section to the Normative > References one). > Just a comment about your example for the fragmentation case with 2 > Destination extensions: from RFC2460 (section 4.1), this only occurs > when there is also a Routing Header extension, so I have to add a RH > in your example (better chance to get a fragmentation :)) >=20 > o draft-gont-6man-nd-extension-headers >=20 > IMHO, this is not a good idea to forbid the use of IPv6 extension with > NDP messages, especially when the reason is partially based on > implementation issues (i.e. the implementation is not able to process > an IPv6 packet): today, there is no real use of Extension header with > NDP but, tomorrow, if we need such an use for a solution, what will > happen? See below > Regarding the fragmentation, is it not possible for the RA-Guard > device to reassemble the fragments and so to be able to check whether > this a RA message or not? It's possible, perhaps. But the trade-off is to much IMHO. = Forcing a L2 device to inspect every packet and re-asemble them is = unfeasible or too expensive (similar for a more intelligent device = listening for every packet in the network looking for rogue RAs). The = same for extension headers in NDP, we are not using it today, may be we = will, but the trade-off to have it "just in case" is too much. >=20 > Thanks in advance for your reply. >=20 > Best regards. >=20 > JMC. Cheers, .as >=20 >=20 > 2011/6/10 Fernando Gont : >> Hi, >>=20 >> Some folks have expressed (both on-list and off-list) that they would >> prefer a less agressive solution for the RA-Guard evasion = vulnerability. >> So I'd like to hear comments about the possible alternatives.. >>=20 >> The current I-Ds (draft-gont-6man-nd-extension-headers and >> draft-gont-v6ops-ra-guard-evasion) basically take this approach: >>=20 >> * Prohibit use of extension headers in ND messages. A host >> implementation must not produce these packets, and must discard them = if >> it receives them >> * This results in a RA-Guard implementation that is as simple as >> possible (it only has to look at the header following the fixed IPv6 >> header). >>=20 >>=20 >> A more relaxed approach would be as follows: >> * Extension headers are allowed with ND messages. >> * If the packet is fragmented, the upper-layer header (ICMPv6 in this >> case) must be present in the first fragment (i.e., hosts must not >> generate packets that violate this requirement, and must discard them = if >> they receive them). >> * Possibly have the RA-Guard box enforce a limit on the maximum = number >> of extension headers that it will process (e.g., if after jumping to >> the, say 10th header the upper-layer header is not found, drop the = packet) >> * This approach is less aggressive than the one proposed in the >> aforementioned I-Ds (i.e., more flexibility), but of course would = also >> mean that the RA-Guard implementation would need to follow the header >> chain, thus leading to increased complexity, and possible performance >> issues. >>=20 >> Any comments/thoughts will be very much appreciated. >>=20 >> Thanks! >>=20 >> Best regards, >> -- >> Fernando Gont >> e-mail: fernando@gont.com.ar || fgont@acm.org >> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >>=20 >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nick@inex.ie Mon Jun 13 15:39:17 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABD211E809F; Mon, 13 Jun 2011 15:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 Vm9+3HekHUxB; Mon, 13 Jun 2011 15:39:16 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [46.182.8.5]) by ietfa.amsl.com (Postfix) with ESMTP id B7A4211E8070; Mon, 13 Jun 2011 15:39:15 -0700 (PDT) X-Envelope-To: ipv6@ietf.org Received: from crumpet.foobar.org (twinkie.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id p5DMcu9R036534 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 13 Jun 2011 23:39:01 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4DF69180.6050902@inex.ie> Date: Mon, 13 Jun 2011 23:38:56 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110528 Thunderbird/5.0b1 MIME-Version: 1.0 To: Fernando Gont Subject: Re: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers) References: <4DF291D0.7080707@gont.com.ar> In-Reply-To: <4DF291D0.7080707@gont.com.ar> X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 16 Jun 2011 13:15:09 -0700 Cc: IPv6 Operations , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 22:39:17 -0000 On 10/06/2011 22:51, Fernando Gont wrote: > * This results in a RA-Guard implementation that is as simple as > possible (it only has to look at the header following the fixed IPv6 > header). dhcpv6 suffers from exactly the same problem. Are there plans to introduce dhcpv6-guard? Nick From housley@vigilsec.com Mon Jun 13 16:57:52 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D75419E800E; Mon, 13 Jun 2011 16:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.158 X-Spam-Level: X-Spam-Status: No, score=-102.158 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 Vfn96rGnbGjm; Mon, 13 Jun 2011 16:57:52 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 356ED9E8007; Mon, 13 Jun 2011 16:57:52 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 86079F241CB; Mon, 13 Jun 2011 19:58:16 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id 2zCri2Y+0vBM; Mon, 13 Jun 2011 19:57:50 -0400 (EDT) Received: from v234.vpn.iad.rg.net (v234.vpn.iad.rg.net [198.180.150.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 5A1EDF24166; Mon, 13 Jun 2011 19:58:15 -0400 (EDT) Subject: Re: [saag] ITU-T SG17 IPv6 security work items liaison Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Russ Housley In-Reply-To: <4DF69899.2050606@cs.tcd.ie> Date: Mon, 13 Jun 2011 19:57:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Thu, 16 Jun 2011 13:15:11 -0700 Cc: v6ops@ietf.org, ipv6@ietf.org, "saag@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 23:57:53 -0000 Stephen: Comments below. Russ > From: IETF Security Area > To: Study Group 17, Questions 2 and 3 > Title: Work on Security of IPv6 >=20 > FOR ACTION >=20 > The IETF thanks Study Group 17 for its liaison LS-206 "Liaison on IPv6 > security issues". As the world transitions to IPv6, new opportunities > and challenges and challenges arise. SG17's new focus on deployment = and s/and challenges and challenges/and challenges/ s/new// > implementation considerations reflects this reality. We would like = to > bring to your attention the following work which we believe may prove = a > useful basis for both X.ipv6-secguide and X.mgv6: >=20 > * RFC 4294 =96 "IPv6 Node Requirements" (N.B., this work is = currently > under revision) Why not just reference the bis document? > * draft-ietf-6man-node-req-bis (work in progress) =96 "IPv6 Node > Requirements RFC 4294-bis" > * RFC 4864 =96 "Local Network Protection for IPv6" > * RFC 6092 =96 "Recommended Simple Security Capabilities in = Customer > Premise Equipment (CPE) for Providing Residential IPv6 Internet > Service" > * RFC 6105 =96 "IPv6 Router Advertisement Guard" > * RFC 6106 =96 "IPv6 Router Advertisement Options for DNS > Configuration", =A77 in particular. >=20 > As you are aware, every RFC contains a Security Considerations = section. > In developing either a implementation or deployment guide, = contributors > are strongly encouraged to review the RFCs and Internet-Drafts that > support any underlying function. >=20 > In addition, we bring to your attention the following IETF Working > Groups that are working on security-related work of IPv6: >=20 > Working Group Purpose Mailing list address > Name >=20 > 6man IPv6 Maintenance ipv6@ietf.org > savi Source Address Validation savi@ietf.org > Improvements > dhc Dynamic Host Configuration dhcwg@ietf.org > v6ops IPv6 Operations v6ops@ietf.org > opsec Operational Security opsec@ietf.org > Capabilities for an IP > Network >=20 > In addition to the above working groups, the Security Area of the IETF > maintains a mailing list for general discussion, saag@ietf.org. We > encourage and invite open and informal discussion in these or other > relevant IETF fora on this very important topic. As with all IETF > working groups, any and all interested parties can choose to directly > contribute via the mailing lists above. >=20 > As in other areas, the Security Area of the IETF invites SG17 to bring > any new-found concerns about IETF protocols to our attention so that = as > and when we revise our documents we can make appropriate amendments to > IETF protocols. In particular, as this planned work matures, we would > welcome hearing about it in more detail, perhaps via an invited > presentation at a saag meeting or via review of draft documents as may > be appropriate. From nick@inex.ie Tue Jun 14 03:00:37 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5588121F85CC; Tue, 14 Jun 2011 03:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 mFnPb+cqO35Y; Tue, 14 Jun 2011 03:00:36 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [46.182.8.5]) by ietfa.amsl.com (Postfix) with ESMTP id C10AB21F85C7; Tue, 14 Jun 2011 03:00:35 -0700 (PDT) X-Envelope-To: saag@ietf.org Received: from cupcake.internal.acquirer.com (mail.acquirer.com [87.198.142.10] (may be forged)) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id p5EA0OHg041950 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 14 Jun 2011 11:00:25 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4DF73138.6010009@inex.ie> Date: Tue, 14 Jun 2011 11:00:24 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110528 Thunderbird/5.0b1 MIME-Version: 1.0 To: Stephen Farrell Subject: Re: [v6ops] [saag] ITU-T SG17 IPv6 security work items liaison References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> In-Reply-To: <4DF69899.2050606@cs.tcd.ie> X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Thu, 16 Jun 2011 13:15:10 -0700 Cc: v6ops@ietf.org, ipv6@ietf.org, "saag@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 10:00:37 -0000 On 14/06/2011 00:09, Stephen Farrell wrote: > * RFC 6105 – "IPv6 Router Advertisement Guard" > * RFC 6106 – "IPv6 Router Advertisement Options for DNS > Configuration", §7 in particular. maybe mention draft-gont-v6ops-ra-guard-evasion? It's not a strategic focused document, but gives specific advice on a specific issue which is relevant to ipv6 lan deployments. Nick From nick@inex.ie Tue Jun 14 05:25:29 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18E3511E80B5; Tue, 14 Jun 2011 05:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 OVSJFEdsL7KY; Tue, 14 Jun 2011 05:25:28 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [46.182.8.5]) by ietfa.amsl.com (Postfix) with ESMTP id 6083C11E80A8; Tue, 14 Jun 2011 05:25:27 -0700 (PDT) X-Envelope-To: ipv6@ietf.org Received: from cupcake.internal.acquirer.com (mail.acquirer.com [87.198.142.10] (may be forged)) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id p5ECPDxr043934 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 14 Jun 2011 13:25:14 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4DF75328.6060109@inex.ie> Date: Tue, 14 Jun 2011 13:25:12 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110528 Thunderbird/5.0b1 MIME-Version: 1.0 To: Fernando Gont Subject: Re: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers) References: <4DF291D0.7080707@gont.com.ar> <4DF69180.6050902@inex.ie> <4DF6B804.4040703@gont.com.ar> In-Reply-To: <4DF6B804.4040703@gont.com.ar> X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 16 Jun 2011 13:15:10 -0700 Cc: IPv6 Operations , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 12:25:29 -0000 On 14/06/2011 02:23, Fernando Gont wrote: > This is something that vendors should answer. As long as there are > implementations that may try DHCPv6 even if no RA is received, DHCPv6 > should be implemented/deployed along RA-Guard, or else attackers will > switch to teh DHCPv6 vector, and RA-Guard will be circumvented this way. probably vendors aren't going to do much about dhcp6-guard unless there is a standard to work towards. I'd offer to help out, but my dhcpv6-fu is not really up to it. Nick From touch@isi.edu Tue Jun 14 17:17:48 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCF81F0C5C; Tue, 14 Jun 2011 17:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.38 X-Spam-Level: X-Spam-Status: No, score=-101.38 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_SORBS_WEB=0.619, 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 drapnSrBNONL; Tue, 14 Jun 2011 17:17:48 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id F167E1F0C5B; Tue, 14 Jun 2011 17:17:47 -0700 (PDT) Received: from [192.168.121.117] ([221.148.74.64]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id p5F0HIuB019915 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 14 Jun 2011 17:17:22 -0700 (PDT) Message-ID: <4DF7FA0D.6040201@isi.edu> Date: Tue, 14 Jun 2011 17:17:17 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Stephen Farrell Subject: Re: [saag] [v6ops] ITU-T SG17 IPv6 security work items liaison References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> <4DF73138.6010009@inex.ie> <4DF740E5.4030309@cs.tcd.ie> In-Reply-To: <4DF740E5.4030309@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Thu, 16 Jun 2011 13:15:12 -0700 Cc: v6ops@ietf.org, Nick Hilliard , ipv6@ietf.org, "saag@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 00:17:48 -0000 Hi, all, It'd be useful to wait until these docs (this v6ops one and the 6man one it refers) are adopted by the relevant WGs before noting them in recommendations to external parties, IMO. Some of the recommendations in these documents are akin to "if I didn't expect it, it's an attack", which I feel makes our protocols too brittle unless we are in a situation of known security compromise via other indicators. The latter doc (6man) also silently discards legitimate packets (complicating debugging), and ends up deprecating the entire extension header feature of IPv6 for all IPv6 signaling protocols - which seems like a bad idea overall. I'd prefer to see the relevant WGs endorse these as useful ways forward before adding them to this list. Joe On 6/14/2011 4:07 AM, Stephen Farrell wrote: > > Thanks Nick, > > I'll add that unless someone tells me its a bad plan. > Its a fairly fresh I-D, but I guess it looks pretty > relevant all right. > > S. > > On 14/06/11 11:00, Nick Hilliard wrote: >> On 14/06/2011 00:09, Stephen Farrell wrote: >>> * RFC 6105 – "IPv6 Router Advertisement Guard" >>> * RFC 6106 – "IPv6 Router Advertisement Options for DNS >>> Configuration", §7 in particular. >> >> maybe mention draft-gont-v6ops-ra-guard-evasion? It's not a strategic >> focused document, but gives specific advice on a specific issue which is >> relevant to ipv6 lan deployments. >> >> Nick >> > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From touch@isi.edu Tue Jun 14 17:36:08 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32EA221F84F1; Tue, 14 Jun 2011 17:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.994 X-Spam-Level: X-Spam-Status: No, score=-101.994 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 mUStbJKOsrRO; Tue, 14 Jun 2011 17:36:07 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id A46F521F84EA; Tue, 14 Jun 2011 17:36:07 -0700 (PDT) Received: from [192.168.121.117] ([221.148.74.90]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id p5F0Zn26026673 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 14 Jun 2011 17:35:54 -0700 (PDT) Message-ID: <4DF7FE65.9070303@isi.edu> Date: Tue, 14 Jun 2011 17:35:49 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Stephen Farrell Subject: Re: [saag] [v6ops] ITU-T SG17 IPv6 security work items liaison References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> <4DF73138.6010009@inex.ie> <4DF740E5.4030309@cs.tcd.ie> <4DF7FA0D.6040201@isi.edu> <4DF7FD96.9010700@cs.tcd.ie> In-Reply-To: <4DF7FD96.9010700@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Thu, 16 Jun 2011 13:15:12 -0700 Cc: v6ops@ietf.org, Nick Hilliard , ipv6@ietf.org, "saag@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 00:36:08 -0000 On 6/14/2011 5:32 PM, Stephen Farrell wrote: > > Hi Joe, > > Fair point about the draft-gont document. I've taken it out > for now. > > Which was the 6man I-D you meant? The one ref'd inside the draft-gont-v6ops doc - it's draft-gont-6man... There aren't issues with the draft-ietf-6man docs. Joe > There are now two referenced > thanks to recent comments and both are draft-ietf-6man so have > presumably been adopted by the WG. > > My current version is attached following today's edits in case > that helps. > > I've still not included rfc 3514 but the more iterations this > takes, the more I'm getting more tempted:-) > > Thanks, > S. > > On 15/06/11 01:17, Joe Touch wrote: >> Hi, all, >> >> It'd be useful to wait until these docs (this v6ops one and the 6man one >> it refers) are adopted by the relevant WGs before noting them in >> recommendations to external parties, IMO. >> >> Some of the recommendations in these documents are akin to "if I didn't >> expect it, it's an attack", which I feel makes our protocols too brittle >> unless we are in a situation of known security compromise via other >> indicators. The latter doc (6man) also silently discards legitimate >> packets (complicating debugging), and ends up deprecating the entire >> extension header feature of IPv6 for all IPv6 signaling protocols - >> which seems like a bad idea overall. >> >> I'd prefer to see the relevant WGs endorse these as useful ways forward >> before adding them to this list. >> >> Joe >> >> On 6/14/2011 4:07 AM, Stephen Farrell wrote: >>> >>> Thanks Nick, >>> >>> I'll add that unless someone tells me its a bad plan. >>> Its a fairly fresh I-D, but I guess it looks pretty >>> relevant all right. >>> >>> S. >>> >>> On 14/06/11 11:00, Nick Hilliard wrote: >>>> On 14/06/2011 00:09, Stephen Farrell wrote: >>>>> * RFC 6105 – "IPv6 Router Advertisement Guard" >>>>> * RFC 6106 – "IPv6 Router Advertisement Options for DNS >>>>> Configuration", §7 in particular. >>>> >>>> maybe mention draft-gont-v6ops-ra-guard-evasion? It's not a strategic >>>> focused document, but gives specific advice on a specific issue which is >>>> relevant to ipv6 lan deployments. >>>> >>>> Nick >>>> >>> _______________________________________________ >>> saag mailing list >>> saag@ietf.org >>> https://www.ietf.org/mailman/listinfo/saag >> From jeanmichel.combes@gmail.com Thu Jun 16 13:44:52 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B01611E82F1; Thu, 16 Jun 2011 13:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.427 X-Spam-Level: X-Spam-Status: No, score=-103.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 A7AVAnZ9YRmR; Thu, 16 Jun 2011 13:44:51 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF0111E82D6; Thu, 16 Jun 2011 13:44:51 -0700 (PDT) Received: by gyf3 with SMTP id 3so782950gyf.31 for ; Thu, 16 Jun 2011 13:44:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=bHHAsTDoB9FhUgwdJFv1uk7yDZ662wCaG0y5sdg2wZ8=; b=UWMXnpCsCCsXquNwAFrlhErzQaFwWVrCGSFAAIGKY3q+oPAADHTjbbGrmmYKxOcWER e3HNvjh7B9H/G4hZZwSYBC3pPBtptulFGL6y7ojvGw6kfnB7ig1yRVuuuJZA46viQUGJ YfVMF8fr9y8RcKsN4A+pUhS/tw4eaLEgzQq1o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=cyLOFHKUV9E+yLE6TQ0oIPaqIbiWKVJPxXzTALmxc1EPP4zR91lRulRYfi7gvOl2EN xWE6fdGTZDB7M65J0zGTk++v6RqS0nN+8XrRaFgL+5Iilp38en6HEA7yWE44jgAElTNb ycFJa2KsQyk3Xz992dMBYN8U2Askm5FsG2jZQ= MIME-Version: 1.0 Received: by 10.236.77.165 with SMTP id d25mr2001300yhe.25.1308257090865; Thu, 16 Jun 2011 13:44:50 -0700 (PDT) Received: by 10.147.83.20 with HTTP; Thu, 16 Jun 2011 13:44:50 -0700 (PDT) In-Reply-To: <351EBA42-0077-4AAD-8D4C-D2880B81FBC6@gmail.com> References: <4DF291D0.7080707@gont.com.ar> <351EBA42-0077-4AAD-8D4C-D2880B81FBC6@gmail.com> Date: Thu, 16 Jun 2011 22:44:50 +0200 Message-ID: Subject: Re: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers) From: Jean-Michel Combes To: Arturo Servin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 20:44:52 -0000 Hi Arturo, at first, thanks for your reply. 2011/6/16 Arturo Servin : > Jean-Michel, > > On 16 Jun 2011, at 14:13, Jean-Michel Combes wrote: > [snip] >> >> o draft-gont-6man-nd-extension-headers >> >> IMHO, this is not a good idea to forbid the use of IPv6 extension with >> NDP messages, especially when the reason is partially based on >> implementation issues (i.e. the implementation is not able to process >> an IPv6 packet): today, there is no real use of Extension header with >> NDP but, tomorrow, if we need such an use for a solution, what will >> happen? > > =A0 =A0 =A0 =A0See below > >> Regarding the fragmentation, is it not possible for the RA-Guard >> device to reassemble the fragments and so to be able to check whether >> this a RA message or not? > > =A0 =A0 =A0 =A0It's possible, perhaps. But the trade-off is to much IMHO.= Forcing a L2 device to inspect every packet and re-asemble them is unfeasi= ble or too expensive (similar for a more intelligent device listening for e= very packet in the network looking for rogue RAs). The same for extension h= eaders in NDP, we are not using it today, may be we will, but the trade-off= to have it "just in case" is too much. > Why is this unfeasible? Again an implementation issue? Why is it too expensive? Memory issue? CPU issue? Something else? Best regards. JMC. From joelja@bogus.com Thu Jun 16 13:57:49 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC9011E829D; Thu, 16 Jun 2011 13:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.199 X-Spam-Level: X-Spam-Status: No, score=-102.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 3tvhDzDIwnUA; Thu, 16 Jun 2011 13:57:49 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4603C11E8268; Thu, 16 Jun 2011 13:57:49 -0700 (PDT) Received: from zorch.corp.zynga.com ([12.184.108.202]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p5GKvhKp080661 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 16 Jun 2011 20:57:44 GMT (envelope-from joelja@bogus.com) Subject: Re: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: Date: Thu, 16 Jun 2011 13:57:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6CDF3074-DB43-443C-BDE3-82558E4F844E@bogus.com> References: <4DF291D0.7080707@gont.com.ar> <351EBA42-0077-4AAD-8D4C-D2880B81FBC6@gmail.com> To: Jean-Michel Combes X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 16 Jun 2011 20:57:44 +0000 (UTC) X-Mailman-Approved-At: Thu, 16 Jun 2011 14:38:12 -0700 Cc: "ipv6@ietf.org" , IPv6 Operations , Arturo Servin X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 20:57:50 -0000 On Jun 16, 2011, at 1:44 PM, Jean-Michel Combes wrote: > Hi Arturo, >=20 > at first, thanks for your reply. >=20 > 2011/6/16 Arturo Servin : >> Jean-Michel, >>=20 >> On 16 Jun 2011, at 14:13, Jean-Michel Combes wrote: >>=20 >=20 > [snip] >=20 >>>=20 >>> o draft-gont-6man-nd-extension-headers >>>=20 >>> IMHO, this is not a good idea to forbid the use of IPv6 extension = with >>> NDP messages, especially when the reason is partially based on >>> implementation issues (i.e. the implementation is not able to = process >>> an IPv6 packet): today, there is no real use of Extension header = with >>> NDP but, tomorrow, if we need such an use for a solution, what will >>> happen? >>=20 >> See below >>=20 >>> Regarding the fragmentation, is it not possible for the RA-Guard >>> device to reassemble the fragments and so to be able to check = whether >>> this a RA message or not? >>=20 >> It's possible, perhaps. But the trade-off is to much IMHO. = Forcing a L2 device to inspect every packet and re-asemble them is = unfeasible or too expensive (similar for a more intelligent device = listening for every packet in the network looking for rogue RAs). The = same for extension headers in NDP, we are not using it today, may be we = will, but the trade-off to have it "just in case" is too much. >>=20 >=20 > Why is this unfeasible? Again an implementation issue? > Why is it too expensive? Memory issue? CPU issue? Something else? it's expensive because you have to set them aside and re-assemble and nd = is going to be reassembled in a control-plane processor, which leads to = cases where the attacker deliberately maximizes the expense associated = with doing so.=20 > Best regards. >=20 > JMC. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From rja.lists@gmail.com Fri Jun 17 06:50:53 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFBC411E80D2 for ; Fri, 17 Jun 2011 06:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] 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 fD7NyLKNSixz for ; Fri, 17 Jun 2011 06:50:51 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id B231211E80A4 for ; Fri, 17 Jun 2011 06:50:50 -0700 (PDT) Received: by qwc23 with SMTP id 23so1848018qwc.31 for ; Fri, 17 Jun 2011 06:50:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:to:mime-version:x-mailer; bh=Nt6cwVaqE1AEjJh4iB/hxmweCSKE/XUcPV8975E1i9A=; b=RIys6/wsFcQTTMit7Y0m97obz41we2R8/bRGzRILQKEw2OCqFn2bLBhezA4JPlPtUu jVN3NgsR+UBwnzsvGhLTQAf9O04AKZRo5mfPfIF6r0Pd3DEfvV7d4MWW+jtvNTkTeixn GnQgMfob7pMr5x2lyFTkZbecHm2A3S53Ik6Jk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=Ak54BfxgYwrEM6ZzqJBxHskdL1m997YrimiUB7XvAN6IAYGQ6ZpHj3KfZXRvW2/a7u K7g3KU++JE4fHd8506vJOJdcMamDPQR68ftqg+mok5KSAGv4V9h8nPXtZqGMGO8vJbQf gjIcMPgAfkzJoTqRQ2zHRcFPfdISj72QMO69U= Received: by 10.224.210.197 with SMTP id gl5mr1831112qab.248.1308318650080; Fri, 17 Jun 2011 06:50:50 -0700 (PDT) Received: from [10.30.20.12] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id f16sm1913677qck.45.2011.06.17.06.50.48 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 17 Jun 2011 06:50:49 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] Question regarding Ra-Guard evasion (ND and extension headers) Date: Fri, 17 Jun 2011 09:50:47 -0400 Message-Id: To: ipv6@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 13:50:53 -0000 Earlier, someone wrote: > it's expensive because you have to set them aside and re-assemble > and nd is going to be reassembled in a control-plane processor, > which leads to cases where the attacker deliberately maximizes > the expense associated with doing so. For fragmented ND packets the above is clearly true for many (most ?) implementations. So I totally understand the motivation for disallowing fragmentation of ND packets. I suspect that most folks agree with this subset of the RA Guard I-D. Certainly I agree with this. Banning all forms of the IPv6 Routing Header in ND packets also seems reasonable, primarily because in all cases ND packets ought to be bridged (i.e. via link layer methods) between source and destination, rather than routed. So I also suspect that most folks agree with this. Just to be clear, I agree with this. What I don't find convincing, and I gather some other folks also don't find convincing, is Fernando's extrapolation that any and all IPv6 extensions should be prohibited in ND packets. The philosophy of the RA-Guard I-D seems to be "ban everything, just in case it might be a problem later". I think that is too strong a position and needlessly limits IPv6 evolution, for little to no actual reduction of operational risk. I propose to invert that philosophy to one where "known serious risks" (e.g. Fragmentation Header, Routing Header) are prohibited while other extensions are permitted. In the special case of ND packets, the Hop-by-Hop Extension Header has behaviour identical to the Destination Options Header -- because there are no hops between source and destination. As RFC-2460, Section 4.3 clearly shows, it IS possible for a device functioning as an RA-Guard to parse *past* the Hop-by-Hop header without knowing anything about its contents (and without needing to know anything about its contents). So in this case, the Hop-by-Hop Extension Header does NOT have the problematic behaviours that it would have in many other situation (e.g. the potential to DOS transit routers simply does NOT exist for an ND packet because those packets are *never* routed). In particular, I believe that ND packets should be allowed to have at least 1 instance each of the IPv6 Hop-by-Hop Options Header, IPv6 Destination Options header, and IP Authentication Header. In practice, such packets will be extremely uncommon. The IPv6 packet design makes it computationally simple and easy to move past that header to get to whatever payload is behind (e.g. ICMPv6, TCP, UDP, SCTP). The incremental cost to a low-cost CPU-based implementation to support this would be incurred only on packets that contained one of these 3 IPv6 extension headers. The cost per extension header present in the packet would be (roughly) to read 2 bytes extra (i.e. the "Next Header" field in the extension header and also the "Hdr Ext Len" field), and then add the value of "Hdr Ext Len" that was just read to the packet pointer. For all 3 of those IPv6 Extension Headers, those 2 bytes are located in precisely the same place, eliminating a need for per-extension special case code. This is a tiny amount of code, with a tiny memory footprint, and would consume a tiny amount of additional CPU instructions, so any device that already is parsing into the IPv6 frame to perform the RA-Guard checks could easily support the presence of these extension headers. While I realise most folks here already understand this, I think it is really important for everyone to understand that it is *impossible* to prevent Denial-of-Service attacks in a useful network deployment. What can and should be done is to find ways to increase the work function of the attacker's least/less expensive attack vectors. The DoS attackers (or at least the attack tool authors) are not stupid and they are lazy, so operational experience consistently has shown that they consistently deploy the least expensive (to the attacker) viable DoS attack they can. So I do not find Denial-of-Service attack concerns particularly credible in the special case of "these 3 (DO, HbH, AH) extension headers appearing in ND packets", because the attacker already would have to be on-link to undertake an ND-oriented DoS attack. An on-link attacker has *numerous* simpler, widely known, and lower-cost-to-the-attacker ways of DoS'ing *any device* on that same link. [WELL KNOWN EXAMPLE: Perhaps the simplest on-link DoS attack would be to flood a large number of link-layer broadcast frames. Even if the receivers simply discarded the frames, such a flood could be quite damaging to normal use of the network. Many many other low-cost link-layer DOS attack vectors are widely known; this is just a simple example.] Yours, Ran Atkinson PS: Having a CALIPSO option (RFC-5570) in an ND packet is a real-world use case, albeit an extremely uncommon kind of IPv6 deployment at present. In an MLS network deployment, devices that have disjoint authorised sensitivity-label ranges ought not be aware of each other. This is easy to achieve by simply putting a CALIPSO option in all IPv6 packets sent within the MLS network deployment. The receiving MLS-enabled node will perform the CALIPSO label check early in the ipv6_input() code, before either passing the packet up to the next protocol xor dropping the packet as having an out-of-range sensitivity label. Per the CALIPSO spec, the CALIPSO option is ignored by nodes that don't support it. From rpaulo@apple.com Fri Jun 17 08:13:21 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98B2211E81B7 for ; Fri, 17 Jun 2011 08:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 J1W95Tr6yNfm for ; Fri, 17 Jun 2011 08:13:21 -0700 (PDT) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id E510E11E81AD for ; Fri, 17 Jun 2011 08:13:20 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay12.apple.com ([17.128.113.53]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LMX00GL4WW9K411@mail-out.apple.com> for ipv6@ietf.org; Fri, 17 Jun 2011 08:12:45 -0700 (PDT) X-AuditID: 11807135-b7b76ae000001169-a9-4dfb6f43792d Received: from [17.153.36.155] (Unknown_Domain [17.153.36.155]) by relay12.apple.com (Apple SCV relay) with SMTP id 24.2F.04457.44F6BFD4; Fri, 17 Jun 2011 08:14:12 -0700 (PDT) Subject: Re: I-D Action: draft-ietf-6man-rfc3484-revise-03.txt From: Rui Paulo In-reply-to: <20110610101654.26396.61851.idtracker@ietfa.amsl.com> Date: Fri, 17 Jun 2011 08:12:45 -0700 Message-id: References: <20110610101654.26396.61851.idtracker@ietfa.amsl.com> To: ipv6@ietf.org X-Mailer: Apple Mail (2.1242) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplluLIzCtJLcpLzFFi42IRnKkyW9cl/7evwcmLXBYvz75ncmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpp2/oK1HBW3f3UwNzA2sHUxcnJICJhI/F/2kh3CFpO4cG89 UJyLQ0hgI6PE7zNzwIqYBbQkbvx7yQRi8woYSkyd85sFxBYWsJNYcPINmM0moCTxrO8E2CBO ASeJNYc2MILYLAKqEq/bGqHmaEssW/iaGWKOjcS+WY/AaoQEHCXWdlxnBbFFBAQltj/4wQJx kKxEV89n1gmMfLOQnDELyRmzkIxdwMi8ilGwKDUnsdLQSC+xoCAnVS85P3cTIyiQGgpNdzA+ Wqh+iFGAg1GJh9fR+pevEGtiWXFl7iFGCQ5mJRHe82a/fYV4UxIrq1KL8uOLSnNSiw8xSnOw KInzvr3v6SskkJ5YkpqdmlqQWgSTZeLglGpgFLO0t92WwDXReurPKRcleu4U1B4U58yfEDGF Pa1Me+vX8G+Lbpk+4BSbwtTz/WoAY/nuTgm3Bwcur1/Gdv99vF3NkfVbrd/d2t7GtevErUlf nyhVBxcdNrZkFMt90HzijO/C6qlMLN51szMYGouuyn5O+3xur9d001tvaw9EPo2K+WO3Y/u7 HiWW4oxEQy3mouJEACYshoQgAgAA X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 15:13:21 -0000 Hi, On Jun 10, 2011, at 3:16 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. > > Title : Update to RFC 3484 Default Address Selection for IPv6 > Author(s) : Arifumi Matsumoto > Jun-ya Kato > Tomohiro Fujisaki > Filename : draft-ietf-6man-rfc3484-revise-03.txt > Pages : 11 > Date : 2011-06-10 > > RFC 3484 describes algorithms for source address selection and for > destination address selection. The algorithms specify default > behavior for all Internet Protocol version 6 (IPv6) implementations. > This document specifies a set of updates that modify the algorithms > and fix the known defects. I can't seem to find the discussion that led to this new draft. Could you please clarify why 3ffe::/16 was removed from the new policy table? Thanks, -- Rui Paulo From brian@innovationslab.net Fri Jun 17 08:25:10 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39C7511E8179 for ; Fri, 17 Jun 2011 08:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 5DrhcU6myBaC for ; Fri, 17 Jun 2011 08:25:09 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC6211E8171 for ; Fri, 17 Jun 2011 08:25:09 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id A88F4881BC for ; Fri, 17 Jun 2011 08:25:08 -0700 (PDT) Received: from clemson.jhuapl.edu (unknown [128.244.243.28]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 67E20130002 for ; Fri, 17 Jun 2011 08:25:08 -0700 (PDT) Message-ID: <4DFB71D3.2090405@innovationslab.net> Date: Fri, 17 Jun 2011 11:25:07 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: I-D Action: draft-ietf-6man-rfc3484-revise-03.txt References: <20110610101654.26396.61851.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 15:25:10 -0000 On 6/17/11 11:12 AM, Rui Paulo wrote: > Hi, > > On Jun 10, 2011, at 3:16 AM, internet-drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the IPv6 Maintenance >> Working Group of the IETF. >> >> Title : Update to RFC 3484 Default Address Selection for >> IPv6 Author(s) : Arifumi Matsumoto Jun-ya Kato Tomohiro >> Fujisaki Filename : draft-ietf-6man-rfc3484-revise-03.txt >> Pages : 11 Date : 2011-06-10 >> >> RFC 3484 describes algorithms for source address selection and for >> destination address selection. The algorithms specify default >> behavior for all Internet Protocol version 6 (IPv6) >> implementations. This document specifies a set of updates that >> modify the algorithms and fix the known defects. > > > I can't seem to find the discussion that led to this new draft. Could > you please clarify why 3ffe::/16 was removed from the new policy > table? The use of 3FFE has been deprecated. Regards, Brian From tjc@ecs.soton.ac.uk Fri Jun 17 08:56:57 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1436C11E81CF for ; Fri, 17 Jun 2011 08:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.349 X-Spam-Level: X-Spam-Status: No, score=-1.349 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_00=-2.599] 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 C1cUCU+d9BtL for ; Fri, 17 Jun 2011 08:56:56 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 0359D11E8084 for ; Fri, 17 Jun 2011 08:56:55 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p5HFumag001770 for ; Fri, 17 Jun 2011 16:56:48 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p5HFumag001770 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1308326208; bh=lgyq1yzQvloHtjTNejrArlyiO40=; h=References:In-Reply-To:Mime-Version:From:Subject:Date:To; b=Jx38aNiXzZj9OpI5hTTypC8Lkb2ipD4yVke+c54VrPqPf4gUv7eUfEGka5l+0OfHk RjfULm3Ju5tGKGy1jfudmu8kMvTYCenRKDqrsFNRQ57K16abIqrh6r52XDD3O+Lg6V L44qQ07c3obqfiplE2Xs31oh2t3GdrPB2QwhmSaQ= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id n5GGum036610282569 ret-id none; Fri, 17 Jun 2011 16:56:48 +0100 Received: from cerf.ecs.soton.ac.uk (cerf.ecs.soton.ac.uk [152.78.69.39]) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p5HFujcw011897 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 17 Jun 2011 16:56:45 +0100 References: <20110610101654.26396.61851.idtracker@ietfa.amsl.com> <4DFB71D3.2090405@innovationslab.net> <582E33EF-5DCD-414E-872A-F457431D0901@ecs.soton.ac.uk> In-Reply-To: <4DFB71D3.2090405@innovationslab.net> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-ID: Content-Transfer-Encoding: 7bit From: Tim Chown Subject: Re: I-D Action: draft-ietf-6man-rfc3484-revise-03.txt Date: Fri, 17 Jun 2011 16:56:45 +0100 To: ipv6@ietf.org X-Mailer: Apple Mail (2.1084) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=n5GGum036610282500; tid=n5GGum036610282569; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: p5HFumag001770 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 15:56:57 -0000 On 17 Jun 2011, at 16:25, Brian Haberman wrote: > On 6/17/11 11:12 AM, Rui Paulo wrote: >> Hi, >> >> On Jun 10, 2011, at 3:16 AM, internet-drafts@ietf.org wrote: >> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. This draft is a work item of the IPv6 Maintenance >>> Working Group of the IETF. >>> >>> Title : Update to RFC 3484 Default Address Selection for >>> IPv6 Author(s) : Arifumi Matsumoto Jun-ya Kato Tomohiro >>> Fujisaki Filename : draft-ietf-6man-rfc3484-revise-03.txt >>> Pages : 11 Date : 2011-06-10 >>> >>> RFC 3484 describes algorithms for source address selection and for >>> destination address selection. The algorithms specify default >>> behavior for all Internet Protocol version 6 (IPv6) >>> implementations. This document specifies a set of updates that >>> modify the algorithms and fix the known defects. >> >> >> I can't seem to find the discussion that led to this new draft. Could >> you please clarify why 3ffe::/16 was removed from the new policy >> table? > > The use of 3FFE has been deprecated. Should we also remove site-locals then, or IPv4-compatibles? Tim From jari.arkko@piuha.net Fri Jun 17 14:22:20 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796F811E80A4 for ; Fri, 17 Jun 2011 14:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.405 X-Spam-Level: X-Spam-Status: No, score=-102.405 tagged_above=-999 required=5 tests=[AWL=0.194, 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 dhWTJAK6Wvo1 for ; Fri, 17 Jun 2011 14:22:19 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id DEA7911E807F for ; Fri, 17 Jun 2011 14:22:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 105A62CC49; Sat, 18 Jun 2011 00:22:17 +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 XCYokD4dJEh1; Sat, 18 Jun 2011 00:22:15 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id CC0BD2CC2F; Sat, 18 Jun 2011 00:22:15 +0300 (EEST) Message-ID: <4DFBC587.9090807@piuha.net> Date: Sat, 18 Jun 2011 00:22:15 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: draft-ietf-6man-rpl-option@tools.ietf.org, IETF IPv6 Mailing List Subject: AD review of draft-ietf-6man-rpl-option Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 21:22:20 -0000 I have reviewed this draft. Some of the issues from the other draft are visible in this one as well, and I saw two additional substantive issues: - we need to specify the behavior with regards to the data in this option better - the text about processing packets in RPL border routers should be written in a different manner Both of these should be easily addressed, however. Please revise the draft and we can send the draft to IETF Last Call. Here are my comments in more detail: > Datagrams being forwarded within a RPL domain MUST include a RPL > Option. For datagrams sourced within a RPL domain, the RPL Option > MAY be included in the datagram itself. I'm not sure I understand the difference or its motivation. Do you really mean that a packet might not have the option until it hits the first router? Or are you just talking about something that happens internally on a host, but on the wire all packets would still have the option? Also, since the tunnel (or something else) is used to include the option for datagrams sourced outside the RPL domain, wouldn't it be easier to just say this: "Datagrams sent between nodes within an RPL domain MUST include an RPL Option." > For datagrams sourced > outside a RPL domain, IPv6-in-IPv6 tunneling, as specified in > [RFC2473 ] SHOULD be used to include a RPL Option. This text should be aligned with whatever conclusion we will have for the issue that I raised with the other document. > To help avoid IP-layer fragmentation, the RPL Option has a maximum > size of RPL_OPTION_MAX_SIZE octets and links within a RPL domain > SHOULD have a MTU of at least 1280 + 44 (outer IP header, Hop-by-Hop > Option header, Option header) + RPL_OPTION_MAX_SIZE + (additional > extension headers or options needed within RPL domain). > There's a same MTU issue here as in the other document. > The action taken by using the RPL Option and the potential set of > sub-TLVs carried within the RPL Option MUST be specified by the RFC > of the protocol that use that option. No TLVs are defined in this > document. > I think you should define the behavior when a node encounters a sub-TLV that it does not recognize. E.g., ignore and move on to the next sub-TLV. Or do you want a stricter policy? In any case, for future extensions it will be necessary to know how they are treated by legacy RPL nodes. > In very specific cases, IPv6-in-IPv6 tunneling may be undesirable due > to the added cost and complexity required to process and carry a > datagram with two IPv6 headers. [I-D.hui-6man-rpl-headers ] describes > how to avoid using IPv6-in-IPv6 tunneling in such specific cases and > the risks involved. > Again, the same comments as in the other draft. Please delete this paragraph. > For datagrams exiting the RPL domain, RPL Border Routers MUST remove > the RPL Option from the datagram. If the RPL Option was included > using tunneled mode and the RPL Border Router serves as the tunnel > end-point, removing the outer IPv6 header serves to remove the RPL > Option as well. Otherwise, the RPL Border Router assumes that the > RPL Option was included using transport mode and MUST remove the RPL > Option from the IPv6 Hop-by-Hop Option header. > The part about removing the RPL option even in a non-tunneled case relates to the issue of supporting that particular mode of operation. But in addition, I wonder if you should write the above text not in terms of packet modification operations but rather in terms of forwarding decision outcomes. Like this, for instance: "For datagrams destined to the RPL Border Router the router processes the packet in the usual way. For instance, if the RPL Option was included using tunneled mode and the RPL Border Router serves as the tunnel end-point, the router removes the outer IPv6 header, at the same removing the RPL Option as well. Datagrams destined elsewhere within the same RPL domain are forwarded to the right interface. Datagrams destined outside the RPL domain are dropped." > 6. Usage of the RPL Option > > The RPL Option is only for use within a RPL domain. RPL routers MUST > process and include the RPL Option when forwarding datagrams to other > nodes within the RPL domain. Routers on the edge of a RPL domain > MUST remove the RPL Option when forwarding datagrams to nodes outside > the RPL domain. What is it that this section says that is not already covered by sections 2 and 5: Sect 2: Datagrams being forwarded within a RPL domain MUST include a RPL Option. Sect 5: ... serves as the tunnel end-point, removing the outer IPv6 header serves to remove the RPL Option as well. Otherwise, the RPL Border Router assumes that the RPL Option was included using transport mode and MUST remove the RPL Option from the IPv6 Hop-by-Hop Option header. > This option may be used to mount several potential attacks since > routers may be flooded by bogus datagram containing the RPL option. > It is thus RECOMMENDED for routers to implement a rate limiter for > datagrams using the RPL Option. > Please open this up a bit. What specific danger does flooding by bogus datagrams and RPL options cause? What would be the default settings for the rate limiter? > Opt Data Len: 8-bit field indicating the length of the option, in > octets, excluding the Option Type and Opt Data Len fields. > > Down 'O': 1-bit flag as defined in Section 11 of > [I-D.ietf-roll-rpl ]. > > Rank-Error 'R': 1-bit flag as defined in Section 11 of > [I-D.ietf-roll-rpl ]. > > Forwarding-Error 'F': 1-bit flag as defined in Section 11 of > [I-D.ietf-roll-rpl ]. > > RPLInstanceID: 8-bit field as defined in Section 11 of > [I-D.ietf-roll-rpl ]. > > SenderRank: 16-bit field as defined in Section 11 of > [I-D.ietf-roll-rpl ]. > > Values within the RPL Option are expected to change en-route. This specification needs to describe what the behavior of a router is with the content of the option. I think this is easy, you should just add to the end: "The processing shall follow the rules described in Section 11.2 of [roll-rpl]. As an aside, the entire Section 11 is marked in roll-rpl as non-normative. I don't think that's actually right as far as 11.2 goes, because it contains tons of MUSTs and SHOULDs. Perhaps you want to fix that in AUTH48... Jari From rpaulo@apple.com Sat Jun 18 08:48:35 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD9B11E81DD for ; Sat, 18 Jun 2011 08:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 aZlPzIBK8kWx for ; Sat, 18 Jun 2011 08:48:35 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 48B4A11E81E6 for ; Sat, 18 Jun 2011 08:48:34 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay11.apple.com ([17.128.113.48]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LMZ00B03T7M0B00@mail-out.apple.com> for ipv6@ietf.org; Sat, 18 Jun 2011 08:47:46 -0700 (PDT) X-AuditID: 11807130-b7c45ae000001381-38-4dfcc8a05220 Received: from [17.153.55.127] (Unknown_Domain [17.153.55.127]) by relay11.apple.com (Apple SCV relay) with SMTP id D1.29.04993.0A8CCFD4; Sat, 18 Jun 2011 08:47:44 -0700 (PDT) Subject: Re: I-D Action: draft-ietf-6man-rfc3484-revise-03.txt From: Rui Paulo In-reply-to: <4DFB71D3.2090405@innovationslab.net> Date: Sat, 18 Jun 2011 08:47:45 -0700 Message-id: <8CC75BA6-A86C-4294-AB5B-7B7606B2A0C0@apple.com> References: <20110610101654.26396.61851.idtracker@ietfa.amsl.com> <4DFB71D3.2090405@innovationslab.net> To: Brian Haberman X-Mailer: Apple Mail (2.1242) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUiONO8XnfBiT++BhNPclnM7PnHaPHy7Hsm ByaPJUt+MnnMPP6FJYApissmJTUnsyy1SN8ugSvj5ZGjjAU7uCt2LJvO3sD4g6OLkZNDQsBE 4sCNy8wQtpjEhXvr2boYuTiEBDYySjw8PZ8JJCEsYCex4OQbFhCbV8BQYuqc32A2s4CWxI1/ L8Fq2ASUJJ71nWAHsTkFjCQmP9gGVsMioCqx/Ol2qHpBiaszpzFC2NoSyxa+ZoaYaSOxbdE2 ZojFMxglfh5oZQNJiAjoSjR2rGCBuE5WoqvnM+sERv5ZSO6YheSOWUjmLmBkXsUoWJSak1hp aKiXWFCQk6qXnJ+7iREUeA2FBjsY1/7kP8QowMGoxMP7s+i3rxBrYllxZe4hRgkOZiURXsU5 f3yFeFMSK6tSi/Lji0pzUosPMUpzsCiJ815b88lXSCA9sSQ1OzW1ILUIJsvEwSnVwNjNncC8 iF1ays9q98IK6c2BPK4/4sX/nTzez7f43L/wV8YLHcW4z7/qP+Cz6/OTixZaLSEnVO0cZu2u 8z9zILLi5FXdL1+MMupKJL5rFCqt324o/PRdUfyXRwnVC7WV91w29j0jf/J9t6E1x8F//smn WXXcv15a/K7z4cbpRYV1/ooagk5nZZRYijMSDbWYi4oTAWUL+QE4AgAA Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2011 15:48:35 -0000 On Jun 17, 2011, at 8:25 AM, Brian Haberman wrote: > On 6/17/11 11:12 AM, Rui Paulo wrote: >> Hi, >> >> On Jun 10, 2011, at 3:16 AM, internet-drafts@ietf.org wrote: >> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. This draft is a work item of the IPv6 Maintenance >>> Working Group of the IETF. >>> >>> Title : Update to RFC 3484 Default Address Selection for >>> IPv6 Author(s) : Arifumi Matsumoto Jun-ya Kato Tomohiro >>> Fujisaki Filename : draft-ietf-6man-rfc3484-revise-03.txt >>> Pages : 11 Date : 2011-06-10 >>> >>> RFC 3484 describes algorithms for source address selection and for >>> destination address selection. The algorithms specify default >>> behavior for all Internet Protocol version 6 (IPv6) >>> implementations. This document specifies a set of updates that >>> modify the algorithms and fix the known defects. >> >> >> I can't seem to find the discussion that led to this new draft. Could >> you please clarify why 3ffe::/16 was removed from the new policy >> table? > > The use of 3FFE has been deprecated. Right, I understand that, but like Tim pointed out, site-locals were also deprecated and are still in the table. I suspect the 3ffe::/16 traffic is low enough these days not to warrant any entry in the table, but I wanted confirmation on that. Regards, -- Rui Paulo From brian@innovationslab.net Sun Jun 19 06:49:54 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7790011E8097 for ; Sun, 19 Jun 2011 06:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 SkHUdB2tLQHw for ; Sun, 19 Jun 2011 06:49:54 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 06B4611E8072 for ; Sun, 19 Jun 2011 06:49:53 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id AC31A8815E for ; Sun, 19 Jun 2011 06:49:53 -0700 (PDT) Received: from Littlejohn.local (c-76-100-105-215.hsd1.md.comcast.net [76.100.105.215]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 35B831368402 for ; Sun, 19 Jun 2011 06:49:53 -0700 (PDT) Message-ID: <4DFDFE7E.4070104@innovationslab.net> Date: Sun, 19 Jun 2011 09:49:50 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: I-D Action: draft-ietf-6man-rfc3484-revise-03.txt References: <20110610101654.26396.61851.idtracker@ietfa.amsl.com> <4DFB71D3.2090405@innovationslab.net> <8CC75BA6-A86C-4294-AB5B-7B7606B2A0C0@apple.com> In-Reply-To: <8CC75BA6-A86C-4294-AB5B-7B7606B2A0C0@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2011 13:49:54 -0000 On 6/18/11 11:47 AM, Rui Paulo wrote: > On Jun 17, 2011, at 8:25 AM, Brian Haberman wrote: > >> On 6/17/11 11:12 AM, Rui Paulo wrote: >>> Hi, >>> >>> On Jun 10, 2011, at 3:16 AM, internet-drafts@ietf.org wrote: >>> >>>> A New Internet-Draft is available from the on-line >>>> Internet-Drafts directories. This draft is a work item of the >>>> IPv6 Maintenance Working Group of the IETF. >>>> >>>> Title : Update to RFC 3484 Default Address Selection >>>> for IPv6 Author(s) : Arifumi Matsumoto Jun-ya Kato >>>> Tomohiro Fujisaki Filename : >>>> draft-ietf-6man-rfc3484-revise-03.txt Pages : 11 Date >>>> : 2011-06-10 >>>> >>>> RFC 3484 describes algorithms for source address selection and >>>> for destination address selection. The algorithms specify >>>> default behavior for all Internet Protocol version 6 (IPv6) >>>> implementations. This document specifies a set of updates that >>>> modify the algorithms and fix the known defects. >>> >>> >>> I can't seem to find the discussion that led to this new draft. >>> Could you please clarify why 3ffe::/16 was removed from the new >>> policy table? >> >> The use of 3FFE has been deprecated. > > Right, I understand that, but like Tim pointed out, site-locals were > also deprecated and are still in the table. I suspect the 3ffe::/16 > traffic is low enough these days not to warrant any entry in the > table, but I wanted confirmation on that. > > Regards, -- Rui Paulo In my opinion, site-locals should be removed as well. Regards, Brian From jari.arkko@piuha.net Sun Jun 19 12:47:18 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3081F11E8113 for ; Sun, 19 Jun 2011 12:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.424 X-Spam-Level: X-Spam-Status: No, score=-102.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 pq+r7rr1KcuX for ; Sun, 19 Jun 2011 12:47:17 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC8811E8084 for ; Sun, 19 Jun 2011 12:47:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B786A2CC3B; Sun, 19 Jun 2011 22:47:14 +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 FLoN2oqJqfZl; Sun, 19 Jun 2011 22:47:14 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id CF33A2CC2F; Sun, 19 Jun 2011 22:47:13 +0300 (EEST) Message-ID: <4DFE5241.90208@piuha.net> Date: Sun, 19 Jun 2011 22:47:13 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: draft-ietf-6man-flow-ecmp@tools.ietf.org, IETF IPv6 Mailing List Subject: AD review of draft-ietf-6man-flow-ecmp Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2011 19:47:18 -0000 I have reviewed this draft. It is well written, justifies its recommendations and I believe it is ready to move forward. I have asked for an IETF Last Call. However, I did see one editorial issue and one technical issue that I would like you to discuss and correct if necessary (even during the Last Call): > If there is a high > proportion of tunnel traffic, traffic will not be distributed as > intended across the paths between R1 and R2. > ... high proportion of traffic from one or small number of tunnels, traffic will not be ... > * Intermediate IPv6 router(s) will presumably encounter a mixture > of tunneled traffic and normal IPv6 traffic. Because of this, > the design may also include {protocol, dest port, source port} > as input keys to the ECMP and/or LAG hash algorithms, to > provide additional entropy for flows whose flow label is set to > zero, including non-tunneled traffic flows. Whether this is > appropriate depends on the expected traffic mix and on > considerations of implementation efficiency. > Really, I don't think we are constructing routers that could only route tunnel packets. A device such as a router needs to be capable of handling both tunnel and non-tunnel packets. Indeed, the router will in general not even be able to know if it is processing tunnel packets. I would recommend changing the above "may also include" to "should also include", and striking the last sentence. Jari From brian.e.carpenter@gmail.com Sun Jun 19 12:49:11 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C976711E8084 for ; Sun, 19 Jun 2011 12:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.431 X-Spam-Level: X-Spam-Status: No, score=-103.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 8AIIUHXiOEe7 for ; Sun, 19 Jun 2011 12:49:10 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id D2B5B11E811E for ; Sun, 19 Jun 2011 12:49:09 -0700 (PDT) Received: by fxm15 with SMTP id 15so817055fxm.31 for ; Sun, 19 Jun 2011 12:49:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=BwKqQFkQdTvE7jfxnlf7D3Ft7BJS+g5xWgFnF7Hhl1w=; b=ZMLCzqBl5AE6r06ImxgJLmieABIWVXPLR44hcI4ayC+rdi4sMCMQ7x/X/unlh0ILTE g2Z0+xJxgp56NA7z9AXlLj5R2rlrMHr6qawj6ShXxQ5HaKwIx6CTDmNYjznxYV2mVjmv 0LIu10G3Cdd3zCYW5cvnqjbJOWAmzGGLM+rX0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; b=mZZGXBJhEuNQMeM4TrsqlK40MPOdE+XcUbmhfL5Y/QSMqOiOgKlWrcde1EZaJNk0gh 3NTzV6T6oYhywAuk7FseICRdtJDgtgz/0TWjRjByqSxs/ilN3hmKLNX6I+6BR+c32hDZ 37Wpbb0zXKu7yQi9lU9pR+g22/hQAFQQQvFkw= Received: by 10.223.73.139 with SMTP id q11mr4971501faj.56.1308512944344; Sun, 19 Jun 2011 12:49:04 -0700 (PDT) Received: from [10.255.25.96] (74-95-74-1-Indianapolis.hfc.comcastbusiness.net [74.95.74.1]) by mx.google.com with ESMTPS id g8sm2412033fai.20.2011.06.19.12.49.00 (version=SSLv3 cipher=OTHER); Sun, 19 Jun 2011 12:49:02 -0700 (PDT) Message-ID: <4DFE52A4.2040207@gmail.com> Date: Mon, 20 Jun 2011 07:48:52 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 6man Subject: Re: Preliminary report on flow label hash algorithms References: <4DE5CA6F.6080803@gmail.com> In-Reply-To: <4DE5CA6F.6080803@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2011 19:49:11 -0000 A small update on this: 1. David Malone found a bug in my C code, which changes the conclusion. Of the algorithms I tried, the one designated #2 apparently performs best of the three, once the bug is fixed. I can't complete the tests and post an updated report until mid-July, due to travel. 2. From the feedback I've received, it's clear that there is great scope for experimenting with various algorithms to find the best one. Assuming we leave an example algorithm in the draft, the text needs to make this clear. We can wait for the Area Director's review before deciding what to do about this. Regards Brian On 2011-06-01 17:13, Brian E Carpenter wrote: > In summary: the algorithm suggested in the Appendix to > draft-ietf-6man-flow-3697bis-04 doesn't perform very well > on real packets, and I have an improved version to suggest. > > This doesn't affect the normative text in the draft, so I > believe it can be fixed. > > The full story, with fonts, tables and pictures: > > http://www.cs.auckland.ac.nz/~brian/flowhash.html > From brian.e.carpenter@gmail.com Sun Jun 19 15:34:23 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D90229E800C for ; Sun, 19 Jun 2011 15:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.442 X-Spam-Level: X-Spam-Status: No, score=-103.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 7jXbTv6C8qZ9 for ; Sun, 19 Jun 2011 15:34:23 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9AB9E8008 for ; Sun, 19 Jun 2011 15:34:22 -0700 (PDT) Received: by fxm15 with SMTP id 15so860652fxm.31 for ; Sun, 19 Jun 2011 15:34:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=XO3w7Uf0/HvZAbj0Sc9t78QRn/iGL2Aaodm35QLXEWA=; b=q7CMeYEybgIrqQodixcPU2kNvcy+wyQHcqNWeA8MiHeoH7UUeXv7z/L79vLDlypsbU lL3m14qZb1Wt5gFCjr4HaUx95NdomnAoztZdCEV4N6JuWMc7nLEBvBW+zKquL/Jg3lHv 1bO0a5CTP8EEDLdxE2p2uQlT5WdJJUsHGPo9Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=HOKLN0WaSDbiz79gMEJo/gBwkCLFl1fzGQDMQOhcyYDILC4AT7Eijl5+TNw1UEuyoJ MI8Lx4zXfxHsbgK0JRwOX9WNZMGFS3XAqbu/PlOuIg+ntk/mvk0v3fgqbMIVnvBCvPli 8oYFgCjsYO1rnsolq9G1/fsQZDQEcL8+DfY0U= Received: by 10.223.13.211 with SMTP id d19mr1936013faa.67.1308522862261; Sun, 19 Jun 2011 15:34:22 -0700 (PDT) Received: from [10.255.25.96] (74-95-74-1-Indianapolis.hfc.comcastbusiness.net [74.95.74.1]) by mx.google.com with ESMTPS id h1sm2468856fag.35.2011.06.19.15.34.16 (version=SSLv3 cipher=OTHER); Sun, 19 Jun 2011 15:34:21 -0700 (PDT) Message-ID: <4DFE793B.4060006@gmail.com> Date: Mon, 20 Jun 2011 10:33:31 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jari Arkko Subject: Re: AD review of draft-ietf-6man-flow-ecmp References: <4DFE5241.90208@piuha.net> In-Reply-To: <4DFE5241.90208@piuha.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF IPv6 Mailing List , draft-ietf-6man-flow-ecmp@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2011 22:34:24 -0000 Hi Jari, Thanks for the review. On 2011-06-20 07:47, Jari Arkko wrote: > I have reviewed this draft. It is well written, justifies its > recommendations and I believe it is ready to move forward. I have asked > for an IETF Last Call. However, I did see one editorial issue and one > technical issue that I would like you to discuss and correct if > necessary (even during the Last Call): > >> If there is a high >> proportion of tunnel traffic, traffic will not be distributed as >> intended across the paths between R1 and R2. >> > > ... high proportion of traffic from one or small number of tunnels, > traffic will not be ... OK > >> * Intermediate IPv6 router(s) will presumably encounter a mixture >> of tunneled traffic and normal IPv6 traffic. Because of this, >> the design may also include {protocol, dest port, source port} >> as input keys to the ECMP and/or LAG hash algorithms, to >> provide additional entropy for flows whose flow label is set to >> zero, including non-tunneled traffic flows. Whether this is >> appropriate depends on the expected traffic mix and on >> considerations of implementation efficiency. >> > > Really, I don't think we are constructing routers that could only route > tunnel packets. A device such as a router needs to be capable of > handling both tunnel and non-tunnel packets. Indeed, the router will in > general not even be able to know if it is processing tunnel packets. I > would recommend changing the above "may also include" to "should also > include", and striking the last sentence. Personally, I think you're right. Should that be a normative SHOULD? We have a small handful of other minor edits that have come in since WGLC. Do you want us to post a new version? Brian From arifumi@nttv6.net Sun Jun 19 19:19:03 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4D2011E8089 for ; Sun, 19 Jun 2011 19:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 wr3tOzaWxjP8 for ; Sun, 19 Jun 2011 19:19:03 -0700 (PDT) Received: from leo.nttv6.net (leo.nttv6.net [192.47.162.93]) by ietfa.amsl.com (Postfix) with ESMTP id F124511E8081 for ; Sun, 19 Jun 2011 19:19:02 -0700 (PDT) Received: from [IPv6:::1] (localhost.nttv6.net [127.0.0.1]) by leo.nttv6.net (8.14.4/8.14.4) with ESMTP id p5K2Eb33010462; Mon, 20 Jun 2011 11:14:37 +0900 (JST) (envelope-from arifumi@nttv6.net) Subject: Re: I-D Action: draft-ietf-6man-rfc3484-revise-03.txt Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Arifumi Matsumoto In-Reply-To: Date: Mon, 20 Jun 2011 11:15:08 +0900 Content-Transfer-Encoding: 7bit Message-Id: <03150EC4-9C90-4789-BB7A-474FF28C5FC9@nttv6.net> References: <20110610101654.26396.61851.idtracker@ietfa.amsl.com> <4DFB71D3.2090405@innovationslab.net> <582E33EF-5DCD-414E-872A-F457431D0901@ecs.soton.ac.uk> To: Tim Chown X-Mailer: Apple Mail (2.1084) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 02:19:03 -0000 Hi, thank you for your comment. I cannot find it soon, but we had discussion about the deprecated prefixes before. There, it was pointed out that 3ffe::/16 was deprecated and now it is just treated as normal global unicast address. So, preserving 3ffe::/16 in the table will bring troubles in future. Regarding site-local prefix, it is still reserved by IETF. So, it was not removed from the table. Please correct me if I'm wrong. Kindest regards, On 2011/06/18, at 0:56, Tim Chown wrote: > > On 17 Jun 2011, at 16:25, Brian Haberman wrote: > >> On 6/17/11 11:12 AM, Rui Paulo wrote: >>> Hi, >>> >>> On Jun 10, 2011, at 3:16 AM, internet-drafts@ietf.org wrote: >>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. This draft is a work item of the IPv6 Maintenance >>>> Working Group of the IETF. >>>> >>>> Title : Update to RFC 3484 Default Address Selection for >>>> IPv6 Author(s) : Arifumi Matsumoto Jun-ya Kato Tomohiro >>>> Fujisaki Filename : draft-ietf-6man-rfc3484-revise-03.txt >>>> Pages : 11 Date : 2011-06-10 >>>> >>>> RFC 3484 describes algorithms for source address selection and for >>>> destination address selection. The algorithms specify default >>>> behavior for all Internet Protocol version 6 (IPv6) >>>> implementations. This document specifies a set of updates that >>>> modify the algorithms and fix the known defects. >>> >>> >>> I can't seem to find the discussion that led to this new draft. Could >>> you please clarify why 3ffe::/16 was removed from the new policy >>> table? >> >> The use of 3FFE has been deprecated. > > Should we also remove site-locals then, or IPv4-compatibles? > > Tim > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Arifumi Matsumoto NGN System Architecture Project NTT Service Integration Laboratories E-mail: arifumi@nttv6.net TEL +81-422-59-3334 FAX +81-422-59-6364 From jari.arkko@piuha.net Sun Jun 19 21:22:58 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED97921F84BA for ; Sun, 19 Jun 2011 21:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.429 X-Spam-Level: X-Spam-Status: No, score=-102.429 tagged_above=-999 required=5 tests=[AWL=0.170, 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 PUHgNQ6DEq9i for ; Sun, 19 Jun 2011 21:22:58 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9E121F84A0 for ; Sun, 19 Jun 2011 21:22:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id EE76B2CC49; Mon, 20 Jun 2011 07:22:56 +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 3E8vyVq7Oo34; Mon, 20 Jun 2011 07:22:56 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 30A502CC2F; Mon, 20 Jun 2011 07:22:55 +0300 (EEST) Message-ID: <4DFECB1D.9090504@piuha.net> Date: Mon, 20 Jun 2011 07:22:53 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: AD review of draft-ietf-6man-flow-ecmp References: <4DFE5241.90208@piuha.net> <4DFE793B.4060006@gmail.com> In-Reply-To: <4DFE793B.4060006@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPv6 Mailing List , draft-ietf-6man-flow-ecmp@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 04:22:59 -0000 Brian, > Personally, I think you're right. Should that be a normative SHOULD? > You were not using RFC 2119 language in this paragraph earlier either, so I don't think it is needed. > We have a small handful of other minor edits that have come in since WGLC. > Do you want us to post a new version? > Please do. Jari From jari.arkko@piuha.net Sun Jun 19 22:12:36 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA8B11E80F1 for ; Sun, 19 Jun 2011 22:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.433 X-Spam-Level: X-Spam-Status: No, score=-102.433 tagged_above=-999 required=5 tests=[AWL=0.166, 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 8GIns7+B3WkO for ; Sun, 19 Jun 2011 22:12:36 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id CC43511E807B for ; Sun, 19 Jun 2011 22:12:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id CE6102CC49; Mon, 20 Jun 2011 08:12:33 +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 d0Pa1ctbUSTf; Mon, 20 Jun 2011 08:12:32 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id D05FC2CC2F; Mon, 20 Jun 2011 08:12:32 +0300 (EEST) Message-ID: <4DFED6BF.6080003@piuha.net> Date: Mon, 20 Jun 2011 08:12:31 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: draft-ietf-6man-flow-update@tools.ietf.org, IETF IPv6 Mailing List Subject: AD review of draft-ietf-6man-flow-update Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 05:12:36 -0000 I have reviewed this specification. It is well written and ready to move forward; I have asked for an IETF Last Call. I did have two very minor editorial comments, and one personal opinion: > In this case too, the word > "alone" is to be interpreted precisely - a router is allowed to > combine the flow label value with other data in order to produce a > uniformly distributed hash. > I think this would be simpler if you had just said "But the word "alone" needs to be taken into account - a router is allowed ..." (There is nothing precise or imprecise about this. You just can't bypass the key word from the rule.) > The main novelty is that a forwarding node (typically a first-hop or > ingress router) may set the flow label value if the source has not > done so, according to the same recommendations that apply to the > source. This might place a considerable processing load on ingress > routers, even if they adopted a stateless method of flow > identification and label assignment. > I'd prefer to replace the second sentence with "This might place a considerable processing load on ingress routers that choose to do so, even ..." Finally, the personal opinion was that I'd probably have left four bits from the flow label as reserved values (set to zero on send; included as flow label bits for all other processing). I'm not asking you to change the approach or the draft, just stating that I would have left some room for future developments. Jari From brian.e.carpenter@gmail.com Mon Jun 20 06:01:40 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D6311E8192 for ; Mon, 20 Jun 2011 06:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.452 X-Spam-Level: X-Spam-Status: No, score=-103.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 pN058kBlrQXg for ; Mon, 20 Jun 2011 06:01:40 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id CC2871F0C4A for ; Mon, 20 Jun 2011 06:01:35 -0700 (PDT) Received: by fxm15 with SMTP id 15so1241217fxm.31 for ; Mon, 20 Jun 2011 06:01:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=uegr0O6kXp/uUnlPLMZBKUOs6ExXsAANZ3EvMKdjtSc=; b=HvqgbzFw17fCAgIo9zXm8BZgMrJXAHu992LULV6I7/ECla0N1Kxmkk5+TU1wKsIaV5 CSB80siTcd3/1osUQaBJyk7J9FCdy78g5MpWhV6uLW9OrcHemY0iw4rBN3l3DNAzV6up jQAq3brVms2hZXgm/Xwd2gUejYZVIXs8wIke8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=a6cmQd9Q1w3HmrPrVXY0r6JmZI59RZopcZzxMIFnjOct6d30qa2z90uXhKiGwnHeVS rxoAwbW+FkAknFpE2gcERw7G6AshSVjLWBxmPjlR1I4fyqMtr1fb7MhBtc0aht57kGVI xgWBkD/+m3KS7UTEdTvYwQCyANf5HewyEjjdU= Received: by 10.223.83.194 with SMTP id g2mr282354fal.133.1308574894925; Mon, 20 Jun 2011 06:01:34 -0700 (PDT) Received: from [10.255.25.96] (74-95-74-1-Indianapolis.hfc.comcastbusiness.net [74.95.74.1]) by mx.google.com with ESMTPS id 10sm1276348faw.0.2011.06.20.06.01.32 (version=SSLv3 cipher=OTHER); Mon, 20 Jun 2011 06:01:33 -0700 (PDT) Message-ID: <4DFF44A6.4020309@gmail.com> Date: Tue, 21 Jun 2011 01:01:26 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jari Arkko Subject: Re: AD review of draft-ietf-6man-flow-update References: <4DFED6BF.6080003@piuha.net> In-Reply-To: <4DFED6BF.6080003@piuha.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF IPv6 Mailing List , draft-ietf-6man-flow-update@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 13:01:40 -0000 Jari, No problem with your editorial comments - they are small enough that I suggest holding them until after the LC. > four bits from the flow label as reserved values There was a pretty clear consensus against having any special bits, when this sort of idea was discussed last year. Thanks Brian On 2011-06-20 17:12, Jari Arkko wrote: > I have reviewed this specification. It is well written and ready to move > forward; I have asked for an IETF Last Call. > > I did have two very minor editorial comments, and one personal opinion: > >> In this case too, the word >> "alone" is to be interpreted precisely - a router is allowed to >> combine the flow label value with other data in order to produce a >> uniformly distributed hash. >> > > I think this would be simpler if you had just said "But the word "alone" > needs to be taken into account - a router is allowed ..." > > (There is nothing precise or imprecise about this. You just can't bypass > the key word from the rule.) > >> The main novelty is that a forwarding node (typically a first-hop or >> ingress router) may set the flow label value if the source has not >> done so, according to the same recommendations that apply to the >> source. This might place a considerable processing load on ingress >> routers, even if they adopted a stateless method of flow >> identification and label assignment. >> > > I'd prefer to replace the second sentence with "This might place a > considerable processing load on ingress routers that choose to do so, > even ..." > > Finally, the personal opinion was that I'd probably have left four bits > from the flow label as reserved values (set to zero on send; included as > flow label bits for all other processing). I'm not asking you to change > the approach or the draft, just stating that I would have left some room > for future developments. > > Jari > > From internet-drafts@ietf.org Mon Jun 20 06:33:57 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F31411E8162; Mon, 20 Jun 2011 06:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 uXWFu4z9Vu-E; Mon, 20 Jun 2011 06:33:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E929111E80AC; Mon, 20 Jun 2011 06:33:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-dad-proxy-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110620133356.8824.57596.idtracker@ietfa.amsl.com> Date: Mon, 20 Jun 2011 06:33:56 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 13:33:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the= IETF. Title : Duplicate Address Detection Proxy Author(s) : Fabio Costa Jean-Michel Combes Xavier Pougnard Hongyu Li Filename : draft-ietf-6man-dad-proxy-01.txt Pages : 13 Date : 2011-06-20 The document describes a mechanism allowing the use of Duplicate Address Detection (DAD) by IPv6 nodes in a point-to-multipoint architecture with "split-horizon" forwarding scheme. Based on= the DAD signalling, the first hop router stores in a Binding Table all known IPv6 addresses used on a point-to-multipoint domain (e.g. VLAN). When a node performs DAD for an address already used by another node, the first hop router replies instead of this last one. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-dad-proxy-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-dad-proxy-01.txt From internet-drafts@ietf.org Mon Jun 20 06:54:32 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0DE11E8165; Mon, 20 Jun 2011 06:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 Dna6GeG+4WXH; Mon, 20 Jun 2011 06:54:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1470211E80A6; Mon, 20 Jun 2011 06:54:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-flow-ecmp-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110620135432.14747.90501.idtracker@ietfa.amsl.com> Date: Mon, 20 Jun 2011 06:54:32 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 13:54:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the= IETF. Title : Using the IPv6 flow label for equal cost multipath routi= ng and link aggregation in tunnels Author(s) : Brian Carpenter Shane Amante Filename : draft-ietf-6man-flow-ecmp-03.txt Pages : 10 Date : 2011-06-20 The IPv6 flow label has certain restrictions on its use. This document describes how those restrictions apply when using the flow label for load balancing by equal cost multipath routing, and for link aggregation, particularly for IP-in-IPv6 tunneled traffic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-ecmp-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-flow-ecmp-03.txt From brian.e.carpenter@gmail.com Mon Jun 20 06:56:13 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3AE11E8094 for ; Mon, 20 Jun 2011 06:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.461 X-Spam-Level: X-Spam-Status: No, score=-103.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 jHVH7Po0Ekfd for ; Mon, 20 Jun 2011 06:56:07 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id A62CA11E818D for ; Mon, 20 Jun 2011 06:56:03 -0700 (PDT) Received: by fxm15 with SMTP id 15so1287372fxm.31 for ; Mon, 20 Jun 2011 06:56:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:subject:content-type:content-transfer-encoding; bh=3yvTW63jkN7yVqDCOtjf/Xu1Q7zLmuXIpfYM98t8xzM=; b=E9A6Is2o9r66uouvlFPJuAkpw1hy/b26wyvIVnSXDWt4cEsmjblD8I5LaZ1HMQVUpB Ck92n1JMSG670+p5iPa1df5Yv+KngpuevMmCpDn0b5+sRL5QO/+HyhP+pHrdXgxsFrFn wVZyERV/NbQmKcLfAXw2OKdRE+cT9cCiAAGKc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; b=bMaIswohB5DwvdlUcS5ieN2IYllUWZLYldssB6uElzrzTMxu5GBGENAAS/AZspxlSK 5hvNpPAkxXm2UiDDjZDNcaAZFUiBWXtZGLOR7zT/BUJ1aen4YVDWrLJa6XTEI5BFNI5+ D2YbkisQpI6iAwA4vWKNkFLbl8eTMWe7i4rcs= Received: by 10.223.41.89 with SMTP id n25mr3900617fae.7.1308578162758; Mon, 20 Jun 2011 06:56:02 -0700 (PDT) Received: from [10.255.25.96] (74-95-74-1-Indianapolis.hfc.comcastbusiness.net [74.95.74.1]) by mx.google.com with ESMTPS id 11sm2832949fax.36.2011.06.20.06.56.01 (version=SSLv3 cipher=OTHER); Mon, 20 Jun 2011 06:56:02 -0700 (PDT) Message-ID: <4DFF5167.4020700@gmail.com> Date: Tue, 21 Jun 2011 01:55:51 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 6man Subject: [Fwd: New Version Notification for draft-ietf-6man-flow-ecmp-03.txt] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 13:56:13 -0000 This version reflects the AD's comments and some minor editorial fixes. Regards Brian Carpenter -------- Original Message -------- Subject: New Version Notification for draft-ietf-6man-flow-ecmp-03.txt Date: Mon, 20 Jun 2011 06:54:32 -0700 From: internet-drafts@ietf.org To: brian.e.carpenter@gmail.com CC: brian.e.carpenter@gmail.com, shane@level3.net A new version of I-D, draft-ietf-6man-flow-ecmp-03.txt has been successfully submitted by Brian Carpenter and posted to the IETF repository. Filename: draft-ietf-6man-flow-ecmp Revision: 03 Title: Using the IPv6 flow label for equal cost multipath routing and link aggregation in tunnels Creation date: 2011-06-20 WG ID: 6man Number of pages: 10 Abstract: The IPv6 flow label has certain restrictions on its use. This document describes how those restrictions apply when using the flow label for load balancing by equal cost multipath routing, and for link aggregation, particularly for IP-in-IPv6 tunneled traffic. The IETF Secretariat From iesg-secretary@ietf.org Mon Jun 20 08:06:53 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EEF121F851B; Mon, 20 Jun 2011 08:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.435 X-Spam-Level: X-Spam-Status: No, score=-102.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 R-6H1rTOTNPG; Mon, 20 Jun 2011 08:06:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD59E21F850E; Mon, 20 Jun 2011 08:06:52 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Last Call: (Using the IPv6 flow label for equal cost multipath routing and link aggregation in tunnels) to BCP X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110620150652.14751.35003.idtracker@ietfa.amsl.com> Date: Mon, 20 Jun 2011 08:06:52 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 15:06:53 -0000 The IESG has received a request from the IPv6 Maintenance WG (6man) to consider the following document: - 'Using the IPv6 flow label for equal cost multipath routing and link aggregation in tunnels' as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-07-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The IPv6 flow label has certain restrictions on its use. This document describes how those restrictions apply when using the flow label for load balancing by equal cost multipath routing, and for link aggregation, particularly for IP-in-IPv6 tunneled traffic. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-6man-flow-ecmp/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-6man-flow-ecmp/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Mon Jun 20 08:07:35 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8A721F853A; Mon, 20 Jun 2011 08:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=0.157, 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 HGLq6gPvaTHi; Mon, 20 Jun 2011 08:07:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A55521F8511; Mon, 20 Jun 2011 08:07:34 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Last Call: (Rationale for update to the IPv6 flow label specification) to Informational RFC X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110620150734.22344.56344.idtracker@ietfa.amsl.com> Date: Mon, 20 Jun 2011 08:07:34 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 15:07:35 -0000 The IESG has received a request from the IPv6 Maintenance WG (6man) to consider the following document: - 'Rationale for update to the IPv6 flow label specification' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-07-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Various published proposals for use of the IPv6 flow label are incompatible with its original specification in RFC 3697. Furthermore, very little practical use is made of the flow label, partly due to some uncertainties about the correct interpretation of the specification. This document discusses and motivates changes to the specification in order to clarify it, and to introduce some additional flexibility. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-6man-flow-update/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-6man-flow-update/ No IPR declarations have been submitted directly on this I-D. From jari.arkko@piuha.net Mon Jun 20 09:09:19 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C61C1F0C4C for ; Mon, 20 Jun 2011 09:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 du9NLXUhYAQ5 for ; Mon, 20 Jun 2011 09:09:18 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id AD36F1F0C45 for ; Mon, 20 Jun 2011 09:09:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id DFBE12CC39; Mon, 20 Jun 2011 19:09:09 +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 d+2aztxZw1xh; Mon, 20 Jun 2011 19:09:09 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id E12142CC2F; Mon, 20 Jun 2011 19:09:08 +0300 (EEST) Message-ID: <4DFF70A4.7040807@piuha.net> Date: Mon, 20 Jun 2011 19:09:08 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: draft-ietf-6man-flow-3697bis@tools.ietf.org, IETF IPv6 Mailing List Subject: AD review of draft-ietf-6man-flow-3697bis Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 16:09:19 -0000 I have reviewed this draft. I think it is in good shape and can move forward once we resolve one issue. Here's the issue: > A node that forwards a flow whose flow label value in arriving > packets is zero MAY change the flow label value. In that case, it is > RECOMMENDED that the forwarding node sets the flow label field for a > flow to a uniformly distributed value as just described for source > nodes. > o The same considerations apply as to source hosts setting the flow > label; in particular, the normal case is that a flow is defined by > the 5-tuple. > o This option, if implemented, would presumably be used by first-hop > or ingress routers. It might place a considerable per-packet > processing load on them, even if they adopted a stateless method > of flow identification and label assignment. This is why the > principal recommendation is that the source host should set the > label. > I think this recommendation is problematic. I agree that the first hop router should insert the flow label, but requiring it to do fragment reassembly in order to find the 5-tuple is a big burden, and I'm not sure its even called for. The RFC 2119 language above is fine. But I'd like to change the part about normal case being the 5-tuple. I think the normal case should be the 2-tuple under these circumstances. The source has access to the 5-tuple; a router is not guaranteed to have access to it. In addition, I'm not sure I understand how a router knows that it is a first hop router. Are there cases where a device might mistakenly believe it is a first hop router at a point where the traffic has already been load-balanced to multiple routers? Are there situations where the multiple first hop routers are used from the same host? The document should provide some guidance about operational conditions where the recommendations for the first hop router can be applied. The document should state how such functionality is turned on (per configuration? automatically?) and provide assurances that problematic conditions can be avoided. Jari From jari.arkko@piuha.net Mon Jun 20 11:14:34 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 934BC11E81BC for ; Mon, 20 Jun 2011 11:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.44 X-Spam-Level: X-Spam-Status: No, score=-102.44 tagged_above=-999 required=5 tests=[AWL=0.159, 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 oTOMzny2A111 for ; Mon, 20 Jun 2011 11:14:34 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC4B11E808E for ; Mon, 20 Jun 2011 11:14:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 75F092CC39; Mon, 20 Jun 2011 21:14:30 +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 nErOs94yoJoJ; Mon, 20 Jun 2011 21:14:30 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id DCE582CC2F; Mon, 20 Jun 2011 21:14:29 +0300 (EEST) Message-ID: <4DFF8E05.3000702@piuha.net> Date: Mon, 20 Jun 2011 21:14:29 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: AD review of draft-ietf-6man-flow-update References: <4DFED6BF.6080003@piuha.net> <4DFF44A6.4020309@gmail.com> In-Reply-To: <4DFF44A6.4020309@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPv6 Mailing List , draft-ietf-6man-flow-update@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 18:14:34 -0000 Brian, >> four bits from the flow label as reserved values >> > > There was a pretty clear consensus against having any special bits, when > this sort of idea was discussed last year. > Ok. Was there a rationale, e.g., that it would be impossible to do so for some reason, or that the bits could not be used? Jari From brian.e.carpenter@gmail.com Mon Jun 20 14:53:12 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CAF811E80AF for ; Mon, 20 Jun 2011 14:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.468 X-Spam-Level: X-Spam-Status: No, score=-103.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 Sd+gOBEiTkys for ; Mon, 20 Jun 2011 14:53:11 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABD411E808E for ; Mon, 20 Jun 2011 14:53:11 -0700 (PDT) Received: by fxm15 with SMTP id 15so1611612fxm.31 for ; Mon, 20 Jun 2011 14:53:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=nuIRy4GwaPOPdy3fcH3aw7CJIxbGKfmMCaCBiRF7L9A=; b=mnAwiiowUqe3pEQK/lwJTbGOiDgRoBokdTLuHVgmV81VgfClDXa/KSg5sNwbG2UuOI MUT3H30FS0gNHyTkCYGqrFrv/lh+PYUwnEGLAPjkSc6XvAMUeE8yIk+ZE9uCeUCYy25G 1zfrPqvTPjJ/ADv8po6vmj7IGVgE/bvQG35yE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=Rwtof3t2mvTbLCqCj7Z/elNCLT2SUMgfbmXnNLJLajZUftXqQuklo2Ab9vv3YHJh0/ 3J9bc5qU7Oko41T/OWiTTEJ+g1TdeXS6JG7U1hAFmZodm4jG+PxggxnyjzFRkPjRPvZz xDNe+TOtUllw/rpf/C7h+ebB37pQkY+uj5SEw= Received: by 10.223.87.3 with SMTP id u3mr2305109fal.13.1308606790369; Mon, 20 Jun 2011 14:53:10 -0700 (PDT) Received: from [10.255.25.96] (74-95-74-1-Indianapolis.hfc.comcastbusiness.net [74.95.74.1]) by mx.google.com with ESMTPS id n13sm3045197fab.46.2011.06.20.14.53.08 (version=SSLv3 cipher=OTHER); Mon, 20 Jun 2011 14:53:09 -0700 (PDT) Message-ID: <4DFFC13F.7020001@gmail.com> Date: Tue, 21 Jun 2011 09:53:03 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jari Arkko Subject: Re: AD review of draft-ietf-6man-flow-update References: <4DFED6BF.6080003@piuha.net> <4DFF44A6.4020309@gmail.com> <4DFF8E05.3000702@piuha.net> In-Reply-To: <4DFF8E05.3000702@piuha.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF IPv6 Mailing List , draft-ietf-6man-flow-update@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 21:53:12 -0000 On 2011-06-21 06:14, Jari Arkko wrote: > Brian, > >>> four bits from the flow label as reserved values >> >> There was a pretty clear consensus against having any special bits, when >> this sort of idea was discussed last year. >> > > Ok. Was there a rationale, e.g., that it would be impossible to do so > for some reason, or that the bits could not be used? I'd have to trawl the archive to find all the arguments, but the main issue was that any attempt to include semantics in the bits of the flow label leads to complexity that probably can't be handled at line speed in a scaleable way. Also 16 bits might make it too easy for a malicious party to predict flow label values. Brian From brian.e.carpenter@gmail.com Mon Jun 20 15:20:52 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C8011E8158 for ; Mon, 20 Jun 2011 15:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.475 X-Spam-Level: X-Spam-Status: No, score=-103.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 BONToGe93xcW for ; Mon, 20 Jun 2011 15:20:51 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF3D11E8159 for ; Mon, 20 Jun 2011 15:20:51 -0700 (PDT) Received: by fxm15 with SMTP id 15so1625740fxm.31 for ; Mon, 20 Jun 2011 15:20:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=+tg/2AljHZS4SzcOBC+mGINqlPigxQNr44k4Yf0suuI=; b=WPzxqAlp3zLYICISv5FvydytlfvuZSytCiMx0rgI+aBVXq8XtdlH7jse2NeDMk45vS 2CsTPV03hQiiP0442IXlf0AVo+9/1n4mwef7/uXGgR3VUXwOqjURB72VnWPAPgRr/XHB +flRVlFCAykkKzyTlByVGjr+AjKsXJmB2XdSo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=nQsesAcwbFIA030N3LKz4LXMVPHTOHcGWbIm71b7WZdenCMmlVUpx37cip+fFWZuHe 2L7ulIJ59JuAxfc8bB3YeSNaZUELo1vVBoIQH7AkqBFnO570TobwYQXtLQQjAZK/eelI vhS3GpAOyQT3ayQcsDeYnqJO0X0d1wsOKyXGs= Received: by 10.223.6.201 with SMTP id a9mr2896063faa.110.1308608450633; Mon, 20 Jun 2011 15:20:50 -0700 (PDT) Received: from [10.255.25.96] (74-95-74-1-Indianapolis.hfc.comcastbusiness.net [74.95.74.1]) by mx.google.com with ESMTPS id f3sm459608faa.30.2011.06.20.15.20.48 (version=SSLv3 cipher=OTHER); Mon, 20 Jun 2011 15:20:50 -0700 (PDT) Message-ID: <4DFFC7BC.7090603@gmail.com> Date: Tue, 21 Jun 2011 10:20:44 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jari Arkko Subject: Re: AD review of draft-ietf-6man-flow-3697bis References: <4DFF70A4.7040807@piuha.net> In-Reply-To: <4DFF70A4.7040807@piuha.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF IPv6 Mailing List , draft-ietf-6man-flow-3697bis@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 22:20:52 -0000 Jari, Thanks for the review. On 2011-06-21 04:09, Jari Arkko wrote: > I have reviewed this draft. > > I think it is in good shape and can move forward once we resolve one > issue. Here's the issue: > >> A node that forwards a flow whose flow label value in arriving >> packets is zero MAY change the flow label value. In that case, it is >> RECOMMENDED that the forwarding node sets the flow label field for a >> flow to a uniformly distributed value as just described for source >> nodes. >> o The same considerations apply as to source hosts setting the flow >> label; in particular, the normal case is that a flow is defined by >> the 5-tuple. >> o This option, if implemented, would presumably be used by first-hop >> or ingress routers. It might place a considerable per-packet >> processing load on them, even if they adopted a stateless method >> of flow identification and label assignment. This is why the >> principal recommendation is that the source host should set the >> label. >> > I think this recommendation is problematic. I agree that the first hop > router should insert the flow label, but requiring it to do fragment > reassembly in order to find the 5-tuple is a big burden, and I'm not > sure its even called for. Yes, this is an embarassingly good catch. I think we need to add some language to the recommendation that source hosts SHOULD set their own flow labels, pointing out that in a fragmented case this is the only way to do things properly. Reverting to the 2-tuple is a serious penalty since a lot of the entropy in headers is in one of the port numbers. > The RFC 2119 language above is fine. But I'd like to change the part > about normal case being the 5-tuple. I think the normal case should be > the 2-tuple under these circumstances. The source has access to the > 5-tuple; a router is not guaranteed to have access to it. As far as routers go, I think we have to say that an implementor has to choose between a reassembly-based solution using the 5-tuple and simply using the 2-tuple (maybe also the fragmentation ID - there is some scope for ingenuity here). > In addition, I'm not sure I understand how a router knows that it is a > first hop router. Are there cases where a device might mistakenly > believe it is a first hop router at a point where the traffic has > already been load-balanced to multiple routers? It's surely a configuration issue - enable flow labelling should be configurable. Otherwise we have to be far too clever, as your following points show. > Are there situations > where the multiple first hop routers are used from the same host? The > document should provide some guidance about operational conditions where > the recommendations for the first hop router can be applied. The > document should state how such functionality is turned on (per > configuration? automatically?) and provide assurances that problematic > conditions can be avoided. I'd like to hear from my co-authors and the WG before producing a new version. Brian From bob.hinden@gmail.com Mon Jun 20 16:31:38 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 027AF11E81D3 for ; Mon, 20 Jun 2011 16:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.932 X-Spam-Level: X-Spam-Status: No, score=-103.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 tUFTaozh8tdT for ; Mon, 20 Jun 2011 16:31:37 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6BAEB11E80B5 for ; Mon, 20 Jun 2011 16:31:37 -0700 (PDT) Received: by pvh18 with SMTP id 18so4407485pvh.31 for ; Mon, 20 Jun 2011 16:31:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=WDvgHw+n0MbkMXQf088tu/EORW4aTViykaevGNfx9pw=; b=T8xF+JdJcxOzH1XSMzXQu2DGqhjD7uEUQcTQRm8Dr/Od4kjcGhrRIJqx4f76H0GcS2 t0sKRtRSp5ocWQ8684at9TrnKVK00jHcmoYVg6RDrdta+wX+CPLQ7Dz1xU8nhN/fm/j6 Cf856sRMMf+Amm6ap1LmNC7VTXfAGjSxMxPpU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=i0GIxYwNTFWJrcR17el7NqH2f2TPTkF29+t8+5PEE73GQeiF66Q+lDxIAX2d521caK y4Ah3TxtoPHVfT5L7V4viBq/bhqt9XUBLOnN5UxJgoOlyCM0l55fPcYL6lLD4w27c2jW 9LyZAVgfjphUSIvZJe7SPlfj61C+tPlz/h/fA= Received: by 10.143.60.5 with SMTP id n5mr882396wfk.434.1308612696811; Mon, 20 Jun 2011 16:31:36 -0700 (PDT) Received: from [172.16.224.217] ([209.97.127.34]) by mx.google.com with ESMTPS id w24sm6719030wfd.5.2011.06.20.16.31.35 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Jun 2011 16:31:35 -0700 (PDT) Subject: Re: AD review of draft-ietf-6man-flow-3697bis Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: <4DFF70A4.7040807@piuha.net> Date: Mon, 20 Jun 2011 16:31:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <71658E03-69C0-4160-BFF7-2AC6F7F5861C@gmail.com> References: <4DFF70A4.7040807@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-6man-flow-3697bis@tools.ietf.org, Bob Hinden , IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 23:31:38 -0000 Jari, On Jun 20, 2011, at 9:09 AM, Jari Arkko wrote: > I have reviewed this draft. >=20 > I think it is in good shape and can move forward once we resolve one = issue. Here's the issue: >=20 >> A node that forwards a flow whose flow label value in arriving >> packets is zero MAY change the flow label value. In that case, it is >> RECOMMENDED that the forwarding node sets the flow label field for a >> flow to a uniformly distributed value as just described for source >> nodes. >> o The same considerations apply as to source hosts setting the flow >> label; in particular, the normal case is that a flow is defined by >> the 5-tuple. >> o This option, if implemented, would presumably be used by first-hop >> or ingress routers. It might place a considerable per-packet >> processing load on them, even if they adopted a stateless method >> of flow identification and label assignment. This is why the >> principal recommendation is that the source host should set the >> label. >> =20 > I think this recommendation is problematic. I agree that the first hop = router should insert the flow label, but requiring it to do fragment = reassembly in order to find the 5-tuple is a big burden, and I'm not = sure its even called for. I agree that requiring a router to reassembly isn't worthwhile. Better = to just leave the flow label as zero. >=20 > The RFC 2119 language above is fine. But I'd like to change the part = about normal case being the 5-tuple. I think the normal case should be = the 2-tuple under these circumstances. The source has access to the = 5-tuple; a router is not guaranteed to have access to it. >=20 > In addition, I'm not sure I understand how a router knows that it is a = first hop router. Are there cases where a device might mistakenly = believe it is a first hop router at a point where the traffic has = already been load-balanced to multiple routers? Are there situations = where the multiple first hop routers are used from the same host? The = document should provide some guidance about operational conditions where = the recommendations for the first hop router can be applied. The = document should state how such functionality is turned on (per = configuration? automatically?) and provide assurances that problematic = conditions can be avoided. I suppose the simple test is if the source address is from a prefix on = the incoming interface. =20 RFC 4311 "IPv6 Host-to-Router Load Sharing" requires (SHOULD) that hosts = send packets for a particular destination to the same router (when it = has multiple routers to choose from). I think the flow label draft = behavior for setting zero flow labels is compatible with this. =20 Does this help answer your questions? Bob >=20 > Jari >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From rja.lists@gmail.com Tue Jun 21 05:51:15 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA3E11E8079 for ; Tue, 21 Jun 2011 05:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 mxPH2mykJsWh for ; Tue, 21 Jun 2011 05:51:15 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id EFE5111E8078 for ; Tue, 21 Jun 2011 05:51:14 -0700 (PDT) Received: by qyk29 with SMTP id 29so3268841qyk.10 for ; Tue, 21 Jun 2011 05:51:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:to:mime-version:x-mailer; bh=aq2by/kqfUODXAsd11HD6fCwwfRkbKrLOyi8cZ7NmFo=; b=sgNeqbZwQS90JCcKmfu2FUA+5Ng2lIk22FYsOly8TMONhV7zdAaZdf4SQBQ4zWJdwl hQo3LWheunp981pDTwgSABivAZjcjppu47OpP1V6C4bfH/sUQGUURVuG6UUvRSguTpsI VIO0DX9n9vafYzquWTv/idsdZnZRqOSzUAjFE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=SK8iUJhVtzfGZN5bQx/vnGNe0k01FG39AKU/wWTscK19mBC61VZJiKz1vpt633SCjX T/kjYzvnHvbxmGgffyMPjGImojJ0VhD8R1/XIcRCG7BZG4IF1kWujIZv6Kl8PV5mbPme jsMSfFaq3To2YuaqIOJHd05+z25Gd2J1ldA9Y= Received: by 10.224.63.228 with SMTP id c36mr1265861qai.391.1308660674375; Tue, 21 Jun 2011 05:51:14 -0700 (PDT) Received: from [10.30.20.12] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id r33sm2977962qcs.6.2011.06.21.05.51.12 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Jun 2011 05:51:13 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: AD review of draft-ietf-6man-flow-3697bis Date: Tue, 21 Jun 2011 08:51:11 -0400 Message-Id: To: ipv6@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 12:51:15 -0000 Earlier, Brian Carpenter wrote: > As far as routers go, I think we have to say that an implementor has > to choose between a reassembly-based solution using the 5-tuple and > simply using the 2-tuple (maybe also the fragmentation ID - there is > some scope for ingenuity here). OBSERVATION: A deployed IPv6 router will encounter many more non-fragmented packets than fragmented packets. RECOMMENDED APPROACH: For the case of non-fragmented packets, use of the full 5 input parameters ought to be mandated. For the case of fragmented packets, use of reduced inputs that are available in the IPv6 header alone should be permitted as an option for implementers. Yours, Ran From rja.lists@gmail.com Tue Jun 21 06:03:57 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32AEC11E810C for ; Tue, 21 Jun 2011 06:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 mzmTryBG5oTo for ; Tue, 21 Jun 2011 06:03:56 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 92E4711E8107 for ; Tue, 21 Jun 2011 06:03:56 -0700 (PDT) Received: by qyk9 with SMTP id 9so2511394qyk.10 for ; Tue, 21 Jun 2011 06:03:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:to:mime-version:x-mailer; bh=S7WxKGpqIS1E2++wKbGQ1K7nweEHleQtAWc64JywwbM=; b=Fr+HKzctYwdeL26qF0KIUKCD+Xn+kz0YvqytY6hDvtwY3eeWW74h8PX2K+/NP4vykc DhW0tVRNREofMG+e1SemBwiEsKsZQQvJSieeASoStRs2IC80Xnt04TLGN9GSjsqkvlLj zF9cOQcJldXnRP6edzI+Z4fxLiMsj+oTjHzCo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=oGW0/8DuBrY8BHOnfxZv8ao//fCt15CHOFAL0+5z3/V1czms2jZRifktI9BwOAcefl kgCASLE2M0ktLGwi0cxnMANHuyoZc4TJ6UurBRdUtIzcj01Rafnd/q+4czIktqRJRzEM b+xgS57ZSzcSBbxXv5HY1xXm6KLrQ7NktiqWI= Received: by 10.224.207.131 with SMTP id fy3mr4905477qab.89.1308661436083; Tue, 21 Jun 2011 06:03:56 -0700 (PDT) Received: from [10.30.20.12] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id g7sm1058241qck.44.2011.06.21.06.03.55 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Jun 2011 06:03:55 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: AD review of draft-ietf-6man-flow-update Date: Tue, 21 Jun 2011 09:03:54 -0400 Message-Id: <023C12B3-CBC6-4406-82FE-ED7707ACE7A6@gmail.com> To: ipv6@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 13:03:57 -0000 Earlier, Brian Carpenter wrote: > I'd have to trawl the archive to find all the arguments, > but the main issue was that any attempt to include semantics > in the bits of the flow label leads to complexity that > probably can't be handled at line speed in a scaleable way. That claim presumes that a typical IPv6 router is using CPU-based packet forwarding. I believe that assumption to be incorrect. (By the way, this assumption underlies a lot of the discussion on the IPv6 list. Those of us who build ("have built", in my own case) real routers try to speak up about this from time to time, apparently without having much impact on WG thinking. I believe that most deployed IPv6 routers are using ASIC-based or FPGA-based forwarding of IPv6 packets. NP-based forwarding is not uncommon, but is probably less common. An advantage of NP-based forwarding engines or FPGA-based forwarding engines is that new capabilities can be added on the fly. While some deployed ASIC-based forwarding engines are programmable, most IPv6-capable ASIC forwarding engines are not programmable. Even the really low-cost consumer electronics routers that support IPv6 generally do so via commodity silicon packet processors offered by a range of different merchant silicon firms based in various countries (example: Broadcom). Since the majority of the lifespan of IPv6 is well into the future, and deployment today remains pretty small today, compared with say 3 years from now, re-allocating those 4 bits seems entirely possible to me. > Also 16 bits might make it too easy for a malicious party > to predict flow label values. That makes no mathematical sense to me. To the extent 16 bits is problematic, 20 bits also would be problematic. So that argument also does not make sense to me. Even if someone has formal maths behind that claim, which so far I haven't seen claimed on the IPv6 WG list, Moore's Law would defeat any claim that 20 bits is adequate within ~5 years. Yours, Ran From rja.lists@gmail.com Tue Jun 21 06:22:45 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5EA11E8095 for ; Tue, 21 Jun 2011 06:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 yVVurv9HA7Sk for ; Tue, 21 Jun 2011 06:22:44 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id ACBE311E8083 for ; Tue, 21 Jun 2011 06:22:44 -0700 (PDT) Received: by qyk29 with SMTP id 29so3294089qyk.10 for ; Tue, 21 Jun 2011 06:22:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:to:mime-version:x-mailer; bh=pG5mjWUqbWjBoDncLbe958OB0VR31YObZs0l8aj3KYk=; b=QTE7bSxgOgTO1aVGwha8OV25hiVJw5kJq/4GhVXXVXxZjJnrhHMiNh5rIQ5swOK04v GIPShtxMEWDT/Y6yCgQ0F3nDT+EiGNqr/Ai8G3UWeXNOgQdlRaVN6XPuX0V10sHbkRVY WPe05zl2dK3N7FwxdScmrfmjysMjumYRxE3Pc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=NV82ewsk51jb46B4tnwAuSheq01YTNZbuYXGAmIHzmugMC347vX6IeetBXbzwX18ep 5XkpQnY33wWtgKgrvfFRqqKKZ+HdVJfdR8bmRedudsTo+LTSLur/fJPy8mYFkFvBtPNM U/xNKSBJR6FRQtxVkzupWAielYPw+q25esbFo= Received: by 10.229.78.96 with SMTP id j32mr5061234qck.121.1308662564065; Tue, 21 Jun 2011 06:22:44 -0700 (PDT) Received: from [10.30.20.12] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id g11sm756806qcm.3.2011.06.21.06.22.42 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Jun 2011 06:22:43 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: AD review of draft-ietf-6man-flow-3697bis Date: Tue, 21 Jun 2011 09:22:41 -0400 Message-Id: To: ipv6@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 13:22:45 -0000 Earlier, Jari Arkko wrote: > In addition, I'm not sure I understand how a router knows that it is a = first hop router. My understanding is that the IPv6 WG's compromise regarding=20 the "Flow Label covert channel issue" that has been worked out=20 expressly permits any IPv6 security gateway to rewrite=20 IPv6 Flow Labels from value A to value B, if required by the=20 security policy deployed in that IPv6 security gateway,=20 provided that value B provides the documented required=20 mathematical properties that support load-balancing purposes. Since IPv6 Flow Label rewriting is allowed under that situation,=20 I don't see any value in restricting the rewriting of IPv6 packets=20 containing a zero IPv6 Flow Label to a non-zero IPv6 Flow Label value=20 -- again, provided the new non-zero value meets the documented=20 required mathematical properties. So I don't think it matters whether the router performing=20 rewriting is a first-hop router or not. Requiring a check of whether the router is a first-hop router is just wasted computational overhead for the router. =20 =46rom the perspective of an IPv6 router implementer, the relevant=20 data are (A) was the IPv6 Flow Label value zero upon receipt by that router, (B) are the 5 input values easily read=20 by that router, and (C) is calculating a non-zero Flow Label=20 value reasonable given other computational demands on that=20 router at that moment in time. =20 For an ASIC-based or FPGA-based IPv6 forwarding engine,=20 - (A) is trivial to check at wire speed - (B) is true IFF packet is not fragmented - (C) is irrelevant since one would throw a few lines of Verilog at the problem For an NP-based IPv6 forwarding engine, - (A) is trivial to check at wire speed - (B) is generally true IFF packet is not fragmented - (C) depends primarily on how much other processing (e.g. encapsulation/decapsulation) that particular frame=20 might require, and secondarily on the number of NP cycles available while performing at wire-speed BOTTOM LINE: If any IPv6 router sees any zero-value Flow Label, the router ought=20 to be permitted (but NOT required) to rewrite the Flow Label value=20 to a non-zero value that meets the published mathematical requirements. Yours, Ran From brian.e.carpenter@gmail.com Tue Jun 21 06:44:58 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9053E11E8092 for ; Tue, 21 Jun 2011 06:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.481 X-Spam-Level: X-Spam-Status: No, score=-103.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 qD7VeQTXNrey for ; Tue, 21 Jun 2011 06:44:58 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id D328311E8078 for ; Tue, 21 Jun 2011 06:44:57 -0700 (PDT) Received: by fxm15 with SMTP id 15so2083722fxm.31 for ; Tue, 21 Jun 2011 06:44:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RoYd0nAlfiVOKZrodBCnBRCoc9MmiFfanjmpMKQoToY=; b=IDTRSrDhvtcI3QGUURwQeU5jNNnQ4rllHGd9EuRt8iOQu4WJibwVtcuEXYAfYk1Mdn dzqyyKiDL/0kHvftwSIaGJ2EHHOU8EGKSdtqpa6WBZkzM5NNwPZQ9Zc4gu9CeKJJRvJc anF5Ro4eE8O6xOH0G7L2tJbW4GAsfg1l43Y14= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=FaNh/pvbV30ndVcU7GrJuRE59w+0XVr0NMBu/HMRrVbAzZxJ2Sl96bOisxpnZ2yPrG GeQKBClPuF4MuAKemaC083ddpPzyK8XKDnK3DfNhQVmBcezqugIAEiloVzDL7v8rYNlU J5CLH6e0hVtpwk4JMeKcg8WH+S2O4zzm6VSY4= Received: by 10.223.143.6 with SMTP id s6mr167162fau.74.1308663895875; Tue, 21 Jun 2011 06:44:55 -0700 (PDT) Received: from [10.255.25.96] (74-95-74-1-Indianapolis.hfc.comcastbusiness.net [74.95.74.1]) by mx.google.com with ESMTPS id a18sm3408384fak.29.2011.06.21.06.44.53 (version=SSLv3 cipher=OTHER); Tue, 21 Jun 2011 06:44:54 -0700 (PDT) Message-ID: <4E00A04C.3040002@gmail.com> Date: Wed, 22 Jun 2011 01:44:44 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: RJ Atkinson Subject: Re: AD review of draft-ietf-6man-flow-3697bis References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 13:44:58 -0000 On 2011-06-22 00:51, RJ Atkinson wrote: > Earlier, Brian Carpenter wrote: >> As far as routers go, I think we have to say that an implementor has >> to choose between a reassembly-based solution using the 5-tuple and >> simply using the 2-tuple (maybe also the fragmentation ID - there is >> some scope for ingenuity here). > > OBSERVATION: > A deployed IPv6 router will encounter many more non-fragmented > packets than fragmented packets. > > RECOMMENDED APPROACH: > > For the case of non-fragmented packets, use of the full 5 input > parameters ought to be mandated. I'd go for RECOMMENDED; we really should leave some scope for implementors I think. Brian > > For the case of fragmented packets, use of reduced inputs that > are available in the IPv6 header alone should be permitted > as an option for implementers. > > Yours, > > Ran > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From brian.e.carpenter@gmail.com Tue Jun 21 06:48:28 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B583C11E80C1 for ; Tue, 21 Jun 2011 06:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.487 X-Spam-Level: X-Spam-Status: No, score=-103.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 gwllqm+WBeUP for ; Tue, 21 Jun 2011 06:48:28 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id F161711E80AC for ; Tue, 21 Jun 2011 06:48:27 -0700 (PDT) Received: by fxm15 with SMTP id 15so2086657fxm.31 for ; Tue, 21 Jun 2011 06:48:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=BIjRoNSn5KR2nQlx8Mn8EEWGNT8NofiHoumE7bmqKsc=; b=xT16fuF32R7ege5PP70rmfXgiA8g6eel0diZz7HaRfz7ngqyxfpmEw8siiXRLRkzIp 1vSOMKzQYwO7jgODY6R3m95X/xqy2zyDy9tvHPd9+osLxYdJJXGrYRAVeF9/1dcMxobr kXzubhy7i1nIjrUc90a0jbQHRFagbDPQVGHtk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=HBBNsu43v2HXx/Qcv9pHfaB5dBUISyu3C1CMNzKyENT2j+LKAv1zvxK7qGDXJH/8nF 062QijGiHeak5KMU3j0qy1xR8Lw73afYHL/nIyz1rcaopDEwr1stywtZN49RsSl16neH ulcvY8IhfqT5Hj3zFH8YvIJUE/tHg/uvpLzGY= Received: by 10.223.59.146 with SMTP id l18mr130489fah.58.1308664106779; Tue, 21 Jun 2011 06:48:26 -0700 (PDT) Received: from [10.255.25.96] (74-95-74-1-Indianapolis.hfc.comcastbusiness.net [74.95.74.1]) by mx.google.com with ESMTPS id 11sm3411169fax.36.2011.06.21.06.48.24 (version=SSLv3 cipher=OTHER); Tue, 21 Jun 2011 06:48:25 -0700 (PDT) Message-ID: <4E00A123.6000209@gmail.com> Date: Wed, 22 Jun 2011 01:48:19 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: RJ Atkinson Subject: Re: AD review of draft-ietf-6man-flow-update References: <023C12B3-CBC6-4406-82FE-ED7707ACE7A6@gmail.com> In-Reply-To: <023C12B3-CBC6-4406-82FE-ED7707ACE7A6@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 13:48:28 -0000 Ran, On 2011-06-22 01:03, RJ Atkinson wrote: > Earlier, Brian Carpenter wrote: >> I'd have to trawl the archive to find all the arguments, >> but the main issue was that any attempt to include semantics >> in the bits of the flow label leads to complexity that >> probably can't be handled at line speed in a scaleable way. > > That claim presumes that a typical IPv6 router is using CPU-based > packet forwarding. I believe that assumption to be incorrect. > (By the way, this assumption underlies a lot of the discussion > on the IPv6 list. Those of us who build ("have built", in my own > case) real routers try to speak up about this from time to time, > apparently without having much impact on WG thinking. > > I believe that most deployed IPv6 routers are using ASIC-based > or FPGA-based forwarding of IPv6 packets. NP-based forwarding > is not uncommon, but is probably less common. An advantage > of NP-based forwarding engines or FPGA-based forwarding engines > is that new capabilities can be added on the fly. While some > deployed ASIC-based forwarding engines are programmable, most > IPv6-capable ASIC forwarding engines are not programmable. > > Even the really low-cost consumer electronics routers that > support IPv6 generally do so via commodity silicon packet > processors offered by a range of different merchant silicon > firms based in various countries (example: Broadcom). > > Since the majority of the lifespan of IPv6 is well into the > future, and deployment today remains pretty small today, > compared with say 3 years from now, re-allocating those 4 bits > seems entirely possible to me. Anything's possible. I was trying to summarise what I recall from the discussions that led to the WG consensus. > >> Also 16 bits might make it too easy for a malicious party >> to predict flow label values. > > That makes no mathematical sense to me. > > To the extent 16 bits is problematic, 20 bits also would be > problematic. So that argument also does not make sense to me. > Even if someone has formal maths behind that claim, which so far > I haven't seen claimed on the IPv6 WG list, Moore's Law would > defeat any claim that 20 bits is adequate within ~5 years. Sure, we are talking about the difference between a brute force attack with a million choices vs 65k choices; not a strong argument, of course. Brian From wesley.george@twcable.com Tue Jun 21 06:57:33 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C80DF11E80AE for ; Tue, 21 Jun 2011 06:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.14 X-Spam-Level: X-Spam-Status: No, score=-0.14 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 JsfYCYbFs9dT for ; Tue, 21 Jun 2011 06:57:33 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id C09209E801F for ; Tue, 21 Jun 2011 06:57:32 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.65,401,1304308800"; d="scan'208";a="227002219" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 21 Jun 2011 09:57:17 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.28]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Tue, 21 Jun 2011 09:57:31 -0400 From: "George, Wesley" To: Brian E Carpenter , Jari Arkko Date: Tue, 21 Jun 2011 09:57:29 -0400 Subject: RE: AD review of draft-ietf-6man-flow-3697bis Thread-Topic: AD review of draft-ietf-6man-flow-3697bis Thread-Index: AcwvmHNZpxC4H9WGS2KFJfNdBnqcqwAdg7Vw Message-ID: <34E4F50CAFA10349A41E0756550084FB0A105287@PRVPEXVS04.corp.twcable.com> References: <4DFF70A4.7040807@piuha.net> <4DFFC7BC.7090603@gmail.com> In-Reply-To: <4DFFC7BC.7090603@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-6man-flow-3697bis@tools.ietf.org" , IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 13:57:33 -0000 -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Bri= an E Carpenter Sent: Monday, June 20, 2011 6:21 PM To: Jari Arkko Cc: IETF IPv6 Mailing List; draft-ietf-6man-flow-3697bis@tools.ietf.org Subject: Re: AD review of draft-ietf-6man-flow-3697bis > I think this recommendation is problematic. I agree that the first hop > router should insert the flow label, but requiring it to do fragment > reassembly in order to find the 5-tuple is a big burden, and I'm not > sure its even called for. Yes, this is an embarassingly good catch. I think we need to add some langu= age to the recommendation that source hosts SHOULD set their own flow labels, pointing out that in a fragmented case this is the only way to do things properly. Reverting to the 2-tuple is a serious penalty since a lot of the entropy in headers is in one of the port numbers. WEG> Given the fact that only end hosts can actually fragment IPv6 packets,= and that's only when MTU less than 1280 is supported, I would expect fragm= entation to be more the exception than the rule. I agree that for completen= ess it is worthwhile to discuss as Brian recommends, but I don't think it's= a major concern, and it should be phrased that way in the draft. > The RFC 2119 language above is fine. But I'd like to change the part > about normal case being the 5-tuple. I think the normal case should be > the 2-tuple under these circumstances. The source has access to the > 5-tuple; a router is not guaranteed to have access to it. As far as routers go, I think we have to say that an implementor has to choose between a reassembly-based solution using the 5-tuple and simply using the 2-tuple (maybe also the fragmentation ID - there is some scope for ingenuity here). WEG> I agree that this is a detail best left to implementers and operators,= but I do not support an explicit recommendation to only do 2-tuple on frag= mented packets. If the draft wants to put some language that it may need to= be a consideration, I'm ok with that, but I do not want this to be a situa= tion where the implementation that we get is only 2-tuple because of a perc= eived (and potentially overstated) scale risk for fragmented packet reassem= bly. I'd much rather router vendors implement 5-tuple, and then let operato= rs decide how they want to manage this potential scale issue via configurat= ion knobs. This also leaves it open for ingenuity as Brian says. Smart vend= ors could probably even use some of their existing rate-limiting machinery = to do some amount of reassembly and then revert to 2-tuple if it exceeds a = certain threshold in order to preserve box performance. If I were to put this in normative language, I would say SHOULD use 5 tuple= for fragments, MAY revert to 2-tuple if reassembly at higher traffic level= s becomes a concern in a given implementation. However, to Brian's comment about fragmentation ID, is there any reason why= the draft can't recommend (or even require) this as a possible improvement= over straight 2-tuple in the revert case? > Are there situations > where the multiple first hop routers are used from the same host? WEG> I think that first-hop router in the context of this draft is more acc= urately defined as the first router in the path which is configured to re-m= ark zero-value flow labels, which probably makes "first-hop router" a poor = choice of words here. Ingress router might be a better choice by itself, si= nce that could more generically cover something like an ASBR as well. Alternatively, you could make a distinction between first-hop router and in= gress router in cases where that device is not the host, but is going to be= encapsulating the data (tunnels, for example) in such a way so that subseq= uent routers cannot see the true 5-tuple data without looking well past the= packet headers. In this case, we may want to strongly recommend that it se= ts the flow label on the outer packet based on data from the inner packet, = since like the host, it has the best visibility into the underlying flows a= nd this will be gone on subsequent hops. Because this is strictly optional and will be incrementally deployed, there= is no way to assume that the first-hop router is anywhere near the origina= ting host, and I think it's overreaching to discuss such specific cases as = above. We've already said that the host should be the one doing this becaus= e it has the best knowledge of its flows. If it doesn't, it's best effort b= ased on what the network can infer from the available data. I'm not sure ho= w the case of one host connected to multiple first-hop routers is different= - it sends packets to all of them, either due to ECMP or other bundling or= some other algorithm, but unless it's doing something relatively strange l= ike per-packet round robin, each of the first-hop routers should be able to= use the information it has to determine flows on the traffic it sees and m= ark accordingly. At most, this might be a good example for why per-packet d= istribution without explicitly setting the flow label is a bad idea. > The document should provide some guidance about operational conditions wh= ere > the recommendations for the first hop router can be applied. The > document should state how such functionality is turned on (per > configuration? automatically?) and provide assurances that problematic > conditions can be avoided. I'd like to hear from my co-authors and the WG before producing a new versi= on. WEG> I think I need some additional clarity on what you mean by the above b= efore I can give much in the way of useful feedback. I'm not sure that much= guidance on operational conditions is necessary, since the introduction al= ready explains the types of networks that would see benefit to enhanced loa= d-balancing, as well as the reasons why FL is a good addition to the existi= ng data used for LB decisions. If your network meets those tests, and your = router supports the feature at scale, enable it. Unless folks can come up w= ith specific cases where enabling FL marking is explicitly NOT recommended.= .. Regarding avoiding problematic conditions, I can think of the following: Inconsistent balancing due to incorrect identification of flows or collisio= n of flow label values Out of order packet delivery due to the above Scaling considerations with managing reassembly of fragments for 5-tuple fl= ow marking Most of these are either going to be discussed based on this review, or are= side effects of the fact that this is a best-effort, incrementally deploye= d and optional implementation. What other problematic conditions are there = that we need to avoid? I think defaults are probably an implementation detail, but if the draft ha= s to make a recommendation, I'd say host-level defaults to on, router-level= defaults to off, and have enabling rewriting zero-value flow labels be a s= eparate configuration item from paying attention to existing nonzero flow l= abel values for load-balancing. Whether it's a global knob or a per-interfa= ce one is probably getting too far into the weeds, but I'd say that at leas= t for the rewriting, it might make sense to have the granularity to enable/= disable on a per-interface basis. Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From jari.arkko@piuha.net Tue Jun 21 07:13:56 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B78811E8106 for ; Tue, 21 Jun 2011 07:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.457 X-Spam-Level: X-Spam-Status: No, score=-102.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 YcZsjerEfZEy for ; Tue, 21 Jun 2011 07:13:55 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 2D03F11E8082 for ; Tue, 21 Jun 2011 07:13:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 3D94A2CC3B; Tue, 21 Jun 2011 17:13:52 +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 QdlmRpISQ5Hc; Tue, 21 Jun 2011 17:13:51 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id ACB502CC2F; Tue, 21 Jun 2011 17:13:51 +0300 (EEST) Message-ID: <4E00A71F.1000201@piuha.net> Date: Tue, 21 Jun 2011 17:13:51 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: RJ Atkinson Subject: Re: AD review of draft-ietf-6man-flow-3697bis References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 14:13:56 -0000 Ran and others, > For the case of non-fragmented packets, use of the full 5 input > parameters ought to be mandated. > > For the case of fragmented packets, use of reduced inputs that > are available in the IPv6 header alone should be permitted > as an option for implementers. > I think you are making it easier than it really is. Here's the problem. The first packet arrives and its small. The router can read the 5-tuple. All fine so far. Picking flowid = f(5-tuple) The next packet arrives, only this time it is fragmented. The router cannot read the 5-tuple from all fragments. Now, what is the router supposed to do? Here are its options: 1. Reassemble to find the 5-tuple information. All is fine, except that its a heavy implementation burden (and a DoS vulnerability). 2. Revert to using 2-tuple for the fragmented packet: flowid' = f(2-tuple) Now flowid != flowid' This is really bad, as it means that a normal packet and a fragmented packet for the same flow would have different flowids, and might take different routes, be re-ordered, etc. 3. Do some magic matching of fragment identifiers. Again, we can find the 5-tuple, but now the router has to remember per-session state (another DoS vulnerability). Or am I missing something? I think the first-hop router has to set the flowid in every packet of the flow, doesn't it? Jari From rja.lists@gmail.com Tue Jun 21 08:00:57 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B07CD21F84D7 for ; Tue, 21 Jun 2011 08:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Tf6FcTNlXuPL for ; Tue, 21 Jun 2011 08:00:57 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id BF36121F84D6 for ; Tue, 21 Jun 2011 08:00:56 -0700 (PDT) Received: by vws12 with SMTP id 12so1740633vws.31 for ; Tue, 21 Jun 2011 08:00:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to :x-mailer; bh=FV9WKlba9BBOG9jE8AbeeVyQrrlZeixc3ZZo0+smUSY=; b=VNyRh7B9haBUCqTGBtFgx4ox3GICIk6/fibt5zBVNRcg5gJUpEG7FNRI4Uhag4GTvE hPgL6gfPBxI+dw9dfJZI/Wp6JtWjAknWgp/I9yJVWSCwfs4TxYqlunLMEdfV+xsEYRno KUComqcJrtQbqu5Dg55+d6tajx443obfIfiNk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=tKYYSzjZvd65dg3vk/5kDhqWPDzS+ODi6AE4Nv1QRvwiZPtH79qjjkzc8chb7nA9nG uxzQnIJOCwTT699zqr/4ct0GwNbxoae4a80cLe13Ot6ztcFUy5G9LcDKrICqxptWITvk SVqZ0B1wfvpG+54IVxDxysMyoOY2DMI/2GuC8= Received: by 10.220.50.141 with SMTP id z13mr2320095vcf.164.1308668456048; Tue, 21 Jun 2011 08:00:56 -0700 (PDT) Received: from [10.30.20.12] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id i32sm247354vck.34.2011.06.21.08.00.54 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Jun 2011 08:00:54 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) Subject: Re: AD review of draft-ietf-6man-flow-3697bis From: RJ Atkinson In-Reply-To: <4E00A71F.1000201@piuha.net> Date: Tue, 21 Jun 2011 11:00:53 -0400 Content-Transfer-Encoding: 7bit Message-Id: <3E9CAB5A-0692-4F56-A24D-EFB7E6627D0D@gmail.com> References: <4E00A71F.1000201@piuha.net> To: ipv6@ietf.org X-Mailer: Apple Mail (2.1084) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 15:00:57 -0000 On 21 Jun 2011, at 10:13 , Jari Arkko wrote: > I think you are making it easier than it really is. > > Here's the problem. > The first packet arrives and its small. The router can read the 5-tuple. > All fine so far. Picking > > flowid = f(5-tuple) > > The next packet arrives, only this time it is fragmented. > The router cannot read the 5-tuple from all fragments. Now, > what is the router supposed to do? Here are its options: > > 1. Reassemble to find the 5-tuple information. All is fine, > except that its a heavy implementation burden (and a DoS vulnerability). A router that I built would not try to reassemble transit traffic. > 2. Revert to using 2-tuple for the fragmented packet: > > flowid' = f(2-tuple) > > Now flowid != flowid' This is really bad, as it means that > a normal packet and a fragmented packet for the same flow > would have different flowids, and might take different routes, > be re-ordered, etc. We agree it is undesirable, but I would not write "really bad". I think we differ on whether it is practical to avoid having different Flow Label values for fragmented vs non-fragmented packets of a given flow *in the particular case* where the originating node sent the packet with zeros in the Flow Label field. In the approach I outlined, for some given flow where the originating node did not set a Flow Label value, the non-fragmented packets all will have some Flow Label value A, while fragmented packets all will have some Flow Label value B. With high probability, (A != B). Still, this outcome is not obviously worse than having all of those packets with a Flow Label value of zero. We might also disagree on how common fragmented IPv6 packets are in the deployed world, I'm not sure. In my experience they are uncommon in the deployed world. I gather they are very common in the small niche of supercomputing, but in that special case the number of fragmented packets will dwarf the number of non-fragmented packets. This results in the vast majority of packets within the flow having the same Flow Label value. Separately, packet re-ordering can (and routinely does) happen in the deployed world already, regardless of contents of the Flow Label field. So receiving nodes already have to be able to cope with reordered packets. Also, modern TCP implementations cope MUCH better with re-ordered packets than older TCP implementations. So the performance hit of a re-ordered packet is not nearly as drastic as it was (for example) 15 years ago. > 3. Do some magic matching of fragment identifiers. Again, we can find > the 5-tuple, but now the router has to remember per-session state > (another DoS vulnerability). (A) A router I built would not be trying to keep that per-session state. (B) Literally every step in packet handling is a potential DOS vulnerability. It is not possible to avoid DOS vulnerabilities in useful packet networks. So one ought to be claiming that the DOS vulnerability is lower-cost for the attacker than existing DoS vulnerabilities and also expensive for the victim. [While I do believe those 2 properties hold in this case, it is crucial to examine/discuss those 2 properties for any claim of any DoS vulnerability in a packet network. If we try to evaluate "DOS vulnerability" on a binary basis, we are unlikely to make scientifically sound decisions.] There is a 4th implementation option, which is to use only fields in the base IPv6 header for all cases where a router adds a Flow Label. That implementation option adds little or no value for load-balancing as compared with a zero Flow Label, because existing load-balancing algorithms in the deployed world already tend to use the variable fields of the IPv6 header (e.g. source IPv6 address, destination IPv6 address, maybe ToS byte) for deployed load-balancing situations. For non-fragmented packets, the deployed world already tends to use the 5 input values that these I-Ds discuss, by the way. Part of my point in mentioning that hardware forwarding engines (i.e. ASIC, FPGA) are already commonplace, even in very low cost devices, was to point out that such forwarding engines can look at any combination of any fields in any IP header (and often also in the TCP/UDP/SCTP/ICMP headers), with no incremental performance cost, at wire-speed. In at least one IPv6 capable forwarding ASIC implementation that I'm very familiar with, this flexibility did not significantly increase the gate count and did not increase the die size. Folks who worked on a different widely deployed IPv6 capable forwarding ASIC have told me that these properties were also true in their silicon. IMHO, the vast majority of the benefit to using the IPv6 Flow Label for load-balancing accrues to those IPv6 packets that have been fragmented where the originating node inserts the non-zero Flow Label value based on the documented 5 input parameters. In the other cases, the 5 values either already can be read spontaneously at wire speed by commonly used merchant silicon forwarding engines (e.g. for non-fragmented packets) OR the after-the-fact inserted Flow Label performs no better than using base IPv6 header fields that can be read spontaneously at wire speed (for fragmented packets). By having routers use the usual 5 inputs to generate a non-zero Flow Label for all non-fragmented packets that arrive with zero value Flow Labels, the common case of a non-fragmented IPv6 packet is handled a bit better and the less common case of a fragmented IPv6 packet is not really worse off. After all, a router can't know from examination of packet N of flow X whether some future packet N + Delta in the same flow X will or won't contain a Fragment Header. IMHO, Yours, Ran From rja.lists@gmail.com Tue Jun 21 08:08:03 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 622EE21F8570 for ; Tue, 21 Jun 2011 08:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 7QJTe1eFd3UO for ; Tue, 21 Jun 2011 08:08:02 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id C3D2621F8504 for ; Tue, 21 Jun 2011 08:08:02 -0700 (PDT) Received: by qyk9 with SMTP id 9so2618564qyk.10 for ; Tue, 21 Jun 2011 08:07:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:to:mime-version:x-mailer; bh=j3kUrtIs1MDT4E1vDjbOoaUNVHLaOTyAhWsfqysDJnY=; b=DwbtItLPdDvG6rxLc48NWs4xh4Q7oUqF61QBqb4hOlPAO12KHsjOZ+vSzv99feAR/N XbjZjz7cXJmAA8XbgNbanp7s2/NKXXXKHss6nSZW7DIguOFepechDbA1r5j0e6PKJWph 3vkU7+qW4DUNCcQyhiqO/XxabmC8Vpb0FqluA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=JlkWSD76LHkKw5B2j1bRa9paKc6ESYcjccds6KVlb4xiSPdJXgyhX/lHpNrMW95+6T ZETG6VIlW7/Us94kas9RDxb/+M2KfdQ/M2JA2UtJ7HmrkQd0nAyHgqbeLaKybLTmkqP/ pwr47Ja0z1oEp47Br0GWEDhtyI59uyTpKLHeM= Received: by 10.229.118.72 with SMTP id u8mr5060527qcq.1.1308668870527; Tue, 21 Jun 2011 08:07:50 -0700 (PDT) Received: from [10.30.20.12] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id g7sm1132794qck.8.2011.06.21.08.07.49 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Jun 2011 08:07:49 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: AD review of draft-ietf-6man-flow-3697bis Date: Tue, 21 Jun 2011 11:07:48 -0400 Message-Id: To: ipv6@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 15:08:03 -0000 CLARIFICATION: I agree with Brian and George that for the case where a router is inserting a Flow Label value into a fragmented packet, it is desirable (and normally practical) to include the Fragment ID field as an input. So that would give 3 input values (Source IP, Dest IP, Fragment ID) for calculating a Flow ID value in fragmented packets. Cheers, Ran From huitema@microsoft.com Tue Jun 21 09:47:30 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B602611E8296 for ; Tue, 21 Jun 2011 09:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Nn-KmMX5gVTy for ; Tue, 21 Jun 2011 09:47:30 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 2357711E8282 for ; Tue, 21 Jun 2011 09:47:29 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 21 Jun 2011 09:47:29 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.1.289.8; Tue, 21 Jun 2011 09:47:28 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.58]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0289.008; Tue, 21 Jun 2011 09:47:28 -0700 From: Christian Huitema To: RJ Atkinson , "ipv6@ietf.org" Subject: RE: AD review of draft-ietf-6man-flow-3697bis Thread-Topic: AD review of draft-ietf-6man-flow-3697bis Thread-Index: AQHMMCUXfCzKhKowFkOlKsMM0peDrpTIBHEg Date: Tue, 21 Jun 2011 16:47:27 +0000 Message-ID: <22F6318E46E26B498ABC828879B08D4F176AEE@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 16:47:30 -0000 > I agree with Brian and George that for the case where a router is inserti= ng a Flow Label value into a fragmented packet, it is > desirable (and norm= ally practical) to include the Fragment ID field as an input. =20 > > So that would give 3 input values (Source IP, Dest IP, Fragment ID) for c= alculating a Flow ID value in fragmented packets. Really? The fragment ID can change with each packet, correct? Imagine a UDP= stream that for some reason uses large packets. Or maybe some large packet= s and some small packets. Isn't the proposal going to result in different p= ackets of the same "application stream" getting different flow ids? Isn't t= hat going to be somewhat problematic for load balancers? -- Christian Huitema =20 From rja.lists@gmail.com Tue Jun 21 10:03:51 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C7511E82A5 for ; Tue, 21 Jun 2011 10:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.532 X-Spam-Level: X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 LxA4HF764Wsc for ; Tue, 21 Jun 2011 10:03:51 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id CB56711E808B for ; Tue, 21 Jun 2011 10:03:50 -0700 (PDT) Received: by qwc23 with SMTP id 23so2330354qwc.31 for ; Tue, 21 Jun 2011 10:03:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to :x-mailer; bh=3fZusqzs5zp6MmuY0AW8CEBS59TBdwVsnPDeXMvBkAo=; b=jLtvx0shKnO9fB2wTD3O1PN1DiXCTTHBHKp03b/qZTL+NWKzkYWXg61X8K6JX51nsJ yKrKokDLHFac4cU5yXTv+djQtP6MbMW6PxiztN1iJtgoW4PQ+1BCGNaJL2MRRyUs1gKP jq9+xR9ZKmrpMZ1xYfOf+98K+7gJYW6CgYujI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=LbN92gQSmvU/D6NNmQkWExaZI0Wa57M0QG1ZWupl0865eSMOXzWAUjlsxZ/gAPylr7 lC5g2Ijpzh6CWX1MsP5Pc5vLn5FgCsXYNXP4PbBS4lDu0iNEp1Fz9rOhq6pfyHDYrMRK ilnoGeaDvwouopje9powjcp3kEZyXObquiru4= Received: by 10.224.63.228 with SMTP id c36mr1527137qai.391.1308675830227; Tue, 21 Jun 2011 10:03:50 -0700 (PDT) Received: from [10.30.20.12] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id r33sm3132053qcs.18.2011.06.21.10.03.49 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Jun 2011 10:03:49 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) Subject: Re: AD review of draft-ietf-6man-flow-3697bis From: RJ Atkinson In-Reply-To: <22F6318E46E26B498ABC828879B08D4F176AEE@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> Date: Tue, 21 Jun 2011 13:03:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <22F6318E46E26B498ABC828879B08D4F176AEE@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> To: ipv6@ietf.org X-Mailer: Apple Mail (2.1084) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 17:03:51 -0000 On 21 Jun 2011, at 12:47 , Christian Huitema wrote: > Really? The fragment ID can change with each packet, correct? Imagine = a UDP stream that for some reason uses large packets. Or maybe some = large packets and some small packets. Isn't the proposal going to result = in different packets of the same "application stream" getting different = flow ids? Isn't that going to be somewhat problematic for load = balancers? I think the starting point probably should be the prior notes=20 on this from Brian & George. As my note made clear, I merely=20 echoed their words. In which, Brian wrote in part: > As far as routers go, I think we have to say that an = implementor=20 > has to choose between a reassembly-based solution using the = 5-tuple=20 > and simply using the 2-tuple (maybe also the fragmentation ID=20= > - there is some scope for ingenuity here). =09 In which, George wrote in part: > However, to Brian's comment about fragmentation ID,=20 > is there any reason why the draft can't recommend=20 > (or even require) this as a possible improvement over=20 > straight 2-tuple in the revert case? Cheers, Ran From shane@castlepoint.net Tue Jun 21 21:07:42 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB2AC11E8122 for ; Tue, 21 Jun 2011 21:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 j0XkXXhm5LD5 for ; Tue, 21 Jun 2011 21:07:42 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 846A711E811D for ; Tue, 21 Jun 2011 21:07:28 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 16900268037; Tue, 21 Jun 2011 22:07:28 -0600 (MDT) Received: from mbpw.castlepoint.net (65-102-206-76.hlrn.qwest.net [65.102.206.76]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Tue, 21 Jun 2011 22:07:27 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=65.102.206.76; client-port=50764; syn-fingerprint=65535:54:1:64:M1452,N,W3,N,N,T,S; data-bytes=0 Subject: Re: AD review of draft-ietf-6man-flow-3697bis Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: <3E9CAB5A-0692-4F56-A24D-EFB7E6627D0D@gmail.com> Date: Tue, 21 Jun 2011 22:07:11 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <8ACA53E6-AC3A-467A-941F-34F975584247@castlepoint.net> References: <4E00A71F.1000201@piuha.net> <3E9CAB5A-0692-4F56-A24D-EFB7E6627D0D@gmail.com> To: RJ Atkinson X-Mailer: Apple Mail (2.1084) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 04:07:43 -0000 Ran, Jari, All, To emphasize some of the excellent points that Ran made ... On Jun 21, 2011, at 9:00 AM, RJ Atkinson wrote: > Separately, packet re-ordering can (and routinely does) happen=20 > in the deployed world already, regardless of contents of the > Flow Label field. So receiving nodes already have to be able=20 > to cope with reordered packets. An example which routinely happens in today's networks would be link = restoration. In that case, the network is restoring traffic from a much = longer path to a shorter, more optimal path in the network. Depending = on the transmission rate of the transmitter, this can/will lead to = temporary reordering of microflows at the receivers. Do note that in = well-operated networks this reordering is, hopefully, transient and of = an extremely short duration. =20 > There is a 4th implementation option, which is to use only fields=20 > in the base IPv6 header for all cases where a router adds a Flow = Label. =20 > That implementation option adds little or no value for load-balancing=20= > as compared with a zero Flow Label, because existing load-balancing=20 > algorithms in the deployed world already tend to use the variable=20 > fields of the IPv6 header (e.g. source IPv6 address, destination IPv6=20= > address, maybe ToS byte) for deployed load-balancing situations. =20 > For non-fragmented packets, the deployed world already tends to use=20 > the 5 input values that these I-Ds discuss, by the way. I think it's important to re-emphasize and expound upon the above. = Namely, deployed IPv6 routers *already* [should] identify fragmented vs. = non-fragmented packets, presumably by inspecting the "Next Header field = of the last header of the Unfragmentable Part" for value 44 [RFC 2460, = Section 4.5] for 'Fragment Header' for the purposes of deciding whether = /or not/ they should attempt to identify Next Headers containing the = Upper Layer protocol and, subsequently, the {protocol, src_port & = dst_port} that will be fed, (along with {src_ip, dst_ip}), into LAG = and/or ECMP hash algorithms for fine-grained load-balancing. "Conservative" router/switch implementations strive to reduce the risk = of _persistent_ reordering of an individual microflow. IOW, since = non-first fragments will not contain Upper Layer protocol information, = (specifically: {src_port, dst_port}), that can be fed as input-keys to = LAG and/or ECMP hash algorithms, the "safe" thing they should do is to = only use the 2-tuple of {src_ip, dst_ip} as input-keys for _all_ = fragments within a microflow. Obviously, this leads to 'coarse-grained' = load-balancing for microflows containing fragmented packets. As with many things, Engineering is about properly managing a series of = trade-offs. Currently, the advantage of avoiding persistent reordering = of fragmented microflows out-weighs the disadvantage of only being able = to perform coarse-grained load-balancing of the assumed very small = amount of fragmented microflows. If this draft is widely implemented & = deployed and originating hosts are encoding a "uniformly distributed", = non-zero flow-label in all packets (fragmented or not), then it would = seem logical that routers would be adapted so that: a) If they encounter a Fragment Header they use: {src_ip, dst_ip + = flow_label} as input-keys to the LAG + ECMP hash algorithms; and/or, b) If they encounter a Next Header with, for example, an Upper Layer = Protocol that they have *not* (yet?) implemented a parsing routine to = extract appropriate input-keys (or, can't, because it's too deep in the = packet's headers), then they revert back to using {src_ip, dst_ip + = flow_label} as input-keys to the LAG + ECMP hash algorithms[1]; and/or, c) [Assuming widespread use of the flow-label], they no longer even = bother looking at any Next Headers in all packets and _always_ use = {src_ip, dst_ip + flow_label} for input-keys to LAG + ECMP hash = algorithms. Personally, I see (a) & (b) as being a short- to medium-term "wins" that = could be safely implemented, by default, in the next-spin of NP, FPGA SW = and ASIC HW, given the existence of this, hopefully soon, RFC. = Obviously, (c) is going to be a little further out. I assume that, = similar to today's router implementations, router vendors will likely = provide the flow-label as yet another input-key that may be used as = input-keys for LAG + ECMP hash algorithms. It will then be up to = individual operators to determine the appropriate time to configure = their routers/switches to, for example, only use: {src_ip, dst_ip + = flow_label} when they are comfortable doing so for all traffic. > IMHO, the vast majority of the benefit to using the IPv6 Flow Label=20 > for load-balancing accrues to those IPv6 packets that have been=20 > fragmented where the originating node inserts the non-zero Flow Label=20= > value based on the documented 5 input parameters. +1 in the short- to medium (?) term. I would also point out a = substantial additional advantage is [long-term] architectural = flexibility in that the end-points (hosts) may freely use *new* = transport protocols (SCTP, DCCP, UDP-lite, etc.) so long as they = continue to label all packets with a "uniformly distributed", non-zero = flow-label so that [Core] routers/switches have something they can = safely use as input-keys for LAG and/or ECMP hash algorithms. At least, = that's one part of the network that we don't need to worry about = upgrading to support new transport-layer protocols. Unfortunately, = middleboxes (FW's or, more generally, "security GW's") might still have = to be adapted depending on the applicability of the new transport-layer = protocol to various network types, (e.g.: SOHO vs. Large-ish = Enterprise). Thanks, -shane [1] One example I can think of here is UDP-lite. Silly as though it may = seem, (since the format of UDP and UDP-lite headers are nearly = identical), parsing routines to extract {src_port, dst_port} from = UDP-lite headers are not [widely] implemented in deployed equipment, = today, because it is assumed this isn't a widely used transport-layer = protocol. Depending on the implementation (ASIC, NP or FPGA), they = might be adapted to recognize UDP-lite, but that's a lot of cost & work = ... *just* for one additional transport-layer protocol!= From fernando.gont.netbook.win@gmail.com Wed Jun 22 01:02:31 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1C1711E80A3; Wed, 22 Jun 2011 01:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.106 X-Spam-Level: X-Spam-Status: No, score=-3.106 tagged_above=-999 required=5 tests=[AWL=0.493, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 WmYyT0M9RdEC; Wed, 22 Jun 2011 01:02:28 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 246E711E8083; Wed, 22 Jun 2011 01:02:28 -0700 (PDT) Received: by gwb20 with SMTP id 20so334461gwb.31 for ; Wed, 22 Jun 2011 01:02:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=/YC2z89mL9IHfxEWkBO8Yo5VsclA1BOA4ViUh1zOmFo=; b=Zbk4kP/uQ0yRti1uowJGLsHzx5uL8oEvqY/6q0KuFkNdcgvPLbXaGMmP0IoW6DCuEY IaZ8st7SC6UTQEIJ3URNC/r1FyDbc/Xfyc+Eyh4nBnSc6Ov8xq5wFMEyGl5B2lxGtXMp bfeatc2QArGnc/iWKyC9kKCnVBYaaPdliQKag= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=tKUR0Xnm4pWQ6RfhjuzhEpIdktKm9Juv+CEART4oh3e4kYsNc2zdlYr6NZoAf26f6f siSe9cMmpsWcsC86pF9upmtY8IdVFDnSF5AD0I2QB1HwqG/AymXiWahtTw3u/JqQ/gee BeFHrz2MJulT0/RfBlXdRlaAJdx8qMojpe0Ko= Received: by 10.150.180.20 with SMTP id c20mr513389ybf.413.1308729747433; Wed, 22 Jun 2011 01:02:27 -0700 (PDT) Received: from [192.168.123.103] ([190.48.241.129]) by mx.google.com with ESMTPS id c26sm332012ana.47.2011.06.22.01.02.18 (version=SSLv3 cipher=OTHER); Wed, 22 Jun 2011 01:02:21 -0700 (PDT) Sender: Fernando Gont Message-ID: <4E01A187.6020008@gont.com.ar> Date: Wed, 22 Jun 2011 05:02:15 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Jean-Michel Combes Subject: Re: [v6ops] Question regarding Ra-Guard evasion (ND and extensio headers) References: <4DF291D0.7080707@gont.com.ar> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 08:02:32 -0000 Hi, Jean-Michel, On 06/16/2011 02:13 PM, Jean-Michel Combes wrote: > IMHO, this draft should update RFC 6105 (If so, RFC6105 reference > should move from Informative References section to the Normative > References one). Yep. > Just a comment about your example for the fragmentation case with 2 > Destination extensions: from RFC2460 (section 4.1), this only occurs > when there is also a Routing Header extension, so I have to add a RH > in your example (better chance to get a fragmentation :)) The specs allow for multiple instances of the same extension headers. Hence, even if possibly non-sensical, the example in Section 4.1 is legitime. > o draft-gont-6man-nd-extension-headers > > IMHO, this is not a good idea to forbid the use of IPv6 extension with > NDP messages, especially when the reason is partially based on > implementation issues (i.e. the implementation is not able to process > an IPv6 packet): Well, I'd argue that it is an operational issue, rather than an implementation issue. -- And chances are that if it is not possible to implement a simple solution for this concrete problem, some may start filtering *all* packets that include extension headers (in particular, those in which the uper layer protocol is not present in the first fragment) > today, there is no real use of Extension header with > NDP but, tomorrow, if we need such an use for a solution, what will > happen? Among the options is that we could state that implementations should provide a switch to enable the processing of extension headers, but that it should default to off. > Regarding the fragmentation, is it not possible for the RA-Guard > device to reassemble the fragments and so to be able to check whether > this a RA message or not? This would open the door to DoS attacks -- the attacker would simply fire lots of fragments that would never get to be reassembled. -- then you're back into the same place (or probably a worse one). Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From rja.lists@gmail.com Wed Jun 22 03:58:05 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6F311E80E4 for ; Wed, 22 Jun 2011 03:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.537 X-Spam-Level: X-Spam-Status: No, score=-3.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 WXhc4-h9U0g5 for ; Wed, 22 Jun 2011 03:58:04 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 58E1711E8076 for ; Wed, 22 Jun 2011 03:58:04 -0700 (PDT) Received: by vws12 with SMTP id 12so689796vws.31 for ; Wed, 22 Jun 2011 03:57:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to :x-mailer; bh=cD8uJw0MdgfxGb13IvP8YFAHW6vt8gpVNmY4chOu5xY=; b=bcl9XNGnrbGZAW5DhtwwE6eIMPbABP9gOh/yaXn1ogYStFcEenHifeNU0GAG+NJrFp 86fN0x+f6FA3WzxkustZoDIXku5rACv4nd9GJLYhultMDALbxEAETQzpLGfMC+H40kf+ IPIoLj7VSEJqCWS+xUChxZ6k7DhC8hw1qsZj4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=OURmcAXD6qKoRNBYa9xjPYHwcCZi0A/IXmswsJNeB2pmeapdsO74+Zk/TN2++WjQde lzvox28EENlwoBShXt8R8b7KegDUVmOs0lhAnItUI7C1yLhR3rwIoTzvcq4vKmm8rhsF dzfXlAuTOGrC+jZvrRc1ll3l2PjWQfkcMIdpA= Received: by 10.220.37.195 with SMTP id y3mr176299vcd.199.1308740277936; Wed, 22 Jun 2011 03:57:57 -0700 (PDT) Received: from [10.30.20.12] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id l1sm53752vco.18.2011.06.22.03.57.55 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Jun 2011 03:57:56 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) Subject: Re: AD review of draft-ietf-6man-flow-3697bis From: RJ Atkinson In-Reply-To: <8ACA53E6-AC3A-467A-941F-34F975584247@castlepoint.net> Date: Wed, 22 Jun 2011 06:57:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E00A71F.1000201@piuha.net> <3E9CAB5A-0692-4F56-A24D-EFB7E6627D0D@gmail.com> <8ACA53E6-AC3A-467A-941F-34F975584247@castlepoint.net> To: ipv6@ietf.org X-Mailer: Apple Mail (2.1084) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 10:58:05 -0000 On 22 Jun 2011, at 00:07 , Shane Amante wrote: > An example which routinely happens in today's networks would be link = restoration. =20 > In that case, the network is restoring traffic from a much longer path = to a > shorter, more optimal path in the network. Depending on the = transmission rate > of the transmitter, this can/will lead to temporary reordering of = microflows > at the receivers. Do note that in well-operated networks this = reordering is, > hopefully, transient and of an extremely short duration. =20 Note that similar to the above, having first packet in a flow travel a slightly different path than subsequent fragments due to ECMP/LAG differences is also predictably "transient" and "of an extremely short duration" (to use Shane's excellent phrasing). > Namely, deployed IPv6 routers *already* [should] identify fragmented > vs. non-fragmented packets, presumably by inspecting the "Next Header > field of the last header of the Unfragmentable Part" for value 44 > [RFC 2460, Section 4.5] for 'Fragment Header' for the purposes of > deciding whether /or not/ they should attempt to identify Next Headers > containing the Upper Layer protocol and, subsequently, the > {protocol, src_port & dst_port} that will be fed, (along with > {src_ip, dst_ip}), into LAG and/or ECMP hash algorithms for > fine-grained load-balancing. Exactly so. Side comment: Because many users/operators require that routers = implement wire-speed Access Control Lists, and most of those ACLs=20= include variables such as transport-layer protocol,=20 and transport-layer port numbers, ASIC/FPGA-based IPv6 routers will continue to parse into the IPv6 packet beyond the IPv6 base header *regardless* of whether that information is needed for ECMP/LAG/load-balancing purposes. I have heard credible reports of an ISP that apparently deploys=20= hundreds of ACL rules into the exterior border routers of their = AS,=20 and apparently that ISP deploys a smaller but still non-trivial=20= number into interior routers. =20 Of course, this also means they select their largest routers in = part=20 upon the routers' ability to support large numbers of ACLs at = full=20 wire-speed and also the ability to look past the occasional IPv6=20= extension header to examine the ICMP/TCP/UDP/etc headers behind = it. > "Conservative" router/switch implementations strive to reduce the risk = of > _persistent_ reordering of an individual microflow. IOW, since = non-first > fragments will not contain Upper Layer protocol information, = (specifically: > {src_port, dst_port}), that can be fed as input-keys to LAG and/or = ECMP hash > algorithms, the "safe" thing they should do is to only use the 2-tuple = of > {src_ip, dst_ip} as input-keys for _all_ fragments within a microflow. = =20 > Obviously, this leads to 'coarse-grained' load-balancing for = microflows > containing fragmented packets. Yes, and an important word above is "persistent", to echo Shane's = emphasis. As Shane observes, this implementation approach is common today. I = believe=20 some implementations today already include the Flow Label, simply = because=20 it is another available differentiator (albeit most commonly zero just = now),=20 not because of this current set of specifications. > If this draft is widely implemented & deployed and originating hosts = are > encoding a "uniformly distributed", non-zero flow-label in all packets > (fragmented or not), then it would seem logical that routers would be > adapted so that: >=20 > a) If they encounter a Fragment Header they use: {src_ip, dst_ip + = flow_label} > as input-keys to the LAG + ECMP hash algorithms; and/or, >=20 > b) If they encounter a Next Header with, for example, an Upper Layer = Protocol > that they have *not* (yet?) implemented a parsing routine to = extract > appropriate input-keys (or, can't, because it's too deep in the = packet's > headers), then they revert back to using {src_ip, dst_ip + = flow_label} > as input-keys to the LAG + ECMP hash algorithms[1]; and/or, >=20 > c) [Assuming widespread use of the flow-label], they no longer even = bother > looking at any Next Headers in all packets and _always_ use = {src_ip, > dst_ip + flow_label} for input-keys to LAG + ECMP hash = algorithms. >=20 > Personally, I see (a) & (b) as being a short- to medium-term "wins" > that could be safely implemented, by default, in the next-spin of NP, > FPGA SW and ASIC HW, given the existence of this, hopefully soon, RFC. = =20 Agreed. In some cases, I think (a) and (b) are already deployed. > Obviously, (c) is going to be a little further out.=20 I would apply the caveat from earlier to (c). =20 Routers will still be looking beyond the IPv6 header *for ACL purposes*,=20= even if those same routers use non-zero Flow Labels for ECMP/LAG,=20 rather than using transport-layer information for ECMP/LAG. > I would also point out a substantial additional advantage is = [long-term] > architectural flexibility in that the end-points (hosts) may freely = use > *new* transport protocols (SCTP, DCCP, UDP-lite, etc.) so long as they > continue to label all packets with a "uniformly distributed", > non-zero flow-label so that [Core] routers/switches have something > they can safely use as input-keys for LAG and/or ECMP hash algorithms. = =20 With respect to ECMP/LAG narrowly, I agree with the above. > At least, that's one part of the network that we don't need to worry > about upgrading to support new transport-layer protocols. = Unfortunately, > middleboxes (FW's or, more generally, "security GW's") might still = have > to be adapted depending on the applicability of the new = transport-layer > protocol to various network types, (e.g.: SOHO vs. Large-ish = Enterprise). Exactly so. Router-based ACLs (which are widespread -- even in=20 some deployed transit/backbone routers) will still need to support those=20= new transport-layer protocols BEFORE those new transport-layer protocols=20= will be practical to widely deploy. =20 Yours, Ran Atkinson PS: For implementations prior to this current set of documents, and for=20= routers creating Flow Labels on the fly, a useful additional input=20= to an ECMP/LAG function would be the "SPI" value of an ESP or AH = header.=20 From rja.lists@gmail.com Wed Jun 22 04:08:47 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706DE11E80EC; Wed, 22 Jun 2011 04:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.542 X-Spam-Level: X-Spam-Status: No, score=-3.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 6UFlrQx3Eakw; Wed, 22 Jun 2011 04:08:46 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A320811E8076; Wed, 22 Jun 2011 04:08:46 -0700 (PDT) Received: by vws12 with SMTP id 12so697770vws.31 for ; Wed, 22 Jun 2011 04:08:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:to:mime-version:x-mailer; bh=hXS7d8LvdktGkkaAFfyI+izS8lbrDjAbherUfbxN6R4=; b=BcD6n+NBHYu3MrHmDm8oDdOFL+m4tFq9NksFxUDHlyLCGRGqjjUE4+Rfhx+tlxvtFN 1s41jd3N96H4gI70rSiK8V3gDcEu3FpB6uM5vABc8yxBFo7dx4gAJynVzyPk3Mtyj5LY L9czHOOVsWIX6GhTEN4KvoGrko4+AttZuL5dY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=KyB0SV5l1xzh6+n5jyHGLsxaCb1PZM899pw3i2DB6ADd5NQHALlanPhpjO84i9eQnc pv6XOe7zIEpUnnMMfwtgzqdnEfTYxdMOqLpqu3+GWIxI0r7GsHft/l4wVy3GWJ3mAlkl 8NgJoz2qK2gYM4Ne3vbL35Et+waHM4hnGMXbs= Received: by 10.52.178.74 with SMTP id cw10mr761801vdc.141.1308740925954; Wed, 22 Jun 2011 04:08:45 -0700 (PDT) Received: from [10.30.20.12] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id c9sm118394vdv.40.2011.06.22.04.08.44 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Jun 2011 04:08:45 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) Date: Wed, 22 Jun 2011 07:08:43 -0400 Message-Id: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> To: v6ops@ietf.org, ipv6@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 11:08:47 -0000 On Weds, 22 June 2011, Fernando Gont wrote: On 06/16/2011 02:13 PM, Jean-Michel Combes wrote: >> o draft-gont-6man-nd-extension-headers >> =20 >> IMHO, this is not a good idea to forbid the use of IPv6 extension = with >> NDP messages, especially when the reason is partially based on >> implementation issues (i.e. the implementation is not able to = process >> an IPv6 packet):=20 >=20 > Well, I'd argue that it is an operational issue, rather than an > implementation issue. -- And chances are that if it is not possible to > implement a simple solution for this concrete problem, some may start > filtering *all* packets that include extension headers (in particular, > those in which the uper layer protocol is not present in the first = fragment) I agree with Jean-Michel Combes and disagree with Fernando. =20 It absolutely is an implementation issue -- specifically it is=20 a "quality of implementation" issue, not a complexity issue. More importantly, the implementation approach I described on the IPv6=20 list is neither complicated nor computationally expensive. In fact,=20 supporting the limited set of non-silly-for-ND-packet Extension Headers has tiny incremental memory footprint and tiny increase in the instruction count. The instruction count increase only applies if an actual Extension Header is encountered, btw. The code for a L2 device to locate the IPv6 header, read that header, and read into the ICMP message to determine that a packet is an ND packet *dwarfs* the code to skip past the small set of reasonable Extension Headers for ND packets. Please (re-)read this previous note: = =09 Yours, Ran From swmike@swm.pp.se Wed Jun 22 04:15:29 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696D411E8076; Wed, 22 Jun 2011 04:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 FwvltjcRT9+4; Wed, 22 Jun 2011 04:15:28 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4CD11E80A9; Wed, 22 Jun 2011 04:15:27 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id DD5D69C; Wed, 22 Jun 2011 13:15:26 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id DB5229A; Wed, 22 Jun 2011 13:15:26 +0200 (CEST) Date: Wed, 22 Jun 2011 13:15:26 +0200 (CEST) From: Mikael Abrahamsson To: RJ Atkinson Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) In-Reply-To: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> Message-ID: References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: v6ops@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 11:15:29 -0000 On Wed, 22 Jun 2011, RJ Atkinson wrote: > It absolutely is an implementation issue -- specifically it is a > "quality of implementation" issue, not a complexity issue. I feel that there should be guidance regarding this in the SAVI documentation, even if this is only a pointer to another document that describes how to parse an IPv6 packet. Just the same way that it's "obvious" that anyone can spoof RAs on a flat L2 lan, it's "obvious" that fragmentation and headers can make parsing actual payload harder and needs to be handled. These two "obvious" have historically been overlooked numerous times. Just the same way describing how to do SAVI L2.5 functionality to solve different security implications needs to be done to provide guidance to vendors, I also feel that they need to be helped to handle fragmentation attacks. -- Mikael Abrahamsson email: swmike@swm.pp.se From rja.lists@gmail.com Wed Jun 22 04:26:30 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E591211E80BC; Wed, 22 Jun 2011 04:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.546 X-Spam-Level: X-Spam-Status: No, score=-3.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 m7UMCfJ7AwAh; Wed, 22 Jun 2011 04:26:30 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 465F011E80F2; Wed, 22 Jun 2011 04:26:30 -0700 (PDT) Received: by gya6 with SMTP id 6so425010gya.31 for ; Wed, 22 Jun 2011 04:26:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to :x-mailer; bh=/3cQW3CutWt6V/t6i5oqm9K6xSTVY1piZ6L9QsseSS8=; b=uNqty9ts3/xmBbqZL0iyu95PJQqiVKOPawCCKo7lD+A26YjVNSSUg2FAincbeuVKJl Bj37F6v2NNLsNn5oabX0h62oNBhBiR3Z9ZWSEJPCnZbWnIfwpmOZ1tcp7Rotij7y19yq GYzTUjnuWkiAUYWTeoa9rp+Lb5hv9xUI/C8wo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=mr7D7xv7PObEO2tGZYxT5QMb7XUETPgxSVFhFA2XoB3UbUNQqTJhppoMtVyAaLE8IA SAqXwQWjh3wWnRKr5hnr5YYvRH2KgyiXExJRh5nq9fNAiLgqxLPKl8JWMHP0GyIG6WzV GYwhOVUrogLWzzZg4vhATEiwwiGxbTKdECbk4= Received: by 10.150.63.19 with SMTP id l19mr596628yba.369.1308741989508; Wed, 22 Jun 2011 04:26:29 -0700 (PDT) Received: from [10.30.20.12] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id u17sm134379ybl.3.2011.06.22.04.26.28 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Jun 2011 04:26:28 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) From: RJ Atkinson In-Reply-To: Date: Wed, 22 Jun 2011 07:25:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <41367707-D357-4A1E-BA0F-CC2EE10521F1@gmail.com> References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> To: v6ops@ietf.org, ipv6@ietf.org X-Mailer: Apple Mail (2.1084) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 11:26:31 -0000 On 22 Jun 2011, at 07:15 , Mikael Abrahamsson wrote: > On Wed, 22 Jun 2011, RJ Atkinson wrote: >> It absolutely is an implementation issue -- specifically it is >> a "quality of implementation" issue, not a complexity issue. >=20 > I feel that there should be guidance regarding this in the SAVI > documentation, even if this is only a pointer to another document > that describes how to parse an IPv6 packet. That seems useful to me. =20 > Just the same way that it's "obvious" that anyone can spoof RAs > on a flat L2 lan, it's "obvious" that fragmentation and headers > can make parsing actual payload harder and needs to be handled. > These two "obvious" have historically been overlooked numerous times. As the 17th June 2011 note I pointed to earlier today,=20 but did not repeat in its entirety, observed: A) the "Fragmentation Header" is clearly a security risk, so banning that makes sense. B) packet re-assembly can be expensive in (memory footprint, = computation). C) the "Routing Header" better not be in an ND packet in any case, since ND packets are supposedly link-local, and therefore not = applicable=20 for any ND packet, so banning that makes sense. That same note pointed out that the above analysis is NOT true for selected other IPv6 Extension Headers (i.e. the ones that=20 might actually be useful with ND), for example: 1) Hop-by-Hop Options header, which safely and trivially can be parsed past by a L2 device just implementing an RA Guard 2) Destination Options header, which also safely and trivially can be parsed past by a L2 device just implementing an RA Guard. =20 > Just the same way describing how to do SAVI L2.5 functionality to = solve > different security implications needs to be done to provide guidance > to vendors, I also feel that they need to be helped to handle = fragmentation attacks. That also sounds useful to me. Cheers, Ran From ipng@69706e6720323030352d30312d31340a.nosense.org Wed Jun 22 04:34:59 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E02CE11E810F; Wed, 22 Jun 2011 04:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.82 X-Spam-Level: X-Spam-Status: No, score=-2.82 tagged_above=-999 required=5 tests=[AWL=1.075, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 Ru513YrG-Ff6; Wed, 22 Jun 2011 04:34:58 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id EE59911E8104; Wed, 22 Jun 2011 04:34:57 -0700 (PDT) Received: from 219-90-231-100.ip.adam.com.au ([219.90.231.100] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QZLhs-0004iP-BS; Wed, 22 Jun 2011 21:04:52 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 68A993B341; Wed, 22 Jun 2011 21:04:51 +0930 (CST) Date: Wed, 22 Jun 2011 21:04:51 +0930 From: Mark Smith To: Philip Homburg Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) Message-ID: <20110622210451.60ad8bce@opy.nosense.org> In-Reply-To: References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.4; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, v6ops@ietf.org, RJ Atkinson X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 11:34:59 -0000 On Wed, 22 Jun 2011 13:18:49 +0200 Philip Homburg wrote: > In your letter dated Wed, 22 Jun 2011 07:08:43 -0400 you wrote: > >More importantly, the implementation approach I described on the IPv6 > >list is neither complicated nor computationally expensive. In fact, > >supporting the limited set of non-silly-for-ND-packet Extension Headers > >has tiny incremental memory footprint and tiny increase in the > >instruction count. The instruction count increase only applies if > >an actual Extension Header is encountered, btw. The code for a L2 > >device to locate the IPv6 header, read that header, and read into > >the ICMP message to determine that a packet is an ND packet *dwarfs* > >the code to skip past the small set of reasonable Extension Headers > >for ND packets. > > I have to admit I don't know much about the internals of L2 switches. But > my mental model of a 10 Gbit/s ethernet switch is that of an ASIC/FPGA that > does almost all forwarding with the CPU just for management. > > I've no idea how expensive it would be to parse extension headers in an ASIC. > > I think it is a bit ironic that if a L2 device has to parse all extension > headers, that then L2 switching of IPv6 packets will be more expensive that > L3 routing them. > It may be getting to the point where it'd probably be easier to address these issues by taking away hosts' ability to multicast to other hosts on the same segment i.e. switch to an NBMA/hub-and-spoke mode of LAN operation, allowing the designated routers to also act as traffic sanitisers for on-link inter-host traffic. Regards, Mark. From swmike@swm.pp.se Wed Jun 22 04:41:34 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED69A21F84CA; Wed, 22 Jun 2011 04:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 KJrjv04kNE5F; Wed, 22 Jun 2011 04:41:34 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFC921F84C8; Wed, 22 Jun 2011 04:41:33 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E1D4C9C; Wed, 22 Jun 2011 13:41:32 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id DE0C19A; Wed, 22 Jun 2011 13:41:32 +0200 (CEST) Date: Wed, 22 Jun 2011 13:41:32 +0200 (CEST) From: Mikael Abrahamsson To: ipv6@ietf.org Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) In-Reply-To: <20110622210451.60ad8bce@opy.nosense.org> Message-ID: References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> <20110622210451.60ad8bce@opy.nosense.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 11:41:35 -0000 On Wed, 22 Jun 2011, Mark Smith wrote: > It may be getting to the point where it'd probably be easier to address > these issues by taking away hosts' ability to multicast to other hosts > on the same segment i.e. switch to an NBMA/hub-and-spoke mode of LAN > operation, allowing the designated routers to also act as traffic > sanitisers for on-link inter-host traffic. I agree, that's the deployment model I advocate for hostile scenarios. Use DHCPv6 for stateful addressing, advertise default GW via RA, don't advertise any on-link prefix, and make sure hosts can't L2 communicate at all with each other by means of enforcement in switches (or just separate them into different L2 domains). -- Mikael Abrahamsson email: swmike@swm.pp.se From rja.lists@gmail.com Wed Jun 22 05:04:42 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD99F11E80EF; Wed, 22 Jun 2011 05:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.549 X-Spam-Level: X-Spam-Status: No, score=-4.549 tagged_above=-999 required=5 tests=[AWL=1.050, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] 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 EslmHyhT0Gv6; Wed, 22 Jun 2011 05:04:42 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id CBBDB11E80BC; Wed, 22 Jun 2011 05:04:41 -0700 (PDT) Received: by qwc23 with SMTP id 23so504774qwc.31 for ; Wed, 22 Jun 2011 05:04:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to :x-mailer; bh=beP2+K2W3+PrXc7PNCdM7T1yro8qQ9IKGYYzxcaDO8A=; b=vbzgvscXvO6OOC8JyiMbnar95n/YWY4bdhhhopMGRfSwOJwBJVvFiI7GFHuBDvlGMT rLJOzDlMus+YH4+L+vYIwJMEMyn78MpDe2KLgcmWvhCUDiTufYZrcC07ZD8DwFWopvw0 gxgM0NZ/yILVyRnt0XEeupMqhZW1OQd01uy+s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=tEX1cytri+0snGsDpXtMkK8aIS85TCLEK9oyxGEm52veX61a1go8ZTf8k2vGOgdwyE oav5aam0PwLFJCO/BWNLftYo9G+o5E1dwWd0sP9VSfSVZDZWnllAPVzRgiXQPJbA5vJJ rpuQ15I5bLESgTq8aIrHs9oAH5Wy8PNrQdiEY= Received: by 10.224.183.206 with SMTP id ch14mr381242qab.343.1308744281101; Wed, 22 Jun 2011 05:04:41 -0700 (PDT) Received: from [10.30.20.12] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id p10sm373900qcu.13.2011.06.22.05.04.39 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Jun 2011 05:04:40 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) From: RJ Atkinson In-Reply-To: Date: Wed, 22 Jun 2011 08:04:39 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: To: v6ops@ietf.org, ipv6@ietf.org X-Mailer: Apple Mail (2.1084) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 12:04:42 -0000 On 22 Jun 2011, at 07:18 , Philip Homburg wrote: > In your letter dated Wed, 22 Jun 2011 07:08:43 -0400 you wrote: >> More importantly, the implementation approach I described on the IPv6 >> list is neither complicated nor computationally expensive. In fact, >> supporting the limited set of non-silly-for-ND-packet Extension Headers >> has tiny incremental memory footprint and tiny increase in the >> instruction count. The instruction count increase only applies if >> an actual Extension Header is encountered, btw. The code for a L2 >> device to locate the IPv6 header, read that header, and read into >> the ICMP message to determine that a packet is an ND packet *dwarfs* >> the code to skip past the small set of reasonable Extension Headers >> for ND packets. > > I have to admit I don't know much about the internals of L2 switches. > But my mental model of a 10 Gbit/s ethernet switch is that of an > ASIC/FPGA that does almost all forwarding with the CPU just for management. I spent most of the last decade building high-performance Ethernet switches. Your mental model is generally the case, but that ASIC/FPGA often already includes IPv4/IPv6 routing capability including some degree of packet parsing capability. (Even the low-cost "consumer electronics" L2 switches now often/commonly use a commodity ASIC that includes at least some L3 capabilities -- although a given product might or might not software-enable those chip features.) Some chips can parse/parse-past any legal combination of IPv4/IPv6 headers at wire-speed. Some can parse past a subset, again at wire-speed, with the most common IPv6 subset being the Routing Header, Destination Options header, and Hop-by-Hop header. I know of at least 2 Ethernet switch vendors that already have sold/deployed ASIC/FPGA-based switches that can parse past IPv6 extension headers (i.e. to read transport-layer header information & provide wire-speed ACLs, to handle an ICMPv6 message, etc.). For the genuine L2-only ASIC/FPGA devices, those without ANY L3 capabilities, any form of Fernando's proposal will require that **all** IPv6 packets, anything with (EtherType=0x86dd) not just all IPv6 ND packets, be sent via the CPU. As you noted later on, this precise situation leads to real challenges in throughput, switch resilience, etc. In such a pure-L2-only case, the big performance hit is parsing INTO the IPv6 packet in the first place. One won't even be able to detect whether a packet is an ND packet until one has parsed inside the ICMPv6 header. Best case, getting that far in is a bunch of CPU instructions for each IPv6 packet. Once one has decided to do that, which might or might not be a wise product-management decision, then parsing past the Dest Opts Header or Hop-by-Hop Header is a tiny incremental hit that applies only to those packets with such headers. Of course, packet reassembly IS expensive. This is why my proposal does NOT disagree with Fernando's proposal to outright ban the IPv6 Fragment Header for IPv6 ND packets. > I've no idea how expensive it would be to parse > extension headers in an ASIC. Good question. I have data. For one implementation I am very familiar with, that Verilog did not significantly increase the gate count, did not make gate layout/place harder, and did not increase the die size. Folks I know who worked on a genetically different ASIC with similar packet parsing capabilities tell me their experience was roughly the same (i.e. gate count increase was minor, no new layout/place issues, and no increase in chip die size). So my answer would be "not very expensive", based on actual experience with this in a commercial product environment. > I think it is a bit ironic that if a L2 device has to parse > all extension headers, that then L2 switching of IPv6 packets > will be more expensive that L3 routing them. For a pure L2-device, without any L3 hardware capabilities, one imagines that the most common product-manaagement decision would be to ignore Fernando's entire spec (and not claim to support it). Again, for a pure L2-device, the expensive part of Fernando's spec is parsing from (EtherType==0x86dd) and start-of-frame to the point where the switch can learn that the packet contains ICMPv6 and that the ICMP Type indicates an ND packet. Parsing past the Dest Opts header & Hop-by-Hop header is a tiny incremental CPU hit (a few assembler instructions) on that basic unavoidable cost. For an L3-capable chip, it often is still possible to use some of the chip's L3 features (e.g. packet parsing) even when the chip is bridging a frame instead of routing a packet. So for the devices using an L3-capable chip, it is not necessarily the case that L2 switching would be more expensive than L3 routing. (Obviously L2 switching with an RA-Guard could be more expensive than L3 routing with RA-Guard for particular chip implementations; I have no doubt that some such chips both exist and are present in some commonly deployed devices.) I do think there is a real question of how deployable Fernando's RA Guard proposal will be *in the near term*. In the longer term, one would hope that the chipset vendors that need to spin a chip would plan for this whenever they do such a spin. (Ultimately, the market will decide whether Fernando's spec deploys, even if the IETF endorses it, as is true with so many notional capabilities.) Cheers, Ran From rja.lists@gmail.com Wed Jun 22 05:11:02 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C82911E8103; Wed, 22 Jun 2011 05:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 2K2nAmWC6zX3; Wed, 22 Jun 2011 05:11:00 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id CF08611E8130; Wed, 22 Jun 2011 05:10:30 -0700 (PDT) Received: by vxi40 with SMTP id 40so741000vxi.31 for ; Wed, 22 Jun 2011 05:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to :x-mailer; bh=7MJM4abPoPN0d7FzVl4f8o+FnWOs8NwrRv69wkcFTIw=; b=liPRX99zW2gmVyRurxvirDlFaiPeaA39au1KMYbXFvO6nVbZPAu1d0G898EcXvx0j7 4bSngtNdCOHiXJVa+kfxefS/7h4lnX4KvDr1nPxTaBbPF5eEM6Hev/KMq2qV16rCm/XX Mh+j6FSW5gj2SN52qjc1TY0JuOgymQ5rCkkww= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=GFehdTpb7n6EKAc4fF+BkC4mEQ3yXuN63gOFcN64wKlu38mPvAgGN1px4KH2345FbJ oCfJnXNQX/Tz8HBeJyqHgCi4V7o/qc0OQT4V7JwQ3zo41f3nGNovKHTmfOcC6sW1uGe5 hVTSwIaZHdpe5oCKk8Wyu30cU+HwkHw3Sag7M= Received: by 10.220.5.10 with SMTP id 10mr227760vct.107.1308744630189; Wed, 22 Jun 2011 05:10:30 -0700 (PDT) Received: from [10.30.20.12] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id dt10sm59398vcb.24.2011.06.22.05.10.28 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Jun 2011 05:10:29 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) From: RJ Atkinson In-Reply-To: <20110622210451.60ad8bce@opy.nosense.org> Date: Wed, 22 Jun 2011 08:10:27 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> <20110622210451.60ad8bce@opy.nosense.org> To: v6ops@ietf.org, ipv6@ietf.org X-Mailer: Apple Mail (2.1084) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 12:11:02 -0000 On 22 Jun 2011, at 07:34 , Mark Smith wrote: > It may be getting to the point where it'd probably be easier > to address these issues by taking away hosts' ability to multicast > to other hosts on the same segment i.e. switch to an NBMA/hub-and-spoke > mode of LAN operation, allowing the designated routers to also > act as traffic sanitisers for on-link inter-host traffic. That is possible; doing so would create a new and different set of operational issues and implementation issues. It isn't immediately obvious to me that the alternative set of issues would be simpler/cheaper/easier than the issues Fernando's proposal raises. Another more fundamental question is how much operational risk the folks who deploy edge networks believe they have, and how much operational risk those folks are comfortable with. Some or many such operational folks might find all of these concepts to have excessive capital and operational expense for the perceived risk reduction. They might conclude that the "cure" is worse than the "disease". Yours, Ran From pch-b2B3A6689@u-1.phicoh.com Wed Jun 22 04:19:03 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 476A511E80F2; Wed, 22 Jun 2011 04:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.532 X-Spam-Level: X-Spam-Status: No, score=-8.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] 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 BwNJAx8ZU5eg; Wed, 22 Jun 2011 04:19:02 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9B311E80BC; Wed, 22 Jun 2011 04:19:01 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QZLSP-0001h8C; Wed, 22 Jun 2011 13:18:53 +0200 Message-Id: To: RJ Atkinson Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com In-reply-to: Your message of "Wed, 22 Jun 2011 07:08:43 -0400 ." <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> Date: Wed, 22 Jun 2011 13:18:49 +0200 X-Mailman-Approved-At: Wed, 22 Jun 2011 05:51:43 -0700 Cc: v6ops@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 11:19:03 -0000 In your letter dated Wed, 22 Jun 2011 07:08:43 -0400 you wrote: >More importantly, the implementation approach I described on the IPv6 >list is neither complicated nor computationally expensive. In fact, >supporting the limited set of non-silly-for-ND-packet Extension Headers >has tiny incremental memory footprint and tiny increase in the >instruction count. The instruction count increase only applies if >an actual Extension Header is encountered, btw. The code for a L2 >device to locate the IPv6 header, read that header, and read into >the ICMP message to determine that a packet is an ND packet *dwarfs* >the code to skip past the small set of reasonable Extension Headers >for ND packets. I have to admit I don't know much about the internals of L2 switches. But my mental model of a 10 Gbit/s ethernet switch is that of an ASIC/FPGA that does almost all forwarding with the CPU just for management. I've no idea how expensive it would be to parse extension headers in an ASIC. I think it is a bit ironic that if a L2 device has to parse all extension headers, that then L2 switching of IPv6 packets will be more expensive that L3 routing them. From joelja@bogus.com Wed Jun 22 08:24:16 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D7511E8135; Wed, 22 Jun 2011 08:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 HfzPJwGfPoRZ; Wed, 22 Jun 2011 08:24:15 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 918AC11E8141; Wed, 22 Jun 2011 08:24:11 -0700 (PDT) Received: from [10.168.76.183] (8.sub-166-250-39.myvzw.com [166.250.39.8]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p5MFO68S038499 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 22 Jun 2011 15:24:08 GMT (envelope-from joelja@bogus.com) Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: Date: Wed, 22 Jun 2011 08:24:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> <20110622210451.60ad8bce@opy.nosense.org> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Wed, 22 Jun 2011 15:24:09 +0000 (UTC) X-Mailman-Approved-At: Wed, 22 Jun 2011 08:31:51 -0700 Cc: v6ops@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 15:24:17 -0000 On Jun 22, 2011, at 4:41 AM, Mikael Abrahamsson wrote: > On Wed, 22 Jun 2011, Mark Smith wrote: >=20 >> It may be getting to the point where it'd probably be easier to = address these issues by taking away hosts' ability to multicast to other = hosts on the same segment i.e. switch to an NBMA/hub-and-spoke mode of = LAN operation, allowing the designated routers to also act as traffic = sanitisers for on-link inter-host traffic. >=20 > I agree, that's the deployment model I advocate for hostile scenarios. = Use DHCPv6 for stateful addressing, advertise default GW via RA, don't = advertise any on-link prefix, and make sure hosts can't L2 communicate = at all with each other by means of enforcement in switches (or just = separate them into different L2 domains). controller based wireless deployments can largely do this for ipv4 (and = v6 to some extent) today. it's a fairly heavyweight approach for lightly = managed networks. > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From Fred.L.Templin@boeing.com Wed Jun 22 08:39:23 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112BA11E80BD; Wed, 22 Jun 2011 08:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] 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 EkFKMPMNPvZY; Wed, 22 Jun 2011 08:39:20 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id BD3AE11E80B2; Wed, 22 Jun 2011 08:39:20 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p5MFdE2c028406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 22 Jun 2011 08:39:15 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p5MFdE56015930; Wed, 22 Jun 2011 10:39:14 -0500 (CDT) Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p5MFdDLG015900 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 22 Jun 2011 10:39:14 -0500 (CDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Wed, 22 Jun 2011 08:39:13 -0700 From: "Templin, Fred L" To: Mikael Abrahamsson , "ipv6@ietf.org" Date: Wed, 22 Jun 2011 08:39:12 -0700 Subject: RE: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) Thread-Topic: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) Thread-Index: Acww0V/B8oFydOorTD28z0GyW5fq1gAH/1mQ Message-ID: References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> <20110622210451.60ad8bce@opy.nosense.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 15:39:23 -0000 Mark and Mikael, > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]=20 > On Behalf Of Mikael Abrahamsson > Sent: Wednesday, June 22, 2011 4:42 AM > To: ipv6@ietf.org > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND=20 > and extension headers) >=20 > On Wed, 22 Jun 2011, Mark Smith wrote: >=20 > > It may be getting to the point where it'd probably be=20 > easier to address=20 > > these issues by taking away hosts' ability to multicast to=20 > other hosts=20 > > on the same segment i.e. switch to an NBMA/hub-and-spoke=20 > mode of LAN=20 > > operation, allowing the designated routers to also act as traffic=20 > > sanitisers for on-link inter-host traffic. That's just how ISATAP works when the advertising ISATAP routers do not advertise on-link IPV6 prefixes. However, the advertising ISATP routers can also send ICMPv6 Redirects - which is really still in keeping with your characterization of "traffic sanitiser". > I agree, that's the deployment model I advocate for hostile=20 > scenarios. Use=20 > DHCPv6 for stateful addressing, advertise default GW via RA, don't=20 > advertise any on-link prefix, That's exactly the model I had in mind for ISATAP. > and make sure hosts can't L2=20 > communicate at=20 > all with each other by means of enforcement in switches (or=20 > just separate=20 > them into different L2 domains). This would certainly enforce a true hub-and-spokes, but may be overly restrictive in some environments. For example, if a host has a way of knowing at L2 that a packet has come from a trusted router and not an anonymous node on the link then there may not be such a strong requirement for L2 segregation. ISATAP provides such a means. Thanks - Fred fred.l.templin@boeing.com > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > = From jeroen@unfix.org Wed Jun 22 11:27:52 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 868F221F84D1 for ; Wed, 22 Jun 2011 11:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 aHqe1yDWjO57 for ; Wed, 22 Jun 2011 11:27:51 -0700 (PDT) Received: from abaddon.unfix.org (abaddon.unfix.org [62.220.146.203]) by ietfa.amsl.com (Postfix) with ESMTP id DEBA521F8466 for ; Wed, 22 Jun 2011 11:27:50 -0700 (PDT) Received: from yomi.ch.unfix.org (yomi.ch.unfix.org [IPv6:2001:41e0:ff42:99:ca2a:14ff:fe1f:2b7b]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by abaddon.unfix.org (Postfix) with ESMTPSA id 2D5B3209AB for ; Wed, 22 Jun 2011 20:27:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unfix.org; s=DKIM2009; t=1308767265; bh=yRLyJx//MchBCtpNLNrvRrU3ecDAWjJ4nKiQBvjXLg0=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=GrhrUM9wyqIVxhFzZyCTDFg6Wecq16/LJvdSg6HezSjGABKCSF1pyzZ2fwobUhcc7 NH2OEekYmkiHkn/Sd2SJVziJUmFVROjsnbOcRqthOiB1RqSxiQM6HccOFzNNI/m2PD hS5CXECYGWdgl5bCaEa/VXwzdrm+zkWWOol7+8vbkW8CG4NY+L9FxnaAQYsLhK5N3O W92NvN/nC3OIiiYQnQcVPAW+FDHi9d0uhENsVpImIi/QeeZEox1akmFhx4i+xTd54F EwJjtEywAbMrnlD2PkKmkQhePM2iDOvlaMut3W9BoaYidreQtDBRHEmZYECTXmRdk8 RzJl0hzyvaMKw== Message-ID: <4E02341F.8070700@unfix.org> Date: Wed, 22 Jun 2011 20:27:43 +0200 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: IETF IPv6 Subject: TTL/hopcount becomes 0, what to send back, original packet with TTL = 1 or the one with TTL = 0? X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 18:27:52 -0000 Hi, I was wondering about the question in the subject. One gets a packet, the TTL/Hopcount is one, as I am the router, I subtract 1, then realize it is 0 and have to send out an ICMP unreachable as I want to actually forward it on to the next router/host. Now, the question is, do I need to send back the _original_ header containing TTL=1 in the payload of the ICMP or the new header with a TTL of 0? The question becomes more interesting when one receives a packet with TTL=0 from some malicious sender, what to do with that one? Greets, Jeroen From fred@cisco.com Wed Jun 22 13:04:55 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 026D711E8149; Wed, 22 Jun 2011 13:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.731 X-Spam-Level: X-Spam-Status: No, score=-110.731 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 M46k1TRS+Q6l; Wed, 22 Jun 2011 13:04:53 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id A359711E813D; Wed, 22 Jun 2011 13:04:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1289; q=dns/txt; s=iport; t=1308773093; x=1309982693; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=QzSCD9FhBAFpB8tmd4lQ2e5l6m6ErB99p6FIsP4glNM=; b=hbcO5ciIdLvnsKNKYECjgRaiERMv4fYpAy7eZ/w5LMS59biW378tjwO4 LyYZVKenEsuZJ0NwoRjhx0HTovRso6PGkQk3A0D0/k5He3aB6oVWQabSX OZV/6y179Ceu1eE7eH+9jMm8NzkNLVJaB12BA97fnneDPr7RNKU7w/N/X c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIVKAk6rRDoI/2dsb2JhbABTpxF3iHOiRp45hi0EhyWKRYRli0c X-IronPort-AV: E=Sophos;i="4.65,407,1304294400"; d="scan'208";a="344358256" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 22 Jun 2011 20:04:53 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5MK4jWQ024694; Wed, 22 Jun 2011 20:04:51 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Wed, 22 Jun 2011 13:04:52 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Wed, 22 Jun 2011 13:04:52 -0700 Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Wed, 22 Jun 2011 13:04:35 -0700 Message-Id: References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, v6ops@ietf.org, RJ Atkinson X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 20:04:55 -0000 On Jun 22, 2011, at 4:15 AM, Mikael Abrahamsson wrote: > Just the same way that it's "obvious" that anyone can spoof RAs on a = flat L2 lan, it's "obvious" that fragmentation and headers can make = parsing actual payload harder and needs to be handled. These two = "obvious" have historically been overlooked numerous times. =46rom my perspective, the issue with the RA-Guard evasion draft isn't = that the faults are possible or that they are described; it's that the = description is specific to RA-Guard. In point of fact, these kinds of = attacks are true for any kind of firewall or other middleware that has = the notion of identifying a specific non-IP packet and selectively do = something to it. I personally think the right way to approach this is to = describe the attack and note, in a footnote somewhere, that one of the = ten thousand special cases it applies to is RA Guard. Another one that = it applies to is any case of deep packet inspection, a specific special = case of that being Cleanfeed - anyone that thinks they can use deep = packet inspection to eliminate pornography, Al-Queda literature, or dog = racing should be advised that overcoming that is as simple as https or = obscure fragmentation that splits a "GET" at a difficult place.= From Ted.Lemon@nominum.com Wed Jun 22 13:19:09 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F5722800F; Wed, 22 Jun 2011 13:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, 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 fcX0mVRy1O92; Wed, 22 Jun 2011 13:19:09 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) by ietfa.amsl.com (Postfix) with ESMTP id 686A3228006; Wed, 22 Jun 2011 13:19:07 -0700 (PDT) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id B3F0E19005C; Wed, 22 Jun 2011 13:19:06 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 22 Jun 2011 13:18:54 -0700 Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) MIME-Version: 1.0 (Apple Message framework v1237.1) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: Date: Wed, 22 Jun 2011 16:18:50 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> <20110622210451.60ad8bce@opy.nosense.org> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1237.1) Cc: v6ops@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 20:19:10 -0000 On Jun 22, 2011, at 7:41 AM, Mikael Abrahamsson wrote: > I agree, that's the deployment model I advocate for hostile scenarios. = Use DHCPv6 for stateful addressing, advertise default GW via RA, don't = advertise any on-link prefix, and make sure hosts can't L2 communicate = at all with each other by means of enforcement in switches (or just = separate them into different L2 domains). Huh. If I had a choice between RA and multicast, I think I'd choose = multicast. When you have to utterly cripple your technology in order = to continue using a protocol, I think it's time to ask whether or not = the protocol you're using is the right protocol at all. From ipng@69706e6720323030352d30312d31340a.nosense.org Wed Jun 22 17:26:00 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD07C21F8473; Wed, 22 Jun 2011 17:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.035 X-Spam-Level: X-Spam-Status: No, score=-2.035 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 wORIxxoVLE8K; Wed, 22 Jun 2011 17:26:00 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id 3D31C21F8472; Wed, 22 Jun 2011 17:25:59 -0700 (PDT) Received: from 219-90-231-100.ip.adam.com.au ([219.90.231.100] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QZXjz-0008LV-6c; Thu, 23 Jun 2011 09:55:51 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 52D9C3B33E; Thu, 23 Jun 2011 09:55:50 +0930 (CST) Date: Thu, 23 Jun 2011 09:55:48 +0930 From: Mark Smith To: Ted Lemon Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) Message-ID: <20110623095548.24d89d7f@opy.nosense.org> In-Reply-To: References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> <20110622210451.60ad8bce@opy.nosense.org> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 00:26:01 -0000 Hi Ted, On Wed, 22 Jun 2011 16:18:50 -0400 Ted Lemon wrote: > On Jun 22, 2011, at 7:41 AM, Mikael Abrahamsson wrote: > > I agree, that's the deployment model I advocate for hostile scenarios. Use DHCPv6 for stateful addressing, advertise default GW via RA, don't advertise any on-link prefix, and make sure hosts can't L2 communicate at all with each other by means of enforcement in switches (or just separate them into different L2 domains). > > Huh. If I had a choice between RA and multicast, I think I'd choose multicast. When you have to utterly cripple your technology in order to continue using a protocol, I think it's time to ask whether or not the protocol you're using is the right protocol at all. > You're right, with Ethernet being the wrong protocol. An Ethernet LAN's nature is peer-to-peer or full mesh - every attached node can send to any other individual node, many other nodes, or all other nodes. For SPs who want to bill for, and possibly control/sanitise their inter-customer traffic, this link layer peer-to-peer nature is a problem. Hub-and-spoke or point-to-point reachability is what they want. If it is possible to enforce a hub-or-spoke topology on an Ethernet LAN by preventing the 1-to-many or 1-to-any capability, in effect making it an NBMA link-layer, or creating a point-to-point topology via VLANs, then Ethernet is the best choice because it is both cheap and ubiquitous. Regards, Mark. From ipng@69706e6720323030352d30312d31340a.nosense.org Wed Jun 22 17:29:06 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B77BC11E808A; Wed, 22 Jun 2011 17:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 HG63oLdoy5NN; Wed, 22 Jun 2011 17:29:06 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id D4B7E11E8071; Wed, 22 Jun 2011 17:29:05 -0700 (PDT) Received: from 219-90-231-100.ip.adam.com.au ([219.90.231.100] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QZXn6-00009K-SK; Thu, 23 Jun 2011 09:59:05 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 90F733B33E; Thu, 23 Jun 2011 09:59:04 +0930 (CST) Date: Thu, 23 Jun 2011 09:59:04 +0930 From: Mark Smith To: RJ Atkinson Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) Message-ID: <20110623095904.554dc351@opy.nosense.org> In-Reply-To: References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> <20110622210451.60ad8bce@opy.nosense.org> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 00:29:06 -0000 Hi Ran, On Wed, 22 Jun 2011 08:10:27 -0400 RJ Atkinson wrote: > > On 22 Jun 2011, at 07:34 , Mark Smith wrote: > > It may be getting to the point where it'd probably be easier > > to address these issues by taking away hosts' ability to multicast > > to other hosts on the same segment i.e. switch to an NBMA/hub-and-spoke > > mode of LAN operation, allowing the designated routers to also > > act as traffic sanitisers for on-link inter-host traffic. > > That is possible; doing so would create a new and different set > of operational issues and implementation issues. It isn't > immediately obvious to me that the alternative set of issues would be > simpler/cheaper/easier than the issues Fernando's proposal raises. > Part of what influenced my suggestion is that mechanisms to implement these sorts of controls already exist in some layer 2 devices - the private vlan feature and placing devices into specific VLANs based on 802.1x authentication. So for environments where rouge RAs are a likelihood, some of these mechanisms, possibly with some necessary changes or additions to IPv6 (e.g. DUD proxy) might be more a more effective and more general "traffic sanitation" solution for all ND based threats, including rogue RAs, spoofed ND NAs etc. > Another more fundamental question is how much operational risk the > folks who deploy edge networks believe they have, and how much > operational risk those folks are comfortable with. Some or many such > operational folks might find all of these concepts to have excessive > capital and operational expense for the perceived risk reduction. > They might conclude that the "cure" is worse than the "disease". > I completely agree, the security context definitely needs to be considered. A drawback of making a change as fundamental as, for example, prohibiting fragmentation in ND messages, is that it implies that it is necessary in any and all contexts. That may not actually be true. In the contexts where rouge RAs are a likelihood (e.g. public wifi, "IPoE" SP networks, etc.) rather than a rare accident , then some of the other layer 2 traffic control mechanisms I mentioned are probably going to be deployed. I wonder if their likely presence reduces the need to make such fundamental changes to IPv6 as disabling fragmentation in ND. With the relatively large number of subnets available in IPv6, up to a point it is practical to have a single host-router pair in a subnet. Once you do that, the only possible victims of these threats are the host itself or the router it depends on for off-link reachability, and those router consequences will or can be limited to the router's host facing interface. These types of on-link threats have now been mitigated or eliminated by individually quarantining each host and using their own self-interest to control their behaviour. Best regards, Mark. From Ted.Lemon@nominum.com Wed Jun 22 17:57:00 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75D2D21F852C; Wed, 22 Jun 2011 17:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.456 X-Spam-Level: X-Spam-Status: No, score=-106.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 NT9jisWcGeAh; Wed, 22 Jun 2011 17:57:00 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 7B26121F852B; Wed, 22 Jun 2011 17:56:59 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTgKPWiLAlY1yWMUKfoszIKcnaS0W94xL@postini.com; Wed, 22 Jun 2011 17:56:59 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 342C01B8581; Wed, 22 Jun 2011 17:56:58 -0700 (PDT) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 14410190058; Wed, 22 Jun 2011 17:56:58 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 22 Jun 2011 17:56:57 -0700 Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) MIME-Version: 1.0 (Apple Message framework v1242) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <20110623095548.24d89d7f@opy.nosense.org> Date: Wed, 22 Jun 2011 20:56:52 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> <20110622210451.60ad8bce@opy.nosense.org> <20110623095548.24d89d7f@opy.nosense.org> To: Mark Smith X-Mailer: Apple Mail (2.1242) Cc: v6ops@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 00:57:00 -0000 On Jun 22, 2011, at 8:25 PM, Mark Smith wrote: > You're right, with Ethernet being the wrong protocol. Well, let's be clear here: Ethernet is apparently the wrong protocol = *for you*. You should be running 802.1x, not plain ethernet, because = you have specific needs that make plain ethernet an inappropriate choice = for you. But that wasn't what I was talking about. IPv6 has to work on = ethernet. IPv6 multicast is useful, and we (at least, some of us) want = it to work. The solution to the rogue RA problem is not to get rid of = ethernet (or at least, so I claim). Moreover, even supposing we could = get rid of ethernet in the sense that you mean, that would simply paper = over the problem, not solve it. If we want a secure network, we have = to use secure protocols. Firewalls are a great second-level defense = (and your hub-and-spoke model is basically a firewall). But they do = not make your network secure: they simply make it harder to attack. So if in fact it is impossible for RA to be adequately secured on an = ethernet, then we need to fix RA, or come up with a different solution, = not slap a bandage on it and call it done. From swmike@swm.pp.se Wed Jun 22 22:48:38 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8E61F0C4A; Wed, 22 Jun 2011 22:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 jTwtSSQumrGU; Wed, 22 Jun 2011 22:48:38 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5451F0C4E; Wed, 22 Jun 2011 22:48:36 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E97559C; Thu, 23 Jun 2011 07:48:32 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E5D529A; Thu, 23 Jun 2011 07:48:32 +0200 (CEST) Date: Thu, 23 Jun 2011 07:48:32 +0200 (CEST) From: Mikael Abrahamsson To: Ted Lemon Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) In-Reply-To: Message-ID: References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> <20110622210451.60ad8bce@opy.nosense.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 05:48:38 -0000 On Wed, 22 Jun 2011, Ted Lemon wrote: > On Jun 22, 2011, at 7:41 AM, Mikael Abrahamsson wrote: >> I agree, that's the deployment model I advocate for hostile scenarios. Use DHCPv6 for stateful addressing, advertise default GW via RA, don't advertise any on-link prefix, and make sure hosts can't L2 communicate at all with each other by means of enforcement in switches (or just separate them into different L2 domains). > > Huh. If I had a choice between RA and multicast, I think I'd choose > multicast. When you have to utterly cripple your technology in order to > continue using a protocol, I think it's time to ask whether or not the > protocol you're using is the right protocol at all. Could you please rephrase the above, I don't understand. Protocol? -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Wed Jun 22 23:34:08 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E58021F847A; Wed, 22 Jun 2011 23:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 V0oNwSMWADjy; Wed, 22 Jun 2011 23:34:08 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0B721F8453; Wed, 22 Jun 2011 23:34:07 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 417F09C; Thu, 23 Jun 2011 08:34:05 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3CE759A; Thu, 23 Jun 2011 08:34:05 +0200 (CEST) Date: Thu, 23 Jun 2011 08:34:05 +0200 (CEST) From: Mikael Abrahamsson To: Mark Smith Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) In-Reply-To: <20110623095548.24d89d7f@opy.nosense.org> Message-ID: References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> <20110622210451.60ad8bce@opy.nosense.org> <20110623095548.24d89d7f@opy.nosense.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org, ipv6@ietf.org, Ted Lemon X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 06:34:08 -0000 On Thu, 23 Jun 2011, Mark Smith wrote: > Hub-and-spoke or point-to-point reachability is what they want. If it is > possible to enforce a hub-or-spoke topology on an Ethernet LAN by > preventing the 1-to-many or 1-to-any capability, in effect making it an > NBMA link-layer, or creating a point-to-point topology via VLANs, then > Ethernet is the best choice because it is both cheap and ubiquitous. Yes, this has been a very successful model for high speed residential connectivity (ETTH) the past 10 years. And yes, you have to protect the users from each other, so they don't do MITM-attacks on each other. This requires some kind of limitation of traffic they can send to each other using L2, and full L2 isolation is of course the best. -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Wed Jun 22 23:36:27 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB4281F0C4B; Wed, 22 Jun 2011 23:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 sApzjP0CEWC0; Wed, 22 Jun 2011 23:36:27 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 2A18E1F0C4A; Wed, 22 Jun 2011 23:36:27 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 366AC9C; Thu, 23 Jun 2011 08:36:26 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 341929A; Thu, 23 Jun 2011 08:36:26 +0200 (CEST) Date: Thu, 23 Jun 2011 08:36:26 +0200 (CEST) From: Mikael Abrahamsson To: Ted Lemon Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) In-Reply-To: Message-ID: References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> <20110622210451.60ad8bce@opy.nosense.org> <20110623095548.24d89d7f@opy.nosense.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 06:36:27 -0000 On Wed, 22 Jun 2011, Ted Lemon wrote: > So if in fact it is impossible for RA to be adequately secured on an > ethernet, then we need to fix RA, or come up with a different solution, > not slap a bandage on it and call it done. I don't see how it can be fixed. Short of encrypting all traffic and pre-distributing keys, ethernet can't be fixed without the "bandaids" you seem to call the measures being used widely to assure ethernet can in fact be used securely. -- Mikael Abrahamsson email: swmike@swm.pp.se From v6ops@globis.net Wed Jun 22 23:57:25 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 105AB21F85A4; Wed, 22 Jun 2011 23:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_LOW=-1] 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 vIz6IhlPKZU8; Wed, 22 Jun 2011 23:57:18 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id 836FC21F8585; Wed, 22 Jun 2011 23:57:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 7CE498700F0; Thu, 23 Jun 2011 08:56:45 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxNkGFhcEifx; Thu, 23 Jun 2011 08:56:40 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 079878700EF; Thu, 23 Jun 2011 08:56:40 +0200 (CEST) Message-ID: <4E02E3A7.4010100@globis.net> Date: Thu, 23 Jun 2011 08:56:39 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: v6ops@ietf.org, ipv6@ietf.org, Ted Lemon Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) Content-Type: multipart/alternative; boundary="------------040101040407070906050409" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 06:57:25 -0000 This is a multi-part message in MIME format. --------------040101040407070906050409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > > Subject: > Re: [v6ops] Question regarding RA-Guard evasion (ND and extension > headers) > From: > Ted Lemon > Date: > Wed, 22 Jun 2011 20:56:52 -0400 > > To: > Mark Smith > CC: > v6ops@ietf.org, ipv6@ietf.org > > Content-Transfer-Encoding: > quoted-printable > Precedence: > list > MIME-Version: > 1.0 (Apple Message framework v1242) > References: > <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> > > <20110622210451.60ad8bce@opy.nosense.org> > > > <20110623095548.24d89d7f@opy.nosense.org> > In-Reply-To: > <20110623095548.24d89d7f@opy.nosense.org> > Message-ID: > > Content-Type: > text/plain; charset="us-ascii" > Message: > 7 > > > On Jun 22, 2011, at 8:25 PM, Mark Smith wrote: > >> > You're right, with Ethernet being the wrong protocol. >> > > Well, let's be clear here: Ethernet is apparently the wrong protocol*for you*. You should be running 802.1x, not plain ethernet, because you have specific needs that make plain ethernet an inappropriate choice for you. > > But that wasn't what I was talking about. IPv6 has to work on ethernet. IPv6 multicast is useful, and we (at least, some of us) want it to work. The solution to the rogue RA problem is not to get rid of ethernet (or at least, so I claim). Moreover, even supposing we could get rid of ethernet in the sense that you mean, that would simply paper over the problem, not solve it. If we want a secure network, we have to use secure protocols. Firewalls are a great second-level defense (and your hub-and-spoke model is basically a firewall). But they do not make your network secure: they simply make it harder to attack. > > So if in fact it is impossible for RA to be adequately secured on an ethernet, then we need to fix RA, or come up with a different solution, not slap a bandage on it and call it done. > > Sounds sensible. Following are IMVVHO "requirements" from an operational perspective. People have similar "issues" with ARP and DHCP (v4) and IPv4 today. But today it is also trivial to filter BOOTP on networks with fixed links/ports to make sure the default route and DNS server are set via DHCP, and only the designated DHCP server/ DHCP relay can/will reply, and that's generally been "good enough". For wireless, people are generally employing something else, like 802.1X, anyway. Sometimes I think we're in danger of making things so complex that the simple filters will no longer work (and having to buy a complete new generation of Ethernet LAN switches to make RA work does not sound operationally attractive) IMVHO If it was equally trivial as today to be able to completely filter the messages that set the default route and the DNS server to certain LAN ports or MAC addresses or IP source addresses or well-known port numbers, and so be able to fairly reliably set the DNS server and the default router on end hosts from a (weakly) trusted source, then the "issue" would be "solved" for most users, because that would be no different to today. If people want to buy a new switch to implement RA Guard, then that's fine too. But RA Guard should not be a prerequisite for reliably setting of a default route on Ethernet, simply because corporate LAN switches generally have to last 5-10 years or so before being replaced. If the trust relationship between an end node and the source that provides the configuration information on the default route and DNS server could be made even stronger, all the better, but in a World of roaming devices and guest users, that is not a trivial nut to crack operationally. regards, RayH --------------040101040407070906050409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Subject:
Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)
From:
Ted Lemon <Ted.Lemon@nominum.com>
Date:
Wed, 22 Jun 2011 20:56:52 -0400
To:
Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>
CC:
v6ops@ietf.org, ipv6@ietf.org
Content-Transfer-Encoding:
quoted-printable
Precedence:
list
MIME-Version:
1.0 (Apple Message framework v1242)
References:
<282787FA-C418-430C-B473-152B4FFE900C@gmail.com> <m1QZLSP-0001h8C@stereo.hq.phicoh.net> <20110622210451.60ad8bce@opy.nosense.org> <alpine.DEB.2.00.1106221337411.19581@uplift.swm.pp.se> <CF7C688F-9262-4A6C-9B57-CFDDF94D246D@nominum.com> <20110623095548.24d89d7f@opy.nosense.org>
In-Reply-To:
<20110623095548.24d89d7f@opy.nosense.org>
Message-ID:
<B5FBA399-6AAC-4036-A0D3-CAA546190B92@nominum.com>
Content-Type:
text/plain; charset="us-ascii"
Message:
7		 

On Jun 22, 2011, at 8:25 PM, Mark Smith wrote:
  
> You're right, with Ethernet being the wrong protocol.
    

Well, let's be clear here: Ethernet is apparently the wrong protocol *for you*.   You should be running 802.1x, not plain ethernet, because you have specific needs that make plain ethernet an inappropriate choice for you.

But that wasn't what I was talking about.   IPv6 has to work on ethernet.   IPv6 multicast is useful, and we (at least, some of us) want it to work.   The solution to the rogue RA problem is not to get rid of ethernet (or at least, so I claim).   Moreover, even supposing we could get rid of ethernet in the sense that you mean, that would simply paper over the problem, not solve it.   If we want a secure network, we have to use secure protocols.   Firewalls are a great second-level defense (and your hub-and-spoke model is basically a firewall).   But they do not make your network secure: they simply make it harder to attack.

So if in fact it is impossible for RA to be adequately secured on an ethernet, then we need to fix RA, or come up with a different solution, not slap a bandage on it and call it done.

Sounds sensible.

Following are IMVVHO "requirements" from an operational perspective.

People have similar "issues" with ARP and DHCP (v4) and IPv4 today. But today it is also trivial to filter BOOTP on networks with fixed links/ports to make sure the default route and DNS server are set via DHCP, and only the designated DHCP server/ DHCP relay can/will reply, and that's generally been "good enough". For wireless, people are generally employing something else, like 802.1X, anyway.

Sometimes I think we're in danger of making things so complex that the simple filters will no longer work (and having to buy a complete new generation of Ethernet LAN switches to make RA work does not sound operationally attractive)

IMVHO If it was equally trivial as today to be able to completely filter the messages that set the default route and the DNS server to certain LAN ports or MAC addresses or IP source addresses or well-known port numbers, and so be able to fairly reliably set the DNS server and the default router on end hosts from a (weakly) trusted source, then the "issue" would be "solved" for most users, because that would be no different to today.

If people want to buy a new switch to implement RA Guard, then that's fine too. But RA Guard should not be a prerequisite for reliably setting of a default route on Ethernet, simply because corporate LAN switches generally have to last 5-10 years or so before being replaced.

If the trust relationship between an end node and the source that provides the configuration information on the default route and DNS server could be made even stronger, all the better, but in a World of roaming devices and guest users, that is not a trivial nut to crack operationally.

regards,
RayH
--------------040101040407070906050409-- From swmike@swm.pp.se Thu Jun 23 00:03:39 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 824CD21F85B7; Thu, 23 Jun 2011 00:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] 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 ShIoX+C5V9KL; Thu, 23 Jun 2011 00:03:39 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id B657C21F85B6; Thu, 23 Jun 2011 00:03:38 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 981539C; Thu, 23 Jun 2011 09:03:37 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 95C719A; Thu, 23 Jun 2011 09:03:37 +0200 (CEST) Date: Thu, 23 Jun 2011 09:03:37 +0200 (CEST) From: Mikael Abrahamsson To: Ray Hunter Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) In-Reply-To: <4E02E3A7.4010100@globis.net> Message-ID: References: <4E02E3A7.4010100@globis.net> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org, ipv6@ietf.org, Ted Lemon X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 07:03:39 -0000 On Thu, 23 Jun 2011, Ray Hunter wrote: > too. But RA Guard should not be a prerequisite for reliably setting of a > default route on Ethernet, simply because corporate LAN switches generally > have to last 5-10 years or so before being replaced. I don't see 5-10 year old LAN switches having any kind of capability of filtering just certain IPv6 packets. They might have the possibility of filtering all 0x86dd packet which is the sensible thing to do unless one can secure it by other means. Securing L2 networks is something not generally done today in enterprise and surprisingly often in SP environments as well. This can be seen by all the problems reported by Windows ICS v6 RA:s being sent out and causing problems to other users (which in a properly build network it shouldn't have the capability of doing, because those packets should be filtered by the access network). -- Mikael Abrahamsson email: swmike@swm.pp.se From tjc@ecs.soton.ac.uk Thu Jun 23 02:37:48 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A2321F8560; Thu, 23 Jun 2011 02:37:48 -0700 (PDT) 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=-2.599, J_CHICKENPOX_21=0.6] 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 PcHpvpBR-Ukk; Thu, 23 Jun 2011 02:37:47 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEE421F8563; Thu, 23 Jun 2011 02:37:46 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p5N9bf1M017317; Thu, 23 Jun 2011 10:37:41 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p5N9bf1M017317 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1308821861; bh=HnGC1uEFJBqocYHs5o5yFpNdZcM=; h=References:In-Reply-To:Mime-Version:From:Subject:Date:To; b=kMbcAU6VOXw3gbLZseDzS/wEHQGaeQKJhxY5VEHuiCkyDNLhc3ByrIXTCkQZ7Wn4C T14E77rg7lRtqm+/X9jCrDEXz6B9CwRAfcdLUuAmmdb7ZmJrLTUWAuXK+Mwloz7QEh DhmtZEeyvns8EXK6ufbhuDkOGhUYj6ROgEU1ouAQ= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id n5MAbf0366136384Li ret-id none; Thu, 23 Jun 2011 10:37:41 +0100 Received: from cerf.ecs.soton.ac.uk (cerf.ecs.soton.ac.uk [152.78.69.39]) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p5N9bZQb004226 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 23 Jun 2011 10:37:35 +0100 References: <4E02E3A7.4010100@globis.net> <88193BC0-9F0B-4D39-B770-81B4ECF39666@ecs.soton.ac.uk> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-ID: Content-Transfer-Encoding: quoted-printable From: Tim Chown Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) Date: Thu, 23 Jun 2011 10:37:34 +0100 To: v6ops@ietf.org, ipv6@ietf.org X-Mailer: Apple Mail (2.1084) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=n5MAbf036613638400; tid=n5MAbf0366136384Li; client=relay,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: p5N9bf1M017317 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 09:37:48 -0000 On 23 Jun 2011, at 08:03, Mikael Abrahamsson wrote: > Securing L2 networks is something not generally done today in = enterprise and surprisingly often in SP environments as well. This can = be seen by all the problems reported by Windows ICS v6 RA:s being sent = out and causing problems to other users (which in a properly build = network it shouldn't have the capability of doing, because those packets = should be filtered by the access network). I think there is some effort to secure layer 2 in academic enterprises, = e.g. I did a straw poll at a recent UK event and about 2/3rds of the = admins there were using DHCPv4 snooping/filtering on layer 2 devices. = But pretty much none had any filters applied for RAs, even if they = could. This probably explains in part why so many admins are = 'comfortable' with the idea of DHCPv6-only operation, in that it's a = known risk model. Some mechanisms also don't help in the way they're deployed. While = academic sites are now heavily into 802.1X for eduroam deployment, = pretty much every rogue ICS-a-like RA that's seen is issued by a device = that has authenticated using 802.1X, but in almost every case the = devices are put into a shared VLAN, not one per user/device. But ICS-a-like rogue RAs are invariably 6to4 prefix, and RFC3484-bis = generally handles that. And such 'accidental' rogue RAs are very = unlikely to be fragmented in an attempt to defeat RA-Guard. RFC6104 = was written with accidental RAs in mind, for reasons stated in the text. Interestingly I've noticed a few scenarios where unicast RAs are being = suggested more, e.g. related to wireless roaming on campuses. Tim From v6ops@globis.net Thu Jun 23 10:14:48 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F2511E8160; Thu, 23 Jun 2011 10:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] 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 1w87TukcSPWS; Thu, 23 Jun 2011 10:14:47 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id E027A11E8125; Thu, 23 Jun 2011 10:14:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id AC74E870087; Thu, 23 Jun 2011 19:14:15 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQX8cWYtPO0T; Thu, 23 Jun 2011 19:14:10 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 61A61870079; Thu, 23 Jun 2011 19:14:10 +0200 (CEST) Message-ID: <4E037462.3070601@globis.net> Date: Thu, 23 Jun 2011 19:14:10 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Mikael Abrahamsson Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) References: <4E02E3A7.4010100@globis.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, ipv6@ietf.org, Ted Lemon X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 17:14:48 -0000 Mikael Abrahamsson wrote: > On Thu, 23 Jun 2011, Ray Hunter wrote: > >> too. But RA Guard should not be a prerequisite for reliably setting >> of a default route on Ethernet, simply because corporate LAN switches >> generally have to last 5-10 years or so before being replaced. > > I don't see 5-10 year old LAN switches having any kind of capability > of filtering just certain IPv6 packets. They might have the > possibility of filtering all 0x86dd packet which is the sensible thing > to do unless one can secure it by other means. > > Securing L2 networks is something not generally done today in > enterprise and surprisingly often in SP environments as well. This can > be seen by all the problems reported by Windows ICS v6 RA:s being sent > out and causing problems to other users (which in a properly build > network it shouldn't have the capability of doing, because those > packets should be filtered by the access network). Many current devices implement DHCP snooping, IP source guard, and similar ARP inspection filters for DHCP (v4) (as an alternative to 802.1x) because the user admin associated with L2 security technology is generally a heavy operational burden. I don't have figures for the percentage of people who would be affected by losing such equivalent functionality if they moved to IPv6 today, but presumably there was an operational "need", or else these IPv4 features would not have been implemented. Obviously the likes of 802.1X are technologically far superior, but that isn't always the deciding factor for implementation. I can guess the answer the CFO will give those same people if they request to renew their current L2 switches 5 years early just because they need to implement RA Guard. So what would those people do today to retain similar functionality for IPv6 without investing heavily, or switching off IPv6? > Short of encrypting all traffic and pre-distributing keys If the WG has reached a stage of looking for a potential alternative mitigation (and perhaps completely crazy out of the box thinking) that doesn't involve replacing switches, may I humbly suggest consideration of using the current DHCPv4/bootp mechanism to distribute an IPv6 address and MAC address (or some other stronger public-key) associated with one or more trusted default routers in the initial network booting process as a mitigation mechanism/ stop gap? The IPv6 hosts can then defend themselves by filtering incoming RA messages to be from the trusted source. I know it sounds truly awful, but it might work. IPv4 RFC1918 addresses are not going to run out. And it seems to me that's the gap between DHCPv6 and DHCPv4 if you have a "problem" with rogue RA, but you already have a decent solution in place for "secure enough" DHCPv4 and DHCPv6. After all, IPv4 transport was also deemed acceptable for use in resolving IPv6 AAAA records. If this is too far left field, please simply ignore me :) Or better still, propose something smarter ;) regards, RayH From Ted.Lemon@nominum.com Thu Jun 23 13:30:50 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 818B121F850A; Thu, 23 Jun 2011 13:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.466 X-Spam-Level: X-Spam-Status: No, score=-106.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 QOO2i6Ix4wcF; Thu, 23 Jun 2011 13:30:49 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 71D7A21F84AC; Thu, 23 Jun 2011 13:30:49 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTgOieE6rAV8QgUsfB54Lkttfbwgz7gou@postini.com; Thu, 23 Jun 2011 13:30:49 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 75CE61B84A0; Thu, 23 Jun 2011 13:30:48 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 684D919005C; Thu, 23 Jun 2011 13:30:48 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from exchange-01.WIN.NOMINUM.COM (64.89.228.50) by CAS-02.WIN.NOMINUM.COM (64.89.228.132) with Microsoft SMTP Server (TLS) id 14.1.289.1; Thu, 23 Jun 2011 13:30:42 -0700 Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 23 Jun 2011 13:30:41 -0700 Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) MIME-Version: 1.0 (Apple Message framework v1242) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: Date: Thu, 23 Jun 2011 16:30:37 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <63524B72-6890-48E4-926F-030744B415A2@nominum.com> References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> <20110622210451.60ad8bce@opy.nosense.org> <20110623095548.24d89d7f@opy.nosense.org> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1242) Cc: v6ops@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 20:30:50 -0000 On Jun 23, 2011, at 2:36 AM, Mikael Abrahamsson wrote: > I don't see how it can be fixed. Short of encrypting all traffic and = pre-distributing keys, ethernet can't be fixed without the "bandaids" = you seem to call the measures being used widely to assure ethernet can = in fact be used securely. There probably is no single solution. But let's consider the solution = Mark proposed: use the fact that you control the infrastructure to = control the flow of packets on the network in such a way that rogue RAs = cannot reach leaf nodes. The reason I object to this solution, in = addition to the fact that it breaks multicast, is that it's a firewall = solution: the client doesn't know it's safe, and as soon as it connects = to a network that's not protected in this way, it's vulnerable. But = the model of using infrastructure control as a credential is = interesting. Is there a way that someone who is not running 802.1x can demonstrate = that they control layer 2? It seems to me that for most examples of = Layer 2 that we care about, the answer is probably yes. So then if the = secure link to the router can be used to communicate a secret, and the = network can provide that secret back to the user in a way that a rogue = RA agent could not do, then the end node can discriminate between rogue = RAs and legitimate RAs. E.g., suppose we have a WiFi network secured with WPA. WPA uses an = X.509 cert to establish the identity of the WPA server. If the private = key authenticated by the cert is used to sign the secret the client = provides, then the client can be sure that the router it is talking to = is controlled by the same entity that controls WPA. Since WPA is tied = directly to the infrastructure, that's proof that the router is managed = by the infrastructure provider. =20 Another solution that would work well in the case of frequently-visited = networks would be the model that ssh uses: keep a list of good routers. = When you connect to a wire, prefer routers on the "good" list to new = routers. If no RAs come from routers on the "good" list, then you need = a heuristic to decide whether or not a new router is good. The = mechanism I described in the previous paragraph could be used to handle = some exceptional cases; other heuristics could be used to handle cases = where the link is not secured in any way: if I try to establish secure = connections, and those connections turn out to be exposed to MITM = attacks, then the router (and hence, the RA from that router) are not = trustworthy. The problem with this stuff is not that it's impossible. It's that = it's not simple. If you want your communications to be secure, you = have to secure them. If all your communications are secure, then a = rogue RA can only do two things: deny service, or allow an attacker to = do traffic analysis and/or cryptanalysis that would not otherwise be = possible. From albert.e.manfredi@boeing.com Thu Jun 23 13:40:35 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93ED321F8442; Thu, 23 Jun 2011 13:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 5DxP1OoLCzf0; Thu, 23 Jun 2011 13:40:34 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id BBD9F21F8441; Thu, 23 Jun 2011 13:40:34 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p5NKePWN010005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 23 Jun 2011 13:40:26 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p5NKePw7007415; Thu, 23 Jun 2011 15:40:25 -0500 (CDT) Received: from XCH-MWHT-03.mw.nos.boeing.com (xch-mwht-03.mw.nos.boeing.com [134.57.119.161]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p5NKeIfi007229 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 23 Jun 2011 15:40:23 -0500 (CDT) Received: from XCH-MWPFX-01.mw.nos.boeing.com (132.173.24.10) by XCH-MWHT-03.mw.nos.boeing.com (134.57.119.161) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 23 Jun 2011 15:40:18 -0500 Received: from XCH-MW-08V.mw.nos.boeing.com ([134.57.118.180]) by XCH-MWPFX-01.mw.nos.boeing.com ([132.173.24.10]) with mapi; Thu, 23 Jun 2011 15:40:17 -0500 From: "Manfredi, Albert E" To: Ted Lemon Date: Thu, 23 Jun 2011 15:40:12 -0500 Subject: RE: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) Thread-Topic: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) Thread-Index: Acwx5H+3fTxU6Ru8TdaKVw/1a7H8agAALFYA Message-ID: References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> <20110622210451.60ad8bce@opy.nosense.org> <20110623095548.24d89d7f@opy.nosense.org> <63524B72-6890-48E4-926F-030744B415A2@nominum.com> In-Reply-To: <63524B72-6890-48E4-926F-030744B415A2@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-TM-AS-Product-Ver: SMEX-10.0.0.1412-6.500.1024-18218.000 X-TM-AS-Result: No--21.977600-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 20:40:35 -0000 Ted Lemon wrote: > There probably is no single solution. But let's consider the solution > Mark proposed: use the fact that you control the infrastructure to > control the flow of packets on the network in such a way that rogue RAs > cannot reach leaf nodes. The reason I object to this solution, in > addition to the fact that it breaks multicast, is that it's a firewall > solution: the client doesn't know it's safe, and as soon as it connects > to a network that's not protected in this way, it's vulnerable. But > the model of using infrastructure control as a credential is > interesting. While I too find it hard to accept the ETTH solution as being "real" Ethern= et, I believe it is the network that is trying to protect itself here, more= than altruistic protection of clients. If clients are protected as a resul= t, great. Yes, in another network, those same clients might not be protected at all. Your solutions appear to be more client-oriented. Bert From Ted.Lemon@nominum.com Thu Jun 23 14:25:35 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F34C11E81AB; Thu, 23 Jun 2011 14:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.474 X-Spam-Level: X-Spam-Status: No, score=-106.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 92PJnPxctE-O; Thu, 23 Jun 2011 14:25:35 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id CBDF611E81A1; Thu, 23 Jun 2011 14:25:34 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTgOvTWeWfUOt1QR7eQAunpMWjQ7jy7xv@postini.com; Thu, 23 Jun 2011 14:25:34 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 8CDB71B8536; Thu, 23 Jun 2011 14:25:33 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 7DBE519005C; Thu, 23 Jun 2011 14:25:33 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from exchange-01.WIN.NOMINUM.COM (64.89.228.50) by CAS-01.WIN.NOMINUM.COM (64.89.228.131) with Microsoft SMTP Server (TLS) id 14.1.289.1; Thu, 23 Jun 2011 14:25:27 -0700 Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 23 Jun 2011 14:25:27 -0700 Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) MIME-Version: 1.0 (Apple Message framework v1242) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: Date: Thu, 23 Jun 2011 17:25:23 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> <20110622210451.60ad8bce@opy.nosense.org> <20110623095548.24d89d7f@opy.nosense.org> <63524B72-6890-48E4-926F-030744B415A2@nominum.com> To: "Manfredi, Albert E" X-Mailer: Apple Mail (2.1242) Cc: "v6ops@ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 21:25:35 -0000 On Jun 23, 2011, at 4:40 PM, Manfredi, Albert E wrote: > Your solutions appear to be more client-oriented. That's correct. Ultimately the security of the client depends on the = client being secure. Trying to secure the client by securing the = network is a noble cause, but ultimately doomed to failure, because you = can't control what networks the client connects to. Of course there = are special cases where this isn't true, but as mobile nodes get more = and more capable, the set of all such special cases gets smaller and = smaller. From albert.e.manfredi@boeing.com Thu Jun 23 14:31:15 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA37A11E8199; Thu, 23 Jun 2011 14:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 dLd-pOicl25u; Thu, 23 Jun 2011 14:31:15 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfa.amsl.com (Postfix) with ESMTP id 07D2111E81B6; Thu, 23 Jun 2011 14:31:15 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p5NLV9aI017765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 23 Jun 2011 14:31:12 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p5NLV9op001665; Thu, 23 Jun 2011 14:31:09 -0700 (PDT) Received: from XCH-MWHT-06.mw.nos.boeing.com (xch-mwht-06.mw.nos.boeing.com [134.57.113.166]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p5NLV8em001611 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 23 Jun 2011 14:31:09 -0700 (PDT) Received: from XCH-MW-08V.mw.nos.boeing.com ([134.57.118.180]) by XCH-MWHT-06.mw.nos.boeing.com ([134.57.113.166]) with mapi; Thu, 23 Jun 2011 16:31:08 -0500 From: "Manfredi, Albert E" To: Ted Lemon Date: Thu, 23 Jun 2011 16:31:07 -0500 Subject: RE: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) Thread-Topic: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) Thread-Index: Acwx7BmJC20WsiiNQS2sTIswF0EhqAAAGs7g Message-ID: References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> <20110622210451.60ad8bce@opy.nosense.org> <20110623095548.24d89d7f@opy.nosense.org> <63524B72-6890-48E4-926F-030744B415A2@nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-10.0.0.1412-6.500.1024-18218.000 x-tm-as-result: No--49.230000-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 21:31:16 -0000 Ted Lemon wrote: > That's correct. Ultimately the security of the client depends on the > client being secure. Trying to secure the client by securing the > network is a noble cause, but ultimately doomed to failure, because you > can't control what networks the client connects to. No, I think you have it backwards. It is service providers that are interested in protecting their networks, i= n this discussion. If they also happen to protect their clients, that is ju= st a nice byproduct. Service providers want to keep malicious clients from degrading their netwo= rk. Bert From Ted.Lemon@nominum.com Thu Jun 23 14:56:58 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4FB21F852C; Thu, 23 Jun 2011 14:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.481 X-Spam-Level: X-Spam-Status: No, score=-106.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 sihXu40sLSS3; Thu, 23 Jun 2011 14:56:58 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 1150E21F852B; Thu, 23 Jun 2011 14:56:54 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTgO2pUb2NRWGJ12OakGPiWmQArKj2eSy@postini.com; Thu, 23 Jun 2011 14:56:57 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 59DF9F8033; Thu, 23 Jun 2011 14:56:53 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 4C2FE19005C; Thu, 23 Jun 2011 14:56:53 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from exchange-01.WIN.NOMINUM.COM (64.89.228.50) by CAS-01.WIN.NOMINUM.COM (64.89.228.131) with Microsoft SMTP Server (TLS) id 14.1.289.1; Thu, 23 Jun 2011 14:56:53 -0700 Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 23 Jun 2011 14:56:51 -0700 Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) MIME-Version: 1.0 (Apple Message framework v1242) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: Date: Thu, 23 Jun 2011 17:56:47 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <8F573F95-319F-4DC2-8D07-59C431E0E65E@nominum.com> References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> <20110622210451.60ad8bce@opy.nosense.org> <20110623095548.24d89d7f@opy.nosense.org> <63524B72-6890-48E4-926F-030744B415A2@nominum.com> To: "Manfredi, Albert E" X-Mailer: Apple Mail (2.1242) Cc: "v6ops@ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 21:56:58 -0000 On Jun 23, 2011, at 5:31 PM, Manfredi, Albert E wrote: > It is service providers that are interested in protecting their = networks, in this discussion. If they also happen to protect their = clients, that is just a nice byproduct. That's fine for service providers, but service providers are not the = only interested parties here. Mark's solution does fine for that use = case, but I would not want it on my home network. From Ted.Lemon@nominum.com Thu Jun 23 15:14:14 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69A8711E8125; Thu, 23 Jun 2011 15:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.488 X-Spam-Level: X-Spam-Status: No, score=-106.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 DkzlymOAeOGJ; Thu, 23 Jun 2011 15:14:13 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 35E5811E80E1; Thu, 23 Jun 2011 15:14:13 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTgO6tNO6lmwm0TJDO6AvineY78crNU//@postini.com; Thu, 23 Jun 2011 15:14:13 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 1389D1B8576; Thu, 23 Jun 2011 15:14:12 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 051E619005C; Thu, 23 Jun 2011 15:14:12 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from exchange-01.WIN.NOMINUM.COM (64.89.228.50) by CAS-02.WIN.NOMINUM.COM (64.89.228.132) with Microsoft SMTP Server (TLS) id 14.1.289.1; Thu, 23 Jun 2011 15:13:36 -0700 Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 23 Jun 2011 15:13:36 -0700 Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) MIME-Version: 1.0 (Apple Message framework v1242) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: Date: Thu, 23 Jun 2011 18:13:31 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <1A7FA259-3266-4FA6-91B7-2180A1065710@nominum.com> References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> <20110622210451.60ad8bce@opy.nosense.org> <20110623095548.24d89d7f@opy.nosense.org> <63524B72-6890-48E4-926F-030744B415A2@nominum.com> <8F573F95-319F-4DC2-8D07-59C431E0E65E@nominum.com> To: Philip Homburg X-Mailer: Apple Mail (2.1242) Cc: "v6ops@ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 22:14:14 -0000 On Jun 23, 2011, at 6:08 PM, Philip Homburg wrote: > Ideally, clients use end-to-end crypto to keep themselves secure, but = the > network still has to be protected against denial of service attacks. No, strictly speaking the *clients* need to be protected against DoS = attacks. One way to do this is to strongly control multicast on the = network. But the network itself cannot suffer from rogue RA = advertisements: it is other clients on the network that suffer. I = realize that this seems like a trivial distinction, but I think it's = important to be clear about it, because it's not always a safe = assumption that any given network will be protected, and hence if we = really care about DoS attacks as a general problem, we need to address = the problem in a way that will work not just on hub-and-spoke networks, = but on broadcast networks as well. From marka@isc.org Thu Jun 23 16:41:39 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2346D11E80D8; Thu, 23 Jun 2011 16:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] 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 SQnHEprWOFGB; Thu, 23 Jun 2011 16:41:38 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 689D711E808B; Thu, 23 Jun 2011 16:41:38 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 8FB605F98E6; Thu, 23 Jun 2011 23:41:20 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 6D519216C7B; Thu, 23 Jun 2011 23:41:18 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 88100112A691; Fri, 24 Jun 2011 09:41:14 +1000 (EST) To: "v6ops@ietf.org" , "ipv6@ietf.org" From: Mark Andrews References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> <20110622210451.60ad8bce@opy.nosense.org> <20110623095548.24d89d7f@opy.nosense.org> <63524B72-6890-48E4-926F-030744B415A2@nominum.com> <8F573F95-319F-4DC2-8D07-59C431E0E65E@nominum.com> <1A7FA259-3266-4FA6-91B7-2180A1065710@nominum.com> Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) In-reply-to: Your message of "Thu, 23 Jun 2011 18:13:31 -0400." <1A7FA259-3266-4FA6-91B7-2180A1065710@nominum.com> Date: Fri, 24 Jun 2011 09:41:14 +1000 Message-Id: <20110623234114.88100112A691@drugs.dv.isc.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 23:41:39 -0000 For many years I just filtered out rogue RA's on my laptop at IETF. I looked at which routers were advertising which prefixes and configured a allow list in the firewall for those that looked correct and denied the rest. Then I removed the bogus addresses, generated as the result of those RA's, from the interface. I also remove the default route when it pointed to a bogus router and performed a router solicitation. Making that into a GUI so the user can point and click should be relatively easy. Add to that next hop selection where you only send to a router that is advertising a prefix covering the source address you are using and trying from multiple source address, you can mostly eliminate the impact of accidental rogue RA's without needing to filter. If you want to eliminate malicious RA's then you need the network operator to help by using CGA's or similar so you can identify spoofed from non-spoofed RA's. The node can learn which router is using CGA's and automatically filter spoofed ones. By keeping a little more state it can also automatically cleanup the side effects from those spoofed RA's. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ipng@69706e6720323030352d30312d31340a.nosense.org Thu Jun 23 17:44:17 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDE711E8081; Thu, 23 Jun 2011 17:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 awNEJ8XvzobR; Thu, 23 Jun 2011 17:44:16 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id C12A511E819D; Thu, 23 Jun 2011 17:44:15 -0700 (PDT) Received: from 219-90-231-100.ip.adam.com.au ([219.90.231.100] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QZuVE-0007Xm-Mq; Fri, 24 Jun 2011 10:14:08 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 089C13B33E; Fri, 24 Jun 2011 10:14:08 +0930 (CST) Date: Fri, 24 Jun 2011 10:14:06 +0930 From: Mark Smith To: Ted Lemon Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) Message-ID: <20110624101406.6498e2b0@opy.nosense.org> In-Reply-To: <63524B72-6890-48E4-926F-030744B415A2@nominum.com> References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> <20110622210451.60ad8bce@opy.nosense.org> <20110623095548.24d89d7f@opy.nosense.org> <63524B72-6890-48E4-926F-030744B415A2@nominum.com> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 00:44:17 -0000 Hi, On Thu, 23 Jun 2011 16:30:37 -0400 Ted Lemon wrote: > On Jun 23, 2011, at 2:36 AM, Mikael Abrahamsson wrote: > > I don't see how it can be fixed. Short of encrypting all traffic and pre-distributing keys, ethernet can't be fixed without the "bandaids" you seem to call the measures being used widely to assure ethernet can in fact be used securely. > > There probably is no single solution. But let's consider the solution Mark proposed: Just to be clear, I wasn't suggesting the methods commonly used in ETTH networks is a universal solution. It seems to me that organisations that would care the most about malicious RAs are SPs. Yet they're already likely to have or put measures in place that naturally mitigate that risk as well as achieving other goals that they have such as traffic billing. So malicious RAs may not be as as much of a threat to them as people might think. Implementing these sorts of measures are just a natural cost of business, because it is part of ensuring your service is available, and ensuring one customer has limited ability to disrupt another's service. Enterprise networks may be most concerned about accidental RAs, as they typically tend to have more control over what hosts can do because they operate them, rather than the customers in the SP case. As Ray mentioned, if the cost of implementing RA guard is prohibitive, some enterprises might just accept the risk and consequences of an occasional accidental RA. Are there other contexts that I haven't identified? The reason I've thought about these contexts is that proposals such as universally preventing fragmentation in ND is a one-size-fits-all approach to the problem that probably can't be reversed if chosen. > use the fact that you control the infrastructure to control the flow > of packets on the network in such a way that rogue RAs cannot reach > leaf nodes. The reason I object to this solution, in addition to the > fact that it breaks multicast, is that it's a firewall solution: the > client doesn't know it's safe, and as soon as it connects to a network > that's not protected in this way, it's vulnerable. But the model of > using infrastructure control as a credential is interesting. > > Is there a way that someone who is not running 802.1x can demonstrate that they control layer 2? It seems to me that for most examples of Layer 2 that we care about, the answer is probably yes. So then if the secure link to the router can be used to communicate a secret, and the network can provide that secret back to the user in a way that a rogue RA agent could not do, then the end node can discriminate between rogue RAs and legitimate RAs. > > E.g., suppose we have a WiFi network secured with WPA. WPA uses an X.509 cert to establish the identity of the WPA server. If the private key authenticated by the cert is used to sign the secret the client provides, then the client can be sure that the router it is talking to is controlled by the same entity that controls WPA. Since WPA is tied directly to the infrastructure, that's proof that the router is managed by the infrastructure provider. > This is basically Secure Neighbor Discovery (SeND) with the addition of key distribution via the 802.1x. I'm not sure the combination exists or is possible, I've been meaning to look into it for a while. > Another solution that would work well in the case of frequently-visited networks would be the model that ssh uses: keep a list of good routers. When you connect to a wire, prefer routers on the "good" list to new routers. If no RAs come from routers on the "good" list, then you need a heuristic to decide whether or not a new router is good. The mechanism I described in the previous paragraph could be used to handle some exceptional cases; other heuristics could be used to handle cases where the link is not secured in any way: if I try to establish secure connections, and those connections turn out to be exposed to MITM attacks, then the router (and hence, the RA from that router) are not trustworthy. > > The problem with this stuff is not that it's impossible. It's that it's not simple. If you want your communications to be secure, you have to secure them. If all your communications are secure, then a rogue RA can only do two things: deny service, or allow an attacker to do traffic analysis and/or cryptanalysis that would not otherwise be possible. > Agree with it not being simple. A secure protocol to authenticate RAs already exists - SeND. The problem with it is the lack of implementations and the key distribution problem. Since we know that methods such as RA guard aren't really "properly secure" and can't be, I think it is important to not to have unrealistic security expectations of them. Regards, Mark. From farmer@umn.edu Thu Jun 23 18:30:17 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCBE11E8084; Thu, 23 Jun 2011 18:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 Wob4i98digjP; Thu, 23 Jun 2011 18:30:16 -0700 (PDT) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.135.88]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8F411E807C; Thu, 23 Jun 2011 18:30:16 -0700 (PDT) Received: from mail-iy0-f171.google.com (mail-iy0-f171.google.com [209.85.210.171]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP Thu, 23 Jun 2011 20:30:08 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-iy0-f171.google.com [209.85.210.171] #+LO+TR X-Umn-Classification: local Received: by mail-iy0-f171.google.com with SMTP id 12so3134063iyi.16 for ; Thu, 23 Jun 2011 18:30:08 -0700 (PDT) Received: by 10.43.132.196 with SMTP id hv4mr624887icc.105.1308879007836; Thu, 23 Jun 2011 18:30:07 -0700 (PDT) Received: from x-128-101-232-243.uofm-secure.wireless.umn.edu (x-128-101-232-243.uofm-secure.wireless.umn.edu [128.101.232.243]) by mx.google.com with ESMTPS id f19sm1187427ibl.49.2011.06.23.18.30.06 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 23 Jun 2011 18:30:07 -0700 (PDT) Message-ID: <4E03E89D.3010603@umn.edu> Date: Thu, 23 Jun 2011 20:30:05 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Ted Lemon Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> <20110622210451.60ad8bce@opy.nosense.org> <20110623095548.24d89d7f@opy.nosense.org> <63524B72-6890-48E4-926F-030744B415A2@nominum.com> In-Reply-To: <63524B72-6890-48E4-926F-030744B415A2@nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 01:30:17 -0000 On 6/23/11 15:30 CDT, Ted Lemon wrote: > On Jun 23, 2011, at 2:36 AM, Mikael Abrahamsson wrote: >> I don't see how it can be fixed. Short of encrypting all traffic >> and pre-distributing keys, ethernet can't be fixed without the >> "bandaids" you seem to call the measures being used widely to >> assure ethernet can in fact be used securely. > > There probably is no single solution. But let's consider the > solution Mark proposed: use the fact that you control the > infrastructure to control the flow of packets on the network in such > a way that rogue RAs cannot reach leaf nodes. The reason I object > to this solution, in addition to the fact that it breaks multicast, > is that it's a firewall solution: the client doesn't know it's safe, > and as soon as it connects to a network that's not protected in this > way, it's vulnerable. But the model of using infrastructure control > as a credential is interesting. I don't think of RA-Guard and DHCP-Guard filters as security measures, they are simply network management and operations techniques. They don't make the network more secure, but they can make operating some networks much easier. They probably also can make some networks more reliable and usable too. But, calling them more secure is probably a stretch. A quick story; 6 years ago we replaced our network and implemented IPv4 DHCP-Guard filters on all access ports on our network, doing this eliminated about 300 trouble tickets a year from rogue IPv4 DHCP servers showing up on our network, home routers used as cheep switches without disabling DHCP, Internet connection sharing software on laptops, etc... Between staff time to track down the offending devices and lost productivity of the effected users, lets use a conservative average cost of $500 an incident, that is $150K a year of cost savings to the University. This didn't make our network one bit more secure, it is still a wide open network that anyone can use, but it is now cheaper to run and provides a more reliable and usable service to our users. This draft is need, if nothing else to let people know about this issue, and if we can find an acceptable way to mitigate the issue great, but classic RA-Guard is still a very effective network management and operations technique, with or without mitigation of this issue. Unintentional rogue RAs are big issues in a LAN environment of any substantial size. However, without mitigation of this issue, RA-Guard is not an effective network security technique. It can't deal with malicious rouge RAs that are a security threat. > Is there a way that someone who is not running 802.1x can demonstrate > that they control layer 2? It seems to me that for most examples of > Layer 2 that we care about, the answer is probably yes. So then if > the secure link to the router can be used to communicate a secret, > and the network can provide that secret back to the user in a way > that a rogue RA agent could not do, then the end node can > discriminate between rogue RAs and legitimate RAs. > > E.g., suppose we have a WiFi network secured with WPA. WPA uses an > X.509 cert to establish the identity of the WPA server. If the > private key authenticated by the cert is used to sign the secret the > client provides, then the client can be sure that the router it is > talking to is controlled by the same entity that controls WPA. > Since WPA is tied directly to the infrastructure, that's proof that > the router is managed by the infrastructure provider. OH... That's an intriguing idea, use 802.1x to securely feed SEND. That might even make using SEND practical in an open network environment like a University. Its a massing protocol layering violation, but most things in the security realm are. > Another solution that would work well in the case of > frequently-visited networks would be the model that ssh uses: keep a > list of good routers. When you connect to a wire, prefer routers on > the "good" list to new routers. If no RAs come from routers on the > "good" list, then you need a heuristic to decide whether or not a new > router is good. The mechanism I described in the previous paragraph > could be used to handle some exceptional cases; other heuristics > could be used to handle cases where the link is not secured in any > way: if I try to establish secure connections, and those connections > turn out to be exposed to MITM attacks, then the router (and hence, > the RA from that router) are not trustworthy. > > The problem with this stuff is not that it's impossible. It's that > it's not simple. If you want your communications to be secure, you > have to secure them. If all your communications are secure, then a > rogue RA can only do two things: deny service, or allow an attacker > to do traffic analysis and/or cryptanalysis that would not otherwise > be possible. Yep, if you secure your communications then these issues are only network management and operational issues, not security issues. However, depending on the network, you still might want to use RA-Guard to prevent such operational issues. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From fernando.gont.netbook.win@gmail.com Thu Jun 23 20:33:37 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA85611E8097; Thu, 23 Jun 2011 20:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 LxdAdRGq4mu7; Thu, 23 Jun 2011 20:33:36 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id B31AD11E81B3; Thu, 23 Jun 2011 20:33:36 -0700 (PDT) Received: by yie30 with SMTP id 30so1437833yie.31 for ; Thu, 23 Jun 2011 20:33:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=VHkviNnV1glA6gGv1QWI3+RkrhB9qz3ZwCPrnL0jNac=; b=fATGzcm9noDyhf9BNoepsQQWE32+NpBYn1zMiOrJ2qggpflsaaMSLaPMA6RV4GWFnS hYmKg8iJdfE48S/D9YzQlBfySvI++Up7nGCpaHaVS/HswC4O43Sg5UOY1KErcLIyT6P3 4A59lD8kZhHt0/AYlh4IeQAP39eyRvx3xIyL8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=iA2+Y1o1UiveWszBGI+KbvYEg+T/1qi09d6HSf0xLa+/25L3QhlUjB4k+kDA3YQNAN wDbbe/k6EkvrmPebxSNR9jOH7DAqY1zUq550CtBA4TUHhtH9/00VcCxvWE5dRo5kI8za naDgD1UiQqmK3ogGA5C+yI+oNsAXTJLBmS0nA= Received: by 10.101.189.38 with SMTP id r38mr2917210anp.119.1308886414622; Thu, 23 Jun 2011 20:33:34 -0700 (PDT) Received: from [192.168.123.103] ([190.48.244.84]) by mx.google.com with ESMTPS id w13sm2139410ano.23.2011.06.23.20.33.31 (version=SSLv3 cipher=OTHER); Thu, 23 Jun 2011 20:33:33 -0700 (PDT) Sender: Fernando Gont Message-ID: <4E0401AD.8070108@gont.com.ar> Date: Fri, 24 Jun 2011 00:17:01 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Mark Smith Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> <20110622210451.60ad8bce@opy.nosense.org> In-Reply-To: <20110622210451.60ad8bce@opy.nosense.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: RJ Atkinson , v6ops@ietf.org, ipv6@ietf.org, Philip Homburg X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 03:33:37 -0000 On 06/22/2011 08:34 AM, Mark Smith wrote: >> I think it is a bit ironic that if a L2 device has to parse all extension >> headers, that then L2 switching of IPv6 packets will be more expensive that >> L3 routing them. > > It may be getting to the point where it'd probably be easier > to address these issues by taking away hosts' ability to multicast to > other hosts on the same segment i.e. switch to an NBMA/hub-and-spoke > mode of LAN operation, allowing the designated routers to also act as > traffic sanitisers for on-link inter-host traffic. Two comments: * Hosts would still need to multicast RSs * This does nto prevent attackers from sending ND packets *unicast* to their victims. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From ipng@69706e6720323030352d30312d31340a.nosense.org Thu Jun 23 21:30:10 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3733811E8197; Thu, 23 Jun 2011 21:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 DnUo0D4gj7yc; Thu, 23 Jun 2011 21:30:09 -0700 (PDT) Received: from smtp2.adam.net.au (smtp2.adam.net.au [202.136.110.251]) by ietfa.amsl.com (Postfix) with ESMTP id EDB1011E80AF; Thu, 23 Jun 2011 21:30:08 -0700 (PDT) Received: from 114-30-114-141.ip.adam.com.au ([114.30.114.141] helo=opy.nosense.org) by smtp2.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QZy1m-0003Gr-Kr; Fri, 24 Jun 2011 13:59:58 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 048653B33E; Fri, 24 Jun 2011 13:59:58 +0930 (CST) Date: Fri, 24 Jun 2011 13:59:57 +0930 From: Mark Smith To: Fernando Gont Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) Message-ID: <20110624135957.0664aa5e@opy.nosense.org> In-Reply-To: <4E0401AD.8070108@gont.com.ar> References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> <20110622210451.60ad8bce@opy.nosense.org> <4E0401AD.8070108@gont.com.ar> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 04:30:10 -0000 Hi Fernando, On Fri, 24 Jun 2011 00:17:01 -0300 Fernando Gont wrote: > On 06/22/2011 08:34 AM, Mark Smith wrote: > > >> I think it is a bit ironic that if a L2 device has to parse all extension > >> headers, that then L2 switching of IPv6 packets will be more expensive that > >> L3 routing them. > > > > It may be getting to the point where it'd probably be easier > > to address these issues by taking away hosts' ability to multicast to > > other hosts on the same segment i.e. switch to an NBMA/hub-and-spoke > > mode of LAN operation, allowing the designated routers to also act as > > traffic sanitisers for on-link inter-host traffic. > > Two comments: > > * Hosts would still need to multicast RSs Yes, but the layer 2 device only delivers those multicast RSes to ports that it has been told are attached to authorised routers. > * This does nto prevent attackers from sending ND packets *unicast* to > their victims. > Actually it can. Have a look at the following - http://tools.ietf.org/html/draft-ietf-6man-dad-proxy-01 The layer 3 hub-and-spoke forwarding topology described can also be and is likely to also be enforced at layer 2, by preventing layer 2 forwarding of traffic between designated host ports, limiting it to host port to router port, or router port to host port. It's interesting to look back on where we've come from. On simple 10BASE2 and earlier Ethernet, broadcast/multicast was cheap, because it was the inherent nature of it's bus topology. After we moved to bridges/switches with individual devices attached to each port, this broadcast/multicast capability had to be actively emulated, because a star topology does not have a natural broadcast/multicast capability. Implementing hub-and-spoke forwarding paths in a bridge/switch is not much more than reducing the requirement to emulate something that fundamentally wasn't natural in the first place. Regards, Mark. From swmike@swm.pp.se Thu Jun 23 22:14:58 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B6021F848A; Thu, 23 Jun 2011 22:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] 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 9QGUygd3LJQO; Thu, 23 Jun 2011 22:14:58 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id F293321F8488; Thu, 23 Jun 2011 22:14:57 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E336B9C; Fri, 24 Jun 2011 07:14:52 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id DEF3E9A; Fri, 24 Jun 2011 07:14:52 +0200 (CEST) Date: Fri, 24 Jun 2011 07:14:52 +0200 (CEST) From: Mikael Abrahamsson To: Ted Lemon Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) In-Reply-To: <63524B72-6890-48E4-926F-030744B415A2@nominum.com> Message-ID: References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> <20110622210451.60ad8bce@opy.nosense.org> <20110623095548.24d89d7f@opy.nosense.org> <63524B72-6890-48E4-926F-030744B415A2@nominum.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 05:14:59 -0000 On Thu, 23 Jun 2011, Ted Lemon wrote: > Is there a way that someone who is not running 802.1x can demonstrate > that they control layer 2? Doesn't 802.1x only control access as a non/off switch? As soon as you're connected to the network, I thought it was back to flat L2 default ethernet again? -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Thu Jun 23 22:16:13 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9316511E8071; Thu, 23 Jun 2011 22:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] 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 q3psnODBxCU4; Thu, 23 Jun 2011 22:16:13 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE2A11E80AF; Thu, 23 Jun 2011 22:16:08 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 6423F9C; Fri, 24 Jun 2011 07:16:07 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 621C49A; Fri, 24 Jun 2011 07:16:07 +0200 (CEST) Date: Fri, 24 Jun 2011 07:16:07 +0200 (CEST) From: Mikael Abrahamsson To: "Manfredi, Albert E" Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) In-Reply-To: Message-ID: References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> <20110622210451.60ad8bce@opy.nosense.org> <20110623095548.24d89d7f@opy.nosense.org> <63524B72-6890-48E4-926F-030744B415A2@nominum.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" , "ipv6@ietf.org" , Ted Lemon X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 05:16:14 -0000 On Thu, 23 Jun 2011, Manfredi, Albert E wrote: > It is service providers that are interested in protecting their > networks, in this discussion. If they also happen to protect their > clients, that is just a nice byproduct. We want to protect the Internet from our customers, not our customers from the Internet. > Service providers want to keep malicious clients from degrading their > network. Exactly. -- Mikael Abrahamsson email: swmike@swm.pp.se From ipng@69706e6720323030352d30312d31340a.nosense.org Thu Jun 23 23:05:21 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D37B9E800A; Thu, 23 Jun 2011 23:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 yovAELry9+KR; Thu, 23 Jun 2011 23:05:21 -0700 (PDT) Received: from smtp2.adam.net.au (smtp2.adam.net.au [202.136.110.251]) by ietfa.amsl.com (Postfix) with ESMTP id 111E6228006; Thu, 23 Jun 2011 23:05:20 -0700 (PDT) Received: from 114-30-114-141.ip.adam.com.au ([114.30.114.141] helo=opy.nosense.org) by smtp2.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QZzVz-0007x2-W1; Fri, 24 Jun 2011 15:35:16 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 6C8C33B33E; Fri, 24 Jun 2011 15:35:15 +0930 (CST) Date: Fri, 24 Jun 2011 15:35:15 +0930 From: Mark Smith To: Mikael Abrahamsson Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) Message-ID: <20110624153515.4e516f1c@opy.nosense.org> In-Reply-To: References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> <20110622210451.60ad8bce@opy.nosense.org> <20110623095548.24d89d7f@opy.nosense.org> <63524B72-6890-48E4-926F-030744B415A2@nominum.com> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, ipv6@ietf.org, Ted Lemon X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 06:05:21 -0000 On Fri, 24 Jun 2011 07:14:52 +0200 (CEST) Mikael Abrahamsson wrote: > On Thu, 23 Jun 2011, Ted Lemon wrote: > > > Is there a way that someone who is not running 802.1x can demonstrate > > that they control layer 2? > > Doesn't 802.1x only control access as a non/off switch? As soon as you're > connected to the network, I thought it was back to flat L2 default > ethernet again? > The thing I've been intending to investigate was whether 802.1x could deliver non-authentication related attributes to the supplicant upon successful authentication, similar to RADIUS Access-Accept messages. If it could, I think that could be used to perform the key distribution to bootstrap SeND. Regards, Mark. From pch-b2B3A6689@u-1.phicoh.com Thu Jun 23 15:08:33 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E15E811E8086; Thu, 23 Jun 2011 15:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.539 X-Spam-Level: X-Spam-Status: No, score=-8.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] 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 nWWHRjXsJE18; Thu, 23 Jun 2011 15:08:33 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id BA99A11E80D7; Thu, 23 Jun 2011 15:08:31 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QZs4b-0001glC; Fri, 24 Jun 2011 00:08:29 +0200 Message-Id: To: Ted Lemon Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> <20110622210451.60ad8bce@opy.nosense.org> <20110623095548.24d89d7f@opy.nosense.org> <63524B72-6890-48E4-926F-030744B415A2@nominum.com> <8F573F95-319F-4DC2-8D07-59C431E0E65E@nominum.com> In-reply-to: Your message of "Thu, 23 Jun 2011 17:56:47 -0400 ." <8F573F95-319F-4DC2-8D07-59C431E0E65E@nominum.com> Date: Fri, 24 Jun 2011 00:08:12 +0200 X-Mailman-Approved-At: Fri, 24 Jun 2011 04:21:01 -0700 Cc: "v6ops@ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 22:08:34 -0000 In your letter dated Thu, 23 Jun 2011 17:56:47 -0400 you wrote: >On Jun 23, 2011, at 5:31 PM, Manfredi, Albert E wrote: >> It is service providers that are interested in protecting their networks, in > this discussion. If they also happen to protect their clients, that is just a > nice byproduct. > >That's fine for service providers, but service providers are not the only inte >rested parties here. Mark's solution does fine for that use case, but I woul >d not want it on my home network. Ideally, clients use end-to-end crypto to keep themselves secure, but the network still has to be protected against denial of service attacks. From pch-b2B3A6689@u-1.phicoh.com Fri Jun 24 02:06:58 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD42611E809B; Fri, 24 Jun 2011 02:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.544 X-Spam-Level: X-Spam-Status: No, score=-8.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] 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 rg6ONwQ6GWZg; Fri, 24 Jun 2011 02:06:58 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF93228005; Fri, 24 Jun 2011 02:06:56 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1Qa2Lm-0001hFC; Fri, 24 Jun 2011 11:06:54 +0200 Message-Id: To: Ted Lemon Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> <20110622210451.60ad8bce@opy.nosense.org> <20110623095548.24d89d7f@opy.nosense.org> <63524B72-6890-48E4-926F-030744B415A2@nominum.com> <8F573F95-319F-4DC2-8D07-59C431E0E65E@nominum.com> <1A7FA259-3266-4FA6-91B7-2180A1065710@nominum.com> In-reply-to: Your message of "Thu, 23 Jun 2011 18:13:31 -0400 ." <1A7FA259-3266-4FA6-91B7-2180A1065710@nominum.com> Date: Fri, 24 Jun 2011 11:06:46 +0200 X-Mailman-Approved-At: Fri, 24 Jun 2011 04:21:01 -0700 Cc: "v6ops@ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 09:06:58 -0000 In your letter dated Thu, 23 Jun 2011 18:13:31 -0400 you wrote: >On Jun 23, 2011, at 6:08 PM, Philip Homburg wrote: >> Ideally, clients use end-to-end crypto to keep themselves secure, but = >the >> network still has to be protected against denial of service attacks. > >No, strictly speaking the *clients* need to be protected against DoS = >attacks. One way to do this is to strongly control multicast on the = >network. But the network itself cannot suffer from rogue RA = >advertisements: it is other clients on the network that suffer. You are right if we just limit ourselves to RAs. But my comment was meant to be broader than that. If a malcious client configures a router's MAC address on his ethernet card then it is not the clients' faults if L2 switches route traffic to the wrong port. Same thing if a malicious client uses another client's IP address and the router gets confused. From pch-b2B3A6689@u-1.phicoh.com Fri Jun 24 02:12:13 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9496411E809B; Fri, 24 Jun 2011 02:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.549 X-Spam-Level: X-Spam-Status: No, score=-8.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] 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 dci1-OfjDe1c; Fri, 24 Jun 2011 02:12:13 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 9204D11E8093; Fri, 24 Jun 2011 02:12:12 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1Qa2Qt-0001iEC; Fri, 24 Jun 2011 11:12:11 +0200 Message-Id: To: David Farmer Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> <20110622210451.60ad8bce@opy.nosense.org> <20110623095548.24d89d7f@opy.nosense.org> <63524B72-6890-48E4-926F-030744B415A2@nominum.com> <4E03E89D.3010603@umn.edu> In-reply-to: Your message of "Thu, 23 Jun 2011 20:30:05 -0500 ." <4E03E89D.3010603@umn.edu> Date: Fri, 24 Jun 2011 11:12:10 +0200 X-Mailman-Approved-At: Fri, 24 Jun 2011 04:21:01 -0700 Cc: v6ops@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 09:12:13 -0000 In your letter dated Thu, 23 Jun 2011 20:30:05 -0500 you wrote: >OH... That's an intriguing idea, use 802.1x to securely feed SEND. That >might even make using SEND practical in an open network environment like >a University. Its a massing protocol layering violation, but most >things in the security realm are. I'm not sure how that's supposed to improve things. To make 802.1x secure (for the client) the client needs to have the server's certificate. Otherwise there can be a man-in-the-middle attack. If you have a way of providing clients with certificates, why not distribute the keys for SEND directly? From fernando.gont.netbook.win@gmail.com Fri Jun 24 05:59:03 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1FB521F84DB; Fri, 24 Jun 2011 05:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.247 X-Spam-Level: X-Spam-Status: No, score=-3.247 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 W5NXezMLfg1t; Fri, 24 Jun 2011 05:59:03 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 03B7C21F84DA; Fri, 24 Jun 2011 05:59:02 -0700 (PDT) Received: by yie30 with SMTP id 30so1642711yie.31 for ; Fri, 24 Jun 2011 05:59:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=YaU7XhZAd9BAWvwtzb9e8KoGmilp4AtKDmb/VML+54Y=; b=pkPIANfSHUXqjCsOZ6Nll1yW3fOIafoRiaLZneDI3+rULJlFkqkRIQwVUQ1RntmHTP hWqAsT3t1k25KPH7S3Takn1WkkJMASMa/SUYcD9y+Wm8VO88lYduB1S3l0CMr+LZ+6J7 cJutrmXgYopFEUR/HTHII1kehMuNC+7mhiDr4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=kd9aNl/rViLpgAW8S3XaJYlLMM+0/Wt6Y9Aed/6Wkt8AcPnfdXd+xgqfH1rnuYhYwj sWi+ZqchsdorPANXeha8iEkfWk1i/X6sLim0dVG6j28czEFKxGMj+oV7zNX+HgORSh+j hdsi2glZu4XI+w3n3yM78EdfhqRE3/0AV5OX4= Received: by 10.101.165.10 with SMTP id s10mr749089ano.10.1308920341874; Fri, 24 Jun 2011 05:59:01 -0700 (PDT) Received: from [192.168.123.103] ([190.48.229.153]) by mx.google.com with ESMTPS id i6sm2529090anm.25.2011.06.24.05.58.58 (version=SSLv3 cipher=OTHER); Fri, 24 Jun 2011 05:59:00 -0700 (PDT) Sender: Fernando Gont Message-ID: <4E047E2A.806@gont.com.ar> Date: Fri, 24 Jun 2011 09:08:10 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: David Farmer Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> <20110622210451.60ad8bce@opy.nosense.org> <20110623095548.24d89d7f@opy.nosense.org> <63524B72-6890-48E4-926F-030744B415A2@nominum.com> <4E03E89D.3010603@umn.edu> In-Reply-To: <4E03E89D.3010603@umn.edu> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, ipv6@ietf.org, Ted Lemon X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 12:59:03 -0000 On 06/23/2011 10:30 PM, David Farmer wrote: >> There probably is no single solution. But let's consider the >> solution Mark proposed: use the fact that you control the >> infrastructure to control the flow of packets on the network in such >> a way that rogue RAs cannot reach leaf nodes. The reason I object >> to this solution, in addition to the fact that it breaks multicast, >> is that it's a firewall solution: the client doesn't know it's safe, >> and as soon as it connects to a network that's not protected in this >> way, it's vulnerable. But the model of using infrastructure control >> as a credential is interesting. > > I don't think of RA-Guard and DHCP-Guard filters as security measures, > they are simply network management and operations techniques. They > don't make the network more secure, but they can make operating some > networks much easier. If they can mitigate specific attack vectors, they do make the network more secure. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From farmer@umn.edu Fri Jun 24 06:39:18 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7580D11E8081; Fri, 24 Jun 2011 06:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] 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 2nRMAFFrh+xF; Fri, 24 Jun 2011 06:39:17 -0700 (PDT) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.135.88]) by ietfa.amsl.com (Postfix) with ESMTP id 7953011E8076; Fri, 24 Jun 2011 06:39:17 -0700 (PDT) Received: from mail-iw0-f171.google.com (mail-iw0-f171.google.com [209.85.214.171]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP Fri, 24 Jun 2011 08:39:07 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-iw0-f171.google.com [209.85.214.171] #+LO+TR X-Umn-Classification: local Received: by iwn34 with SMTP id 34so3734055iwn.16 for ; Fri, 24 Jun 2011 06:39:06 -0700 (PDT) Received: by 10.43.61.196 with SMTP id wx4mr3020640icb.310.1308922745976; Fri, 24 Jun 2011 06:39:05 -0700 (PDT) Received: from vpn0-823.vpn.umn.edu (vpn0-823.vpn.umn.edu [134.84.3.55]) by mx.google.com with ESMTPS id vn4sm2617099icb.7.2011.06.24.06.39.03 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 24 Jun 2011 06:39:04 -0700 (PDT) Message-ID: <4E049375.5070603@umn.edu> Date: Fri, 24 Jun 2011 08:39:01 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Philip Homburg Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> <20110622210451.60ad8bce@opy.nosense.org> <20110623095548.24d89d7f@opy.nosense.org> <63524B72-6890-48E4-926F-030744B415A2@nominum.com> <4E03E89D.3010603@umn.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 13:39:18 -0000 On 6/24/11 04:12 CDT, Philip Homburg wrote: > In your letter dated Thu, 23 Jun 2011 20:30:05 -0500 you wrote: >> OH... That's an intriguing idea, use 802.1x to securely feed SEND. That >> might even make using SEND practical in an open network environment like >> a University. Its a massing protocol layering violation, but most >> things in the security realm are. > > I'm not sure how that's supposed to improve things. To make 802.1x secure > (for the client) the client needs to have the server's certificate. Otherwise > there can be a man-in-the-middle attack. > > If you have a way of providing clients with certificates, why not distribute > the keys for SEND directly? From a technical and theoretical point of view you are correct, they are fundamentally the same problem. However, from a practical point of view, there are available solutions and tools, even some commercially available, for dealing with securely configuring 802.1x, especially in the wireless realm with WPA2, at many different scales, from the home user network all the way up to multinational enterprise. The issue even has some mind share with the non-technical end users world, thanks to the virus like spread of wireless home gateways. So, the key/certificate distribution problem is hard enough to do right once. We are getting close with 802.1x and WPA2, why not build on that for SEND? I'm not saying you shouldn't be able to configure SEND separately if you wish, and if you can that might be even more secure. But, being able to securely generate keys or obtain certificates for SEND using 802.1x and/or WPA2 would create a much lower barrier to entry for SEND. But even with all that, we don't eliminate the usefulness of RA-Guard in may situations. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From fernando@gont.com.ar Fri Jun 24 07:11:07 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1030C11E80B5; Fri, 24 Jun 2011 07:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.491 X-Spam-Level: X-Spam-Status: No, score=-4.491 tagged_above=-999 required=5 tests=[AWL=1.508, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] 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 3MRVhW4w-fyN; Fri, 24 Jun 2011 07:11:06 -0700 (PDT) Received: from mx3.sophos.com (mx3.sophos.com [74.202.89.160]) by ietfa.amsl.com (Postfix) with ESMTP id 553A011E80A1; Fri, 24 Jun 2011 07:11:05 -0700 (PDT) Received: from mx3.sophos.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3A5F4FA0029; Fri, 24 Jun 2011 15:11:04 +0100 (BST) Received: from dhost002-54.dex002.intermedia.net (dhost002-54.dex002.intermedia.net [64.78.21.151]) by mx3.sophos.com (Postfix) with ESMTPS id A25B3681A3; Fri, 24 Jun 2011 15:11:03 +0100 (BST) Received: from mail pickup service by dhost002-54.dex002.intermedia.net with Microsoft SMTPSVC; Fri, 24 Jun 2011 07:09:58 -0700 Received: from mx.astaro.com ([213.144.15.13]) by dhost002-54.dex002.intermedia.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Jun 2011 06:00:48 -0700 Received: from mail.ietf.org ([64.170.98.30]:60017) by mx.astaro.com with esmtp (Exim 4.69) (envelope-from ) id 1Qa604-00037t-1P for uweber@astaro.com; Fri, 24 Jun 2011 15:00:44 +0200 Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C3221F8504; Fri, 24 Jun 2011 05:59:06 -0700 (PDT) X-CTCH-RefID: str=0001.0A0B0207.4E048A7C.01A9:SCFSTAT11644009,ss=1,fgs=0 X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1FB521F84DB; Fri, 24 Jun 2011 05:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 W5NXezMLfg1t; Fri, 24 Jun 2011 05:59:03 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 03B7C21F84DA; Fri, 24 Jun 2011 05:59:02 -0700 (PDT) Received: by yie30 with SMTP id 30so1642711yie.31 for ; Fri, 24 Jun 2011 05:59:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=YaU7XhZAd9BAWvwtzb9e8KoGmilp4AtKDmb/VML+54Y=; b=pkPIANfSHUXqjCsOZ6Nll1yW3fOIafoRiaLZneDI3+rULJlFkqkRIQwVUQ1RntmHTP hWqAsT3t1k25KPH7S3Takn1WkkJMASMa/SUYcD9y+Wm8VO88lYduB1S3l0CMr+LZ+6J7 cJutrmXgYopFEUR/HTHII1kehMuNC+7mhiDr4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=kd9aNl/rViLpgAW8S3XaJYlLMM+0/Wt6Y9Aed/6Wkt8AcPnfdXd+xgqfH1rnuYhYwj sWi+ZqchsdorPANXeha8iEkfWk1i/X6sLim0dVG6j28czEFKxGMj+oV7zNX+HgORSh+j hdsi2glZu4XI+w3n3yM78EdfhqRE3/0AV5OX4= Received: by 10.101.165.10 with SMTP id s10mr749089ano.10.1308920341874; Fri, 24 Jun 2011 05:59:01 -0700 (PDT) Received: from [192.168.123.103] ([190.48.229.153]) by mx.google.com with ESMTPS id i6sm2529090anm.25.2011.06.24.05.58.58 (version=SSLv3 cipher=OTHER); Fri, 24 Jun 2011 05:59:00 -0700 (PDT) Message-ID: <4E047E2A.806@gont.com.ar> Date: Fri, 24 Jun 2011 09:08:10 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: David Farmer References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> <20110622210451.60ad8bce@opy.nosense.org> <20110623095548.24d89d7f@opy.nosense.org> <63524B72-6890-48E4-926F-030744B415A2@nominum.com> <4E03E89D.3010603@umn.edu> In-Reply-To: <4E03E89D.3010603@umn.edu> X-Enigmail-Version: 1.1.2 Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: v6ops-bounces@ietf.org Errors-To: v6ops-bounces@ietf.org X-OriginalArrivalTime: 24 Jun 2011 13:00:48.0981 (UTC) FILETIME=[BD407050:01CC326E] Cc: v6ops@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 14:11:07 -0000 On 06/23/2011 10:30 PM, David Farmer wrote: >> There probably is no single solution. But let's consider the >> solution Mark proposed: use the fact that you control the >> infrastructure to control the flow of packets on the network in such >> a way that rogue RAs cannot reach leaf nodes. The reason I object >> to this solution, in addition to the fact that it breaks multicast, >> is that it's a firewall solution: the client doesn't know it's safe, >> and as soon as it connects to a network that's not protected in this >> way, it's vulnerable. But the model of using infrastructure control >> as a credential is interesting. > > I don't think of RA-Guard and DHCP-Guard filters as security measures, > they are simply network management and operations techniques. They > don't make the network more secure, but they can make operating some > networks much easier. If they can mitigate specific attack vectors, they do make the network more secure. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From fernando.gont.netbook.win@gmail.com Fri Jun 24 07:59:33 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA4F21F8445; Fri, 24 Jun 2011 07:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.458 X-Spam-Level: X-Spam-Status: No, score=-3.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 0U1VxbjfKYuW; Fri, 24 Jun 2011 07:59:28 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 92A7D21F8440; Fri, 24 Jun 2011 07:59:28 -0700 (PDT) Received: by gwb20 with SMTP id 20so1696179gwb.31 for ; Fri, 24 Jun 2011 07:59:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=Xvfypji8FPO1O3AzTgH1Zk9J7/UyhRQembFnnwiXM4A=; b=I7bmC8ujjGbpbujcWyvnVWkDJnG81sZvr+MXY5d3MGcLywU91RZYYB+AsWjIUARANq mi+ewOdqf2pBFot/lcU7vk8GunNMtVYDgrnTaSTFj0B8YZCv5YwKaIR4hCZ5omW90qiQ 2pjVq4hag2nRRPpaiNVxM407eUgGssgFUK2eQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=wASJAl8ESkt73qwlHv3NPp7XZyD1a8q6H4AbW0d3aTIUXyPdcRAlfykwvvQBOwUEJ7 nCG+bkXGrO0qJ20fkUZS0VTy2EmjDFwSskjJO4vra2A7wm59Fr1g7GkN2nmq2kwBqcLu 2p8EVDi8SrISpBSQQ69LFg62kBytPVg+W3P4A= Received: by 10.90.248.10 with SMTP id v10mr3937217agh.54.1308927566308; Fri, 24 Jun 2011 07:59:26 -0700 (PDT) Received: from [192.168.123.103] ([190.48.229.153]) by mx.google.com with ESMTPS id w19sm2619196anf.12.2011.06.24.07.59.22 (version=SSLv3 cipher=OTHER); Fri, 24 Jun 2011 07:59:24 -0700 (PDT) Sender: Fernando Gont Message-ID: <4E048FC7.5070706@gont.com.ar> Date: Fri, 24 Jun 2011 10:23:19 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Mark Smith Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> <20110622210451.60ad8bce@opy.nosense.org> <4E0401AD.8070108@gont.com.ar> <20110624135957.0664aa5e@opy.nosense.org> In-Reply-To: <20110624135957.0664aa5e@opy.nosense.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 14:59:33 -0000 On 06/24/2011 01:29 AM, Mark Smith wrote: > Actually it can. Have a look at the following - > > http://tools.ietf.org/html/draft-ietf-6man-dad-proxy-01 > > The layer 3 hub-and-spoke forwarding topology described can also be and > is likely to also be enforced at layer 2, by preventing layer 2 > forwarding of traffic between designated host ports, limiting it to > host port to router port, or router port to host port. I think that deploying this only for dealing with ND-based attacks would be overkill. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From ipng@69706e6720323030352d30312d31340a.nosense.org Fri Jun 24 08:04:59 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFCBD21F8566; Fri, 24 Jun 2011 08:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.835 X-Spam-Level: X-Spam-Status: No, score=-1.835 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 xfIkXzhJL+v0; Fri, 24 Jun 2011 08:04:59 -0700 (PDT) Received: from smtp2.adam.net.au (smtp2.adam.net.au [202.136.110.251]) by ietfa.amsl.com (Postfix) with ESMTP id 58AF221F8560; Fri, 24 Jun 2011 08:04:59 -0700 (PDT) Received: from 114-30-114-141.ip.adam.com.au ([114.30.114.141] helo=opy.nosense.org) by smtp2.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1Qa7wA-0003Tx-UP; Sat, 25 Jun 2011 00:34:50 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 49A243B341; Sat, 25 Jun 2011 00:34:50 +0930 (CST) Date: Sat, 25 Jun 2011 00:34:50 +0930 From: Mark Smith To: Fernando Gont Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) Message-ID: <20110625003450.6369ba85@opy.nosense.org> In-Reply-To: <4E048FC7.5070706@gont.com.ar> References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> <20110622210451.60ad8bce@opy.nosense.org> <4E0401AD.8070108@gont.com.ar> <20110624135957.0664aa5e@opy.nosense.org> <4E048FC7.5070706@gont.com.ar> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 15:05:00 -0000 On Fri, 24 Jun 2011 10:23:19 -0300 Fernando Gont wrote: > On 06/24/2011 01:29 AM, Mark Smith wrote: > > Actually it can. Have a look at the following - > > > > http://tools.ietf.org/html/draft-ietf-6man-dad-proxy-01 > > > > The layer 3 hub-and-spoke forwarding topology described can also be and > > is likely to also be enforced at layer 2, by preventing layer 2 > > forwarding of traffic between designated host ports, limiting it to > > host port to router port, or router port to host port. > > I think that deploying this only for dealing with ND-based attacks would > be overkill. > Depends on who you are. > Thanks, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > From brian@innovationslab.net Fri Jun 24 10:13:34 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0307911E80E4 for ; Fri, 24 Jun 2011 10:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.669 X-Spam-Level: X-Spam-Status: No, score=-101.669 tagged_above=-999 required=5 tests=[AWL=0.930, 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 0qAZqfSZ4NjX for ; Fri, 24 Jun 2011 10:13:32 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id D25D011E80B2 for ; Fri, 24 Jun 2011 10:13:32 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 80CBF881A6 for ; Fri, 24 Jun 2011 10:13:32 -0700 (PDT) Received: from tigers.local (unknown [75.94.92.25]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id B37C31369552 for ; Fri, 24 Jun 2011 10:13:31 -0700 (PDT) Message-ID: <4E04C5B8.5010505@innovationslab.net> Date: Fri, 24 Jun 2011 13:13:28 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Consensus call on adopting: draft-hartmann-6man-addressnaming References: <4DD40582.40005@innovationslab.net> In-Reply-To: <4DD40582.40005@innovationslab.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 17:13:34 -0000 All, Sorry for the delay in posting this, but there is no consensus to adopt this draft as a 6MAN document. Regards, Brian On 5/18/11 1:44 PM, Brian Haberman wrote: > All, > This starts a 2-week consensus call on adopting: > > Title : Naming IPv6 address parts > Author(s) : L. Donnerhacke, et al. > Filename : draft-hartmann-6man-addresspartnaming-01.txt > Pages : 8 > Date : 2011-05-06 > > as a 6MAN WG document. Please state your opinion (either for or > against) on making this draft a WG draft either on the mailing list or > to the chairs. This call will end on May 1, 2011. > > Regards, > Brian & Bob > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From fernando.gont.netbook.win@gmail.com Fri Jun 24 12:31:34 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFB8711E80BE; Fri, 24 Jun 2011 12:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.473 X-Spam-Level: X-Spam-Status: No, score=-3.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 MaMCpvYPryvZ; Fri, 24 Jun 2011 12:31:33 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE4511E8084; Fri, 24 Jun 2011 12:31:33 -0700 (PDT) Received: by gya6 with SMTP id 6so1815589gya.31 for ; Fri, 24 Jun 2011 12:31:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=GAImZqxfpNN3vuqn+gc3pmQSKKRQHQ3I80oybROUmUs=; b=OOE0xgCKqJSrt31JtUwlcoOvUbLupUiynAreUHAt3IaTuFsJQgkQB8S07+ksXEAt81 LuAcEo2dEfi2MKMxFW9vpBpvWNs9qjPVIGtVYCn0WFcsbBrZ5ak2w8VMkQA5+vgwpYS5 JlwoXsaKNHaBHOjgJhSgVSOsKFiTjw+tDTLjQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=gqK+LZt4YvBtDOEmvWvDRpTB/oKC7EyeKbD8LZLL33U+QquNMzezc5FgMj/NVn7yXQ GBYi/kGqMWlzG+1gOVcAaZxcpnVT78lP595gLidKtLz2x+TSDF10UkGjX2seB3QD0oun cSyQbITvCSXXkRWmXS7Blek9DQNarqeftwVTQ= Received: by 10.101.179.39 with SMTP id g39mr3974041anp.96.1308943892944; Fri, 24 Jun 2011 12:31:32 -0700 (PDT) Received: from [192.168.123.103] ([190.48.229.153]) by mx.google.com with ESMTPS id c21sm2812391ana.50.2011.06.24.12.31.28 (version=SSLv3 cipher=OTHER); Fri, 24 Jun 2011 12:31:31 -0700 (PDT) Sender: Fernando Gont Message-ID: <4E04E60E.7010808@gont.com.ar> Date: Fri, 24 Jun 2011 16:31:26 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Fred Baker Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: RJ Atkinson , v6ops@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 19:31:34 -0000 On 06/22/2011 05:04 PM, Fred Baker wrote: >> From my perspective, the issue with the RA-Guard evasion draft >> isn't that the faults are possible or that they are described; it's >> that the description is specific to RA-Guard. In point of fact, >> these kinds of attacks are true for any kind of firewall or other >> middleware that has the notion of identifying a specific non-IP >> packet and selectively do something to it. There some specific considerations for RA-Guard: * RA-Guard has been specified, whereas firewall behaviour hasn't. * Many networks employ DHCPv4-guard and/or arp-monitoring, and probably expect to be able to do the same thing with IPv6 -- but these evasion techniques apply only to the v6 case * RA-Guard is implemented in layer-2 devices, where fragment reassembly would be too onerous. >> to eliminate pornography, Al-Queda literature, or dog racing should >> be advised that overcoming that is as simple as https or obscure >> fragmentation that splits a "GET" at a difficult place. Parsing the app stream was already difficult with v4. Not being able to even find the upper-layer header is new with v6. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From brian.e.carpenter@gmail.com Sat Jun 25 18:07:10 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5197911E80BA for ; Sat, 25 Jun 2011 18:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.511 X-Spam-Level: X-Spam-Status: No, score=-103.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 xgqGKM0YvoVZ for ; Sat, 25 Jun 2011 18:07:09 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id 492BD11E8080 for ; Sat, 25 Jun 2011 18:07:09 -0700 (PDT) Received: by fxe4 with SMTP id 4so1279104fxe.27 for ; Sat, 25 Jun 2011 18:07:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZhwkWD3wO7FoqJVX98MaNLQmrkv4veCHBV/X3IJO+Ng=; b=UgOvLc/4Z4MrthZap1Mci6Fz6F6Op3MMSomYds5VsUzYl082qs02DGNEyskLYnxTTW i+eP0/TpW6/YMIBm1w4LPrRUzL2UmDqaIZpWy1FcOX3XAplwz6haN6+gpUSEP/IPF0gS k7IY7A+XTM/H8lTUz4G1RxaXzKSrihOHH9YFw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=D6QPxqe/1ZecxnpgBUj9bJSWmHvKG70GecGl/wClYdgZKrsOlvyW/+Jxog2O/9mwQJ Rx3AJ/8W7JK+koXEfzscMXMGrG7dQr45LjME217m8hsf5IrQ/CycUgFLKzZNGVLiqjw+ GApwGLF0IVxD3m2bt+FS0OtEgaQOw8zvPfHnw= Received: by 10.223.99.153 with SMTP id u25mr5168587fan.112.1309050428029; Sat, 25 Jun 2011 18:07:08 -0700 (PDT) Received: from [10.255.25.96] (74-95-74-1-Indianapolis.hfc.comcastbusiness.net [74.95.74.1]) by mx.google.com with ESMTPS id n7sm2581600fam.19.2011.06.25.18.07.04 (version=SSLv3 cipher=OTHER); Sat, 25 Jun 2011 18:07:06 -0700 (PDT) Message-ID: <4E068630.7010502@gmail.com> Date: Sun, 26 Jun 2011 13:06:56 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jari Arkko Subject: Re: AD review of draft-ietf-6man-flow-3697bis References: <4DFF70A4.7040807@piuha.net> In-Reply-To: <4DFF70A4.7040807@piuha.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF IPv6 Mailing List , draft-ietf-6man-flow-3697bis@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 01:07:10 -0000 Hi, The discussion Jari's issue has died down, so I'd like to propose some revised text: A node that forwards a flow whose flow label value in arriving packets is zero MAY change the flow label value. In that case, it is RECOMMENDED that the forwarding node sets the flow label field for a flow to a uniformly distributed value as just described for source nodes. o The same considerations apply as to source hosts setting the flow label; in particular, the preferred case is that a flow is defined by the 5-tuple. However, there are cases in which the complete 5-tuple for all packets is not readily available to a forwarding node, in particular for fragmented packets. In such cases a flow can be defined by fewer IPv6 header fields, typically using only the 2-tuple {dest addr, source addr}. A forwarding node implementation MAY use this 2-tuple in all cases. [BC: this version indicates the problem that Jari discovered, but is agnostic on the question of whether a router could or should solve it by reassembling the fragmented packet.] o This option, if implemented, would presumably be used by first-hop or ingress routers. It might place a considerable per-packet processing load on them, even if they adopted a stateless method of flow identification and label assignment. This is why the principal recommendation is that the source host should set the label. o The deployment of this option MUST be consistent with [RFC4311]. [BC: This last sentence is to cover Jari's point about a router knowing it's appropriate for it to set the label.] Comments? If not, I will post the draft in a day or two.] Regards Brian Carpenter On 2011-06-21 04:09, Jari Arkko wrote: > I have reviewed this draft. > > I think it is in good shape and can move forward once we resolve one > issue. Here's the issue: > >> A node that forwards a flow whose flow label value in arriving >> packets is zero MAY change the flow label value. In that case, it is >> RECOMMENDED that the forwarding node sets the flow label field for a >> flow to a uniformly distributed value as just described for source >> nodes. >> o The same considerations apply as to source hosts setting the flow >> label; in particular, the normal case is that a flow is defined by >> the 5-tuple. >> o This option, if implemented, would presumably be used by first-hop >> or ingress routers. It might place a considerable per-packet >> processing load on them, even if they adopted a stateless method >> of flow identification and label assignment. This is why the >> principal recommendation is that the source host should set the >> label. >> > I think this recommendation is problematic. I agree that the first hop > router should insert the flow label, but requiring it to do fragment > reassembly in order to find the 5-tuple is a big burden, and I'm not > sure its even called for. > > The RFC 2119 language above is fine. But I'd like to change the part > about normal case being the 5-tuple. I think the normal case should be > the 2-tuple under these circumstances. The source has access to the > 5-tuple; a router is not guaranteed to have access to it. > > In addition, I'm not sure I understand how a router knows that it is a > first hop router. Are there cases where a device might mistakenly > believe it is a first hop router at a point where the traffic has > already been load-balanced to multiple routers? Are there situations > where the multiple first hop routers are used from the same host? The > document should provide some guidance about operational conditions where > the recommendations for the first hop router can be applied. The > document should state how such functionality is turned on (per > configuration? automatically?) and provide assurances that problematic > conditions can be avoided. > > Jari > > From brian@innovationslab.net Mon Jun 27 06:51:14 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9569221F85BA for ; Mon, 27 Jun 2011 06:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 8ujobElKxsrg for ; Mon, 27 Jun 2011 06:51:13 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 39F9B21F85E6 for ; Mon, 27 Jun 2011 06:50:16 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id F2D4A88141 for ; Mon, 27 Jun 2011 06:48:16 -0700 (PDT) Received: from tigers.local (unknown [75.94.92.25]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 4A66B1369555 for ; Mon, 27 Jun 2011 06:48:16 -0700 (PDT) Message-ID: <4E088A1A.5000209@innovationslab.net> Date: Mon, 27 Jun 2011 09:48:10 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: AD review of draft-ietf-6man-flow-3697bis References: <4DFF70A4.7040807@piuha.net> <4E068630.7010502@gmail.com> In-Reply-To: <4E068630.7010502@gmail.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 13:51:14 -0000 Brian, On 6/25/11 9:06 PM, Brian E Carpenter wrote: > Hi, > > The discussion Jari's issue has died down, so I'd like to propose some revised text: > > A node that forwards a flow whose flow label value in arriving > packets is zero MAY change the flow label value. In that case, it is > RECOMMENDED that the forwarding node sets the flow label field for a > flow to a uniformly distributed value as just described for source > nodes. > o The same considerations apply as to source hosts setting the flow > label; in particular, the preferred case is that a flow is defined > by the 5-tuple. However, there are cases in which the complete > 5-tuple for all packets is not readily available to a forwarding > node, in particular for fragmented packets. In such cases a flow > can be defined by fewer IPv6 header fields, typically using only > the 2-tuple {dest addr, source addr}. A forwarding node > implementation MAY use this 2-tuple in all cases. > > [BC: this version indicates the problem that Jari discovered, but is > agnostic on the question of whether a router could or should solve it > by reassembling the fragmented packet.] > > o This option, if implemented, would presumably be used by first-hop > or ingress routers. It might place a considerable per-packet > processing load on them, even if they adopted a stateless method > of flow identification and label assignment. This is why the > principal recommendation is that the source host should set the > label. > o The deployment of this option MUST be consistent with [RFC4311]. > > [BC: This last sentence is to cover Jari's point about a router knowing it's > appropriate for it to set the label.] > > Comments? If not, I will post the draft in a day or two.] These changes look fine to me. Regards, Brian From shane@castlepoint.net Mon Jun 27 07:29:36 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D74721F862E for ; Mon, 27 Jun 2011 07:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 2Gst94+AgJ5D for ; Mon, 27 Jun 2011 07:29:35 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id B66B321F862D for ; Mon, 27 Jun 2011 07:29:35 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 4320126806D; Mon, 27 Jun 2011 08:29:35 -0600 (MDT) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 27 Jun 2011 08:29:35 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=61051; data-bytes=0 Subject: Re: AD review of draft-ietf-6man-flow-3697bis Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: <4E068630.7010502@gmail.com> Date: Mon, 27 Jun 2011 08:29:33 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <8631C8D9-C22B-4CFA-8CC4-C2791B6BD5BF@castlepoint.net> References: <4DFF70A4.7040807@piuha.net> <4E068630.7010502@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1084) Cc: "draft-ietf-6man-flow-3697bis@tools.ietf.org" , IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 14:29:36 -0000 Brian, On Jun 25, 2011, at 7:06 PM, Brian E Carpenter wrote: > Hi, >=20 > The discussion Jari's issue has died down, so I'd like to propose some = revised text: >=20 > A node that forwards a flow whose flow label value in arriving > packets is zero MAY change the flow label value. In that case, it = is > RECOMMENDED that the forwarding node sets the flow label field for a > flow to a uniformly distributed value as just described for source > nodes. > o The same considerations apply as to source hosts setting the flow > label; in particular, the preferred case is that a flow is = defined > by the 5-tuple. However, there are cases in which the complete > 5-tuple for all packets is not readily available to a forwarding > node, in particular for fragmented packets. In such cases a flow > can be defined by fewer IPv6 header fields, typically using only > the 2-tuple {dest addr, source addr}. A forwarding node > implementation MAY use this 2-tuple in all cases. I'm not comfortable with the words "in all cases" in the last sentence. = Perhaps change "in all cases" to "in these cases"? (IOW, I don't = believe you're trying to relax the rule that use of the 5-tuple is = generally preferred to construct a hash for the flow-label where = _practical_). > [BC: this version indicates the problem that Jari discovered, but is > agnostic on the question of whether a router could or should solve it > by reassembling the fragmented packet.] >=20 > o This option, if implemented, would presumably be used by = first-hop > or ingress routers. It might place a considerable per-packet > processing load on them, even if they adopted a stateless method > of flow identification and label assignment. This is why the > principal recommendation is that the source host should set the > label. > o The deployment of this option MUST be consistent with [RFC4311]. >=20 > [BC: This last sentence is to cover Jari's point about a router = knowing it's > appropriate for it to set the label.] >=20 > Comments? If not, I will post the draft in a day or two.] >=20 > Regards > Brian Carpenter >=20 >=20 >=20 >=20 > On 2011-06-21 04:09, Jari Arkko wrote: >> I have reviewed this draft. >>=20 >> I think it is in good shape and can move forward once we resolve one >> issue. Here's the issue: >>=20 >>> A node that forwards a flow whose flow label value in arriving >>> packets is zero MAY change the flow label value. In that case, it = is >>> RECOMMENDED that the forwarding node sets the flow label field for a >>> flow to a uniformly distributed value as just described for source >>> nodes. >>> o The same considerations apply as to source hosts setting the flow >>> label; in particular, the normal case is that a flow is defined by >>> the 5-tuple. >>> o This option, if implemented, would presumably be used by = first-hop >>> or ingress routers. It might place a considerable per-packet >>> processing load on them, even if they adopted a stateless method >>> of flow identification and label assignment. This is why the >>> principal recommendation is that the source host should set the >>> label. >>>=20 >> I think this recommendation is problematic. I agree that the first = hop >> router should insert the flow label, but requiring it to do fragment >> reassembly in order to find the 5-tuple is a big burden, and I'm not >> sure its even called for. >>=20 >> The RFC 2119 language above is fine. But I'd like to change the part >> about normal case being the 5-tuple. I think the normal case should = be >> the 2-tuple under these circumstances. The source has access to the >> 5-tuple; a router is not guaranteed to have access to it. >>=20 >> In addition, I'm not sure I understand how a router knows that it is = a >> first hop router. Are there cases where a device might mistakenly >> believe it is a first hop router at a point where the traffic has >> already been load-balanced to multiple routers? Are there situations >> where the multiple first hop routers are used from the same host? The >> document should provide some guidance about operational conditions = where >> the recommendations for the first hop router can be applied. The >> document should state how such functionality is turned on (per >> configuration? automatically?) and provide assurances that = problematic >> conditions can be avoided. >>=20 >> Jari >>=20 >>=20 From internet-drafts@ietf.org Mon Jun 27 10:54:15 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB8D111E810F; Mon, 27 Jun 2011 10:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.431 X-Spam-Level: X-Spam-Status: No, score=-102.431 tagged_above=-999 required=5 tests=[AWL=0.168, 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 8d6BiVR0KBZn; Mon, 27 Jun 2011 10:54:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C9111E80CF; Mon, 27 Jun 2011 10:54:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-exthdr-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110627175415.3884.80988.idtracker@ietfa.amsl.com> Date: Mon, 27 Jun 2011 10:54:15 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 17:54:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the= IETF. Title : An uniform format for IPv6 extension headers Author(s) : Suresh Krishnan Apple Inc. Erik Kline James Hoagland Manav Bhatia Filename : draft-ietf-6man-exthdr-03.txt Pages : 8 Date : 2011-06-27 In IPv6, optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the transport layer header. There are a small number of such extension headers currently defined. This document defines a format for defining new IPv6 extension headers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-exthdr-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-exthdr-03.txt From narten@us.ibm.com Mon Jun 27 12:50:05 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0650B11E8165 for ; Mon, 27 Jun 2011 12:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 LcIloTPRrCXb for ; Mon, 27 Jun 2011 12:50:04 -0700 (PDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by ietfa.amsl.com (Postfix) with ESMTP id 4882311E8154 for ; Mon, 27 Jun 2011 12:50:04 -0700 (PDT) Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e5.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p5RJLgY6030915 for ; Mon, 27 Jun 2011 15:21:42 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p5RJnsXx151066 for ; Mon, 27 Jun 2011 15:49:56 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p5RJnpKr011603 for ; Mon, 27 Jun 2011 16:49:53 -0300 Received: from cichlid.raleigh.ibm.com (sig-9-65-253-226.mts.ibm.com [9.65.253.226]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p5RJnmWx011123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Jun 2011 16:49:49 -0300 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p5RJngpd013577; Mon, 27 Jun 2011 15:49:42 -0400 Message-Id: <201106271949.p5RJngpd013577@cichlid.raleigh.ibm.com> To: RJ Atkinson Subject: Re: AD review of draft-ietf-6man-flow-3697bis In-reply-to: <3E9CAB5A-0692-4F56-A24D-EFB7E6627D0D@gmail.com> References: <4E00A71F.1000201@piuha.net> <3E9CAB5A-0692-4F56-A24D-EFB7E6627D0D@gmail.com> Comments: In-reply-to RJ Atkinson message dated "Tue, 21 Jun 2011 11:00:53 -0400." Date: Mon, 27 Jun 2011 15:49:42 -0400 From: Thomas Narten Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 19:50:05 -0000 RJ Atkinson writes: > In the approach I outlined, for some given flow where the > originating node did not set a Flow Label value, the > non-fragmented packets all will have some Flow Label value A, > while fragmented packets all will have some Flow Label value B. > With high probability, (A != B). Still, this outcome is not > obviously worse than having all of those packets with a Flow Label > value of zero. IMO, it is worse. It means that packets with the different Flow Labels may take different paths, and thus arrive at the destination out of order relative to each other. This is known to cause problems with TCP. Sure, implementations may (generally) be able to handle this better today than in the past, it is not the case that reordering packets has no impact. It will depend on various factors... Setting the Flow Label using only the 2-typle for all packets would prevent this reording. (It would have other undesirable effects of having the load balancing not work ideally, but that is a different issue.) That said, I agree that there is no easy way to end up with the same flow label value for both fragmented and unfragmented packets (unless set by the source). I also agree that having routers reassemble packets in order to generate proper Flow Ids would be a silly requirement (or suggestion) and no router would implement that. I think we are stuck with having different flow ids being generated for fragmented vs. unfragmented packets. Thomas From rja.lists@gmail.com Mon Jun 27 13:44:59 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1648A11E8185 for ; Mon, 27 Jun 2011 13:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 qbQBRz9mYw6O for ; Mon, 27 Jun 2011 13:44:58 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id CA1DC11E817F for ; Mon, 27 Jun 2011 13:44:53 -0700 (PDT) Received: by vws12 with SMTP id 12so5100891vws.31 for ; Mon, 27 Jun 2011 13:44:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=XzEnXmj42t9d+RJ14v0ynhY0HGReMeLeRo1hvG1FTq4=; b=goCs73zkkhHfe/s2idRHWMaD9euanu3UGSoJ4vynylMLeFiXVZ52sLeFoy0U3f5vI6 sozwSgr6BnAeuEeO8+GR0mt+UKnPK8cxiYR7PrQBFgHimgIsDzFUi4EvtBNJWc5+1V8h 4PgAt9hbFjTH2c+SAWpeeqzN01Vxpj8M8w+xk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=XB3vmFMkuYqHxbFjxE6iQbu1/+Snx8NSYObfwZApb9Pvveag9pKsUcUhEIoadDlVdF hXeX9+YZuJqFxvWcvr4R7hQeF9M8HfRb74+59or4LMHctdC92nLTI9pLpQ0uSu4+bNnb vGG8qH2kuVWNhT+irwNWB77GzmmScPdsD++dM= Received: by 10.52.75.167 with SMTP id d7mr8965001vdw.95.1309207493156; Mon, 27 Jun 2011 13:44:53 -0700 (PDT) Received: from [10.30.20.12] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id z7sm1647210vdg.19.2011.06.27.13.44.51 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 27 Jun 2011 13:44:52 -0700 (PDT) Subject: Re: AD review of draft-ietf-6man-flow-3697bis Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: RJ Atkinson In-Reply-To: <201106271949.p5RJngpd013577@cichlid.raleigh.ibm.com> Date: Mon, 27 Jun 2011 16:44:50 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <4E00A71F.1000201@piuha.net> <3E9CAB5A-0692-4F56-A24D-EFB7E6627D0D@gmail.com> <201106271949.p5RJngpd013577@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1084) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 20:44:59 -0000 On 27 Jun 2011, at 15:49 , Thomas Narten wrote: > RJ Atkinson writes: >> In the approach I outlined, for some given flow where the >> originating node did not set a Flow Label value, the >> non-fragmented packets all will have some Flow Label value A, >> while fragmented packets all will have some Flow Label value B. >> With high probability, (A != B). Still, this outcome is not >> obviously worse than having all of those packets with a Flow Label >> value of zero. > > IMO, it is worse. It means that packets with the different Flow Labels > may take different paths, and thus arrive at the destination out of > order relative to each other. This is ALSO true for packets containing an all-zero Flow Label. Existing deployed routers typically go read the transport-protocol and transport-layer ports, and load-balance based on all 5 values (IP addresses, transport protocol, plus transport-layer port numbers). If not all 5 values are accesssible, for example due to presence of a Fragmentation Header, then existing deployed routers typically use the 2 values available (i.e. IP addresses). For the case where the Flow Label is zero, I fully expect that routers will use the currently deployed behaviour. So having 2 different Flow Label values in the case I describe at top yields **identical** behaviour as today -- therefore "not obviously worse" in the quote at top. > This is known to cause problems with TCP. Sure, implementations > may (generally) be able to handle this better today than in the past, > it is not the case that reordering packets has no impact. Historically, back in the days of 4.3 BSD TCP performance was seriously harmed by packet reordering. Modern TCP implementations, however, are more robust. So the performance impact of small amounts of packet reordering (which is the case here) ranges between minor and ignorable. > Setting the Flow Label using only the 2-typle for all packets > would prevent this reordering. No. It would not. Packet reordering will still occur from time to time in the deployed Internet -- no matter what the Flow Label values might be. > That said, I agree that there is no easy way to end up with the same > flow label value for both fragmented and unfragmented packets (unless > set by the source). I also agree that having routers reassemble > packets in order to generate proper Flow Ids would be a silly > requirement (or suggestion) and no router would implement that. > > I think we are stuck with having different flow ids being generated > for fragmented vs. unfragmented packets. I'm glad we ended up the same place, although we clearly followed different reasoning to get there. :-) Cheers, Ran From narten@us.ibm.com Mon Jun 27 14:09:12 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7FF21F8566 for ; Mon, 27 Jun 2011 14:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 hTuXDMTeN023 for ; Mon, 27 Jun 2011 14:09:11 -0700 (PDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by ietfa.amsl.com (Postfix) with ESMTP id 1437D21F8562 for ; Mon, 27 Jun 2011 14:09:11 -0700 (PDT) Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by e5.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p5RKekMg027354 for ; Mon, 27 Jun 2011 16:40:46 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p5RL8xJM1413160 for ; Mon, 27 Jun 2011 17:08:59 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p5RL8x5I008241 for ; Mon, 27 Jun 2011 17:08:59 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-65-253-226.mts.ibm.com [9.65.253.226]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p5RL8wq6008190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Jun 2011 17:08:59 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p5RL8uet015584; Mon, 27 Jun 2011 17:08:57 -0400 Message-Id: <201106272108.p5RL8uet015584@cichlid.raleigh.ibm.com> To: RJ Atkinson Subject: Re: AD review of draft-ietf-6man-flow-3697bis In-reply-to: References: <4E00A71F.1000201@piuha.net> <3E9CAB5A-0692-4F56-A24D-EFB7E6627D0D@gmail.com> <201106271949.p5RJngpd013577@cichlid.raleigh.ibm.com> Comments: In-reply-to RJ Atkinson message dated "Mon, 27 Jun 2011 16:44:50 -0400." Date: Mon, 27 Jun 2011 17:08:56 -0400 From: Thomas Narten Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 21:09:12 -0000 RJ Atkinson writes: > For the case where the Flow Label is zero, I fully expect that routers > will use the currently deployed behaviour. So having 2 different > Flow Label values in the case I describe at top yields **identical** > behaviour as today -- therefore "not obviously worse" in the quote > at top. OK. We are in agreement on the technical points. But I disagree that just because this is what happens today (with the limited IPv6 usage at hand), it is fine. We don't have enough experience with IPv6 usage today to really say that this is fine. Your use of the term "not obviously worse" is a bit misleading, IMO, since we have almost zero experience with the IPv6 Flow Label today. Anyway, we are on the same page in terms of what we can do about it. Thomas From jari.arkko@piuha.net Mon Jun 27 15:57:22 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBFD69E8005 for ; Mon, 27 Jun 2011 15:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.197 X-Spam-Level: X-Spam-Status: No, score=-102.197 tagged_above=-999 required=5 tests=[AWL=0.402, 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 V4aOxGMQJNCz for ; Mon, 27 Jun 2011 15:57:22 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 48EEE1F0C56 for ; Mon, 27 Jun 2011 15:57:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 57B582CC39; Tue, 28 Jun 2011 01:57:20 +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 1dhXYH3jtTGx; Tue, 28 Jun 2011 01:57:19 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id B21642CC2F; Tue, 28 Jun 2011 01:57:19 +0300 (EEST) Message-ID: <4E090ACF.3030901@piuha.net> Date: Tue, 28 Jun 2011 00:57:19 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Bob Hinden Subject: Re: AD review of draft-ietf-6man-flow-3697bis References: <4DFF70A4.7040807@piuha.net> <71658E03-69C0-4160-BFF7-2AC6F7F5861C@gmail.com> In-Reply-To: <71658E03-69C0-4160-BFF7-2AC6F7F5861C@gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPv6 Mailing List , draft-ietf-6man-flow-3697bis@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 22:57:23 -0000 Bob, >> In addition, I'm not sure I understand how a router knows that it is a first hop router. Are there cases where a device might mistakenly believe it is a first hop router at a point where the traffic has already been load-balanced to multiple routers? Are there situations where the multiple first hop routers are used from the same host? The document should provide some guidance about operational conditions where the recommendations for the first hop router can be applied. The document should state how such functionality is turned on (per configuration? automatically?) and provide assurances that problematic conditions can be avoided. >> > > I suppose the simple test is if the source address is from a prefix on the incoming interface. > > RFC 4311 "IPv6 Host-to-Router Load Sharing" requires (SHOULD) that hosts send packets for a particular destination to the same router (when it has multiple routers to choose from). I think the flow label draft behavior for setting zero flow labels is compatible with this. > > Does this help answer your questions? > Yes, at least for the part where there several first hop routers. Thank you. Perhaps something like what you said above could be noted in the document, too. Jari From jari.arkko@piuha.net Mon Jun 27 16:40:51 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBFFA11E80C2 for ; Mon, 27 Jun 2011 16:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.297 X-Spam-Level: X-Spam-Status: No, score=-102.297 tagged_above=-999 required=5 tests=[AWL=0.302, 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 LQR9D8NtarbW for ; Mon, 27 Jun 2011 16:40:51 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 5330E11E809B for ; Mon, 27 Jun 2011 16:40:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A71D82CC49 for ; Tue, 28 Jun 2011 02:40:43 +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 fe6UtVSoJQ5U for ; Tue, 28 Jun 2011 02:40:43 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id E1A1B2CC2F for ; Tue, 28 Jun 2011 02:40:41 +0300 (EEST) Message-ID: <4E0914F6.9070709@piuha.net> Date: Tue, 28 Jun 2011 01:40:38 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: AD review of draft-ietf-6man-flow-3697bis References: <4E00A71F.1000201@piuha.net> <3E9CAB5A-0692-4F56-A24D-EFB7E6627D0D@gmail.com> <201106271949.p5RJngpd013577@cichlid.raleigh.ibm.com> <201106272108.p5RL8uet015584@cichlid.raleigh.ibm.com> In-Reply-To: <201106272108.p5RL8uet015584@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 23:40:52 -0000 I still have an uneasy feeling about the changing flow IDs across the same TCP session. It feels wrong. That being said, Ran's argument that different classifications for fragmented/non-fragmented packets already happening for load-balancing reasons (and presumably even for IPv4) when a fragmented packet hits a backbone router and the port numbers are not in the packet. I'm fine with Brian's suggested text. I would personally open the text up a bit more, however. I would explain, for instance, why RFC 4311 is relevant. I would explain the tradeoffs between packet reassembly, different flow IDs, and using just 2-tuples. Jari From internet-drafts@ietf.org Tue Jun 28 04:54:59 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A47111E80EE; Tue, 28 Jun 2011 04:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.501 X-Spam-Level: X-Spam-Status: No, score=-102.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 l1NpqUoj0zGK; Tue, 28 Jun 2011 04:54:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11FE411E8092; Tue, 28 Jun 2011 04:54:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-addr-select-opt-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110628115459.7387.30595.idtracker@ietfa.amsl.com> Date: Tue, 28 Jun 2011 04:54:59 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 11:54:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the= IETF. Title : Distributing Address Selection Policy using DHCPv6 Author(s) : Arifumi Matsumoto Tomohiro Fujisaki Jun-ya Kato Tim Chown Filename : draft-ietf-6man-addr-select-opt-01.txt Pages : 10 Date : 2011-06-28 RFC 3484 defines default address selection mechanisms for IPv6 that allow nodes to select appropriate address when faced with multiple source and/or destination addresses to choose between. The RFC allowed for the future definition of methods to administratively configure the address selection policy information. This document defines a new DHCPv6 option for such configuration, allowing a site administrator to distribute address selection policy, and thus control the address selection behavior of nodes in their site. While RFC 3484 is in the process of being updated, with a revised default policy table, that table may not suit every scenario, and thus the DHCPv6 option defined in this text may be used to override that policy where desired. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-addr-select-opt-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-addr-select-opt-01.txt From narten@us.ibm.com Tue Jun 28 06:06:19 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD8921F86E0 for ; Tue, 28 Jun 2011 06:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 s2OlA+hJpIMS for ; Tue, 28 Jun 2011 06:06:18 -0700 (PDT) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfa.amsl.com (Postfix) with ESMTP id D09AF21F86DE for ; Tue, 28 Jun 2011 06:06:17 -0700 (PDT) Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by e9.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p5SCYrpr031813 for ; Tue, 28 Jun 2011 08:34:53 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p5SD69pE157392 for ; Tue, 28 Jun 2011 09:06:09 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p5S95v83002183 for ; Tue, 28 Jun 2011 06:05:57 -0300 Received: from cichlid.raleigh.ibm.com (sig-9-65-218-180.mts.ibm.com [9.65.218.180]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p5S95uLQ002150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jun 2011 06:05:56 -0300 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p5SD66su006820; Tue, 28 Jun 2011 09:06:06 -0400 Message-Id: <201106281306.p5SD66su006820@cichlid.raleigh.ibm.com> To: Brian E Carpenter Subject: Re: AD review of draft-ietf-6man-flow-3697bis In-reply-to: <4E068630.7010502@gmail.com> References: <4DFF70A4.7040807@piuha.net> <4E068630.7010502@gmail.com> Comments: In-reply-to Brian E Carpenter message dated "Sun, 26 Jun 2011 13:06:56 +1200." Date: Tue, 28 Jun 2011 09:06:06 -0400 From: Thomas Narten Cc: IETF IPv6 Mailing List , draft-ietf-6man-flow-3697bis@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 13:06:19 -0000 Brian E Carpenter writes: > o The deployment of this option MUST be consistent with [RFC4311]. > [BC: This last sentence is to cover Jari's point about a router knowing it's > appropriate for it to set the label.] Could you please explain what the above is intended to do? I don't see right off what the point is. Thomas From narten@us.ibm.com Tue Jun 28 06:54:28 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54BAE21F8605 for ; Tue, 28 Jun 2011 06:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 fVqYGDenkngx for ; Tue, 28 Jun 2011 06:54:26 -0700 (PDT) Received: from e38.co.us.ibm.com (e38.co.us.ibm.com [32.97.110.159]) by ietfa.amsl.com (Postfix) with ESMTP id 84B6821F8606 for ; Tue, 28 Jun 2011 06:54:26 -0700 (PDT) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e38.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p5SDjlfu004337 for ; Tue, 28 Jun 2011 07:45:47 -0600 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p5SDpEb2039716 for ; Tue, 28 Jun 2011 07:53:55 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p5S7D1GP025010 for ; Tue, 28 Jun 2011 01:13:02 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-218-180.mts.ibm.com [9.65.218.180]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p5S7D0Id023851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jun 2011 01:13:00 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p5SDCn2H006854; Tue, 28 Jun 2011 09:12:49 -0400 Message-Id: <201106281312.p5SDCn2H006854@cichlid.raleigh.ibm.com> To: Jari Arkko Subject: Re: AD review of draft-ietf-6man-flow-3697bis In-reply-to: <4E090ACF.3030901@piuha.net> References: <4DFF70A4.7040807@piuha.net> <71658E03-69C0-4160-BFF7-2AC6F7F5861C@gmail.com> <4E090ACF.3030901@piuha.net> Comments: In-reply-to Jari Arkko message dated "Tue, 28 Jun 2011 00:57:19 +0200." Date: Tue, 28 Jun 2011 09:12:49 -0400 From: Thomas Narten Cc: IETF IPv6 Mailing List , Bob Hinden , draft-ietf-6man-flow-3697bis@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 13:54:28 -0000 Jari Arkko writes: > Bob, > >> In addition, I'm not sure I understand how a router knows that it > >> is a first hop router. IMO, this is not necessarily intended to be something routers just know automatically. The point is that routers closer to the source tend to have better knowledge about how to set the Flow Label properly. For example, access routers, which may already be screening the port for invalid MAC src addrs, improper src IP addresses, etc. Routers that do this would be well placed to do Flow Label setting as well. That all said, any router that sees a Flow Label of zero, and wants to change it to something better presumably should/can. When would that NOT be the case? > >> Are there cases where a device might > >> mistakenly believe it is a first hop router at a point where the > >> traffic has already been load-balanced to multiple routers? Are > >> there situations where the multiple first hop routers are used > >> from the same host? Sure. But why should that impact how the Flow Label is rewritten from zero to something else? > >> The document should provide some guidance about operational > >> conditions where the recommendations for the first hop router can > >> be applied. The document should state how such functionality is > >> turned on (per configuration? automatically?) and provide > >> assurances that problematic conditions can be avoided. What problematic conditions do we need to worry about here? Thomas From tjc@ecs.soton.ac.uk Tue Jun 28 07:21:21 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C79D021F86BA for ; Tue, 28 Jun 2011 07:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 M7CTxKd-JuHB for ; Tue, 28 Jun 2011 07:21:20 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 1561C21F86B9 for ; Tue, 28 Jun 2011 07:21:19 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p5SEL6lU011678 for ; Tue, 28 Jun 2011 15:21:06 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p5SEL6lU011678 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1309270866; bh=N4xEiLvt3Kd3Fp1B8Fq/CRYKo6o=; h=Subject:From:Date:To:Mime-Version:References; b=U7flNSZQOTCe/zxOkSCalxN1xe3dGzr3v7zZ96vSWdqiKnw96H0nmW6Zqrj9krbR0 BIGTszTkLq6RO1tz0EeqE0SnKY3BBXgnkP2xmmqx51GsEXTV8/EwcIxbm8W/dUTNCj KYH3N6Ciba9Am7xwwvbJiJdQgWf2gwVs64tLfGLU= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id n5RFL603661006374H ret-id none; Tue, 28 Jun 2011 15:21:06 +0100 Received: from [IPv6:2001:630:d0:f103::c0:ffee] ([IPv6:2001:630:d0:f103::c0:ffee]) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p5SEL3ad004120 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 28 Jun 2011 15:21:03 +0100 Subject: rfc3484-bis issue 1: deprecated prefixes From: Tim Chown Content-Type: text/plain; charset=us-ascii Message-ID: Date: Tue, 28 Jun 2011 15:21:03 +0100 To: ipv6@ietf.org Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=n5RFL6036610063700; tid=n5RFL603661006374H; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 References: <13EEB723-2B22-4782-B6F0-95BCDEF13A33@ecs.soton.ac.uk> X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: p5SEL6lU011678 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 14:21:21 -0000 Hi, The authors of rfc3484-bis would like to solicit feedback on three open = issues, to help shape a (hopefully) final update before the cut-off on = 11th July. The first issue is which deprecated prefixes to include in the new = default policy table. As of -03, the 3ffe::/16 prefix has been removed. = Should the site-local and IPv4-compatible prefixes also be removed from = the table? We also note that there is discussion about the future of 6to4, and thus = of the 2002::/16 prefix. Since draft-ietf-v6ops-6to4-advisory-02 cites = 3484-bis as a tool to mitigate against the bad effects of 6to4, it seems = prudent to leave the 6to4 prefix in the table to allow for existing 6to4 = implementations. Sites wishing to prefer 6to4 to IPv4 can adjust their = policy table manually or using the proposed DHCPv6 option. Comments please. Tim=20= From tjc@ecs.soton.ac.uk Tue Jun 28 07:41:30 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B9B11E812E for ; Tue, 28 Jun 2011 07:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 KLjRlzn392nx for ; Tue, 28 Jun 2011 07:41:29 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id CFD2B11E80D4 for ; Tue, 28 Jun 2011 07:41:18 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p5SEf7ce016365 for ; Tue, 28 Jun 2011 15:41:07 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p5SEf7ce016365 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1309272067; bh=YOtbY0J/397zHZTPDiUMnxFImEw=; h=Subject:From:Date:To:Mime-Version:References; b=WrTynvsSGAHgmARz34VpX1z1Y7D9Xd6L9azSZlhe197ygZ755iqkTLcvYEIClnfys mBo17B+K8dCbmHiSIcViriE8LGYIHoasNXeJ8+DtKdRadohCdbJadqm/2Fw18IR7br q7CnXfZ/tjM87/NabHFs/BQ3FdqmsK6rKQIxeKqE= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id n5RFf70366100792la ret-id none; Tue, 28 Jun 2011 15:41:07 +0100 Received: from [IPv6:2001:630:d0:f103::c0:ffee] ([IPv6:2001:630:d0:f103::c0:ffee]) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p5SEf1Tk008706 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 28 Jun 2011 15:41:01 +0100 Subject: rfc3484-bis issue 3: prefer greatest prefix lifetime? From: Tim Chown Content-Type: text/plain; charset=us-ascii Message-ID: Date: Tue, 28 Jun 2011 15:41:01 +0100 To: ipv6@ietf.org Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=n5RFf7036610079200; tid=n5RFf70366100792la; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 References: X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: p5SEf7ce016365 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 14:41:30 -0000 The third issue is I think one that Mark Smith raised, and there was = some discussion without a conclusion. Do we add a rule between 3 and 4 saying 'Prefer greatest preferred = lifetime', i.e. If the addresses SA and SB both have non-zero value = preferred lifetimes (are "non-deprecated"), prefer the address with the = greatest value preferred lifetime? There are some cases where this might be expected behaviour, but there = have been views expressed both ways. Comments please. Tim= From tjc@ecs.soton.ac.uk Tue Jun 28 07:47:49 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1466311E80DA for ; Tue, 28 Jun 2011 07:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, 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 tn+w0DHyaa49 for ; Tue, 28 Jun 2011 07:47:48 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 19FD711E80C3 for ; Tue, 28 Jun 2011 07:39:02 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p5SEcnQB015818 for ; Tue, 28 Jun 2011 15:38:49 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p5SEcnQB015818 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1309271929; bh=uAWrPCX/UbPDl7/IPHi9Bcu0DVc=; h=Subject:From:Date:To:Mime-Version:References; b=T6UczH2Dje3whBH21jG3wWwuoa39hmF+FZ+xPqtSEHkGtrmNSXKYd81su2GpiHBSB sBmMSYxcUUZvY5l5mbokYImeh8Hv/hSrNRa+8beGFElJ84sIvxYoB8CSTjY1BNY1Iy RgruGpexoVJyTKrY+nkJrD3FEYvon8L547O/0jJQ= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id n5RFcn0366100770Sl ret-id none; Tue, 28 Jun 2011 15:38:49 +0100 Received: from [IPv6:2001:630:d0:f103::c0:ffee] ([IPv6:2001:630:d0:f103::c0:ffee]) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p5SEcjne008380 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 28 Jun 2011 15:38:45 +0100 Subject: rfc3484-bis issue 2: privacy addresses From: Tim Chown Content-Type: multipart/alternative; boundary=Apple-Mail-8-252243139 Message-ID: Date: Tue, 28 Jun 2011 15:38:44 +0100 To: ipv6@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=n5RFcn036610077000; tid=n5RFcn0366100770Sl; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 References: <5440EBA2-DDA9-46B9-B417-68148C6382CD@ecs.soton.ac.uk> X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: p5SEcnQB015818 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 14:47:49 -0000 --Apple-Mail-8-252243139 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The second issue is surrounding IPv6 privacy addresses (RFC4941). Section 3.1 of RFC4941 states: "this document assumes that when a node initiates outgoing communication, temporary addresses can be given preference over public addresses when the device is configured to do so. [ADDR_SELECT] mandates implementations to provide a mechanism, which allows an application to configure its preference for temporary addresses over public addresses. It also allows for an implementation to prefer temporary addresses by default, so that the connections initiated by the node can use temporary addresses without requiring application-specific enablement." This suggests there should be a mechanism for a host to choose whether = to use temporary or public addresses. RFC3484 talks about preferring = temporary or public addresses in Rule 7. In practice, implementations = seem to prefer privacy addresses (to initiate connections) when they are = enabled. At the moment, RFC3484-bis says nothing different or new for = privacy addresses. Should there be a configuration switch for privacy extensions somewhere, = and if so how is this controlled - locally or via a policy distribution = mechanism? =20 In IETF80, the suggestion to 'tell' a host whether it should use privacy = addresses by using an RA flag was not well received. There was at least = one comment at IETF80 that the privilege to carry the traffic and the = privilege to turn on/off the privacy extension should be different. Comments please. Tim --Apple-Mail-8-252243139 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The = second issue is surrounding IPv6 privacy addresses = (RFC4941).

Section 3.1 of RFC4941 = states:
  "this document assumes that when a node = initiates outgoing
   communication, =
temporary addresses can be given preference over
   public addresses when the device is configured to do so.
   [ADDR_SELECT] mandates implementations to provide a =
mechanism, which
   allows an application to configure its preference for temporary
   addresses over public addresses.  It also allows for an
   implementation to prefer temporary addresses by default, so that the
   connections initiated by the node can use temporary addresses without
   requiring application-specific enablement."

This suggests =
there should be a mechanism for a host to choose whether to use =
temporary or public addresses.  RFC3484 talks about preferring temporary =
or public addresses in Rule 7.  In practice, implementations seem to =
prefer privacy addresses (to initiate connections) when they are =
enabled.  At the moment, RFC3484-bis says nothing different or new for =
privacy addresses.

Should there be a =
configuration switch for privacy extensions somewhere, and if so how is =
this controlled - locally or via a policy distribution mechanism?  =


In IETF80, the =
suggestion to 'tell' a host whether it should use privacy addresses by =
using an RA flag was not well received. There was at =
least one comment at IETF80 that the privilege to carry the traffic and the =
privilege to turn on/off the privacy extension should be =
different.
Comments =
please.

Tim

= --Apple-Mail-8-252243139-- From brian@innovationslab.net Tue Jun 28 10:14:11 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15375228015 for ; Tue, 28 Jun 2011 10:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 zvyeXgoP9KgJ for ; Tue, 28 Jun 2011 10:14:10 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7F93B22800E for ; Tue, 28 Jun 2011 10:14:10 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id EA2C4881AC for ; Tue, 28 Jun 2011 10:14:09 -0700 (PDT) Received: from tigers.local (unknown [75.94.92.25]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 593A01369594 for ; Tue, 28 Jun 2011 10:14:09 -0700 (PDT) Message-ID: <4E0A0BD9.6040202@innovationslab.net> Date: Tue, 28 Jun 2011 13:14:01 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: IPv6 WG Mailing List Subject: Fwd: Please help the Nomcom X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 17:14:11 -0000 All, The NomCom Chair needs more volunteers... Regards, Brian -------- Original Message -------- Subject: Please help the Nomcom Date: Fri, 24 Jun 2011 11:35:13 -0700 (PDT) From: NomCom Chair To: Working Group Chairs Hi WG chairs, We have had a good response to the first call for volunteers but the rate at which new volunteers are coming in is slowing down. The Nomcom process is best served by a large pool of volunteers drawn from a wide spectrum of IETF attendees. Where else would we find this wide spectrum if not in the WG mailing lists. I would really appreciate it if you can forward the message onto your working group mailing lists. The latest volunteer status and the second call for volunteers can be found at https://datatracker.ietf.org/ann/nomcom/2964/ Thanks in advance for your help. Suresh Krishnan Nomcom Chair 2011-2012 Email: nomcom-chair@ietf.org, suresh.krishnan@ericsson.com From suresh.krishnan@ericsson.com Tue Jun 28 12:37:27 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADD4811E8100 for ; Tue, 28 Jun 2011 12:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.398 X-Spam-Level: X-Spam-Status: No, score=-106.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 jZYe4O7iA8qG for ; Tue, 28 Jun 2011 12:37:27 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 2840211E807B for ; Tue, 28 Jun 2011 12:37:27 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p5SJYaYE001094; Tue, 28 Jun 2011 14:34:39 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.253]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 28 Jun 2011 15:34:32 -0400 From: Suresh Krishnan To: Tim Chown , "ipv6@ietf.org" Date: Tue, 28 Jun 2011 15:32:49 -0400 Subject: RE: rfc3484-bis issue 2: privacy addresses Thread-Topic: rfc3484-bis issue 2: privacy addresses Thread-Index: Acw1onYDS/5cgCfNRoulw/qRiUcoUAAJ7RU8 Message-ID: <4FD1E7CD248BF84F86BD4814EDDDBCC1513D42BE0C@EUSAACMS0703.eamcs.ericsson.se> References: <5440EBA2-DDA9-46B9-B417-68148C6382CD@ecs.soton.ac.uk>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 19:37:27 -0000 Hi Tim, There is already a programmatic switch for this in RFC5014 (IPV6_PREFER_S= RC_TMP/IPV6_PREFER_SRC_PUBLIC). Applications wishing to override system pol= icy may do so by using this API. Cheers Suresh ________________________________________ From: ipv6-bounces@ietf.org [ipv6-bounces@ietf.org] On Behalf Of Tim Chown = [tjc@ecs.soton.ac.uk] Sent: Tuesday, June 28, 2011 10:38 AM To: ipv6@ietf.org Subject: rfc3484-bis issue 2: privacy addresses The second issue is surrounding IPv6 privacy addresses (RFC4941). Section 3.1 of RFC4941 states: "this document assumes that when a node initiates outgoing communication, temporary addresses can be given preference over public addresses when the device is configured to do so. [ADDR_SELECT] mandat= es implementations to provide a mechanism, which allows an application to configure its preference for temporary addresses over public addresses. It also allows for an implementation to prefer temporary addresses by default, so that the connections initiated by the node can use temporary addresses without requiring application-specific enablement." This suggests there should be a mechanism for a host to choose whether to u= se temporary or public addresses. RFC3484 talks about preferring temporary= or public addresses in Rule 7. In practice, implementations seem to prefe= r privacy addresses (to initiate connections) when they are enabled. At th= e moment, RFC3484-bis says nothing different or new for privacy addresses. Should there be a configuration switch for privacy extensions somewhere, an= d if so how is this controlled - locally or via a policy distribution mecha= nism? In IETF80, the suggestion to 'tell' a host whether it should use privacy ad= dresses by using an RA flag was not well received. There was at least one c= omment at IETF80 that the privilege to carry the traffic and the privilege = to turn on/off the privacy extension should be different. Comments please. Tim From brian.e.carpenter@gmail.com Tue Jun 28 13:13:12 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C47911E80F3 for ; Tue, 28 Jun 2011 13:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 UEAfz0IUIDz7 for ; Tue, 28 Jun 2011 13:13:11 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6A88411E80CA for ; Tue, 28 Jun 2011 13:13:11 -0700 (PDT) Received: by iye7 with SMTP id 7so601536iye.31 for ; Tue, 28 Jun 2011 13:13:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=O2fcy4P4y8VnHmfjU0psrxf8xqhrFtz9NFR7+6AE6F4=; b=VbdwzZ0d7TslAfyvY6GSu/VcBndIyGDxVI9u4JIpkoZ9ACgA3orMbxYx47pp+YRrYt jBGqW0WyV9XRPlCekREDBAC/2OwM4T94pC5kLC1IDSNXLklXTGajdg76XNwW4DEjYcb/ ySR/sdVktlSvIGpZASlopi4HQAsL4ydO199dU= Received: by 10.42.158.65 with SMTP id g1mr9317110icx.245.1309291990450; Tue, 28 Jun 2011 13:13:10 -0700 (PDT) Received: from [10.255.25.75] (74-95-74-1-Indianapolis.hfc.comcastbusiness.net [74.95.74.1]) by mx.google.com with ESMTPS id fw9sm232097ibb.30.2011.06.28.13.13.08 (version=SSLv3 cipher=OTHER); Tue, 28 Jun 2011 13:13:09 -0700 (PDT) Message-ID: <4E0A35CD.2010803@gmail.com> Date: Wed, 29 Jun 2011 08:13:01 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Thomas Narten Subject: Re: AD review of draft-ietf-6man-flow-3697bis References: <4DFF70A4.7040807@piuha.net> <4E068630.7010502@gmail.com> <201106281306.p5SD66su006820@cichlid.raleigh.ibm.com> In-Reply-To: <201106281306.p5SD66su006820@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF IPv6 Mailing List , draft-ietf-6man-flow-3697bis@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 20:13:12 -0000 On 2011-06-29 01:06, Thomas Narten wrote: > Brian E Carpenter writes: > >> o The deployment of this option MUST be consistent with [RFC4311]. > >> [BC: This last sentence is to cover Jari's point about a router knowing it's >> appropriate for it to set the label.] > > Could you please explain what the above is intended to do? I don't see > right off what the point is. Jari's question was how a router knows whether it should or shouldn't set the flow label. That is hard to answer succinctly because it depends on local configuration, but I agree that more explanation is needed, beyond consistency with 4311. I'll try to come up with something. Brian From brian.e.carpenter@gmail.com Tue Jun 28 13:18:28 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E3011E8106 for ; Tue, 28 Jun 2011 13:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 4yiCWm+Axw2I for ; Tue, 28 Jun 2011 13:18:27 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id A2B6A11E808C for ; Tue, 28 Jun 2011 13:18:27 -0700 (PDT) Received: by yxp4 with SMTP id 4so322733yxp.31 for ; Tue, 28 Jun 2011 13:18:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=UcX9L6aZukf4OIidRM+sif0XSN43OoiIXc9J6is5uDU=; b=bB2GcGRcvQe0MMYrtia3eVhtnGHR+BS6Ihi09U07ooh1MaWAwxLmIB68JXKbGACpZy WRK9P5IE4sqkhoYl0OX14+s4oNRPJEYM4XJt/q8OTF7kBAuTS6xo6LuEU+hzCjHTEdmK nGIz+b8lN1Lmy4GNuqgXCUyBzVXBn2C6vIpRQ= Received: by 10.151.11.9 with SMTP id o9mr24683ybi.360.1309292307083; Tue, 28 Jun 2011 13:18:27 -0700 (PDT) Received: from [10.255.25.75] (74-95-74-1-Indianapolis.hfc.comcastbusiness.net [74.95.74.1]) by mx.google.com with ESMTPS id j70sm365068yhk.56.2011.06.28.13.18.25 (version=SSLv3 cipher=OTHER); Tue, 28 Jun 2011 13:18:25 -0700 (PDT) Message-ID: <4E0A370E.5090108@gmail.com> Date: Wed, 29 Jun 2011 08:18:22 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Thomas Narten Subject: Re: AD review of draft-ietf-6man-flow-3697bis References: <4DFF70A4.7040807@piuha.net> <71658E03-69C0-4160-BFF7-2AC6F7F5861C@gmail.com> <4E090ACF.3030901@piuha.net> <201106281312.p5SDCn2H006854@cichlid.raleigh.ibm.com> In-Reply-To: <201106281312.p5SDCn2H006854@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Bob Hinden , draft-ietf-6man-flow-3697bis@tools.ietf.org, IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 20:18:28 -0000 On 2011-06-29 01:12, Thomas Narten wrote: > Jari Arkko writes: > >> Bob, > >>>> In addition, I'm not sure I understand how a router knows that it >>>> is a first hop router. > > IMO, this is not necessarily intended to be something routers just > know automatically. The point is that routers closer to the source > tend to have better knowledge about how to set the Flow Label > properly. For example, access routers, which may already be screening > the port for invalid MAC src addrs, improper src IP addresses, > etc. Routers that do this would be well placed to do Flow Label > setting as well. > > That all said, any router that sees a Flow Label of zero, and wants to > change it to something better presumably should/can. When would that > NOT be the case? If the network manager of the site decides not to do it there? I think it needs to be configurable. > >>>> Are there cases where a device might >>>> mistakenly believe it is a first hop router at a point where the >>>> traffic has already been load-balanced to multiple routers? Are >>>> there situations where the multiple first hop routers are used >>>> from the same host? > > Sure. But why should that impact how the Flow Label is rewritten from > zero to something else? Because different routers might pick different labels for packets that belong to the same flow. Brian > >>>> The document should provide some guidance about operational >>>> conditions where the recommendations for the first hop router can >>>> be applied. The document should state how such functionality is >>>> turned on (per configuration? automatically?) and provide >>>> assurances that problematic conditions can be avoided. > > What problematic conditions do we need to worry about here? From brian.e.carpenter@gmail.com Tue Jun 28 13:20:26 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6486121F852C for ; Tue, 28 Jun 2011 13:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 qDAj6bhWh2-8 for ; Tue, 28 Jun 2011 13:20:25 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA1521F84F1 for ; Tue, 28 Jun 2011 13:20:09 -0700 (PDT) Received: by yxp4 with SMTP id 4so323526yxp.31 for ; Tue, 28 Jun 2011 13:20:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=1ZDJ63M+W9ymOJAYoskZCbEjNMmoPlY9kZ9TmTIXFtQ=; b=dSpDE4tTtd7EHXoHbleqtHFLOYR9d5IKp8OZ6gBLRTWoX1d1DmaoSBF3mngB3Ulsky kY17je3+clUebRIgObKqlufmMSsMIJfPGGEKDuzxqE0PM4uDUIbAm1UJx5SDkoTWjYSI kZnVpvwGk2C9pphwPT1nMT1syYJ/IA9YejRwA= Received: by 10.236.173.199 with SMTP id v47mr4467244yhl.483.1309292408930; Tue, 28 Jun 2011 13:20:08 -0700 (PDT) Received: from [10.255.25.75] (74-95-74-1-Indianapolis.hfc.comcastbusiness.net [74.95.74.1]) by mx.google.com with ESMTPS id i30sm366934yhm.49.2011.06.28.13.20.07 (version=SSLv3 cipher=OTHER); Tue, 28 Jun 2011 13:20:08 -0700 (PDT) Message-ID: <4E0A3775.3080604@gmail.com> Date: Wed, 29 Jun 2011 08:20:05 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jari Arkko Subject: Re: AD review of draft-ietf-6man-flow-3697bis References: <4E00A71F.1000201@piuha.net> <3E9CAB5A-0692-4F56-A24D-EFB7E6627D0D@gmail.com> <201106271949.p5RJngpd013577@cichlid.raleigh.ibm.com> <201106272108.p5RL8uet015584@cichlid.raleigh.ibm.com> <4E0914F6.9070709@piuha.net> In-Reply-To: <4E0914F6.9070709@piuha.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 20:20:26 -0000 On 2011-06-28 11:40, Jari Arkko wrote: > I still have an uneasy feeling about the changing flow IDs across the > same TCP session. It feels wrong. > > That being said, Ran's argument that different classifications for > fragmented/non-fragmented packets already happening for load-balancing > reasons (and presumably even for IPv4) when a fragmented packet hits a > backbone router and the port numbers are not in the packet. > > I'm fine with Brian's suggested text. I would personally open the text > up a bit more, however. I would explain, for instance, why RFC 4311 is > relevant. I would explain the tradeoffs between packet reassembly, > different flow IDs, and using just 2-tuples. OK, I have to provide more words, clearly... it may take another day or two. Brian From narten@us.ibm.com Tue Jun 28 13:23:48 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF52311E8173 for ; Tue, 28 Jun 2011 13:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 Pe68pYEq7HRa for ; Tue, 28 Jun 2011 13:23:48 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by ietfa.amsl.com (Postfix) with ESMTP id 60BDE11E8172 for ; Tue, 28 Jun 2011 13:23:48 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e35.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p5SK5R4E008033 for ; Tue, 28 Jun 2011 14:05:27 -0600 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id p5SKNhE2171486 for ; Tue, 28 Jun 2011 14:23:43 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p5SENFls011739 for ; Tue, 28 Jun 2011 08:23:15 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-218-180.mts.ibm.com [9.65.218.180]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p5SENEbL011636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jun 2011 08:23:15 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p5SKNZdR012027; Tue, 28 Jun 2011 16:23:40 -0400 Message-Id: <201106282023.p5SKNZdR012027@cichlid.raleigh.ibm.com> To: Brian E Carpenter Subject: Re: AD review of draft-ietf-6man-flow-3697bis In-reply-to: <4E0A370E.5090108@gmail.com> References: <4DFF70A4.7040807@piuha.net> <71658E03-69C0-4160-BFF7-2AC6F7F5861C@gmail.com> <4E090ACF.3030901@piuha.net> <201106281312.p5SDCn2H006854@cichlid.raleigh.ibm.com> <4E0A370E.5090108@gmail.com> Comments: In-reply-to Brian E Carpenter message dated "Wed, 29 Jun 2011 08:18:22 +1200." Date: Tue, 28 Jun 2011 16:23:35 -0400 From: Thomas Narten Cc: Bob Hinden , draft-ietf-6man-flow-3697bis@tools.ietf.org, IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 20:23:48 -0000 > > That all said, any router that sees a Flow Label of zero, and wants to > > change it to something better presumably should/can. When would that > > NOT be the case? > If the network manager of the site decides not to do it there? I think > it needs to be configurable. Absolutely, and by default should probably be off. > >>>> Are there cases where a device might > >>>> mistakenly believe it is a first hop router at a point where the > >>>> traffic has already been load-balanced to multiple routers? Are > >>>> there situations where the multiple first hop routers are used > >>>> from the same host? > > > > Sure. But why should that impact how the Flow Label is rewritten from > > zero to something else? > Because different routers might pick different labels for packets > that belong to the same flow. But, this implies packets from the same flow are being sent through different routers. If that is happening, something is broken, and this document can't (and shouldn't) fix it ... And it won't happen at the first hop. I.e., ND addresses this as does RFC 4311. All packets from the same flow go through the same router at the first hop. Load balancing at the ND level means different flows can go through different default routers. Thomas From brian.e.carpenter@gmail.com Tue Jun 28 14:45:01 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E98921F8432 for ; Tue, 28 Jun 2011 14:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 pB3Nt-zYq-ai for ; Tue, 28 Jun 2011 14:45:00 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id AAC8911E811C for ; Tue, 28 Jun 2011 14:45:00 -0700 (PDT) Received: by iye7 with SMTP id 7so680475iye.31 for ; Tue, 28 Jun 2011 14:45:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Zt7edI8OA/yQJC14cQ+evIvEsBTbIG9u704wdJznObk=; b=QESjL9AQGMXO+YrIqelgCqBZD+3r0CDgLjaTXbU5Wu4IqRZJ7Q2Uw6/8jSO3XJQ/IG Or/FEP2vCDr68hu/YqZD6uTcRkGxt2wZ5of9zIdqiIgos3+M9tImFeiEnYwJl1b0biPJ JFNERIgZvpKg2TSTBhksf0wz/tb/kg33m7TOY= Received: by 10.42.144.195 with SMTP id c3mr80146icv.9.1309297500111; Tue, 28 Jun 2011 14:45:00 -0700 (PDT) Received: from [10.255.25.75] (74-95-74-1-Indianapolis.hfc.comcastbusiness.net [74.95.74.1]) by mx.google.com with ESMTPS id q15sm261528ibb.65.2011.06.28.14.44.58 (version=SSLv3 cipher=OTHER); Tue, 28 Jun 2011 14:44:59 -0700 (PDT) Message-ID: <4E0A4B58.70007@gmail.com> Date: Wed, 29 Jun 2011 09:44:56 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Thomas Narten Subject: Re: AD review of draft-ietf-6man-flow-3697bis References: <4DFF70A4.7040807@piuha.net> <71658E03-69C0-4160-BFF7-2AC6F7F5861C@gmail.com> <4E090ACF.3030901@piuha.net> <201106281312.p5SDCn2H006854@cichlid.raleigh.ibm.com> <4E0A370E.5090108@gmail.com> <201106282023.p5SKNZdR012027@cichlid.raleigh.ibm.com> In-Reply-To: <201106282023.p5SKNZdR012027@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Bob Hinden , draft-ietf-6man-flow-3697bis@tools.ietf.org, IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 21:45:01 -0000 By way of introduction, I have a preference for standards text to be as short as possible, because the more we say, the more likely we are to be wrong (especially when speculating about future router design). So here is my next proposal for the text about routers setting the flow label. As always, comments welcome (suggested text especially welcome...): A node that forwards a flow whose flow label value in arriving packets is zero MAY change the flow label value. In that case, it is RECOMMENDED that the forwarding node sets the flow label field for a flow to a uniformly distributed value as just described for source nodes. o The same considerations apply as to source hosts setting the flow label; in particular, the preferred case is that a flow is defined by the 5-tuple. However, there are cases in which the complete 5-tuple for all packets is not readily available to a forwarding node, in particular for fragmented packets. In such cases a flow can be defined by fewer IPv6 header fields, typically using only the 2-tuple {dest addr, source addr}. There are alternative approaches that implementers could choose, such as: * A forwarding node might use the 5-tuple to define a flow whenever possible, but use the 2-tuple when the complete 5-tuple is not available. In this case, unfragmented and fragmented packets belonging to the same transport session would receive different flow label values, altering the effect of subsequent load distribution based on the flow label. * A forwarding node might use the 2-tuple to define a flow in all cases. In this case, subsequent load distribution would be based only on IP addresses. o This option, if implemented, would presumably be of value in first-hop or ingress routers. It might place a considerable per- packet processing load on them, even if they adopted a stateless method of flow identification and label assignment. Also, it should not interfere with host-to-router load sharing [RFC4311]. Therefore, it needs to be under the control of network managers, to avoid unwanted processing load and any other undesirable effects. For this reason it MUST be a configurable option, disabled by default. The preceding rules taken together allow a given network to include routers that set flow labels on behalf of hosts that do not do so. The complications described explain why the principal recommendation is that the source hosts should set the label. From jari.arkko@piuha.net Tue Jun 28 14:51:27 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEFF11E8179 for ; Tue, 28 Jun 2011 14:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.358 X-Spam-Level: X-Spam-Status: No, score=-102.358 tagged_above=-999 required=5 tests=[AWL=0.241, 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 bFxkgy4GLq1t for ; Tue, 28 Jun 2011 14:51:26 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id A180D11E816A for ; Tue, 28 Jun 2011 14:51:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 83A182CC49; Wed, 29 Jun 2011 00:51:24 +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 2dud9G8LqCGZ; Wed, 29 Jun 2011 00:51:24 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 476CE2CC39; Wed, 29 Jun 2011 00:51:22 +0300 (EEST) Message-ID: <4E0A4CD9.7090600@piuha.net> Date: Tue, 28 Jun 2011 23:51:21 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: AD review of draft-ietf-6man-flow-3697bis References: <4DFF70A4.7040807@piuha.net> <71658E03-69C0-4160-BFF7-2AC6F7F5861C@gmail.com> <4E090ACF.3030901@piuha.net> <201106281312.p5SDCn2H006854@cichlid.raleigh.ibm.com> <4E0A370E.5090108@gmail.com> <201106282023.p5SKNZdR012027@cichlid.raleigh.ibm.com> <4E0A4B58.70007@gmail.com> In-Reply-To: <4E0A4B58.70007@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Thomas Narten , IETF IPv6 Mailing List , Bob Hinden , draft-ietf-6man-flow-3697bis@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 21:51:27 -0000 I'm fine with this text. Jari From arifumi@nttv6.net Tue Jun 28 22:31:55 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 466279E8019 for ; Tue, 28 Jun 2011 22:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 eI8Y7IHvS6C3 for ; Tue, 28 Jun 2011 22:31:54 -0700 (PDT) Received: from leo.nttv6.net (leo.nttv6.net [192.47.162.93]) by ietfa.amsl.com (Postfix) with ESMTP id 72DEF9E8018 for ; Tue, 28 Jun 2011 22:31:54 -0700 (PDT) Received: from radiko.smartstream.ne.jp (localhost.nttv6.net [127.0.0.1]) by leo.nttv6.net (8.14.4/8.14.4) with ESMTP id p5T5RRaP027803; Wed, 29 Jun 2011 14:27:27 +0900 (JST) (envelope-from arifumi@nttv6.net) Subject: Re: rfc3484-bis issue 2: privacy addresses Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Arifumi Matsumoto In-Reply-To: <4FD1E7CD248BF84F86BD4814EDDDBCC1513D42BE0C@EUSAACMS0703.eamcs.ericsson.se> Date: Wed, 29 Jun 2011 14:28:18 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <971D6F0B-9109-42EC-ABE0-1A5E3AB99741@nttv6.net> References: <5440EBA2-DDA9-46B9-B417-68148C6382CD@ecs.soton.ac.uk>, <4FD1E7CD248BF84F86BD4814EDDDBCC1513D42BE0C@EUSAACMS0703.eamcs.ericsson.se> To: Suresh Krishnan X-Mailer: Apple Mail (2.1084) Cc: Tim Chown , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 05:31:55 -0000 Hi Suresh, On 2011/06/29, at 4:32, Suresh Krishnan wrote: > Hi Tim, > There is already a programmatic switch for this in RFC5014 = (IPV6_PREFER_SRC_TMP/IPV6_PREFER_SRC_PUBLIC). Applications wishing to = override system policy may do so by using this API. Yes. An application can control which kind of address to choose by that = API. Our question is whether we should have a way to configure host-wide = policy about when to use temporary address or not. For example, if we extend the policy table to have Privacy column like = below, Prefix Precedence Label Privacy ::1/128 60 0 OFF fc00::/7 50 1 OFF ::/0 40 2 ON ::ffff:0:0/96 30 3 OFF 2002::/16 20 4 OFF 2001::/32 10 5 OFF ::/96 1 10 OFF fec0::/10 1 11 OFF a temporary address will be used only when a destination address longest = matches ::/0 entry in this table. Please note that this is about address selection and not about whether a = host should generate temporary address for a received RA prefix. As Tim mentioned, if we agree to have this kind of new tool, after that, = we should discuss about policy distribution of this added column. Best regards, >=20 > Cheers > Suresh >=20 > ________________________________________ > From: ipv6-bounces@ietf.org [ipv6-bounces@ietf.org] On Behalf Of Tim = Chown [tjc@ecs.soton.ac.uk] > Sent: Tuesday, June 28, 2011 10:38 AM > To: ipv6@ietf.org > Subject: rfc3484-bis issue 2: privacy addresses >=20 > The second issue is surrounding IPv6 privacy addresses (RFC4941). >=20 > Section 3.1 of RFC4941 states: > "this document assumes that when a node initiates outgoing >=20 > communication, temporary addresses can be given preference over > public addresses when the device is configured to do so. > [ADDR_SELECT] = mandates implementations to provide a mechanism, which > allows an application to configure its preference for temporary > addresses over public addresses. It also allows for an > implementation to prefer temporary addresses by default, so that the > connections initiated by the node can use temporary addresses = without > requiring application-specific enablement." >=20 >=20 > This suggests there should be a mechanism for a host to choose whether = to use temporary or public addresses. RFC3484 talks about preferring = temporary or public addresses in Rule 7. In practice, implementations = seem to prefer privacy addresses (to initiate connections) when they are = enabled. At the moment, RFC3484-bis says nothing different or new for = privacy addresses. >=20 >=20 > Should there be a configuration switch for privacy extensions = somewhere, and if so how is this controlled - locally or via a policy = distribution mechanism? >=20 >=20 > In IETF80, the suggestion to 'tell' a host whether it should use = privacy addresses by using an RA flag was not well received. There was = at least one comment at IETF80 that the privilege to carry the traffic = and the privilege to turn on/off the privacy extension should be = different. >=20 >=20 > Comments please. >=20 >=20 > Tim >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Arifumi Matsumoto NGN System Architecture Project NTT Service Integration Laboratories E-mail: arifumi@nttv6.net TEL +81-422-59-3334 FAX +81-422-59-6364 From bob.hinden@gmail.com Wed Jun 29 09:17:15 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E959E805A for ; Wed, 29 Jun 2011 09:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 7kRA2mrzkJt0 for ; Wed, 29 Jun 2011 09:17:14 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4F64C9E8053 for ; Wed, 29 Jun 2011 09:17:14 -0700 (PDT) Received: by wyj26 with SMTP id 26so1116716wyj.31 for ; Wed, 29 Jun 2011 09:17:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=/pIzczrUFSryUi3VnIE0YQg8SnNVOnCHfblKx/7nYf0=; b=bS3aXAShDff+1f0aTCzfBYMw2V35lGHarFxl9v7DkjeGugoGlkD9RSXAWSZrDJAujN 6smdxguinvili+jhJl4ROLHE4uU5IludARgWfc+zsdj/AjXYMIOeU/AbOrSO7vvenF+K f59IiR2i6yQkN5gCKVc173w2doqavOb2mT0vs= Received: by 10.216.1.200 with SMTP id 50mr2009348wed.33.1309364223737; Wed, 29 Jun 2011 09:17:03 -0700 (PDT) Received: from [10.0.0.37] (c-24-130-225-13.hsd1.ca.comcast.net [24.130.225.13]) by mx.google.com with ESMTPS id ej7sm1013844wbb.36.2011.06.29.09.17.00 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Jun 2011 09:17:02 -0700 (PDT) Subject: Re: AD review of draft-ietf-6man-flow-3697bis Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: <4E0A4CD9.7090600@piuha.net> Date: Wed, 29 Jun 2011 09:16:57 -0700 Content-Transfer-Encoding: 7bit Message-Id: <81AF3FF2-72E2-41EF-AF4C-DEC3C8E7CD56@gmail.com> References: <4DFF70A4.7040807@piuha.net> <71658E03-69C0-4160-BFF7-2AC6F7F5861C@gmail.com> <4E090ACF.3030901@piuha.net> <201106281312.p5SDCn2H006854@cichlid.raleigh.ibm.com> <4E0A370E.5090108@gmail.com> <201106282023.p5SKNZdR012027@cichlid.raleigh.ibm.com> <4E0A4B58.70007@gmail.com> <4E0A4CD9.7090600@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1084) Cc: Thomas Narten , IETF IPv6 Mailing List , Bob Hinden , Brian E Carpenter , draft-ietf-6man-flow-3697bis@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 16:17:16 -0000 On Jun 28, 2011, at 2:51 PM, Jari Arkko wrote: > I'm fine with this text. > As am I. Bob From narten@us.ibm.com Wed Jun 29 09:42:48 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B98521F865A for ; Wed, 29 Jun 2011 09:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 i3qqE83rHIbJ for ; Wed, 29 Jun 2011 09:42:47 -0700 (PDT) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA0C21F8655 for ; Wed, 29 Jun 2011 09:42:46 -0700 (PDT) Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by e9.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p5TGBQh5026372 for ; Wed, 29 Jun 2011 12:11:26 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p5TGgife1433818 for ; Wed, 29 Jun 2011 12:42:44 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p5TGgh5b025209 for ; Wed, 29 Jun 2011 12:42:44 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-76-145-19.mts.ibm.com [9.76.145.19]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p5TGggca025162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jun 2011 12:42:43 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p5TGgfRw009875; Wed, 29 Jun 2011 12:42:42 -0400 Message-Id: <201106291642.p5TGgfRw009875@cichlid.raleigh.ibm.com> To: Brian E Carpenter Subject: Re: AD review of draft-ietf-6man-flow-3697bis In-reply-to: <4E0A4B58.70007@gmail.com> References: <4DFF70A4.7040807@piuha.net> <71658E03-69C0-4160-BFF7-2AC6F7F5861C@gmail.com> <4E090ACF.3030901@piuha.net> <201106281312.p5SDCn2H006854@cichlid.raleigh.ibm.com> <4E0A370E.5090108@gmail.com> <201106282023.p5SKNZdR012027@cichlid.raleigh.ibm.com> <4E0A4B58.70007@gmail.com> Comments: In-reply-to Brian E Carpenter message dated "Wed, 29 Jun 2011 09:44:56 +1200." Date: Wed, 29 Jun 2011 12:42:41 -0400 From: Thomas Narten Cc: draft-ietf-6man-flow-3697bis@tools.ietf.org, Bob Hinden , IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 16:42:48 -0000 I'm generally OK with this text. Brian E Carpenter writes: > o This option, if implemented, would presumably be of value in > first-hop or ingress routers. It might place a considerable per- > packet processing load on them, even if they adopted a stateless > method of flow identification and label assignment. Also, it > should not interfere with host-to-router load sharing [RFC4311]. This sentence is ambiguous. is the "should not" a statement of fact, or is it a directive, i.e., is there some implication for implementors that they need to be aware of so as not to intefere with 4311? Thomas From iesg-secretary@ietf.org Wed Jun 29 10:57:56 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637E111E809B; Wed, 29 Jun 2011 10:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.452 X-Spam-Level: X-Spam-Status: No, score=-102.452 tagged_above=-999 required=5 tests=[AWL=0.147, 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 q6Rx4TlWG4+E; Wed, 29 Jun 2011 10:57:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2513621F8586; Wed, 29 Jun 2011 10:57:54 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Last Call: (IPv6 Node Requirements) to Informational RFC X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110629175754.14430.70950.idtracker@ietfa.amsl.com> Date: Wed, 29 Jun 2011 10:57:54 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 17:57:56 -0000 The IESG has received a request from the IPv6 Maintenance WG (6man) to consider the following document: - 'IPv6 Node Requirements' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-07-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. This document obsoletes RFC4294. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-6man-node-req-bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-6man-node-req-bis/ No IPR declarations have been submitted directly on this I-D. From brian.e.carpenter@gmail.com Wed Jun 29 12:44:28 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82AFF11E80B8 for ; Wed, 29 Jun 2011 12:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 Oh1s7dYk9D2a for ; Wed, 29 Jun 2011 12:44:28 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 06F8D11E8099 for ; Wed, 29 Jun 2011 12:44:27 -0700 (PDT) Received: by iwn39 with SMTP id 39so1730515iwn.31 for ; Wed, 29 Jun 2011 12:44:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=FbL4QdEQr+xru4Izz2hO1tSQD9TCf529qnayFUz6Qqw=; b=r5w/dgfy1BnZt2ky5Zf3o37ki644EuXpEMQtSHn0nU1M/n7jCbYBbGBTr+wy/PVCWt sntqlK1YOoktAY3tSkYIqkI0AFfMYr2p+pfWkMk9hNzBo5hX9CG5OEmBYjBIl1iursKS aR70f8NMfpxnS0VHinEln2LrFIQTuNUAIOexY= Received: by 10.231.111.228 with SMTP id t36mr998818ibp.59.1309376667439; Wed, 29 Jun 2011 12:44:27 -0700 (PDT) Received: from [10.255.25.75] (74-95-74-1-Indianapolis.hfc.comcastbusiness.net [74.95.74.1]) by mx.google.com with ESMTPS id p15sm765430ibh.12.2011.06.29.12.44.26 (version=SSLv3 cipher=OTHER); Wed, 29 Jun 2011 12:44:26 -0700 (PDT) Message-ID: <4E0B8096.1080502@gmail.com> Date: Thu, 30 Jun 2011 07:44:22 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Thomas Narten Subject: Re: AD review of draft-ietf-6man-flow-3697bis References: <4DFF70A4.7040807@piuha.net> <71658E03-69C0-4160-BFF7-2AC6F7F5861C@gmail.com> <4E090ACF.3030901@piuha.net> <201106281312.p5SDCn2H006854@cichlid.raleigh.ibm.com> <4E0A370E.5090108@gmail.com> <201106282023.p5SKNZdR012027@cichlid.raleigh.ibm.com> <4E0A4B58.70007@gmail.com> <201106291642.p5TGgfRw009875@cichlid.raleigh.ibm.com> In-Reply-To: <201106291642.p5TGgfRw009875@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-ietf-6man-flow-3697bis@tools.ietf.org, Bob Hinden , IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 19:44:28 -0000 On 2011-06-30 04:42, Thomas Narten wrote: > I'm generally OK with this text. > > Brian E Carpenter writes: >> o This option, if implemented, would presumably be of value in >> first-hop or ingress routers. It might place a considerable per- >> packet processing load on them, even if they adopted a stateless >> method of flow identification and label assignment. Also, it >> should not interfere with host-to-router load sharing [RFC4311]. > > This sentence is ambiguous. is the "should not" a statement of fact, > or is it a directive, i.e., is there some implication for implementors > that they need to be aware of so as not to intefere with 4311? There's a fair amount of wiggle room in 4311, but I think it is true that setting the flow label in a router *will not* interfere. So I think that s/should not/will not/ is correct. Brian From internet-drafts@ietf.org Wed Jun 29 13:11:30 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC1721F85EE; Wed, 29 Jun 2011 13:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 o7VrpW4WHIYG; Wed, 29 Jun 2011 13:11:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6B821F85E5; Wed, 29 Jun 2011 13:11:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-flow-3697bis-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110629201129.29008.71102.idtracker@ietfa.amsl.com> Date: Wed, 29 Jun 2011 13:11:29 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 20:11:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the= IETF. Title : IPv6 Flow Label Specification Author(s) : Shane Amante Brian Carpenter Sheng Jiang Jarno Rajahalme Filename : draft-ietf-6man-flow-3697bis-05.txt Pages : 16 Date : 2011-06-29 This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods. Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of scope for this document. The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-3697bis-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-flow-3697bis-05.txt From brian.e.carpenter@gmail.com Wed Jun 29 13:13:23 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B420F11E80DA for ; Wed, 29 Jun 2011 13:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 yv+lITyd-+5P for ; Wed, 29 Jun 2011 13:13:22 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id C28D211E80C3 for ; Wed, 29 Jun 2011 13:13:22 -0700 (PDT) Received: by iwn39 with SMTP id 39so1754630iwn.31 for ; Wed, 29 Jun 2011 13:13:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=fTb+YtWUvtwjIG3hX98DnE4qR6sVnN+k7EnbnBqXApI=; b=CLUVFcfjJzUdl3jIwsSkHjiRYmJkxJkuYfZ7WYZEi24fcRGmF5JRMBE9XD8WQwU13g LlDNCXQZkMnTKM1btvZGkWpSzWWa8y3knKJacumeT/gR6K0K08edd4NUwPlmaN33NH97 wFxs2r3VGvP3gnhzpu4BmSROvrjtZ7AISyloc= Received: by 10.42.154.196 with SMTP id r4mr1165820icw.193.1309378402244; Wed, 29 Jun 2011 13:13:22 -0700 (PDT) Received: from [10.255.25.75] (74-95-74-1-Indianapolis.hfc.comcastbusiness.net [74.95.74.1]) by mx.google.com with ESMTPS id x13sm773512ibh.50.2011.06.29.13.13.21 (version=SSLv3 cipher=OTHER); Wed, 29 Jun 2011 13:13:21 -0700 (PDT) Message-ID: <4E0B875A.40604@gmail.com> Date: Thu, 30 Jun 2011 08:13:14 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 6man Subject: [Fwd: I-D Action: draft-ietf-6man-flow-3697bis-05.txt] Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 20:13:23 -0000 I believe this version resolves Jari's comments and the subsequent discussion. Brian -------- Original Message -------- Subject: I-D Action: draft-ietf-6man-flow-3697bis-05.txt Date: Wed, 29 Jun 2011 13:11:29 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: ipv6@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. Title : IPv6 Flow Label Specification Author(s) : Shane Amante Brian Carpenter Sheng Jiang Jarno Rajahalme Filename : draft-ietf-6man-flow-3697bis-05.txt Pages : 16 Date : 2011-06-29 This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods. Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of scope for this document. The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-3697bis-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-flow-3697bis-05.txt -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From jari.arkko@piuha.net Wed Jun 29 14:59:35 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F31911E80AB for ; Wed, 29 Jun 2011 14:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.364 X-Spam-Level: X-Spam-Status: No, score=-102.364 tagged_above=-999 required=5 tests=[AWL=0.235, 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 Jy7T7NfdgYXE for ; Wed, 29 Jun 2011 14:59:35 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 199F911E80A8 for ; Wed, 29 Jun 2011 14:59:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 384552CC3B; Thu, 30 Jun 2011 00:59:34 +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 Egyzze0Cct7g; Thu, 30 Jun 2011 00:59:33 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 6E2492CC39; Thu, 30 Jun 2011 00:59:33 +0300 (EEST) Message-ID: <4E0BA045.5080202@piuha.net> Date: Wed, 29 Jun 2011 23:59:33 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Brian E Carpenter , Thomas Narten Subject: Re: AD review of draft-ietf-6man-flow-3697bis References: <4DFF70A4.7040807@piuha.net> <71658E03-69C0-4160-BFF7-2AC6F7F5861C@gmail.com> <4E090ACF.3030901@piuha.net> <201106281312.p5SDCn2H006854@cichlid.raleigh.ibm.com> <4E0A370E.5090108@gmail.com> In-Reply-To: <4E0A370E.5090108@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPv6 Mailing List , Bob Hinden , draft-ietf-6man-flow-3697bis@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 21:59:35 -0000 Thomas, Brian, >> Sure. But why should that impact how the Flow Label is rewritten from >> zero to something else? >> > > Because different routers might pick different labels for packets > that belong to the same flow. > Yes, that was my concern. > But, this implies packets from the same flow are being sent through > different routers. If that is happening, something is broken, and this > document can't (and shouldn't) fix it ... > > And it won't happen at the first hop. I.e., ND addresses this as does > RFC 4311. All packets from the same flow go through the same router at > the first hop. Load balancing at the ND level means different flows > can go through different default routers. Ok. I have a bit better feeling about this in that case. Jari From jari.arkko@piuha.net Wed Jun 29 15:02:26 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7386811E80F5 for ; Wed, 29 Jun 2011 15:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.376 X-Spam-Level: X-Spam-Status: No, score=-102.376 tagged_above=-999 required=5 tests=[AWL=0.223, 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 2nbnhGmVhIFv for ; Wed, 29 Jun 2011 15:02:26 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 90A4F11E80ED for ; Wed, 29 Jun 2011 15:02:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id BC1622CC3B; Thu, 30 Jun 2011 01:02:24 +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 f9q8Nrao+kW6; Thu, 30 Jun 2011 01:02:21 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 19BB32CC39; Thu, 30 Jun 2011 01:02:21 +0300 (EEST) Message-ID: <4E0BA0ED.8050203@piuha.net> Date: Thu, 30 Jun 2011 00:02:21 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: [Fwd: I-D Action: draft-ietf-6man-flow-3697bis-05.txt] References: <4E0B875A.40604@gmail.com> In-Reply-To: <4E0B875A.40604@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 22:02:26 -0000 Good. Are we ready to send this to Last Call, or do we want to wait for possible other comments from the working group? Jari Brian E Carpenter kirjoitti: > I believe this version resolves Jari's comments and the > subsequent discussion. > > Brian > > -------- Original Message -------- > Subject: I-D Action: draft-ietf-6man-flow-3697bis-05.txt > Date: Wed, 29 Jun 2011 13:11:29 -0700 > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > CC: ipv6@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 > Maintenance Working Group of the IETF. > > Title : IPv6 Flow Label Specification > Author(s) : Shane Amante > Brian Carpenter > Sheng Jiang > Jarno Rajahalme > Filename : draft-ietf-6man-flow-3697bis-05.txt > Pages : 16 > Date : 2011-06-29 > > This document specifies the IPv6 Flow Label field and the minimum > requirements for IPv6 nodes labeling flows, IPv6 nodes forwarding > labeled packets, and flow state establishment methods. Even when > mentioned as examples of possible uses of the flow labeling, more > detailed requirements for specific use cases are out of scope for > this document. > > The usage of the Flow Label field enables efficient IPv6 flow > classification based only on IPv6 main header fields in fixed > positions. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-3697bis-05.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-flow-3697bis-05.txt > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > From jari.arkko@piuha.net Wed Jun 29 15:35:28 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B2F21F8496 for ; Wed, 29 Jun 2011 15:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.387 X-Spam-Level: X-Spam-Status: No, score=-102.387 tagged_above=-999 required=5 tests=[AWL=0.212, 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 gOfRWhy4v8ss for ; Wed, 29 Jun 2011 15:35:28 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 1791D21F848D for ; Wed, 29 Jun 2011 15:35:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 40E972CC3B; Thu, 30 Jun 2011 01:35:27 +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 kdxvUpWa4sUy; Thu, 30 Jun 2011 01:35:26 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id C081E2CC39; Thu, 30 Jun 2011 01:35:26 +0300 (EEST) Message-ID: <4E0BA8AF.2070200@piuha.net> Date: Thu, 30 Jun 2011 00:35:27 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: [Fwd: I-D Action: draft-ietf-6man-flow-3697bis-05.txt] References: <4E0B875A.40604@gmail.com> <4E0BA0ED.8050203@piuha.net> In-Reply-To: <4E0BA0ED.8050203@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 22:35:28 -0000 I looked at Last Call time period and IESG telechat schedule and saw that if we want this approved before the IETF, it needs to go to IETF Last Call today. So I sent it in. If there are substantive comments from the working group we can pull the document back for further consideration in the working group. Jari From bob.hinden@gmail.com Wed Jun 29 15:39:04 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B65911E80C3 for ; Wed, 29 Jun 2011 15:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 s9Et76JVO5Yu for ; Wed, 29 Jun 2011 15:39:04 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id E94E311E80BE for ; Wed, 29 Jun 2011 15:39:03 -0700 (PDT) Received: by pvh18 with SMTP id 18so1520429pvh.31 for ; Wed, 29 Jun 2011 15:39:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=isHls4nRydvQfIJdK0/KqZz7mveQX3UW9Y7Clzcd8+o=; b=s/KUAjgSBWafzojo2fs2W/4rKj15dw/N3okg/4yyo56xEOyRWw7X38SsEHFmSI1ef3 nNuk6PJMjNz8QVqmiTbZ+s0aA+lvojVlZpvjwuhtQgk5Zs5BTGwGnZaOBgZzcL3I/aDv 93ll04zL+HKKNaoa9kOE+ry5wcas8dDtA/rzk= Received: by 10.68.5.68 with SMTP id q4mr1660337pbq.117.1309387143395; Wed, 29 Jun 2011 15:39:03 -0700 (PDT) Received: from [172.16.224.217] ([209.97.127.34]) by mx.google.com with ESMTPS id z7sm1182240pbk.19.2011.06.29.15.39.01 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Jun 2011 15:39:02 -0700 (PDT) Subject: Re: [Fwd: I-D Action: draft-ietf-6man-flow-3697bis-05.txt] Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: <4E0BA8AF.2070200@piuha.net> Date: Wed, 29 Jun 2011 15:39:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <05503FA3-C89A-4115-ABCD-4A9223D483D3@gmail.com> References: <4E0B875A.40604@gmail.com> <4E0BA0ED.8050203@piuha.net> <4E0BA8AF.2070200@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1084) Cc: 6man , Bob Hinden , Brian E Carpenter X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 22:39:04 -0000 On Jun 29, 2011, at 3:35 PM, Jari Arkko wrote: > I looked at Last Call time period and IESG telechat schedule and saw = that if we want this approved before the IETF, it needs to go to IETF = Last Call today. So I sent it in. If there are substantive comments from = the working group we can pull the document back for further = consideration in the working group. >=20 Works for me. It's good to see it taking the next step forward. Thanks, Bob From iesg-secretary@ietf.org Wed Jun 29 15:52:53 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 570F311E8107; Wed, 29 Jun 2011 15:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 JB4l9XicIoi7; Wed, 29 Jun 2011 15:52:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C26111E80BD; Wed, 29 Jun 2011 15:52:51 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Last Call: (IPv6 Flow Label Specification) to Proposed Standard X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110629225251.13122.14929.idtracker@ietfa.amsl.com> Date: Wed, 29 Jun 2011 15:52:51 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 22:52:53 -0000 The IESG has received a request from the IPv6 Maintenance WG (6man) to consider the following document: - 'IPv6 Flow Label Specification' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-07-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods. Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of scope for this document. The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-6man-flow-3697bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-6man-flow-3697bis/ No IPR declarations have been submitted directly on this I-D. From joelja@bogus.com Thu Jun 30 00:07:03 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8FA011E813E; Thu, 30 Jun 2011 00:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.949 X-Spam-Level: X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 ZFEXz6sil7fd; Thu, 30 Jun 2011 00:07:03 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 08EFF11E8074; Thu, 30 Jun 2011 00:07:02 -0700 (PDT) Received: from zorch.lan (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p5U76xw0047171 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 30 Jun 2011 07:07:00 GMT (envelope-from joelja@bogus.com) From: Joel Jaeggli Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: new draft: draft-gashinsky-v6nd-enhance-00 Date: Thu, 30 Jun 2011 00:06:59 -0700 Message-Id: To: ipv6@ietf.org, "v6ops@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 30 Jun 2011 07:07:00 +0000 (UTC) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 07:07:03 -0000 I would direct the two working groups' attention if I may to a recently = posted draft: http://tools.ietf.org/html/draft-gashinsky-v6nd-enhance-00 the potential DOS exposure that ipv6 neighbor discovery poses to routers = is generally understood at this point, the document covers usable work = arounds, and includes some rough proposals for addressing what the = authors views as shortcomings in the neighbor disocvery process. some inspiration was drawn from: http://tools.ietf.org/html/draft-nordmark-6man-impatient-nud-00 thanks joel A new version of I-D, draft-gashinsky-v6nd-enhance-00.txt has been = successfully submitted by joel jaeggli and posted to the IETF = repository. Filename: draft-gashinsky-v6nd-enhance Revision: 00 Title: Operational Neighbor Discovery Problems and = Enhancements. Creation date: 2011-06-29 WG ID: Individual Submission Number of pages: 15 Abstract: In IPv4, subnets are generally small, made just large enough to cover the actual number of machines on the subnet. In contrast, the default IPv6 subnet size is a /64, a number so large it covers trillions of addresses, the overwhelming number of which will be unassigned. Consequently, simplistic implementations of Neighbor Discovery can be vulnerable to denial of service attacks whereby they attempt to perform address resolution for large numbers of unassigned addresses. Such denial of attacks can be launched intentionally (by an attacker), or result from legitimate operational tools that scan networks for inventory and other purposes. As a result of these vulnerabilities, new devices may not be able to "join" a = network, it may be impossible to establish new IPv6 flows, and existing ipv6 transported flows may be interrupted. This document describes the problem in detail and suggests possible implementation improvements as well as operational mitigation techniques that can in some cases to protect against such attacks. It also discusses possible modifications to the traditional [RFC4861] neighbor discovery protocol itself. The IETF Secretariat From ipng@69706e6720323030352d30312d31340a.nosense.org Thu Jun 30 01:16:54 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD8721F878D for ; Thu, 30 Jun 2011 01:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 BuYRp3QJW3CM for ; Thu, 30 Jun 2011 01:16:53 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4B121F878F for ; Thu, 30 Jun 2011 01:16:53 -0700 (PDT) Received: from 122-49-187-58.ip.adam.com.au ([122.49.187.58] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QcCQc-0007Vt-B4; Thu, 30 Jun 2011 17:46:50 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id F14003B33E; Thu, 30 Jun 2011 17:46:49 +0930 (CST) Date: Thu, 30 Jun 2011 17:46:49 +0930 From: Mark Smith To: Tim Chown Subject: Re: rfc3484-bis issue 3: prefer greatest prefix lifetime? Message-ID: <20110630174649.2bba7811@opy.nosense.org> In-Reply-To: References: X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 08:16:54 -0000 Hi Tim, On Tue, 28 Jun 2011 15:41:01 +0100 Tim Chown wrote: > The third issue is I think one that Mark Smith raised, and there was some discussion without a conclusion. > Thanks very much for checking on this. > Do we add a rule between 3 and 4 saying 'Prefer greatest preferred lifetime', i.e. If the addresses SA and SB both have non-zero value preferred lifetimes (are "non-deprecated"), prefer the address with the greatest value preferred lifetime? > > There are some cases where this might be expected behaviour, but there have been views expressed both ways. > > Comments please. > I raised the specific question of static vs SLAAC on the ipv6-ops operator list under the title "Static vs SLAAC - Static expected to be preferred?". There were a few direct, "yes, that's what I expect" responses. The rest of the discussion seemed to be about increasingly complicated and variety of ways of disabling SLAAC addresses (including disabling receiving RAs completely) on hosts that you want to assign static addresses to. Perhaps their complexity and variety also suggest that configure IPv6 static addresses and having them preferred should be simpler. One possible outcome of the discussion was to change the position of my suggested rule to between rules 7 and 8, as the original position I suggested would make static addresses preferred over privacy (temporary) rules, as privacy addresses would have smaller preferred lifetimes than the typical infinite preferred lifetime of a static address. Thinking about this some more, I've realised that rule 3 is more of a rule to filter out deprecated addresses. It would only result in a final address selection if there is only one preferred address remaining. If there is more than one preferred address after rule 3, then the subsequent rules are the ones that select the actual preferred address to use, based on different address attributes. The attribute that isn't in the current list is the value of the preferred lifetime. I've though that preferred lifetimes that are significantly (dramatically!) greater than RA lifetimes are serving more than the purpose of just aging addresses out, but also expressing a preference for use of that address. This preference idea seemed to me to be supported by the RFC4861 defaults of an RA lifetime of 3 * MaxRtrAdvInterval or 1800 seconds, and a an AdvPreferredLifetime of 604800 seconds. If two prefixes were announced, one with a preferred lifetime of 3600 seconds, and the other with 604800, I'd think the administrator intended the 604800 second prefix to be preferred because it is going to live for far longer. So it seemed to me that the address selection rules should consider the value of the preferred lifetime. By doing so, it also meant that static addresses would win if they were configured, as their preferred lifetime is 'infinite'. Having better understood the purpose of rule 3, I'm now having trouble suggesting where in the subsequent rules that the value of the preferred lifetime should be considered. If it is put in between rule 3 and 4, it means that the subsequent rules are unlikely to ever be applied unless two or more addresses have exactly the same preferred lifetime. I think that is being too restrictive. OTOH, the preferred lifetime value could be used as a tie breaker for the subsequent rules, applied if two or more addresses pass. For example, if there are two Rule 4 home addresses, then preferred lifetime is used to pick one of those, and if they both have the same preferred lifetime, then Rule 5 is evaluated. The drawback of that is that static routes may then not override SLAAC or DHCPv6 learned addresses which was the original goal. Unfortunately I can't see a simple way to use the value of the preferred lifetime in the source address selection process and still achieve preference of static addresses over other types. So perhaps the only way to make static addresses take precedence is just to have a simple "Prefer Static Addresses" rule between Rule 3 and Rule 4. Thanks, Mark. From brian.e.carpenter@gmail.com Thu Jun 30 05:33:00 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC7511E8083 for ; Thu, 30 Jun 2011 05:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 f1vmSj0v6Pvh for ; Thu, 30 Jun 2011 05:33:00 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D5C3711E807F for ; Thu, 30 Jun 2011 05:32:59 -0700 (PDT) Received: by iwn39 with SMTP id 39so2418415iwn.31 for ; Thu, 30 Jun 2011 05:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=x9rV/t79rjVZLL4VvReAP1sSVxc2qDYREFYAwslDrgk=; b=vilCQH8AW7d+aI31jRIQdo7TZeP69EkDv4vhMFKTuZ+GT2piwLCAhnajVYpBu03ipf B/qCLMIyy31fQcnFnQ5NmS+X+OYiEXRwWPOacM1XHTJYYpUJyAENJU/bbB7As/OXmeCW /vLSzELUL36aHJX2CRhWBpqk4Et2hl+w8uIlA= Received: by 10.42.162.68 with SMTP id w4mr2223123icx.29.1309437179384; Thu, 30 Jun 2011 05:32:59 -0700 (PDT) Received: from [10.255.25.75] (74-95-74-1-Indianapolis.hfc.comcastbusiness.net [74.95.74.1]) by mx.google.com with ESMTPS id j2sm2144534icu.22.2011.06.30.05.32.58 (version=SSLv3 cipher=OTHER); Thu, 30 Jun 2011 05:32:58 -0700 (PDT) Message-ID: <4E0C6CEF.9090107@gmail.com> Date: Fri, 01 Jul 2011 00:32:47 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jari Arkko Subject: Re: [Fwd: I-D Action: draft-ietf-6man-flow-3697bis-05.txt] References: <4E0B875A.40604@gmail.com> <4E0BA0ED.8050203@piuha.net> <4E0BA8AF.2070200@piuha.net> In-Reply-To: <4E0BA8AF.2070200@piuha.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 12:33:00 -0000 Thanks Jari. Of course, we can always factor in later WG comments if necessary. Regards Brian On 2011-06-30 10:35, Jari Arkko wrote: > I looked at Last Call time period and IESG telechat schedule and saw > that if we want this approved before the IETF, it needs to go to IETF > Last Call today. So I sent it in. If there are substantive comments from > the working group we can pull the document back for further > consideration in the working group. > > Jari > > From ietfc@btconnect.com Thu Jun 30 10:06:18 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F05F511E8227 for ; Thu, 30 Jun 2011 10:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.526 X-Spam-Level: X-Spam-Status: No, score=-1.526 tagged_above=-999 required=5 tests=[AWL=-0.416, BAYES_05=-1.11] 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 bM-FublJF4u9 for ; Thu, 30 Jun 2011 10:06:18 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr07.btconnect.com [213.123.20.125]) by ietfa.amsl.com (Postfix) with ESMTP id C8F2A11E8075 for ; Thu, 30 Jun 2011 10:06:17 -0700 (PDT) Received: from host81-156-70-165.range81-156.btcentralplus.com (HELO pc6) ([81.156.70.165]) by c2bthomr07.btconnect.com with SMTP id DPO12390; Thu, 30 Jun 2011 18:06:07 +0100 (BST) Message-ID: <018801cc373f$46438840$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Jari Arkko" , "Brian E Carpenter" References: <4E0B875A.40604@gmail.com> <4E0BA0ED.8050203@piuha.net> <4E0BA8AF.2070200@piuha.net> Subject: Re: [Fwd: I-D Action: draft-ietf-6man-flow-3697bis-05.txt] Date: Thu, 30 Jun 2011 18:03:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4E0CACFF.0007, actions=TAG X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.6.30.162715:17:7.586, ip=81.156.70.165, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __FRAUD_BODY_WEBMAIL, __URI_NO_PATH, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_900_999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, BODY_SIZE_1000_LESS, RDNS_SUSP, BODY_SIZE_2000_LESS, __FRAUD_WEBMAIL, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr07.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0201.4E0CAD04.015B,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 17:06:19 -0000 Is there a document shepherd write up for this document? Is there a document shepherd:-) Tom Petch ----- Original Message ----- From: "Jari Arkko" To: "Brian E Carpenter" Cc: "6man" Sent: Thursday, June 30, 2011 12:35 AM Subject: Re: [Fwd: I-D Action: draft-ietf-6man-flow-3697bis-05.txt] > I looked at Last Call time period and IESG telechat schedule and saw > that if we want this approved before the IETF, it needs to go to IETF > Last Call today. So I sent it in. If there are substantive comments from > the working group we can pull the document back for further > consideration in the working group. > > Jari > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From bob.hinden@gmail.com Thu Jun 30 10:23:30 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6434B11E8276 for ; Thu, 30 Jun 2011 10:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1, 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 mIXiQswEvzKW for ; Thu, 30 Jun 2011 10:23:29 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B3E3511E8271 for ; Thu, 30 Jun 2011 10:23:28 -0700 (PDT) Received: by iwn39 with SMTP id 39so2702144iwn.31 for ; Thu, 30 Jun 2011 10:23:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=6HUbFui1v983mm+HBBvhogzW7YXRfdrr6uTG6+P3TDY=; b=m9q7bIww9epo/9+Ev/wAQp6KBZ5CAZDlta3g1DtRRUaiRmb1i7hY122LUnDzfc1AYV 33tVM2xK5Glqec+v+E7RyJvIlrjF8X5fzkRVKGMwjCJSZBKvWb9PMPSCozfn24okw4Uk TTWP2A+ik6G8zSj/itiQmijVqHIffs7rGImpc= Received: by 10.42.168.3 with SMTP id u3mr2184626icy.355.1309454608055; Thu, 30 Jun 2011 10:23:28 -0700 (PDT) Received: from [172.16.224.217] ([209.97.127.34]) by mx.google.com with ESMTPS id x4sm550333ibm.8.2011.06.30.10.23.25 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 30 Jun 2011 10:23:26 -0700 (PDT) Subject: Re: [Fwd: I-D Action: draft-ietf-6man-flow-3697bis-05.txt] Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bob Hinden X-Priority: 3 In-Reply-To: <018801cc373f$46438840$4001a8c0@gateway.2wire.net> Date: Thu, 30 Jun 2011 10:23:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E0B875A.40604@gmail.com> <4E0BA0ED.8050203@piuha.net> <4E0BA8AF.2070200@piuha.net> <018801cc373f$46438840$4001a8c0@gateway.2wire.net> To: t.petch X-Mailer: Apple Mail (2.1084) Cc: Bob Hinden , Brian E Carpenter , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 17:23:30 -0000 Tom, Brian Haberman is the document shepherd. The questionnaire was sent to = the ADs and should be in the tracker. Bob On Jun 30, 2011, at 9:03 AM, t.petch wrote: > Is there a document shepherd write up for this document? >=20 > Is there a document shepherd:-) >=20 > Tom Petch >=20 > ----- Original Message -----=20 > From: "Jari Arkko" > To: "Brian E Carpenter" > Cc: "6man" > Sent: Thursday, June 30, 2011 12:35 AM > Subject: Re: [Fwd: I-D Action: draft-ietf-6man-flow-3697bis-05.txt] >=20 >=20 >> I looked at Last Call time period and IESG telechat schedule and saw=20= >> that if we want this approved before the IETF, it needs to go to IETF=20= >> Last Call today. So I sent it in. If there are substantive comments = from=20 >> the working group we can pull the document back for further=20 >> consideration in the working group. >>=20 >> Jari >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From bob.hinden@gmail.com Thu Jun 30 11:06:50 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 297D311E820B for ; Thu, 30 Jun 2011 11:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.572 X-Spam-Level: X-Spam-Status: No, score=-103.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 nAmv6AeiMYEG for ; Thu, 30 Jun 2011 11:06:49 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A78BC11E80B5 for ; Thu, 30 Jun 2011 11:06:49 -0700 (PDT) Received: by iye7 with SMTP id 7so2738258iye.31 for ; Thu, 30 Jun 2011 11:06:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=Ma4pjJCVE578kVpaQRZb8g2wv2p1lytk0OU+7D+E4xQ=; b=b3fh2y1WOWOI2kmO9E7Eu+eptjDZI3IBGONOY8d+O6h3s9Hx3DOSMvmGRoucYag5U0 jb/Z5lrEbbVOlGAqq/RGZZCc0WTwTwHcbua2HCkvIypjT9eqZVb/pA5OaK3HafTya7ci MedEalWYqw1mg/99XCpZWCoTUlbvRxp6RFcA8= Received: by 10.42.223.3 with SMTP id ii3mr2254558icb.49.1309457209197; Thu, 30 Jun 2011 11:06:49 -0700 (PDT) Received: from [172.16.224.217] ([209.97.127.34]) by mx.google.com with ESMTPS id d6sm2396819icx.13.2011.06.30.11.06.47 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 30 Jun 2011 11:06:48 -0700 (PDT) From: Bob Hinden Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: 6MAN WG Last Call: <> Date: Thu, 30 Jun 2011 11:06:45 -0700 Message-Id: <592F1E78-3C0E-4B7B-A27D-3F8016A503EF@gmail.com> To: 6man Mailing List Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Brian Haberman , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 18:06:50 -0000 All, This message starts a two week 6MAN Working Group Last Call on = advancing: Title : An uniform format for IPv6 extension headers Author(s) : Suresh Krishnan Erik Kline James Hoagland Manav Bhatia Filename : draft-ietf-6man-exthdr-03.txt Pages : 8 Date : 2011-06-27 =09 http://tools.ietf.org/html/draft-ietf-6man-exthdr-03 as a Proposed Standard. Substantive comments and statements of support = for advancing this document should be directed to the mailing list. = Editorial suggestions can be sent to the authors. This last call will = end on 14 July 2011. Regards, Bob Hinden & Brian Haberman 6MAN Chairs From brian.e.carpenter@gmail.com Thu Jun 30 12:07:02 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8975111E807D for ; Thu, 30 Jun 2011 12:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1, 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 ZaIwcAVGKI33 for ; Thu, 30 Jun 2011 12:07:02 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 07B4111E807A for ; Thu, 30 Jun 2011 12:07:01 -0700 (PDT) Received: by iye7 with SMTP id 7so2796386iye.31 for ; Thu, 30 Jun 2011 12:07:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=dX8zaFVx8LffdfqhRzwFemP8HSK0Gz5YiUqCPQd1jT4=; b=tFHOQ9EHe0dDFFTHfMtY+W4USdZNlOmEkpOS2X4lWIlAjk92FaQgLIhAzcVe99k0kt BvcuNI9xzz2LU/HdzwXCVTxPO9373kJDgM5k9R9roUY2lfaBRf4nM3BSgUC5bbWJljDf lnmlextbrHRgbAkVcFDS1CHVGA5XXNRomi2h8= Received: by 10.42.130.129 with SMTP id v1mr2012847ics.336.1309460821275; Thu, 30 Jun 2011 12:07:01 -0700 (PDT) Received: from [10.255.25.75] (74-95-74-1-Indianapolis.hfc.comcastbusiness.net [74.95.74.1]) by mx.google.com with ESMTPS id y1sm2447261ica.4.2011.06.30.12.06.58 (version=SSLv3 cipher=OTHER); Thu, 30 Jun 2011 12:07:00 -0700 (PDT) Message-ID: <4E0CC946.8040609@gmail.com> Date: Fri, 01 Jul 2011 07:06:46 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Bob Hinden Subject: Re: [Fwd: I-D Action: draft-ietf-6man-flow-3697bis-05.txt] References: <4E0B875A.40604@gmail.com> <4E0BA0ED.8050203@piuha.net> <4E0BA8AF.2070200@piuha.net> <018801cc373f$46438840$4001a8c0@gateway.2wire.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man , "t.petch" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 19:07:02 -0000 With respect to one comment in the writeup: "At this point, the example algorithm provided in Appendix A does not generate sufficiently distributed flow label values. Prior to RFC publication or IETF Last Call, this algorithm will need to be replaced by the authors." The latest draft does contain an updated algorithm, and the wording has been changed to make it very clear that it's only a simple example. Regards Brian On 2011-07-01 05:23, Bob Hinden wrote: > Tom, > > Brian Haberman is the document shepherd. The questionnaire was sent to the ADs and should be in the tracker. > > Bob > > > On Jun 30, 2011, at 9:03 AM, t.petch wrote: > >> Is there a document shepherd write up for this document? >> >> Is there a document shepherd:-) >> >> Tom Petch >> >> ----- Original Message ----- >> From: "Jari Arkko" >> To: "Brian E Carpenter" >> Cc: "6man" >> Sent: Thursday, June 30, 2011 12:35 AM >> Subject: Re: [Fwd: I-D Action: draft-ietf-6man-flow-3697bis-05.txt] >> >> >>> I looked at Last Call time period and IESG telechat schedule and saw >>> that if we want this approved before the IETF, it needs to go to IETF >>> Last Call today. So I sent it in. If there are substantive comments from >>> the working group we can pull the document back for further >>> consideration in the working group. >>> >>> Jari >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > From bob.hinden@gmail.com Thu Jun 30 16:30:52 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A6711E818F for ; Thu, 30 Jun 2011 16:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.574 X-Spam-Level: X-Spam-Status: No, score=-103.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 L1HJshOhvp-v for ; Thu, 30 Jun 2011 16:30:51 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id D224B11E80BD for ; Thu, 30 Jun 2011 16:30:51 -0700 (PDT) Received: by pvh18 with SMTP id 18so2920452pvh.31 for ; Thu, 30 Jun 2011 16:30:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=PtTbIshQp82g4Ak1Hwc+H101r7cN2VOueBvCa5tbFB0=; b=dwqFO5i3qNHBSC0BJexK60kwRoJZ4wCuWacwHE/X1ON4SQkDeyZvIRLdrs0UpqYnnn V0UJ/y0QjuNkReX1YwlmXnDqrB+om0mUEAlDSAdkchKbQH2vn1nIAJpmeOSni0jKQBMm npmcYXkzE/1v7GJyke6cj4SP9fGcWZr+RuFFE= Received: by 10.68.22.232 with SMTP id h8mr2774506pbf.528.1309476651366; Thu, 30 Jun 2011 16:30:51 -0700 (PDT) Received: from [172.16.224.217] ([209.97.127.34]) by mx.google.com with ESMTPS id d1sm1695344pbj.88.2011.06.30.16.30.49 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 30 Jun 2011 16:30:50 -0700 (PDT) From: Bob Hinden Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: 6MAN WG Last Call: Date: Thu, 30 Jun 2011 16:30:48 -0700 Message-Id: <0D404626-3B18-41EA-839D-43FDA972842B@gmail.com> To: 6man Mailing List Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Brian Haberman , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 23:30:52 -0000 [Resend] All, This message starts a two week 6MAN Working Group Last Call on = advancing: Title : An uniform format for IPv6 extension headers Author(s) : Suresh Krishnan Erik Kline James Hoagland Manav Bhatia Filename : draft-ietf-6man-exthdr-03.txt Pages : 8 Date : 2011-06-27 =09 http://tools.ietf.org/html/draft-ietf-6man-exthdr-03 as a Proposed Standard. Substantive comments and statements of support = for advancing this document should be directed to the mailing list. = Editorial suggestions can be sent to the authors. This last call will = end on 14 July 2011. Regards, Bob Hinden & Brian Haberman 6MAN Chairs