From dromasca@avaya.com Tue Oct 19 09:17:47 2010 Return-Path: X-Original-To: smartpowerdir@core3.amsl.com Delivered-To: smartpowerdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FC0E3A689C for ; Tue, 19 Oct 2010 09:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9BtJS0PySRF for ; Tue, 19 Oct 2010 09:17:46 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 0952D3A682C for ; Tue, 19 Oct 2010 09:17:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,351,1283745600"; d="scan'208";a="39703830" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 19 Oct 2010 12:19:16 -0400 X-IronPort-AV: E=Sophos;i="4.57,351,1283745600"; d="scan'208";a="527925470" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 19 Oct 2010 12:19:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Oct 2010 18:19:07 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Meeting in Beijing? Thread-Index: ActvqVr9ceY7Ni0RSjOcLdSMUkoLUw== From: "Romascanu, Dan (Dan)" To: "IETF SmartPower Directorate" Subject: [smartpowerdir] Meeting in Beijing? X-BeenThere: smartpowerdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Members of the Smart Power Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 16:17:47 -0000 Are we planning for a meeting of smartpowerdir in Beijing? My meeting slots fade out quickly, but I still have Thursday breakfast free if we decide to meet at the same time as in Maastricht.=20 Dan From jari.arkko@piuha.net Wed Oct 20 10:42:12 2010 Return-Path: X-Original-To: smartpowerdir@core3.amsl.com Delivered-To: smartpowerdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 814E33A68C8 for ; Wed, 20 Oct 2010 10:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZxj4F-9k9fX for ; Wed, 20 Oct 2010 10:42:11 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 58C573A689C for ; Wed, 20 Oct 2010 10:42:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 58EEA2CC32; Wed, 20 Oct 2010 20:43:44 +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 4oigr6NJ+TAQ; Wed, 20 Oct 2010 20:43:44 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id DF5D52CC2F; Wed, 20 Oct 2010 20:43:43 +0300 (EEST) Message-ID: <4CBF2A4F.1030109@piuha.net> Date: Wed, 20 Oct 2010 20:43:43 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF SmartPower Directorate Subject: Re: [smartpowerdir] Meeting in Beijing? X-BeenThere: smartpowerdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Members of the Smart Power Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 17:42:12 -0000 That would be a good time for me as well. I would like to have a meeting. Jari Romascanu, Dan (Dan) kirjoitti: > Are we planning for a meeting of smartpowerdir in Beijing? My meeting > slots fade out quickly, but I still have Thursday breakfast free if we > decide to meet at the same time as in Maastricht. > > Dan > > From ted.ietf@gmail.com Wed Oct 20 11:33:52 2010 Return-Path: X-Original-To: smartpowerdir@core3.amsl.com Delivered-To: smartpowerdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B0033A680D for ; Wed, 20 Oct 2010 11:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBUuUnCVh0Sj for ; Wed, 20 Oct 2010 11:33:50 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 155423A6802 for ; Wed, 20 Oct 2010 11:33:47 -0700 (PDT) Received: by qwc9 with SMTP id 9so2704146qwc.31 for ; Wed, 20 Oct 2010 11:35:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=dSTEaG8Ym5qE5/75v0P0Tnl/tfBzuCzd4L53p1ORfho=; b=SR9VKMKTlcWbsC93lEFQCM4KB4nqb24dZgJCg80jx0tiC4fAVffaHdFtkBQi6uStYn Lt8ZVyvMwsPQzQyQT0F1l7aWvDQRPH9+NTi/TJ2wKlOLAdBoQPmqmzFkoIBFfy2N+MlO W23Ph54h6qLwXT/3dPoLQcCVbWbPRWMDk1kpM= 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=kvT2s1AMc2KDe42Pyw3geoEhxzA52hLzvnEO1Xp7YQ0N/WoVCHgcjNKXGTJ/+UcO1Q Hec+TEWGfiVKYTRvVbxOFUnhA6HnsKIyuvI3hSNVwmUyMoJTHlN469DRaZyctK+MD83T Cbf8mXmxr0TpdovsbjSqOnxzulkxW9kVVHpyk= MIME-Version: 1.0 Received: by 10.229.182.205 with SMTP id cd13mr6813078qcb.30.1287599721290; Wed, 20 Oct 2010 11:35:21 -0700 (PDT) Received: by 10.229.213.69 with HTTP; Wed, 20 Oct 2010 11:35:20 -0700 (PDT) In-Reply-To: <4CBF2A4F.1030109@piuha.net> References: <4CBF2A4F.1030109@piuha.net> Date: Wed, 20 Oct 2010 11:35:20 -0700 Message-ID: From: Ted Hardie To: Jari Arkko Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF SmartPower Directorate Subject: Re: [smartpowerdir] Meeting in Beijing? X-BeenThere: smartpowerdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Members of the Smart Power Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 18:33:52 -0000 I am available at this time, and I'll hold it for this until any further word comes in. Ted On Wed, Oct 20, 2010 at 10:43 AM, Jari Arkko wrote: > That would be a good time for me as well. > > I would like to have a meeting. > > Jari > > Romascanu, Dan (Dan) kirjoitti: >> >> Are we planning for a meeting of smartpowerdir in Beijing? My meeting >> slots fade out quickly, but I still have Thursday breakfast free if we >> decide to meet at the same time as in Maastricht. >> Dan >> >> > > From zach@sensinode.com Wed Oct 20 12:41:45 2010 Return-Path: X-Original-To: smartpowerdir@core3.amsl.com Delivered-To: smartpowerdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 456FB3A6838 for ; Wed, 20 Oct 2010 12:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.507 X-Spam-Level: X-Spam-Status: No, score=-3.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZYz8rhP3+ax for ; Wed, 20 Oct 2010 12:41:42 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id D36D33A68B1 for ; Wed, 20 Oct 2010 12:41:38 -0700 (PDT) Received: from [192.168.1.3] (line-6222.dyn.kponet.fi [85.29.70.165]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o9KJh6mx030499 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Oct 2010 22:43:06 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-84-58942633; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Wed, 20 Oct 2010 22:43:07 +0300 Message-Id: <1F7C6415-9D86-4DD6-AFD0-63796509EE61@sensinode.com> References: <4CBF2A4F.1030109@piuha.net> To: Ted Hardie X-Mailer: Apple Mail (2.1081) Cc: IETF SmartPower Directorate Subject: Re: [smartpowerdir] Meeting in Beijing? X-BeenThere: smartpowerdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Members of the Smart Power Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 19:41:45 -0000 --Apple-Mail-84-58942633 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Thursday morning works for me as well. Zach On Oct 20, 2010, at 9:35 PM, Ted Hardie wrote: > I am available at this time, and I'll hold it for this > until any further word comes in. > > Ted > > On Wed, Oct 20, 2010 at 10:43 AM, Jari Arkko wrote: >> That would be a good time for me as well. >> >> I would like to have a meeting. >> >> Jari >> >> Romascanu, Dan (Dan) kirjoitti: >>> >>> Are we planning for a meeting of smartpowerdir in Beijing? My meeting >>> slots fade out quickly, but I still have Thursday breakfast free if we >>> decide to meet at the same time as in Maastricht. >>> Dan >>> >>> >> >> -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-84-58942633 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAyMDE5NDMw OFowIwYJKoZIhvcNAQkEMRYEFJ2ay3KP7LAsigcJOMlfLWbD1gXvMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAFEgrWeKYivj+qjiUKJeJLWO+d0U5asAljVumHRjMxjB36EH7GEEneaL 1qdGsr1dSc+tFGNZNkFm4J53yPrEDnrgXLDrYx2/p4GgcEy6DlM6txeduYFBinC1y+xX4iGNWYf5 u8kvywR+vu9vGy24uEHGxXrAZdZ6ND9wohVnA9fJG7nP3gZb+HB1H18UgkELqEf9ixxa5OHNTcX2 RuxwfuYZu9xSn5teKJpnmMNhYa4QTjYsesF6+zLt1SDUep5Ud2p+K+PI/dM+koPnKehTql1a1VSx P4MTmMFKZfP7XVYsFnwWXLDOsatw5LBvDWFnPamb0WyfzPwDNNkvtM59HcMAAAAAAAA= --Apple-Mail-84-58942633-- From rdroms.ietf@gmail.com Wed Oct 20 15:35:59 2010 Return-Path: X-Original-To: smartpowerdir@core3.amsl.com Delivered-To: smartpowerdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 321643A6990 for ; Wed, 20 Oct 2010 15:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzixHwZMnX3q for ; Wed, 20 Oct 2010 15:35:54 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 78D503A69FF for ; Wed, 20 Oct 2010 15:34:51 -0700 (PDT) Received: by qwc9 with SMTP id 9so2963092qwc.31 for ; Wed, 20 Oct 2010 15:36:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=Qp+UtqecICGBV7zQY9YrbMSR2i/YJAVjW9pgxFt2GBg=; b=Uga2zFHKPNhE4fekW0U7fINlojv1OrlK3lNywUjPZ5FC0cpoZw3dN8Y9CrqdSyLLGx /JPMahXr2iIjOM5TVio4N0wRiiq6qhlhNl7ARM1LDQoNdQvzomG9u569slvBzAPHJXoU gRPOnZClGo0ZmzsbFAJTt8ABXPZvtPOpuiwZY= 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=Vii8PERcQlmFrk50T2jdO+8YLL5yFUgyddpHtTwlM8DgP+UsGASmR5xkuI/7IWNgFk pYDYZhZ1BbqSv/cxuSoyekQe1SfP1+Y2rsIzOa3/8UfzdkN+gWmfFEsVIRCtfj5CJ30I EVwVrFqP8gNXvBEU89xnhcSkReiD1IPwgusWk= Received: by 10.229.185.137 with SMTP id co9mr6947527qcb.189.1287614181619; Wed, 20 Oct 2010 15:36:21 -0700 (PDT) Received: from bxb-rdroms-8712.cisco.com (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id m7sm661582qck.37.2010.10.20.15.36.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 20 Oct 2010 15:36:20 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <4CBF2A4F.1030109@piuha.net> Date: Wed, 20 Oct 2010 18:36:17 -0400 Content-Transfer-Encoding: 7bit Message-Id: <6AA76962-7777-424A-95AA-4A4D4F2312F6@gmail.com> References: <4CBF2A4F.1030109@piuha.net> To: Dan Romascanu X-Mailer: Apple Mail (2.1081) Cc: IETF SmartPower Directorate Subject: Re: [smartpowerdir] Meeting in Beijing? X-BeenThere: smartpowerdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Members of the Smart Power Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 22:35:59 -0000 I'm available Thu AM and will keep the slot open. - Ralph On Oct 20, 2010, at 1:43 PM 10/20/10, Jari Arkko wrote: > That would be a good time for me as well. > > I would like to have a meeting. > > Jari > > Romascanu, Dan (Dan) kirjoitti: >> Are we planning for a meeting of smartpowerdir in Beijing? My meeting >> slots fade out quickly, but I still have Thursday breakfast free if we >> decide to meet at the same time as in Maastricht. >> Dan >> >> > From vint@google.com Wed Oct 20 16:33:59 2010 Return-Path: X-Original-To: smartpowerdir@core3.amsl.com Delivered-To: smartpowerdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1F6E3A6900 for ; Wed, 20 Oct 2010 16:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6XII+5qAhO6 for ; Wed, 20 Oct 2010 16:33:58 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 4C45F3A6875 for ; Wed, 20 Oct 2010 16:33:58 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id o9KNZVxG016831 for ; Wed, 20 Oct 2010 16:35:31 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1287617731; bh=sxWCsokdONO7tYOXet3vZrMKHFI=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=lTPTCblTKxvwqrFafWvjq6LvlF1hhLpo2PpiYfUimX2ta3KDxFvVQtl7MtktS/Djd E4Z7UWlAMTcIrvPkTGfsw== Received: from gwaa20 (gwaa20.prod.google.com [10.200.27.20]) by hpaq5.eem.corp.google.com with ESMTP id o9KNZUaG016019 for ; Wed, 20 Oct 2010 16:35:30 -0700 Received: by gwaa20 with SMTP id a20so2556784gwa.10 for ; Wed, 20 Oct 2010 16:35:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=u8q1IQjp+FxVub0DEjw71zEd97W4mhm+5pmgvznrsZo=; b=HEWD7EnlNfQFEsbLOQdTodMaznZHKa3OgKUNlLN2eqJvBGx3JIXGfwgL0kZ9zByJ3X Xz61fJlVtx0e5y5xpW0w== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=tskF2mF5lDuEiT6oND+ut9h3/laGadzmWbJ4sISnNYDAXOP9IdJAOWDfGEHx1mZ6eo zdie1yhVzkVBg5vURKvw== MIME-Version: 1.0 Received: by 10.150.99.3 with SMTP id w3mr2313276ybb.97.1287617729772; Wed, 20 Oct 2010 16:35:29 -0700 (PDT) Received: by 10.150.133.9 with HTTP; Wed, 20 Oct 2010 16:35:29 -0700 (PDT) In-Reply-To: <6AA76962-7777-424A-95AA-4A4D4F2312F6@gmail.com> References: <4CBF2A4F.1030109@piuha.net> <6AA76962-7777-424A-95AA-4A4D4F2312F6@gmail.com> Date: Wed, 20 Oct 2010 19:35:29 -0400 Message-ID: From: Vint Cerf To: Ralph Droms Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: IETF SmartPower Directorate Subject: Re: [smartpowerdir] Meeting in Beijing? X-BeenThere: smartpowerdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Members of the Smart Power Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 23:34:00 -0000 i am unable to go to beijing but would greatly appreciate any advice emerging from your discussions. v On Wed, Oct 20, 2010 at 6:36 PM, Ralph Droms wrote: > I'm available Thu AM and will keep the slot open. > > - Ralph > > On Oct 20, 2010, at 1:43 PM 10/20/10, Jari Arkko wrote: > >> That would be a good time for me as well. >> >> I would like to have a meeting. >> >> Jari >> >> Romascanu, Dan (Dan) kirjoitti: >>> Are we planning for a meeting of smartpowerdir in Beijing? My meeting >>> slots fade out quickly, but I still have Thursday breakfast free if we >>> decide to meet at the same time as in Maastricht. >>> Dan >>> >>> >> > > From mehmet.ersue@nsn.com Thu Oct 21 01:23:12 2010 Return-Path: X-Original-To: smartpowerdir@core3.amsl.com Delivered-To: smartpowerdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B18E23A69DD for ; Thu, 21 Oct 2010 01:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.436 X-Spam-Level: X-Spam-Status: No, score=-102.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEnLFCKQfm67 for ; Thu, 21 Oct 2010 01:23:11 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id A12A53A69C7 for ; Thu, 21 Oct 2010 01:23:11 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o9L8Oc7N026473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Oct 2010 10:24:38 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o9L8ObcA011447; Thu, 21 Oct 2010 10:24:38 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Oct 2010 10:24:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Oct 2010 10:24:35 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64011B6E91@DEMUEXC006.nsn-intra.net> In-Reply-To: <6AA76962-7777-424A-95AA-4A4D4F2312F6@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [smartpowerdir] Meeting in Beijing? Thread-Index: Actwp3hwsuXwgXwBTiy4kxBCpLcpHAAUbxag References: <4CBF2A4F.1030109@piuha.net> <6AA76962-7777-424A-95AA-4A4D4F2312F6@gmail.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Ralph Droms" , "Dan Romascanu" X-OriginalArrivalTime: 21 Oct 2010 08:24:37.0116 (UTC) FILETIME=[660803C0:01CB70F9] Cc: IETF SmartPower Directorate Subject: Re: [smartpowerdir] Meeting in Beijing? X-BeenThere: smartpowerdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Members of the Smart Power Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 08:23:12 -0000 Thursday morning works. Mehmet > -----Original Message----- > From: smartpowerdir-bounces@ietf.org [mailto:smartpowerdir- > bounces@ietf.org] On Behalf Of ext Ralph Droms > Sent: Thursday, October 21, 2010 12:36 AM > To: Dan Romascanu > Cc: IETF SmartPower Directorate > Subject: Re: [smartpowerdir] Meeting in Beijing? >=20 > I'm available Thu AM and will keep the slot open. >=20 > - Ralph >=20 > On Oct 20, 2010, at 1:43 PM 10/20/10, Jari Arkko wrote: >=20 > > That would be a good time for me as well. > > > > I would like to have a meeting. > > > > Jari > > > > Romascanu, Dan (Dan) kirjoitti: > >> Are we planning for a meeting of smartpowerdir in Beijing? My > meeting > >> slots fade out quickly, but I still have Thursday breakfast free if > we > >> decide to meet at the same time as in Maastricht. > >> Dan > >> > >> > > From fred@cisco.com Thu Oct 21 05:01:12 2010 Return-Path: X-Original-To: smartpowerdir@core3.amsl.com Delivered-To: smartpowerdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E0503A6767 for ; Thu, 21 Oct 2010 05:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.412 X-Spam-Level: X-Spam-Status: No, score=-110.412 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyiQMtrayvUh for ; Thu, 21 Oct 2010 05:01:11 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id E2F033A69A1 for ; Thu, 21 Oct 2010 05:01:10 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFrIv0xAZnwN/2dsb2JhbAChVnGjZZwthUoEikuDBA X-IronPort-AV: E=Sophos;i="4.58,216,1286150400"; d="scan'208";a="173123172" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 21 Oct 2010 12:02:46 +0000 Received: from Freds-Computer.local (rtp-vpn4-695.cisco.com [10.82.210.183]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o9LC2Zaa029182; Thu, 21 Oct 2010 12:02:39 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Thu, 21 Oct 2010 08:02:45 -0400 X-PGP-Universal: processed; by Freds-Computer.local on Thu, 21 Oct 2010 08:02:45 -0400 Mime-Version: 1.0 (Apple Message framework v1081) From: Fred Baker In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64011B6E91@DEMUEXC006.nsn-intra.net> Date: Thu, 21 Oct 2010 08:02:25 -0400 Message-Id: References: <4CBF2A4F.1030109@piuha.net> <6AA76962-7777-424A-95AA-4A4D4F2312F6@gmail.com> <80A0822C5E9A4440A5117C2F4CD36A64011B6E91@DEMUEXC006.nsn-intra.net> To: "Ersue, Mehmet (NSN - DE/Munich)" , IETF SmartPower Directorate X-Mailer: Apple Mail (2.1081) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [smartpowerdir] Meeting in Beijing? X-BeenThere: smartpowerdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Members of the Smart Power Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 12:01:12 -0000 Great. Let's have breakfast together Thursday of the IETF. Thanks for = bringing it up, Dan. What's a good time? 7:30 with a view to running away by 9:00? On Oct 21, 2010, at 4:24 AM, Ersue, Mehmet (NSN - DE/Munich) wrote: > Thursday morning works. >=20 > Mehmet >=20 >=20 >> -----Original Message----- >> From: smartpowerdir-bounces@ietf.org [mailto:smartpowerdir- >> bounces@ietf.org] On Behalf Of ext Ralph Droms >> Sent: Thursday, October 21, 2010 12:36 AM >> To: Dan Romascanu >> Cc: IETF SmartPower Directorate >> Subject: Re: [smartpowerdir] Meeting in Beijing? >>=20 >> I'm available Thu AM and will keep the slot open. >>=20 >> - Ralph >>=20 >> On Oct 20, 2010, at 1:43 PM 10/20/10, Jari Arkko wrote: >>=20 >>> That would be a good time for me as well. >>>=20 >>> I would like to have a meeting. >>>=20 >>> Jari >>>=20 >>> Romascanu, Dan (Dan) kirjoitti: >>>> Are we planning for a meeting of smartpowerdir in Beijing? My >> meeting >>>> slots fade out quickly, but I still have Thursday breakfast free if >> we >>>> decide to meet at the same time as in Maastricht. >>>> Dan >>>>=20 >>>>=20 >>>=20 >=20 From rdroms.ietf@gmail.com Thu Oct 21 05:09:27 2010 Return-Path: X-Original-To: smartpowerdir@core3.amsl.com Delivered-To: smartpowerdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1B3D3A6934 for ; Thu, 21 Oct 2010 05:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fmxb7OGusbSc for ; Thu, 21 Oct 2010 05:09:27 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id E228C3A68DE for ; Thu, 21 Oct 2010 05:09:26 -0700 (PDT) Received: by pxi9 with SMTP id 9so1018024pxi.31 for ; Thu, 21 Oct 2010 05:11:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=ya0ze0pD5DhPuYuM0FmmNMlCMqFOW0OUmlhuangphAY=; b=P0Oi0VP6WahWvFUsqXLRQla6CDwCZUSpeurskRRqpFn8rnevToF6ujx9jSJy+r6hm8 Mn88GmI5hK1+4mUxyI7tWxytNXrHcYVjhMhCwpCzyeMFYR+nMtMJVWsIMxya9oanYcga JvKhYHGFkzhuKoAaL1EVN7s8WlrvLaM/efTeE= 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=oUY/GykEv7NrqPeCpIx1wLZOKMojznvJMBjBcoWk8z3416vKbzYZh+XB19QNkxGRV9 048ddyZsbdlgKUTBxuJiMa6WLc1Jc8zc0NwhSkIKNftDTH9obx4VC5otHX3/YDA40urt jDXjju2Xgc44TNbda8lFJYW5JVhJlpSB5v/mg= Received: by 10.142.238.5 with SMTP id l5mr524694wfh.337.1287663062306; Thu, 21 Oct 2010 05:11:02 -0700 (PDT) Received: from bxb-rdroms-8712.cisco.com (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id h28sm528221vcr.43.2010.10.21.05.11.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 21 Oct 2010 05:11:01 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: Date: Thu, 21 Oct 2010 08:11:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CBF2A4F.1030109@piuha.net> <6AA76962-7777-424A-95AA-4A4D4F2312F6@gmail.com> <80A0822C5E9A4440A5117C2F4CD36A64011B6E91@DEMUEXC006.nsn-intra.net> To: Fred Baker X-Mailer: Apple Mail (2.1081) Cc: IETF SmartPower Directorate Subject: Re: [smartpowerdir] Meeting in Beijing? X-BeenThere: smartpowerdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Members of the Smart Power Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 12:09:27 -0000 OK with me; it's in my calendar. - Ralph On Oct 21, 2010, at 8:02 AM 10/21/10, Fred Baker wrote: > Great. Let's have breakfast together Thursday of the IETF. Thanks for = bringing it up, Dan. >=20 > What's a good time? 7:30 with a view to running away by 9:00? >=20 > On Oct 21, 2010, at 4:24 AM, Ersue, Mehmet (NSN - DE/Munich) wrote: >=20 >> Thursday morning works. >>=20 >> Mehmet >>=20 >>=20 >>> -----Original Message----- >>> From: smartpowerdir-bounces@ietf.org [mailto:smartpowerdir- >>> bounces@ietf.org] On Behalf Of ext Ralph Droms >>> Sent: Thursday, October 21, 2010 12:36 AM >>> To: Dan Romascanu >>> Cc: IETF SmartPower Directorate >>> Subject: Re: [smartpowerdir] Meeting in Beijing? >>>=20 >>> I'm available Thu AM and will keep the slot open. >>>=20 >>> - Ralph >>>=20 >>> On Oct 20, 2010, at 1:43 PM 10/20/10, Jari Arkko wrote: >>>=20 >>>> That would be a good time for me as well. >>>>=20 >>>> I would like to have a meeting. >>>>=20 >>>> Jari >>>>=20 >>>> Romascanu, Dan (Dan) kirjoitti: >>>>> Are we planning for a meeting of smartpowerdir in Beijing? My >>> meeting >>>>> slots fade out quickly, but I still have Thursday breakfast free = if >>> we >>>>> decide to meet at the same time as in Maastricht. >>>>> Dan >>>>>=20 >>>>>=20 >>>>=20 >>=20 >=20 From mehmet.ersue@nsn.com Thu Oct 21 05:25:30 2010 Return-Path: X-Original-To: smartpowerdir@core3.amsl.com Delivered-To: smartpowerdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EEFE3A6767 for ; Thu, 21 Oct 2010 05:25:30 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pG3UT421kKpR for ; Thu, 21 Oct 2010 05:25:26 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 450183A66B4 for ; Thu, 21 Oct 2010 05:25:26 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o9LCQsdV002614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Oct 2010 14:26:54 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o9LCQnsU010230; Thu, 21 Oct 2010 14:26:54 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Oct 2010 14:26:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Oct 2010 14:26:46 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64011E5146@DEMUEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [smartpowerdir] Meeting in Beijing? Thread-Index: ActxF+Ee+qfwyM4uTviCZCv177mUCgAA1EvA References: <4CBF2A4F.1030109@piuha.net> <6AA76962-7777-424A-95AA-4A4D4F2312F6@gmail.com> <80A0822C5E9A4440A5117C2F4CD36A64011B6E91@DEMUEXC006.nsn-intra.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Fred Baker" , "IETF SmartPower Directorate" X-OriginalArrivalTime: 21 Oct 2010 12:26:47.0726 (UTC) FILETIME=[3AF324E0:01CB711B] Subject: Re: [smartpowerdir] Meeting in Beijing? X-BeenThere: smartpowerdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Members of the Smart Power Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 12:25:30 -0000 ACK. Cheers, Mehmet > -----Original Message----- > From: ext Fred Baker [mailto:fred@cisco.com] > Sent: Thursday, October 21, 2010 2:02 PM > To: Ersue, Mehmet (NSN - DE/Munich); IETF SmartPower Directorate > Cc: ext Ralph Droms; Dan Romascanu > Subject: Re: [smartpowerdir] Meeting in Beijing? >=20 > Great. Let's have breakfast together Thursday of the IETF. Thanks for > bringing it up, Dan. >=20 > What's a good time? 7:30 with a view to running away by 9:00? >=20 > On Oct 21, 2010, at 4:24 AM, Ersue, Mehmet (NSN - DE/Munich) wrote: >=20 > > Thursday morning works. > > > > Mehmet > > > > > >> -----Original Message----- > >> From: smartpowerdir-bounces@ietf.org [mailto:smartpowerdir- > >> bounces@ietf.org] On Behalf Of ext Ralph Droms > >> Sent: Thursday, October 21, 2010 12:36 AM > >> To: Dan Romascanu > >> Cc: IETF SmartPower Directorate > >> Subject: Re: [smartpowerdir] Meeting in Beijing? > >> > >> I'm available Thu AM and will keep the slot open. > >> > >> - Ralph > >> > >> On Oct 20, 2010, at 1:43 PM 10/20/10, Jari Arkko wrote: > >> > >>> That would be a good time for me as well. > >>> > >>> I would like to have a meeting. > >>> > >>> Jari > >>> > >>> Romascanu, Dan (Dan) kirjoitti: > >>>> Are we planning for a meeting of smartpowerdir in Beijing? My > >> meeting > >>>> slots fade out quickly, but I still have Thursday breakfast free > if > >> we > >>>> decide to meet at the same time as in Maastricht. > >>>> Dan > >>>> > >>>> > >>> > > From dromasca@avaya.com Thu Oct 21 07:53:02 2010 Return-Path: X-Original-To: smartpowerdir@core3.amsl.com Delivered-To: smartpowerdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09E9E3A6A2C for ; Thu, 21 Oct 2010 07:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEFoo7J7KGb4 for ; Thu, 21 Oct 2010 07:53:01 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id BB2C63A6A2E for ; Thu, 21 Oct 2010 07:53:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.58,217,1286164800"; d="scan'208";a="243879221" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 21 Oct 2010 10:54:36 -0400 X-IronPort-AV: E=Sophos;i="4.58,217,1286164800"; d="scan'208";a="528740723" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 21 Oct 2010 10:54:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Oct 2010 16:54:20 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [smartpowerdir] Meeting in Beijing? Thread-Index: ActxF+JCdON9EBJBQeSCLMQTFLwSEAAF+R1Q References: <4CBF2A4F.1030109@piuha.net> <6AA76962-7777-424A-95AA-4A4D4F2312F6@gmail.com> <80A0822C5E9A4440A5117C2F4CD36A64011B6E91@DEMUEXC006.nsn-intra.net> From: "Romascanu, Dan (Dan)" To: "Fred Baker" , "Ersue, Mehmet (NSN - DE/Munich)" , "IETF SmartPower Directorate" Subject: Re: [smartpowerdir] Meeting in Beijing? X-BeenThere: smartpowerdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Members of the Smart Power Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 14:53:02 -0000 7:30 to 9AM is fine - I put it in my schedule.=20 Dan =20 > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com]=20 > Sent: Thursday, October 21, 2010 2:02 PM > To: Ersue, Mehmet (NSN - DE/Munich); IETF SmartPower Directorate > Cc: ext Ralph Droms; Romascanu, Dan (Dan) > Subject: Re: [smartpowerdir] Meeting in Beijing? >=20 > Great. Let's have breakfast together Thursday of the IETF.=20 > Thanks for bringing it up, Dan. >=20 > What's a good time? 7:30 with a view to running away by 9:00? >=20 > On Oct 21, 2010, at 4:24 AM, Ersue, Mehmet (NSN - DE/Munich) wrote: >=20 > > Thursday morning works. > >=20 > > Mehmet > >=20 > >=20 > >> -----Original Message----- > >> From: smartpowerdir-bounces@ietf.org [mailto:smartpowerdir-=20 > >> bounces@ietf.org] On Behalf Of ext Ralph Droms > >> Sent: Thursday, October 21, 2010 12:36 AM > >> To: Dan Romascanu > >> Cc: IETF SmartPower Directorate > >> Subject: Re: [smartpowerdir] Meeting in Beijing? > >>=20 > >> I'm available Thu AM and will keep the slot open. > >>=20 > >> - Ralph > >>=20 > >> On Oct 20, 2010, at 1:43 PM 10/20/10, Jari Arkko wrote: > >>=20 > >>> That would be a good time for me as well. > >>>=20 > >>> I would like to have a meeting. > >>>=20 > >>> Jari > >>>=20 > >>> Romascanu, Dan (Dan) kirjoitti: > >>>> Are we planning for a meeting of smartpowerdir in Beijing? My > >> meeting > >>>> slots fade out quickly, but I still have Thursday=20 > breakfast free if > >> we > >>>> decide to meet at the same time as in Maastricht. > >>>> Dan > >>>>=20 > >>>>=20 > >>>=20 > >=20 >=20 >=20 From fred@cisco.com Mon Oct 25 11:46:02 2010 Return-Path: X-Original-To: smartpowerdir@core3.amsl.com Delivered-To: smartpowerdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 800FA3A697F for ; Mon, 25 Oct 2010 11:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRJf-S6cqm3D for ; Mon, 25 Oct 2010 11:46:02 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 61DB03A682F for ; Mon, 25 Oct 2010 11:45:59 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.58,236,1286150400"; d="scan'208,217";a="374355716" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 25 Oct 2010 18:47:44 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o9PIlNeN019476 for ; Mon, 25 Oct 2010 18:47:25 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Mon, 25 Oct 2010 11:47:30 -0700 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Mon, 25 Oct 2010 11:47:30 -0700 From: Fred Baker Date: Mon, 25 Oct 2010 11:47:16 -0700 Message-Id: <1144520E-FC10-4A67-AE2D-95584E1A9D8D@cisco.com> To: IETF SmartPower Directorate Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Content-Type: multipart/alternative; boundary=Apple-Mail-46-487591200 Subject: [smartpowerdir] Diff: draft-baker-ietf-core-07.txt - sg-ietf-compendium.txt X-BeenThere: smartpowerdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Members of the Smart Power Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 18:46:03 -0000 --Apple-Mail-46-487591200 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 25, 2010, at 11:29 AM, IETF I-D Submission Tool wrote: >=20 > A new version of I-D, draft-baker-ietf-core-09.txt has been = successfully submitted by Fred Baker and posted to the IETF repository. >=20 > Filename: draft-baker-ietf-core > Revision: 09 > Title: Internet Protocols for the Smart Grid > Creation_date: 2010-10-25 > WG ID: Independent Submission > Number_of_pages: 57 >=20 > Abstract: > This note identifies the key protocols of the Internet Protocol Suite > for use in the Smart Grid. The target audience is those people > seeking guidance on how to construct an appropriate Internet Protocol > Suite profile for the Smart Grid. In practice, such a profile would > consist of selecting what is needed for Smart Grid deployment from > the picture presented here. < draft-baker-ietf-core-07.txt sg-ietf-compendium.txt =09 =09 Network Working Group F. Baker = Network Working Group = F. Baker=09 Internet-Draft D. Meyer = Internet-Draft = D. Meyer=09 Intended status: Informational Cisco Systems = Intended status: Informational Cisco = Systems=09 Expires: February 18, 2011 August 17, 2010 = Expires: April 28, 2011 October = 25, 2010=09 =09 Internet Protocols for the Smart Grid = Internet Protocols for the Smart Grid=09 draft-baker-ietf-core-07 = draft-baker-ietf-core-09=09 =09 Abstract Abstract=09 =09 This note identifies the key protocols of the Internet Protocol Suite = This note identifies the key protocols of the Internet = Protocol Suite=09 for use in the Smart Grid. The target audience is those people = for use in the Smart Grid. The target audience is those = people=09 seeking guidance on how to construct an appropriate Internet Protocol = seeking guidance on how to construct an appropriate Internet = Protocol=09 Suite profile for the Smart Grid. In practice, such a profile would = Suite profile for the Smart Grid. In practice, such a = profile would=09 consist of selecting what is needed for Smart Grid deployment from = consist of selecting what is needed for Smart Grid deployment = from=09 the picture presented here. the picture presented here.=09= =09 =09 skipping to change at page 1, line 35 skipping to change at = page 1, line 35=09 Internet-Drafts are working documents of the Internet Engineering = Internet-Drafts are working documents of the Internet = Engineering=09 Task Force (IETF). Note that other groups may also distribute = Task Force (IETF). Note that other groups may also = distribute=09 working documents as Internet-Drafts. The list of current Internet- = working documents as Internet-Drafts. The list of current = Internet-=09 Drafts is at http://datatracker.ietf.org/drafts/current/. = Drafts is at http://datatracker.ietf.org/drafts/current/.=09 =09 Internet-Drafts are draft documents valid for a maximum of six months = Internet-Drafts are draft documents valid for a maximum of = six months=09 and may be updated, replaced, or obsoleted by other documents at any = and may be updated, replaced, or obsoleted by other documents = at any=09 time. It is inappropriate to use Internet-Drafts as reference = time. It is inappropriate to use Internet-Drafts as = reference=09 material or to cite them other than as "work in progress." = material or to cite them other than as "work in progress."=09 =09 This Internet-Draft will expire on February 18, 2011. = This Internet-Draft will expire on April 28, 2011.=09 =09 Copyright Notice Copyright Notice=09 =09 Copyright (c) 2010 IETF Trust and the persons identified as the = Copyright (c) 2010 IETF Trust and the persons identified as = the=09 document authors. All rights reserved. document = authors. All rights reserved.=09 =09 This document is subject to BCP 78 and the IETF Trust's Legal = This document is subject to BCP 78 and the IETF Trust's Legal=09= Provisions Relating to IETF Documents Provisions = Relating to IETF Documents=09 (http://trustee.ietf.org/license-info) in effect on the date of = (http://trustee.ietf.org/license-info) in effect on the date = of=09 publication of this document. Please review these documents = publication of this document. Please review these documents=09 =09 skipping to change at page 2, line 19 skipping to change at = page 2, line 19=09 2. The Internet Protocol Suite . . . . . . . . . . . . . . . . . 5 = 2. The Internet Protocol Suite . . . . . . . . . . . . . . = . . . 5=09 2.1. Internet Protocol Layers . . . . . . . . . . . . . . . . . 5 = 2.1. Internet Protocol Layers . . . . . . . . . . . . . . = . . . 5=09 2.1.1. Application . . . . . . . . . . . . . . . . . . . . . 6 = 2.1.1. Application . . . . . . . . . . . . . . . . . . = . . . 6=09 2.1.2. Transport . . . . . . . . . . . . . . . . . . . . . . 7 = 2.1.2. Transport . . . . . . . . . . . . . . . . . . . = . . . 7=09 2.1.3. Network . . . . . . . . . . . . . . . . . . . . . . . 7 = 2.1.3. Network . . . . . . . . . . . . . . . . . . . . = . . . 7=09 2.1.3.1. Internet Protocol . . . . . . . . . . . . . . . . 8 = 2.1.3.1. Internet Protocol . . . . . . . . . . . . . = . . . 8=09 2.1.3.2. Lower layer networks . . . . . . . . . . . . . . . 8 = 2.1.3.2. Lower layer networks . . . . . . . . . . . . = . . . 8=09 2.1.4. Media layers: Physical and Link . . . . . . . . . . . 8 = 2.1.4. Media layers: Physical and Link . . . . . . . . = . . . 8=09 2.2. Security issues . . . . . . . . . . . . . . . . . . . . . 8 = 2.2. Security issues . . . . . . . . . . . . . . . . . . = . . . 8=09 2.2.1. Physical security . . . . . . . . . . . . . . . . . . 9 = 2.2.1. Physical security . . . . . . . . . . . . . . . = . . . 9=09 2.2.2. Session identification . . . . . . . . . . . . . . . . 9 = 2.2.2. Session Authentication . . . . . . . . . . . . . = . . . 9=09 2.2.3. Confidentiality . . . . . . . . . . . . . . . . . . . 10 = 2.2.3. Confidentiality . . . . . . . . . . . . . . . . = . . . 10=09 2.3. Network Infrastructure . . . . . . . . . . . . . . . . . . 11 = 2.3. Network Infrastructure . . . . . . . . . . . . . . . = . . . 11=09 2.3.1. Domain Name System (DNS) . . . . . . . . . . . . . . . 11 = 2.3.1. Domain Name System (DNS) . . . . . . . . . . . . = . . . 11=09 2.3.2. Network Management . . . . . . . . . . . . . . . . . . 11 = 2.3.2. Network Management . . . . . . . . . . . . . . . = . . . 11=09 3. Specific protocols . . . . . . . . . . . . . . . . . . . . . . 11 = 3. Specific protocols . . . . . . . . . . . . . . . . . . . = . . . 11=09 3.1. Security solutions . . . . . . . . . . . . . . . . . . . . 12 = 3.1. Security solutions . . . . . . . . . . . . . . . . . = . . . 12=09 3.1.1. Session identification, authentication, = 3.1.1. Session identification, authentication,=09 authorization, and accounting . . . . . . . . . . . . 12 = authorization, and accounting . . . . . . . . . = . . . 12=09 3.1.2. IP Security Architecture (IPsec) . . . . . . . . . . . 12 = 3.1.2. IP Security Architecture (IPsec) . . . . . . . . = . . . 12=09 3.1.3. Transport Layer Security (TLS) . . . . . . . . . . . . 12 = 3.1.3. Transport Layer Security (TLS) . . . . . . . . . = . . . 13=09 3.1.4. Secure/Multipurpose Internet Mail Extensions = 3.1.4. Secure/Multipurpose Internet Mail Extensions=09 (S/MIME) . . . . . . . . . . . . . . . . . . . . . . . 13 = (S/MIME) . . . . . . . . . . . . . . . . . . . . = . . . 14=09 3.2. Network Layer . . . . . . . . . . . . . . . . . . . . . . 13 = 3.2. Network Layer . . . . . . . . . . . . . . . . . . . = . . . 14=09 3.2.1. IPv4/IPv6 Coexistence Advice . . . . . . . . . . . . . 13 = 3.2.1. IPv4/IPv6 Coexistence Advice . . . . . . . . . . = . . . 14=09 3.2.1.1. Dual Stack Coexistence . . . . . . . . . . . . . . 14 = 3.2.1.1. Dual Stack Coexistence . . . . . . . . . . . = . . . 14=09 3.2.1.2. Tunneling Mechanism . . . . . . . . . . . . . . . 14 = 3.2.1.2. Tunneling Mechanism . . . . . . . . . . . . = . . . 15=09 3.2.1.3. Translation between IPv4 and IPv6 Networks . . . . 14 = 3.2.1.3. Translation between IPv4 and IPv6 Networks . = . . . 15=09 3.2.2. Internet Protocol Version 4 . . . . . . . . . . . . . 15 = 3.2.2. Internet Protocol Version 4 . . . . . . . . . . = . . . 16=09 3.2.2.1. IPv4 Address Allocation and Assignment . . . . . . 16 = 3.2.2.1. IPv4 Address Allocation and Assignment . . . = . . . 17=09 3.2.2.2. IPv4 Unicast Routing . . . . . . . . . . . . . . . 16 = 3.2.2.2. IPv4 Unicast Routing . . . . . . . . . . . . = . . . 17=09 3.2.2.3. IPv4 Multicast Forwarding and Routing . . . . . . 16 = 3.2.2.3. IPv4 Multicast Forwarding and Routing . . . = . . . 17=09 3.2.3. Internet Protocol Version 6 . . . . . . . . . . . . . 17 = 3.2.3. Internet Protocol Version 6 . . . . . . . . . . = . . . 18=09 3.2.3.1. IPv6 Address Allocation and Assignment . . . . . . 17 = 3.2.3.1. IPv6 Address Allocation and Assignment . . . = . . . 18=09 3.2.3.2. IPv6 Routing . . . . . . . . . . . . . . . . . . . 18 = 3.2.3.2. IPv6 Routing . . . . . . . . . . . . . . . . = . . . 19=09 3.2.4. Routing for IPv4 and IPv6 . . . . . . . . . . . . . . 18 = 3.2.4. Routing for IPv4 and IPv6 . . . . . . . . . . . = . . . 19=09 3.2.4.1. Routing Information Protocol . . . . . . . . . . . 18 = 3.2.4.1. Routing Information Protocol . . . . . . . . = . . . 19=09 3.2.4.2. Open Shortest Path First . . . . . . . . . . . . . 19 = 3.2.4.2. Open Shortest Path First . . . . . . . . . . = . . . 19=09 3.2.4.3. ISO Intermediate System to Intermediate System . . 19 = 3.2.4.3. ISO Intermediate System to Intermediate = System . . 20=09 3.2.4.4. Border Gateway Protocol . . . . . . . . . . . . . 19 = 3.2.4.4. Border Gateway Protocol . . . . . . . . . . = . . . 20=09 3.2.4.5. Dynamic MANET On-demand (DYMO) Routing . . . . . . 20 = 3.2.4.5. Dynamic MANET On-demand (DYMO) Routing . . . = . . . 20=09 3.2.4.6. Optimized Link State Routing Protocol . . . . . . 20 = 3.2.4.6. Optimized Link State Routing Protocol . . . = . . . 21=09 3.2.4.7. Routing for Low power and Lossy Networks . . . . . 20 = 3.2.4.7. Routing for Low power and Lossy Networks . . = . . . 21=09 3.2.5. IPv6 Multicast Forwarding and Routing . . . . . . . . 20 = 3.2.5. IPv6 Multicast Forwarding and Routing . . . . . = . . . 22=09 3.2.5.1. Protocol-Independent Multicast Routing . . . . . . 21 = 3.2.5.1. Protocol-Independent Multicast Routing . . . = . . . 22=09 3.2.6. Adaptation to lower layer networks and link layer = 3.2.6. Adaptation to lower layer networks and link layer=09= protocols . . . . . . . . . . . . . . . . . . . . . . 21 = protocols . . . . . . . . . . . . . . . . . . . = . . . 23=09 3.3. Transport Layer . . . . . . . . . . . . . . . . . . . . . 22 = 3.3. Transport Layer . . . . . . . . . . . . . . . . . . = . . . 23=09 3.3.1. User Datagram Protocol (UDP) . . . . . . . . . . . . . 22 = 3.3.1. User Datagram Protocol (UDP) . . . . . . . . . . = . . . 23=09 3.3.2. Transmission Control Protocol (TCP) . . . . . . . . . 22 = 3.3.2. Transmission Control Protocol (TCP) . . . . . . = . . . 24=09 3.3.3. Stream Control Transmission Protocol (SCTP) . . . . . 23 = 3.3.3. Stream Control Transmission Protocol (SCTP) . . = . . . 24=09 3.3.4. Datagram Congestion Control Protocol (DCCP) . . . . . 23 = 3.3.4. Datagram Congestion Control Protocol (DCCP) . . = . . . 25=09 3.4. Infrastructure . . . . . . . . . . . . . . . . . . . . . . 24 = 3.4. Infrastructure . . . . . . . . . . . . . . . . . . . = . . . 25=09 3.4.1. Domain Name System . . . . . . . . . . . . . . . . . . 24 = 3.4.1. Domain Name System . . . . . . . . . . . . . . . = . . . 25=09 3.4.2. Dynamic Host Configuration . . . . . . . . . . . . . . 24 = 3.4.2. Dynamic Host Configuration . . . . . . . . . . . = . . . 26=09 3.5. Service and Resource Discovery . . . . . . . . . . . . . . 24 = 3.4.3. Network Time . . . . . . . . . . . . . . . . . . = . . . 26=09 3.5.1. Service Discovery . . . . . . . . . . . . . . . . . . 24 = 3.5. Network Management . . . . . . . . . . . . . . . . . = . . . 26=09 3.5.2. Resource Discovery . . . . . . . . . . . . . . . . 25 = 3.5.1. Simple Network Management Protocol (SNMP) . . . = . . . 26=09 3.6. Other Applications . . . . . . . . . . . . . . . . . . . . 26 = 3.5.2. Network Configuration (NETCONF) Protocol . . . . = . . . 27=09 3.6.1. Network Time . . . . . . . . . . . . . . . . . . . . . 26 = 3.6. Service and Resource Discovery . . . . . . . . . . . = . . . 28=09 3.6.2. Session Initiation Protocol . . . . . . . . . . . . . 26 = 3.6.1. Service Discovery . . . . . . . . . . . . . . . = . . . 28=09 3.6.3. Calendaring . . . . . . . . . . . . . . . . . . . . . 27 = 3.6.2. Resource Discovery . . . . . . . . . . . . . . . = . . . 28=09 4. A simplified view of the business architecture . . . . . . . . 27 = 3.7. Other Applications . . . . . . . . . . . . . . . . . = . . . 29=09 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 = 3.7.1. Session Initiation Protocol . . . . . . . . . . = . . . 29=09 6. Security Considerations . . . . . . . . . . . . . . . . . . . 32 = 3.7.2. Calendaring . . . . . . . . . . . . . . . . . . = . . . 30=09 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 = 4. A simplified view of the business architecture . . . . . = . . . 30=09 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 = 5. IANA Considerations . . . . . . . . . . . . . . . . . . = . . . 34=09 8.1. Normative References . . . . . . . . . . . . . . . . . . . 32 = 6. Security Considerations . . . . . . . . . . . . . . . . = . . . 35=09 8.2. Informative References . . . . . . . . . . . . . . . . . . 32 = 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . = . . . 35=09 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 = 8. References . . . . . . . . . . . . . . . . . . . . . . . = . . . 35=09 8.1. Normative References . . . . . . . . . . . . . . . . = . . . 35=09 8.2. Informative References . . . . . . . . . . . . . . . = . . . 35=09 Appendix A. Example: Advanced Metering Infrastructure . . . = . . . 49=09 A.1. How to structure a network . . . . . . . . . . . . . = . . . 51=09 A.1.1. HAN Routing . . . . . . . . . . . . . . . . . . = . . . 53=09 A.1.2. HAN Security . . . . . . . . . . . . . . . . . . = . . . 53=09 A.2. Model 1: AMI with separated domains . . . . . . . . = . . . 54=09 A.3. Model 2: AMI with neighborhood access to the home . = . . . 55=09 A.4. Model 3: Collector is an IP router . . . . . . . . . = . . . 56=09 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . = . . . 57=09 =09 1. Introduction 1. Introduction=09 =09 This document provides Smart Grid designers with advice on how to = This document provides Smart Grid designers with advice on = how to=09 best "profile" the Internet Protocol Suite (IPS) for use on with = best "profile" the Internet Protocol Suite (IPS) for use on = with=09 Smart Grids. It provides an overview of the IPS and the key = Smart Grids. It provides an overview of the IPS and the key=09 protocols that are critical in integrating Smart Grid devices into an = protocols that are critical in integrating Smart Grid devices = into an=09 IP-based infrastructure. IP-based infrastructure.=09 =09 The IPS provides options for several key architectural components. = The IPS provides options for several key architectural = components.=09 =09 skipping to change at page 4, line 45 skipping to change at = page 4, line 45=09 =09 o IPv6 Node Requirements [RFC4294], o IPv6 Node = Requirements [RFC4294],=09 =09 At this writing, RFC 4294 is in the process of being updated, in = At this writing, RFC 4294 is in the process of being updated, = in=09 [I-D.ietf-6man-node-req-bis]. = [I-D.ietf-6man-node-req-bis].=09 =09 This document is intended to provide Smart Grid architects and = This document is intended to provide Smart Grid architects = and=09 designers with a compendium of relevant RFCs (and to some extent = designers with a compendium of relevant RFCs (and to some = extent=09 Internet Drafts), and is organized as an annotated list of RFCs. To = Internet Drafts), and is organized as an annotated list of = RFCs. To=09 that end, the remainder of this document is organized as follows: = that end, the remainder of this document is organized as = follows:=09 Section 2 describes the Internet Architecture and its protocol suite. = = =09 Section 3 outlines the set of protocols that will be useful in Smart = o Section 2 describes the Internet Architecture and its = protocol=09 Grid deployment. Finally, Section 4 provides an overview of the = suite.=09 business architecture embodied in the design and deployment of the = = =09 IPS. o Section 3 outlines the set of protocols that will = be useful in=09 Smart Grid deployment.=09 = =09 o Finally, Section 4 provides an overview of the business=09 architecture embodied in the design and deployment of the = IPS.=09 =09 2. The Internet Protocol Suite 2. The Internet Protocol Suite=09= =09 Before enumerating the list of Internet protocols relevant to Smart = Before enumerating the list of Internet protocols relevant to = Smart=09 Grid, we discuss the layered architecture of the IPS, the functions = Grid, we discuss the layered architecture of the IPS, the = functions=09 of the various layers, and their associated protocols. = of the various layers, and their associated protocols.=09 =09 2.1. Internet Protocol Layers 2.1. Internet Protocol Layers=09= =09 While Internet architecture uses the definitions and language similar = While Internet architecture uses the definitions and language = similar=09 =09 skipping to change at page 8, line 49 skipping to change at = page 8, line 49=09 At the lowest layer of the IP architecture, data is encoded in = At the lowest layer of the IP architecture, data is encoded = in=09 messages and transmitted over the physical media. While the IETF = messages and transmitted over the physical media. While the = IETF=09 specifies algorithms for carrying IPv4 and IPv6 various media types, = specifies algorithms for carrying IPv4 and IPv6 various media = types,=09 it rarely actually defines the media - it happily uses specifications = it rarely actually defines the media - it happily uses = specifications=09 from IEEE, ITU, and other sources. from IEEE, ITU, and = other sources.=09 =09 2.2. Security issues 2.2. Security issues=09 =09 While it is popular to complain about the security of the Internet, = While it is popular to complain about the security of the = Internet,=09 solutions to many Internet security problems already exist but have = solutions to many Internet security problems already exist = but have=09 not been widely deployed. Internet security solutions attempt to = either not been widely deployed, may impact critical = performance=09 mitigate a set of known threats at a specified cost; addressing = criteria, or require security measures outside the IPS. = Internet=09 security issues requires first a threat analysis and assessment and a = security solutions attempt to mitigate a set of known threats = within=09 set of mitigations appropriate to the threats. Since we have threats = the IPS domain at a specified cost; addressing security = issues=09 at every layer, we should expect to find mitigations at every layer. = requires first a threat analysis and assessment and a set of=09= mitigations appropriate to the threats. Since we have = threats at=09 every layer, we should expect to find mitigations at every = layer.=09 =09 2.2.1. Physical security 2.2.1. Physical security=09 =09 At the physical and data link layers, threats generally center on = At the physical and data link layers, threats generally = center on=09 physical attacks on the network - the effects of backhoes, = physical attacks on the network - the effects of backhoes,=09 deterioration of physical media, and various kinds of environmental = deterioration of physical media, and various kinds of = environmental=09 noise. Radio-based networks are subject to signal fade due to = noise. Radio-based networks are subject to signal fade due = to=09 distance, interference, and environmental factors; it is widely noted = distance, interference, and environmental factors; it is = widely noted=09 that IEEE 802.15.4 networks frequently place a metal ground plate = that IEEE 802.15.4 networks frequently place a metal ground = plate=09 between the meter and the device that manages it. Fiber was at one = between the meter and the device that manages it. Fiber was = at one=09 =09 skipping to change at page 9, line 26 skipping to change at = page 9, line 28=09 learned to tap it by bending the fiber and collecting incidental = learned to tap it by bending the fiber and collecting = incidental=09 light, and we have learned about backhoes. As a result, some = light, and we have learned about backhoes. As a result, some=09= installations encase fiber optic cable in a pressurized sheath, both = installations encase fiber optic cable in a pressurized = sheath, both=09 to quickly identify the location of a cut and to make it more = to quickly identify the location of a cut and to make it more=09= difficult to tap. difficult to tap.=09 =09 While there are protocol behaviors that can detect certain classes of = While there are protocol behaviors that can detect certain = classes of=09 physical faults, such as keep-alive exchanges, physical security is = physical faults, such as keep-alive exchanges, physical = security is=09 generally not considered to be a protocol problem. = generally not considered to be a protocol problem.=09 =09 2.2.2. Session identification 2.2.2. Session Authentication=09= =09 At the transport and application layers and in lower layer networks = At the transport and application layers and in lower layer = networks=09 where dynamic connectivity such as ATM Switched Virtual Circuits = where dynamic connectivity such as ATM Switched Virtual = Circuits=09 (SVCs) or "dial" connectivity are in use, there tend to be several = (SVCs) or "dial" connectivity are in use, there tend to be = several=09 different classes of authentication/authorization requirements. The = different classes of authentication/authorization = requirements. The=09 basic requirements that must be satisfied are: basic = requirements that must be satisfied are:=09 =09 1. Verify that peers are appropriate partners; this generally means = 1. Verify that peers are appropriate partners; this = generally means=09 knowing "who" they are and that they have a "need to know" or are = knowing "who" they are and that they have a "need to = know" or are=09 trusted sources. trusted sources.=09 =09 skipping to change at page 10, line 9 skipping to change at = page 10, line 11=09 against modification attacks. against = modification attacks.=09 =09 In other words, both the communications channel itself and message = In other words, both the communications channel itself and = message=09 exchanges (both by knowing the source of the information and to have = exchanges (both by knowing the source of the information and = to have=09 proof of its validity) must be secured. Three examples suffice to = proof of its validity) must be secured. Three examples = suffice to=09 illustrate the challenges. illustrate the challenges.=09 =09 One common attack against a TCP session is to bombard the session = One common attack against a TCP session is to bombard the = session=09 with reset messages. Other attacks against TCP include the "SYN = with reset messages. Other attacks against TCP include the = "SYN=09 flooding" attack, in which an attacker attempts to exhaust the memory = flooding" attack, in which an attacker attempts to exhaust = the memory=09 of the target by creating TCP state. Experience has shown that by = of the target by creating TCP state. In particular, the = attacker=09 including information in the transport header or a related protocol = attempts to exhaust the target's memory by opening a large = number of=09 like the IPsec (Section 3.1.2) or TLS (Section 3.1.3), a host can = unique TCP connections, each of which is represented by a=09 identify legitimate messages and discard mitigate any damage that may = Transmission Control Block (TCB). The attack is successful = if the=09 have been caused by the attack. attacker can cause = the target to fill its memory with TCBs.=09 Experience has shown that by including information in the = transport=09 header or a related protocol like the IPsec (Section 3.1.2) = or TLS=09 (Section 3.1.3), a host can identify legitimate messages and = discard=09 the others, thus mitigating any damage that may have been = caused by=09 the attack.=09 =09 Another common attack involves unauthorized communication with a = Another common attack involves unauthorized communication = with a=09 router or a service. For example, an unauthorized party might try to = router or a service. For example, an unauthorized party = might try to=09 join the routing system. To protect against such attacks, an = join the routing system. To protect against such attacks, an=09= Internet Service Provider (ISP) should not accept information from = Internet Service Provider (ISP) should not accept information = from=09 new peers without verifying that the peer is who it claims to be and = new peers without verifying that the peer is who it claims to = be and=09 that the peer is authorized to carry on the exchange of information. = that the peer is authorized to carry on the exchange of = information.=09 =09 More generally, in order to secure a communications channel, it must = More generally, in order to secure a communications channel, = it must=09 be possible to verify that messages putatively received from a peer = be possible to verify that messages putatively received from = a peer=09 =09 skipping to change at page 11, line 7 skipping to change at = page 11, line 11=09 there frequently a requirement for confidentiality. Confidentiality = there frequently a requirement for confidentiality. = Confidentiality=09 arises at several layers, sometimes simultaneously. For example, = arises at several layers, sometimes simultaneously. For = example,=09 providers of credit card transaction services want application layer = providers of credit card transaction services want = application layer=09 privacy, which can be supplied by encrypting application data or by = privacy, which can be supplied by encrypting application data = or by=09 an encrypted transport layer. If an ISP (or other entity) wants to = an encrypted transport layer. If an ISP (or other entity) = wants to=09 hide its network structure, it can to encrypt the network layer = hide its network structure, it can to encrypt the network = layer=09 header. header.=09 =09 2.3. Network Infrastructure 2.3. Network Infrastructure=09 =09 While these are not critical to the design of a specific system, they = While the following protocols are not critical to the design = of a=09 are important to running a network, and as such are surveyed here. = specific system, they are important to running a network, and = as such=09 are surveyed here.=09 =09 2.3.1. Domain Name System (DNS) 2.3.1. Domain Name = System (DNS)=09 =09 The DNS' main function is translating names to numeric IP addresses. = The DNS' main function is translating names to numeric IP = addresses.=09 While this is not critical to running a network, certain functions = While this is not critical to running a network, certain = functions=09 are made a lot easier if numeric addresses can be replaced with = are made a lot easier if numeric addresses can be replaced = with=09 mnemonic names. This facilitates renumbering of networks and = mnemonic names. This facilitates renumbering of networks and=09= generally improves the manageability and serviceability of the = generally improves the manageability and serviceability of = the=09 network. DNS has a set of security extensions called DNSSEC, which = network. DNS has a set of security extensions called DNSSEC, = which=09 can be used to provide strong cryptographic authentication to that = can be used to provide strong cryptographic authentication to = the=09 protocol. DNS and DNSSEC are discussed further in Section 3.4.1. = DNS. DNS and DNSSEC are discussed further in Section 3.4.1.=09= =09 2.3.2. Network Management 2.3.2. Network Management=09 =09 Network management has proven to be a difficult problem. As such, = Network management has proven to be a difficult problem. As = such,=09 various solutions have been proposed, implemented, and deployed. = various solutions have been proposed, implemented, and = deployed.=09 Each solution has its proponents, all of whom have solid arguments = Each solution has its proponents, all of whom have solid = arguments=09 for their viewpoints. The IETF has two major network management = for their viewpoints. The IETF has two major network = management=09 solutions for device operation: SNMP, which is ASN.1-encoded and is = solutions for device operation: SNMP, which is ASN.1-encoded = and is=09 primarily used for monitoring of system variables and is a polled = primarily used for monitoring of system variables and is a = polled=09 architecture, and NetConf [RFC4741], which is XML-encoded and = architecture, and NetConf [RFC4741], which is XML-encoded and=09= =09 skipping to change at page 11, line 47 skipping to change at = page 12, line 5=09 While the IP Protocol Suite does not have specific solutions for = While the IP Protocol Suite does not have specific solutions = for=09 secure provisioning and configuration, these problems have been = secure provisioning and configuration, these problems have = been=09 solved using IP protocols in specifications such as DOCSIS 3.0 = solved using IP protocols in specifications such as DOCSIS = 3.0=09 [SP-MULPIv3.0]. [SP-MULPIv3.0].=09 =09 3. Specific protocols 3. Specific protocols=09 =09 In this section, having briefly laid out the IP architecture and some = In this section, having briefly laid out the IP architecture = and some=09 of the problems that the architecture tries to address, we introduce = of the problems that the architecture tries to address, we = introduce=09 specific protocols that might be appropriate to various Smart Grid = specific protocols that might be appropriate to various Smart = Grid=09 use cases. Use cases should be analyzed along privacy, AAA, = use cases. Use cases should be analyzed along privacy,=09 transport and network solution dimensions. The following sections = Authentication, Authorization, and Accounting (AAA), = transport and=09 provide guidance for such analyzes. network solution = dimensions. The following sections provide guidance=09 for such analyzes.=09 =09 3.1. Security solutions 3.1. Security solutions=09 =09 As noted, a key consideration in security solutions is a good threat = As noted, a key consideration in security solutions is a good = threat=09 analysis coupled with appropriate mitigation strategies at each = analysis coupled with appropriate mitigation strategies at = each=09 layer. The following sections outline the security features of the = layer. The following sections outline the security features = of the=09 IPS. IPS.=09 =09 3.1.1. Session identification, authentication, authorization, and = 3.1.1. Session identification, authentication, authorization, = and=09 accounting accounting=09 =09 skipping to change at page 12, line 34 skipping to change at = page 12, line 39=09 =09 The Security Architecture for the Internet Protocol (IPsec) [RFC4301] = The Security Architecture for the Internet Protocol (IPsec) = [RFC4301]=09 is a set of control and data protocols that are implemented between = is a set of control and data protocols that are implemented = between=09 IPv4 and the chosen transport layer, or in IPv6's security extension = IPv4 and the chosen transport layer, or in IPv6's security = extension=09 header. It allows transport layer sessions to communicate in a way = header. It allows transport layer sessions to communicate in = a way=09 that is designed to prevent eavesdropping, tampering, or message = that is designed to prevent eavesdropping, tampering, or = message=09 forgery. As is typical with IETF specifications, the architecture is = forgery. As is typical with IETF specifications, the = architecture is=09 spelled out in a number of documents which specify the specific = spelled out in a number of documents which specify the = specific=09 components: the IP Authentication Header (AH) [RFC4302] Encapsulating = components: the IP Authentication Header (AH) [RFC4302] = Encapsulating=09 Security Payload (ESP) [RFC4303], Internet Key Exchange (IKEv2) = Security Payload (ESP) [RFC4303], Internet Key Exchange = (IKEv2)=09 [RFC4306], Cryptographic Algorithms [RFC4307], Cryptographic = [RFC5996], Cryptographic Algorithms [RFC4307], Cryptographic=09 Algorithm Implementation Requirements for ESP and AH [RFC4835], and = Algorithm Implementation Requirements for ESP and AH = [RFC4835], and=09 the use of Advanced Encryption Standard (AES) [RFC4309]. = the use of Advanced Encryption Standard (AES) [RFC4309].=09 =09 IPsec provides two modes: Transport mode and tunnel mode. In = IPsec provides two modes: Transport mode and tunnel mode. In=09= transport mode, IPsec ESP encrypts the transport layer and the = transport mode, IPsec ESP encrypts the transport layer and = the=09 application data. In tunnel mode, the source IP datagram is = application data. In tunnel mode, the source IP datagram is=09 encrypted and encapsulated in a second IP header addressed to the = encrypted and encapsulated in a second IP header addressed to = the=09 intended decryptor. As might be expected, tunnel mode is frequently = intended decryptor. As might be expected, tunnel mode is = frequently=09 used for virtual private networks which need to securely transmit = used for virtual private networks which need to securely = transmit=09 data across networks with unknown (or no) other security properties. = data across networks with unknown (or no) other security = properties.=09 In both cases, authentication, authorization, and confidentiality = In both cases, authentication, authorization, and = confidentiality=09 extend from system to system, and apply to all applications that the = extend from system to system, and apply to all applications = that the=09 two systems use. two systems use.=09 =09 Note that IPsec can provide non-repudiation when an = asymmetric=09 authentication algorithm is used with the AH header and both = sender=09 and receiver keys are used in the authentication calculation.=09= However, the default authentication algorithm is keyed MD5, = which=09 like all symmetric algorithms cannot provide non-repudiation = by=09 itself (since the sender's key is not used in the = computation). So=09 while IPsec provides a means of authenticating network level = objects=09 (packets), these objects are are ephemeral and not directly=09= correlated with a particular application. As a result non-=09= repudiation is not generally applicable to network level = objects such=09 as packets.=09 = =09 3.1.3. Transport Layer Security (TLS) 3.1.3. Transport Layer = Security (TLS)=09 =09 Transport Layer Security [RFC5246] and Datagram Transport Layer = Transport Layer Security [RFC5246] and Datagram Transport = Layer=09 Security [RFC4347][I-D.ietf-tls-rfc4347-bis] are mechanisms that = Security [RFC4347][I-D.ietf-tls-rfc4347-bis] are mechanisms = that=09 travel within the transport layer protocol data unit, meaning that = travel within the transport layer protocol data unit, meaning = that=09 they readily traverse network address translators and secure the = they readily traverse network address translators and secure = the=09 information exchanges without securing the datagrams exchanged or the = information exchanges without securing the datagrams = exchanged or the=09 transport layer itself. Each allows client/server applications to = transport layer itself. Each allows client/server = applications to=09 communicate in a way that is designed to prevent eavesdropping, = communicate in a way that is designed to prevent = eavesdropping,=09 tampering, or message forgery. Authentication, authorization, and = tampering, or message forgery. Authentication, = authorization, and=09 confidentiality exist for a session between specific applications. = confidentiality exist for a session between specific = applications.=09 =09 When used in conjunction with IEEE 802.1X [IEEE802.1X], EAP-TLS = In order to communicate securely, an TLS client and TLS = server must=09 [RFC5216] is widely considered to offer excellent access security to = agree on the cryptographic algorithms and keys that they will = use on=09 a wired or wireless IEEE 802 LAN (IEEE 802.1X in conjunction with = the secured connection. In particular, they must agree on = these=09 EAP-TLS is the baseline for Zigbee SEP 2.0). Note that one potential = items:=09 drawback of 802.1X technology is that it requires deployment of = =09 client-side certificates, which is frequently seen as a deployment = o Key Establishment Algorithm=09 barrier. =09 o Peer Authentication Algorithm=09 =09 o Bulk Data Encryption Algorithm and key size=09 =09 o Digest Algorithm=09 =09 Since each categories has multiple options, the number of = possible=09 combinations is large. As a result, TLS does not allow all = possible=09 combinations of choices; rather it only allows certain = well-defined=09 combinations known as Cipher Suites. [IEC62351-3] outlines = the use=09 of different TLS Cipher Suites for use in the Smart Grid.=09 = =09 When used in conjunction with IEEE 802.1X [IEEE802.1X], both = EAP-TLS=09 [RFC5216] and the Protocol for Carrying Authentication for = Network=09 Access (PANA) [RFC5193] are widely considered to offer = excellent=09 access security to a wired or wireless IEEE 802 LAN (IEEE = 802.1X in=09 conjunction with EAP-TLS is the baseline for Zigbee SEP 2.0).=09= =09 3.1.4. Secure/Multipurpose Internet Mail Extensions (S/MIME) = 3.1.4. Secure/Multipurpose Internet Mail Extensions (S/MIME)=09 =09 The S/MIME [RFC2045] [RFC2046] [RFC2047] [RFC4289] [RFC2049] = The S/MIME [RFC2045] [RFC2046] [RFC2047] [RFC4289] [RFC2049]=09 [RFC5750] [RFC5751] [RFC4262] specification was originally designed = [RFC5750] [RFC5751] [RFC4262] specification was originally = designed=09 as an extension to SMTP Mail to provide evidence that the putative = as an extension to SMTP Mail to provide evidence that the = putative=09 sender of an email message in fact sent it, and that the content = sender of an email message in fact sent it, and that the = content=09 received was in fact the content that was sent. As its name = received was in fact the content that was sent. As its name=09 suggests, by extension this is a way of securing any object that can = suggests, by extension this is a way of securing any object = that can=09 be exchanged, by any means, and has become one of the most common = be exchanged, by any means, and has become one of the most = common=09 =09 skipping to change at page 15, line 19 skipping to change at = page 16, line 6=09 [I-D.ietf-behave-address-format] = [I-D.ietf-behave-address-format]=09 =09 o DNS extensions [I-D.ietf-behave-dns64] o DNS = extensions [I-D.ietf-behave-dns64]=09 =09 o IP/ICMP Translation Algorithm [I-D.ietf-behave-v6v4-xlate] = o IP/ICMP Translation Algorithm [I-D.ietf-behave-v6v4-xlate]=09= =09 o Translation from IPv6 Clients to IPv4 Servers o = Translation from IPv6 Clients to IPv4 Servers=09 [I-D.ietf-behave-v6v4-xlate-stateful] = [I-D.ietf-behave-v6v4-xlate-stateful]=09 =09 As with IPv4/IPv4 Network Address Translation, translation between = As with IPv4/IPv4 Network Address Translation, translation = between=09 IPv4 and IPv6 has limited real world applicability: any application = IPv4 and IPv6 has limited real world applicability for an = application=09 protocol that carries IP addresses and expects them to be meaningful = protocol which carry IP addresses in its payload and expects = those=09 to both client and server or to both peers will have trouble when the = addresses to be meaningful to both client and server. = However, for=09 addresses are transparently translated. However, for those protocols = those protocols that do not, protocol translation can provide = a=09 that do not, protocol translation can provide a useful network = useful network extension.=09 extension. =09 =09 Network-based translation provides for two types of services: = Network-based translation provides for two types of services:=09= stateless (and therefore scalable and load-sharable) translation = stateless (and therefore scalable and load-sharable) = translation=09 between IPv4 and IPv6 addresses that embed an IPv4 address in them, = between IPv4 and IPv6 addresses that embed an IPv4 address in = them,=09 and stateful translation similar to IPv4/IPv4 translation between = and stateful translation similar to IPv4/IPv4 translation = between=09 IPv4 addresses. The stateless mode is straightforward to implement, = IPv4 addresses. The stateless mode is straightforward to = implement,=09 but due to the embedding, requires IPv4 addresses to be allocated to = but due to the embedding, requires IPv4 addresses to be = allocated to=09 an otherwise IPv6-only network, and is primarily useful for IPv4- = an otherwise IPv6-only network, and is primarily useful for = IPv4-=09 accessible servers implemented in the IPv6 network. The stateful = accessible servers implemented in the IPv6 network. The = stateful=09 mode allows clients in the IPv6 network to access servers in the IPv4 = mode allows clients in the IPv6 network to access servers in = the IPv4=09 network, but does not provide such service for IPv4 clients accessing = network, but does not provide such service for IPv4 clients = accessing=09 IPv6 peers or servers with general addresses; it does however have = IPv6 peers or servers with general addresses; it does however = have=09 the advantage that it does not require that a unique IPv4 address be = the advantage that it does not require that a unique IPv4 = address be=09 embedded in the IPv6 address of hosts using this mechanism. = embedded in the IPv6 address of hosts using this mechanism.=09 =09 Finally, note that some networks site networks are IPv6 only = while=09 some transits networks are IPv4 only. In these cases it may = be=09 necessary to tunnel IPv6 over IPv4 or translate between IPv6 = and=09 IPv4.=09 = =09 3.2.2. Internet Protocol Version 4 3.2.2. Internet = Protocol Version 4=09 =09 IPv4 [RFC0791] and the Internet Control Message Protocol [RFC0792] = IPv4 [RFC0791] and the Internet Control Message Protocol = [RFC0792]=09 comprise the IPv4 network layer. IPv4 provides unreliable delivery = comprise the IPv4 network layer. IPv4 provides unreliable = delivery=09 of datagrams. of datagrams.=09 =09 IPv4 also provides for fragmentation and reassembly of long datagrams = IPv4 also provides for fragmentation and reassembly of long = datagrams=09 for transmission through networks with small Maximum Transmission = for transmission through networks with small Maximum = Transmission=09 Units (MTU). The MTU is the largest packet size that can be = Units (MTU). The MTU is the largest packet size that can be=09 delivered across the network. In addition, the IPS provides the = delivered across the network. In addition, the IPS provides = the=09 =09 skipping to change at page 16, line 15 skipping to change at = page 17, line 6=09 IPv4 originally supported an experimental type of service field that = IPv4 originally supported an experimental type of service = field that=09 identified eight levels of operational precedence styled after the = identified eight levels of operational precedence styled = after the=09 requirements of military telephony, plus three and later four bit = requirements of military telephony, plus three and later four = bit=09 flags that OSI IS-IS for IPv4 (IS-IS) [RFC1195] and OSPF Version 2 = flags that OSI IS-IS for IPv4 (IS-IS) [RFC1195] and OSPF = Version 2=09 [RFC2328] interpreted as control traffic; this control traffic is = [RFC2328] interpreted as control traffic; this control = traffic is=09 assured of not being dropped when queued or upon receipt even if = assured of not being dropped when queued or upon receipt even = if=09 other traffic is being dropped.. These control bits turned out to be = other traffic is being dropped.. These control bits turned = out to be=09 less useful than the designers had hoped. They were replaced by the = less useful than the designers had hoped. They were replaced = by the=09 Differentiated Services Architecture [RFC2474][RFC2475], which = Differentiated Services Architecture [RFC2474][RFC2475], = which=09 contains a six bit code point used to select an algorithm (a "per-hop = contains a six bit code point used to select an algorithm (a = "per-hop=09 behavior") to be applied to the datagram. behavior") to = be applied to the datagram. The IETF has also produced=09 a set of Configuration Guidelines for DiffServ Service = Classes=09 [RFC4594], which describes a set of service classes that may = be=09 useful to a network operator.=09 =09 3.2.2.1. IPv4 Address Allocation and Assignment 3.2.2.1. = IPv4 Address Allocation and Assignment=09 =09 IPv4 addresses are administratively assigned, usually using automated = IPv4 addresses are administratively assigned, usually using = automated=09 methods, and assigned using the Dynamic Host Configuration Protocol = methods, and assigned using the Dynamic Host Configuration = Protocol=09 (DHCP) [RFC2131]. On most interface types, neighboring equipment = (DHCP) [RFC2131]. On most interface types, neighboring = equipment=09 identify each other's addresses using Address Resolution Protocol = identify each other's addresses using Address Resolution = Protocol=09 (ARP) [RFC0826]. (ARP) [RFC0826].=09 =09 3.2.2.2. IPv4 Unicast Routing 3.2.2.2. IPv4 Unicast Routing=09= =09 skipping to change at page 20, line 41 skipping to change at = page 21, line 32=09 can be used in other forms of ad hoc networks. It provides arbitrary = can be used in other forms of ad hoc networks. It provides = arbitrary=09 connectivity between device within a distributed subnet. As with = connectivity between device within a distributed subnet. As = with=09 protocols designed for wired networks, routing is calculated and = protocols designed for wired networks, routing is calculated = and=09 maintained whenever changes are detected, and maintained in each = maintained whenever changes are detected, and maintained in = each=09 router's tables. The set of nodes that operate as routers within the = router's tables. The set of nodes that operate as routers = within the=09 subnet, however, are fairly fluid, and dependent on this = subnet, however, are fairly fluid, and dependent on this=09 instantaneous topology of the subnet. instantaneous = topology of the subnet.=09 =09 3.2.4.7. Routing for Low power and Lossy Networks 3.2.4.7. = Routing for Low power and Lossy Networks=09 =09 The RPL: IPv6 Routing Protocol for Low power and Lossy Networks = The IPv6 Routing Protocol for Low power and Lossy Networks = (RPL)=09 [I-D.ietf-roll-rpl] xxx [I-D.ietf-roll-rpl] is a = reactive routing protocol designed for use=09 in resource constrained networks. Requirements for resource=09= constrained networks are defined in [RFC5548], [RFC5673], = [RFC5826],=09 and [RFC5867].=09 =09 Briefly, a constrained network is comprised of nodes that:=09 =09 o Are built with limited processing power and memory, and = sometimes=09 energy when operating on batteries.=09 =09 o Are interconnected through a low-data-rate network = interface and=09 potentially vulnerable to communication instability and = low packet=09 delivery rates.=09 =09 o Potentially have a mix of roles such as being able to act = as a=09 host (i.e., generating traffic) and/or a router (i.e., = both=09 forwarding and generating RPL traffic).=09 =09 3.2.5. IPv6 Multicast Forwarding and Routing 3.2.5. IPv6 = Multicast Forwarding and Routing=09 =09 IPv6 specifies both unicast and multicast datagram exchange. This = IPv6 specifies both unicast and multicast datagram exchange. = This=09 uses the Multicast Listener Discovery Protocol (MLDv2) [RFC2710] = uses the Multicast Listener Discovery Protocol (MLDv2) = [RFC2710]=09 [RFC3590] [RFC3810] [RFC4604] to enable applications to join = [RFC3590] [RFC3810] [RFC4604] to enable applications to join=09 multicast groups, and for most applications uses Source-Specific = multicast groups, and for most applications uses = Source-Specific=09 Multicast [RFC4607] for routing and delivery of multicast messages. = Multicast [RFC4607] for routing and delivery of multicast = messages.=09 =09 The mechanisms experimentally developed for reliable multicast in = The mechanisms experimentally developed for reliable = multicast in=09 IPv4, discussed in Section 3.2.2.3, can be used in IPv6 as well. = IPv4, discussed in Section 3.2.2.3, can be used in IPv6 as = well.=09 =09 3.2.5.1. Protocol-Independent Multicast Routing 3.2.5.1. = Protocol-Independent Multicast Routing=09 =09 xxx Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol = A multicast routing protocol has two basic functions: = Building the=09 Specification (Revised) [RFC3973] xxx Protocol Independent Multicast = multicast distribution tree and forwarding multicast traffic.=09= Multicast routing protocols generally contain a control plane = for=09 building distribution trees, and a forwarding plane that uses = the=09 distribution tree when forwarding multicast traffic.=09 =09 A the highest level, the multicast model works as follows: = hosts=09 express their interest in receiving multicast traffic from a = source=09 by sending a Join message to their first hop router. That = router in=09 turn sends a Join message upstream towards the root of the = tree,=09 grafting the router (leaf node) onto the distribution tree = for the=09 group. Data is delivered down the tree toward the leaf = nodes, which=09 forward it onto the local network for delivery.=09 =09 The initial multicast model deployed in the Internet was = known as=09 Any-Source Multicast (ASM). In the ASM model any host could = send to=09 the group, and inter-domain multicast was difficult. = Protocols such=09 as Protocol Independent Multicast - Dense Mode (PIM-DM): = Protocol=09 Specification (Revised) [RFC3973] and Protocol Independent = Multicast=09 - Sparse Mode (PIM-SM): Protocol Specification (Revised) [RFC4601] = - Sparse Mode (PIM-SM): Protocol Specification (Revised) = [RFC4601]=09 xxx Source-Specific Multicast (SSM) [RFC3569] xxx Source-Specific = were designed for the ASM model.=09 Protocol Independent Multicast [RFC4608] xxx Authentication and = =09 Confidentiality in Protocol Independent Multicast Sparse Mode = Many modern multicast deployments use Source-Specific = Multicast (PIM-=09 (PIM-SM) Link-Local Messages [RFC5796] xxx SSM) = [RFC3569][RFC4608]. In the SSM model, a host expresses interest=09 in a "channel", which is comprised of a source (S) and a = group (G).=09 Distribution tress are rooted the sending host (called an = "(S,G)=09 tree"). Since only the source S can send on to the group, = SSM has=09 inherent anti-jamming capability. In addition, inter-domain=09= multicast is simplified since it is the responsibility of the=09= receivers (rather than the network) to find the (S,G) channel = they=09 are interested in receiving. This implies that SSM requires = some=09 form of directory service so that receivers can find the = (S,G)=09 channels.=09 =09 3.2.6. Adaptation to lower layer networks and link layer protocols = 3.2.6. Adaptation to lower layer networks and link layer = protocols=09 =09 In general, the layered architecture of the Internet enables the IPS = In general, the layered architecture of the Internet enables = the IPS=09 to run over any appropriate layer two architecture. The ability to = to run over any appropriate layer two architecture. The = ability to=09 change the link or physical layer without having to rethink the = change the link or physical layer without having to rethink = the=09 network layer, transports, or applications has been a great benefit = network layer, transports, or applications has been a great = benefit=09 in the Internet. in the Internet.=09 =09 Examples of link layer adaptation technology include: = Examples of link layer adaptation technology include:=09 =09 skipping to change at page 24, line 40 skipping to change at = page 26, line 25=09 [RFC2131] or DHCPv6 [RFC3315]. The best argument for the use of = [RFC2131] or DHCPv6 [RFC3315]. The best argument for the use = of=09 autoconfiguration is a large number of systems that require little = autoconfiguration is a large number of systems that require = little=09 more than a random number as an address; the argument for DHCP is = more than a random number as an address; the argument for = DHCP is=09 administrative control. administrative control.=09 =09 There are other parameters that may need to be allocated to hosts = There are other parameters that may need to be allocated to = hosts=09 which require administrative configuration; examples include the = which require administrative configuration; examples include = the=09 addresses of DNS servers, keys for Secure DNS and Network Time = addresses of DNS servers, keys for Secure DNS and Network = Time=09 servers. servers.=09 =09 3.5. Service and Resource Discovery 3.4.3. Network Time=09 =09 The Network Time Protocol was originally designed by Dave = Mills of=09 the University of Delaware and CSNET, for the purpose of = implementing=09 a temporal metric in the Fuzzball Routing Protocol and = generally=09 coordinating time experiments. The current versions of the = time=09 protocol are the Network Time Protocol [RFC5905].=09 = =09 3.5. Network Management=09 =09 The IETF has developed two protocols for network management: = SNMP and=09 NETCONF. SNMP is discussed in Section 3.5.1, and NETCONF is=09= discussed in Section 3.5.2.=09 =09 3.5.1. Simple Network Management Protocol (SNMP)=09 =09 The Simple Network Management Protocol, originally specified = in the=09 late 1980's and having passed through several revisions, is = specified=09 in several documents:=09 =09 o An Architecture for Describing Simple Network Management = Protocol=09 (SNMP) Management Frameworks [RFC3411]=09 =09 o Message Processing and Dispatching [RFC3412]=09 =09 o SNMP Applications [RFC3413]=09 o User-based Security Model (USM) for SNMP version 3 = [RFC3414]=09 =09 o View-based Access Control Model (VACM) [RFC3415]=09 =09 o Version 2 of the SNMP Protocol Operations [RFC3416]=09 =09 o Transport Mappings [RFC3417]=09 =09 o Management Information Base (MIB) [RFC3418]=09 =09 It provides capabilities for polled and event-driven = activities, and=09 for both monitoring and configuration of systems in the = field.=09 Historically, it has been used primarily for monitoring nodes = in a=09 network. Messages and their constituent data are encoded = using a=09 profile of ASN.1.=09 =09 3.5.2. Network Configuration (NETCONF) Protocol=09 =09 The NETCONF Configuration Protocol is specified in one basic=09= document, with supporting documents for carrying it over the = IPS.=09 These documents include:=09 =09 o NETCONF Configuration Protocol [RFC4741]=09 =09 o Using the NETCONF Configuration Protocol over Secure SHell = (SSH)=09 [RFC4742]=09 =09 o Using NETCONF over the Simple Object Access Protocol = (SOAP)=09 [RFC4743]=09 =09 o Using the NETCONF Protocol over the Blocks Extensible = Exchange=09 Protocol (BEEP) [RFC4744]=09 =09 o NETCONF Event Notifications [RFC5277]=09 =09 o NETCONF over Transport Layer Security (TLS) [RFC5539]=09 =09 o Partial Lock Remote Procedure Call (RPC) for NETCONF = [RFC5717]=09 =09 NETCONF was developed in response to operator requests for a = common=09 configuration protocol based on ASCII text as opposed to = ASN.1. In=09 essence, it carries XML-encoded remote procedure call (RPC) = data. In=09 response to Smart Grid requirements, there is consideration = of a=09 variant of the protocol that could be used for polled and = event-=09 driven management activities, and for both monitoring and=09 configuration of systems in the field.=09 =09 3.6. Service and Resource Discovery=09 =09 Service and resource discovery are among the most important protocols = Service and resource discovery are among the most important = protocols=09 for constrained resource self-organizing networks. These include = for constrained resource self-organizing networks. These = include=09 various sensor networks as well as the Home Area Networks (HANs), = various sensor networks as well as the Home Area Networks = (HANs),=09 Building Area Networks (BANs) and Field Area Networks (FANs) = Building Area Networks (BANs) and Field Area Networks (FANs)=09 envisioned by Smart Grid architects. envisioned by Smart = Grid architects.=09 =09 3.5.1. Service Discovery 3.6.1. Service Discovery=09 =09 Service discovery protocols are designed for the automatic = Service discovery protocols are designed for the automatic=09 configuration and detection of devices, and the services offered by = configuration and detection of devices, and the services = offered by=09 the discovered devices. In many cases service discovery is performed = the discovered devices. In many cases service discovery is = performed=09 by so-called "constrained resource" devices (i.e., those with limited = by so-called "constrained resource" devices (i.e., those with = limited=09 processing power, memory, and power resources). = processing power, memory, and power resources).=09 =09 In general, service discovery is concerned with the assignment of = In general, service discovery is concerned with the = resolution and=09 network addresses (perhaps via Stateless Address Autoconfiguration = distribution of hostnames via multicast DNS=09 [RFC4862]), resolution and distribution of hostnames via multicast = [I-D.cheshire-dnsext-multicastdns] and the automatic location = of=09 DNS [I-D.cheshire-dnsext-multicastdns] and the automatic location of = =09 network services via DHCP (Section 3.4.2), the DNS Service Discovery = network services via DHCP (Section 3.4.2), the DNS Service = Discovery=09 (DNS-SD) [I-D.cheshire-dnsext-dns-sd] (part of Apple's Bonjour = (DNS-SD) [I-D.cheshire-dnsext-dns-sd] (part of Apple's = Bonjour=09 technology), and the Service Location Protocol (SLP) [RFC2608]. = technology) and the Service Location Protocol (SLP) = [RFC2608].=09 =09 3.5.2. Resource Discovery 3.6.2. Resource Discovery=09 =09 Resource Discovery is concerned with the discovery resources offered = Resource Discovery is concerned with the discovery of = resources=09 by end-points and is extremely important in machine-to-machine = offered by end-points and is extremely important in = machine-to-=09 closed-loop applications (i.e., those with no humans in the loop). = machine closed-loop applications (i.e., those with no humans = in the=09 The goals of resource discover protocols include: = loop). The goals of resource discover protocols include:=09 =09 Simplicity of creation and maintenance of resources = Simplicity of creation and maintenance of resources=09 =09 Commonly understood semantics Commonly = understood semantics=09 =09 Conformance to existing and emerging standards = Conformance to existing and emerging standards=09 =09 International scope and applicability = International scope and applicability=09 =09 Extensibility Extensibility=09 =09 Interoperability among collections and indexing systems = Interoperability among collections and indexing systems=09 =09 The Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] is = The Constrained Application Protocol (CoAP) = [I-D.ietf-core-coap] is=09 being developed in IETF with these goals in mind. In particular, = being developed in IETF with these goals in mind. In = particular,=09 CoAP is designed for use in constrained resource networks and for = CoAP is designed for use in constrained resource networks and = for=09 machine-to-machine applications such as smart energy and building = machine-to-machine applications such as smart energy and = building=09 automation. It provides a RESTful transfer protocol, a built-in = automation. It provides a RESTful transfer protocol = [RESTFUL], a=09 resource discovery protocol, and includes web concepts such as URIs = built-in resource discovery protocol, and includes web = concepts such=09 and content-types. CoAP provides both unicast and multicast resource = as URIs and content-types. CoAP provides both unicast and = multicast=09 discovery and includes the ability to filter on attributes of = resource discovery and includes the ability to filter on = attributes=09 resource descriptions. Finally, CoAP resource discovery can also be = of resource descriptions. Finally, CoAP resource discovery = can also=09 used to discovery HTTP resources. be used to discovery = HTTP resources.=09 =09 For simplicity, CoAP makes the assumption that all CoAP servers = For simplicity, CoAP makes the assumption that all CoAP = servers=09 listen on the default CoAP port or otherwise have been configured or = listen on the default CoAP port or otherwise have been = configured or=09 discovered using some general service discovery mechanism such as DNS = discovered using some general service discovery mechanism = such as DNS=09 Service Discovery (DNS-SD) [I-D.cheshire-dnsext-dns-sd]. = Service Discovery (DNS-SD) [I-D.cheshire-dnsext-dns-sd].=09 =09 Resource discovery in CoAP is accomplished through the use of well- = Resource discovery in CoAP is accomplished through the use of = well-=09 known resources which describe the links offered by a CoAP server. = known resources which describe the links offered by a CoAP = server.=09 CoAP defines a well-known URI for discovery: "/.well-known/r" = CoAP defines a well-known URI for discovery: "/.well-known/r"=09= [RFC5785]. For example, the query [GET /.well-known/r] returns a = [RFC5785]. For example, the query [GET /.well-known/r] = returns a=09 list of links (representing resources) available from the queried = list of links (representing resources) available from the = queried=09 CoAP server. A query such as [GET /.well-known/r?n=3DVoltage] = returns CoAP server. A query such as [GET = /.well-known/r?n=3DVoltage] returns=09 the resources with the name Voltage. the resources with = the name Voltage.=09 =09 3.6. Other Applications 3.7. Other Applications=09 =09 There are several applications that are widely used but are not = There are several applications that are widely used but are = not=09 properly thought of as infrastructure. properly = thought of as infrastructure.=09 =09 3.6.1. Network Time 3.7.1. Session Initiation Protocol=09 =09 The Network Time Protocol was originally designed by Dave Mills of = =09 the University of Delaware and CSNET, for the purpose of implementing = =09 a temporal metric in the Fuzzball Routing Protocol and generally = =09 coordinating time experiments. The current versions of the time = =09 protocol are the Network Time Protocol [RFC5905]. =09 =09 NTP is currently being updated in [RFC5905]. =09 =09 3.6.2. Session Initiation Protocol =09 =09 The Session Initiation Protocol The Session = Initiation Protocol=09 [RFC3261][RFC3265][RFC3853][RFC4320][RFC4916][RFC5393][RFC5621] is an = = [RFC3261][RFC3265][RFC3853][RFC4320][RFC4916][RFC5393][RFC5621] is an=09 application layer control (signaling) protocol for creating, = application layer control (signaling) protocol for creating,=09 modifying and terminating multimedia sessions on the Internet, meant = modifying and terminating multimedia sessions on the = Internet, meant=09 to be more scalable than H.323. Multimedia sessions can be voice, = to be more scalable than H.323. Multimedia sessions can be = voice,=09 video, instant messaging, shared data, and/or subscriptions of = video, instant messaging, shared data, and/or subscriptions = of=09 events. SIP can run on top of TCP, UDP, SCTP, or TLS over TCP. SIP = events. SIP can run on top of TCP, UDP, SCTP, or TLS over = TCP. SIP=09 is independent of the transport layer, and independent of the = is independent of the transport layer, and independent of the=09= underlying IPv4/v6 version. In fact, the transport protocol used can = underlying IPv4/v6 version. In fact, the transport protocol = used can=09 =09 skipping to change at page 27, line 10 skipping to change at = page 30, line 11=09 designed to be SDP aware (i.e., looking into each packet far enough = designed to be SDP aware (i.e., looking into each packet far = enough=09 to discover what the IP address and port number is for this = to discover what the IP address and port number is for this=09 particular session - and resetting it based on the Session Traversal = particular session - and resetting it based on the Session = Traversal=09 Utilities for NAT [RFC5389], the session established by SIP will not = Utilities for NAT [RFC5389], the session established by SIP = will not=09 result in RTP packets being sent to the proper endpoint (in SIP = result in RTP packets being sent to the proper endpoint (in = SIP=09 called a user agent, or UA). It should be noted that SIP messaging = called a user agent, or UA). It should be noted that SIP = messaging=09 has no issues with NATs, it is just the UA's inability to generally = has no issues with NATs, it is just the UA's inability to = generally=09 learn about the presence of the NATs that prevent the RTP packets = learn about the presence of the NATs that prevent the RTP = packets=09 from being received by the UA establishing the session. = from being received by the UA establishing the session.=09 =09 3.6.3. Calendaring 3.7.2. Calendaring=09 =09 Internet calendaring, as implemented in Apple iCal, Microsoft Outlook = Internet calendaring, as implemented in Apple iCal, Microsoft = Outlook=09 and Entourage, and Google Calendar, is specified in Internet = and Entourage, and Google Calendar, is specified in Internet=09 Calendaring and Scheduling Core Object Specification (iCalendar) = Calendaring and Scheduling Core Object Specification = (iCalendar)=09 [RFC5545] and is in the process of being updated to an XML schema in = [RFC5545] and is in the process of being updated to an XML = schema in=09 iCalendar XML Representation [I-D.daboo-et-al-icalendar-in-xml] = iCalendar XML Representation = [I-D.daboo-et-al-icalendar-in-xml]=09 Several protocols exist to carry calendar events, including iCalendar = Several protocols exist to carry calendar events, including = iCalendar=09 Transport-Independent Interoperability Protocol (iTIP) [RFC5546], the = Transport-Independent Interoperability Protocol (iTIP) = [RFC5546], the=09 Message-Based Interoperability Protocol (iMIP) [RFC2447] , and open = Message-Based Interoperability Protocol (iMIP) [RFC2447] , = and open=09 source work on the Atom Publishing Protocol [RFC5023]. = source work on the Atom Publishing Protocol [RFC5023].=09 =09 skipping to change at page 32, line 17 skipping to change at = page 35, line 17=09 therefore be removed upon publication as an RFC at the RFC Editor's = therefore be removed upon publication as an RFC at the RFC = Editor's=09 discretion. discretion.=09 =09 6. Security Considerations 6. Security Considerations=09 =09 Security is addressed in some detail in Section 2.2 and Section 3.1. = Security is addressed in some detail in Section 2.2 and = Section 3.1.=09 =09 7. Acknowledgements 7. Acknowledgements=09 =09 Review comments were made by Andrew Yourtchenko, Ashok Narayanan, = Review comments were made by Andrew Yourtchenko, Ashok = Narayanan,=09 Bernie Volz, Chris Lonvick, Dave McGrew, Dave Oran, David Su, Hemant = Bernie Volz, Chris Lonvick, Dave McGrew, Dave Oran, David Su, = Don=09 Singh, James Polk, John Meylor, Joseph Salowey, Julien Abeille, Kerry = Sturek, Francis Cleveland, Hemant Singh, James Polk, John = Meylor,=09 Lynn, Magnus Westerlund, Murtaza Chiba, Paul Duffy, Paul Hoffman, = Joseph Salowey, Julien Abeille, Kerry Lynn, Magnus = Westerlund,=09 Ralph Droms, Russ White, Sheila Frankel, and Toerless Eckert. Dave = Murtaza Chiba, Paul Duffy, Paul Hoffman, Ralph Droms, Russ = White,=09 McGrew, Vint Cerf, and Ralph Droms suggested text. = Sheila Frankel, Tom Herbst, and Toerless Eckert. Dave McGrew, Vint=09 Cerf, and Ralph Droms suggested text.=09 =09 8. References 8. References=09 =09 8.1. Normative References 8.1. Normative References=09 =09 [RFC1122] Braden, R., "Requirements for Internet Hosts - = [RFC1122] Braden, R., "Requirements for Internet Hosts -=09 Communication Layers", STD 3, RFC 1122, October 1989. = Communication Layers", STD 3, RFC 1122, October = 1989.=09 =09 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application = [RFC1123] Braden, R., "Requirements for Internet Hosts - = Application=09 and Support", STD 3, RFC 1123, October 1989. = and Support", STD 3, RFC 1123, October 1989.=09 =09 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", = [RFC1812] Baker, F., "Requirements for IP Version 4 = Routers",=09 RFC 1812, June 1995. RFC 1812, = June 1995.=09 =09 [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, = [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294,=09 April 2006. April 2006.=09 =09 8.2. Informative References 8.2. Informative References=09 =09 [1822] Bolt Beranek and Newman Inc., "Interface Message = Processor=09 -- Specifications for the interconnection of a = host and a=09 IMP, Report No. 1822", January 1976.=09 = =09 [I-D.arkko-ipv6-transition-guidelines] = [I-D.arkko-ipv6-transition-guidelines]=09 Arkko, J. and F. Baker, "Guidelines for Using IPv6 = Arkko, J. and F. Baker, "Guidelines for Using IPv6=09= Transition Mechanisms", Transition = Mechanisms during IPv6 Deployment",=09 draft-arkko-ipv6-transition-guidelines-03 (work in = draft-arkko-ipv6-transition-guidelines-06 (work in=09= progress), July 2010. progress), = August 2010.=09 =09 [I-D.cheshire-dnsext-dns-sd] [I-D.cheshire-dnsext-dns-sd]=09= Cheshire, S. and M. Krochmal, "DNS-Based Service = Cheshire, S. and M. Krochmal, "DNS-Based Service=09 Discovery", draft-cheshire-dnsext-dns-sd-06 (work in = Discovery", draft-cheshire-dnsext-dns-sd-06 (work = in=09 progress), March 2010. progress), = March 2010.=09 =09 [I-D.cheshire-dnsext-multicastdns] = [I-D.cheshire-dnsext-multicastdns]=09 Cheshire, S. and M. Krochmal, "Multicast DNS", = Cheshire, S. and M. Krochmal, "Multicast DNS",=09 draft-cheshire-dnsext-multicastdns-11 (work in progress), = draft-cheshire-dnsext-multicastdns-11 (work in = progress),=09 March 2010. March 2010.=09 =09 [I-D.daboo-et-al-icalendar-in-xml] = [I-D.daboo-et-al-icalendar-in-xml]=09 Daboo, C., Douglass, M., and S. Lees, "xCal: The XML = Daboo, C., Douglass, M., and S. Lees, "xCal: The = XML=09 format for iCalendar", format for = iCalendar",=09 draft-daboo-et-al-icalendar-in-xml-05 (work in progress), = draft-daboo-et-al-icalendar-in-xml-06 (work in = progress),=09 July 2010. September 2010.=09 =09 [I-D.ietf-6lowpan-hc] [I-D.ietf-6lowpan-hc]=09 Hui, J. and P. Thubert, "Compression Format for IPv6 = Hui, J. and P. Thubert, "Compression Format for = IPv6=09 Datagrams in 6LoWPAN Networks", draft-ietf-6lowpan-hc-08 = Datagrams in 6LoWPAN Networks", = draft-ietf-6lowpan-hc-12=09 (work in progress), July 2010. = (work in progress), September 2010.=09 =09 [I-D.ietf-6man-node-req-bis] [I-D.ietf-6man-node-req-bis]=09= Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node = Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 = Node=09 Requirements RFC 4294-bis", = Requirements RFC 4294-bis",=09 draft-ietf-6man-node-req-bis-05 (work in progress), = draft-ietf-6man-node-req-bis-05 (work in = progress),=09 July 2010. July 2010.=09 =09 [I-D.ietf-behave-address-format] = [I-D.ietf-behave-address-format]=09 Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. = Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., = and X.=09 Li, "IPv6 Addressing of IPv4/IPv6 Translators", = Li, "IPv6 Addressing of IPv4/IPv6 Translators",=09 draft-ietf-behave-address-format-10 (work in progress), = draft-ietf-behave-address-format-10 (work in = progress),=09 August 2010. August 2010.=09 =09 [I-D.ietf-behave-dns64] [I-D.ietf-behave-dns64]=09 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, = Bagnulo, M., Sullivan, A., Matthews, P., and I. = Beijnum,=09 "DNS64: DNS extensions for Network Address Translation = "DNS64: DNS extensions for Network Address = Translation=09 from IPv6 Clients to IPv4 Servers", = from IPv6 Clients to IPv4 Servers",=09 draft-ietf-behave-dns64-10 (work in progress), July 2010. = draft-ietf-behave-dns64-11 (work in progress),=09 October 2010.=09 =09 [I-D.ietf-behave-v6v4-framework] = [I-D.ietf-behave-v6v4-framework]=09 Baker, F., Li, X., Bao, C., and K. Yin, "Framework for = Baker, F., Li, X., Bao, C., and K. Yin, "Framework = for=09 IPv4/IPv6 Translation", IPv4/IPv6 = Translation",=09 draft-ietf-behave-v6v4-framework-10 (work in progress), = draft-ietf-behave-v6v4-framework-10 (work in = progress),=09 August 2010. August 2010.=09 =09 [I-D.ietf-behave-v6v4-xlate] [I-D.ietf-behave-v6v4-xlate]=09= Li, X., Bao, C., and F. Baker, "IP/ICMP Translation = Li, X., Bao, C., and F. Baker, "IP/ICMP = Translation=09 Algorithm", draft-ietf-behave-v6v4-xlate-21 (work in = Algorithm", draft-ietf-behave-v6v4-xlate-23 (work = in=09 progress), August 2010. progress), = September 2010.=09 =09 [I-D.ietf-behave-v6v4-xlate-stateful] = [I-D.ietf-behave-v6v4-xlate-stateful]=09 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful = Bagnulo, M., Matthews, P., and I. Beijnum, = "Stateful=09 NAT64: Network Address and Protocol Translation from IPv6 = NAT64: Network Address and Protocol Translation = from IPv6=09 Clients to IPv4 Servers", Clients to = IPv4 Servers",=09 draft-ietf-behave-v6v4-xlate-stateful-12 (work in = draft-ietf-behave-v6v4-xlate-stateful-12 (work in=09 progress), July 2010. progress), = July 2010.=09 =09 [I-D.ietf-core-coap] [I-D.ietf-core-coap]=09 Shelby, Z., Frank, B., and D. Sturek, "Constrained = Shelby, Z., Frank, B., and D. Sturek, "Constrained=09= Application Protocol (CoAP)", draft-ietf-core-coap-01 = Application Protocol (CoAP)", = draft-ietf-core-coap-02=09 (work in progress), July 2010. = (work in progress), September 2010.=09 =09 [I-D.ietf-manet-dymo] [I-D.ietf-manet-dymo]=09 Chakeres, I. and C. Perkins, "Dynamic MANET On-demand = Chakeres, I. and C. Perkins, "Dynamic MANET = On-demand=09 (DYMO) Routing", draft-ietf-manet-dymo-21 (work in = (DYMO) Routing", draft-ietf-manet-dymo-21 (work in=09= progress), July 2010. progress), = July 2010.=09 =09 [I-D.ietf-roll-rpl] [I-D.ietf-roll-rpl]=09 Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing = Winter, T., Thubert, P., and R. Team, "RPL: IPv6 = Routing=09 Protocol for Low power and Lossy Networks", = Protocol for Low power and Lossy Networks",=09 draft-ietf-roll-rpl-11 (work in progress), July 2010. = draft-ietf-roll-rpl-11 (work in progress), July = 2010.=09 =09 [I-D.ietf-tls-rfc4347-bis] [I-D.ietf-tls-rfc4347-bis]=09 Rescorla, E. and N. Modadugu, "Datagram Transport Layer = Rescorla, E. and N. Modadugu, "Datagram Transport = Layer=09 Security version 1.2", draft-ietf-tls-rfc4347-bis-04 (work = Security version 1.2", = draft-ietf-tls-rfc4347-bis-04 (work=09 in progress), July 2010. in = progress), July 2010.=09 =09 [IEC62351-3]=09 International Electrotechnical Commission = Technical=09 Committee 57, "POWER SYSTEMS MANAGEMENT AND = ASSOCIATED=09 INFORMATION EXCHANGE. DATA AND COMMUNICATIONS = SECURITY --=09 Part 3: Communication network and system security = Profiles=09 including TCP/IP", May 2007.=09 = =09 [IEEE802.1X] [IEEE802.1X]=09 Institute of Electrical and Electronics Engineers, "IEEE = Institute of Electrical and Electronics Engineers, = "IEEE=09 Standard for Local and Metropolitan Area Networks - Port = Standard for Local and Metropolitan Area Networks = - Port=09 based Network Access Control", IEEE Standard 802.1X-2010, = based Network Access Control", IEEE Standard = 802.1X-2010,=09 February 2010. February 2010.=09 =09 [RESTFUL] Fielding, "Architectural Styles and the Design of = Network-=09 based Software Architectures", 2000.=09 = =09 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, = [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC = 768,=09 August 1980. August 1980.=09 =09 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, = [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,=09 September 1981. September 1981.=09 =09 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, = [RFC0792] Postel, J., "Internet Control Message Protocol", = STD 5,=09 RFC 792, September 1981. RFC 792, = September 1981.=09 =09 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, = [RFC0793] Postel, J., "Transmission Control Protocol", STD = 7,=09 =09 skipping to change at page 38, line 37 skipping to change at = page 42, line 5=09 March 2002. March 2002.=09 =09 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., = [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., = Perkins, C.,=09 and M. Carney, "Dynamic Host Configuration Protocol for = and M. Carney, "Dynamic Host Configuration = Protocol for=09 IPv6 (DHCPv6)", RFC 3315, July 2003. = IPv6 (DHCPv6)", RFC 3315, July 2003.=09 =09 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. = [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., = and A.=09 Thyagarajan, "Internet Group Management Protocol, Version = Thyagarajan, "Internet Group Management Protocol, = Version=09 3", RFC 3376, October 2002. = 3", RFC 3376, October 2002.=09 =09 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An=09 Architecture for Describing Simple Network = Management=09 Protocol (SNMP) Management Frameworks", STD 62, = RFC 3411,=09 December 2002.=09 =09 [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. = Wijnen,=09 "Message Processing and Dispatching for the Simple = Network=09 Management Protocol (SNMP)", STD 62, RFC 3412,=09 December 2002.=09 =09 [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple = Network=09 Management Protocol (SNMP) Applications", STD 62,=09= RFC 3413, December 2002.=09 =09 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security = Model=09 (USM) for version 3 of the Simple Network = Management=09 Protocol (SNMPv3)", STD 62, RFC 3414, December = 2002.=09 =09 [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, = "View-based=09 Access Control Model (VACM) for the Simple Network=09= Management Protocol (SNMP)", STD 62, RFC 3415,=09 December 2002.=09 =09 [RFC3416] Presuhn, R., "Version 2 of the Protocol Operations = for the=09 Simple Network Management Protocol (SNMP)", STD = 62,=09 RFC 3416, December 2002.=09 =09 [RFC3417] Presuhn, R., "Transport Mappings for the Simple = Network=09 Management Protocol (SNMP)", STD 62, RFC 3417,=09 December 2002.=09 =09 [RFC3418] Presuhn, R., "Management Information Base (MIB) = for the=09 Simple Network Management Protocol (SNMP)", STD = 62,=09 RFC 3418, December 2002.=09 = =09 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral = [RFC3424] Daigle, L. and IAB, "IAB Considerations for = UNilateral=09 Self-Address Fixing (UNSAF) Across Network Address = Self-Address Fixing (UNSAF) Across Network Address=09= Translation", RFC 3424, November 2002. = Translation", RFC 3424, November 2002.=09 =09 [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport = [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, = "Transport=09 Layer Security over Stream Control Transmission Protocol", = Layer Security over Stream Control Transmission = Protocol",=09 RFC 3436, December 2002. RFC 3436, = December 2002.=09 =09 [RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, = [RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., = Handley,=09 M., and J. Crowcroft, "The Use of Forward Error Correction = M., and J. Crowcroft, "The Use of Forward Error = Correction=09 =09 skipping to change at page 40, line 34 skipping to change at = page 44, line 36=09 =09 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the = [RFC4301] Kent, S. and K. Seo, "Security Architecture for = the=09 Internet Protocol", RFC 4301, December 2005. = Internet Protocol", RFC 4301, December 2005.=09 =09 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, = [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,=09 December 2005. December 2005.=09 =09 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", = [RFC4303] Kent, S., "IP Encapsulating Security Payload = (ESP)",=09 RFC 4303, December 2005. RFC 4303, = December 2005.=09 =09 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", = =09 RFC 4306, December 2005. =09 = =09 [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the = [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in = the=09 Internet Key Exchange Version 2 (IKEv2)", RFC 4307, = Internet Key Exchange Version 2 (IKEv2)", RFC = 4307,=09 December 2005. December 2005.=09 =09 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM = [RFC4309] Housley, R., "Using Advanced Encryption Standard = (AES) CCM=09 Mode with IPsec Encapsulating Security Payload (ESP)", = Mode with IPsec Encapsulating Security Payload = (ESP)",=09 RFC 4309, December 2005. RFC 4309, = December 2005.=09 =09 [RFC4320] Sparks, R., "Actions Addressing Identified Issues with the = [RFC4320] Sparks, R., "Actions Addressing Identified Issues = with the=09 Session Initiation Protocol's (SIP) Non-INVITE = Session Initiation Protocol's (SIP) Non-INVITE=09 =09 skipping to change at page 41, line 23 skipping to change at = page 45, line 23=09 Message Protocol (ICMPv6) for the Internet Protocol = Message Protocol (ICMPv6) for the Internet = Protocol=09 Version 6 (IPv6) Specification", RFC 4443, March 2006. = Version 6 (IPv6) Specification", RFC 4443, March = 2006.=09 =09 [RFC4487] Le, F., Faccin, S., Patil, B., and H. Tschofenig, "Mobile = [RFC4487] Le, F., Faccin, S., Patil, B., and H. Tschofenig, = "Mobile=09 IPv6 and Firewalls: Problem Statement", RFC 4487, = IPv6 and Firewalls: Problem Statement", RFC 4487,=09 May 2006. May 2006.=09 =09 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session = [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: = Session=09 Description Protocol", RFC 4566, July 2006. = Description Protocol", RFC 4566, July 2006.=09 =09 [RFC4594] Babiarz, J., Chan, K., and F. Baker, = "Configuration=09 Guidelines for DiffServ Service Classes", RFC = 4594,=09 August 2006.=09 = =09 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, = [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. = Kouvelas,=09 "Protocol Independent Multicast - Sparse Mode (PIM-SM): = "Protocol Independent Multicast - Sparse Mode = (PIM-SM):=09 Protocol Specification (Revised)", RFC 4601, August 2006. = Protocol Specification (Revised)", RFC 4601, = August 2006.=09 =09 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet = [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using = Internet=09 Group Management Protocol Version 3 (IGMPv3) and Multicast = Group Management Protocol Version 3 (IGMPv3) and = Multicast=09 Listener Discovery Protocol Version 2 (MLDv2) for Source- = Listener Discovery Protocol Version 2 (MLDv2) for = Source-=09 Specific Multicast", RFC 4604, August 2006. = Specific Multicast", RFC 4604, August 2006.=09 =09 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for = [RFC4607] Holbrook, H. and B. Cain, "Source-Specific = Multicast for=09 =09 skipping to change at page 41, line 46 skipping to change at = page 45, line 50=09 Protocol Independent Multicast in 232/8", BCP 120, = Protocol Independent Multicast in 232/8", BCP 120,=09= RFC 4608, August 2006. RFC 4608, = August 2006.=09 =09 [RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap = [RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A = Roadmap=09 for Transmission Control Protocol (TCP) Specification = for Transmission Control Protocol (TCP) = Specification=09 Documents", RFC 4614, September 2006. = Documents", RFC 4614, September 2006.=09 =09 [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, = [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC = 4741,=09 December 2006. December 2006.=09 =09 [RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF=09= Configuration Protocol over Secure SHell (SSH)", = RFC 4742,=09 December 2006.=09 =09 [RFC4743] Goddard, T., "Using NETCONF over the Simple Object = Access=09 Protocol (SOAP)", RFC 4743, December 2006.=09 =09 [RFC4744] Lear, E. and K. Crozier, "Using the NETCONF = Protocol over=09 the Blocks Extensible Exchange Protocol (BEEP)", = RFC 4744,=09 December 2006.=09 = =09 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, = [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,=09 "Multiprotocol Extensions for BGP-4", RFC 4760, = "Multiprotocol Extensions for BGP-4", RFC 4760,=09 January 2007. January 2007.=09 =09 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation = [RFC4787] Audet, F. and C. Jennings, "Network Address = Translation=09 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, = (NAT) Behavioral Requirements for Unicast UDP", = BCP 127,=09 RFC 4787, January 2007. RFC 4787, = January 2007.=09 =09 [RFC4835] Manral, V., "Cryptographic Algorithm Implementation = [RFC4835] Manral, V., "Cryptographic Algorithm = Implementation=09 Requirements for Encapsulating Security Payload (ESP) and = Requirements for Encapsulating Security Payload = (ESP) and=09 =09 skipping to change at page 43, line 10 skipping to change at = page 47, line 25=09 PPP", RFC 5072, September 2007. = PPP", RFC 5072, September 2007.=09 =09 [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- = [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of = Peer-to-=09 Peer (P2P) Communication across Network Address = Peer (P2P) Communication across Network Address=09 Translators (NATs)", RFC 5128, March 2008. = Translators (NATs)", RFC 5128, March 2008.=09 =09 [RFC5135] Wing, D. and T. Eckert, "IP Multicast Requirements for a = [RFC5135] Wing, D. and T. Eckert, "IP Multicast Requirements = for a=09 Network Address Translator (NAT) and a Network Address = Network Address Translator (NAT) and a Network = Address=09 Port Translator (NAPT)", BCP 135, RFC 5135, February 2008. = Port Translator (NAPT)", BCP 135, RFC 5135, = February 2008.=09 =09 [RFC5193] Jayaraman, P., Lopez, R., Ohba, Y., Parthasarathy, = M., and=09 A. Yegin, "Protocol for Carrying Authentication = for=09 Network Access (PANA) Framework", RFC 5193, May = 2008.=09 = =09 [RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and = [RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT = and=09 Firewall Traversal Issues of Host Identity Protocol (HIP) = Firewall Traversal Issues of Host Identity = Protocol (HIP)=09 Communication", RFC 5207, April 2008. = Communication", RFC 5207, April 2008.=09 =09 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS = [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS=09 Authentication Protocol", RFC 5216, March 2008. = Authentication Protocol", RFC 5216, March 2008.=09 =09 [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over = [RFC5238] Phelan, T., "Datagram Transport Layer Security = (DTLS) over=09 the Datagram Congestion Control Protocol (DCCP)", = the Datagram Congestion Control Protocol (DCCP)",=09 RFC 5238, May 2008. RFC 5238, = May 2008.=09 =09 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security = [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer = Security=09 (TLS) Protocol Version 1.2", RFC 5246, August 2008. = (TLS) Protocol Version 1.2", RFC 5246, August = 2008.=09 =09 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event=09 Notifications", RFC 5277, July 2008.=09 = =09 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, = [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,=09 October 2008. October 2008.=09 =09 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF = [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, = "OSPF=09 for IPv6", RFC 5340, July 2008. = for IPv6", RFC 5340, July 2008.=09 =09 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, = [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. = Wing,=09 "Session Traversal Utilities for NAT (STUN)", RFC 5389, = "Session Traversal Utilities for NAT (STUN)", RFC = 5389,=09 October 2008. October 2008.=09 =09 [RFC5393] Sparks, R., Lawrence, S., Hawrylyshen, A., and B. Campen, = [RFC5393] Sparks, R., Lawrence, S., Hawrylyshen, A., and B. = Campen,=09 "Addressing an Amplification Vulnerability in Session = "Addressing an Amplification Vulnerability in = Session=09 Initiation Protocol (SIP) Forking Proxies", RFC 5393, = Initiation Protocol (SIP) Forking Proxies", RFC = 5393,=09 December 2008. December 2008.=09 =09 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines = [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage = Guidelines=09 for Application Designers", BCP 145, RFC 5405, = for Application Designers", BCP 145, RFC 5405,=09 November 2008. November 2008.=09 =09 [RFC5539] Badra, M., "NETCONF over Transport Layer Security = (TLS)",=09 RFC 5539, May 2009.=09 = =09 [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling = [RFC5545] Desruisseaux, B., "Internet Calendaring and = Scheduling=09 Core Object Specification (iCalendar)", RFC 5545, = Core Object Specification (iCalendar)", RFC 5545,=09 September 2009. September 2009.=09 =09 [RFC5546] Daboo, C., "iCalendar Transport-Independent = [RFC5546] Daboo, C., "iCalendar Transport-Independent=09 Interoperability Protocol (iTIP)", RFC 5546, = Interoperability Protocol (iTIP)", RFC 5546,=09 December 2009. December 2009.=09 =09 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. = Barthel,=09 "Routing Requirements for Urban Low-Power and = Lossy=09 Networks", RFC 5548, May 2009.=09 = =09 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 = [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4=09 Infrastructures (6rd)", RFC 5569, January 2010. = Infrastructures (6rd)", RFC 5569, January 2010.=09 =09 [RFC5621] Camarillo, G., "Message Body Handling in the Session = [RFC5621] Camarillo, G., "Message Body Handling in the = Session=09 Initiation Protocol (SIP)", RFC 5621, September 2009. = Initiation Protocol (SIP)", RFC 5621, September = 2009.=09 =09 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. = Phinney,=09 "Industrial Routing Requirements in Low-Power and = Lossy=09 Networks", RFC 5673, October 2009.=09 = =09 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion = [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP = Congestion=09 Control", RFC 5681, September 2009. = Control", RFC 5681, September 2009.=09 =09 [RFC5717] Lengyel, B. and M. Bjorklund, "Partial Lock Remote=09= Procedure Call (RPC) for NETCONF", RFC 5717,=09 December 2009.=09 = =09 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, = [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. = Macker,=09 "NACK-Oriented Reliable Multicast (NORM) Transport = "NACK-Oriented Reliable Multicast (NORM) Transport=09= Protocol", RFC 5740, November 2009. = Protocol", RFC 5740, November 2009.=09 =09 [RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet = [RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose = Internet=09 Mail Extensions (S/MIME) Version 3.2 Certificate = Mail Extensions (S/MIME) Version 3.2 Certificate=09 Handling", RFC 5750, January 2010. = Handling", RFC 5750, January 2010.=09 =09 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet = [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose = Internet=09 Mail Extensions (S/MIME) Version 3.2 Message = Mail Extensions (S/MIME) Version 3.2 Message=09 Specification", RFC 5751, January 2010. = Specification", RFC 5751, January 2010.=09 =09 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known = [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining = Well-Known=09 Uniform Resource Identifiers (URIs)", RFC 5785, = Uniform Resource Identifiers (URIs)", RFC 5785,=09 April 2010. April 2010.=09 =09 [RFC5796] Atwood, W., Islam, S., and M. Siami, "Authentication and = [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home = Automation=09 Confidentiality in Protocol Independent Multicast Sparse = Routing Requirements in Low-Power and Lossy = Networks",=09 Mode (PIM-SM) Link-Local Messages", RFC 5796, March 2010. = RFC 5826, April 2010.=09 =09 [RFC5838] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. = [RFC5838] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., = and R.=09 Aggarwal, "Support of Address Families in OSPFv3", = Aggarwal, "Support of Address Families in OSPFv3",=09= RFC 5838, April 2010. RFC 5838, = April 2010.=09 =09 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. = Vermeylen,=09 "Building Automation Routing Requirements in = Low-Power and=09 Lossy Networks", RFC 5867, June 2010.=09 = =09 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network = [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, = "Network=09 Time Protocol Version 4: Protocol and Algorithms = Time Protocol Version 4: Protocol and Algorithms=09 Specification", RFC 5905, June 2010. = Specification", RFC 5905, June 2010.=09 =09 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,=09= "Internet Key Exchange Protocol Version 2 = (IKEv2)",=09 RFC 5996, September 2010.=09 = =09 [SP-MULPIv3.0] [SP-MULPIv3.0]=09 CableLabs, "DOCSIS 3.0 MAC and Upper Layer Protocols = CableLabs, "DOCSIS 3.0 MAC and Upper Layer = Protocols=09 Interface Specification, CM-SP-MULPIv3.0-I10-090529", = Interface Specification, = CM-SP-MULPIv3.0-I10-090529",=09 May 2009. May 2009.=09 =09 Appendix A. Example: Advanced Metering Infrastructure=09 =09 This appendix provides a worked example of the use of the = Internet=09 Protocol Suite in a network such as the Smart Grid's Advanced=09= Metering Infrastructure (AMI). There are several possible = models.=09 =09 Figure 6 shows the structure of the AMI as it reaches out = towards a=09 set of residences. In this structure, we have the home = itself and=09 its Home Area Network (HAN), the Neighborhood Area Network = (NAN) that=09 the utility uses to access the meter at the home, and the = utility=09 access network that connects a set of NANs to the utility = itself.=09 For the purposes of this discussion, assume that the NAN = contains a=09 distributed application in a set collectors, which is of = course only=09 one way the application could be implemented.=09 =09 ---=09 A thermostats, appliances, etc=09 | ------+-----------------------------------=09 | |=09 |"HAN" | <--- Energy Services Interface (ESI)=09 | +---+---+=09 | | Meter | Meter is generally an ALG between the AMI and = the HAN=09 | +---+---+=09 V \=09 --- \=09 A \ | /=09 | \ | /=09 | "NAN" +--+-+-+---+ Likely a router but could=09 | |Collector | be an front-end application=09 V +----+-----+ gateway for utility=09 --- \=09 A \ | /=09 | \ | /=09 |"AMI" +--+-+-+--+=09 | | AMI |=09 | | Headend |=09 V +---------+=09 ---=09 =09 Figure 6: The HAN, NAN, and Utility in the Advanced = Metering=09 Infrastructure=09 =09 There are several questions that have to be answered in = describing=09 this picture, which given possible answers yield different = possible=09 models. They include at least:=09 =09 o How does Demand Response work? Either:=09 =09 * The utility presents pricing signals to the home,=09 =09 * The utility presents pricing signals individual devices = (e.g.,=09 a Pluggable Electric Vehicle),=09 =09 * The utility adjusts settings on individual appliances = within=09 the home.=09 =09 o How does the utility access meters at the home?=09 =09 * The AMI Headend manages the interfaces with the meters,=09= collecting metering data and passing it on to the = appropriate=09 applications over the Enterprise Bus, or=09 =09 * Distributed application support (collectors") might = access and=09 summarize the information; this device might be managed = by the=09 utility or by a service between the utility and its = customers.=09 =09 In implementation, these models are idealized; reality may = include=09 some aspects of each model in specified cases.=09 =09 The examples include:=09 =09 1. Appendix A.2 presumes that the HAN, the NAN, and the = utility's=09 network are separate administrative domains and speak = application=09 to application across those domains.=09 =09 2. Appendix A.3 repeats the first example, but presuming = that the=09 utility directly accesses appliances within the HAN from = the=09 collector".=09 =09 3. Appendix A.4 repeats the first example, but presuming = that the=09 collector directly forwards traffic as a router in = addition to=09 distributed application chores. Note that this case = implies=09 numerous privacy and security concerns and as such is = considered=09 a less likely deployment model.=09 =09 A.1. How to structure a network=09 =09 A key consideration in the Internet has been the development = of new=09 link layer technologies over time. The ARPANET originally = used a BBN=09 proprietary link layer called BBN 1822 [1822]. In the late = 1970's,=09 the ARPANET switched to X.25 as an interface to the 1822 = network.=09 With the deployment of the IEEE 802 series technologies in = the early=09 1980's, IP was deployed on Ethernet (IEEE 802.3), Token Ring = (IEEE=09 802.5) and WiFi (IEEE 802.11), as well as Arcnet, serial = lines of=09 various kinds, Frame Relay, and ATM. A key issue in this = evolution=09 was that the applications developed to run on the Internet = use APIs=09 related to the IPS, and as a result require little or no = change to=09 continue to operate in a new link layer architecture or a = mixture of=09 them.=09 =09 The Smart Grid is likely to see a similar evolution over = time.=09 Consider the Home Area Network (HAN) as a readily = understandable=09 small network. At this juncture, technologies proposed for=09= residential networks include IEEE P1901 (Homeplug), IEEE = 802.15.4g=09 (Zigbee), and IEEE 802.11 (WiFi, commonly deployed today and = used by=09 some high end appliances). It is reasonable to expect other=09= technologies to be developed in the future. As the Zigbee = Alliance=09 has learned (and as a resulted incorporated the IPS in Secure = Energy=09 Profile 2.0), there is significant value in providing a = virtual=09 address that is mapped to interfaces or nodes attached to = each of=09 those technologies.=09 =09 There are two possible communication models within the HAN, = both of=09 which are likely to be useful. Devices may communicate = directly with=09 each other, or they may be managed by some central = controller. An=09 example of direct communications might be a light switch that=09= directly commands a lamp to turn on or off. An example of = indirect=09 communications might be a control application in a Customer = or=09 Building that accepts telemetry from a thermostat, applies = some form=09 of policy, and controls the heating and air conditioning = systems. In=09 addition, there are high end appliances in the market today = that use=09 residential broadband to communicate with their = manufacturers, and=09 obviously the meter needs to communicate with the utility.=09 =09 Utility NAN=09 /=09 /=09 +----+-----+ +--+ +--+ +--+=09 | Meter | |D1| |D2| |D3|=09 +-----+----+ ++-+ ++-+ ++-+=09 | | | |=09 ----+-+-------+----+----+---- IEEE 802.15.4=09 |=09 +--+---+=09 |Router+------/------ Residential Broadband=09 +--+---+=09 |=09 ----+---------+----+----+---- IEEE P1901=09 | | |=09 ++-+ ++-+ ++-+=09 |D4| |D5| |D6|=09 +--+ +--+ +--+=09 =09 Figure 7: Home Area Network=09 =09 Figure 7 shows a simple network containing IEEE 802.15.4 and = IEEE=09 1901 domains. It shows the connectivity between them as a = router=09 separate from the EMS. This is for clarity; the two could of = course=09 be incorporated into a single system, and one could imagine=09= appliances that want to communicate with their manufacturers=09= supporting both a HAN interface and a WiFi interface rather = than=09 depending on the router. These are all manufacturer design=09= decisions.=09 =09 A.1.1. HAN Routing=09 =09 The HAN can be seen as communicating with two kinds of = non-HAN=09 networks. One is the home LAN, which may in turn be attached = to the=09 Internet, and will generally either derive its prefix from = the=09 upstream ISP or use a self-generated ULA. Another is the = utility's=09 NAN, which through an ESI provides utility connectivity to = the HAN;=09 in this case the HAN will be addressed by a self-generated = ULA (note,=09 however, that in some cases ESI may also provide a prefix via = DHCP=09 [RFC3315]). In addition, the HAN will have link-local = addresses that=09 can be used between neighboring nodes. In general, an HAN = will be=09 comprised of both 802.15.4, 802.11 (and possibly other) = networks.=09 =09 The ESI is node on the user's residential network, and will = not=09 typically provide stateful packet forwarding or firewall = services=09 between the HAN and the utility network(s). In general, the = meter/=09 ESI is just a node on the home network. However, the ESI = must be=09 capable of understanding that most home networks are not = 802.15.4=09 enabled (rather, they are typically 802.11 networks), and = that it=09 must be capable of setting up ad-hoc networks between various = sensors=09 in the home (e.g., betweeen the meter and say, a thermostat) = in the=09 event there aren't other networks available.=09 =09 A.1.2. HAN Security=09 =09 In any network, we have a variety of threats and a variety of=09= possible mitigations. These include, at minimum:=09 =09 Link Layer: Why is your machine able to talk in my network? = The=09 WiFi SSIDs often use some form of authenticated access = control,=09 which may be a simple encrypted password mechanism or may = use a=09 combination of encryption and IEEE 802.1X+EAP-TLS = Authentication/=09 Authorization to ensure that only authorized communicants = can use=09 it. If a LAN has a router attached, the router may also = implement=09 a firewall to filter remote accesses.=09 =09 Network Layer: Given that your machine is authorized access = to my=09 network, why is your machine talking with my machine? = IPsec is a=09 way of ensuring that computers that can use a network are = allowed=09 to talk with each other, may also enforce confidentiality, = and may=09 provide VPN services to make a device or network appear to = be part=09 of a remote network.=09 =09 Application: Given that your machine is authorized access to = my=09 network and my machine, why is your application talking = with my=09 application? The fact that your machine and mine are = allowed to=09 talk for some applications doesn't mean they are allowed = to for=09 all applications. (D)TLS, https, and other such = mechanisms enable=09 an application to impose application-to-application = controls=09 similar to the network layer controls provided by IPsec.=09= =09 Remote Application: How do I know that the data I received = is the=09 data you sent? Especially in applications like electronic = mail,=09 where data passes through a number of intermediaries that = one may=09 or may not really want munging it (how many times have you = seen a=09 URL broken by a mail server?), we have tools (DKIM, = S/MIME, and=09 W3C XML Signatures to name a few) to provide = non-repudiability and=09 integrity verification. This may also have legal = ramifications:=09 if a record of a meter reading is to be used in billing, = and the=09 bill is disputed in court, one could imagine the court = wanting=09 proof that the record in fact came from that meter at that = time=09 and contained that data.=09 =09 Application-specific security: In addition, applications = often=09 provide security services of their own. The fact that I = can=09 access a file system, for example, doesn't mean that I am=09= authorized to access everything in it; the file system may = well=09 prevent my access to some of its contents. Routing = protocols like=09 BGP obsess with the question "what statements that my peer = made am=09 I willing to believe". And monitoring protocols like SNMP = may not=09 be willing to answer every question they are asked, = depending on=09 access configuration.=09 =09 Devices in the HAN want controlled access to the LAN in = question for=09 obvious reasons. In addition, there should be some form of = mutual=09 authentication between devices - the lamp controller will = want to=09 know that the light switch telling it to change state is the = right=09 light switch, for example. The EMS may well want strong=09 authentication of accesses - the parents may not want the = children=09 changing the settings, and while the utility and the customer = are=09 routinely granted access, other parties (especially parties = with=09 criminal intent) need to be excluded.=09 =09 A.2. Model 1: AMI with separated domains=09 =09 With the background given in Appendix A.1, we can now discuss = the use=09 of IP (IPv4 or IPv6) in the AMI.=09 =09 In this first model, consider the three domains in Figure 6 = to=09 literally be separate administrative domains, potentially = operated by=09 different entities. For example, the NAN could be a WiMAX = network=09 operated by a traditional telecom operator, the utility's = network=09 (including the collector) is its own, and the residential = network is=09 operated by the resident. In this model, while = communications=09 between the collector and the Meter are normal, the utility = has no=09 other access to appliances in the home, and the collector = doesn't=09 directly forward messages from the NAN upstream.=09 =09 In this case, as shown in Figure 7, it would make the most = sense to=09 design the collector, the Meter, and the EMS as hosts on the = NAN -=09 design them as systems whose applications can originate and = terminate=09 exchanges or sessions in the NAN, but not forward traffic = from or to=09 other devices.=09 =09 In such a configuration, Demand Response has to be performed = by=09 having the EMS accept messages such as price signals from the = "pole=09 top", apply some form of policy, and then orchestrate actions = within=09 the home. Another possibility is to have the EMS communicate = with=09 the ESI located in the meter. If the thermostat has high = demand and=09 low demand (day/night or morning/day/evening/night) settings, = Demand=09 Response might result in it moving to a lower demand setting, = and the=09 EMS might also turn off specified circuits in the home to = diminish=09 lighting.=09 =09 In this scenario, QoS issues reportedly arise when high = precedence=09 messages must be sent through the collector to the home; if = the=09 collector is occupied polling the meters or doing some other = task,=09 the application may not yield control of the processor to the=09= application that services the message. Clearly, this is = either an=09 application or an OS problem; applications need to be = designed in a=09 manner that doesn't block high precedence messages. The = collector=09 also needs to use appropriate NAN services, if they exist, to = provide=09 the NAN QoS it needs. For example, if WiMax is in use, it = might use=09 a routine-level service for normal exchanges but a higher = precedence=09 service for these messages.=09 =09 A.3. Model 2: AMI with neighborhood access to the home=09 =09 In this second model, let's imagine that the utility directly=09= accesses appliances within the HAN. Rather than expect an = EMS to=09 respond to price signals in Demand Response, it directly = commands=09 devices like air conditioners to change state, or throws = relays on=09 circuits to or within the home.=09 =09 +----------+ +--+ +--+ +--+=09 | Meter | |D1| |D2| |D3|=09 +-----+----+ ++-+ ++-+ ++-+=09 | | | |=09 ----+-+-------+----+----+---- IEEE 802.15.4=09 |=09 +--+---+=09 | +------/------ NAN=09 |Router|=09 | +------/------ Residential Broadband=09 +--+---+=09 |=09 ----+---------+----+----+---- IEEE P1901=09 | | |=09 ++-+ ++-+ ++-+=09 |D4| |D5| |D6|=09 +--+ +--+ +--+=09 =09 Figure 8: Home Area Network=09 =09 In this case, as shown in Figure 8, the Meter, and EMS as = hosts on=09 the HAN, and there is a router between the HAN and the NAN.=09= =09 As one might imagine, there are serious security = considerations in=09 this model. Traffic between the NAN and the residential = broadband=09 network should be filtered, and the issues raised in Appendix = A.1.2=09 take on a new level of meaning. One of the biggest threats = may be a=09 legal or at least a public relations issue; if the utility=09 intentionally disables a circuit in a manner or at a time = that=09 threatens life (the resident's kidney dialysis machine is on = it, or a=09 respirator, for example) the matter might make the papers.=09 Unauthorized access could be part of juvenile pranks or other = things=09 as well. So one really wants the appliances to only obey = commands=09 under strict authentication/authorization controls.=09 =09 In addition to the QoS issues raised in Appendix A.2, there = is the=09 possibility of queuing issues in the router. In such a case, = the IP=09 datagrams should probably use the Low-Latency Data Service = Class=09 described in [RFC4594], and let other traffic use the = Standard=09 Service Class or other service classes.=09 =09 A.4. Model 3: Collector is an IP router=09 =09 In this third model, the relationship between the NAN and the = HAN is=09 either as in Appendix A.2 or Appendix A.3; what is different = is that=09 the collector may be an IP router. In addition to whatever=09= autonomous activities it is doing, it forwards traffic as an = IP=09 router in some cases.=09 =09 As and analogous to Appendix A.3, there are serious security=09= considerations in this model. Traffic being forwarded should = be=09 filtered, and the issues raised in Appendix A.1.2 take on a = new level=09 of meaning - but this time at the utility mainframe. = Unauthorized=09 access is likely similar to other financially-motivated = attacks that=09 happen in the Internet, but presumably would be coming from = devices=09 in the HAN that have been co-opted in some way. One really = wants the=09 appliances to only obey commands under strict authentication/=09= authorization controls.=09 =09 In addition to the QoS issues raised in Appendix A.2, there = is the=09 possibility of queuing issues in the collector. In such a = case, the=09 IP datagrams should probably use the Low-Latency Data Service = Class=09 described in [RFC4594], and let other traffic use the = Standard=09 Service Class or other service classes.=09 = =09 Authors' Addresses Authors' Addresses=09 =09 Fred Baker Fred Baker=09 Cisco Systems Cisco Systems=09 Santa Barbara, California 93117 Santa Barbara, = California 93117=09 USA USA=09 =09 Email: fred@cisco.com Email: fred@cisco.com=09 =09 David Meyer David Meyer=09 =09 End of changes. 60 change blocks.=20 149 lines changed or deleted 758 lines changed or added=09 This html diff was produced by rfcdiff 1.40. The latest version is = available from http://tools.ietf.org/tools/rfcdiff/=20 --Apple-Mail-46-487591200 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii =20 =20 =20 Diff: draft-baker-ietf-core-07.txt - = sg-ietf-compendium.txt=20 =20

On Oct 25, 2010, at 11:29 AM, IETF I-D Submission Tool = wrote:


A new version of I-D, = draft-baker-ietf-core-09.txt has been successfully submitted by Fred = Baker and posted to the IETF repository.

Filename: =  draft-baker-ietf-core
Revision: =  09
Title:  Internet Protocols for the = Smart Grid
Creation_date:  2010-10-25
WG ID: =  Independent Submission
Number_of_pages: = 57

Abstract:
This note identifies the key protocols of the = Internet Protocol Suite
for use in the Smart Grid.  The target = audience is those people
seeking guidance on how to construct an = appropriate Internet Protocol
Suite profile for the Smart Grid. =  In practice, such a profile would
consist of selecting what is = needed for Smart Grid deployment from
the picture presented = here.

=20 =20 =20 = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
< draft-baker-ietf-core-07.txt  =  sg-ietf-compendium.txt 
Network Working Group = F. Baker Network Working Group = F. Baker
Internet-Draft = D. Meyer Internet-Draft = D. Meyer
Intended status: Informational = Cisco Systems Intended status: = Informational Cisco Systems
Expires: February 18, 2011 = August 17, 2010 Expires: April 28, 2011 = October 25, 2010
= Internet Protocols for the Smart Grid Internet Protocols for the Smart = Grid
= draft-baker-ietf-core-07 = draft-baker-ietf-core-09
Abstract Abstract
= This note identifies the key protocols of the Internet Protocol = Suite This note identifies the key = protocols of the Internet Protocol Suite
= for use in the Smart Grid. The target audience is those people = for use in the Smart Grid. The target = audience is those people
= seeking guidance on how to construct an appropriate Internet = Protocol seeking guidance on how to = construct an appropriate Internet Protocol
= Suite profile for the Smart Grid. In practice, such a profile = would Suite profile for the Smart = Grid. In practice, such a profile would
= consist of selecting what is needed for Smart Grid deployment = from consist of selecting what is = needed for Smart Grid deployment from
= the picture presented here. the = picture presented here.
=
skipping to change at page 1, line = 35 skipping to = change at page 1, line 35
= Internet-Drafts are working documents of the Internet = Engineering Internet-Drafts are = working documents of the Internet Engineering
= Task Force (IETF). Note that other groups may also distribute = Task Force (IETF). Note that other groups = may also distribute
= working documents as Internet-Drafts. The list of current = Internet- working documents as = Internet-Drafts. The list of current Internet-
= Drafts is at http://datatracker.ie= tf.org/drafts/current/. Drafts = is at http://datatracker.ie= tf.org/drafts/current/.
= Internet-Drafts are draft documents valid for a maximum of six = months Internet-Drafts are draft = documents valid for a maximum of six months
= and may be updated, replaced, or obsoleted by other documents at = any and may be updated, replaced, = or obsoleted by other documents at any
= time. It is inappropriate to use Internet-Drafts as reference = time. It is inappropriate to use = Internet-Drafts as reference
= material or to cite them other than as "work in progress." = material or to cite them other than as "work = in progress."
= This Internet-Draft will expire on February = 18, 2011. This = Internet-Draft will expire on April 28, = 2011.
Copyright Notice Copyright Notice
= Copyright (c) 2010 IETF Trust and the persons identified as the = Copyright (c) 2010 IETF Trust and the = persons identified as the
= document authors. All rights reserved. = document authors. All rights reserved.
= This document is subject to BCP 78 and the IETF Trust's Legal = This document is subject to BCP 78 and the = IETF Trust's Legal
= Provisions Relating to IETF Documents = Provisions Relating to IETF Documents
= (http://trustee.ietf.org/lice= nse-info) in effect on the date of = (http://trustee.ietf.org/lice= nse-info) in effect on the date of
= publication of this document. Please review these documents = publication of this document. Please review = these documents
=
skipping to change at page 2, line = 19 skipping to = change at page 2, line 19
= 2. The Internet Protocol Suite . . . . . . . . . . . . . . . . . = 5 2. The Internet Protocol Suite = . . . . . . . . . . . . . . . . . 5
= 2.1. Internet Protocol Layers . . . . . . . . . . . . . . . . . = 5 2.1. Internet Protocol Layers = . . . . . . . . . . . . . . . . . 5
= 2.1.1. Application . . . . . . . . . . . . . . . . . . . . . = 6 2.1.1. Application . . . . = . . . . . . . . . . . . . . . . . 6
= 2.1.2. Transport . . . . . . . . . . . . . . . . . . . . . . = 7 2.1.2. Transport . . . . . = . . . . . . . . . . . . . . . . . 7
= 2.1.3. Network . . . . . . . . . . . . . . . . . . . . . . . = 7 2.1.3. Network . . . . . . = . . . . . . . . . . . . . . . . . 7
= 2.1.3.1. Internet Protocol . . . . . . . . . . . . . . . . = 8 2.1.3.1. Internet Protocol = . . . . . . . . . . . . . . . . 8
= 2.1.3.2. Lower layer networks . . . . . . . . . . . . . . . = 8 2.1.3.2. Lower layer = networks . . . . . . . . . . . . . . . 8
= 2.1.4. Media layers: Physical and Link . . . . . . . . . . . = 8 2.1.4. Media layers: = Physical and Link . . . . . . . . . . . 8
= 2.2. Security issues . . . . . . . . . . . . . . . . . . . . . = 8 2.2. Security issues . . . . = . . . . . . . . . . . . . . . . . 8
= 2.2.1. Physical security . . . . . . . . . . . . . . . . . . = 9 2.2.1. Physical security . = . . . . . . . . . . . . . . . . . 9
= 2.2.2. Session identification . . . = . . . . . . . . . . . . . 9 = 2.2.2. Session Authentication . . . . . . = . . . . . . . . . . 9
= 2.2.3. Confidentiality . . . . . . . . . . . . . . . . . . . = 10 2.2.3. Confidentiality . . = . . . . . . . . . . . . . . . . . 10
= 2.3. Network Infrastructure . . . . . . . . . . . . . . . . . . = 11 2.3. Network Infrastructure . = . . . . . . . . . . . . . . . . . 11
= 2.3.1. Domain Name System (DNS) . . . . . . . . . . . . . . . = 11 2.3.1. Domain Name System = (DNS) . . . . . . . . . . . . . . . 11
= 2.3.2. Network Management . . . . . . . . . . . . . . . . . . = 11 2.3.2. Network Management . = . . . . . . . . . . . . . . . . . 11
= 3. Specific protocols . . . . . . . . . . . . . . . . . . . . . . = 11 3. Specific protocols . . . . . = . . . . . . . . . . . . . . . . . 11
= 3.1. Security solutions . . . . . . . . . . . . . . . . . . . . = 12 3.1. Security solutions . . . = . . . . . . . . . . . . . . . . . 12
= 3.1.1. Session identification, authentication, 3.1.1. Session identification, = authentication,
= authorization, and accounting . . . . . . . . . . . . = 12 authorization, and = accounting . . . . . . . . . . . . 12
= 3.1.2. IP Security Architecture (IPsec) . . . . . . . . . . . = 12 3.1.2. IP Security = Architecture (IPsec) . . . . . . . . . . . 12
= 3.1.3. Transport Layer Security (TLS) . . . . . . . . . . . . = 12 = 3.1.3. Transport Layer Security (TLS) . . . . . . . . . . . . 13
= 3.1.4. Secure/Multipurpose Internet Mail Extensions = 3.1.4. Secure/Multipurpose Internet = Mail Extensions
= (S/MIME) . . . . . . . . . . . . . . . . . . . . . . . = 13 = (S/MIME) . . . . . . . . . . . . . . . . . . . . . . . 14
= 3.2. Network Layer . . . . . . . . . . . . . . . . . . . . . . = 13 = 3.2. Network Layer . . . . . . . . . . . . . . . . . . . . . . 14
= 3.2.1. IPv4/IPv6 Coexistence Advice . . . . . . . . . . . . . = 13 = 3.2.1. IPv4/IPv6 Coexistence Advice . . . . . . . . . . . . . 14
= 3.2.1.1. Dual Stack Coexistence . . . . . . . . . . . . . . = 14 3.2.1.1. Dual Stack = Coexistence . . . . . . . . . . . . . . 14
= 3.2.1.2. Tunneling Mechanism . . . . . . . . . . . . . . . = 14 = 3.2.1.2. Tunneling Mechanism . . . . . . . . . . . . . . . 15
= 3.2.1.3. Translation between IPv4 and IPv6 Networks . . . . = 14 = 3.2.1.3. Translation between IPv4 and IPv6 Networks . . . . 15
= 3.2.2. Internet Protocol Version 4 . . . . . . . . . . . . . = 15 = 3.2.2. Internet Protocol Version 4 . . . . . . . . . . . . . 16
= 3.2.2.1. IPv4 Address Allocation and Assignment . . . . . . = 16 = 3.2.2.1. IPv4 Address Allocation and Assignment . . . . . . 17
= 3.2.2.2. IPv4 Unicast Routing . . . . . . . . . . . . . . . = 16 = 3.2.2.2. IPv4 Unicast Routing . . . . . . . . . . . . . . . 17
= 3.2.2.3. IPv4 Multicast Forwarding and Routing . . . . . . = 16 = 3.2.2.3. IPv4 Multicast Forwarding and Routing . . . . . . 17
= 3.2.3. Internet Protocol Version 6 . . . . . . . . . . . . . = 17 = 3.2.3. Internet Protocol Version 6 . . . . . . . . . . . . . 18
= 3.2.3.1. IPv6 Address Allocation and Assignment . . . . . . = 17 = 3.2.3.1. IPv6 Address Allocation and Assignment . . . . . . 18
= 3.2.3.2. IPv6 Routing . . . . . . . . . . . . . . . . . . . = 18 = 3.2.3.2. IPv6 Routing . . . . . . . . . . . . . . . . . . . 19
= 3.2.4. Routing for IPv4 and IPv6 . . . . . . . . . . . . . . = 18 = 3.2.4. Routing for IPv4 and IPv6 . . . . . . . . . . . . . . 19
= 3.2.4.1. Routing Information Protocol . . . . . . . . . . . = 18 = 3.2.4.1. Routing Information Protocol . . . . . . . . . . . 19
= 3.2.4.2. Open Shortest Path First . . . . . . . . . . . . . = 19 3.2.4.2. Open Shortest = Path First . . . . . . . . . . . . . 19
= 3.2.4.3. ISO Intermediate System to Intermediate System . . = 19 = 3.2.4.3. ISO Intermediate System to Intermediate System . . 20
= 3.2.4.4. Border Gateway Protocol . . . . . . . . . . . . . = 19 = 3.2.4.4. Border Gateway Protocol . . . . . . . . . . . . . 20
= 3.2.4.5. Dynamic MANET On-demand (DYMO) Routing . . . . . . = 20 3.2.4.5. Dynamic MANET = On-demand (DYMO) Routing . . . . . . 20
= 3.2.4.6. Optimized Link State Routing Protocol . . . . . . = 20 = 3.2.4.6. Optimized Link State Routing Protocol . . . . . . 21
= 3.2.4.7. Routing for Low power and Lossy Networks . . . . . = 20 = 3.2.4.7. Routing for Low power and Lossy Networks . . . . . 21
= 3.2.5. IPv6 Multicast Forwarding and Routing . . . . . . . . = 20 = 3.2.5. IPv6 Multicast Forwarding and Routing . . . . . . . . 22
= 3.2.5.1. Protocol-Independent Multicast Routing . . . . . . = 21 = 3.2.5.1. Protocol-Independent Multicast Routing . . . . . . 22
= 3.2.6. Adaptation to lower layer networks and link layer = 3.2.6. Adaptation to lower layer = networks and link layer
= protocols . . . . . . . . . . . . . . . . . . . . . . = 21 = protocols . . . . . . . . . . . . . . . . . . . . . . 23
= 3.3. Transport Layer . . . . . . . . . . . . . . . . . . . . . = 22 = 3.3. Transport Layer . . . . . . . . . . . . . . . . . . . . . 23
= 3.3.1. User Datagram Protocol (UDP) . . . . . . . . . . . . . = 22 = 3.3.1. User Datagram Protocol (UDP) . . . . . . . . . . . . . 23
= 3.3.2. Transmission Control Protocol (TCP) . . . . . . . . . = 22 = 3.3.2. Transmission Control Protocol (TCP) . . . . . . . . . 24
= 3.3.3. Stream Control Transmission Protocol (SCTP) . . . . . = 23 = 3.3.3. Stream Control Transmission Protocol (SCTP) . . . . . 24
= 3.3.4. Datagram Congestion Control Protocol (DCCP) . . . . . = 23 = 3.3.4. Datagram Congestion Control Protocol (DCCP) . . . . . 25
= 3.4. Infrastructure . . . . . . . . . . . . . . . . . . . . . . = 24 = 3.4. Infrastructure . . . . . . . . . . . . . . . . . . . . . . 25
= 3.4.1. Domain Name System . . . . . . . . . . . . . . . . . . = 24 = 3.4.1. Domain Name System . . . . . . . . . . . . . . . . . . 25
= 3.4.2. Dynamic Host Configuration . . . . . . . . . . . . . . = 24 = 3.4.2. Dynamic Host Configuration . . . . . . . . . . . . . . 26
3.5. Service and Resource = Discovery . . . . . . . . . . . . . . 24 3.4.3. Network Time . . . . . . . . . . = . . . . . . . . . . . 26
3.5.1. Service = Discovery . . . . . . . . . . . . . . . . . . 24 3.5. Network Management . . . . . . . . . = . . . . . . . . . . . 26
= 3.5.2. Resource Discovery . . . . . . . . . . . . . . . . = 25 3.5.1. Simple Network Management Protocol = (SNMP) . . . . . . 26
3.6. Other = Applications . . . . . . . . . . . . . . . . . . . . 26 = 3.5.2. Network Configuration (NETCONF) Protocol = . . . . . . . 27
3.6.1. Network = Time . . . . . . . . . . . . . . . . . . . . . 26 3.6. Service and Resource Discovery . . . = . . . . . . . . . . . 28
3.6.2. Session = Initiation Protocol . . . . . . . . . . . . . 26 3.6.1. Service Discovery . . . . . . . = . . . . . . . . . . . 28
3.6.3. = Calendaring . . . . . . . . . . . . . . . . . . . . . 27 3.6.2. Resource Discovery . . . . . . . = . . . . . . . . . . . 28
= 4. A simplified view of the business architecture . . . . . . . . = 27 3.7. Other Applications . . . . . . . . . = . . . . . . . . . . . 29
= 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . = 31 3.7.1. Session Initiation Protocol . . = . . . . . . . . . . . 29
= 6. Security Considerations . . . . . . . . . . . . . . . . . . . = 32 3.7.2. Calendaring . . . . . . . . . . = . . . . . . . . . . . 30
= 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . = 32 = 4. A simplified view of the business architecture . . . . . . . . 30
= 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . = 32 = 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
= 8.1. Normative References . . . . . . . . . . . . . . . . . . . = 32 = 6. Security Considerations . . . . . . . . . . . . . . . . . . . 35
= 8.2. Informative References . . . . . . . . . . . . . . . . . . = 32 = 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
= Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . = 44 = 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
8.1. = Normative References . . . . . . . . . . . . . . . . . . . 35
8.2. = Informative References . . . . . . . . . . . . . . . . . . 35
Appendix A. Example: Advanced Metering = Infrastructure . . . . . . 49
A.1. How to structure a network . . . . . . . . . = . . . . . . . 51
A.1.1. HAN Routing . . . . . . . . . . . . . . = . . . . . . . 53
A.1.2. HAN Security . . . . . . . . . . . . . . = . . . . . . . 53
A.2. Model 1: AMI with separated domains . . . . = . . . . . . . 54
A.3. Model 2: AMI with neighborhood access to the = home . . . . 55
A.4. Model 3: Collector is an IP router . . . . . = . . . . . . . 56
Authors' = Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57
1. = Introduction 1. Introduction
= This document provides Smart Grid designers with advice on how = to This document provides Smart = Grid designers with advice on how to
= best "profile" the Internet Protocol Suite (IPS) for use on = with best "profile" the Internet = Protocol Suite (IPS) for use on with
= Smart Grids. It provides an overview of the IPS and the key = Smart Grids. It provides an overview of the = IPS and the key
= protocols that are critical in integrating Smart Grid devices into = an protocols that are critical in = integrating Smart Grid devices into an
= IP-based infrastructure. IP-based = infrastructure.
= The IPS provides options for several key architectural = components. The IPS provides = options for several key architectural components.
=
skipping to change at page 4, line = 45 skipping to = change at page 4, line 45
= o IPv6 Node Requirements [RFC4294], = o IPv6 Node Requirements [RFC4294],
= At this writing, RFC 4294 is in the process of being updated, = in At this writing, RFC 4294 is in = the process of being updated, in
= [I-D.ietf-6man-node-req-bis]. = [I-D.ietf-6man-node-req-bis].
= This document is intended to provide Smart Grid architects and = This document is intended to provide Smart = Grid architects and
= designers with a compendium of relevant RFCs (and to some = extent designers with a compendium = of relevant RFCs (and to some extent
= Internet Drafts), and is organized as an annotated list of RFCs. = To Internet Drafts), and is = organized as an annotated list of RFCs. To
= that end, the remainder of this document is organized as = follows: that end, the remainder of = this document is organized as follows:
= Section 2 describes the Internet Architecture and its protocol = suite. =
= Section 3 outlines the set of protocols that will be useful in = Smart o Section 2 describes the Internet Architecture = and its protocol
= Grid deployment. Finally, Section 4 provides an overview of = the suite.
= business architecture embodied in the design and deployment of = the =
= IPS. o Section 3 outlines the set of protocols that = will be useful in
Smart Grid = deployment.
=
o Finally, Section 4 provides an overview of = the business
architecture = embodied in the design and deployment of the IPS.
2. = The Internet Protocol Suite 2. The = Internet Protocol Suite
= Before enumerating the list of Internet protocols relevant to = Smart Before enumerating the list = of Internet protocols relevant to Smart
= Grid, we discuss the layered architecture of the IPS, the = functions Grid, we discuss the = layered architecture of the IPS, the functions
= of the various layers, and their associated protocols. of the various layers, and their associated = protocols.
2.1.= Internet Protocol Layers 2.1. = Internet Protocol Layers
= While Internet architecture uses the definitions and language = similar While Internet architecture = uses the definitions and language similar
=
skipping to change at page 8, line = 49 skipping to = change at page 8, line 49
= At the lowest layer of the IP architecture, data is encoded in = At the lowest layer of the IP architecture, = data is encoded in
= messages and transmitted over the physical media. While the = IETF messages and transmitted over = the physical media. While the IETF
= specifies algorithms for carrying IPv4 and IPv6 various media = types, specifies algorithms for = carrying IPv4 and IPv6 various media types,
= it rarely actually defines the media - it happily uses = specifications it rarely actually = defines the media - it happily uses specifications
= from IEEE, ITU, and other sources. = from IEEE, ITU, and other sources.
2.2.= Security issues 2.2. Security = issues
= While it is popular to complain about the security of the = Internet, While it is popular to = complain about the security of the Internet,
= solutions to many Internet security problems already exist but = have solutions to many Internet = security problems already exist but have
= not been widely deployed. Internet = security solutions attempt to = either not been widely deployed, may impact critical = performance
= mitigate a set of known threats at a specified cost; = addressing = criteria, or require security measures outside the IPS. = Internet
= security issues requires first a threat analysis and assessment and = a security solutions attempt to = mitigate a set of known threats within
= set of mitigations appropriate to the threats. Since we have = threats the = IPS domain at a specified cost; addressing security = issues
= at every layer, we should expect to find mitigations at every = layer. requires first a threat = analysis and assessment and a set of
mitigations = appropriate to the threats. Since we have threats at
every layer, we = should expect to find mitigations at every layer.
2.2.1. Physical security 2.2.1. Physical security
= At the physical and data link layers, threats generally center = on At the physical and data link = layers, threats generally center on
= physical attacks on the network - the effects of backhoes, = physical attacks on the network - the = effects of backhoes,
= deterioration of physical media, and various kinds of = environmental deterioration of = physical media, and various kinds of environmental
= noise. Radio-based networks are subject to signal fade due to = noise. Radio-based networks are subject to = signal fade due to
= distance, interference, and environmental factors; it is widely = noted distance, interference, and = environmental factors; it is widely noted
= that IEEE 802.15.4 networks frequently place a metal ground = plate that IEEE 802.15.4 networks = frequently place a metal ground plate
= between the meter and the device that manages it. Fiber was at = one between the meter and the = device that manages it. Fiber was at one
=
skipping to change at page 9, line = 26 skipping to = change at page 9, line 28
= learned to tap it by bending the fiber and collecting = incidental learned to tap it by = bending the fiber and collecting incidental
= light, and we have learned about backhoes. As a result, some = light, and we have learned about backhoes. = As a result, some
= installations encase fiber optic cable in a pressurized sheath, = both installations encase fiber = optic cable in a pressurized sheath, both
= to quickly identify the location of a cut and to make it more = to quickly identify the location of a cut = and to make it more
= difficult to tap. difficult to = tap.
= While there are protocol behaviors that can detect certain classes = of While there are protocol = behaviors that can detect certain classes of
= physical faults, such as keep-alive exchanges, physical security = is physical faults, such as = keep-alive exchanges, physical security is
= generally not considered to be a protocol problem. generally not considered to be a protocol = problem.
2.2.2. Session identification 2.2.2. Session Authentication
= At the transport and application layers and in lower layer = networks At the transport and = application layers and in lower layer networks
= where dynamic connectivity such as ATM Switched Virtual = Circuits where dynamic connectivity = such as ATM Switched Virtual Circuits
= (SVCs) or "dial" connectivity are in use, there tend to be = several (SVCs) or "dial" = connectivity are in use, there tend to be several
= different classes of authentication/authorization requirements. = The different classes of = authentication/authorization requirements. The
= basic requirements that must be satisfied are: basic requirements that must be satisfied = are:
= 1. Verify that peers are appropriate partners; this generally = means 1. Verify that peers are = appropriate partners; this generally means
= knowing "who" they are and that they have a "need to know" or = are knowing "who" they are and = that they have a "need to know" or are
= trusted sources. trusted = sources.
=
skipping to change at page 10, line = 9 skipping to = change at page 10, line 11
= against modification attacks. = against modification attacks.
= In other words, both the communications channel itself and = message In other words, both the = communications channel itself and message
= exchanges (both by knowing the source of the information and to = have exchanges (both by knowing the = source of the information and to have
= proof of its validity) must be secured. Three examples suffice = to proof of its validity) must be = secured. Three examples suffice to
= illustrate the challenges. = illustrate the challenges.
= One common attack against a TCP session is to bombard the = session One common attack against a = TCP session is to bombard the session
= with reset messages. Other attacks against TCP include the = "SYN with reset messages. Other = attacks against TCP include the "SYN
= flooding" attack, in which an attacker attempts to exhaust the = memory flooding" attack, in which = an attacker attempts to exhaust the memory
= of the target by creating TCP state. Experience has shown that = by of the target by creating TCP = state. In particular, the = attacker
= including information in the transport header or a related = protocol = attempts to exhaust the target's memory by opening a large number = of
= like the IPsec (Section 3.1.2) or TLS (Section 3.1.3), a host = can unique = TCP connections, each of which is represented by a
= identify legitimate messages and discard mitigate any damage that may Transmission Control Block = (TCB). The attack is successful if the
= have been caused by the attack. attacker can cause the target to fill its memory = with TCBs.
Experience has = shown that by including information in the transport
header or a = related protocol like the IPsec (Section 3.1.2) or TLS
(Section 3.1.3), = a host can identify legitimate messages and discard
the others, thus mitigating any damage that may = have been caused by
the = attack.
= Another common attack involves unauthorized communication with = a Another common attack involves = unauthorized communication with a
= router or a service. For example, an unauthorized party might try = to router or a service. For = example, an unauthorized party might try to
= join the routing system. To protect against such attacks, an = join the routing system. To protect against = such attacks, an
= Internet Service Provider (ISP) should not accept information = from Internet Service Provider = (ISP) should not accept information from
= new peers without verifying that the peer is who it claims to be = and new peers without verifying = that the peer is who it claims to be and
= that the peer is authorized to carry on the exchange of = information. that the peer is = authorized to carry on the exchange of information.
= More generally, in order to secure a communications channel, it = must More generally, in order to = secure a communications channel, it must
= be possible to verify that messages putatively received from a = peer be possible to verify that = messages putatively received from a peer
=
skipping to change at page 11, line = 7 skipping to = change at page 11, line 11
= there frequently a requirement for confidentiality. = Confidentiality there frequently a = requirement for confidentiality. Confidentiality
= arises at several layers, sometimes simultaneously. For = example, arises at several layers, = sometimes simultaneously. For example,
= providers of credit card transaction services want application = layer providers of credit card = transaction services want application layer
= privacy, which can be supplied by encrypting application data or = by privacy, which can be supplied = by encrypting application data or by
= an encrypted transport layer. If an ISP (or other entity) wants = to an encrypted transport layer. = If an ISP (or other entity) wants to
= hide its network structure, it can to encrypt the network layer = hide its network structure, it can to = encrypt the network layer
= header. header.
2.3.= Network Infrastructure 2.3. Network = Infrastructure
= While these are not critical to the = design of a specific system, they = While the following protocols are not = critical to the design of a
= are important to running a network, and as such are surveyed = here. specific system, they are = important to running a network, and as such
are surveyed = here.
2.3.1. Domain Name System (DNS) 2.3.1. Domain Name System (DNS)
= The DNS' main function is translating names to numeric IP = addresses. The DNS' main function = is translating names to numeric IP addresses.
= While this is not critical to running a network, certain = functions While this is not = critical to running a network, certain functions
= are made a lot easier if numeric addresses can be replaced with = are made a lot easier if numeric addresses = can be replaced with
= mnemonic names. This facilitates renumbering of networks and = mnemonic names. This facilitates = renumbering of networks and
= generally improves the manageability and serviceability of the = generally improves the manageability and = serviceability of the
= network. DNS has a set of security extensions called DNSSEC, = which network. DNS has a set of = security extensions called DNSSEC, which
= can be used to provide strong cryptographic authentication to that can = be used to provide strong cryptographic authentication to the
protocol. DNS and = DNSSEC are discussed further in Section 3.4.1. DNS. DNS and DNSSEC = are discussed further in Section 3.4.1.
2.3.2. Network Management 2.3.2. Network Management
= Network management has proven to be a difficult problem. As = such, Network management has proven = to be a difficult problem. As such,
= various solutions have been proposed, implemented, and = deployed. various solutions have = been proposed, implemented, and deployed.
= Each solution has its proponents, all of whom have solid = arguments Each solution has its = proponents, all of whom have solid arguments
= for their viewpoints. The IETF has two major network = management for their viewpoints. = The IETF has two major network management
= solutions for device operation: SNMP, which is ASN.1-encoded and = is solutions for device operation: = SNMP, which is ASN.1-encoded and is
= primarily used for monitoring of system variables and is a = polled primarily used for = monitoring of system variables and is a polled
= architecture, and NetConf [RFC4741], which is XML-encoded and = architecture, and NetConf [RFC4741], which = is XML-encoded and
=
skipping to change at page 11, line = 47 skipping to = change at page 12, line 5
= While the IP Protocol Suite does not have specific solutions = for While the IP Protocol Suite = does not have specific solutions for
= secure provisioning and configuration, these problems have been = secure provisioning and configuration, these = problems have been
= solved using IP protocols in specifications such as DOCSIS 3.0 = solved using IP protocols in specifications = such as DOCSIS 3.0
= [SP-MULPIv3.0]. = [SP-MULPIv3.0].
3. = Specific protocols 3. Specific = protocols
= In this section, having briefly laid out the IP architecture and = some In this section, having = briefly laid out the IP architecture and some
= of the problems that the architecture tries to address, we = introduce of the problems that the = architecture tries to address, we introduce
= specific protocols that might be appropriate to various Smart = Grid specific protocols that might = be appropriate to various Smart Grid
= use cases. Use cases should be analyzed along privacy, AAA, use = cases. Use cases should be analyzed along privacy,
= transport and network solution dimensions. The following = sections Authentication, Authorization, and Accounting = (AAA), transport and
= provide guidance for such analyzes. = network solution dimensions. The following sections provide = guidance
for such = analyzes.
3.1.= Security solutions 3.1. Security = solutions
= As noted, a key consideration in security solutions is a good = threat As noted, a key = consideration in security solutions is a good threat
= analysis coupled with appropriate mitigation strategies at each = analysis coupled with appropriate mitigation = strategies at each
= layer. The following sections outline the security features of = the layer. The following sections = outline the security features of the
= IPS. IPS.
3.1.1. Session identification, authentication, = authorization, and 3.1.1. Session = identification, authentication, authorization, and
= accounting = accounting
=
skipping to change at page 12, line = 34 skipping to = change at page 12, line 39
= The Security Architecture for the Internet Protocol (IPsec) = [RFC4301] The Security Architecture = for the Internet Protocol (IPsec) [RFC4301]
= is a set of control and data protocols that are implemented = between is a set of control and = data protocols that are implemented between
= IPv4 and the chosen transport layer, or in IPv6's security = extension IPv4 and the chosen = transport layer, or in IPv6's security extension
= header. It allows transport layer sessions to communicate in a = way header. It allows transport = layer sessions to communicate in a way
= that is designed to prevent eavesdropping, tampering, or = message that is designed to prevent = eavesdropping, tampering, or message
= forgery. As is typical with IETF specifications, the architecture = is forgery. As is typical with = IETF specifications, the architecture is
= spelled out in a number of documents which specify the specific = spelled out in a number of documents which = specify the specific
= components: the IP Authentication Header (AH) [RFC4302] = Encapsulating components: the IP = Authentication Header (AH) [RFC4302] Encapsulating
= Security Payload (ESP) [RFC4303], Internet Key Exchange (IKEv2) = Security Payload (ESP) [RFC4303], Internet = Key Exchange (IKEv2)
= [RFC4306], Cryptographic Algorithms = [RFC4307], Cryptographic [RFC5996], Cryptographic Algorithms [RFC4307], = Cryptographic
= Algorithm Implementation Requirements for ESP and AH [RFC4835], = and Algorithm Implementation = Requirements for ESP and AH [RFC4835], and
= the use of Advanced Encryption Standard (AES) [RFC4309]. = the use of Advanced Encryption Standard = (AES) [RFC4309].
= IPsec provides two modes: Transport mode and tunnel mode. In = IPsec provides two modes: Transport mode and = tunnel mode. In
= transport mode, IPsec ESP encrypts the transport layer and the = transport mode, IPsec ESP encrypts the = transport layer and the
= application data. In tunnel mode, the source IP datagram is = application data. In tunnel mode, the = source IP datagram is
= encrypted and encapsulated in a second IP header addressed to = the encrypted and encapsulated in a = second IP header addressed to the
= intended decryptor. As might be expected, tunnel mode is = frequently intended decryptor. As = might be expected, tunnel mode is frequently
= used for virtual private networks which need to securely = transmit used for virtual private = networks which need to securely transmit
= data across networks with unknown (or no) other security = properties. data across networks = with unknown (or no) other security properties.
= In both cases, authentication, authorization, and = confidentiality In both cases, = authentication, authorization, and confidentiality
= extend from system to system, and apply to all applications that = the extend from system to system, = and apply to all applications that the
= two systems use. two systems = use.
Note that IPsec can provide non-repudiation when an = asymmetric
authentication algorithm is used with the AH header = and both sender
and receiver keys are used in the authentication = calculation.
However, the default authentication algorithm is = keyed MD5, which
like all symmetric algorithms cannot provide = non-repudiation by
itself (since the sender's key is not used in the = computation). So
while IPsec provides a means of authenticating = network level objects
(packets), these objects are are ephemeral and not = directly
correlated with a particular application. As a = result non-
repudiation is not generally applicable to network = level objects such
as packets.
=
3.1.3. Transport Layer Security (TLS) 3.1.3. Transport Layer Security (TLS)
= Transport Layer Security [RFC5246] and Datagram Transport Layer = Transport Layer Security [RFC5246] and = Datagram Transport Layer
= Security [RFC4347][I-D.ietf-tls-rfc4347-bis] are mechanisms = that Security = [RFC4347][I-D.ietf-tls-rfc4347-bis] are mechanisms that
= travel within the transport layer protocol data unit, meaning = that travel within the transport = layer protocol data unit, meaning that
= they readily traverse network address translators and secure = the they readily traverse network = address translators and secure the
= information exchanges without securing the datagrams exchanged or = the information exchanges without = securing the datagrams exchanged or the
= transport layer itself. Each allows client/server applications = to transport layer itself. Each = allows client/server applications to
= communicate in a way that is designed to prevent eavesdropping, = communicate in a way that is designed to = prevent eavesdropping,
= tampering, or message forgery. Authentication, authorization, = and tampering, or message forgery. = Authentication, authorization, and
= confidentiality exist for a session between specific = applications. confidentiality exist = for a session between specific applications.
= When used in conjunction with IEEE 802.1X [IEEE802.1X], = EAP-TLS In = order to communicate securely, an TLS client and TLS server = must
= [RFC5216] is widely considered to offer = excellent access security to agree on the cryptographic algorithms and keys that = they will use on
= a wired or wireless IEEE 802 LAN (IEEE 802.1X in conjunction = with the = secured connection. In particular, they must agree on = these
= EAP-TLS is the baseline for Zigbee SEP 2.0). Note that one potential items:
drawback of 802.1X technology = is that it requires deployment of
client-side certificates, = which is frequently seen as a deployment o Key Establishment = Algorithm
barrier. =
o Peer Authentication Algorithm
o Bulk Data Encryption Algorithm and key = size
o Digest Algorithm
Since each categories has multiple options, the = number of possible
combinations is large. As a result, TLS does not = allow all possible
combinations of choices; rather it only allows = certain well-defined
combinations known as Cipher Suites. [IEC62351-3] = outlines the use
of different TLS Cipher Suites for use in the Smart = Grid.
=
When used in = conjunction with IEEE 802.1X [IEEE802.1X], both EAP-TLS
[RFC5216] and the Protocol for Carrying Authentication for = Network
Access (PANA) [RFC5193] are widely considered = to offer excellent
access security = to a wired or wireless IEEE 802 LAN (IEEE 802.1X in
conjunction with = EAP-TLS is the baseline for Zigbee SEP 2.0).
3.1.4. Secure/Multipurpose Internet Mail Extensions = (S/MIME) 3.1.4. Secure/Multipurpose = Internet Mail Extensions (S/MIME)
= The S/MIME [RFC2045] [RFC2046] [RFC2047] [RFC4289] [RFC2049] = The S/MIME [RFC2045] [RFC2046] [RFC2047] = [RFC4289] [RFC2049]
= [RFC5750] [RFC5751] [RFC4262] specification was originally = designed [RFC5750] [RFC5751] = [RFC4262] specification was originally designed
= as an extension to SMTP Mail to provide evidence that the = putative as an extension to SMTP = Mail to provide evidence that the putative
= sender of an email message in fact sent it, and that the = content sender of an email message = in fact sent it, and that the content
= received was in fact the content that was sent. As its name = received was in fact the content that was = sent. As its name
= suggests, by extension this is a way of securing any object that = can suggests, by extension this is = a way of securing any object that can
= be exchanged, by any means, and has become one of the most = common be exchanged, by any means, = and has become one of the most common
=
skipping to change at page 15, line = 19 skipping to = change at page 16, line 6
= [I-D.ietf-behave-address-format] = [I-D.ietf-behave-address-format]
= o DNS extensions [I-D.ietf-behave-dns64] o DNS extensions [I-D.ietf-behave-dns64]
= o IP/ICMP Translation Algorithm [I-D.ietf-behave-v6v4-xlate] = o IP/ICMP Translation Algorithm = [I-D.ietf-behave-v6v4-xlate]
= o Translation from IPv6 Clients to IPv4 Servers o Translation from IPv6 Clients to IPv4 = Servers
= [I-D.ietf-behave-v6v4-xlate-stateful] [I-D.ietf-behave-v6v4-xlate-stateful]
= As with IPv4/IPv4 Network Address Translation, translation = between As with IPv4/IPv4 Network = Address Translation, translation between
= IPv4 and IPv6 has limited real world applicability: any application IPv4 and IPv6 has limited real world applicability for an application
= protocol that carries IP addresses and = expects them to be meaningful = protocol which = carry IP addresses in its payload = and expects those
= to both client and server or to both peers will = have trouble when the addresses to be meaningful to both client and = server. However, for
addresses are transparently = translated. However, for those protocols those protocols that do not, protocol translation = can provide a
= that do not, protocol translation can provide a useful = network useful network = extension.
= extension.
= Network-based translation provides for two types of services: = Network-based translation provides for two = types of services:
= stateless (and therefore scalable and load-sharable) = translation stateless (and = therefore scalable and load-sharable) translation
= between IPv4 and IPv6 addresses that embed an IPv4 address in = them, between IPv4 and IPv6 = addresses that embed an IPv4 address in them,
= and stateful translation similar to IPv4/IPv4 translation = between and stateful translation = similar to IPv4/IPv4 translation between
= IPv4 addresses. The stateless mode is straightforward to = implement, IPv4 addresses. The = stateless mode is straightforward to implement,
= but due to the embedding, requires IPv4 addresses to be allocated = to but due to the embedding, = requires IPv4 addresses to be allocated to
= an otherwise IPv6-only network, and is primarily useful for = IPv4- an otherwise IPv6-only = network, and is primarily useful for IPv4-
= accessible servers implemented in the IPv6 network. The = stateful accessible servers = implemented in the IPv6 network. The stateful
= mode allows clients in the IPv6 network to access servers in the = IPv4 mode allows clients in the = IPv6 network to access servers in the IPv4
= network, but does not provide such service for IPv4 clients = accessing network, but does not = provide such service for IPv4 clients accessing
= IPv6 peers or servers with general addresses; it does however = have IPv6 peers or servers with = general addresses; it does however have
= the advantage that it does not require that a unique IPv4 address = be the advantage that it does not = require that a unique IPv4 address be
= embedded in the IPv6 address of hosts using this mechanism. = embedded in the IPv6 address of hosts using = this mechanism.
Finally, note that some networks site networks are IPv6 = only while
some transits networks are IPv4 only. In these = cases it may be
necessary to tunnel IPv6 over IPv4 or translate = between IPv6 and
IPv4.
=
3.2.2. Internet Protocol Version 4 3.2.2. Internet Protocol Version 4
= IPv4 [RFC0791] and the Internet Control Message Protocol = [RFC0792] IPv4 [RFC0791] and the = Internet Control Message Protocol [RFC0792]
= comprise the IPv4 network layer. IPv4 provides unreliable = delivery comprise the IPv4 network = layer. IPv4 provides unreliable delivery
= of datagrams. of datagrams.
= IPv4 also provides for fragmentation and reassembly of long = datagrams IPv4 also provides for = fragmentation and reassembly of long datagrams
= for transmission through networks with small Maximum = Transmission for transmission = through networks with small Maximum Transmission
= Units (MTU). The MTU is the largest packet size that can be = Units (MTU). The MTU is the largest packet = size that can be
= delivered across the network. In addition, the IPS provides = the delivered across the network. = In addition, the IPS provides the
=
skipping to change at page 16, line = 15 skipping to = change at page 17, line 6
= IPv4 originally supported an experimental type of service field = that IPv4 originally supported an = experimental type of service field that
= identified eight levels of operational precedence styled after = the identified eight levels of = operational precedence styled after the
= requirements of military telephony, plus three and later four = bit requirements of military = telephony, plus three and later four bit
= flags that OSI IS-IS for IPv4 (IS-IS) [RFC1195] and OSPF Version = 2 flags that OSI IS-IS for IPv4 = (IS-IS) [RFC1195] and OSPF Version 2
= [RFC2328] interpreted as control traffic; this control traffic = is [RFC2328] interpreted as control = traffic; this control traffic is
= assured of not being dropped when queued or upon receipt even = if assured of not being dropped = when queued or upon receipt even if
= other traffic is being dropped.. These control bits turned out to = be other traffic is being dropped.. = These control bits turned out to be
= less useful than the designers had hoped. They were replaced by = the less useful than the designers = had hoped. They were replaced by the
= Differentiated Services Architecture [RFC2474][RFC2475], which = Differentiated Services Architecture = [RFC2474][RFC2475], which
= contains a six bit code point used to select an algorithm (a = "per-hop contains a six bit code = point used to select an algorithm (a "per-hop
= behavior") to be applied to the datagram. behavior") to be applied to the datagram. The IETF has also produced
a set of Configuration Guidelines for DiffServ = Service Classes
[RFC4594], which describes a set of service classes = that may be
useful to a network operator.
3.2.2.1. IPv4 Address Allocation and Assignment = 3.2.2.1. IPv4 Address Allocation and = Assignment
= IPv4 addresses are administratively assigned, usually using = automated IPv4 addresses are = administratively assigned, usually using automated
= methods, and assigned using the Dynamic Host Configuration = Protocol methods, and assigned = using the Dynamic Host Configuration Protocol
= (DHCP) [RFC2131]. On most interface types, neighboring = equipment (DHCP) [RFC2131]. On = most interface types, neighboring equipment
= identify each other's addresses using Address Resolution = Protocol identify each other's = addresses using Address Resolution Protocol
= (ARP) [RFC0826]. (ARP) = [RFC0826].
3.2.2.2. IPv4 Unicast Routing 3.2.2.2. IPv4 Unicast Routing
=
skipping to change at page 20, line = 41 skipping to = change at page 21, line 32
= can be used in other forms of ad hoc networks. It provides = arbitrary can be used in other = forms of ad hoc networks. It provides arbitrary
= connectivity between device within a distributed subnet. As = with connectivity between device = within a distributed subnet. As with
= protocols designed for wired networks, routing is calculated = and protocols designed for wired = networks, routing is calculated and
= maintained whenever changes are detected, and maintained in = each maintained whenever changes = are detected, and maintained in each
= router's tables. The set of nodes that operate as routers within = the router's tables. The set of = nodes that operate as routers within the
= subnet, however, are fairly fluid, and dependent on this = subnet, however, are fairly fluid, and = dependent on this
= instantaneous topology of the subnet. = instantaneous topology of the subnet.
3.2.4.7. Routing for Low power and Lossy = Networks 3.2.4.7. Routing for Low = power and Lossy Networks
= The RPL: IPv6 Routing Protocol for Low = power and Lossy Networks The IPv6 = Routing Protocol for Low power and Lossy Networks (RPL)
= [I-D.ietf-roll-rpl] xxx = [I-D.ietf-roll-rpl] is= a reactive routing protocol designed for use
in resource constrained networks. Requirements for = resource
constrained networks are defined in [RFC5548], = [RFC5673], [RFC5826],
and [RFC5867].
Briefly, a constrained network is comprised of nodes = that:
o Are built with limited processing power and = memory, and sometimes
energy when operating on = batteries.
o Are interconnected through a low-data-rate = network interface and
potentially vulnerable to communication = instability and low packet
delivery rates.
o Potentially have a mix of roles such as being = able to act as a
host (i.e., generating traffic) and/or a router = (i.e., both
forwarding and generating RPL = traffic).
3.2.5. IPv6 Multicast Forwarding and Routing = 3.2.5. IPv6 Multicast Forwarding and = Routing
= IPv6 specifies both unicast and multicast datagram exchange. = This IPv6 specifies both unicast = and multicast datagram exchange. This
= uses the Multicast Listener Discovery Protocol (MLDv2) = [RFC2710] uses the Multicast = Listener Discovery Protocol (MLDv2) [RFC2710]
= [RFC3590] [RFC3810] [RFC4604] to enable applications to join = [RFC3590] [RFC3810] [RFC4604] to enable = applications to join
= multicast groups, and for most applications uses = Source-Specific multicast groups, = and for most applications uses Source-Specific
= Multicast [RFC4607] for routing and delivery of multicast = messages. Multicast [RFC4607] for = routing and delivery of multicast messages.
= The mechanisms experimentally developed for reliable multicast = in The mechanisms experimentally = developed for reliable multicast in
= IPv4, discussed in Section 3.2.2.3, can be used in IPv6 as = well. IPv4, discussed in Section = 3.2.2.3, can be used in IPv6 as well.
3.2.5.1. Protocol-Independent Multicast Routing = 3.2.5.1. Protocol-Independent Multicast = Routing
= xxx Protocol Independent Multicast - = Dense Mode (PIM-DM): Protocol = A multicast routing protocol has two basic = functions: Building the
= Specification (Revised) [RFC3973] xxx = Protocol Independent Multicast multicast distribution tree and forwarding multicast = traffic.
Multicast routing protocols generally contain a = control plane for
building distribution trees, and a forwarding plane = that uses the
distribution tree when forwarding multicast = traffic.
A the highest level, the multicast model works as = follows: hosts
express their interest in receiving multicast = traffic from a source
by sending a Join message to their first hop router. = That router in
turn sends a Join message upstream towards the root = of the tree,
grafting the router (leaf node) onto the = distribution tree for the
group. Data is delivered down the tree toward the = leaf nodes, which
forward it onto the local network for = delivery.
The initial multicast model deployed in the Internet = was known as
Any-Source Multicast (ASM). In the ASM model any = host could send to
the group, and inter-domain multicast was difficult. = Protocols such
as Protocol Independent Multicast - Dense = Mode (PIM-DM): Protocol
Specification = (Revised) [RFC3973] and Protocol = Independent Multicast
= - Sparse Mode (PIM-SM): Protocol Specification (Revised) = [RFC4601] - Sparse Mode (PIM-SM): = Protocol Specification (Revised) [RFC4601]
= xxx Source-Specific Multicast (SSM) [RFC3569] xxx Source-Specific = were designed for = the ASM model.
Protocol Independent = Multicast [RFC4608] xxx Authentication and
= Confidentiality in Protocol Independent Multicast Sparse = Mode = Many modern multicast deployments use Source-Specific Multicast = (PIM-
(PIM-SM) Link-Local Messages = [RFC5796] xxx SSM) [RFC3569][RFC4608]. In the SSM model, a host = expresses interest
in a "channel", which is comprised of a source = (S) and a group (G).
Distribution tress are rooted the sending host = (called an "(S,G)
tree"). Since only the source S can send on to the = group, SSM has
inherent anti-jamming capability. In addition, = inter-domain
multicast is simplified since it is the = responsibility of the
receivers (rather than the network) to find the = (S,G) channel they
are interested in receiving. This implies that SSM requires = some
form of directory service so that receivers can find = the (S,G)
channels.
3.2.6. Adaptation to lower layer networks and link layer = protocols 3.2.6. Adaptation to lower = layer networks and link layer protocols
= In general, the layered architecture of the Internet enables the = IPS In general, the layered = architecture of the Internet enables the IPS
= to run over any appropriate layer two architecture. The ability = to to run over any appropriate = layer two architecture. The ability to
= change the link or physical layer without having to rethink the = change the link or physical layer without = having to rethink the
= network layer, transports, or applications has been a great = benefit network layer, transports, = or applications has been a great benefit
= in the Internet. in the = Internet.
= Examples of link layer adaptation technology include: Examples of link layer adaptation technology = include:
=
skipping to change at page 24, line = 40 skipping to = change at page 26, line 25
= [RFC2131] or DHCPv6 [RFC3315]. The best argument for the use = of [RFC2131] or DHCPv6 [RFC3315]. = The best argument for the use of
= autoconfiguration is a large number of systems that require = little autoconfiguration is a large = number of systems that require little
= more than a random number as an address; the argument for DHCP = is more than a random number as an = address; the argument for DHCP is
= administrative control. = administrative control.
= There are other parameters that may need to be allocated to = hosts There are other parameters = that may need to be allocated to hosts
= which require administrative configuration; examples include = the which require administrative = configuration; examples include the
= addresses of DNS servers, keys for Secure DNS and Network Time = addresses of DNS servers, keys for Secure = DNS and Network Time
= servers. servers.
3.5. Service and Resource Discovery 3.4.3. Network = Time
The Network Time Protocol was originally designed by = Dave Mills of
the University of Delaware and CSNET, for the = purpose of implementing
a temporal metric in the Fuzzball Routing Protocol = and generally
coordinating time experiments. The current versions = of the time
protocol are the Network Time Protocol = [RFC5905].
=
3.5. Network Management
The IETF has developed two protocols for network = management: SNMP and
NETCONF. SNMP is discussed in Section 3.5.1, and = NETCONF is
discussed in Section 3.5.2.
3.5.1. Simple Network Management Protocol = (SNMP)
The Simple Network Management Protocol, originally = specified in the
late 1980's and having passed through several = revisions, is specified
in several documents:
o An Architecture for Describing Simple Network = Management Protocol
(SNMP) Management Frameworks = [RFC3411]
o Message Processing and Dispatching = [RFC3412]
o SNMP Applications [RFC3413]
o User-based Security Model (USM) for SNMP version = 3 [RFC3414]
o View-based Access Control Model (VACM) = [RFC3415]
o Version 2 of the SNMP Protocol Operations = [RFC3416]
o Transport Mappings [RFC3417]
o Management Information Base (MIB) = [RFC3418]
It provides capabilities for polled and event-driven = activities, and
for both monitoring and configuration of systems in = the field.
Historically, it has been used primarily for = monitoring nodes in a
network. Messages and their constituent data are = encoded using a
profile of ASN.1.
3.5.2. Network Configuration (NETCONF) = Protocol
The NETCONF Configuration Protocol is specified in = one basic
document, with supporting documents for carrying it = over the IPS.
These documents include:
o NETCONF Configuration Protocol = [RFC4741]
o Using the NETCONF Configuration Protocol over = Secure SHell (SSH)
[RFC4742]
o Using NETCONF over the Simple Object Access = Protocol (SOAP)
[RFC4743]
o Using the NETCONF Protocol over the Blocks = Extensible Exchange
Protocol (BEEP) [RFC4744]
o NETCONF Event Notifications = [RFC5277]
o NETCONF over Transport Layer Security (TLS) = [RFC5539]
o Partial Lock Remote Procedure Call (RPC) for = NETCONF [RFC5717]
NETCONF was developed in response to operator = requests for a common
configuration protocol based on ASCII text as = opposed to ASN.1. In
essence, it carries XML-encoded remote procedure = call (RPC) data. In
response to Smart Grid requirements, there is = consideration of a
variant of the protocol that could be used for = polled and event-
driven management activities, and for both = monitoring and
configuration of systems in the = field.
3.6. Service and Resource Discovery
= Service and resource discovery are among the most important = protocols Service and resource = discovery are among the most important protocols
= for constrained resource self-organizing networks. These = include for constrained resource = self-organizing networks. These include
= various sensor networks as well as the Home Area Networks = (HANs), various sensor networks as = well as the Home Area Networks (HANs),
= Building Area Networks (BANs) and Field Area Networks (FANs) = Building Area Networks (BANs) and Field Area = Networks (FANs)
= envisioned by Smart Grid architects. = envisioned by Smart Grid architects.
3.5.1. Service = Discovery 3.6.1. Service Discovery
= Service discovery protocols are designed for the automatic = Service discovery protocols are designed for = the automatic
= configuration and detection of devices, and the services offered = by configuration and detection of = devices, and the services offered by
= the discovered devices. In many cases service discovery is = performed the discovered devices. = In many cases service discovery is performed
= by so-called "constrained resource" devices (i.e., those with = limited by so-called "constrained = resource" devices (i.e., those with limited
= processing power, memory, and power resources). processing power, memory, and power = resources).
= In general, service discovery is concerned with the assignment of = In general, service discovery is concerned with the resolution = and
network addresses (perhaps = via Stateless Address Autoconfiguration distribution of hostnames via multicast DNS
[RFC4862]), resolution = and distribution of hostnames via multicast [I-D.cheshire-dnsext-multicastdns] and the automatic = location of
= DNS [I-D.cheshire-dnsext-multicastdns] and the automatic location = of
= network services via DHCP (Section 3.4.2), the DNS Service = Discovery network services via DHCP = (Section 3.4.2), the DNS Service Discovery
= (DNS-SD) [I-D.cheshire-dnsext-dns-sd] (part of Apple's Bonjour = (DNS-SD) [I-D.cheshire-dnsext-dns-sd] (part = of Apple's Bonjour
= technology), and the Service Location = Protocol (SLP) [RFC2608]. = technology) and the Service Location Protocol (SLP) [RFC2608].
3.5.2. Resource = Discovery 3.6.2.= Resource Discovery
= Resource Discovery is concerned with the discovery resources = offered Resource Discovery is = concerned with the discovery of = resources
= by end-points and is extremely important in machine-to-machine offered by end-points and is extremely important in = machine-to-
= closed-loop applications (i.e., those with no humans in the = loop). = machine closed-loop applications (i.e., those with no humans in = the
= The goals of resource discover protocols include: loop). The goals of resource discover protocols = include:
= Simplicity of creation and maintenance of resources Simplicity of creation and maintenance of = resources
= Commonly understood semantics = Commonly understood semantics
= Conformance to existing and emerging standards Conformance to existing and emerging = standards
= International scope and applicability International scope and applicability
= Extensibility = Extensibility
= Interoperability among collections and indexing systems = Interoperability among collections and = indexing systems
= The Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] = is The Constrained Application = Protocol (CoAP) [I-D.ietf-core-coap] is
= being developed in IETF with these goals in mind. In = particular, being developed in IETF = with these goals in mind. In particular,
= CoAP is designed for use in constrained resource networks and = for CoAP is designed for use in = constrained resource networks and for
= machine-to-machine applications such as smart energy and = building machine-to-machine = applications such as smart energy and building
= automation. It provides a RESTful transfer protocol, a built-in automation. It provides a RESTful transfer protocol [RESTFUL], a
= resource discovery protocol, and includes web concepts such as = URIs built-in resource discovery = protocol, and includes web concepts such
= and content-types. CoAP provides both unicast and multicast = resource as URIs and = content-types. CoAP provides both unicast and multicast
= discovery and includes the ability to filter on attributes of = resource discovery and includes the ability = to filter on attributes
= resource descriptions. Finally, CoAP resource discovery can also = be of resource descriptions. = Finally, CoAP resource discovery can also
= used to discovery HTTP resources. = be used to discovery HTTP resources.
= For simplicity, CoAP makes the assumption that all CoAP servers = For simplicity, CoAP makes the assumption = that all CoAP servers
= listen on the default CoAP port or otherwise have been configured = or listen on the default CoAP port = or otherwise have been configured or
= discovered using some general service discovery mechanism such as = DNS discovered using some general = service discovery mechanism such as DNS
= Service Discovery (DNS-SD) [I-D.cheshire-dnsext-dns-sd]. = Service Discovery (DNS-SD) = [I-D.cheshire-dnsext-dns-sd].
= Resource discovery in CoAP is accomplished through the use of = well- Resource discovery in CoAP is = accomplished through the use of well-
= known resources which describe the links offered by a CoAP = server. known resources which = describe the links offered by a CoAP server.
= CoAP defines a well-known URI for discovery: "/.well-known/r" = CoAP defines a well-known URI for discovery: = "/.well-known/r"
= [RFC5785]. For example, the query [GET /.well-known/r] returns = a [RFC5785]. For example, the = query [GET /.well-known/r] returns a
= list of links (representing resources) available from the = queried list of links (representing = resources) available from the queried
= CoAP server. A query such as [GET /.well-known/r?n=3DVoltage] = returns CoAP server. A query such = as [GET /.well-known/r?n=3DVoltage] returns
= the resources with the name Voltage. = the resources with the name Voltage.
3.6. Other = Applications 3.7. Other Applications
= There are several applications that are widely used but are not = There are several applications that are = widely used but are not
= properly thought of as infrastructure. = properly thought of as infrastructure.
3.6.1. Network = Time 3.7.1. Session Initiation Protocol
The Network Time Protocol was = originally designed by Dave Mills of
the University of Delaware = and CSNET, for the purpose of implementing
a temporal metric in the = Fuzzball Routing Protocol and generally
coordinating time = experiments. The current versions of the time
protocol are the Network Time = Protocol [RFC5905].
NTP is currently being = updated in [RFC5905].
3.6.2. Session = Initiation Protocol
= The Session Initiation Protocol The = Session Initiation Protocol
= [RFC3261][RFC3265][RFC3853][RFC4320][RFC4916][RFC5393][RFC5621] is = an = [RFC3261][RFC3265][RFC3853][RFC4320][RFC4916][RFC5393][RFC5621] is = an
= application layer control (signaling) protocol for creating, = application layer control (signaling) = protocol for creating,
= modifying and terminating multimedia sessions on the Internet, = meant modifying and terminating = multimedia sessions on the Internet, meant
= to be more scalable than H.323. Multimedia sessions can be = voice, to be more scalable than = H.323. Multimedia sessions can be voice,
= video, instant messaging, shared data, and/or subscriptions of = video, instant messaging, shared data, = and/or subscriptions of
= events. SIP can run on top of TCP, UDP, SCTP, or TLS over TCP. = SIP events. SIP can run on top of = TCP, UDP, SCTP, or TLS over TCP. SIP
= is independent of the transport layer, and independent of the = is independent of the transport layer, and = independent of the
= underlying IPv4/v6 version. In fact, the transport protocol used = can underlying IPv4/v6 version. In = fact, the transport protocol used can
=
skipping to change at page 27, line = 10 skipping to = change at page 30, line 11
= designed to be SDP aware (i.e., looking into each packet far = enough designed to be SDP aware = (i.e., looking into each packet far enough
= to discover what the IP address and port number is for this = to discover what the IP address and port = number is for this
= particular session - and resetting it based on the Session = Traversal particular session - and = resetting it based on the Session Traversal
= Utilities for NAT [RFC5389], the session established by SIP will = not Utilities for NAT [RFC5389], = the session established by SIP will not
= result in RTP packets being sent to the proper endpoint (in SIP = result in RTP packets being sent to the = proper endpoint (in SIP
= called a user agent, or UA). It should be noted that SIP = messaging called a user agent, or = UA). It should be noted that SIP messaging
= has no issues with NATs, it is just the UA's inability to = generally has no issues with NATs, = it is just the UA's inability to generally
= learn about the presence of the NATs that prevent the RTP = packets learn about the presence of = the NATs that prevent the RTP packets
= from being received by the UA establishing the session. = from being received by the UA establishing = the session.
3.6.3. = Calendaring 3.7.2. Calendaring
= Internet calendaring, as implemented in Apple iCal, Microsoft = Outlook Internet calendaring, as = implemented in Apple iCal, Microsoft Outlook
= and Entourage, and Google Calendar, is specified in Internet = and Entourage, and Google Calendar, is = specified in Internet
= Calendaring and Scheduling Core Object Specification = (iCalendar) Calendaring and = Scheduling Core Object Specification (iCalendar)
= [RFC5545] and is in the process of being updated to an XML schema = in [RFC5545] and is in the process = of being updated to an XML schema in
= iCalendar XML Representation [I-D.daboo-et-al-icalendar-in-xml] = iCalendar XML Representation = [I-D.daboo-et-al-icalendar-in-xml]
= Several protocols exist to carry calendar events, including = iCalendar Several protocols exist = to carry calendar events, including iCalendar
= Transport-Independent Interoperability Protocol (iTIP) [RFC5546], = the Transport-Independent = Interoperability Protocol (iTIP) [RFC5546], the
= Message-Based Interoperability Protocol (iMIP) [RFC2447] , and = open Message-Based Interoperability = Protocol (iMIP) [RFC2447] , and open
= source work on the Atom Publishing Protocol [RFC5023]. source work on the Atom Publishing Protocol = [RFC5023].
=
skipping to change at page 32, line = 17 skipping to = change at page 35, line 17
= therefore be removed upon publication as an RFC at the RFC = Editor's therefore be removed upon = publication as an RFC at the RFC Editor's
= discretion. discretion.
6. = Security Considerations 6. Security = Considerations
= Security is addressed in some detail in Section 2.2 and Section = 3.1. Security is addressed in some = detail in Section 2.2 and Section 3.1.
7. = Acknowledgements 7. = Acknowledgements
= Review comments were made by Andrew Yourtchenko, Ashok = Narayanan, Review comments were = made by Andrew Yourtchenko, Ashok Narayanan,
= Bernie Volz, Chris Lonvick, Dave McGrew, Dave Oran, David Su, = Hemant Bernie Volz, Chris Lonvick, = Dave McGrew, Dave Oran, David Su, Don
= Singh, James Polk, John Meylor, Joseph Salowey, Julien Abeille, = Kerry = Sturek, Francis Cleveland, Hemant Singh, James Polk, John = Meylor,
= Lynn, Magnus Westerlund, Murtaza Chiba, Paul Duffy, Paul = Hoffman, Joseph Salowey, Julien = Abeille, Kerry Lynn, Magnus Westerlund,
= Ralph Droms, Russ White, Sheila Frankel, and Toerless Eckert. = Dave Murtaza Chiba, Paul Duffy, = Paul Hoffman, Ralph Droms, Russ White,
= McGrew, Vint Cerf, and Ralph Droms suggested text. Sheila Frankel, Tom = Herbst, and Toerless Eckert. Dave McGrew, Vint
Cerf, and Ralph = Droms suggested text.
8. = References 8. References
8.1.= Normative References 8.1. Normative = References
= [RFC1122] Braden, R., "Requirements for Internet Hosts - = [RFC1122] Braden, R., "Requirements for = Internet Hosts -
= Communication Layers", STD 3, RFC 1122, October = 1989. Communication = Layers", STD 3, RFC 1122, October 1989.
= [RFC1123] Braden, R., "Requirements for Internet Hosts - = Application [RFC1123] Braden, R., = "Requirements for Internet Hosts - Application
= and Support", STD 3, RFC 1123, October 1989. = and Support", STD 3, RFC 1123, = October 1989.
= [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", = [RFC1812] Baker, F., "Requirements for IP = Version 4 Routers",
= RFC 1812, June 1995. = RFC 1812, June 1995.
= [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, = [RFC4294] Loughney, J., "IPv6 Node = Requirements", RFC 4294,
= April 2006. = April 2006.
8.2.= Informative References 8.2. = Informative References
[1822] Bolt Beranek and Newman Inc., "Interface = Message Processor
-- Specifications for the interconnection = of a host and a
IMP, Report No. 1822", January = 1976.
=
= [I-D.arkko-ipv6-transition-guidelines] = [I-D.arkko-ipv6-transition-guidelines]
= Arkko, J. and F. Baker, "Guidelines for Using IPv6 = Arkko, J. and F. Baker, = "Guidelines for Using IPv6
= Transition Mechanisms", = Transition Mechanisms during IPv6 = Deployment",
= draft-arkko-ipv6-transition-guidelines-03 (work in = = draft-arkko-ipv6-transition-guidelines-06 (work in
= progress), July = 2010. progress), August 2010.
= [I-D.cheshire-dnsext-dns-sd] = [I-D.cheshire-dnsext-dns-sd]
= Cheshire, S. and M. Krochmal, "DNS-Based Service = Cheshire, S. and M. Krochmal, = "DNS-Based Service
= Discovery", draft-cheshire-dnsext-dns-sd-06 (work in = Discovery", = draft-cheshire-dnsext-dns-sd-06 (work in
= progress), March 2010. = progress), March 2010.
= [I-D.cheshire-dnsext-multicastdns] = [I-D.cheshire-dnsext-multicastdns]
= Cheshire, S. and M. Krochmal, "Multicast DNS", = Cheshire, S. and M. Krochmal, = "Multicast DNS",
= draft-cheshire-dnsext-multicastdns-11 (work in = progress), = draft-cheshire-dnsext-multicastdns-11 (work in progress),
= March 2010. = March 2010.
= [I-D.daboo-et-al-icalendar-in-xml] = [I-D.daboo-et-al-icalendar-in-xml]
= Daboo, C., Douglass, M., and S. Lees, "xCal: The XML = Daboo, C., Douglass, M., and S. = Lees, "xCal: The XML
= format for iCalendar", = format for iCalendar",
= draft-daboo-et-al-icalendar-in-xml-05 (work in = progress), draft-daboo-et-al-icalendar-in-xml-06 (work in = progress),
= July 2010. September = 2010.
= [I-D.ietf-6lowpan-hc] = [I-D.ietf-6lowpan-hc]
= Hui, J. and P. Thubert, "Compression Format for IPv6 = Hui, J. and P. Thubert, = "Compression Format for IPv6
= Datagrams in 6LoWPAN Networks", draft-ietf-6lowpan-hc-08 Datagrams in 6LoWPAN Networks", draft-ietf-6lowpan-hc-12
= (work in progress), July = 2010. (work in = progress), September 2010.
= [I-D.ietf-6man-node-req-bis] = [I-D.ietf-6man-node-req-bis]
= Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 = Node Jankiewicz, E., = Loughney, J., and T. Narten, "IPv6 Node
= Requirements RFC 4294-bis", = Requirements RFC 4294-bis",
= draft-ietf-6man-node-req-bis-05 (work in progress), = draft-ietf-6man-node-req-bis-05 = (work in progress),
= July 2010. = July 2010.
= [I-D.ietf-behave-address-format] = [I-D.ietf-behave-address-format]
= Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and = X. Bao, C., Huitema, C., = Bagnulo, M., Boucadair, M., and X.
= Li, "IPv6 Addressing of IPv4/IPv6 Translators", = Li, "IPv6 Addressing of IPv4/IPv6 = Translators",
= draft-ietf-behave-address-format-10 (work in = progress), = draft-ietf-behave-address-format-10 (work in progress),
= August 2010. = August 2010.
= [I-D.ietf-behave-dns64] = [I-D.ietf-behave-dns64]
= Bagnulo, M., Sullivan, A., Matthews, P., and I. = Beijnum, Bagnulo, M., = Sullivan, A., Matthews, P., and I. Beijnum,
= "DNS64: DNS extensions for Network Address = Translation "DNS64: DNS = extensions for Network Address Translation
= from IPv6 Clients to IPv4 Servers", from IPv6 Clients to IPv4 = Servers",
= draft-ietf-behave-dns64-10 = (work in progress), July 2010. = draft-ietf-behave-dns64-11 (work in = progress),
October 2010.
= [I-D.ietf-behave-v6v4-framework] = [I-D.ietf-behave-v6v4-framework]
= Baker, F., Li, X., Bao, C., and K. Yin, "Framework = for Baker, F., Li, X., = Bao, C., and K. Yin, "Framework for
= IPv4/IPv6 Translation", = IPv4/IPv6 Translation",
= draft-ietf-behave-v6v4-framework-10 (work in = progress), = draft-ietf-behave-v6v4-framework-10 (work in progress),
= August 2010. = August 2010.
= [I-D.ietf-behave-v6v4-xlate] = [I-D.ietf-behave-v6v4-xlate]
= Li, X., Bao, C., and F. Baker, "IP/ICMP Translation = Li, X., Bao, C., and F. Baker, = "IP/ICMP Translation
= Algorithm", draft-ietf-behave-v6v4-xlate-21 (work = in Algorithm", draft-ietf-behave-v6v4-xlate-23 (work in
= progress), August = 2010. progress), September 2010.
= [I-D.ietf-behave-v6v4-xlate-stateful] = [I-D.ietf-behave-v6v4-xlate-stateful]
= Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful = Bagnulo, M., Matthews, P., and I. = Beijnum, "Stateful
= NAT64: Network Address and Protocol Translation from = IPv6 NAT64: Network = Address and Protocol Translation from IPv6
= Clients to IPv4 Servers", = Clients to IPv4 Servers",
= draft-ietf-behave-v6v4-xlate-stateful-12 (work in = = draft-ietf-behave-v6v4-xlate-stateful-12 (work in
= progress), July 2010. = progress), July 2010.
= [I-D.ietf-core-coap] = [I-D.ietf-core-coap]
= Shelby, Z., Frank, B., and D. Sturek, "Constrained = Shelby, Z., Frank, B., and D. = Sturek, "Constrained
= Application Protocol (CoAP)", draft-ietf-core-coap-01 Application Protocol (CoAP)", draft-ietf-core-coap-02
= (work in progress), July = 2010. (work in = progress), September 2010.
= [I-D.ietf-manet-dymo] = [I-D.ietf-manet-dymo]
= Chakeres, I. and C. Perkins, "Dynamic MANET = On-demand Chakeres, I. = and C. Perkins, "Dynamic MANET On-demand
= (DYMO) Routing", draft-ietf-manet-dymo-21 (work in = (DYMO) Routing", = draft-ietf-manet-dymo-21 (work in
= progress), July 2010. = progress), July 2010.
= [I-D.ietf-roll-rpl] = [I-D.ietf-roll-rpl]
= Winter, T., Thubert, P., and R. Team, "RPL: IPv6 = Routing Winter, T., = Thubert, P., and R. Team, "RPL: IPv6 Routing
= Protocol for Low power and Lossy Networks", Protocol for Low power and Lossy = Networks",
= draft-ietf-roll-rpl-11 (work in progress), July = 2010. = draft-ietf-roll-rpl-11 (work in progress), July 2010.
= [I-D.ietf-tls-rfc4347-bis] = [I-D.ietf-tls-rfc4347-bis]
= Rescorla, E. and N. Modadugu, "Datagram Transport = Layer Rescorla, E. and = N. Modadugu, "Datagram Transport Layer
= Security version 1.2", draft-ietf-tls-rfc4347-bis-04 = (work Security version = 1.2", draft-ietf-tls-rfc4347-bis-04 (work
= in progress), July 2010. = in progress), July 2010.
[IEC62351-3]
International Electrotechnical Commission = Technical
Committee 57, "POWER SYSTEMS MANAGEMENT = AND ASSOCIATED
INFORMATION EXCHANGE. DATA AND = COMMUNICATIONS SECURITY --
Part 3: Communication network and system = security Profiles
including TCP/IP", May = 2007.
=
= [IEEE802.1X] [IEEE802.1X]
= Institute of Electrical and Electronics Engineers, = "IEEE Institute of = Electrical and Electronics Engineers, "IEEE
= Standard for Local and Metropolitan Area Networks - = Port Standard for Local = and Metropolitan Area Networks - Port
= based Network Access Control", IEEE Standard = 802.1X-2010, based = Network Access Control", IEEE Standard 802.1X-2010,
= February 2010. = February 2010.
[RESTFUL] Fielding, "Architectural Styles and the = Design of Network-
based Software Architectures", = 2000.
=
= [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC = 768, [RFC0768] Postel, J., "User = Datagram Protocol", STD 6, RFC 768,
= August 1980. = August 1980.
= [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, = [RFC0791] Postel, J., "Internet Protocol", = STD 5, RFC 791,
= September 1981. = September 1981.
= [RFC0792] Postel, J., "Internet Control Message Protocol", STD = 5, [RFC0792] Postel, J., "Internet = Control Message Protocol", STD 5,
= RFC 792, September 1981. = RFC 792, September 1981.
= [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, = [RFC0793] Postel, J., "Transmission Control = Protocol", STD 7,
=
skipping to change at page 38, line = 37 skipping to = change at page 42, line 5
= March 2002. = March 2002.
= [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, = C., [RFC3315] Droms, R., Bound, = J., Volz, B., Lemon, T., Perkins, C.,
= and M. Carney, "Dynamic Host Configuration Protocol = for and M. Carney, = "Dynamic Host Configuration Protocol for
= IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July = 2003.
= [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and = A. [RFC3376] Cain, B., Deering, = S., Kouvelas, I., Fenner, B., and A.
= Thyagarajan, "Internet Group Management Protocol, = Version Thyagarajan, = "Internet Group Management Protocol, Version
= 3", RFC 3376, October 2002. = 3", RFC 3376, October 2002.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, = "An
Architecture for Describing Simple = Network Management
Protocol (SNMP) Management Frameworks", = STD 62, RFC 3411,
December 2002.
[RFC3412] Case, J., Harrington, D., Presuhn, R., = and B. Wijnen,
"Message Processing and Dispatching for = the Simple Network
Management Protocol (SNMP)", STD 62, RFC = 3412,
December 2002.
[RFC3413] Levi, D., Meyer, P., and B. Stewart, = "Simple Network
Management Protocol (SNMP) Applications", = STD 62,
RFC 3413, December 2002.
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based = Security Model
(USM) for version 3 of the Simple Network = Management
Protocol (SNMPv3)", STD 62, RFC 3414, = December 2002.
[RFC3415] Wijnen, B., Presuhn, R., and K. = McCloghrie, "View-based
Access Control Model (VACM) for the = Simple Network
Management Protocol (SNMP)", STD 62, RFC = 3415,
December 2002.
[RFC3416] Presuhn, R., "Version 2 of the Protocol = Operations for the
Simple Network Management Protocol = (SNMP)", STD 62,
RFC 3416, December 2002.
[RFC3417] Presuhn, R., "Transport Mappings for the = Simple Network
Management Protocol (SNMP)", STD 62, RFC = 3417,
December 2002.
[RFC3418] Presuhn, R., "Management Information Base = (MIB) for the
Simple Network Management Protocol = (SNMP)", STD 62,
RFC 3418, December 2002.
=
= [RFC3424] Daigle, L. and IAB, "IAB Considerations for = UNilateral [RFC3424] Daigle, L. = and IAB, "IAB Considerations for UNilateral
= Self-Address Fixing (UNSAF) Across Network Address = Self-Address Fixing (UNSAF) = Across Network Address
= Translation", RFC 3424, November 2002. Translation", RFC 3424, November = 2002.
= [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, = "Transport [RFC3436] Jungmaier, = A., Rescorla, E., and M. Tuexen, "Transport
= Layer Security over Stream Control Transmission = Protocol", Layer = Security over Stream Control Transmission Protocol",
= RFC 3436, December 2002. = RFC 3436, December 2002.
= [RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., = Handley, [RFC3453] Luby, M., = Vicisano, L., Gemmell, J., Rizzo, L., Handley,
= M., and J. Crowcroft, "The Use of Forward Error = Correction M., and J. = Crowcroft, "The Use of Forward Error Correction
=
skipping to change at page 40, line = 34 skipping to = change at page 44, line 36
= [RFC4301] Kent, S. and K. Seo, "Security Architecture for the = [RFC4301] Kent, S. and K. Seo, "Security = Architecture for the
= Internet Protocol", RFC 4301, December 2005. = Internet Protocol", RFC 4301, = December 2005.
= [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, = [RFC4302] Kent, S., "IP Authentication = Header", RFC 4302,
= December 2005. = December 2005.
= [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", = [RFC4303] Kent, S., "IP Encapsulating = Security Payload (ESP)",
= RFC 4303, December 2005. = RFC 4303, December 2005.
= [RFC4306] Kaufman, C., "Internet Key Exchange = (IKEv2) Protocol",
RFC 4306, December = 2005.
= =
= [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in = the [RFC4307] Schiller, J., = "Cryptographic Algorithms for Use in the
= Internet Key Exchange Version 2 (IKEv2)", RFC 4307, = Internet Key Exchange Version 2 = (IKEv2)", RFC 4307,
= December 2005. = December 2005.
= [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) = CCM [RFC4309] Housley, R., "Using = Advanced Encryption Standard (AES) CCM
= Mode with IPsec Encapsulating Security Payload = (ESP)", Mode with IPsec = Encapsulating Security Payload (ESP)",
= RFC 4309, December 2005. = RFC 4309, December 2005.
= [RFC4320] Sparks, R., "Actions Addressing Identified Issues with = the [RFC4320] Sparks, R., "Actions = Addressing Identified Issues with the
= Session Initiation Protocol's (SIP) Non-INVITE = Session Initiation Protocol's = (SIP) Non-INVITE
=
skipping to change at page 41, line = 23 skipping to = change at page 45, line 23
= Message Protocol (ICMPv6) for the Internet Protocol = Message Protocol (ICMPv6) for the = Internet Protocol
= Version 6 (IPv6) Specification", RFC 4443, March = 2006. Version 6 (IPv6) = Specification", RFC 4443, March 2006.
= [RFC4487] Le, F., Faccin, S., Patil, B., and H. Tschofenig, = "Mobile [RFC4487] Le, F., Faccin, = S., Patil, B., and H. Tschofenig, "Mobile
= IPv6 and Firewalls: Problem Statement", RFC 4487, = IPv6 and Firewalls: Problem = Statement", RFC 4487,
= May 2006. May = 2006.
= [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: = Session [RFC4566] Handley, M., = Jacobson, V., and C. Perkins, "SDP: Session
= Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July = 2006.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, = "Configuration
Guidelines for DiffServ Service Classes", = RFC 4594,
August 2006.
=
= [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. = Kouvelas, [RFC4601] Fenner, B., = Handley, M., Holbrook, H., and I. Kouvelas,
= "Protocol Independent Multicast - Sparse Mode = (PIM-SM): "Protocol = Independent Multicast - Sparse Mode (PIM-SM):
= Protocol Specification (Revised)", RFC 4601, August = 2006. Protocol = Specification (Revised)", RFC 4601, August 2006.
= [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using = Internet [RFC4604] Holbrook, H., = Cain, B., and B. Haberman, "Using Internet
= Group Management Protocol Version 3 (IGMPv3) and = Multicast Group = Management Protocol Version 3 (IGMPv3) and Multicast
= Listener Discovery Protocol Version 2 (MLDv2) for = Source- Listener = Discovery Protocol Version 2 (MLDv2) for Source-
= Specific Multicast", RFC 4604, August 2006. Specific Multicast", RFC 4604, August = 2006.
= [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast = for [RFC4607] Holbrook, H. and B. = Cain, "Source-Specific Multicast for
=
skipping to change at page 41, line = 46 skipping to = change at page 45, line 50
= Protocol Independent Multicast in 232/8", BCP 120, = Protocol Independent Multicast in = 232/8", BCP 120,
= RFC 4608, August 2006. = RFC 4608, August 2006.
= [RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A = Roadmap [RFC4614] Duke, M., = Braden, R., Eddy, W., and E. Blanton, "A Roadmap
= for Transmission Control Protocol (TCP) = Specification for = Transmission Control Protocol (TCP) Specification
= Documents", RFC 4614, September 2006. Documents", RFC 4614, September = 2006.
= [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC = 4741, [RFC4741] Enns, R., "NETCONF = Configuration Protocol", RFC 4741,
= December 2006. = December 2006.
[RFC4742] Wasserman, M. and T. Goddard, "Using the = NETCONF
Configuration Protocol over Secure SHell = (SSH)", RFC 4742,
December 2006.
[RFC4743] Goddard, T., "Using NETCONF over the = Simple Object Access
Protocol (SOAP)", RFC 4743, December = 2006.
[RFC4744] Lear, E. and K. Crozier, "Using the = NETCONF Protocol over
the Blocks Extensible Exchange Protocol = (BEEP)", RFC 4744,
December 2006.
=
= [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, = [RFC4760] Bates, T., Chandra, R., Katz, D., = and Y. Rekhter,
= "Multiprotocol Extensions for BGP-4", RFC 4760, = "Multiprotocol Extensions for = BGP-4", RFC 4760,
= January 2007. = January 2007.
= [RFC4787] Audet, F. and C. Jennings, "Network Address = Translation [RFC4787] Audet, F. = and C. Jennings, "Network Address Translation
= (NAT) Behavioral Requirements for Unicast UDP", BCP = 127, (NAT) Behavioral = Requirements for Unicast UDP", BCP 127,
= RFC 4787, January 2007. = RFC 4787, January 2007.
= [RFC4835] Manral, V., "Cryptographic Algorithm Implementation = [RFC4835] Manral, V., "Cryptographic = Algorithm Implementation
= Requirements for Encapsulating Security Payload (ESP) = and Requirements for = Encapsulating Security Payload (ESP) and
=
skipping to change at page 43, line = 10 skipping to = change at page 47, line 25
= PPP", RFC 5072, September 2007. PPP", RFC 5072, September 2007.
= [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of = Peer-to- [RFC5128] Srisuresh, P., = Ford, B., and D. Kegel, "State of Peer-to-
= Peer (P2P) Communication across Network Address = Peer (P2P) Communication across = Network Address
= Translators (NATs)", RFC 5128, March 2008. Translators (NATs)", RFC 5128, March = 2008.
= [RFC5135] Wing, D. and T. Eckert, "IP Multicast Requirements for = a [RFC5135] Wing, D. and T. = Eckert, "IP Multicast Requirements for a
= Network Address Translator (NAT) and a Network = Address Network Address = Translator (NAT) and a Network Address
= Port Translator (NAPT)", BCP 135, RFC 5135, February = 2008. Port Translator = (NAPT)", BCP 135, RFC 5135, February 2008.
[RFC5193] Jayaraman, P., Lopez, R., Ohba, Y., = Parthasarathy, M., and
A. Yegin, "Protocol for Carrying = Authentication for
Network Access (PANA) Framework", RFC = 5193, May 2008.
=
= [RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT = and [RFC5207] Stiemerling, M., = Quittek, J., and L. Eggert, "NAT and
= Firewall Traversal Issues of Host Identity Protocol = (HIP) Firewall Traversal = Issues of Host Identity Protocol (HIP)
= Communication", RFC 5207, April 2008. Communication", RFC 5207, April = 2008.
= [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS = [RFC5216] Simon, D., Aboba, B., and R. = Hurst, "The EAP-TLS
= Authentication Protocol", RFC 5216, March 2008. = Authentication Protocol", RFC = 5216, March 2008.
= [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) = over [RFC5238] Phelan, T., = "Datagram Transport Layer Security (DTLS) over
= the Datagram Congestion Control Protocol (DCCP)", = the Datagram Congestion Control = Protocol (DCCP)",
= RFC 5238, May 2008. = RFC 5238, May 2008.
= [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer = Security [RFC5246] Dierks, T. and = E. Rescorla, "The Transport Layer Security
= (TLS) Protocol Version 1.2", RFC 5246, August 2008. = (TLS) Protocol Version 1.2", RFC = 5246, August 2008.
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF = Event
Notifications", RFC 5277, July = 2008.
=
= [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, = [RFC5308] Hopps, C., "Routing IPv6 with = IS-IS", RFC 5308,
= October 2008. = October 2008.
= [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, = "OSPF [RFC5340] Coltun, R., = Ferguson, D., Moy, J., and A. Lindem, "OSPF
= for IPv6", RFC 5340, July 2008. for IPv6", RFC 5340, July 2008.
= [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, = [RFC5389] Rosenberg, J., Mahy, R., = Matthews, P., and D. Wing,
= "Session Traversal Utilities for NAT (STUN)", RFC = 5389, "Session Traversal = Utilities for NAT (STUN)", RFC 5389,
= October 2008. = October 2008.
= [RFC5393] Sparks, R., Lawrence, S., Hawrylyshen, A., and B. = Campen, [RFC5393] Sparks, R., = Lawrence, S., Hawrylyshen, A., and B. Campen,
= "Addressing an Amplification Vulnerability in = Session "Addressing an = Amplification Vulnerability in Session
= Initiation Protocol (SIP) Forking Proxies", RFC = 5393, Initiation = Protocol (SIP) Forking Proxies", RFC 5393,
= December 2008. = December 2008.
= [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage = Guidelines [RFC5405] Eggert, L. = and G. Fairhurst, "Unicast UDP Usage Guidelines
= for Application Designers", BCP 145, RFC 5405, = for Application Designers", BCP = 145, RFC 5405,
= November 2008. = November 2008.
[RFC5539] Badra, M., "NETCONF over Transport Layer = Security (TLS)",
RFC 5539, May 2009.
=
= [RFC5545] Desruisseaux, B., "Internet Calendaring and = Scheduling [RFC5545] Desruisseaux, = B., "Internet Calendaring and Scheduling
= Core Object Specification (iCalendar)", RFC 5545, = Core Object Specification = (iCalendar)", RFC 5545,
= September 2009. = September 2009.
= [RFC5546] Daboo, C., "iCalendar Transport-Independent [RFC5546] Daboo, C., "iCalendar = Transport-Independent
= Interoperability Protocol (iTIP)", RFC 5546, = Interoperability Protocol = (iTIP)", RFC 5546,
= December 2009. = December 2009.
[RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. = Barthel,
"Routing Requirements for Urban Low-Power = and Lossy
Networks", RFC 5548, May = 2009.
=
= [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 [RFC5569] Despres, R., "IPv6 Rapid Deployment on = IPv4
= Infrastructures (6rd)", RFC 5569, January 2010. = Infrastructures (6rd)", RFC 5569, = January 2010.
= [RFC5621] Camarillo, G., "Message Body Handling in the Session = [RFC5621] Camarillo, G., "Message Body = Handling in the Session
= Initiation Protocol (SIP)", RFC 5621, September = 2009. Initiation = Protocol (SIP)", RFC 5621, September 2009.
[RFC5673] Pister, K., Thubert, P., Dwars, S., and T. = Phinney,
"Industrial Routing Requirements in = Low-Power and Lossy
Networks", RFC 5673, October = 2009.
=
= [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP = Congestion [RFC5681] Allman, M., = Paxson, V., and E. Blanton, "TCP Congestion
= Control", RFC 5681, September 2009. Control", RFC 5681, September = 2009.
[RFC5717] Lengyel, B. and M. Bjorklund, "Partial Lock = Remote
Procedure Call (RPC) for NETCONF", RFC = 5717,
December 2009.
=
= [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. = Macker, [RFC5740] Adamson, B., = Bormann, C., Handley, M., and J. Macker,
= "NACK-Oriented Reliable Multicast (NORM) Transport = "NACK-Oriented Reliable Multicast = (NORM) Transport
= Protocol", RFC 5740, November 2009. Protocol", RFC 5740, November = 2009.
= [RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose = Internet [RFC5750] Ramsdell, B. = and S. Turner, "Secure/Multipurpose Internet
= Mail Extensions (S/MIME) Version 3.2 Certificate = Mail Extensions (S/MIME) Version = 3.2 Certificate
= Handling", RFC 5750, January 2010. Handling", RFC 5750, January 2010.
= [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose = Internet [RFC5751] Ramsdell, B. = and S. Turner, "Secure/Multipurpose Internet
= Mail Extensions (S/MIME) Version 3.2 Message = Mail Extensions (S/MIME) Version = 3.2 Message
= Specification", RFC 5751, January 2010. Specification", RFC 5751, January = 2010.
= [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining = Well-Known [RFC5785] Nottingham, = M. and E. Hammer-Lahav, "Defining Well-Known
= Uniform Resource Identifiers (URIs)", RFC 5785, = Uniform Resource Identifiers = (URIs)", RFC 5785,
= April 2010. = April 2010.
= [RFC5796] Atwood, W., Islam, S., and = M. Siami, "Authentication and = [RFC5826] Brandt, = A., Buron, J., and G. Porcu, "Home = Automation
= Confidentiality in Protocol Independent = Multicast Sparse Routing Requirements in Low-Power and Lossy Networks",
Mode (PIM-SM) = Link-Local Messages", RFC 5796, = March 2010. RFC = 5826, April 2010.
= [RFC5838] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and = R. [RFC5838] Lindem, A., = Mirtorabi, S., Roy, A., Barnes, M., and R.
= Aggarwal, "Support of Address Families in OSPFv3", = Aggarwal, "Support of Address = Families in OSPFv3",
= RFC 5838, April 2010. = RFC 5838, April 2010.
[RFC5867] Martocci, J., De Mil, P., Riou, N., and W. = Vermeylen,
"Building Automation Routing Requirements = in Low-Power and
Lossy Networks", RFC 5867, June = 2010.
=
= [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, = "Network [RFC5905] Mills, D., = Martin, J., Burbank, J., and W. Kasch, "Network
= Time Protocol Version 4: Protocol and Algorithms = Time Protocol Version 4: Protocol = and Algorithms
= Specification", RFC 5905, June 2010. Specification", RFC 5905, June = 2010.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. = Eronen,
"Internet Key Exchange Protocol Version 2 = (IKEv2)",
RFC 5996, September 2010.
=
= [SP-MULPIv3.0] = [SP-MULPIv3.0]
= CableLabs, "DOCSIS 3.0 MAC and Upper Layer Protocols = CableLabs, "DOCSIS 3.0 MAC and = Upper Layer Protocols
= Interface Specification, = CM-SP-MULPIv3.0-I10-090529", = Interface Specification, CM-SP-MULPIv3.0-I10-090529",
= May 2009. May = 2009.
Appendix A. Example: Advanced Metering = Infrastructure
This appendix provides a worked example of the use = of the Internet
Protocol Suite in a network such as the Smart Grid's = Advanced
Metering Infrastructure (AMI). There are several = possible models.
Figure 6 shows the structure of the AMI as it = reaches out towards a
set of residences. In this structure, we have the = home itself and
its Home Area Network (HAN), the Neighborhood Area = Network (NAN) that
the utility uses to access the meter at the home, = and the utility
access network that connects a set of NANs to the = utility itself.
For the purposes of this discussion, assume that the = NAN contains a
distributed application in a set collectors, which = is of course only
one way the application could be = implemented.
---
A thermostats, appliances, = etc
| = ------+-----------------------------------
| |
|"HAN" | <--- Energy Services Interface = (ESI)
| +---+---+
| | Meter | Meter is generally an ALG between = the AMI and the HAN
| +---+---+
V \
--- \
A \ | /
| \ | /
| "NAN" +--+-+-+---+ Likely a router but = could
| |Collector | be an front-end = application
V +----+-----+ gateway for = utility
--- \
A \ | /
| \ | /
|"AMI" +--+-+-+--+
| | AMI |
| | Headend |
V +---------+
---
Figure 6: The HAN, NAN, and Utility in the = Advanced Metering
= Infrastructure
There are several questions that have to be answered = in describing
this picture, which given possible answers yield = different possible
models. They include at least:
o How does Demand Response work? = Either:
* The utility presents pricing signals to the = home,
* The utility presents pricing signals = individual devices (e.g.,
a Pluggable Electric Vehicle),
* The utility adjusts settings on individual = appliances within
the home.
o How does the utility access meters at the = home?
* The AMI Headend manages the interfaces with = the meters,
collecting metering data and passing it on to = the appropriate
applications over the Enterprise Bus, = or
* Distributed application support (collectors") = might access and
summarize the information; this device might = be managed by the
utility or by a service between the utility = and its customers.
In implementation, these models are idealized; = reality may include
some aspects of each model in specified = cases.
The examples include:
1. Appendix A.2 presumes that the HAN, the NAN, and = the utility's
network are separate administrative domains and = speak application
to application across those = domains.
2. Appendix A.3 repeats the first example, but = presuming that the
utility directly accesses appliances within the = HAN from the
collector".
3. Appendix A.4 repeats the first example, but = presuming that the
collector directly forwards traffic as a router = in addition to
distributed application chores. Note that this = case implies
numerous privacy and security concerns and as = such is considered
a less likely deployment model.
A.1. How to structure a network
A key consideration in the Internet has been the = development of new
link layer technologies over time. The ARPANET = originally used a BBN
proprietary link layer called BBN 1822 [1822]. In = the late 1970's,
the ARPANET switched to X.25 as an interface to the = 1822 network.
With the deployment of the IEEE 802 series = technologies in the early
1980's, IP was deployed on Ethernet (IEEE 802.3), = Token Ring (IEEE
802.5) and WiFi (IEEE 802.11), as well as Arcnet, = serial lines of
various kinds, Frame Relay, and ATM. A key issue in = this evolution
was that the applications developed to run on the = Internet use APIs
related to the IPS, and as a result require little = or no change to
continue to operate in a new link layer architecture = or a mixture of
them.
The Smart Grid is likely to see a similar evolution = over time.
Consider the Home Area Network (HAN) as a readily = understandable
small network. At this juncture, technologies = proposed for
residential networks include IEEE P1901 (Homeplug), = IEEE 802.15.4g
(Zigbee), and IEEE 802.11 (WiFi, commonly deployed = today and used by
some high end appliances). It is reasonable to = expect other
technologies to be developed in the future. As the = Zigbee Alliance
has learned (and as a resulted incorporated the IPS = in Secure Energy
Profile 2.0), there is significant value in = providing a virtual
address that is mapped to interfaces or nodes = attached to each of
those technologies.
There are two possible communication models within = the HAN, both of
which are likely to be useful. Devices may = communicate directly with
each other, or they may be managed by some central = controller. An
example of direct communications might be a light = switch that
directly commands a lamp to turn on or off. An = example of indirect
communications might be a control application in a = Customer or
Building that accepts telemetry from a thermostat, = applies some form
of policy, and controls the heating and air = conditioning systems. In
addition, there are high end appliances in the = market today that use
residential broadband to communicate with their = manufacturers, and
obviously the meter needs to communicate with the = utility.
Utility NAN
/
/
+----+-----+ +--+ +--+ = +--+
| Meter | |D1| |D2| = |D3|
+-----+----+ ++-+ ++-+ = ++-+
| | | = |
----+-+-------+----+----+---- IEEE = 802.15.4
|
+--+---+
|Router+------/------ Residential = Broadband
+--+---+
|
----+---------+----+----+---- IEEE = P1901
| | = |
++-+ ++-+ = ++-+
|D4| |D5| = |D6|
+--+ +--+ = +--+
Figure 7: Home Area = Network
Figure 7 shows a simple network containing IEEE = 802.15.4 and IEEE
1901 domains. It shows the connectivity between = them as a router
separate from the EMS. This is for clarity; the two = could of course
be incorporated into a single system, and one could = imagine
appliances that want to communicate with their = manufacturers
supporting both a HAN interface and a WiFi interface = rather than
depending on the router. These are all manufacturer = design
decisions.
A.1.1. HAN Routing
The HAN can be seen as communicating with two kinds = of non-HAN
networks. One is the home LAN, which may in turn be = attached to the
Internet, and will generally either derive its = prefix from the
upstream ISP or use a self-generated ULA. Another = is the utility's
NAN, which through an ESI provides utility = connectivity to the HAN;
in this case the HAN will be addressed by a = self-generated ULA (note,
however, that in some cases ESI may also provide a = prefix via DHCP
[RFC3315]). In addition, the HAN will have = link-local addresses that
can be used between neighboring nodes. In general, = an HAN will be
comprised of both 802.15.4, 802.11 (and possibly = other) networks.
The ESI is node on the user's residential network, = and will not
typically provide stateful packet forwarding or = firewall services
between the HAN and the utility network(s). In = general, the meter/
ESI is just a node on the home network. However, = the ESI must be
capable of understanding that most home networks are = not 802.15.4
enabled (rather, they are typically 802.11 = networks), and that it
must be capable of setting up ad-hoc networks = between various sensors
in the home (e.g., betweeen the meter and say, a = thermostat) in the
event there aren't other networks = available.
A.1.2. HAN Security
In any network, we have a variety of threats and a = variety of
possible mitigations. These include, at = minimum:
Link Layer: Why is your machine able to talk in my = network? The
WiFi SSIDs often use some form of authenticated = access control,
which may be a simple encrypted password = mechanism or may use a
combination of encryption and IEEE 802.1X+EAP-TLS = Authentication/
Authorization to ensure that only authorized = communicants can use
it. If a LAN has a router attached, the router = may also implement
a firewall to filter remote = accesses.
Network Layer: Given that your machine is = authorized access to my
network, why is your machine talking with my = machine? IPsec is a
way of ensuring that computers that can use a = network are allowed
to talk with each other, may also enforce = confidentiality, and may
provide VPN services to make a device or network = appear to be part
of a remote network.
Application: Given that your machine is authorized = access to my
network and my machine, why is your application = talking with my
application? The fact that your machine and mine = are allowed to
talk for some applications doesn't mean they are = allowed to for
all applications. (D)TLS, https, and other such = mechanisms enable
an application to impose = application-to-application controls
similar to the network layer controls provided by = IPsec.
Remote Application: How do I know that the data I = received is the
data you sent? Especially in applications like = electronic mail,
where data passes through a number of = intermediaries that one may
or may not really want munging it (how many times = have you seen a
URL broken by a mail server?), we have tools = (DKIM, S/MIME, and
W3C XML Signatures to name a few) to provide = non-repudiability and
integrity verification. This may also have legal = ramifications:
if a record of a meter reading is to be used in = billing, and the
bill is disputed in court, one could imagine the = court wanting
proof that the record in fact came from that = meter at that time
and contained that data.
Application-specific security: In addition, = applications often
provide security services of their own. The fact = that I can
access a file system, for example, doesn't mean = that I am
authorized to access everything in it; the file = system may well
prevent my access to some of its contents. = Routing protocols like
BGP obsess with the question "what statements = that my peer made am
I willing to believe". And monitoring protocols = like SNMP may not
be willing to answer every question they are = asked, depending on
access configuration.
Devices in the HAN want controlled access to the LAN = in question for
obvious reasons. In addition, there should be some = form of mutual
authentication between devices - the lamp controller = will want to
know that the light switch telling it to change = state is the right
light switch, for example. The EMS may well want = strong
authentication of accesses - the parents may not = want the children
changing the settings, and while the utility and the = customer are
routinely granted access, other parties (especially = parties with
criminal intent) need to be excluded.
A.2. Model 1: AMI with separated = domains
With the background given in Appendix A.1, we can = now discuss the use
of IP (IPv4 or IPv6) in the AMI.
In this first model, consider the three domains in = Figure 6 to
literally be separate administrative domains, = potentially operated by
different entities. For example, the NAN could be a = WiMAX network
operated by a traditional telecom operator, the = utility's network
(including the collector) is its own, and the = residential network is
operated by the resident. In this model, while = communications
between the collector and the Meter are normal, the = utility has no
other access to appliances in the home, and the = collector doesn't
directly forward messages from the NAN = upstream.
In this case, as shown in Figure 7, it would make = the most sense to
design the collector, the Meter, and the EMS as = hosts on the NAN -
design them as systems whose applications can = originate and terminate
exchanges or sessions in the NAN, but not forward = traffic from or to
other devices.
In such a configuration, Demand Response has to be = performed by
having the EMS accept messages such as price signals = from the "pole
top", apply some form of policy, and then = orchestrate actions within
the home. Another possibility is to have the EMS = communicate with
the ESI located in the meter. If the thermostat has = high demand and
low demand (day/night or morning/day/evening/night) = settings, Demand
Response might result in it moving to a lower demand = setting, and the
EMS might also turn off specified circuits in the = home to diminish
lighting.
In this scenario, QoS issues reportedly arise when = high precedence
messages must be sent through the collector to the = home; if the
collector is occupied polling the meters or doing = some other task,
the application may not yield control of the = processor to the
application that services the message. Clearly, = this is either an
application or an OS problem; applications need to = be designed in a
manner that doesn't block high precedence messages. = The collector
also needs to use appropriate NAN services, if they = exist, to provide
the NAN QoS it needs. For example, if WiMax is in = use, it might use
a routine-level service for normal exchanges but a = higher precedence
service for these messages.
A.3. Model 2: AMI with neighborhood access to the = home
In this second model, let's imagine that the utility = directly
accesses appliances within the HAN. Rather than = expect an EMS to
respond to price signals in Demand Response, it = directly commands
devices like air conditioners to change state, or = throws relays on
circuits to or within the home.
+----------+ +--+ +--+ = +--+
| Meter | |D1| |D2| = |D3|
+-----+----+ ++-+ ++-+ = ++-+
| | | = |
----+-+-------+----+----+---- IEEE = 802.15.4
|
+--+---+
| +------/------ = NAN
|Router|
| +------/------ Residential = Broadband
+--+---+
|
----+---------+----+----+---- IEEE = P1901
| | = |
++-+ ++-+ = ++-+
|D4| |D5| = |D6|
+--+ +--+ = +--+
Figure 8: Home Area = Network
In this case, as shown in Figure 8, the Meter, and = EMS as hosts on
the HAN, and there is a router between the HAN and = the NAN.
As one might imagine, there are serious security = considerations in
this model. Traffic between the NAN and the = residential broadband
network should be filtered, and the issues raised in = Appendix A.1.2
take on a new level of meaning. One of the biggest = threats may be a
legal or at least a public relations issue; if the = utility
intentionally disables a circuit in a manner or at a = time that
threatens life (the resident's kidney dialysis = machine is on it, or a
respirator, for example) the matter might make the = papers.
Unauthorized access could be part of juvenile pranks = or other things
as well. So one really wants the appliances to only = obey commands
under strict authentication/authorization = controls.
In addition to the QoS issues raised in Appendix = A.2, there is the
possibility of queuing issues in the router. In = such a case, the IP
datagrams should probably use the Low-Latency Data = Service Class
described in [RFC4594], and let other traffic use = the Standard
Service Class or other service = classes.
A.4. Model 3: Collector is an IP router
In this third model, the relationship between the = NAN and the HAN is
either as in Appendix A.2 or Appendix A.3; what is = different is that
the collector may be an IP router. In addition to = whatever
autonomous activities it is doing, it forwards = traffic as an IP
router in some cases.
As and analogous to Appendix A.3, there are serious = security
considerations in this model. Traffic being = forwarded should be
filtered, and the issues raised in Appendix A.1.2 = take on a new level
of meaning - but this time at the utility mainframe. = Unauthorized
access is likely similar to other = financially-motivated attacks that
happen in the Internet, but presumably would be = coming from devices
in the HAN that have been co-opted in some way. One = really wants the
appliances to only obey commands under strict = authentication/
authorization controls.
In addition to the QoS issues raised in Appendix = A.2, there is the
possibility of queuing issues in the collector. In = such a case, the
IP datagrams should probably use the Low-Latency = Data Service Class
described in [RFC4594], and let other traffic use = the Standard
Service Class or other service = classes.
=
Authors' Addresses Authors' Addresses
= Fred Baker Fred Baker
= Cisco Systems Cisco Systems
= Santa Barbara, California 93117 = Santa Barbara, California 93117
= USA USA
= Email: fred@cisco.com = Email: fred@cisco.com
= David Meyer David Meyer
 End of changes. 60 change blocks. 
149 lines changed or = deleted 758 lines changed or = added

This = html diff was produced by rfcdiff 1.40. The latest version is available = from http://tools.ietf.org/to= ols/rfcdiff/
=20 =20

= --Apple-Mail-46-487591200-- From mehmet.ersue@nsn.com Tue Oct 26 07:28:23 2010 Return-Path: X-Original-To: smartpowerdir@core3.amsl.com Delivered-To: smartpowerdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35E9A3A67A1; Tue, 26 Oct 2010 07:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.443 X-Spam-Level: X-Spam-Status: No, score=-102.443 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-qpGGX2zPOy; Tue, 26 Oct 2010 07:28:20 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id A4C993A6912; Tue, 26 Oct 2010 07:28:06 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o9QETr2e014387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 26 Oct 2010 16:29:53 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o9QETnqc012344; Tue, 26 Oct 2010 16:29:53 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Oct 2010 16:29:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB751A.407201F6" Date: Tue, 26 Oct 2010 16:29:50 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6401232486@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft Version of the Document "IETF Network Management Framework and Standards" Thread-Index: Act0d5HeOGmwjsYoRlC9J+vAmaLjQgAF6EKgACIDWjA= From: "Ersue, Mehmet (NSN - DE/Munich)" To: "IETF SmartPower Directorate" , X-OriginalArrivalTime: 26 Oct 2010 14:29:52.0660 (UTC) FILETIME=[40C76540:01CB751A] Subject: [smartpowerdir] FW: Draft Version of the Document "IETF Network Management Framework and Standards" X-BeenThere: smartpowerdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Members of the Smart Power Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 14:28:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB751A.407201F6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, as discussed in the SGIP PAP01 meeting in September I prepared a draft = on "IETF Network Management Framework and Standards", which will be = further updated and extended with the help of a few contributors for = different topics. It is likely that the draft will be splitted after = some time into two documents focusing on survey and applicability = statement for SG environment.=20 I think such an overview and guideline document is useful not only at = IETF but also in other SDOs planning to use IETF management technologies = and data models. The draft will be also discussed in the OPSAWG session in IETF #79. Any comments and additional contributors are highly appreciated.=20 The next version is planned for end of November before the SGIP F2F = meeting in Chicago. Mehmet=20 From: Ersue, Mehmet (NSN - DE/Munich)=20 Sent: Tuesday, October 26, 2010 12:07 AM To: SGIP-PAP01WG@SMARTGRIDLISTSERV.ORG Subject: Draft Version of the Document "IETF Network Management = Framework and Standards" Hi All, please find below the link to an early draft document I submitted aiming = to address the action item from the St.Louis PAP01 meeting. The document will be also discussed in the coming IETF meeting November = 8-12, 2010. http://tools.ietf.org/id/draft-ersue-opsawg-management-fw=20 I and some invited contributors will work on the document in the coming = weeks and update it with subsequent versions. I would appreciate any comments. Best Regards,=20 Mehmet Ersue _____________________________________________________ Nokia Siemens Networks CTO IE Internet St.-Martinstrasse 76 81541 Munich Germany Mobile: +49 172 8432301 ___________________________________________________________ Nokia Siemens Networks GmbH & Co. KG Sitz der Gesellschaft: M=FCnchen / = Registered office: Munich Registergericht: M=FCnchen / Commercial registry: Munich, HRA 88537 = WEEE-Reg.-Nr.: DE 52984304 Pers=F6nlich haftende Gesellschafterin / General Partner: Nokia Siemens = Networks Management GmbH Gesch=E4ftsleitung / Board of Directors: Joachim Malterer, Lydia Sommer = Sitz der Gesellschaft: M=FCnchen / Registered office: Munich Registergericht: M=FCnchen / Commercial = registry: Munich, HRB 163416=20 ------_=_NextPart_001_01CB751A.407201F6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Diff: draft-baker-ietf-core-07.txt - = sg-ietf-compendium.txt

Hi All,

as discussed in the SGIP PAP01 meeting in September I = prepared a draft on "IETF Network Management Framework and Standards", = which will be further updated and extended with the help of a few contributors = for different topics. It is likely that the draft will be splitted after = some time into two documents focusing on survey and applicability statement for SG = environment.

I think such an overview and guideline document is useful = not only at IETF but also in other SDOs planning to use IETF management technologies = and data models.
The draft will be also discussed in the OPSAWG session in IETF = #79.

Any comments and additional contributors are highly = appreciated.
The next version is planned for end of November before the SGIP F2F = meeting in Chicago.

Mehmet =

From:= Ersue, Mehmet (NSN - DE/Munich)
Sent: Tuesday, October 26, 2010 12:07 AM
To: SGIP-PAP01WG@SMARTGRIDLISTSERV.ORG
Subject: Draft Version of the Document "IETF Network Management Framework and Standards"

Hi All,

please find below the link to an early draft document I = submitted aiming to address the action item from the St.Louis PAP01 meeting.
The document will be also discussed in the coming IETF meeting November = 8-12, 2010.

http:/= /tools.ietf.org/id/draft-ersue-opsawg-management-fw

I and some invited contributors will work on the document in = the coming weeks and update it with subsequent versions.
I would appreciate any comments.

= Best Regards,
Mehmet Ersue
_____________________________________________________
Nokia Siemens Networks
CTO IE Internet
St.-Martinstrasse 76
81541 Munich
Germany
Mobile: +49 172 8432301=
___________________________________________________________ Nokia Siemens Networks GmbH & Co. K= G Sitz der Gesellschaft: M=FCnchen / Registered office: Munich
Registergericht: M=FCnchen / Commercial registry: Munich, HRA 88537 WEEE-Reg.-Nr.: DE 52984304
Pers=F6nlich haftende Gesellschafterin / General Partner: Nokia Siemens = Networks Management GmbH
Gesch=E4ftsleitung / Board of Directors: Joachim Malterer, Lydia Sommer = Sitz der Gesellschaft: M=FCnchen /
Registered office: Munich Registergericht: M=FCnchen / Commercial = registry: Munich, HRB 163416

------_=_NextPart_001_01CB751A.407201F6-- From fred@cisco.com Wed Oct 27 10:47:06 2010 Return-Path: X-Original-To: smartpowerdir@core3.amsl.com Delivered-To: smartpowerdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B1AA3A68B1 for ; Wed, 27 Oct 2010 10:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.388 X-Spam-Level: X-Spam-Status: No, score=-110.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uK53Ew28mukw for ; Wed, 27 Oct 2010 10:47:05 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 3C5E83A6888 for ; Wed, 27 Oct 2010 10:47:05 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.58,247,1286150400"; d="scan'208";a="207683342" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 27 Oct 2010 17:48:55 +0000 Received: from Freds-Computer.local (sjc-vpn6-486.cisco.com [10.21.121.230]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9RHmlkV021901; Wed, 27 Oct 2010 17:48:50 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Wed, 27 Oct 2010 10:48:55 -0700 X-PGP-Universal: processed; by Freds-Computer.local on Wed, 27 Oct 2010 10:48:55 -0700 Mime-Version: 1.0 (Apple Message framework v1081) From: Fred Baker In-Reply-To: <4CC861F1.8020400@po.ntts.co.jp> Date: Wed, 27 Oct 2010 10:48:40 -0700 Message-Id: <923C74C3-1949-4807-B98C-F9482663648E@cisco.com> References: <4CC85CDF.6010702@po.ntts.co.jp> <10A1401B-0139-495E-AD2B-3734A0FC795F@cisco.com> <4CC861F1.8020400@po.ntts.co.jp> To: IETF SmartPower Directorate X-Mailer: Apple Mail (2.1081) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Satoru Kanno , David Meyer Subject: Re: [smartpowerdir] Internet Protocols for the Smart Grid X-BeenThere: smartpowerdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Members of the Smart Power Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 17:47:06 -0000 Question - any opinions on NTT proprietary cipher suites in the = draft-baker-ietf-core? On Oct 27, 2010, at 10:31 AM, Satoru Kanno wrote: > Dear Fred, >=20 > Thank you for your reply. >=20 > (2010/10/28 2:14), Fred Baker wrote: >> What is the RFC number? >>=20 >=20 > o TLS RFC > RFC5932, Camellia Cipher Suites for TLS > http://www.ietf.org/rfc/rfc5932.txt >=20 > o IPsec RFC > RFC 5529, Modes of Operation for Camellia for Use with IPsec > http://www.ietf.org/rfc/rfc5529.txt >=20 > RFC 4312, The Camellia Cipher Algorithm and Its Use With IPsec > http://www.ietf.org/rfc/rfc4312.txt >=20 > Regards, > Satoru >=20 >> On Oct 27, 2010, at 10:09 AM, Satoru Kanno wrote: >>=20 >>> Dear Fred, >>>=20 >>> My name is Satoru Kanno from NTT Software. >>> I am working at standardization activity for Camellia cipher = algorithm. >>>=20 >>> I found your internet draft for 'Internet Protocol for the Smart = Grid'. >>>=20 >>> The your draft is referring to AES as suites as IPsec and TLS. >>> We hope to add the Camellia's RFCs to your draft as OPTIONAL, >>> because we strongly believe that Camellia has been specified in = IPsec >>> and TLS etc in IETF as well as AES. >>>=20 >>> Additionally, the Smart Grid is important topics for NTT :) >>>=20 >>> What do you think? >>>=20 >>> o Camellia Information >>> http://info.isl.ntt.co.jp/crypt/eng/camellia/intro.html >>>=20 >>> o Standardization related information >>> http://info.isl.ntt.co.jp/crypt/eng/camellia/standard.html >>>=20 >>> Best regards, >>>=20 >>> -- >>> Satoru Kanno >>>=20 >>> Security Business Unit >>> Mobile and Security Solution Business Group >>> NTT Software Corporation >>>=20 >>> e-mail: kanno.satoru@po.ntts.co.jp >>>=20 >>=20 >>=20 >=20 >=20 > --=20 > Satoru Kanno >=20 > Security Business Unit > Mobile and Security Solution Business Group > NTT Software Corporation >=20 > e-mail: kanno.satoru@po.ntts.co.jp >=20 From vint@google.com Wed Oct 27 10:56:39 2010 Return-Path: X-Original-To: smartpowerdir@core3.amsl.com Delivered-To: smartpowerdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FF4E3A6888 for ; Wed, 27 Oct 2010 10:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.477 X-Spam-Level: X-Spam-Status: No, score=-106.477 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxpAqTG+VZeZ for ; Wed, 27 Oct 2010 10:56:38 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 1DB823A6828 for ; Wed, 27 Oct 2010 10:56:37 -0700 (PDT) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id o9RHwRVk022140 for ; Wed, 27 Oct 2010 10:58:27 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1288202307; bh=MhDYU+2oma2g7LqF5K9FBdNJVlY=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=EdYox5PN0xtIiRWLHv+AZSKw/PIxmfs324m8EyG6kj7WFMIoJVv2UoDbRi1uLoAYl DlRod3JxubHRU1VVvnvxw== Received: from qwb7 (qwb7.prod.google.com [10.241.193.71]) by hpaq1.eem.corp.google.com with ESMTP id o9RHvFvi019725 for ; Wed, 27 Oct 2010 10:58:26 -0700 Received: by qwb7 with SMTP id 7so952864qwb.3 for ; Wed, 27 Oct 2010 10:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8gVr7MnGB8UWsUmuOTT2sSVT/zDj3PFDYLkFwyUGdI8=; b=U2f9/rn9JNgvw/lhNEhM2ljdek+80vNOu+d5QiPFq1LGz07e+D5J4R9h6hUo1zp1KB 2VBN7iEnoQ4TJ4wkVvkw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pPEuMX3dYP9a594iy3+PTw/55MTjDnXHK8d0iJ5ULLHi+YjNyhpZi3S49ix/qZKQ+j 1OY7AqI/4uJXuCzFi9fg== MIME-Version: 1.0 Received: by 10.224.32.151 with SMTP id c23mr3153790qad.275.1288202305403; Wed, 27 Oct 2010 10:58:25 -0700 (PDT) Received: by 10.229.114.146 with HTTP; Wed, 27 Oct 2010 10:58:25 -0700 (PDT) In-Reply-To: <923C74C3-1949-4807-B98C-F9482663648E@cisco.com> References: <4CC85CDF.6010702@po.ntts.co.jp> <10A1401B-0139-495E-AD2B-3734A0FC795F@cisco.com> <4CC861F1.8020400@po.ntts.co.jp> <923C74C3-1949-4807-B98C-F9482663648E@cisco.com> Date: Wed, 27 Oct 2010 13:58:25 -0400 Message-ID: From: Vint Cerf To: Fred Baker Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: David Meyer , Satoru Kanno , IETF SmartPower Directorate Subject: Re: [smartpowerdir] Internet Protocols for the Smart Grid X-BeenThere: smartpowerdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Members of the Smart Power Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 17:56:39 -0000 I would have thought it preferable to avoid proprietary technology if at all possible unless it is provided gratis and in perpetuity to everyone? v On Wed, Oct 27, 2010 at 1:48 PM, Fred Baker wrote: > Question - any opinions on NTT proprietary cipher suites in the draft-bak= er-ietf-core? > > On Oct 27, 2010, at 10:31 AM, Satoru Kanno wrote: > >> Dear Fred, >> >> Thank you for your reply. >> >> (2010/10/28 2:14), Fred Baker wrote: >>> What is the RFC number? >>> >> >> o TLS RFC >> RFC5932, Camellia Cipher Suites for TLS >> http://www.ietf.org/rfc/rfc5932.txt >> >> o IPsec RFC >> RFC 5529, Modes of Operation for Camellia for Use with IPsec >> http://www.ietf.org/rfc/rfc5529.txt >> >> RFC 4312, The Camellia Cipher Algorithm and Its Use With IPsec >> http://www.ietf.org/rfc/rfc4312.txt >> >> Regards, >> Satoru >> >>> On Oct 27, 2010, at 10:09 AM, Satoru Kanno wrote: >>> >>>> Dear Fred, >>>> >>>> My name is Satoru Kanno from NTT Software. >>>> I am working at standardization activity for Camellia cipher algorithm= . >>>> >>>> I found your internet draft for 'Internet Protocol for the Smart Grid'= . >>>> >>>> The your draft is referring to AES as suites as IPsec and TLS. >>>> We hope to add the Camellia's RFCs to your draft as OPTIONAL, >>>> because we strongly believe that Camellia has been specified in IPsec >>>> and TLS etc in IETF as well as AES. >>>> >>>> Additionally, the Smart Grid is important topics for NTT :) >>>> >>>> What do you think? >>>> >>>> o Camellia Information >>>> =A0http://info.isl.ntt.co.jp/crypt/eng/camellia/intro.html >>>> >>>> o Standardization related information >>>> =A0http://info.isl.ntt.co.jp/crypt/eng/camellia/standard.html >>>> >>>> Best regards, >>>> >>>> -- >>>> Satoru Kanno >>>> >>>> Security Business Unit >>>> Mobile and Security Solution Business Group >>>> NTT Software Corporation >>>> >>>> e-mail: kanno.satoru@po.ntts.co.jp >>>> >>> >>> >> >> >> -- >> Satoru Kanno >> >> Security Business Unit >> Mobile and Security Solution Business Group >> NTT Software Corporation >> >> e-mail: kanno.satoru@po.ntts.co.jp >> > > From fred@cisco.com Thu Oct 28 10:45:21 2010 Return-Path: X-Original-To: smartpowerdir@core3.amsl.com Delivered-To: smartpowerdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEFF53A68EB for ; Thu, 28 Oct 2010 10:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.394 X-Spam-Level: X-Spam-Status: No, score=-110.394 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eINYKI9LRa9P for ; Thu, 28 Oct 2010 10:45:20 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id EA03A3A686A for ; Thu, 28 Oct 2010 10:45:20 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHpTyUyrR7H+/2dsb2JhbAChSnGjTJwvhUgEhFeFfIMI X-IronPort-AV: E=Sophos;i="4.58,253,1286150400"; d="scan'208";a="277349646" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 28 Oct 2010 17:47:13 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o9SHkaHR011332 for ; Thu, 28 Oct 2010 17:47:08 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Thu, 28 Oct 2010 10:47:13 -0700 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Thu, 28 Oct 2010 10:47:13 -0700 From: Fred Baker Date: Thu, 28 Oct 2010 10:47:08 -0700 References: <8D4701D4-6D03-445E-92E0-4FCBDD5F5EA8@cisco.com> To: IETF SmartPower Directorate Message-Id: Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: [smartpowerdir] Fwd: PAP #1 X-BeenThere: smartpowerdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Members of the Smart Power Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 17:45:21 -0000 Begin forwarded message: > From: Fred Baker > Date: October 28, 2010 10:46:30 AM PDT > To: Ron Ambrosio > Cc: SGIP-PAP01WG@SMARTGRIDLISTSERV.ORG > Subject: PAP #1 >=20 > We had a meeting regarding PAP #1 this morning, primarily discussing=20= >=20 > http://tools.ietf.org/html/draft-baker-ietf-core > "Internet Protocols for the Smart Grid", Fred Baker, Dave Meyer, > 25-Oct-10 >=20 > which was written at David's request.=20 >=20 > In the meeting this morning, one change was requested, which was the = citation of SG Networks' architectural picture of the Smart Grid as an = example of the use of the Internet Protocol Suite in the Smart Grid. The = IETF will need to review it and make sure it agrees that it is = reasonable, of course, but I agreed in principle to include the citation = if he sent the bibliographic information and a URL for an openly = accessible version of the document. >=20 > CSWG says it has reviewed it and finds it acceptable, and per the PAP = closing process we need a similar statement from SGAC. I am also taking = it into the document, when the above has been finalized, into the IETF = final review and publication process.