From nobody Wed Apr 1 04:36:18 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7F81A87C0 for ; Wed, 1 Apr 2015 04:36:17 -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=0 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LiZWCa7dsbPy for ; Wed, 1 Apr 2015 04:36:09 -0700 (PDT) Received: from mailscan1.extendcp.co.uk (mailscan39.extendcp.co.uk [176.32.230.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD90C1A6FCB for ; Wed, 1 Apr 2015 04:36:08 -0700 (PDT) Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mailscan2.hi.local) by mailscan-g75.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1YdGwH-0006h0-Vt; Wed, 01 Apr 2015 12:36:05 +0100 Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mail41.extendcp.co.uk) by mailscan2.hi.local with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1YdGwG-0005aF-AS; Wed, 01 Apr 2015 12:36:05 +0100 Received: from host86-156-208-9.range86-156.btcentralplus.com ([86.156.208.9] helo=[192.168.0.6]) by mail41.extendcp.com with esmtpsa (UNKNOWN:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1YdFc7-00079K-Dc; Wed, 01 Apr 2015 11:11:12 +0100 Message-ID: <551BC405.3070204@gridmerge.com> Date: Wed, 01 Apr 2015 11:10:13 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Max Pritikin (pritikin)" References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> <5512DE41.6030209@gmail.com> <77FA386512F0D748BC7C02C36EB1106D956D45@szxeml557-mbs.china.huawei.com> <7912.1427385447@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D95700F@szxeml557-mbs.china.huawei.com> <1F85BE1D-44A3-420A-8852-A4BA0DE213AC@cisco.com> <247ADDB2-807D-4AB5-A814-58381A929EB5@cisco.com> In-Reply-To: <247ADDB2-807D-4AB5-A814-58381A929EB5@cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030806010500010301010807" X-Authenticated-As: robert.cragie@gridmerge.com X-Extend-Src: mailout Archived-At: Cc: Michael Richardson , "Hedanping \(Ana\)" , "anima@ietf.org" Subject: Re: [Anima] Ownership Concept X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 11:36:17 -0000 This is a cryptographically signed message in MIME format. --------------ms030806010500010301010807 Content-Type: multipart/mixed; boundary="------------020605020702050404090906" This is a multi-part message in MIME format. --------------020605020702050404090906 Content-Type: multipart/alternative; boundary="------------060500060002070706020201" --------------060500060002070706020201 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi Max, Thanks for your responses. Further responses inline, bracketed by=20 Robert On 30/03/2015 18:03, Max Pritikin (pritikin) wrote: >> >> >>> There are certainly cases where I can see this being used but >>> conceptually it is not much different to a whitelist on the >>> registrar. >> >> The registrar is owned and operated by the domain owner. The >> cloud service is not. I argue MASA substantially simplifies the >> threat model. >> >> >> I see now that the purpose of the MASA service is not online=20 >> whitelisting, and the difference in the domain authority and the=20 >> MASA. >> >> >>> The only other operation it seems to do is to sign the domain >>> certificate. But the registrar could also do this - so I guess >>> this is really combining MASA and registrar in a single box. >>> Either way, the NE has to have the domain public key, whether >>> the MASA or the Registrar is authorised to issue domain >>> certificates on behalf of the Domain CA and any other public >>> keys relevant to the certificate chain. >> >> The MASA does not sign certs >> >> >> So why is it called a "signing authority" then? Confusing. I can = >> see it may sign authorisation tokes (see later). > > Understood. It signs the =93proof of logging=94 things we called=20 > =93authorization tokens=94. Please feel free to suggest terms that reso= nate. I think "authorization token" is fine. There needs to be more=20 detail on the process, that's all. >> >> So please explain the authorisation token in more detail and what=20 >> leads to its generation. This is a bit more than just logging. > > s4.1.2: NE only joins a domain if an authorization token is provided.=20 > This behavior of the NE ensures that a log of the authorization token=20 > is also a log of every time the NE joins a domain. OK > > s4.3.2: Registrar only allows the device to join the domain if the=20 > devices history (e.g. the log information) doesn=92t show it has joined= =20 > Mallory=92s domain. Or, if the registar doesn=92t care, maybe it just=20 > doesn=92t check. I would imagine Mallory's purpose is to manipulate the joining to=20 make it look as if the NE didn't join Mallory's domain. I see that the=20 MASA check is auxiliary and optional > > s4.3.3: Registrar MUST claim the device, obtaining an authorization=20 > token and ensuring a log entry is generated, in order to get the=20 > device to trust it. OK > >> As far as I can see (and please correct me if I am wrong), the=20 >> Mallory/honeypot detection isn't really shown in Figure 1. > > In figure1 note that =93device history log=94 and =93authorization toke= n=94=20 > are sent to the Domain from the MASA. The Domain then decides =93still = > accept device?=94 based on the log information. This is the Registrar=20 > checking for Mallory. If the log information shows an=20 > unknown/unexpected log entry then Mallory has been detected. > > It is still the Domain=92s policy decision about continuing. > >> For this to work, the NE would have to send details of the registrar=20 >> it has received, presumably relayed by the registrar itself (OCSP)? > > Ummm=85 didn=92t follow you completely. I suggest keeping the log=20 > information in the cloud and delivering it to the registrar from there = > because I don=92t trust the NE to reveal that it is has been corrupted = > by Mallory. I think what is missing is that the request needs to come from the = NE and contain information about the Domain the NE thinks it is=20 connecting to as well as the NE. Otherwise Mallory could successfully=20 act as MITM and convince the NE that it is a legitimate domain. See=20 attached diagrams. >> Then the MASA service sends a signed authorisation token back,=20 >> attesting the validity of the Registrar. A honeypot would not be able = >> to provide valid credentials so at that point would fail. > > Correct, the Mallory domain would have to contact the MASA to obtain a = > signed authorization token which ensures that the event has been logged= =2E > >> If a honeypot tried to use a honeypot MASA, it wouldn't have the=20 >> private key to sign the authorisation token so that would fail to. If = >> the honeypot claims the MASA is unreachable - another failure. So I=20 >> agree, a good way to simplify the threat model. >> >> >> >>> Regarding the honeypot (Mallory) attack - the NE is going to >>> find out it's a honeypot as the honeypot will not be able to >>> issue valid domain certificates. >> >> The NE can't identify a "valid" domain certificate so I don't >> believe this is correct. >> >> >> It could if it were pre-provisioned with the Registrar's public=20 >> key and Domain CA public key. As you point out, in Section 2, "As a=20 >> service offering the MASA can incorporate many of the bootstrapping=20 >> elements (such as the Registrar and the Domain CA) into the overall=20 >> service." So surely in this case, there is no separation of CAs?= > > For any given domain one could do this. But it doesn=92t work at scale = > or if the target domain isn=92t known when the device leaves the vendor= =2E All the more reason for the additional data needed at the=20 beginning of the sequence (Domain ID sent to NE) Robert --------------060500060002070706020201 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Max,

Thanks for your responses. Further responses inline, bracketed by <RCC2></RCC2>

Robert

On 30/03/2015 18:03, Max Pritikin (pritikin) wrote:

There are certainly cases where I can see this being used but conceptually it is not much different to a whitelist on the registrar.

The registrar is owned and operated by the domain owner. The cloud service is not. I argue MASA substantially simplifies the threat model.=A0=

<RCC>I see now that the purpose of the MASA service is not online whitelisting, and the difference in the domain authority and the MASA.</RCC>

The only other operation it seems to do is to sign the domain certificate. But the registrar could also do this - so I guess this is really combining MASA and registrar in a single box. Either way, the NE has to have the domain public key, whether the MASA or the Registrar is authorised to issue domain certificates on behalf of the Domain CA and any other public keys relevant to the certificate chain.
The MASA does not sign certs

<RCC>So why is it called a "signing authority" then? Confusing. I can see it may sign authorisation tokes (see later).

Understood. It signs the =93proof of logging=94 things we called =93authorization tokens=94. Please feel free to suggest terms that resonate.
<RCC2>I think "authorization token" is fine. There needs to be more detail on the process, that's all.</RCC2>
<RCC>
So please explain the authorisation token in more detail and what leads to its generation. This is a bit more than just logging.

s4.1.2: NE only joins a domain if an authorization token is provided. This behavior of the NE ensures that a log of the authorization token is also a log of every time the NE joins a domain.
<RCC2>OK</RCC2>

s4.3.2: Registrar only allows the device to join the domain if the devices history (e.g. the log information) doesn=92t sho= w it has joined Mallory=92s domain. Or, if the registar doesn=92t= care, maybe it just doesn=92t check.
<RCC2>I would imagine Mallory's purpose is to manipulate the joining to make it look as if the NE didn't join Mallory's domain. I see that the MASA check is auxiliary and optional</RCC2>

s4.3.3: Registrar MUST claim the device, obtaining an authorization token and ensuring a log entry is generated, in order to get the device to trust it.
<RCC2>OK</RCC2>

As far as I can see (and please correct me if I am wrong), the Mallory/honeypot detection isn't really shown in Figure 1.

In figure1 note that =93device history log=94 and =93authorization token=94 are sent to the Domain from the MASA.= The Domain then decides =93still accept device?=94 based on the= log information. This is the Registrar checking for Mallory. If the log information shows an unknown/unexpected log entry then Mallory has been detected.=A0

It is still the Domain=92s policy decision about continuing.= =A0

For this to work, the NE would have to send details of the registrar it has received, presumably relayed by the registrar itself (OCSP)?

Ummm=85 didn=92t follow you completely. I suggest keeping th= e log information in the cloud and delivering it to the registrar from there because I don=92t trust the NE to reveal that it is has been corrupted by Mallory.
<RCC2>I think what is missing is that the request needs to come from the NE and contain information about the Domain the NE thinks it is connecting to as well as the NE. Otherwise Mallory could successfully act as MITM and convince the NE that it is a legitimate domain. See attached diagrams.</RCC2>
Then the MASA service sends a signed authorisation token back, attesting the validity of the Registrar. A honeypot would not be able to provide valid credentials so at that point would fail.

Correct, the Mallory domain would have to contact the MASA to obtain a signed authorization token which ensures that the event has been logged.=A0

If a honeypot tried to use a honeypot MASA, it wouldn't have the private key to sign the authorisation token so that would fail to. If the honeypot claims the MASA is unreachable - another failure. So I agree, a good way to simplify the threat model.
</RCC>
=A0

Regarding the honeypot (Mallory) attack - the NE is going to find out it's a honeypot as the honeypot will not be able to issue valid domain certificates.

The NE can't identify a "valid" domain certificate so I don't believe this is correct.=A0=

<RCC>It could if it were pre-provisioned with the Registrar's public key and Domain CA public key. As you point out, in Section 2, "As a service offering the MASA can incorporate many of the bootstrapping elements (such as the Registrar and the Domain CA) into the overall service." So surely in this case, there is no separation of CAs?</RCC>=A0

For any given domain one could do this. But it doesn=92t wor= k at scale or if the target domain isn=92t known when the device leaves the vendor.
<RCC2>All the more reason for the additional data needed at the beginning of the sequence (Domain ID sent to NE)</RCC2>
=
Robert
--------------060500060002070706020201-- --------------020605020702050404090906 Content-Type: text/plain; charset=windows-1252; name="draft-pritikin-anima-bootstrapping-keyinfra-diags.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename*0="draft-pritikin-anima-bootstrapping-keyinfra-diags.txt" +---------+ +----------+ +-----------+ | New | | | | MASA | | Entity | | Domain | | Service | | | | | | (Internet)| +---------+ +----------+ +-----------+ | | | |<-------discovery--------->| | |---802.1AR credential----->| | | | | | [ accept device? ] | | | | | |---802.1AR identity-------->| | |---Domain ID--------------->| | | | | | [device belongs] | | [to domain? ] | | | | | [update audit log] | | | | |<---device history log------| | |<-- authorization token-----| | | | | [ still accept device?] | | | | |<----authorization token---| | |<----domain information----| | | | | [auth token valid?] | | | | | |----domain enrolment------>| | |<----domain certificate----| | | | Current model. Issue is that a MITM could spoof itself as a valid domain = due to the limited ability of the NE to check: +---------+ +----------+ +----------+ = +-----------+ | New | | | | | = | MASA | | Entity | | MITM | | Domain | = | Service | | | | | | | = | (Internet)| +---------+ +----------+ +----------+ = +-----------+ | | | = | |<-------discovery--------->| | = | |---802.1AR credential----->| | = |=20 | |---802.1AR credential----->| = | | | [ accept device? = ] | | | | = | | | |---802.1A= R identity-------->| | | |---Domain= ID--------------->| | | | = | | | | = [device belongs] | | | = [to domain? ] | | | = | | | | = [update audit log] | | | = | | | |<---devic= e history log------| | | |<-- autho= rization token-----| | | | = | | | [ still accept devi= ce?] | | | | = | | |<----authorization token---| = | | |<----domain information----| = | |<----authorization token---| | = | |<-----!!MD information!!---| | = | | | | = | [auth token valid?] | | = | | | | = | |----domain enrolment------>| | = | |<----!!MD certificate!!----| | = | | | MD: Mallory Domain This can be fixed by binding the Domain ID with the NE ID and sending bot= h to MASA service, originating from the NE. This limits the Registrar to = a pass-through service (it can augment the flow with its own Domain ID). = MASA can then check a) the NE is valid, b) the Domain the NE is in contac= t with is valid and c) the Domain it received the request from is valid. =20 +---------+ +----------+ +-----------+ | New | | | | MASA | | Entity | | Domain | | Service | | | | | | (Internet)| +---------+ +----------+ +-----------+ | | | |<-------discovery--------->| | |<---Domain ID--------------| | | | | |---802.1AR credential----->| | |---Bound Domain ID-------->| | | | | | [ accept device? ] | | | | | |---802.1AR identity-------->| | |---Bound Domain ID--------->| | |---Domain ID--------------->| | | | | | [device belongs] | | [to domain? ] | | | | | [update audit log] | | | | |<---device history log------| | |<---Bound Domain ID---------| | |<---Domain ID---------------| | |<-- authorization token-----| | | | | [ still accept device?] | | | | |<----Bound Domain ID-------| | |<----Domain ID-------------| | |<----authorization token---| | |<----domain information----| | | | | [auth token valid?] | | | | | |----domain enrolment------>| | |<----domain certificate----| | | | | =20 I'm not sure all the information in the later flows is required but the B= ound Domain ID is the important addition. --------------020605020702050404090906-- --------------ms030806010500010301010807 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRnzCC BXQwggRcoAMCAQICECdm7lbrSfOOq9dwovyE3iIwDQYJKoZIhvcNAQEMBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w MDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4MzhaMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDErMCkGA1UEAxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJHoVJLSClaxrA0k3cXPRGd0mSs3 o30jcABxvFPfxPoqEo9LfxBWvZ9wcrdhf8lLDxenPeOwBGHu/xGXx/SGPgr6Plz5k+Y0etkU a+ecs4Wggnp2r3GQ1+z9DfqcbPrfsIL0FH75vsSmL09/mX+1/GdDcr0MANaJ62ss0+2PmBwU q37l42782KjkkiTaQ2tiuFX96sG8bLaL8w6NmuSbbGmZ+HhIMEXVreENPEVg/DKWUSe8Z8PK LrZr6kbHxyCgsR9l3kgIuqROqfKDRjeE6+jMgUhDZ05yKptcvUwbKIpcInu0q5jZ7uBRg8MJ Rk5tPpn6lRfafDNXQTyNUe0LtlyvLGMa31fIP7zpXcSbr0WZ4qNaJLS6qVY9z2+q/0lYvvCo //S4rek3+7q49As6+ehDQh6J2ITLE/HZu+GJYLiMKFasFB2cCudx688O3T2plqFIvTz3r7UN IkzAEYHsVjv206LiW7eyBCJSlYCTaeiOTGXxkQMtcHQC6otnFSlpUgK7199QalVGv6CjKGF/ cNDDoqosIapHziicBkV2v4IYJ7TVrrTLUOZr9EyGcTDppt8WhuDY/0Dd+9BCiH+jMzouXB5B EYFjzhhxayvspoq3MVw6akfgw3lZ1iAar/JqmKpyvFdK0kuduxD8sExB5e0dPV4onZzMv7NR 2qdH5YRTAgMBAAGjgfQwgfEwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFLuvfgI9+qbxPISOre44mOzZMjLUMA4GA1UdDwEB/wQEAwIBhjAPBgNVHRMBAf8E BTADAQH/MBEGA1UdIAQKMAgwBgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3Js LnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEE KTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEB DAUAA4IBAQBkv4PxX5qF0M24oSlXDeha99HpPvJ2BG7xUnC7Hjz/TQ10asyBgiXTw6AqXUz1 uouhbcRUCXXH4ycOXYR5N0ATd/W0rBzQO6sXEtbvNBh+K+l506tXRQyvKPrQ2+VQlYi734VX aX2S2FLKc4G/HPPmuG5mEQWzHpQtf5GVklnxTM6jkXFMfEcMOwsZ9qGxbIY+XKrELoLL+QeW ukhNkPKUyKlzousGeyOd3qLzTVWfemFFmBhox15AayP1eXrvjLVri7dvRvR78T1LBNiTgFla 4EEkHbKPFWBYR9vvbkb9FfXZX5qz29i45ECzzZc5roW7HY683Ieb0abv8TtvEDhvMIIF5jCC A86gAwIBAgIQapvhODv/K2ufAdXZuKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAwWhcNMjgwMTA5MjM1OTU5WjCBlzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtMtaDRfTpYPpynMS6n 9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlAckY1wgOkUMgz KlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL55AqLPikF lgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHWse9t GKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK +xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNV HQ4EFgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQI MAYBAf8CAQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9j cmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEG CCsGAQUFBwEBBGUwYzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09N T0RPUlNBQWRkVHJ1c3RDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2Nh LmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81 zd9A/tNx4+jsQgwRGiHjZrAYayZrrm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIa l9v5IkDcZoFD7f3iT7PdkHJY9B51csvU50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwp WZT89RY0wpJO+2V6eXEGGHsROs3njeP9DqqqAJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNM UH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/56ebTOWlcrurffade2022O/tUU1gb4jfW CcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3ztveBdvUCIYZojTq/OCR6MvnzS6X 72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+IMMAj1KcL/Zo9jzJ16HO5m60 ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBrGk1II+3yL8aorYew6CQv dVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggyh/TqvXG5v7zmEVDN XFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9KVkfKehIwggY5 MIIFIaADAgECAhEAkJNVgmy0T3j/sFnejfTMyTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTQwOTE2MDAwMDAwWhcN MTcwOTE1MjM1OTU5WjCCATcxCzAJBgNVBAYTAkdCMRAwDgYDVQQREwdXRjQgNFdBMRcwFQYD VQQIEw5XZXN0IFlvcmtzaGlyZTESMBAGA1UEBxMJV2FrZWZpZWxkMRQwEgYDVQQJEwtHcmFu Z2UgTW9vcjEfMB0GA1UECRMWODkgR3JlZW5maWVsZCBDcmVzY2VudDEXMBUGA1UEChMOR3Jp ZG1lcmdlIEx0ZC4xNDAyBgNVBAsTK0lzc3VlZCB0aHJvdWdoIEdyaWRtZXJnZSBMdGQuIEUt UEtJIE1hbmFnZXIxHzAdBgNVBAsTFkNvcnBvcmF0ZSBTZWN1cmUgRW1haWwxFjAUBgNVBAMT DVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0BCQEWG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALTtrEYc/EYQZDn+/Byj786j qzQJukVnEZ0qu6G8Y/QZphmITLPJJCxlCvJhRGCt5zRDfwG1lM0k77mTVP166mrPMKfEbhAF mhW54app3f02j/E0T73Wkwqhc2xj+vs6ox+kXRZIiEa/VY1TXd8ALZZAJ2uPQm+3QByE0cO6 7Q7jr5dmZuXAuygh5Q7MvzxL0vKmxhJ1n0veVDwk+BifimRX+HHU3XTGrqySkiN4Amdm7ESD qdO7UAoezIGZoA/fTJE9CS4f4tVXcKhfGlp/Tw3K9q9cp6cjYD802hnFoiSQ9PgLviP20lcH CIGn91WkYhuYG9u8Fzgzmu0yVK5L0kkCAwEAAaOCAdswggHXMB8GA1UdIwQYMBaAFIKvbIz4 xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBTSD2iG48824eEQkBLu4BgdWzh49TAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIw RgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAwUwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1 cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9j YS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNy bDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LmNvbW9kb2NhLmNv bS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQG CCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJgYDVR0RBB8wHYEbcm9iZXJ0 LmNyYWdpZUBncmlkbWVyZ2UuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAq8C9mIiSV9Nj9ZjHa 1kupbDGYy57v5fCk9lT++uiwGBP9yIFd9Gr8wISOl+96l9OLo8E+5CcPLyt96H4ez/ksXjC1 5EhzuhUB7HNi2b9GLDenjiHW4vBmSoIAbt9Pnz6zZsPH7eBPBcqkIWLFuqKBYUoXKLpzrVtr Kgv6PM3t2+4YakBnMWjpcqzinurEeGq4mh3gHTv03wcyT6eQVCu5k4yaJxoQReYtYIjv+W+m LmT/ZW61ZATZb2adV8xPejUlWSq4+2bpRbXZpD9FAmomNC8fSvGUUhMfYq5t5IUPHfP0kEH5 WQVWgVfpcf6Q8rnpWznsMiJrucUpJf8ZenHtMYIEKDCCBCQCAQEwga0wgZcxCzAJBgNVBAYT AkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkJNVgmy0T3j/sFnejfTMyTAJ BgUrDgMCGgUAoIICTzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNTA0MDExMDEwMTNaMCMGCSqGSIb3DQEJBDEWBBT02EQn3pg0ECpuim0vjX7sjGLcyzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG+BgkrBgEEAYI3EAQxgbAwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhEAkJNVgmy0T3j/sFnejfTMyTCBwAYLKoZIhvcNAQkQAgsxgbCgga0w gZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8g UlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkJNVgmy0 T3j/sFnejfTMyTANBgkqhkiG9w0BAQEFAASCAQA+VokuY1cNjgH/NDGGF5MnMrU/mfC6hxvA wH3izaQL8SP6xCBc1Gx8cQY8MuiIsiN2g6P7E3tHQ6P0GfQMUgW6yDsAt3dwjAw1YwquDSLY e/WVWdIuynC/Vl2NSNHNudM0A6/2L1Iml/LebOq/5DUH5JL3H9tj2tnc/VdVEFhI9GfVjFGo zzr4S5CkNDWNy+6aEcCToEq6IQsuwb4q+Wxlphhk4Wkej2FZtenC5HGjMr6AIpuxmvcKUgsZ Bm3hmZwSGf1QJG9gz1KGOSiGowmavlnDWRsfN/qRZh7t1XjCyYMQkIL0kuDGy8IElsZwGkXE lwyoL+9HcNlEknZIxy5WAAAAAAAA --------------ms030806010500010301010807-- From nobody Wed Apr 1 09:52:57 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18EA51AD0AD for ; Wed, 1 Apr 2015 09:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIcYhNfkLgGR for ; Wed, 1 Apr 2015 09:52:50 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A5CC1ACE09 for ; Wed, 1 Apr 2015 09:52:50 -0700 (PDT) Received: by lboc7 with SMTP id c7so40831451lbo.1 for ; Wed, 01 Apr 2015 09:52:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=KsOAPbGEVMsJH6cpyQQF5d7j35D1g7pGhQUuPhcwssQ=; b=qTZHsKaBTdCpgBHkgsh/ejRmC51sQi+Ty7rBF+FjrTOaEfJBGmCg3KR8ZFmpEBTbX8 IoW/3ZhSavlXLh0zXTxI2mBPcD09PAbBnFmvq77mhYLa9PxV7Wq8NjAeoov4TwLEva7n dwdYzKsnnpl7aOH6y6EKDfnQe58hqrpAzOZYjjRLkEixnFZTsXhzIZHILxYUtWzRDsn2 hSD5qXvPAkw5Zt+hGx6WrH9ohn4lM5whoWWnGgosQVbIuNVWATmkw3k0OygMYTHfA6gc EjrfInIYlTr28IKsL86/Ycy1/tKWkhRS2sId5Vi5FqpNYjuV+RKniypbepurDxRStyFx jryw== MIME-Version: 1.0 X-Received: by 10.112.157.100 with SMTP id wl4mr36979302lbb.108.1427907168670; Wed, 01 Apr 2015 09:52:48 -0700 (PDT) Received: by 10.114.59.103 with HTTP; Wed, 1 Apr 2015 09:52:48 -0700 (PDT) In-Reply-To: <551A53B8.7020005@gmx.net> References: <5511DDA0.6040308@gmx.net> <14422.1427751694@sandelman.ca> <551A53B8.7020005@gmx.net> Date: Wed, 1 Apr 2015 11:52:48 -0500 Message-ID: From: Behcet Sarikaya To: Hannes Tschofenig Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Michael Richardson , "anima@ietf.org" Subject: Re: [Anima] OMA Lightweight M2M X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 16:52:52 -0000 On Tue, Mar 31, 2015 at 2:58 AM, Hannes Tschofenig wrote: > Hi Michael, > > the 'OMA Lightweight M2M (LWM2M) protocol' is the right link to click on > (which is listed at > http://openmobilealliance.org/about-oma/work-program/m2m-enablers/). > > There are a few documents including requirements, architecture, etc. but > the main document to focus on is the technical specification. > > If it helps, I can also provide my high-level overview of what the > specification does. Yes, please do so. Regards, Behcet > > Ciao > Hannes > > On 03/30/2015 11:41 PM, Michael Richardson wrote: >> Hannes Tschofenig wrote: >> > Since several persons do not seem to be aware of it I wanted to post a >> > link to the list: >> > http://openmobilealliance.org/about-oma/work-program/m2m-enablers/ >> >> > I would be interested to see whether there is overlap between ZeroTouch >> > / ANIMA bootstrapping and the OMA work. >> >> After some poking around, I get to: >> http://openmobilealliance.org/about-oma/work-program/device-management/ >> >> which has about 20 documents to read. >> When I picked to first one, I got to: >> http://technical.openmobilealliance.org/Technical/technical-information/release-program/current-releases/dm-v1-1-2 >> >> then I asked for it, and got a copyright notice asking me to type stuff in. >> then I got to: >> http://technical.openmobilealliance.org/Technical/Release_Program/docs/DM/V1_1_2-20040113-A/OMA-SyncML-DM-Bootstrap-V1_1_2-20031209-A.pdf >> >> which I see is 25 pages of PDF. >> >> I wonder if there is a shorter reading list. >> >> I think, in this case of this document, "SyncML", it's not applicable because >> it says: >> >> "e.g. by inserting a SIM, the prerequisites for this process are in place" >> >> so, the assumption seems to be that a shared secret (SIM protocol) is >> available for bootstrap. I will read further this week, as the OMA >> LwM2M is something I had wanted to look further into, but I'm really not >> feeling the love with this organization. >> > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Tue Apr 7 23:57:29 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210EF1B29FC for ; Tue, 7 Apr 2015 23:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpZCJ2cQuuVj for ; Tue, 7 Apr 2015 23:57:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C3FB1B29F8 for ; Tue, 7 Apr 2015 23:57:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRD73325; Wed, 08 Apr 2015 06:57:23 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 8 Apr 2015 07:57:22 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.135]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Wed, 8 Apr 2015 14:57:15 +0800 From: Sheng Jiang To: "anima@ietf.org" Thread-Topic: ANIMA minutes for IETF 92 Thread-Index: AdBxyT6gLSSDY2XhR9ulOGQAmBWoig== Date: Wed, 8 Apr 2015 06:57:15 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B925F4F91F0@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.197] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "anima-chairs@tools.ietf.org" Subject: [Anima] ANIMA minutes for IETF 92 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 06:57:28 -0000 SGksIGFsbCwNCg0KVGhlIG1pbnV0ZXMgZm9yIHRoZSBBTklNQSBzZXNzaW9ucyBhdCBJRVRGOTIg aW4gRGFsbGFzIGNhbiBiZSBmb3VuZCBhdDoNCg0KaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVk aW5ncy85Mi9taW51dGVzL21pbnV0ZXMtOTItYW5pbWENCg0KTWFueSB0aGFua3MgdG8gTGF1cmVu dCBDaWF2YWdsaWEgYW5kIEJpbmcgTGl1IGZvciB0YWtpbmcgbWludXRlcy4NCg0KUGxlYXNlIHNl bmQgYW55IGNvcnJlY3Rpb25zIHRvIHRoZSBjaGFpcnMuDQoNCkJlc3QgcmVnYXJkcywNCg0KU2hl bmcgKyBUb2VybGVzcw0K From nobody Wed Apr 8 20:06:34 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7C01B2B72 for ; Wed, 8 Apr 2015 20:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8M5e0BS4n8LM for ; Wed, 8 Apr 2015 20:06:32 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97F721B2B6D for ; Wed, 8 Apr 2015 20:06:30 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRE71965; Thu, 09 Apr 2015 03:06:29 +0000 (GMT) Received: from SZXEML426-HUB.china.huawei.com (10.82.67.181) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 9 Apr 2015 04:06:28 +0100 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.131]) by szxeml426-hub.china.huawei.com ([10.82.67.181]) with mapi id 14.03.0158.001; Thu, 9 Apr 2015 11:06:25 +0800 From: "Hedanping (Ana)" To: "robert.cragie@gridmerge.com" , "Max Pritikin (pritikin)" Thread-Topic: [Anima] Ownership Concept Thread-Index: AQHQZn+XTQng45mwMk+HZqqnogMqdJ0rrpGAgAErGoCAAWoPYIAAJEeAgACJpQD//4q5gIAAbnWAgAAavACAAwvOAIACsluAgAKxQYCADJZlwA== Date: Thu, 9 Apr 2015 03:06:24 +0000 Message-ID: <77FA386512F0D748BC7C02C36EB1106D95C712@szxeml557-mbs.china.huawei.com> References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> <5512DE41.6030209@gmail.com> <77FA386512F0D748BC7C02C36EB1106D956D45@szxeml557-mbs.china.huawei.com> <7912.1427385447@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D95700F@szxeml557-mbs.china.huawei.com> <1F85BE1D-44A3-420A-8852-A4BA0DE213AC@cisco.com> <247ADDB2-807D-4AB5-A814-58381A929EB5@cisco.com> <551BC405.3070204@gridmerge.com> In-Reply-To: <551BC405.3070204@gridmerge.com> Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.94.103] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Michael Richardson , "anima@ietf.org" Subject: Re: [Anima] Ownership Concept X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 03:06:33 -0000 Hi Max, Please see my comments inline. >-----Original Message----- >From: Robert Cragie [mailto:robert.cragie@gridmerge.com] >Sent: Wednesday, April 01, 2015 6:10 PM >To: Max Pritikin (pritikin) >Cc: Hedanping (Ana); Michael Richardson; anima@ietf.org >Subject: Re: [Anima] Ownership Concept > >Hi Max, > >Thanks for your responses. Further responses inline, bracketed by > > >For any given domain one could do this. But it doesn't work at scale or = if the >target domain isn't known when the device leaves the vendor. >All the more reason for the additional data needed at the beginnin= g of >the sequence (Domain ID sent to NE) Agree, my understanding from the draft is that 'Registrar is informed a pri= ori the unique identifier (e.g. serial number)... ', the vendor should alr= eady know the domain/registrar before the device leaves, and the registrar = is informed of the device list. If that's the case, why not pre-configure t= he device with the domain ID/ registrar ID or certificates?=20 Besides, if the NE is moved from one domain to another, necessary configura= tion should be done to the NE and corresponding registrars should be inform= ed, and the registrar must trust such configuration. Therefore MASA's log i= nformation is not important to the registrar/the joining NE and may not be = part of the bootstrapping messages. Ana From nobody Wed Apr 8 22:51:58 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E50811B2CB1 for ; Wed, 8 Apr 2015 22:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xBhMK6IRfk4 for ; Wed, 8 Apr 2015 22:51:55 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14AA51B2CAB for ; Wed, 8 Apr 2015 22:51:55 -0700 (PDT) Received: by paboj16 with SMTP id oj16so138943222pab.0 for ; Wed, 08 Apr 2015 22:51:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=aZRdWJb2Y7YvLtcGk6xb1G89Tt+Cctrva3eKmoUaSDs=; b=TMjl22vLOBNmAV7UD2aNOd7wsKEXJM3dqz5Dkkpu6Dy5ChHxjbVrH8lhUXtw/rMCuh A23kJKcChpvj8Tb6G8bXDtODw2rjQy/uB6xnYtjf5sUfmbu+rdyCvrXBi7RriKFDkWdb fnEepntv7UgZXFBLcawd1pT7xvG64sldkgv4wpWKs5AWNz/YH//NKpgRyXxLTpJs6c1D dGWlvGqpT1BQoyA4QwHJSdvU7HIX8qdoAlOKD6dic3g05+SyIGiBfDcGFl2s8rSaAp0U Ci6uxFg+pZJpwWJQBUbbk9lUcc/KWw7MHY2zMvXO03UXmUT2ZT2+3oztIjdkVqVw70F+ 1QTw== X-Received: by 10.68.248.98 with SMTP id yl2mr51722501pbc.41.1428558714734; Wed, 08 Apr 2015 22:51:54 -0700 (PDT) Received: from ?IPv6:2406:e007:4c2b:1:28cc:dc4c:9703:6781? ([2406:e007:4c2b:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id dd1sm12907614pbb.57.2015.04.08.22.51.47 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Apr 2015 22:51:53 -0700 (PDT) Message-ID: <55261379.7020000@gmail.com> Date: Thu, 09 Apr 2015 17:51:53 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Hedanping (Ana)" , "robert.cragie@gridmerge.com" , "Max Pritikin (pritikin)" References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> <5512DE41.6030209@gmail.com> <77FA386512F0D748BC7C02C36EB1106D956D45@szxeml557-mbs.china.huawei.com> <7912.1427385447@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D95700F@szxeml557-mbs.china.huawei.com> <1F85BE1D-44A3-420A-8852-A4BA0DE213AC@cisco.com> <247ADDB2-807D-4AB5-A814-58381A929EB5@cisco.com> <551BC405.3070204@gridmerge.com> <77FA386512F0D748BC7C02C36EB1106D95C712@szxeml557-mbs.china.huawei.com> In-Reply-To: <77FA386512F0D748BC7C02C36EB1106D95C712@szxeml557-mbs.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Michael Richardson , "anima@ietf.org" Subject: Re: [Anima] Ownership Concept X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 05:51:57 -0000 Hi Ana, On 09/04/2015 15:06, Hedanping (Ana) wrote: > Hi Max, > Please see my comments inline. > > >-----Original Message----- > >From: Robert Cragie [mailto:robert.cragie@gridmerge.com] > >Sent: Wednesday, April 01, 2015 6:10 PM > >To: Max Pritikin (pritikin) > >Cc: Hedanping (Ana); Michael Richardson; anima@ietf.org > >Subject: Re: [Anima] Ownership Concept > > > >Hi Max, > > > >Thanks for your responses. Further responses inline, bracketed by > > > > > >For any given domain one could do this. But it doesn't work at scale or if the > >target domain isn't known when the device leaves the vendor. > >All the more reason for the additional data needed at the beginning of > >the sequence (Domain ID sent to NE) > > > Agree, my understanding from the draft is that 'Registrar is informed a priori the unique identifier (e.g. serial number)... ', the vendor should already know the domain/registrar before the device leaves, I don't think that is realistic. The device could be sold to a dealer by the manufacturer, sit in the dealer's warehouse for a year, and then be sold by mail order to a PO Box address in another country. In a managed network you can assume that the device identity is made known to the registrar before it is connected to the the network, but there will be many cases where there is no prior communication of any kind between the registrar and the manufacturer. In an unmanaged network there is also no pre-registration at all. Brian > and the registrar is informed of the device list. If that's the case, why not pre-configure the device with the domain ID/ registrar ID or certificates? > Besides, if the NE is moved from one domain to another, necessary configuration should be done to the NE and corresponding registrars should be informed, and the registrar must trust such configuration. Therefore MASA's log information is not important to the registrar/the joining NE and may not be part of the bootstrapping messages. > > Ana > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Thu Apr 9 12:04:38 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E021A8986 for ; Thu, 9 Apr 2015 12:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3koF2sPPcom for ; Thu, 9 Apr 2015 12:04:36 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 263E61A89C4 for ; Thu, 9 Apr 2015 12:04:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3559; q=dns/txt; s=iport; t=1428606273; x=1429815873; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=5mrgzr0tp4QBEAptkuV5DK/L4w4H1dLuo/uScAkbDXk=; b=Nv7zWG0b1ID4J1EtRbl6tWqbn8Kb7Itfy94VRmBbP4Wdk3JHaQK8j0Pk ax4pUd8y4kZzp6HP66KmPKf+edcpCSecjzhfkFNIUeIPt7lpt+m8fMa5k zZuHb2qMC30eLas/ivysetIT9CyAFCHUOEv9Nmo5oxJVIsDP2UsH2FxmN M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0COBQAozCZV/5NdJa1TCYMIUlwFxhgKhgECgUY7EQEBAQEBAQF9hB8BAQEDAQEBAWsLBQcEAgEIEQQBASgHJwsUCQgCBA4FiCIIDc5QAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLK4QgERgIKwcCBIMRgRYFkQGGI4NogR2DN4JlhE2FEYNLIoF+gXFvgQQkHH8BAQE X-IronPort-AV: E=Sophos;i="5.11,551,1422921600"; d="scan'208";a="139812070" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-4.cisco.com with ESMTP; 09 Apr 2015 19:04:32 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t39J4Wou018905 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Apr 2015 19:04:32 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.184]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Thu, 9 Apr 2015 14:04:32 -0500 From: "Max Pritikin (pritikin)" To: "Hedanping (Ana)" Thread-Topic: [Anima] Ownership Concept Thread-Index: AQHQZn+Wm4eAxWuLS02QOiRijuPZe50siH6AgAErG4CAAORAgIAAqhaAgAAKs4CAAAlUAIAAbsyA///G6uSAA1+gAIACsoiAgAKxFICADBw9AIABC7AA Date: Thu, 9 Apr 2015 19:04:31 +0000 Message-ID: <93110A7A-4FD8-4D30-B833-5AC516B54BFB@cisco.com> References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> <5512DE41.6030209@gmail.com> <77FA386512F0D748BC7C02C36EB1106D956D45@szxeml557-mbs.china.huawei.com> <7912.1427385447@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D95700F@szxeml557-mbs.china.huawei.com> <1F85BE1D-44A3-420A-8852-A4BA0DE213AC@cisco.com> <247ADDB2-807D-4AB5-A814-58381A929EB5@cisco.com> <551BC405.3070204@gridmerge.com> <77FA386512F0D748BC7C02C36EB1106D95C712@szxeml557-mbs.china.huawei.com> In-Reply-To: <77FA386512F0D748BC7C02C36EB1106D95C712@szxeml557-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.34.137] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "robert.cragie@gridmerge.com" , "anima@ietf.org" , Michael Richardson Subject: Re: [Anima] Ownership Concept X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 19:04:38 -0000 On Apr 8, 2015, at 9:06 PM, Hedanping (Ana) wrot= e: > Hi Max, > Please see my comments inline. >=20 >> -----Original Message----- >> From: Robert Cragie [mailto:robert.cragie@gridmerge.com] >> Sent: Wednesday, April 01, 2015 6:10 PM >> To: Max Pritikin (pritikin) >> Cc: Hedanping (Ana); Michael Richardson; anima@ietf.org >> Subject: Re: [Anima] Ownership Concept >>=20 >> Hi Max, >>=20 >> Thanks for your responses. Further responses inline, bracketed by >> >>=20 >> For any given domain one could do this. But it doesn't work at scale or = if the >> target domain isn't known when the device leaves the vendor. >> All the more reason for the additional data needed at the beginnin= g of >> the sequence (Domain ID sent to NE) >=20 >=20 > Agree, my understanding from the draft is that 'Registrar is informed a p= riori the unique identifier (e.g. serial number)... =91, Noting that this is just a list of product serial numbers, such as from an = electronic bill-of-sale or read from packaging material using a bar code re= ader or whatever.=20 > the vendor should already know the domain/registrar before the device le= aves, and the registrar is informed of the device list. If that's the case,= why not pre-configure the device with the domain ID/ registrar ID or certi= ficates?=20 I agree with Brian that this is difficult with complex modern supply chains= . Tracking =93the device to domain association=94 requires the domain and v= endor to have a secure and authenticated channel but also your suggestion r= equires that this information is known before the device enters the supply = chain at all. As Brian points out this impacts any warehouse or resale mech= anism.=20 > Besides, if the NE is moved from one domain to another, necessary configu= ration should be done to the NE and corresponding registrars should be info= rmed, and the registrar must trust such configuration. Therefore MASA's log= information is not important to the registrar/the joining NE and may not b= e part of the bootstrapping messages. In order for domain_1 to do the "necessary configuration=94 it must be trus= ted by the NE, which means that the association was logged at the vendor=92= s MASA server. Lets assume that either the NE was wiped to factory defaults= OR that domain_1 installed malware - either of which could be used to (re)= trigger bootstrapping when the NE joins domain_2. During bootstrapping the = domain_2 registrar contacts the MASA server as per normal bootstrapping ope= rations. The log information is analyzed and if domain_1 was expected, perh= aps as a normal part of the vendor=92s potentially complex supply chain or = because domain_2 knew it was purchasing used equipment, then bootstrapping = proceeds as normal. On the other hand, if domain_2 normally never sees logs= with domain_1 in them then this triggers an exception and the domain_2 reg= istrar is afforded the opportunity to involve the administrator, apply addi= tional configuration validation, or whatever.=20 The vendor=92s responsibilities never are not effected. Although the vendor= has interesting information about how many times the NE has (re)trigger bo= otstrapping it doesn=92t necessarily even know the actual identity of domai= n_1 or domain_2.=20 - max >=20 > Ana >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Thu Apr 9 13:29:40 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2136B1B31F4 for ; Thu, 9 Apr 2015 13:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrkwZdFlthGB for ; Thu, 9 Apr 2015 13:29:36 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C85AB1A8BB0 for ; Thu, 9 Apr 2015 13:29:36 -0700 (PDT) Received: by pacyx8 with SMTP id yx8so160213546pac.1 for ; Thu, 09 Apr 2015 13:29:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=F6bihJYKOA8b5UQBWSvItTKZc/WhV1xJa3X3rnbk+h8=; b=p1o+rvqFXz4KGM1QlUPVb3pAwx52kYYdlCoz/ydqIPzrHJbmsnuSh0YcFxIfurHzbk Iq65CcsktzV6PU6cn/7lUj0uOFmj0zQooAPRnxUbR/gk6k/4bdJQJI1BN6cd5Njb7SQf SY5CGB5oGYH/81ty44wNHHUE7wG2+sIqqPD3cBBNGWihs63kCmUpAHKb+34TsKYw2uoj kKFxL8JTibKaMxfzovsOCHcdYz4qcMH7MuwaWfphzqL0Et/RR7mo/OVjr4iURm4Gy06b H8cKaxaNzU6IEV1WY+RY7nmUvR+53JSFClxVlmqE0/4vOa9J5gzwJGiYgasJgR1sX0od EUyw== X-Received: by 10.66.150.165 with SMTP id uj5mr59631579pab.54.1428611376522; Thu, 09 Apr 2015 13:29:36 -0700 (PDT) Received: from ?IPv6:2406:e007:65de:1:28cc:dc4c:9703:6781? ([2406:e007:65de:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id n5sm15457031pdh.27.2015.04.09.13.29.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2015 13:29:35 -0700 (PDT) Message-ID: <5526E134.7060208@gmail.com> Date: Fri, 10 Apr 2015 08:29:40 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Max Pritikin (pritikin)" , "Hedanping (Ana)" References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> <5512DE41.6030209@gmail.com> <77FA386512F0D748BC7C02C36EB1106D956D45@szxeml557-mbs.china.huawei.com> <7912.1427385447@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D95700F@szxeml557-mbs.china.huawei.com> <1F85BE1D-44A3-420A-8852-A4BA0DE213AC@cisco.com> <247ADDB2-807D-4AB5-A814-58381A929EB5@cisco.com> <551BC405.3070204@gridmerge.com> <77FA386512F0D748BC7C02C36EB1106D95C712@szxeml557-mbs.china.huawei.com> <93110A7A-4FD8-4D30-B833-5AC516B54BFB@cisco.com> In-Reply-To: <93110A7A-4FD8-4D30-B833-5AC516B54BFB@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "robert.cragie@gridmerge.com" , "anima@ietf.org" , Michael Richardson Subject: Re: [Anima] Ownership Concept X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 20:29:39 -0000 Just one extra point below to make myself a bit clearer: On 10/04/2015 07:04, Max Pritikin (pritikin) wrote: >=20 > On Apr 8, 2015, at 9:06 PM, Hedanping (Ana) = wrote: >=20 >> Hi Max, >> Please see my comments inline. >> >>> -----Original Message----- >>> From: Robert Cragie [mailto:robert.cragie@gridmerge.com] >>> Sent: Wednesday, April 01, 2015 6:10 PM >>> To: Max Pritikin (pritikin) >>> Cc: Hedanping (Ana); Michael Richardson; anima@ietf.org >>> Subject: Re: [Anima] Ownership Concept >>> >>> Hi Max, >>> >>> Thanks for your responses. Further responses inline, bracketed by >>> >>> >>> For any given domain one could do this. But it doesn't work at scale = or if the >>> target domain isn't known when the device leaves the vendor. >>> All the more reason for the additional data needed at the begin= ning of >>> the sequence (Domain ID sent to NE) >> >> >> Agree, my understanding from the draft is that 'Registrar is informed = a priori the unique identifier (e.g. serial number)... =E2=80=98, >=20 > Noting that this is just a list of product serial numbers, such as from= an electronic bill-of-sale or read from packaging material using a bar c= ode reader or whatever.=20 >=20 >> the vendor should already know the domain/registrar before the device= leaves, and the registrar is informed of the device list. If that's the = case, why not pre-configure the device with the domain ID/ registrar ID o= r certificates?=20 >=20 > I agree with Brian that this is difficult with complex modern supply ch= ains. Tracking =E2=80=9Cthe device to domain association=E2=80=9D require= s the domain and vendor to have a secure and authenticated channel but al= so your suggestion requires that this information is known before the dev= ice enters the supply chain at all. As Brian points out this impacts any = warehouse or resale mechanism.=20 Right. But I would like to be clear that I don't regard a MASA as the onl= y solution to this problem. Another solution is some kind of check-in procedure: when a device is purchased by a network operator*, they perfor= m an in-house procedure that does a factory reset for safety, then generate= s a new key pair inside the device, and then securely registers the new pub= lic key and the device identity. That means that the manufacturer, the supply= chain, and the MASA all disappear from the trust model. * "operator" could include a home user, with a simple registration process in the Bluetooth style. Brian >=20 >> Besides, if the NE is moved from one domain to another, necessary conf= iguration should be done to the NE and corresponding registrars should be= informed, and the registrar must trust such configuration. Therefore MAS= A's log information is not important to the registrar/the joining NE and = may not be part of the bootstrapping messages. >=20 > In order for domain_1 to do the "necessary configuration=E2=80=9D it mu= st be trusted by the NE, which means that the association was logged at t= he vendor=E2=80=99s MASA server. Lets assume that either the NE was wiped= to factory defaults OR that domain_1 installed malware - either of which= could be used to (re)trigger bootstrapping when the NE joins domain_2. D= uring bootstrapping the domain_2 registrar contacts the MASA server as pe= r normal bootstrapping operations. The log information is analyzed and if= domain_1 was expected, perhaps as a normal part of the vendor=E2=80=99s = potentially complex supply chain or because domain_2 knew it was purchasi= ng used equipment, then bootstrapping proceeds as normal. On the other ha= nd, if domain_2 normally never sees logs with domain_1 in them then this = triggers an exception and the domain_2 registrar is afforded the opportun= ity to involve the administrator, apply additional configuration validati= on, or whatever.=20 >=20 > The vendor=E2=80=99s responsibilities never are not effected. Although = the vendor has interesting information about how many times the NE has (r= e)trigger bootstrapping it doesn=E2=80=99t necessarily even know the actu= al identity of domain_1 or domain_2.=20 >=20 > - max >=20 >=20 >> >> Ana >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 From nobody Thu Apr 9 14:33:04 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE2F1B2AA8 for ; Thu, 9 Apr 2015 14:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYnXo_aI2x4M for ; Thu, 9 Apr 2015 14:33:01 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BB7D1B3364 for ; Thu, 9 Apr 2015 14:33:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5648; q=dns/txt; s=iport; t=1428615180; x=1429824780; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=RsFkwLaox3569PGwVgcYBa5+4+bNEK8aqkc5zwAtJd8=; b=JOMzUrwONVNy3PJ0ySbat0zsXMyz0A0IpYLfa8SZLSsEPLZZzB9qfueA oh14l28I4TD1E6CEUaWNtQ0aicNFwoZY7aORcU249wiKPAJ6oYeQru+yF QIi87eIZY+fI8L6xpeE8KavGAhgNknGSdWxj6RIwfCCbNK8w6GUUa5rfG Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CPBQBK7yZV/5pdJa1TCYMEUlwFxhgKhgECgUNMAQEBAQEBfoQfAQEBAwEBAQFrCwUHBAIBCBEEAQEBJwchBgsUCQgCBA4FG4d7AwkIDckFDYVNAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLK4JIgVgRGAgrBwIEgxGBFgWRAYYjghuBTYEdgzeCZYRNgieCaoNLIoF+gXFvAYEDJBx/AQEB X-IronPort-AV: E=Sophos;i="5.11,552,1422921600"; d="scan'208";a="410606323" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 09 Apr 2015 21:32:59 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t39LWxco019063 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Apr 2015 21:32:59 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.184]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Thu, 9 Apr 2015 16:32:58 -0500 From: "Max Pritikin (pritikin)" To: Brian E Carpenter Thread-Topic: [Anima] Ownership Concept Thread-Index: AQHQZn+Wm4eAxWuLS02QOiRijuPZe50siH6AgAErG4CAAORAgIAAqhaAgAAKs4CAAAlUAIAAbsyA///G6uSAA1+gAIACsoiAgAKxFICADBw9AIABC7AAgAAXzACAABGtAA== Date: Thu, 9 Apr 2015 21:32:57 +0000 Message-ID: <902591F8-C7D6-43E1-A954-9E9E85901CAF@cisco.com> References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> <5512DE41.6030209@gmail.com> <77FA386512F0D748BC7C02C36EB1106D956D45@szxeml557-mbs.china.huawei.com> <7912.1427385447@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D95700F@szxeml557-mbs.china.huawei.com> <1F85BE1D-44A3-420A-8852-A4BA0DE213AC@cisco.com> <247ADDB2-807D-4AB5-A814-58381A929EB5@cisco.com> <551BC405.3070204@gridmerge.com> <77FA386512F0D748BC7C02C36EB1106D95C712@szxeml557-mbs.china.huawei.com> <93110A7A-4FD8-4D30-B833-5AC516B54BFB@cisco.com> <5526E134.7060208@gmail.com> In-Reply-To: <5526E134.7060208@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.34.137] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "robert.cragie@gridmerge.com" , "Hedanping \(Ana\)" , "anima@ietf.org" , Michael Richardson Subject: Re: [Anima] Ownership Concept X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 21:33:03 -0000 On Apr 9, 2015, at 2:29 PM, Brian E Carpenter = wrote: > Just one extra point below to make myself a bit clearer: >=20 > On 10/04/2015 07:04, Max Pritikin (pritikin) wrote: >>=20 >> On Apr 8, 2015, at 9:06 PM, Hedanping (Ana) w= rote: >>=20 >>> Hi Max, >>> Please see my comments inline. >>>=20 >>>> -----Original Message----- >>>> From: Robert Cragie [mailto:robert.cragie@gridmerge.com] >>>> Sent: Wednesday, April 01, 2015 6:10 PM >>>> To: Max Pritikin (pritikin) >>>> Cc: Hedanping (Ana); Michael Richardson; anima@ietf.org >>>> Subject: Re: [Anima] Ownership Concept >>>>=20 >>>> Hi Max, >>>>=20 >>>> Thanks for your responses. Further responses inline, bracketed by >>>> >>>>=20 >>>> For any given domain one could do this. But it doesn't work at scale o= r if the >>>> target domain isn't known when the device leaves the vendor. >>>> All the more reason for the additional data needed at the beginn= ing of >>>> the sequence (Domain ID sent to NE) >>>=20 >>>=20 >>> Agree, my understanding from the draft is that 'Registrar is informed a= priori the unique identifier (e.g. serial number)... =91, >>=20 >> Noting that this is just a list of product serial numbers, such as from = an electronic bill-of-sale or read from packaging material using a bar code= reader or whatever.=20 >>=20 >>> the vendor should already know the domain/registrar before the device l= eaves, and the registrar is informed of the device list. If that's the case= , why not pre-configure the device with the domain ID/ registrar ID or cert= ificates?=20 >>=20 >> I agree with Brian that this is difficult with complex modern supply cha= ins. Tracking =93the device to domain association=94 requires the domain an= d vendor to have a secure and authenticated channel but also your suggestio= n requires that this information is known before the device enters the supp= ly chain at all. As Brian points out this impacts any warehouse or resale m= echanism.=20 >=20 > Right. But I would like to be clear that I don't regard a MASA as the onl= y > solution to this problem. My responses are in terms of the bootstrapping draft so I refer to MASA. Al= ternative cloud based mechanisms have differing tradeoffs as we=92ve been d= iscussing.=20 > Another solution is some kind of check-in > procedure: when a device is purchased by a network operator*, they perfor= m > an in-house procedure that does a factory reset for safety, then generate= s > a new key pair inside the device, and then securely registers the new pub= lic > key and the device identity. That means that the manufacturer, the supply > chain, and the MASA all disappear from the trust model. I agree that =93touch based=94 models also exist.=20 The difficulty is of course proving physical possession. Bluetooth and simi= lar models usually fall back on =93unauthenticated=94 connections when nece= ssary input/output functionality aren=92t available on the devices. I tend = to discount these due to the security characteristics but appreciate your k= eeping them part of the conversation.=20 > * "operator" could include a home user, with a simple registration > process in the Bluetooth style. My thinking on this is that we want to enable that same user to have a simi= lar user experience but *also* provide the more discerning and security awa= re administrator the ability to implement a better security model without f= orcing them to chose different pieces of hardware or run different software= paths. - max >=20 > Brian >=20 >>=20 >>> Besides, if the NE is moved from one domain to another, necessary confi= guration should be done to the NE and corresponding registrars should be in= formed, and the registrar must trust such configuration. Therefore MASA's l= og information is not important to the registrar/the joining NE and may not= be part of the bootstrapping messages. >>=20 >> In order for domain_1 to do the "necessary configuration=94 it must be t= rusted by the NE, which means that the association was logged at the vendor= =92s MASA server. Lets assume that either the NE was wiped to factory defau= lts OR that domain_1 installed malware - either of which could be used to (= re)trigger bootstrapping when the NE joins domain_2. During bootstrapping t= he domain_2 registrar contacts the MASA server as per normal bootstrapping = operations. The log information is analyzed and if domain_1 was expected, p= erhaps as a normal part of the vendor=92s potentially complex supply chain = or because domain_2 knew it was purchasing used equipment, then bootstrappi= ng proceeds as normal. On the other hand, if domain_2 normally never sees l= ogs with domain_1 in them then this triggers an exception and the domain_2 = registrar is afforded the opportunity to involve the administrator, apply a= dditional configuration validation, or whatever.=20 >>=20 >> The vendor=92s responsibilities never are not effected. Although the ven= dor has interesting information about how many times the NE has (re)trigger= bootstrapping it doesn=92t necessarily even know the actual identity of do= main_1 or domain_2.=20 >>=20 >> - max >>=20 >>=20 >>>=20 >>> Ana >>>=20 >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima >>=20 >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima From nobody Thu Apr 9 14:57:11 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 245B91A8934 for ; Thu, 9 Apr 2015 14:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fo5X85dq-5UZ for ; Thu, 9 Apr 2015 14:57:07 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 301571B33AB for ; Thu, 9 Apr 2015 14:57:07 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 0479B203B1 for ; Thu, 9 Apr 2015 18:07:54 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 08F3663B76; Thu, 9 Apr 2015 17:57:05 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E52AE636B6 for ; Thu, 9 Apr 2015 17:57:05 -0400 (EDT) From: Michael Richardson To: "anima\@ietf.org" In-Reply-To: <5526E134.7060208@gmail.com> References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> <5512DE41.6030209@gmail.com> <77FA386512F0D748BC7C02C36EB1106D956D45@szxeml557-mbs.china.huawei.com> <7912.1427385447@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D95700F@szxeml557-mbs.china.huawei.com> <1F85BE1D-44A3-420A-8852-A4BA0DE213AC@cisco.com> <247ADDB2-807D-4AB5-A814-58381A929EB5@cisco.com> <551BC405.3070204@gridmerge.com> <77FA386512F0D748BC7C02C36EB1106D95C712@szxeml557-mbs.china.huawei.com> <93110A7A-4FD8-4D30-B833-5AC516B54BFB@cisco.com> <5526E134.7060208@gmail.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Anima] Ownership Concept X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 21:57:09 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Max wrote in response to a thread from Ana: >> I agree with Brian that this is difficult with complex modern supply >> chains. Tracking =E2=80=9Cthe device to domain association=E2=80=9D = requires the >> domain and vendor to have a secure and authenticated channel but also >> your suggestion requires that this information is known before the >> device enters the supply chain at all. As Brian points out this >> impacts any warehouse or resale mechanism. Brian E Carpenter wrote: > Right. But I would like to be clear that I don't regard a MASA as the > only solution to this problem. Another solution is some kind of > check-in procedure: when a device is purchased by a network operator*, > they perform an in-house procedure that does a factory reset for > safety, then generates a new key pair inside the device, and then > securely registers the new public key and the device identity. That > means that the manufacturer, the supply chain, and the MASA all > disappear from the trust model. Just for further clarity, 1) to whom do they register the new public key? 2) do they remove any other vendor key? (802.1AR offers both keeping the IDevID and adding a LDevID, and also the option to replace the IDevID) I believe with judicious use of things like QR codes on the packaging containing either symmetric authentication secrets, (or possibly even assymmetric private keys), that one can bypass a number of layers of unevolved supply chain. My proposal would be to start from the premise that the supply chain has evolved already, and figure out how we bootstrap in that situation, and then we add way to mitigate the unevenness of new technology. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVSb1sYCLcPvd0N1lAQLJ1Af+IdvQ3UjKNpSAnIP1YCeRYde2K9l2tUeW kjracllY0jjP04TMn7t1NFd6iKWaRX5o9h661XQwVLtyfZsFXtOXcuATVsjSUfyn QmAwAiEU6VOtpgfV8x/xTR59GWpu8J7p33DRtXfkQeCEyZpGZfTPUot3UKmnG5mj K0Hp/nlfi2VfWyftzith2dNI9bamu7oHVSc2r/IfYDzSPilaSsXXK2V+M+wrB6Gy drIkTibQOMjV/KfRaD04QxSrzmRglbVQf5Uv39g5ptO4yX3gt8ucjWANLZvD9UGA Lv491jXasBi8x1UsOFZvNJgJcy+YkoE1/sdHukYQ24NcS+G6jLozIg== =BUu4 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Apr 9 16:05:46 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA191B35D2 for ; Thu, 9 Apr 2015 16:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrYumtNNyySO for ; Thu, 9 Apr 2015 16:05:41 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4D191B35C3 for ; Thu, 9 Apr 2015 16:05:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2347; q=dns/txt; s=iport; t=1428620742; x=1429830342; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TBaZz56+vbg3+nbccKkEQQt5lwu0xNJxmAx0Pp+x19Q=; b=lwJg4TLfGFfZkDl8tRJE87B13XS7DTJKRb6aIMmSaAiqYe/rxakDYYij AyGfletlArMYw9nO5+SeNyhx9ElOARmuiEqSwM5d1k8fhfzMG+XPr6cN6 GqoVkl9WCaTgZHliLfpP0amBshQbRFFXeC2xIIK3ZM+0AMKz2SXCgP2V+ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CMBQC4BCdV/5FdJa1TCYMIUlwFxFKBSQqGAQKBRDkTAQEBAQEBAX2EHwEBAQMBAQEBawsQAgEIGC4hBgslAgQOBRuHewMJCA3JAQ2FTQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEiyuCSIFYKTMHgxeBFgWRAYg+gU0BgRyKaYIngmqDSyKDb28BgUN/AQEB X-IronPort-AV: E=Sophos;i="5.11,553,1422921600"; d="scan'208";a="139818815" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-1.cisco.com with ESMTP; 09 Apr 2015 23:05:41 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t39N5eq3032413 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Apr 2015 23:05:41 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.184]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Thu, 9 Apr 2015 18:05:40 -0500 From: "Max Pritikin (pritikin)" To: Michael Richardson Thread-Topic: [Anima] Ownership Concept Thread-Index: AQHQZn+Wm4eAxWuLS02QOiRijuPZe50siH6AgAErG4CAAORAgIAAqhaAgAAKs4CAAAlUAIAAbsyA///G6uSAA1+gAIACsoiAgAKxFICADBw9AIABC7AAgAAXzACAABhtgIAAEycA Date: Thu, 9 Apr 2015 23:05:39 +0000 Message-ID: References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> <5512DE41.6030209@gmail.com> <77FA386512F0D748BC7C02C36EB1106D956D45@szxeml557-mbs.china.huawei.com> <7912.1427385447@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D95700F@szxeml557-mbs.china.huawei.com> <1F85BE1D-44A3-420A-8852-A4BA0DE213AC@cisco.com> <247ADDB2-807D-4AB5-A814-58381A929EB5@cisco.com> <551BC405.3070204@gridmerge.com> <77FA386512F0D748BC7C02C36EB1106D95C712@szxeml557-mbs.china.huawei.com> <93110A7A-4FD8-4D30-B833-5AC516B54BFB@cisco.com> <5526E134.7060208@gmail.com> <21336.1428616625@sandelman.ca> In-Reply-To: <21336.1428616625@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.34.137] Content-Type: text/plain; charset="Windows-1252" Content-ID: <812390F2F0CBD74297B2661E99CC1F21@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "anima@ietf.org" Subject: Re: [Anima] Ownership Concept X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 23:05:43 -0000 On Apr 9, 2015, at 3:57 PM, Michael Richardson wrot= e: >=20 > Max wrote in response to a thread from Ana: >>> I agree with Brian that this is difficult with complex modern supply >>> chains. Tracking =93the device to domain association=94 requires the >>> domain and vendor to have a secure and authenticated channel but also >>> your suggestion requires that this information is known before the >>> device enters the supply chain at all. As Brian points out this >>> impacts any warehouse or resale mechanism. >=20 > Brian E Carpenter wrote: >> Right. But I would like to be clear that I don't regard a MASA as the >> only solution to this problem. Another solution is some kind of >> check-in procedure: when a device is purchased by a network operator*, >> they perform an in-house procedure that does a factory reset for >> safety, then generates a new key pair inside the device, and then >> securely registers the new public key and the device identity. That >> means that the manufacturer, the supply chain, and the MASA all >> disappear from the trust model. >=20 > Just for further clarity, > 1) to whom do they register the new public key? > 2) do they remove any other vendor key? > (802.1AR offers both keeping the IDevID and adding a LDevID, and also > the option to replace the IDevID) >=20 > I believe with judicious use of things like QR codes on the packaging > containing either symmetric authentication secrets, (or possibly even > assymmetric private keys), that one can bypass a number of layers of > unevolved supply chain. >=20 > My proposal would be to start from the premise that the supply chain has > evolved already, and figure out how we bootstrap in that situation, and t= hen > we add way to mitigate the unevenness of new technology. This is an excellent point. Being able to incrementally add functionality t= o an existing supply chain without having to upgrade the entire supply chai= n is an important consideration.=20 - max >=20 >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Thu Apr 9 16:51:06 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 295D61B378A for ; Thu, 9 Apr 2015 16:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSGlbV_Vksh7 for ; Thu, 9 Apr 2015 16:51:02 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87A381B3789 for ; Thu, 9 Apr 2015 16:51:02 -0700 (PDT) Received: by pdbqa5 with SMTP id qa5so3455977pdb.1 for ; Thu, 09 Apr 2015 16:51:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=mYs22eBeZ1mbv6y40fyf65Ynqqxn4b8P4cLvVrj//oA=; b=EwLEGZC2zouJ9/07UTsVuj99Kc8OdwsN+Qbvj4yit7PQswECCjbfnCQXRV22oSNe0L u2NyD1M8xx0nhqaSSH73ALCHq5fHHYLS2BYl2pMDrJtFtAg/VjfPs/LW5EfOGGuWnXjf ghpauonBIWtBuJzDKotCdZqZgR6t+J3Z69P6zrajiXfbqRbA2hXozG1DXbL8CD493UH5 Dcf5DOPGPp4x2D33hDOrBe5Z++dLK1iYp/02cP3aJ7CeYSQhzYw+MHtXakVuaYna95xZ 8v2SLjQJukd79zgK5rbMY+8R1nnqtTG35Xxd16z+KFzkD9xf4/1U+XRPVO7x1tinPkSR M6sQ== X-Received: by 10.70.90.162 with SMTP id bx2mr51015520pdb.60.1428623462249; Thu, 09 Apr 2015 16:51:02 -0700 (PDT) Received: from ?IPv6:2406:e007:65de:1:28cc:dc4c:9703:6781? ([2406:e007:65de:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id tg14sm162540pac.15.2015.04.09.16.50.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2015 16:51:01 -0700 (PDT) Message-ID: <5527106A.10106@gmail.com> Date: Fri, 10 Apr 2015 11:51:06 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Michael Richardson , "anima@ietf.org" References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> <5512DE41.6030209@gmail.com> <77FA386512F0D748BC7C02C36EB1106D956D45@szxeml557-mbs.china.huawei.com> <7912.1427385447@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D95700F@szxeml557-mbs.china.huawei.com> <1F85BE1D-44A3-420A-8852-A4BA0DE213AC@cisco.com> <247ADDB2-807D-4AB5-A814-58381A929EB5@cisco.com> <551BC405.3070204@gridmerge.com> <77FA386512F0D748BC7C02C36EB1106D95C712@szxeml557-mbs.china.huawei.com> <93110A7A-4FD8-4D30-B833-5AC516B54BFB@cisco.com> <5526E134.7060208@gmail.com> <21336.1428616625@sandelman.ca> In-Reply-To: <21336.1428616625@sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] Ownership Concept X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 23:51:04 -0000 On 10/04/2015 09:57, Michael Richardson wrote: >=20 > Max wrote in response to a thread from Ana: > >> I agree with Brian that this is difficult with complex modern su= pply > >> chains. Tracking =E2=80=9Cthe device to domain association=E2=80= =9D requires the > >> domain and vendor to have a secure and authenticated channel but= also > >> your suggestion requires that this information is known before t= he > >> device enters the supply chain at all. As Brian points out this > >> impacts any warehouse or resale mechanism. >=20 > Brian E Carpenter wrote: > > Right. But I would like to be clear that I don't regard a MASA as= the > > only solution to this problem. Another solution is some kind of > > check-in procedure: when a device is purchased by a network opera= tor*, > > they perform an in-house procedure that does a factory reset for > > safety, then generates a new key pair inside the device, and then= > > securely registers the new public key and the device identity. Th= at > > means that the manufacturer, the supply chain, and the MASA all > > disappear from the trust model. >=20 > Just for further clarity, > 1) to whom do they register the new public key? Their own CA, within their own network. Remember that our target market for Anima includes very large networks (carriers or large enterprises). But that isn't the whole market, of course. Smaller enterprises may be happier to farm out security functions to the cloud, although it will only take one well-publicised breach for that to become less popular. I think we have to design the base mechanisms to be very tolerant of multiple scenarios. > 2) do they remove any other vendor key? > (802.1AR offers both keeping the IDevID and adding a LDevID, and also > the option to replace the IDevID) Good question. At first sight I don't see a good reason to destroy existing keys. > I believe with judicious use of things like QR codes on the packaging > containing either symmetric authentication secrets, (or possibly even > assymmetric private keys), that one can bypass a number of layers of > unevolved supply chain. >=20 > My proposal would be to start from the premise that the supply chain ha= s > evolved already, and figure out how we bootstrap in that situation, and= then > we add way to mitigate the unevenness of new technology. I don't see coping with various scenarios as mitigation, but as a basic requirement. For one thing, even if the supply chain evolves in a certain= way, it will continue to evolve in the long term, and we want to avoid a legacy problem when that happens. Brian From nobody Fri Apr 10 08:55:23 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C40D1A1EF7 for ; Fri, 10 Apr 2015 08:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUSVJzFJQdJY for ; Fri, 10 Apr 2015 08:55:14 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33C6F1A6EDC for ; Fri, 10 Apr 2015 08:55:14 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 70F86203B0; Fri, 10 Apr 2015 12:06:03 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id C086063B76; Fri, 10 Apr 2015 11:55:12 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A90AD636B6; Fri, 10 Apr 2015 11:55:12 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter In-Reply-To: <5527106A.10106@gmail.com> References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> <5512DE41.6030209@gmail.com> <77FA386512F0D748BC7C02C36EB1106D956D45@szxeml557-mbs.china.huawei.com> <7912.1427385447@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D95700F@szxeml557-mbs.china.huawei.com> <1F85BE1D-44A3-420A-8852-A4BA0DE213AC@cisco.com> <247ADDB2-807D-4AB5-A814-58381A929EB5@cisco.com> <551BC405.3070204@gridmerge.com> <77FA386512F0D748BC7C02C36EB1106D95C712@szxeml557-mbs.china.huawei.com> <93110A7A-4FD8-4D30-B833-5AC516B54BFB@cisco.com> <5526E134.7060208@gmail.com> <21336.1428616625@sandelman.ca> <5527106A.10106@gmail.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Cc: "anima@ietf.org" Subject: Re: [Anima] Ownership Concept X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 15:55:21 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> would like to be clear that I don't regard a MASA as the > only >> solution to this problem. Another solution is some kind of > check-in >> procedure: when a device is purchased by a network operator*, > they >> perform an in-house procedure that does a factory reset for > safety, >> then generates a new key pair inside the device, and then > securely >> registers the new public key and the device identity. That > means >> that the manufacturer, the supply chain, and the MASA all > disappear >> from the trust model. >> Just for further clarity, 1) to whom do they register the new public >> key? > Their own CA, within their own network. Remember that our target market > for Anima includes very large networks (carriers or large enterprises). > But that isn't the whole market, of course. Smaller enterprises may be > happier to farm out security functions to the cloud, although it will > only take one well-publicised breach for that to become less popular. I don't mean to be obtuse, but do I understand the process you are describing to be: 1) the network operator unboxes the system in a lab/provisioning center (It sure sounds like a serial console. I have learnt recently, this is called the "craft terminal" in telco speak. On small devices, this cable might speak USB or JTAG...) 2) the network generates the new key, and enrolls it, I guess doing a copy and past on the craft terminal of the certificate request. 3) the network operator boxes the system backup and ships it to where it needs to go. (which might be a warehouse, where it will wait as a spare part) >> 2) do they remove any other vendor key? (802.1AR offers both keeping >> the IDevID and adding a LDevID, and also the option to replace the >> IDevID) > Good question. At first sight I don't see a good reason to destroy > existing keys. If you leave the original IDevID there, and it is possible to reset the device into a state where it will use that ID, then it is possible that the original vendor can now "steal" the device back by issuing a new ownership token. >> My proposal would be to start from the premise that the supply chain >> has evolved already, and figure out how we bootstrap in that >> situation, and then we add way to mitigate the unevenness of new >> technology. > I don't see coping with various scenarios as mitigation, but as a basic > requirement. For one thing, even if the supply chain evolves in a > certain way, it will continue to evolve in the long term, and we want > to avoid a legacy problem when that happens. Okay, if you don't like the word "mitigation", I'm okay with that. My intention is that we create an endgame scenario and then we add some transition strategies that can disappear later on. (I realize how poorly this has gone with IPv6, so let's not go down that rathole, unless you fundamentally disagree with this strategy) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVSfyYICLcPvd0N1lAQLNVwf/fVw6B9d+Mp6Xq6qSjkyBsMR9p/2s6Ntk qCPKLLnz2Ia0/Rmr2AlvhlmJ/zQSF+fgz4j/jtca0y9iq0B8EtEcTkX2ygu9Sx9H r9bJJdXFPXp2uHip6QFhxTVq9icxt4pp4455qso61MY5mhINClzxnvXChWjYweyA EygwD58gzjySIWvlDzHn4t8IsV0C/DGs9Z+rT+xrocknxF0jF0bMSglVKK25rr9K eTFg3PLs50x6R0f2Rh3F0sUXZbV/jKWxQ8Rj/nLher2L80OVAxafuANKtehc5MaQ z5qhwL9RbAraQSm6UBo9pB+2q7acA4ZI4jfBQtZrbAfYvk3zydBtGg== =bfpc -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Apr 10 09:26:15 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B011AC41D for ; Fri, 10 Apr 2015 09:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wzgzMd_ZDUNt for ; Fri, 10 Apr 2015 09:26:07 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EBBE1A92B3 for ; Fri, 10 Apr 2015 09:26:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5739; q=dns/txt; s=iport; t=1428683167; x=1429892767; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=PFfc3P2qPbUyzXjTu7602MsxFYFIKLIiO/H+ATbDuXE=; b=eDQ3RKQylUb1rEJbtCVMfymscUWrSpRg6Yjsy78RsRHx8ktXpl7/Mz92 t1snW3rVGN6b/bEkl1mHQZdOOEYwCoVkAAcH4uYiaOlKv4YJUoC+AkJdr Ha4Xr2mDRddUIxphfvvMYhqJuHhUzHpA9kKImrFZ/NtWMf9wRRv4vhHRm Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AZBQCB+CdV/4UNJK1TCYMMUlwFxGaBRAqGAQKBPjoSAQEBAQEBAX2EHwEBAQMBAQEBZAcGBQULAgEIGC4hBgslAgQOBRuHewMJCA3JQw2FTgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEiyuCSIFIECkzB4MXgRYFkQOIP4FNgR2DN4c0gieCaoNMIoNvbwGBQ38BAQE X-IronPort-AV: E=Sophos;i="5.11,557,1422921600"; d="scan'208";a="140078989" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-3.cisco.com with ESMTP; 10 Apr 2015 16:26:06 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t3AGQ6wW025205 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Apr 2015 16:26:06 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.184]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Fri, 10 Apr 2015 11:26:06 -0500 From: "Max Pritikin (pritikin)" To: Michael Richardson Thread-Topic: [Anima] Ownership Concept Thread-Index: AQHQZn+Wm4eAxWuLS02QOiRijuPZe50siH6AgAErG4CAAORAgIAAqhaAgAAKs4CAAAlUAIAAbsyA///G6uSAA1+gAIACsoiAgAKxFICADBw9AIABC7AAgAAXzACAABhtgIAAH9sAgAENXQCAAAikgA== Date: Fri, 10 Apr 2015 16:26:05 +0000 Message-ID: References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> <5512DE41.6030209@gmail.com> <77FA386512F0D748BC7C02C36EB1106D956D45@szxeml557-mbs.china.huawei.com> <7912.1427385447@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D95700F@szxeml557-mbs.china.huawei.com> <1F85BE1D-44A3-420A-8852-A4BA0DE213AC@cisco.com> <247ADDB2-807D-4AB5-A814-58381A929EB5@cisco.com> <551BC405.3070204@gridmerge.com> <77FA386512F0D748BC7C02C36EB1106D95C712@szxeml557-mbs.china.huawei.com> <93110A7A-4FD8-4D30-B833-5AC516B54BFB@cisco.com> <5526E134.7060208@gmail.com> <21336.1428616625@sandelman.ca> <5527106A.10106@gmail.com> <15763.1428681312@sandelman.ca> In-Reply-To: <15763.1428681312@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.147.227] Content-Type: text/plain; charset="Windows-1252" Content-ID: <1F8D193C09E5CF478A6EC31159CBFC82@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "anima@ietf.org" Subject: Re: [Anima] Ownership Concept X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 16:26:09 -0000 Michael, some questions for you inline so I can better understand the issue= s you=92re thinking about,=20 On Apr 10, 2015, at 9:55 AM, Michael Richardson wro= te: >=20 > Brian E Carpenter wrote: >>> would like to be clear that I don't regard a MASA as the > only >>> solution to this problem. Another solution is some kind of > check-in >>> procedure: when a device is purchased by a network operator*, > they >>> perform an in-house procedure that does a factory reset for > safety, >>> then generates a new key pair inside the device, and then > securely >>> registers the new public key and the device identity. That > means >>> that the manufacturer, the supply chain, and the MASA all > disappear >>> from the trust model. >=20 >>> Just for further clarity, 1) to whom do they register the new public >>> key? >=20 >> Their own CA, within their own network. Remember that our target market >> for Anima includes very large networks (carriers or large enterprises). >> But that isn't the whole market, of course. Smaller enterprises may be >> happier to farm out security functions to the cloud, although it will >> only take one well-publicised breach for that to become less popular. >=20 > I don't mean to be obtuse, but do I understand the process you are descri= bing > to be: > 1) the network operator unboxes the system in a lab/provisioning center > (It sure sounds like a serial console. I have learnt recently, this i= s > called the "craft terminal" in telco speak. On small devices, this > cable might speak USB or JTAG=85) This describes a relatively high touch scenario where the device is staged = and supports the so called =93craft terminal=94 as an out-of-band managemen= t channel. This incurs additional operational (staging) and capital (extra = interfaces) expenses so I tend to think in terms of non-staging and inline = solutions (aka =93zero touch=94 etc). Do you have a sense that the model yo= u=92re describing here will become more widespread? =20 > 2) the network generates the new key, and enrolls it, I guess doing a > copy and past on the craft terminal of the certificate request. Even if we assume a =93craft terminal=94 that is physically secured do you = think it is a good idea to have the network generate the key =97 or do you = see value in the more classic asymmetric key approach where the device gene= rates the key itself if possible? > 3) the network operator boxes the system backup and ships it to where it > needs to go. (which might be a warehouse, where it will wait as a spa= re part) Do you imagine that the credentials installed in 1-2 are the final credenti= als for the device? Or do you think it might have more generic credentials = while it sits in the warehouse and be issued its final credentials after it= is deployed?=20 Do you see value in the device manufacturer providing steps 1-2 during manu= facturing thus saving the final customer the costs and complexities of thes= e steps?=20 >=20 >>> 2) do they remove any other vendor key? (802.1AR offers both keeping >>> the IDevID and adding a LDevID, and also the option to replace the >>> IDevID) >=20 >> Good question. At first sight I don't see a good reason to destroy >> existing keys. >=20 > If you leave the original IDevID there, and it is possible to reset the > device into a state where it will use that ID, then it is possible that t= he > original vendor can now "steal" the device back by issuing a new ownershi= p > token. Please keep in mind here that the IDevID credential is the devices identity= . The concern you are raising is around the device having a Trust Anchor of= the vendor. Verification of a provisioning "authorization token=94 is one = way this Trust Anchor might be used. Another way it is often used is verifi= cation of code updates from the vendor. Are you proposing that the new owne= r of the device be capable of removing this Trust Anchor? If so how do they= perform secure software updates? If the IDevID credential is permanently removed then the device=92s behavio= r has been permanently changed. If the IDevID credential is *only* used for= authenticating the device during an initial provisioning/bootstrap then re= moving it means the device can never be provisioned again w/o depending on = the =93craft terminal=94 concepts above. What does one do to secure (re)pro= visioning of a wireless only device in your model?=20 Thanks, - max >>> My proposal would be to start from the premise that the supply chain >>> has evolved already, and figure out how we bootstrap in that >>> situation, and then we add way to mitigate the unevenness of new >>> technology. >=20 >> I don't see coping with various scenarios as mitigation, but as a basic >> requirement. For one thing, even if the supply chain evolves in a >> certain way, it will continue to evolve in the long term, and we want >> to avoid a legacy problem when that happens. >=20 > Okay, if you don't like the word "mitigation", I'm okay with that. > My intention is that we create an endgame scenario and then we add some > transition strategies that can disappear later on. (I realize how poorly > this has gone with IPv6, so let's not go down that rathole, unless you > fundamentally disagree with this strategy) >=20 >=20 >=20 >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Fri Apr 10 12:12:50 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A94151A8853 for ; Fri, 10 Apr 2015 12:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEvbrqg5kpyV for ; Fri, 10 Apr 2015 12:12:48 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ED831A8850 for ; Fri, 10 Apr 2015 12:12:48 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 65369203AA for ; Fri, 10 Apr 2015 15:23:38 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 539EB63B76; Fri, 10 Apr 2015 15:12:47 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 389EE636B6 for ; Fri, 10 Apr 2015 15:12:47 -0400 (EDT) From: Michael Richardson To: "anima\@ietf.org" In-Reply-To: References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> <5512DE41.6030209@gmail.com> <77FA386512F0D748BC7C02C36EB1106D956D45@szxeml557-mbs.china.huawei.com> <7912.1427385447@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D95700F@szxeml557-mbs.china.huawei.com> <1F85BE1D-44A3-420A-8852-A4BA0DE213AC@cisco.com> <247ADDB2-807D-4AB5-A814-58381A929EB5@cisco.com> <551BC405.3070204@gridmerge.com> <77FA386512F0D748BC7C02C36EB1106D95C712@szxeml557-mbs.china.huawei.com> <93110A7A-4FD8-4D30-B833-5AC516B54BFB@cisco.com> <5526E134.7060208@gmail.com> <21336.1428616625@sandelman.ca> <5527106A.10106@gmail.com> <15763.1428681312@sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Anima] Ownership Concept X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 19:12:49 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Max Pritikin (pritikin) wrote: max> Michael, some questions for you inline so I can better understand max> the issues you=E2=80=99re thinking about, good. >>>> Just for further clarity, 1) to whom do they register the new publ= ic >>>> key? >> >>> Their own CA, within their own network. Remember that our target ma= rket >>> for Anima includes very large networks (carriers or large enterpris= es). >>> But that isn't the whole market, of course. Smaller enterprises may= be >>> happier to farm out security functions to the cloud, although it wi= ll >>> only take one well-publicised breach for that to become less popula= r. >> >> I don't mean to be obtuse, but do I understand the process you are d= escribing >> to be: >> 1) the network operator unboxes the system in a lab/provisioning cen= ter >> (It sure sounds like a serial console. I have learnt recently, this = is >> called the "craft terminal" in telco speak. On small devices, this >> cable might speak USB or JTAG=E2=80=A6) max> This describes a relatively high touch scenario where the device is max> staged and supports the so called =E2=80=9Ccraft terminal=E2=80=9D= as an out-of-band max> management channel. This incurs additional operational (staging) a= nd max> capital (extra interfaces) expenses so I tend to think in terms of max> non-staging and inline solutions (aka =E2=80=9Czero touch=E2=80=9D= etc). Do you have max> a sense that the model you=E2=80=99re describing here will become = more max> widespread? Max, just to be clear, I'm not advocating this "high touch" scenario, I'm just trying to understand if this is what Brian is suggesting before I make any judgement of any kind. >> 2) the network generates the new key, and enrolls it, I guess doing a >> copy and past on the craft terminal of the certificate request. max> Even if we assume a =E2=80=9Ccraft terminal=E2=80=9D that is physi= cally secured do max> you think it is a good idea to have the network generate the key = =E2=80=94 max> or do you see value in the more classic asymmetric key approach max> where the device generates the key itself if possible? I think that the machine should generate it's own key, and key it secure internally. Many hardware modules do not support exporting their private key... The CSR consists of public info only (essentially a self-signed copy of the public key, plus desired attributes). The copy and paste of a certificate request (CSR) is therefore of public information, but it must handled carefully as it can be substituted along the way. >> 3) the network operator boxes the system backup and ships it to wher= e it >> needs to go. (which might be a warehouse, where it will wait as a sp= are part) max> Do you imagine that the credentials installed in 1-2 are the final max> credentials for the device? Or do you think it might have more max> generic credentials while it sits in the warehouse and be issued i= ts max> final credentials after it is deployed? When steps 1/2 are done "inhouse", then I think that both scenarios are possible and likely. So for instance, I would expect all military-like organizations (probably including rescue and humanitarian entities) to have= a staging situation. They simply can't assume there is any "online" where th= ey are going to do enrollment with. max> Do you see value in the device manufacturer providing steps 1-2 max> during manufacturing thus saving the final customer the costs and max> complexities of these steps? okay, so I'll finally bite: listed steps 1/2 are what we do now, and they suck. They are secure only because of the craft terminal, and devices too small for such an interface, or operators too simple to have an RS232 on their laptop can not play. The "0000" and "1111" as the univeral BT headset code are shameful... [my god, the headset could *speak* it's code to you :-)] Yes, I want steps 1/2 done during manufacturing, but we need to bridge the ownership gap to be bridged. I hope Brian will answer my original email, because I'm sure that he didn't want to re-invent the craft terminal. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVSggroCLcPvd0N1lAQI6pggAhGc9k7XBd2PHvHbIed3u5n6CWP+9tbk4 GICV6KrHJikDEbdFDyVGiHaFhlbhtCeSbe6YxbxOI3IrIBBiobZB1JT90ZChG8KF tSpqhYA0tuBXSwGABXzXjXOuM7KRkm6iJENjtyVVJ6ySOuvydYE2YoMtki+wfAxB JSNb0+7vQmmov4k93UOXtYeB+daAsWujx7ABIgFjXtCjxJNmx/x+vEd2UFzJBa2u NcEWNbqAKmhBhYpAio3HEhp+f7R++lMabv78x5iJOzdpgXSHJCoAP0/9hdIAF1Gz U4DBI11/M7fn/SDTcHBKsaI3cwYoWv0Ey5tfCm37MVebzCC+VSF8KQ== =Ni35 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Apr 10 13:12:16 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF621A87D7 for ; Fri, 10 Apr 2015 13:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UqOoaxBfcT6 for ; Fri, 10 Apr 2015 13:12:12 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6E811A87D5 for ; Fri, 10 Apr 2015 13:12:12 -0700 (PDT) Received: by pacyx8 with SMTP id yx8so31502973pac.1 for ; Fri, 10 Apr 2015 13:12:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=xGkX37HO2jbQNcWCt1J+EXeoNt5lBBx01NGBxTBafYU=; b=MIMRTmNAMPC6VPPYmrI1pSYfUIa/r5eruoX8PGRxPDCIa5h1ot13buYiUsfPqnVdQx fvb0TztnjWhesXA30aeI865SBhGPJIOU86tWh3it4zFB4inv13Ybfmp45MkKbMh9Zagy qn9qLSOLIYo0THLG/oZFYwbffAy2IY3Lw6FJH9zxpb+dHsN9pH81d9E2/Qg/rAHWdNbI ZEpGWw7vja+rF+P3TgPjf+U1gn7Bsfw5z/pVXgRiTOzqUL1Rg1yRAb7LfJ1/8PlvfUlL n+61Jbt/xKfnYsMWUIvchnldH0ZLpqlzYTaI0ZMe9jd51LHbiz/zQbGHrQO5GuhLBfe4 DiyA== X-Received: by 10.68.223.165 with SMTP id qv5mr5628145pbc.82.1428696732381; Fri, 10 Apr 2015 13:12:12 -0700 (PDT) Received: from ?IPv6:2406:e007:7e03:1:28cc:dc4c:9703:6781? ([2406:e007:7e03:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id u8sm3114737pdj.46.2015.04.10.13.12.09 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Apr 2015 13:12:11 -0700 (PDT) Message-ID: <55282EA2.6070409@gmail.com> Date: Sat, 11 Apr 2015 08:12:18 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Michael Richardson , "anima@ietf.org" References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> <5512DE41.6030209@gmail.com> <77FA386512F0D748BC7C02C36EB1106D956D45@szxeml557-mbs.china.huawei.com> <7912.1427385447@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D95700F@szxeml557-mbs.china.huawei.com> <1F85BE1D-44A3-420A-8852-A4BA0DE213AC@cisco.com> <247ADDB2-807D-4AB5-A814-58381A929EB5@cisco.com> <551BC405.3070204@gridmerge.com> <77FA386512F0D748BC7C02C36EB1106D95C712@szxeml557-mbs.china.huawei.com> <93110A7A-4FD8-4D30-B833-5AC516B54BFB@cisco.com> <5526E134.7060208@gmail.com> <21336.1428616625@sandelman.ca> <5527106A.10106@gmail.com> <15763.1428681312@sandelman.ca> <24238.1428693167@sandelman.ca> In-Reply-To: <24238.1428693167@sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] Ownership Concept X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 20:12:14 -0000 Good morning (NZ time). Some responses in line. On 11/04/2015 07:12, Michael Richardson wrote: >=20 > Max Pritikin (pritikin) wrote: >=20 > max> Michael, some questions for you inline so I can better underst= and > max> the issues you=E2=80=99re thinking about, >=20 > good. >=20 > >>>> Just for further clarity, 1) to whom do they register the new = public > >>>> key? > >> > >>> Their own CA, within their own network. Remember that our targe= t market > >>> for Anima includes very large networks (carriers or large enter= prises). > >>> But that isn't the whole market, of course. Smaller enterprises= may be > >>> happier to farm out security functions to the cloud, although i= t will > >>> only take one well-publicised breach for that to become less po= pular. > >> > >> I don't mean to be obtuse, but do I understand the process you a= re describing > >> to be: > >> 1) the network operator unboxes the system in a lab/provisioning= center > >> (It sure sounds like a serial console. I have learnt recently, t= his is > >> called the "craft terminal" in telco speak. On small devices, t= his > >> cable might speak USB or JTAG=E2=80=A6) >=20 > max> This describes a relatively high touch scenario where the devi= ce is > max> staged and supports the so called =E2=80=9Ccraft terminal=E2=80= =9D as an out-of-band > max> management channel. This incurs additional operational (stagin= g) and > max> capital (extra interfaces) expenses so I tend to think in term= s of > max> non-staging and inline solutions (aka =E2=80=9Czero touch=E2=80= =9D etc). Do you have > max> a sense that the model you=E2=80=99re describing here will bec= ome more > max> widespread? >=20 > Max, just to be clear, I'm not advocating this "high touch" scenario, I= 'm > just trying to understand if this is what Brian is suggesting before I = make > any judgement of any kind. Yes, I believe that there will be operators who want to do it this way. I can imagine incumbent telcos doing so, just because that's the way they= work. I can certainly imagine military or other high security operators doing so, because they are simply unwilling to trust anybody else. I'm not advocating this approach; I just believe that some fraction of the market will want to keep the entire process 100% in-house, with no MASA and no call-home. > >> 2) the network generates the new key, and enrolls it, I guess do= ing a > >> copy and past on the craft terminal of the certificate request. >=20 > max> Even if we assume a =E2=80=9Ccraft terminal=E2=80=9D that is p= hysically secured do > max> you think it is a good idea to have the network generate the k= ey =E2=80=94 > max> or do you see value in the more classic asymmetric key approac= h > max> where the device generates the key itself if possible? >=20 > I think that the machine should generate it's own key, and key it secur= e > internally. Many hardware modules do not support exporting their priva= te > key... =20 Oh. I'm missing something then; how does the rest of the domain learn the public key? > The CSR consists of public info only (essentially a self-signed copy > of the public key, plus desired attributes). The copy and paste of a > certificate request (CSR) is therefore of public information, but it mu= st > handled carefully as it can be substituted along the way. >=20 > >> 3) the network operator boxes the system backup and ships it to = where it > >> needs to go. (which might be a warehouse, where it will wait as = a spare part) >=20 > max> Do you imagine that the credentials installed in 1-2 are the f= inal > max> credentials for the device? Or do you think it might have more= > max> generic credentials while it sits in the warehouse and be issu= ed its > max> final credentials after it is deployed? >=20 > When steps 1/2 are done "inhouse", then I think that both scenarios are= > possible and likely. So for instance, I would expect all military-like= > organizations (probably including rescue and humanitarian entities) to = have a > staging situation. They simply can't assume there is any "online" wher= e they > are going to do enrollment with. Exactly my point. Military installations, nuclear power stations, the access control system for highly secure buildings,... >=20 > max> Do you see value in the device manufacturer providing steps 1-= 2 > max> during manufacturing thus saving the final customer the costs = and > max> complexities of these steps? >=20 > okay, so I'll finally bite: listed steps 1/2 are what we do now, and th= ey > suck. They are secure only because of the craft terminal, and devices > too small for such an interface, or operators too simple to have an RS2= 32 on > their laptop can not play. >=20 > The "0000" and "1111" as the univeral BT headset code are shameful... [= my > god, the headset could *speak* it's code to you :-)] >=20 > Yes, I want steps 1/2 done during manufacturing, but we need to bridge = the > ownership gap to be bridged. >=20 > I hope Brian will answer my original email, because I'm sure that he di= dn't > want to re-invent the craft terminal. Not specially. My whole point is that Anima infrastructure needs to be ro= bust against a whole variety of scenarios, regardless of what we think is the best scenario. Brian From nobody Fri Apr 10 13:40:34 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACCE1A88E4 for ; Fri, 10 Apr 2015 13:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itYYUGOpjUbX for ; Fri, 10 Apr 2015 13:40:31 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED0321A88DB for ; Fri, 10 Apr 2015 13:40:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7568; q=dns/txt; s=iport; t=1428698431; x=1429908031; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=DcQYEGCSSqFmnHzOYI8zcSkq2uNdjbgmzQH/rnr19H8=; b=RLN9DHSMoDQ7BOX/oaZhbjddlsO1t0bi7sJ/RF5YCp0cDC5g8FxyRPgz zYtL1StdPaMCH2vzDVEs6WdX9lkH7aX+6v/IkKVEtuK18AS3tYCe3FTYT j2NXX4fKaMw/Anyl5FNcva+vRYSwu5tfqCqJHUISas6wIW+10mkJvABoR Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AOBQBFNChV/5JdJa1cgwxSXAXGKgqGAQKBRDwQAQEBAQEBAX2EHwEBAQMBAQEBZAcGBQULAgEIGC4hBgslAgQOBRuHewMJCA3JNA2FUAEBAQEBAQEBAQEBAQEBAQEBAQEBFASKLH+CSIFICREBAhwzB4MXgRYFkQOIQIFNji+GNiKDb28BgQo5fwEBAQ X-IronPort-AV: E=Sophos;i="5.11,558,1422921600"; d="scan'208";a="140128630" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-1.cisco.com with ESMTP; 10 Apr 2015 20:40:29 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t3AKeTsl000556 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Apr 2015 20:40:29 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.184]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Fri, 10 Apr 2015 15:40:29 -0500 From: "Max Pritikin (pritikin)" To: Brian E Carpenter Thread-Topic: [Anima] Ownership Concept Thread-Index: AQHQZn+Wm4eAxWuLS02QOiRijuPZe50siH6AgAErG4CAAORAgIAAqhaAgAAKs4CAAAlUAIAAbsyA///G6uSAA1+gAIACsoiAgAKxFICADBw9AIABC7AAgAAXzACAABhtgIAAH9sAgAENXQCAAAikgIAALpGAgAAQoQCAAAfigA== Date: Fri, 10 Apr 2015 20:40:28 +0000 Message-ID: <4D76E559-9E91-434C-8B2D-CAFDE3EFB1B4@cisco.com> References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> <5512DE41.6030209@gmail.com> <77FA386512F0D748BC7C02C36EB1106D956D45@szxeml557-mbs.china.huawei.com> <7912.1427385447@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D95700F@szxeml557-mbs.china.huawei.com> <1F85BE1D-44A3-420A-8852-A4BA0DE213AC@cisco.com> <247ADDB2-807D-4AB5-A814-58381A929EB5@cisco.com> <551BC405.3070204@gridmerge.com> <77FA386512F0D748BC7C02C36EB1106D95C712@szxeml557-mbs.china.huawei.com> <93110A7A-4FD8-4D30-B833-5AC516B54BFB@cisco.com> <5526E134.7060208@gmail.com> <21336.1428616625@sandelman.ca> <5527106A.10106@gmail.com> <15763.1428681312@sandelman.ca> <24238.1428693167@sandelman.ca> <55282EA2.6070409@gmail.com> In-Reply-To: <55282EA2.6070409@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.147.227] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Michael Richardson , "anima@ietf.org" Subject: Re: [Anima] Ownership Concept X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 20:40:33 -0000 It is always morning somewhere!=20 I personally disagree with the assertion that somebody with physical posses= sion of the device in factory default state should be able to =93take owner= ship=94 of the device without engaging with the vendor/cloud service. I und= erstand that there is a long history of this model and folks are reluctant = to give it up =97 so I expect that we=92ll have to deal with it for a short= while longer. I think a pragmatic position is to declare such activities a= s out-of-scope since they=92re clearly NOT a zero touch model. This would a= void needing to weaken the zero-touch threat model to deal with an inherent= ly problematic use case.=20 Here is my justification for my position: The threat is that an attacker in= tercepts the device during shipping and installs malware on it. Google can = help you trivially find examples of this. Mitigations of this threat includ= e: a) log information on a _secure_ service (e.g. MASA approach) b) strong crypto authorization (e.g. netconfig owner certificates) c) [I=92m open to other ideas?]=20 Where any of these mitigations can be made to work where the target domain = is offline such as an oil field or ship at sea. BUT if the mitigation can b= e sidestepped by physical possession checks then anybody with physical poss= ession can inject themselves without being logged.=20 The only ways I know to mitigate that threat are to use TCG style measured = boot with remote attestation. This is something I agree with but since it r= equires hardware=85 I think the best approach is to layer that level of sec= urity on top of whatever inline zero-touch protocols we come up with (e.g. = declare it out-of-scope here since the mitigation is also out-of-scope).=20 - max On Apr 10, 2015, at 3:12 PM, Brian E Carpenter wrote: > Good morning (NZ time). Some responses in line. >=20 > On 11/04/2015 07:12, Michael Richardson wrote: >>=20 >> Max Pritikin (pritikin) wrote: >>=20 >> max> Michael, some questions for you inline so I can better understan= d >> max> the issues you=92re thinking about, >>=20 >> good. >>=20 >>>>>> Just for further clarity, 1) to whom do they register the new public >>>>>> key? >>>>=20 >>>>> Their own CA, within their own network. Remember that our target mark= et >>>>> for Anima includes very large networks (carriers or large enterprises= ). >>>>> But that isn't the whole market, of course. Smaller enterprises may b= e >>>>> happier to farm out security functions to the cloud, although it will >>>>> only take one well-publicised breach for that to become less popular. >>>>=20 >>>> I don't mean to be obtuse, but do I understand the process you are des= cribing >>>> to be: >>>> 1) the network operator unboxes the system in a lab/provisioning cente= r >>>> (It sure sounds like a serial console. I have learnt recently, this is >>>> called the "craft terminal" in telco speak. On small devices, this >>>> cable might speak USB or JTAG=85) >>=20 >> max> This describes a relatively high touch scenario where the device= is >> max> staged and supports the so called =93craft terminal=94 as an out= -of-band >> max> management channel. This incurs additional operational (staging)= and >> max> capital (extra interfaces) expenses so I tend to think in terms = of >> max> non-staging and inline solutions (aka =93zero touch=94 etc). Do = you have >> max> a sense that the model you=92re describing here will become more >> max> widespread? >>=20 >> Max, just to be clear, I'm not advocating this "high touch" scenario, I'= m >> just trying to understand if this is what Brian is suggesting before I m= ake >> any judgement of any kind. >=20 > Yes, I believe that there will be operators who want to do it this way. > I can imagine incumbent telcos doing so, just because that's the way they > work. I can certainly imagine military or other high security operators > doing so, because they are simply unwilling to trust anybody else. >=20 > I'm not advocating this approach; I just believe that some fraction > of the market will want to keep the entire process 100% in-house, > with no MASA and no call-home. >=20 >>>> 2) the network generates the new key, and enrolls it, I guess doing a >>>> copy and past on the craft terminal of the certificate request. >>=20 >> max> Even if we assume a =93craft terminal=94 that is physically secu= red do >> max> you think it is a good idea to have the network generate the key= =97 >> max> or do you see value in the more classic asymmetric key approach >> max> where the device generates the key itself if possible? >>=20 >> I think that the machine should generate it's own key, and key it secure >> internally. Many hardware modules do not support exporting their privat= e >> key... =20 >=20 > Oh. I'm missing something then; how does the rest of the domain learn > the public key? >=20 >> The CSR consists of public info only (essentially a self-signed copy >> of the public key, plus desired attributes). The copy and paste of a >> certificate request (CSR) is therefore of public information, but it mus= t >> handled carefully as it can be substituted along the way. >>=20 >>>> 3) the network operator boxes the system backup and ships it to where = it >>>> needs to go. (which might be a warehouse, where it will wait as a spar= e part) >>=20 >> max> Do you imagine that the credentials installed in 1-2 are the fin= al >> max> credentials for the device? Or do you think it might have more >> max> generic credentials while it sits in the warehouse and be issued= its >> max> final credentials after it is deployed? >>=20 >> When steps 1/2 are done "inhouse", then I think that both scenarios are >> possible and likely. So for instance, I would expect all military-like >> organizations (probably including rescue and humanitarian entities) to h= ave a >> staging situation. They simply can't assume there is any "online" where= they >> are going to do enrollment with. >=20 > Exactly my point. Military installations, nuclear power stations, the > access control system for highly secure buildings,... >=20 >>=20 >> max> Do you see value in the device manufacturer providing steps 1-2 >> max> during manufacturing thus saving the final customer the costs an= d >> max> complexities of these steps? >>=20 >> okay, so I'll finally bite: listed steps 1/2 are what we do now, and the= y >> suck. They are secure only because of the craft terminal, and devices >> too small for such an interface, or operators too simple to have an RS23= 2 on >> their laptop can not play. >>=20 >> The "0000" and "1111" as the univeral BT headset code are shameful... [m= y >> god, the headset could *speak* it's code to you :-)] >>=20 >> Yes, I want steps 1/2 done during manufacturing, but we need to bridge t= he >> ownership gap to be bridged. >>=20 >> I hope Brian will answer my original email, because I'm sure that he did= n't >> want to re-invent the craft terminal. >=20 > Not specially. My whole point is that Anima infrastructure needs to be ro= bust > against a whole variety of scenarios, regardless of what we think is the > best scenario. >=20 > Brian >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Fri Apr 10 17:04:46 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7AA1B2ECC for ; Fri, 10 Apr 2015 17:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFjwrCGEt5I3 for ; Fri, 10 Apr 2015 17:04:43 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0147.outbound.protection.outlook.com [207.46.100.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC9AC1B2ECB for ; Fri, 10 Apr 2015 17:04:43 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.1.130.23; Sat, 11 Apr 2015 00:04:42 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.180]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.180]) with mapi id 15.01.0130.020; Sat, 11 Apr 2015 00:04:42 +0000 From: Kent Watsen To: "Max Pritikin (pritikin)" , Brian E Carpenter Thread-Topic: [Anima] Ownership Concept Thread-Index: AQHQZn+WmG3Pkztd4UiFW+kyT70z+Z0sNK2AgAErGoCAAORAgIAAqhaAgAAKtICAAAmrgIAAbnSAgAAavACAAwvOAIACsluAgAKxQYCADBw9AIABC7KAgAAXygCAABhtgIAAH9sAgAENXgCAAAihgIAALpOAgAAQoQCAAAffAP//9gCA Date: Sat, 11 Apr 2015 00:04:41 +0000 Message-ID: References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> <5512DE41.6030209@gmail.com> <77FA386512F0D748BC7C02C36EB1106D956D45@szxeml557-mbs.china.huawei.com> <7912.1427385447@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D95700F@szxeml557-mbs.china.huawei.com> <1F85BE1D-44A3-420A-8852-A4BA0DE213AC@cisco.com> <247ADDB2-807D-4AB5-A814-58381A929EB5@cisco.com> <551BC405.3070204@gridmerge.com> <77FA386512F0D748BC7C02C36EB1106D95C712@szxeml557-mbs.china.huawei.com> <93110A7A-4FD8-4D30-B833-5AC516B54BFB@cisco.com> <5526E134.7060208@gmail.com> <21336.1428616625@sandelman.ca> <5527106A.10106@gmail.com> <15763.1428681312@sandelman.ca> <24238.1428693167@sandelman.ca> <55282EA2.6070409@gmail.com> <4D76E559-9E91-434C-8B2D-CAFDE3EFB1B4@cisco.com> In-Reply-To: <4D76E559-9E91-434C-8B2D-CAFDE3EFB1B4@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.11] authentication-results: cisco.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(83506001)(50986999)(87936001)(2950100001)(2900100001)(54356999)(66066001)(36756003)(86362001)(2656002)(99286002)(77156002)(106116001)(122556002)(92566002)(46102003)(76176999)(93886004)(62966003)(102836002)(40100003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; x-forefront-prvs: 05437568AA Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2015 00:04:41.9979 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458 Archived-At: Cc: Michael Richardson , "anima@ietf.org" Subject: Re: [Anima] Ownership Concept X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2015 00:04:46 -0000 >I personally disagree with the assertion that somebody with physical >possession of the device in factory default state should be able to =B3tak= e >ownership=B2 of the device without engaging with the vendor/cloud service. I agree emphatically. >I understand that there is a long history of this model and folks are >reluctant to give it up =8B so I expect that we=B9ll have to deal with it = for >a short while longer. I think a pragmatic position is to declare such >activities as out-of-scope since they=B9re clearly NOT a zero touch model. >This would avoid needing to weaken the zero-touch threat model to deal >with an inherently problematic use case. Also agree. A device that has been pre-staged (manually configured) is no longer at factory default and hence no bootstrapping process will occur. As a corollary to this, in order to thwart interdiction attacks, installers should always factory reset equipment as the first step to the bootstrapping process. >The only ways I know to mitigate that threat are to use TCG style >measured boot with remote attestation. This is something I agree with but >since it requires hardware=8A I think the best approach is to layer that >level of security on top of whatever inline zero-touch protocols we come >up with (e.g. declare it out-of-scope here since the mitigation is also >out-of-scope). Agreed. The only pragmatic mitigation to interdiction is the TCG measured boot with remote attestation, but even then it's defeatable with enough determination and resources. For that matter, an IDevID can only be trusted if an HSM like a TPM is used. IMO, equipment without said protections are laughably insecure. If we were to introduce levels is security, it might look like: Unprotected HSM-protocted TPM-protected IDevID IDevID secure boot ----------- ------------- ------------- Gold : x x Silver : x Bronze : x Bronze-level equipment can implement the bootstrapping protocol, but they're not suitable for critical deployments. Swinging the conversation around, it seems that the two proposals readout like this (hopefully it's a fair and accurate assessment): NETCONF Zero-touch ------------------ What: An offline process whereby a vendor (or delegate) signs a voucher that allows an owner to sign the bootstrapping data. Pros: Addresses the problem directly (e.g., owners, vouchers, etc.) How bootstrapping data is accessed doesn't matter (http, usb, nfc, etc.) No degradation in security when deployed on private networks. Results in configuration (not just keys) Cons: It will be difficult to track ownership through some supply chains Bootstrapping Keyinfra ---------------------- What: An online process whereby a vendor (or delegate) signs a voucher indicating that it is okay with the device joining the domain. Pros: Avoids supply-chain tracking issues. Cons: Unclear security guarantees provided by local policies. Security degraded on private networks. Also, both solutions rely on the device proving itself to the network using an IDevID. For Zero-touch, the IDevID is only used after the device has processed the bootstrapping data (e.g., it's configured to call home). For Keyinfra, the IDevID is used by the device during the enrollment process. Some additional thoughts: - The keyinfra solution could blend in the ownership voucher concept. That is, a MASA could dynamically sign a voucher to a registrar that could then sign the bootstrapping data for the device. - We seems that unnatural contortions are being performed to support consumer grade equipment (e.g., home net), where security is opt-in at best. - We should see if there are ways to mitigate the supply chain issues. Maybe a kiosk or a QRC printed on the receipt at Best Buys? Thanks, Kent From nobody Fri Apr 10 18:15:40 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 268A71A9235 for ; Fri, 10 Apr 2015 18:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id onWS95XRFUnl for ; Fri, 10 Apr 2015 18:15:37 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B3451A9232 for ; Fri, 10 Apr 2015 18:15:37 -0700 (PDT) Received: by pdbqa5 with SMTP id qa5so39288152pdb.1 for ; Fri, 10 Apr 2015 18:15:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=+C3A54g3F9lliJVxLwWOwIhyJBLB/d0gymvWFcrRmzs=; b=HVdVBDzTtqQeq+IAhTrZHIOCQZ0b5ps3gEZHAagaq2pjAqLTnFe/HipjSHL1NgqyVg p8LTPrRd8DzzaXUWXDLJJn+/r/mU0f5OU/m+pghNOZiXp2GVqv7faRBWB0fLBCg2EF1w ThLI9w6PE4yZ6TiJW4Zpt4P8yDdd0LrOxFOlzXtj82N4UWJACyrHbPv3OpqQFau3r0oc FNm6QUGIzzHVN/UCmPgfGIAPtXjLESQNTSb9Zkj54+235nz+2PnHXMj8Lh4kB2W2RQUk tZ2alOTfdIpUuAJBtpr7kI1y+1HgTiJRvzz8X/nzAmjaC0xbSXAFRmMuscRXITr97JH+ hC+w== X-Received: by 10.70.96.65 with SMTP id dq1mr7172045pdb.79.1428714937042; Fri, 10 Apr 2015 18:15:37 -0700 (PDT) Received: from ?IPv6:2406:e007:7e03:1:28cc:dc4c:9703:6781? ([2406:e007:7e03:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id kn7sm270906pab.10.2015.04.10.18.15.34 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Apr 2015 18:15:36 -0700 (PDT) Message-ID: <552875C0.8000609@gmail.com> Date: Sat, 11 Apr 2015 13:15:44 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Michael Behringer References: <55219C7C.1050608@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F2DCE6@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22F2DCE6@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Anima WG Subject: Re: [Anima] Anima domain/node ID format question X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2015 01:15:39 -0000 Hi, I'm extending this conversation to the list, with permission. The assumption here is that (regardless of how the ownership and security bootstrap dicussion ends up), the nodes in an autonomic network will be identified by a Node ID within a domain identified by a Domain ID. Now read on... On 07/04/2015 18:57, Michael Behringer (mbehring) wrote: > Hi Brian, > > [sorry yesterday was a day off here] > > Inline... > >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: 05 April 2015 22:35 >> To: Michael Behringer (mbehring); eckert.anima(mailer list); Liubing (Leo) >> Subject: Anima domain/node ID format question >> >> Hi, >> >> I'm asking this question to the anima-reference-model team first, but we >> can certainly expand the discussion to the WG if useful. >> >> I believe we have a concept that there will be an authenticated Domain ID >> for each AN domain, and an authenticated Node ID for each node in a >> domain. We're planning to remove the built-in security from GDNP, and >> require that GDNP must either operate within the ACP, or use (D)TLS if it for >> some reason is not running within the ACP. >> >> I suspect we will nevertheless want to keep a GDNP option to carry the >> {Domain ID, Node ID} pair - but even if we don't do this, the reference >> model will probably need to say something about them. > > I think it is clear that we MUST have a single domain and node ID in an autonomic network. No, "single" is wrong. We need a "lowest common denominator". There can (and will) be several forms of ID, that doesn't matter, what matters is that there is the one that's constant and that all nodes in the domain understand. > >> So, my question: should we define a single format for Domain ID and Node >> ID, or should they be versioned? > > In our approach we're using a single format for node ID and domain ID, but a versioned form for addressing. Reason is that the node ID and domain ID are not really structured, but addressing might well need to be. So, we need some flexibility there. I agree that the IDs may not be structured (from an external point of view) but might there not be different families of ID? For addressing, in GDNP we have locator options, currently of type IPv4, IPv6 and FQDN. Is that what you are thinking of, or something else? > We're planning on writing up our approach on addressing, for discussion, but it hasn't happened yet. > >> draft-pritikin does define a specific format of Domain ID. I'm not sure if any >> current draft defines a Node ID format, except for the material we plan to >> delete from GDNP. > > This (node ID, domain ID, address model) should probably go into the reference model. Thoughts? Yes, I think it belongs in the reference model, but since that is likely to end up Informational, we might need to put the format definitions, if needed, somewhere else. Brian > I suggest to take this to the list. Feel free to copy the list on your reply. > > Michael > >> Brian From nobody Sat Apr 11 11:04:11 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BEC31A87BE for ; Sat, 11 Apr 2015 11:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Z2BIo0XyZIS for ; Sat, 11 Apr 2015 11:04:08 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E7641A879F for ; Sat, 11 Apr 2015 11:04:08 -0700 (PDT) Received: from mb-aye.local (160.sub-70-211-1.myvzw.com [70.211.1.160]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t3BI43Wg099673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 11 Apr 2015 18:04:04 GMT (envelope-from joelja@bogus.com) To: "Max Pritikin (pritikin)" , Brian E Carpenter references: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> <5512DE41.6030209@gmail.com> <77FA386512F0D748BC7C02C36EB1106D956D45@szxeml557-mbs.china.huawei.com> <7912.1427385447@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D95700F@szxeml557-mbs.china.huawei.com> <1F85BE1D-44A3-420A-8852-A4BA0DE213AC@cisco.com> <247ADDB2-807D-4AB5-A814-58381A929EB5@cisco.com> <551BC405.3070204@gridmerge.com> <77FA386512F0D748BC7C02C36EB1106D95C712@szxeml557-mbs.china.huawei.com> <93110A7A-4FD8-4D30-B833-5AC516B54BFB@cisco.com> <5526E134.7060208@gmail.com> <21336.1428616625@sandelman.ca> <5527106A.10106@gmail.com> <15763.1428681312@sandelman.ca> <24238.1428693167@sandelman.ca> <55282EA2.6070409@gmail.com> <4D76E559-9E91-434C-8B2D-CAFDE3EFB1B4@cisco.com> From: joel jaeggli x-enigmail-draft-status: N1110 message-id: <5529620D.7010102@bogus.com> Date: Sat, 11 Apr 2015 11:03:57 -0700 user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0 mime-version: 1.0 in-reply-to: <4D76E559-9E91-434C-8B2D-CAFDE3EFB1B4@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8LHdbuGo0T15mHT8X9iDPLIPEMUreLGLR" Archived-At: Cc: Michael Richardson , "anima@ietf.org" Subject: Re: [Anima] Ownership Concept X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2015 18:04:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8LHdbuGo0T15mHT8X9iDPLIPEMUreLGLR Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 4/10/15 1:40 PM, Max Pritikin (pritikin) wrote: > It is always morning somewhere! >=20 > I personally disagree with the assertion that somebody with physical > possession of the device in factory default state should be able to > =93take ownership=94 of the device without engaging with the vendor/clo= ud > service. I understand that there is a long history of this model and > folks are reluctant to give it up =97 so I expect that we=92ll have to > deal with it for a short while longer. I think a pragmatic position > is to declare such activities as out-of-scope since they=92re clearly > NOT a zero touch model. This would avoid needing to weaken the > zero-touch threat model to deal with an inherently problematic use > case. This actually seems like a question of business model... which is not really a problem I would expect us to address directly. > Here is my justification for my position: The threat is that an > attacker intercepts the device during shipping and installs malware > on it. Google can help you trivially find examples of this. > Mitigations of this threat include: a) log information on a _secure_ > service (e.g. MASA approach) b) strong crypto authorization (e.g. > netconfig owner certificates) c) [I=92m open to other ideas?] Where any= > of these mitigations can be made to work where the target domain is > offline such as an oil field or ship at sea. BUT if the mitigation > can be sidestepped by physical possession checks then anybody with > physical possession can inject themselves without being logged. if customers demand it that's what you'll build, if not then whatever. > The only ways I know to mitigate that threat are to use TCG style > measured boot with remote attestation. This is something I agree with > but since it requires hardware=85 I think the best approach is to layer= > that level of security on top of whatever inline zero-touch protocols > we come up with (e.g. declare it out-of-scope here since the > mitigation is also out-of-scope). >=20 > - max >=20 > On Apr 10, 2015, at 3:12 PM, Brian E Carpenter > wrote: >=20 >> Good morning (NZ time). Some responses in line. >>=20 >> On 11/04/2015 07:12, Michael Richardson wrote: >>>=20 >>> Max Pritikin (pritikin) wrote: >>>=20 >>> max> Michael, some questions for you inline so I can better >>> understand max> the issues you=92re thinking about, >>>=20 >>> good. >>>=20 >>>>>>> Just for further clarity, 1) to whom do they register the >>>>>>> new public key? >>>>>=20 >>>>>> Their own CA, within their own network. Remember that our >>>>>> target market for Anima includes very large networks >>>>>> (carriers or large enterprises). But that isn't the whole >>>>>> market, of course. Smaller enterprises may be happier to >>>>>> farm out security functions to the cloud, although it will=20 >>>>>> only take one well-publicised breach for that to become >>>>>> less popular. >>>>>=20 >>>>> I don't mean to be obtuse, but do I understand the process >>>>> you are describing to be: 1) the network operator unboxes the >>>>> system in a lab/provisioning center (It sure sounds like a >>>>> serial console. I have learnt recently, this is called the >>>>> "craft terminal" in telco speak. On small devices, this=20 >>>>> cable might speak USB or JTAG=85) >>>=20 >>> max> This describes a relatively high touch scenario where the >>> device is max> staged and supports the so called =93craft terminal=94= >>> as an out-of-band max> management channel. This incurs additional >>> operational (staging) and max> capital (extra interfaces) >>> expenses so I tend to think in terms of max> non-staging and >>> inline solutions (aka =93zero touch=94 etc). Do you have max> a sense= >>> that the model you=92re describing here will become more max> >>> widespread? >>>=20 >>> Max, just to be clear, I'm not advocating this "high touch" >>> scenario, I'm just trying to understand if this is what Brian is >>> suggesting before I make any judgement of any kind. >>=20 >> Yes, I believe that there will be operators who want to do it this >> way. I can imagine incumbent telcos doing so, just because that's >> the way they work. I can certainly imagine military or other high >> security operators doing so, because they are simply unwilling to >> trust anybody else. >>=20 >> I'm not advocating this approach; I just believe that some >> fraction of the market will want to keep the entire process 100% >> in-house, with no MASA and no call-home. >>=20 >>>>> 2) the network generates the new key, and enrolls it, I guess >>>>> doing a copy and past on the craft terminal of the >>>>> certificate request. >>>=20 >>> max> Even if we assume a =93craft terminal=94 that is physically >>> secured do max> you think it is a good idea to have the network >>> generate the key =97 max> or do you see value in the more classic >>> asymmetric key approach max> where the device generates the key >>> itself if possible? >>>=20 >>> I think that the machine should generate it's own key, and key it >>> secure internally. Many hardware modules do not support >>> exporting their private key... >>=20 >> Oh. I'm missing something then; how does the rest of the domain >> learn the public key? >>=20 >>> The CSR consists of public info only (essentially a self-signed >>> copy of the public key, plus desired attributes). The copy and >>> paste of a certificate request (CSR) is therefore of public >>> information, but it must handled carefully as it can be >>> substituted along the way. >>>=20 >>>>> 3) the network operator boxes the system backup and ships it >>>>> to where it needs to go. (which might be a warehouse, where >>>>> it will wait as a spare part) >>>=20 >>> max> Do you imagine that the credentials installed in 1-2 are the >>> final max> credentials for the device? Or do you think it might >>> have more max> generic credentials while it sits in the warehouse >>> and be issued its max> final credentials after it is deployed? >>>=20 >>> When steps 1/2 are done "inhouse", then I think that both >>> scenarios are possible and likely. So for instance, I would >>> expect all military-like organizations (probably including rescue >>> and humanitarian entities) to have a staging situation. They >>> simply can't assume there is any "online" where they are going to >>> do enrollment with. >>=20 >> Exactly my point. Military installations, nuclear power stations, >> the access control system for highly secure buildings,... >>=20 >>>=20 >>> max> Do you see value in the device manufacturer providing steps >>> 1-2 max> during manufacturing thus saving the final customer the >>> costs and max> complexities of these steps? >>>=20 >>> okay, so I'll finally bite: listed steps 1/2 are what we do now, >>> and they suck. They are secure only because of the craft >>> terminal, and devices too small for such an interface, or >>> operators too simple to have an RS232 on their laptop can not >>> play. >>>=20 >>> The "0000" and "1111" as the univeral BT headset code are >>> shameful... [my god, the headset could *speak* it's code to you >>> :-)] >>>=20 >>> Yes, I want steps 1/2 done during manufacturing, but we need to >>> bridge the ownership gap to be bridged. >>>=20 >>> I hope Brian will answer my original email, because I'm sure that >>> he didn't want to re-invent the craft terminal. >>=20 >> Not specially. My whole point is that Anima infrastructure needs to >> be robust against a whole variety of scenarios, regardless of what >> we think is the best scenario. >>=20 >> Brian >>=20 >> _______________________________________________ Anima mailing list=20 >> Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima >=20 > _______________________________________________ Anima mailing list=20 > Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima >=20 --8LHdbuGo0T15mHT8X9iDPLIPEMUreLGLR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlUpYg4ACgkQ8AA1q7Z/VrJongCbBknNgicEsKQcNBoKw2b9cYax n0MAn2SN8bgx772A68Q9rewH2i9JIB/X =KQ5G -----END PGP SIGNATURE----- --8LHdbuGo0T15mHT8X9iDPLIPEMUreLGLR-- From nobody Sat Apr 11 14:16:47 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9E31A87F0 for ; Sat, 11 Apr 2015 14:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECf9FNB0GG3h for ; Sat, 11 Apr 2015 14:16:44 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 691E41A87EC for ; Sat, 11 Apr 2015 14:16:41 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 59EB0203AB for ; Sat, 11 Apr 2015 17:27:34 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 2096763B76; Sat, 11 Apr 2015 17:16:39 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 09ED863731 for ; Sat, 11 Apr 2015 17:16:39 -0400 (EDT) From: Michael Richardson To: Anima WG In-Reply-To: <552875C0.8000609@gmail.com> References: <55219C7C.1050608@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F2DCE6@xmb-rcd-x14.cisco.com> <552875C0.8000609@gmail.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Anima] Anima domain/node ID format question X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2015 21:16:46 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > I'm extending this conversation to the list, with permission. The > assumption here is that (regardless of how the ownership and security > bootstrap dicussion ends up), the nodes in an autonomic network will be > identified by a Node ID within a domain identified by a Domain ID. I'm reluctant to have any kind of node-ID structure beyond something like a uuid. I agree that it needs to be qualified by a DomainID. I think that all other things should be attributes of the nodeID, queryable and reportable via some mechanism. I think that the node-ID should be cryptographically bound into the IDevID as Node-ID @ VENDOR-DOMAIN, and when bootstraped, it should be bound in LDevID as Node-ID'@OPERATOR-DOMAIN. I believe that for many, it will suffice to set Node-ID' == Node-ID, but I don't believe this should be hard coded anywhere in a protocol. In particular, some operators will prefer to maintain the Node-ID across physical replacements of a router chassis, while other operators will prefer to always replace it. If there is some additional data relevant to warantees (an Asset Tag or Chassis Serial Number), then this should be represented as an attribute. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVSmPNoCLcPvd0N1lAQISrQf+JmtTXQMJ2b6mIoU1AIlx0opUR2la9Fpr V+D/14zt1DUmfAGbsOwJfxeFIXwr3YCS3nKHWoBnFCpyYLdD/UmoTAmb7IPt96HW C90qKdw56t7JYie/drbfrWrUjURUYOUdJLr5cdvTNinydL21VT8E8KVcqx/QbiY7 uKblknmDx8hTT0YvykSyHw+9YvR4oofhfLwxOJYB+K3AfMNpFiOfad21nTYxS8qH FVD68iYmJgaz9IpmexP4m0ZIcl6OKdeJpI/mERjUf0L/36mAgmsqhtOE2ESGRlKo +qvfZsLpBF7J8eZNymsu0/0q9FN/ZBLZxealoIB+R5syrTl2XzidhQ== =Jhrb -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Apr 11 16:17:20 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4838C1B3109 for ; Sat, 11 Apr 2015 16:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaYWScS_YT5U for ; Sat, 11 Apr 2015 16:17:17 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B79941B3107 for ; Sat, 11 Apr 2015 16:17:16 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id AB319203AB for ; Sat, 11 Apr 2015 19:28:10 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 5E30C63B76; Sat, 11 Apr 2015 19:17:15 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 49790636B6 for ; Sat, 11 Apr 2015 19:17:15 -0400 (EDT) From: Michael Richardson To: "anima\@ietf.org" In-Reply-To: <5529620D.7010102@bogus.com> References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> <5512DE41.6030209@gmail.com> <77FA386512F0D748BC7C02C36EB1106D956D45@szxeml557-mbs.china.huawei.com> <7912.1427385447@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D95700F@szxeml557-mbs.china.huawei.com> <1F85BE1D-44A3-420A-8852-A4BA0DE213AC@cisco.com> <247ADDB2-807D-4AB5-A814-58381A929EB5@cisco.com> <551BC405.3070204@gridmerge.com> <77FA386512F0D748BC7C02C36EB1106D95C712@szxeml557-mbs.china.huawei.com> <93110A7A-4FD8-4D30-B833-5AC516B54BFB@cisco.com> <5526E134.7060208@gmail.com> <21336.1428616625@sandelman.ca> <5527106A.10106@gmail.com> <15763.1428681312@sandelman.ca> <24238.1428693167@sandelman.ca> <55282EA2.6070409@gmail.com> <4D76E559-9E91-434C-8B2D-CAFDE3EFB1B4@cisco.com> <5529620D .7010102@bogus.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Anima] Ownership Concept X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2015 23:17:19 -0000 --=-=-= Content-Type: text/plain joel jaeggli and Max started a thread on the question of whether or not some operators and some vendors will want to maintain a model where physical possession of the device implies ownership. I observe that for quite a number of operators the trip back to the vendor for (initial) deployment authorization is itself a far worse attack than other attacks. In particular, it can change the business relationship from one of purchaser to that of effective leasor, as it could restrict ability to resell. So let's not try to solve this problem, but instead consider the converse problem. Rather than dealing with: "there is a device in my posession that I wish to own", to instead deal with, "There is a device not in my posession, which I wish to claim" mcr> I think that the machine should generate it's own key, and key it mcr> secure internally. Many hardware modules do not support mcr> exporting their private key... max> Oh. I'm missing something then; how does the rest of the domain max> learn the public key? Maybe the term is CSR not clear: that's the request to get a certificate that is sent to the CA. It would be returned to the system to be installed as the domain-specific certificate, and then the machine would be deployed with a locally significant certificate. This craft terminal mechanism is a mitigation for the situation where we don't have a token-enabled MASA and/or other vendor-anchored ownership certificate. mcr> When steps 1/2 are done "inhouse", then I think that both mcr> scenarios are possible and likely. So for instance, I would mcr> expect all military-like organizations (probably including rescue mcr> and humanitarian entities) to have a staging situation. They mcr> simply can't assume there is any "online" where they are going to mcr> do enrollment with. max> Exactly my point. Military installations, nuclear power stations, max> the access control system for highly secure buildings,... My claim is that the equipment has already been bootstraped prior to being placed into a warehouse. My claim is also that we should consider the entirely online, zero-touch situation, and consider the work-arounds for not being online as requiring a mitigation proceedure. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVSmre4CLcPvd0N1lAQK4qggAhRr+jjxfu3dOJVQAD9q7IEt1fzuWOlmJ roJDrsIWf6BxB7PTB3Quu8mJLiQDZVB1uboa/EMGcPDzFwQXmMG4bbXr/OdyYz60 cTpY+RVL+eq0+ZeCvKsgO463KYrgssW8ImtoQpxFR0UglhCxxhv78OrmIa9T+r6p 33rfrnnLQNFjerI9oWR+s8nhaCdwt50qhCTaK4+1h8J5WlqvFTctoAKGDSVdn1o2 ROq72HIARC99jpxOnbKtbe82GTRa2l6KUTjRrIyPsw98QkwsPuAOsOcXMxICsG4q 2yIZ7BfuWFfMXVS3mZoniZo0lqJgQI+s0ylf2roVdXkxtICeEaKAoQ== =ztTJ -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Apr 11 17:51:01 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8D81A910B for ; Sat, 11 Apr 2015 17:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CX_kP6v4GwDz for ; Sat, 11 Apr 2015 17:50:58 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C21011A9106 for ; Sat, 11 Apr 2015 17:50:58 -0700 (PDT) Received: by paboj16 with SMTP id oj16so62126868pab.0 for ; Sat, 11 Apr 2015 17:50:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=N1SSBpQrcwm2nXYs+oMe8vfovKr64FJzXqFQZphgFhs=; b=KBxmdCFzFnWB1wBcP+lo2J6VWHU2DKybZG7QKSRcg8w8UNEnHd0thMcAGxOwn9KDJt QOEF+cqkl2200PFTQtwcKHzynx7+oNLy39strk3IOrp+ZoKCY6kfCmeqJecJrmvOjSzX LhF3qaM7Rm5COzGdrlY7sroYsAPjxJdcf7k7OIffb3woQyp7tVS2Y8vQCCC1MYQ9KRC3 5Q6NSJ4NZloq4s++wrkV3mNjSrnK+UiN5b3NNwsn+Au6B0TM5aCqqs8hjKgDTo3HJDU+ lZfQLExqlRo2/9+oCiZ/BaQxCyrADr98ZbXJ31AF31Yz/D8UC3+7Q3rvfUgVBjYO/vOf tWXQ== X-Received: by 10.66.65.130 with SMTP id x2mr14288469pas.152.1428799858457; Sat, 11 Apr 2015 17:50:58 -0700 (PDT) Received: from ?IPv6:2406:e007:533b:1:28cc:dc4c:9703:6781? ([2406:e007:533b:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id rj6sm3032292pbc.62.2015.04.11.17.50.55 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Apr 2015 17:50:57 -0700 (PDT) Message-ID: <5529C150.8010500@gmail.com> Date: Sun, 12 Apr 2015 12:50:24 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Michael Richardson , "anima@ietf.org" References: <5511E12E.9050002@gmx.net> <77FA386512F0D748BC7C02C36EB1106D956D45@szxeml557-mbs.china.huawei.com> <7912.1427385447@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D95700F@szxeml557-mbs.china.huawei.com> <1F85BE1D-44A3-420A-8852-A4BA0DE213AC@cisco.com> <247ADDB2-807D-4AB5-A814-58381A929EB5@cisco.com> <551BC405.3070204@gridmerge.com> <77FA386512F0D748BC7C02C36EB1106D95C712@szxeml557-mbs.china.huawei.com> <93110A7A-4FD8-4D30-B833-5AC516B54BFB@cisco.com> <5526E134.7060208@gmail.com> <21336.1428616625@sandelman.ca> <5527106A.10106@gmail.com> <15763.1428681312@sandelman.ca> <24238.1428693167@sandelman.ca> <55282EA2.6070409@gmail.com> <4D76E559-9E91-434C-8B2D-CAFDE3EFB1B4@cisco.com> <5529620D .7010102@bogus.com> <9477.1428794235@sandelman.ca> In-Reply-To: <9477.1428794235@sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Ownership Concept X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2015 00:51:00 -0000 Two things... On 12/04/2015 11:17, Michael Richardson wrote: > > joel jaeggli and Max started a thread on the question of > whether or not some operators and some vendors will want to maintain a model > where physical possession of the device implies ownership. > > I observe that for quite a number of operators the trip back to the vendor > for (initial) deployment authorization is itself a far worse attack than other > attacks. In particular, it can change the business relationship from one of > purchaser to that of effective leasor, as it could restrict ability to > resell. > > So let's not try to solve this problem, but instead consider the converse > problem. Rather than dealing with: "there is a device in my posession that > I wish to own", to instead deal with, "There is a device not in my posession, > which I wish to claim" > > mcr> I think that the machine should generate it's own key, and key it > mcr> secure internally. Many hardware modules do not support > mcr> exporting their private key... > > max> Oh. I'm missing something then; how does the rest of the domain > max> learn the public key? > > Maybe the term is CSR not clear: that's the request to get a certificate that > is sent to the CA. It would be returned to the system to be installed as the > domain-specific certificate, and then the machine would be deployed with a > locally significant certificate. This craft terminal mechanism is a > mitigation for the situation where we don't have a token-enabled MASA and/or > other vendor-anchored ownership certificate. > > mcr> When steps 1/2 are done "inhouse", then I think that both > mcr> scenarios are possible and likely. So for instance, I would > mcr> expect all military-like organizations (probably including rescue > mcr> and humanitarian entities) to have a staging situation. They > mcr> simply can't assume there is any "online" where they are going to > mcr> do enrollment with. > > max> Exactly my point. Military installations, nuclear power stations, > max> the access control system for highly secure buildings,... > > My claim is that the equipment has already been bootstraped prior to being > placed into a warehouse. > > My claim is also that we should consider the entirely online, zero-touch > situation, and consider the work-arounds for not being online as requiring a > mitigation proceedure. 1. The comments tagged above as max> were actually brian> (and if everybody used the de facto standard quoting convention for plain text email, we wouldn't have that confusion). 2. I do object to your choice of words ("work-around" and "mitigation"). They are just alternative methods, which will be used for reasons that aren't our business. I submit that our business is to make the Anima infrastructure work equally well (and equally securely) in each case. Brian From nobody Sun Apr 12 18:06:59 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD0D1B3B15 for ; Sun, 12 Apr 2015 18:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9U2u-VCiriAG for ; Sun, 12 Apr 2015 18:06:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E6FF1B3B14 for ; Sun, 12 Apr 2015 18:06:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUT54741; Mon, 13 Apr 2015 01:06:53 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 13 Apr 2015 02:06:52 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.135]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Mon, 13 Apr 2015 09:06:49 +0800 From: Sheng Jiang To: Brian E Carpenter , Michael Behringer Thread-Topic: [Anima] Anima domain/node ID format question Thread-Index: AQHQc/ULSeLRxwNrLECNjpvkEvwdE51KIn6g Date: Mon, 13 Apr 2015 01:06:48 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B925F4FDDE8@nkgeml512-mbx.china.huawei.com> References: <55219C7C.1050608@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F2DCE6@xmb-rcd-x14.cisco.com> <552875C0.8000609@gmail.com> In-Reply-To: <552875C0.8000609@gmail.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.197] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Anima WG Subject: Re: [Anima] Anima domain/node ID format question X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 01:06:59 -0000 PkknbSBleHRlbmRpbmcgdGhpcyBjb252ZXJzYXRpb24gdG8gdGhlIGxpc3QsIHdpdGggcGVybWlz c2lvbi4gVGhlDQo+YXNzdW1wdGlvbiBoZXJlIGlzIHRoYXQgKHJlZ2FyZGxlc3Mgb2YgaG93IHRo ZSBvd25lcnNoaXAgYW5kIHNlY3VyaXR5DQo+Ym9vdHN0cmFwIGRpY3Vzc2lvbiBlbmRzIHVwKSwg dGhlIG5vZGVzIGluIGFuIGF1dG9ub21pYyBuZXR3b3JrIHdpbGwgYmUNCj5pZGVudGlmaWVkIGJ5 IGEgTm9kZSBJRCB3aXRoaW4gYSBkb21haW4gaWRlbnRpZmllZCBieSBhIERvbWFpbiBJRC4NCg0K QWxsb3cgbWUgdG8gYmUgZGl2ZXJnZW50IGEgbGl0dGxlIGJpdC4gV2h5IHNpbmdsZSBkb21haW4g SUQ/IElmIGFuIGF1dG9ub21pYyBub2RlIGNhbiBvbmx5IGhhdmUgb25lIGRvbWFpbiBJRCwgdGhl IGRvbWFpbiBtYW5hZ2VtZW50IGNvdWxkIGJlIHJpZ2VzY2VudC4gVGhlbiB3ZSBoYXZlIHRvIGhh bmRsZSBzb21ldGhpbmcsIGxpa2UgZG9tYWluIG1lcmdlbmNlLCByZW51bWJlcmluZywgZXRjLiBJ ZiB3ZSBkZWNvdXBsZSB0aGUgbm9kZSBmcm9tIGl0cyBiZWxvbmdpbmcgZG9tYWluLCBpdCBtZWFu cyBhIG5vZGUgY291bGQgaGF2ZSB2aXJ0dWFsIGlkcyB0aGF0IGJlbG9uZyB0byBkaWZmZXJlbnQg ZG9tYWluIG9yIGdyb3VwLiBUaGVuLCBtYXliZSB3ZSBkbyBub3QgaGF2ZSB0byBoYXZlIGdyb3Vw IGNvbmNlcHQ/DQoNCkJlc3QgcmVnYXJkcywNCg0KU2hlbmcNCg0KPk5vdyByZWFkIG9uLi4uDQo+ DQo+T24gMDcvMDQvMjAxNSAxODo1NywgTWljaGFlbCBCZWhyaW5nZXIgKG1iZWhyaW5nKSB3cm90 ZToNCj4+IEhpIEJyaWFuLA0KPj4NCj4+IFtzb3JyeSB5ZXN0ZXJkYXkgd2FzIGEgZGF5IG9mZiBo ZXJlXQ0KPj4NCj4+IElubGluZS4uLg0KPj4NCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPj4+IEZyb206IEJyaWFuIEUgQ2FycGVudGVyIFttYWlsdG86YnJpYW4uZS5jYXJwZW50ZXJA Z21haWwuY29tXQ0KPj4+IFNlbnQ6IDA1IEFwcmlsIDIwMTUgMjI6MzUNCj4+PiBUbzogTWljaGFl bCBCZWhyaW5nZXIgKG1iZWhyaW5nKTsgZWNrZXJ0LmFuaW1hKG1haWxlciBsaXN0KTsgTGl1Ymlu ZyAoTGVvKQ0KPj4+IFN1YmplY3Q6IEFuaW1hIGRvbWFpbi9ub2RlIElEIGZvcm1hdCBxdWVzdGlv bg0KPj4+DQo+Pj4gSGksDQo+Pj4NCj4+PiBJJ20gYXNraW5nIHRoaXMgcXVlc3Rpb24gdG8gdGhl IGFuaW1hLXJlZmVyZW5jZS1tb2RlbCB0ZWFtIGZpcnN0LCBidXQgd2UNCj4+PiBjYW4gY2VydGFp bmx5IGV4cGFuZCB0aGUgZGlzY3Vzc2lvbiB0byB0aGUgV0cgaWYgdXNlZnVsLg0KPj4+DQo+Pj4g SSBiZWxpZXZlIHdlIGhhdmUgYSBjb25jZXB0IHRoYXQgdGhlcmUgd2lsbCBiZSBhbiBhdXRoZW50 aWNhdGVkIERvbWFpbiBJRA0KPj4+IGZvciBlYWNoIEFOIGRvbWFpbiwgYW5kIGFuIGF1dGhlbnRp Y2F0ZWQgTm9kZSBJRCBmb3IgZWFjaCBub2RlIGluIGENCj4+PiBkb21haW4uIFdlJ3JlIHBsYW5u aW5nIHRvIHJlbW92ZSB0aGUgYnVpbHQtaW4gc2VjdXJpdHkgZnJvbSBHRE5QLCBhbmQNCj4+PiBy ZXF1aXJlIHRoYXQgR0ROUCBtdXN0IGVpdGhlciBvcGVyYXRlIHdpdGhpbiB0aGUgQUNQLCBvciB1 c2UgKEQpVExTIGlmIGl0DQo+Zm9yDQo+Pj4gc29tZSByZWFzb24gaXMgbm90IHJ1bm5pbmcgd2l0 aGluIHRoZSBBQ1AuDQo+Pj4NCj4+PiBJIHN1c3BlY3Qgd2Ugd2lsbCBuZXZlcnRoZWxlc3Mgd2Fu dCB0byBrZWVwIGEgR0ROUCBvcHRpb24gdG8gY2FycnkgdGhlDQo+Pj4ge0RvbWFpbiBJRCwgTm9k ZSBJRH0gcGFpciAtIGJ1dCBldmVuIGlmIHdlIGRvbid0IGRvIHRoaXMsIHRoZSByZWZlcmVuY2UN Cj4+PiBtb2RlbCB3aWxsIHByb2JhYmx5IG5lZWQgdG8gc2F5IHNvbWV0aGluZyBhYm91dCB0aGVt Lg0KPj4NCj4+IEkgdGhpbmsgaXQgaXMgY2xlYXIgdGhhdCB3ZSBNVVNUIGhhdmUgYSBzaW5nbGUg ZG9tYWluIGFuZCBub2RlIElEIGluIGFuDQo+YXV0b25vbWljIG5ldHdvcmsuIE5vLCAic2luZ2xl IiBpcyB3cm9uZy4gV2UgbmVlZCBhICJsb3dlc3QgY29tbW9uDQo+ZGVub21pbmF0b3IiLiBUaGVy ZSBjYW4gKGFuZCB3aWxsKSBiZSBzZXZlcmFsIGZvcm1zIG9mIElELCB0aGF0IGRvZXNuJ3QgbWF0 dGVyLA0KPndoYXQgbWF0dGVycyBpcyB0aGF0IHRoZXJlIGlzIHRoZSBvbmUgdGhhdCdzIGNvbnN0 YW50IGFuZCB0aGF0IGFsbCBub2RlcyBpbiB0aGUNCj5kb21haW4gdW5kZXJzdGFuZC4NCj4+DQo+ Pj4gU28sIG15IHF1ZXN0aW9uOiBzaG91bGQgd2UgZGVmaW5lIGEgc2luZ2xlIGZvcm1hdCBmb3Ig RG9tYWluIElEIGFuZCBOb2RlDQo+Pj4gSUQsIG9yIHNob3VsZCB0aGV5IGJlIHZlcnNpb25lZD8N Cj4+DQo+PiBJbiBvdXIgYXBwcm9hY2ggd2UncmUgdXNpbmcgYSBzaW5nbGUgZm9ybWF0IGZvciBu b2RlIElEIGFuZCBkb21haW4gSUQsIGJ1dA0KPmEgdmVyc2lvbmVkIGZvcm0gZm9yIGFkZHJlc3Np bmcuIFJlYXNvbiBpcyB0aGF0IHRoZSBub2RlIElEIGFuZCBkb21haW4gSUQNCj5hcmUgbm90IHJl YWxseSBzdHJ1Y3R1cmVkLCBidXQgYWRkcmVzc2luZyBtaWdodCB3ZWxsIG5lZWQgdG8gYmUuIFNv LCB3ZSBuZWVkDQo+c29tZSBmbGV4aWJpbGl0eSB0aGVyZS4NCj4NCj5JIGFncmVlIHRoYXQgdGhl IElEcyBtYXkgbm90IGJlIHN0cnVjdHVyZWQgKGZyb20gYW4gZXh0ZXJuYWwgcG9pbnQgb2Ygdmll dykNCj5idXQgbWlnaHQgdGhlcmUgbm90IGJlIGRpZmZlcmVudCBmYW1pbGllcyBvZiBJRD8NCj4N Cj5Gb3IgYWRkcmVzc2luZywgaW4gR0ROUCB3ZSBoYXZlIGxvY2F0b3Igb3B0aW9ucywgY3VycmVu dGx5IG9mIHR5cGUgSVB2NCwgSVB2Ng0KPmFuZCBGUUROLiBJcyB0aGF0IHdoYXQgeW91IGFyZSB0 aGlua2luZyBvZiwgb3Igc29tZXRoaW5nIGVsc2U/DQo+DQo+PiBXZSdyZSBwbGFubmluZyBvbiB3 cml0aW5nIHVwIG91ciBhcHByb2FjaCBvbiBhZGRyZXNzaW5nLCBmb3IgZGlzY3Vzc2lvbiwNCj5i dXQgaXQgaGFzbid0IGhhcHBlbmVkIHlldC4NCj4+DQo+Pj4gZHJhZnQtcHJpdGlraW4gZG9lcyBk ZWZpbmUgYSBzcGVjaWZpYyBmb3JtYXQgb2YgRG9tYWluIElELiBJJ20gbm90IHN1cmUgaWYNCj5h bnkNCj4+PiBjdXJyZW50IGRyYWZ0IGRlZmluZXMgYSBOb2RlIElEIGZvcm1hdCwgZXhjZXB0IGZv ciB0aGUgbWF0ZXJpYWwgd2UgcGxhbiB0bw0KPj4+IGRlbGV0ZSBmcm9tIEdETlAuDQo+Pg0KPj4g VGhpcyAobm9kZSBJRCwgZG9tYWluIElELCBhZGRyZXNzIG1vZGVsKSBzaG91bGQgcHJvYmFibHkg Z28gaW50byB0aGUNCj5yZWZlcmVuY2UgbW9kZWwuIFRob3VnaHRzPw0KPg0KPlllcywgSSB0aGlu ayBpdCBiZWxvbmdzIGluIHRoZSByZWZlcmVuY2UgbW9kZWwsIGJ1dCBzaW5jZSB0aGF0IGlzIGxp a2VseSB0bw0KPmVuZCB1cCBJbmZvcm1hdGlvbmFsLCB3ZSBtaWdodCBuZWVkIHRvIHB1dCB0aGUg Zm9ybWF0IGRlZmluaXRpb25zLCBpZiBuZWVkZWQsDQo+c29tZXdoZXJlIGVsc2UuDQo+DQo+ICAg QnJpYW4NCj4NCj4+IEkgc3VnZ2VzdCB0byB0YWtlIHRoaXMgdG8gdGhlIGxpc3QuIEZlZWwgZnJl ZSB0byBjb3B5IHRoZSBsaXN0IG9uIHlvdXIgcmVwbHkuDQo+Pg0KPj4gTWljaGFlbA0KPj4NCj4+ PiAgICAgQnJpYW4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPkFuaW1hIG1haWxpbmcgbGlzdA0KPkFuaW1hQGlldGYub3JnDQo+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYQ0K From nobody Sun Apr 12 21:41:31 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762F31A6F39 for ; Sun, 12 Apr 2015 21:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUilZLrcb-OP for ; Sun, 12 Apr 2015 21:41:27 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C38E41A6F0A for ; Sun, 12 Apr 2015 21:41:27 -0700 (PDT) Received: by pabsx10 with SMTP id sx10so89741170pab.3 for ; Sun, 12 Apr 2015 21:41:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=DWr5nwzrL0l8eeq2H+PMTVvqwqj0jUTPpLN0dbEjwa0=; b=oohwvXewniS53nLNLp200wu6vk8ETLqsxKmFzFsknXIHhO170L3943mjRzfoYfcmQw BEsv32k72xWtHaneJYaH8Fm4YSTHTAV2SOengQHXnsf1vYtDRA6F4DpcGsWzQ4Lt2a3x qDjmtq4OwHmMU7XwhWT6zKd5LF+rQvGEjgcwrKJRFbUBdxtQ8ga8QvshxK/xLlNcoFWU r6rH4sWaHDyRFgHA2uKHEDL+SwDUlEOO5PHqkV4sdWGEEB600fV6HE9mxs30slAn3SZX XbqlN8byeAtV2xrvQmHh9/RlCbuKRtmragJvc4+W0LUr671q7gkMVNvnkASIX4Mxrs4R v4Sg== X-Received: by 10.68.203.66 with SMTP id ko2mr23004157pbc.156.1428900087469; Sun, 12 Apr 2015 21:41:27 -0700 (PDT) Received: from ?IPv6:2406:e007:695b:1:28cc:dc4c:9703:6781? ([2406:e007:695b:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id wn4sm4105138pac.16.2015.04.12.21.41.24 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Apr 2015 21:41:26 -0700 (PDT) Message-ID: <552B48F2.20206@gmail.com> Date: Mon, 13 Apr 2015 16:41:22 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Sheng Jiang , Michael Behringer References: <55219C7C.1050608@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F2DCE6@xmb-rcd-x14.cisco.com> <552875C0.8000609@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F4FDDE8@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B925F4FDDE8@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Anima WG Subject: Re: [Anima] Anima domain/node ID format question X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 04:41:29 -0000 On 13/04/2015 13:06, Sheng Jiang wrote: >> I'm extending this conversation to the list, with permission. The >> assumption here is that (regardless of how the ownership and security >> bootstrap dicussion ends up), the nodes in an autonomic network will be >> identified by a Node ID within a domain identified by a Domain ID. > > Allow me to be divergent a little bit. Why single domain ID? If an autonomic node can only have one domain ID, the domain management could be rigescent. Then we have to handle something, like domain mergence, renumbering, etc. If we decouple the node from its belonging domain, it means a node could have virtual ids that belong to different domain or group. Then, maybe we do not have to have group concept? Yes, I see no reason why a given node must be registered in only one domain. We certainly should not put such a restriction in the basic protocols. Regards Brian > Best regards, > > Sheng > >> Now read on... >> >> On 07/04/2015 18:57, Michael Behringer (mbehring) wrote: >>> Hi Brian, >>> >>> [sorry yesterday was a day off here] >>> >>> Inline... >>> >>>> -----Original Message----- >>>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >>>> Sent: 05 April 2015 22:35 >>>> To: Michael Behringer (mbehring); eckert.anima(mailer list); Liubing (Leo) >>>> Subject: Anima domain/node ID format question >>>> >>>> Hi, >>>> >>>> I'm asking this question to the anima-reference-model team first, but we >>>> can certainly expand the discussion to the WG if useful. >>>> >>>> I believe we have a concept that there will be an authenticated Domain ID >>>> for each AN domain, and an authenticated Node ID for each node in a >>>> domain. We're planning to remove the built-in security from GDNP, and >>>> require that GDNP must either operate within the ACP, or use (D)TLS if it >> for >>>> some reason is not running within the ACP. >>>> >>>> I suspect we will nevertheless want to keep a GDNP option to carry the >>>> {Domain ID, Node ID} pair - but even if we don't do this, the reference >>>> model will probably need to say something about them. >>> >>> I think it is clear that we MUST have a single domain and node ID in an >> autonomic network. No, "single" is wrong. We need a "lowest common >> denominator". There can (and will) be several forms of ID, that doesn't matter, >> what matters is that there is the one that's constant and that all nodes in the >> domain understand. >>> >>>> So, my question: should we define a single format for Domain ID and Node >>>> ID, or should they be versioned? >>> >>> In our approach we're using a single format for node ID and domain ID, but >> a versioned form for addressing. Reason is that the node ID and domain ID >> are not really structured, but addressing might well need to be. So, we need >> some flexibility there. >> >> I agree that the IDs may not be structured (from an external point of view) >> but might there not be different families of ID? >> >> For addressing, in GDNP we have locator options, currently of type IPv4, IPv6 >> and FQDN. Is that what you are thinking of, or something else? >> >>> We're planning on writing up our approach on addressing, for discussion, >> but it hasn't happened yet. >>> >>>> draft-pritikin does define a specific format of Domain ID. I'm not sure if >> any >>>> current draft defines a Node ID format, except for the material we plan to >>>> delete from GDNP. >>> >>> This (node ID, domain ID, address model) should probably go into the >> reference model. Thoughts? >> >> Yes, I think it belongs in the reference model, but since that is likely to >> end up Informational, we might need to put the format definitions, if needed, >> somewhere else. >> >> Brian >> >>> I suggest to take this to the list. Feel free to copy the list on your reply. >>> >>> Michael >>> >>>> Brian >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima From nobody Mon Apr 13 06:38:33 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D32C1A011B for ; Mon, 13 Apr 2015 06:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ck-uf6G5MzHu for ; Mon, 13 Apr 2015 06:38:23 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ECDE1A00FE for ; Mon, 13 Apr 2015 06:38:18 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D386FE1AC; Mon, 13 Apr 2015 09:49:17 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 7FF7463B76; Mon, 13 Apr 2015 09:38:16 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6A485636A2; Mon, 13 Apr 2015 09:38:16 -0400 (EDT) From: Michael Richardson To: Michael Behringer , Anima WG In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B925F4FDDE8@nkgeml512-mbx.china.huawei.com> References: <55219C7C.1050608@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F2DCE6@xmb-rcd-x14.cisco.com> <552875C0.8000609@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F4FDDE8@nkgeml512-mbx.china.huawei.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Anima] Anima domain/node ID format question X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 13:38:32 -0000 Sheng Jiang wrote: >> I'm extending this conversation to the list, with permission. The >> assumption here is that (regardless of how the ownership and security >> bootstrap dicussion ends up), the nodes in an autonomic network will be >> identified by a Node ID within a domain identified by a Domain ID. > Allow me to be divergent a little bit. Why single domain ID? If an > autonomic node can only have one domain ID, the domain management could > be rigescent. Then we have to handle something, like domain mergence, > renumbering, etc. If we decouple the node from its belonging domain, it > means a node could have virtual ids that belong to different domain or > group. Then, maybe we do not have to have group concept? I think we shouldn't try to boil the ocean dry before inventing electricity. I can buy the renumbering argument, but not really. I think that if there is a merge (or more accurately, an acquisition, therefore a transfer of ownership), then I think that it is acceptable, even required, that either the autonomic bootstrap occur again, or that the existing autonomic control plane is used to replace the LDevID. I think that re-initializing the autonomic control plane should never cause anything untoward to happen to the production network, so we don't need to worry about causing a flag day to the entire network. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Mon Apr 13 07:58:20 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB6A1ACC8C for ; Mon, 13 Apr 2015 07:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DquUMREZkd9t for ; Mon, 13 Apr 2015 07:58:16 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 990011ACC82 for ; Mon, 13 Apr 2015 07:58:16 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1CB33E1AC for ; Mon, 13 Apr 2015 11:09:16 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 2BA7163B76; Mon, 13 Apr 2015 10:58:15 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 16FCA636B6 for ; Mon, 13 Apr 2015 10:58:15 -0400 (EDT) From: Michael Richardson To: "anima\@ietf.org" In-Reply-To: <5529C150.8010500@gmail.com> References: <5511E12E.9050002@gmx.net> <77FA386512F0D748BC7C02C36EB1106D956D45@szxeml557-mbs.china.huawei.com> <7912.1427385447@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D95700F@szxeml557-mbs.china.huawei.com> <1F85BE1D-44A3-420A-8852-A4BA0DE213AC@cisco.com> <247ADDB2-807D-4AB5-A814-58381A929EB5@cisco.com> <551BC405.3070204@gridmerge.com> <77FA386512F0D748BC7C02C36EB1106D95C712@szxeml557-mbs.china.huawei.com> <93110A7A-4FD8-4D30-B833-5AC516B54BFB@cisco.com> <5526E134.7060208@gmail.com> <21336.1428616625@sandelman.ca> <5527106A.10106@gmail.com> <15763.1428681312@sandelman.ca> <24238.1428693167@sandelman.ca> <55282EA2.6070409@gmail.com> <4D76E559-9E91-434C-8B2D-CAFDE3EFB1B4@cisco.com> <5529620D .7010102@bogus.com> <9477.1428794235@sandelman.! ca> <5 529C150.8010500@gmail.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Anima] Ownership Concept X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 14:58:19 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> My claim is also that we should consider the entirely online, zero-touch >> situation, and consider the work-arounds for not being online as requiring a >> mitigation proceedure. > 1. The comments tagged above as max> were actually brian> > (and if everybody used the de facto standard quoting convention for plain > text email, we wouldn't have that confusion). My fault, trying to interpret a really long/deep thread with lots of stupid quoting. And... which standard would that be? :-) > 2. I do object to your choice of words ("work-around" and "mitigation"). They > are just alternative methods, which will be used for reasons that aren't > our business. I submit that our business is to make the Anima infrastructure > work equally well (and equally securely) in each case. I think it is useful to discuss why you don't like my words, and why I don't like the words: "alternatives methods", because I think that there could be something deeper here. As I see it, we are about to define a sequence of steps {A->B->C->D->E}, which leads to creation of a secure autonomic control plane, on which intents will be communicated, and resources distributed/allocated. I think that all devices need to be at a well defined step in this process, and it might be that we have to write some state machines that deal with how to go forward, backwards, and when factory reset is the only way forward, and when it must in fact be forbidden. As such, if devices arrive at step C via alternative methods, having never gone through steps A, and B, then there may be some things that we can not do in the process. Those alternative methods must now become documented and so really we now have a sequence that looks like: {(W->X->Y),(A->B)}->C->D->E. and we can not say, if D fails, go back to B, because maybe it arrived via X instead. So that's why I used the terms "mitigation" --- we will instead have a process that looks like: W Q v v A---> B ---> C Where W and Q are distinct ways of getting to A or B from scratch. If one arrives via W->A, then if we say, "go back to B", then it's clear one can do that. If one arrives via Q->B, then when one says, "go back to B", it might mean one has to go back to Q, and perform the step to get to B again. There is no path W->Q here. Q is a mitigation for the device (or morely the device's supply chain) not having the A step available. Maybe I'm being pedantic, and maybe I'm violently agreeing with Brian's intention, but not his words. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVSvZhoCLcPvd0N1lAQIRzggAniSGB9+lodHjwlaUStgWz7DkTzFuFynr lsB56YEMkcOvzblmJnQKeFWm1DoiPxoxYi5iLtnbc2kRbshQmwXL23Ufz1fAst8H 5X1dwWOwVcH5RyzGFXBcgBugrA0n1jGQJPIlG6P87UScA1HzLJo+DIPjahvK7hX5 0kG9/7n9yL6d7vYzUPV9W2D+c19Q9f3juxU4yLiQbsykxEniLlQcC4g9bhL81HYp ypDXp94nTFvjeSVZoWqnRCTrFD9gD8urIxT9pjjMAzoRzi0IgzaE01hnKFyoG1Sr S0L63OQ94HuWYuG12xUTpfTvaCF32ICjJFDss8QNzCa4M3UwbZqfWQ== =ELBD -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Apr 13 08:19:13 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A10341ACD70 for ; Mon, 13 Apr 2015 08:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9VAJ8orORfJ for ; Mon, 13 Apr 2015 08:19:10 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D96F1ACD6F for ; Mon, 13 Apr 2015 08:19:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2663; q=dns/txt; s=iport; t=1428938351; x=1430147951; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=E5r4g7TYbk01FdNrmxKw1u5u9DcmqvfLluDId1fWD2k=; b=mOdnUdLt7UxxWReoORDwGR721LPSru1YXiDENQs6bS/u3n4nU/S4Tg64 h78lKcD3S4VaxezmxOPMiHCEesCBwgd4Keya5Jq3xIoBt3fwJtBnY61Xm BWGEEGWVfi71ScwNximQtvbRB1uU8hJq8DbI3aVchNPTe49FmyZPE0Osl k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CWBQDZ3StV/51dJa1cgwxSXAXEJ4I5hgUCgTk7EQEBAQEBAQF9hB8BAQEEOksEAgEIEQQBAQEKFAkHMhQJCAIEAQkJCIgizQUBAQEBAQEBAQEBAQEBAQEBAQEBGYsrhEs4BoMRgRYFkQyeeyKDb2+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.11,570,1422921600"; d="scan'208";a="140776839" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-7.cisco.com with ESMTP; 13 Apr 2015 15:19:10 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t3DFJ9CK023830 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Apr 2015 15:19:09 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.189]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Mon, 13 Apr 2015 10:19:09 -0500 From: "Michael Behringer (mbehring)" To: "mcr@sandelman.ca" , Anima WG Thread-Topic: [Anima] Anima domain/node ID format question Thread-Index: AQHQb+AI2067fXfYcEu2MoTKLOY0Jp1BHlxAgAY/xgCAAyIrAIAA0fUA///H4GA= Date: Mon, 13 Apr 2015 15:19:08 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22F402F1@xmb-rcd-x14.cisco.com> References: <55219C7C.1050608@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F2DCE6@xmb-rcd-x14.cisco.com> <552875C0.8000609@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F4FDDE8@nkgeml512-mbx.china.huawei.com> <25755.1428932296@sandelman.ca> In-Reply-To: <25755.1428932296@sandelman.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.133] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Anima domain/node ID format question X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 15:19:12 -0000 I tend to agree with Michael here. To me, a device belongs to someone, ulti= mately. There can only be one ultimate owner, and ultimate source of truth.= Now that doesn't prevent for example shared management, where another enti= ty is managing a sub-part of the device (or maybe even the entire device fo= r a period of time). But there is always one "real" owner at a time. And I would suggest for now to keep it simple, if a device changes hands, i= t enrols again.=20 Before embarking on a more complex story line, I'd like to understand which= model we can't reasonably solve with the above assumption?=20 Michael > -----Original Message----- > From: mcr@sandelman.ca [mailto:mcr@sandelman.ca] > Sent: 13 April 2015 15:38 > To: Michael Behringer (mbehring); Anima WG > Subject: Re: [Anima] Anima domain/node ID format question >=20 >=20 > Sheng Jiang wrote: > >> I'm extending this conversation to the list, with permission. The > >> assumption here is that (regardless of how the ownership and secur= ity > >> bootstrap dicussion ends up), the nodes in an autonomic network wi= ll > be > >> identified by a Node ID within a domain identified by a Domain ID. >=20 > > Allow me to be divergent a little bit. Why single domain ID? If an > > autonomic node can only have one domain ID, the domain management > could > > be rigescent. Then we have to handle something, like domain > mergence, > > renumbering, etc. If we decouple the node from its belonging domain= , it > > means a node could have virtual ids that belong to different domain= or > > group. Then, maybe we do not have to have group concept? >=20 > I think we shouldn't try to boil the ocean dry before inventing electrici= ty. > I can buy the renumbering argument, but not really. I think that if ther= e is a > merge (or more accurately, an acquisition, therefore a transfer of > ownership), then I think that it is acceptable, even required, that eithe= r the > autonomic bootstrap occur again, or that the existing autonomic control > plane is used to replace the LDevID. >=20 > I think that re-initializing the autonomic control plane should never cau= se > anything untoward to happen to the production network, so we don't need > to worry about causing a flag day to the entire network. >=20 > -- > ] Never tell me the odds! | ipv6 mesh netwo= rks [ > ] Michael Richardson, Sandelman Software Works | network archite= ct [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails= [ >=20 From nobody Mon Apr 13 08:34:17 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 616F11ACD90 for ; Mon, 13 Apr 2015 08:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnsA3I7tTyEJ for ; Mon, 13 Apr 2015 08:34:13 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95F2D1ACD08 for ; Mon, 13 Apr 2015 08:34:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3851; q=dns/txt; s=iport; t=1428939254; x=1430148854; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ko+84+fskD4eiXCMHgF8+Nv8xzMhKTUnDuPl1QDPw7w=; b=btQkVRclIF/qPyPghBNTvGe2k+eFDribafJkuzXjmyaEp/34AI0nNRbN P7i6hIkqV4E7MZQ73M+RCmyJYgw4V4q+klZAjfeHoj1opUaugtyd+HUM5 WBTAEWerpTO0U5LM4HUJ+PqYcIfInbUFTe7XHmCdK07WD8A9u1Wvtr0r6 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BvBQCj4StV/4ENJK1cgwxSXAXGWgqGAQKBOTsRAQEBAQEBAX2EHwEBAQMBAQEBawsFCwIBCA4KLicLJQIECgQFiCIIDcx+AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4srhEkzB4MXgRYFkQyKD4EdjEWHCiKDb2+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.11,570,1422921600"; d="scan'208";a="140780756" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-2.cisco.com with ESMTP; 13 Apr 2015 15:34:13 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t3DFYCD5003366 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Apr 2015 15:34:12 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.90]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Mon, 13 Apr 2015 10:34:12 -0500 From: "Max Pritikin (pritikin)" To: Michael Richardson Thread-Topic: [Anima] Anima domain/node ID format question Thread-Index: AQHQc/UMZDAMqZxDo0i8toMr6ww3zJ1KeCMAgADR9QCAACBjgA== Date: Mon, 13 Apr 2015 15:34:11 +0000 Message-ID: References: <55219C7C.1050608@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F2DCE6@xmb-rcd-x14.cisco.com> <552875C0.8000609@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F4FDDE8@nkgeml512-mbx.china.huawei.com> <25755.1428932296@sandelman.ca> In-Reply-To: <25755.1428932296@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.232.82] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Anima WG , "Michael Behringer \(mbehring\)" Subject: Re: [Anima] Anima domain/node ID format question X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 15:34:15 -0000 On Apr 13, 2015, at 7:38 AM, Michael Richardson wrote: >=20 > Sheng Jiang wrote: >>> I'm extending this conversation to the list, with permission. The >>> assumption here is that (regardless of how the ownership and security >>> bootstrap dicussion ends up), the nodes in an autonomic network will be >>> identified by a Node ID within a domain identified by a Domain ID. >=20 >> Allow me to be divergent a little bit. Why single domain ID? If an >> autonomic node can only have one domain ID, the domain management could >> be rigescent. Then we have to handle something, like domain mergence, >> renumbering, etc. If we decouple the node from its belonging domain, it >> means a node could have virtual ids that belong to different domain or >> group. Then, maybe we do not have to have group concept? >=20 > I think we shouldn't try to boil the ocean dry before inventing electrici= ty. > I can buy the renumbering argument, but not really. I think that if ther= e is > a merge (or more accurately, an acquisition, therefore a transfer of > ownership), then I think that it is acceptable, even required, that eithe= r > the autonomic bootstrap occur again, All models for autonomic bootstrapping so far include the device trusting t= he vendor =93more than=94 anything locally. This makes total sense when the= local trust anchor is completely untrusted. But if the local trust anchor = *is* known my default thinking has been that this 'overrides=92 some or all= aspects of the vendor trust anchor. Therefore we can=92t do autonomic boot= strapping a second time without returning the device to factory default whi= ch also requires some sort of physical proof of possession. Mandating this = sort of behavior protects the current owner of the device from any compromi= sed vendor trust anchor. The side effect is that physical possession proofs are required if the curr= ent owner loses their own trust anchors. Which do you feel is the better ch= oice?=20 > or that the existing autonomic control > plane is used to replace the LDevID. I think for the normal transition model when keys are not lost or compromis= ed this makes sense to me. Implemented either as an =93autonomic bootstrapp= ing=94 but where the current owner trust anchor takes the place of the vend= or (thus acceptable to occur w/o physical proof of possession) or implement= ed as an update to the devices trust anchor using the normal key management= methods.=20 > I think that re-initializing the autonomic control plane should never cau= se > anything untoward to happen to the production network, so we don't need t= o > worry about causing a flag day to the entire network. In the PKI space one can extend the trust anchor chain to a =93new=94 trust= anchor in a rolling (non-flag-day) fashion using the mechanism detailed in= EST RFC7030 section 4.1.3 CA Certificate Response and from CMP RFC4210 sec= tion 4.1.1. Rolling over from an old CA trust anchor to a new CA trust anch= or sounds exactly like rolling over from an old owner to a new owner (to me= ) and would be the first place I=92d look to for insight on how to deal wit= h an acquired AN domain. This rollover could occur either at the normal tra= nsition cycle when the first keys are expiring or it could be prematurely t= riggered via a TBD mechanism.=20 - max >=20 > -- > ] Never tell me the odds! | ipv6 mesh netwo= rks [ > ] Michael Richardson, Sandelman Software Works | network archite= ct [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails= [ >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Mon Apr 13 13:23:41 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E13B01A3BA4 for ; Mon, 13 Apr 2015 13:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OY9R3FTpUIyU for ; Mon, 13 Apr 2015 13:23:38 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 192211A3B9B for ; Mon, 13 Apr 2015 13:23:38 -0700 (PDT) Received: by pdbqd1 with SMTP id qd1so5762829pdb.2 for ; Mon, 13 Apr 2015 13:23:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Fk4TgQiAuwIfGWrf0q9lVlvbkR9SMH4UbiuMNjWWIL8=; b=rSpUzf9rBDLrRcFcQ/m+EFkhzvH1SSnNtaLV/+IPhktt+ZG1kU08oYyx6kViH+O3y2 FCXY7zqwQDxkCSvve/Y5M2NafRWJEnOkvTZNDFl1E+4gmGYof2bNZ8Zy31muqBFw+d7c 6y4e9GGQ8kyq2zWTkUP2xTdLLRoQc8G4szHshHwE+1S0IK6YZSLT8NTlXzlMbe5k/W4g 7HeOLl6Xpp38e7JVu1gTBkt1gt0qLCYmMvnsE7J/GZhCvBQiZRl2i+PFwaCxem+Y/yTg Ibr2DuJcEL+UI4kRlzXqi/jPtoA8zlXN4TgEAsOvWGhzstF9sotBtI3W1516caxpL9Ct ANJA== X-Received: by 10.68.239.65 with SMTP id vq1mr29810194pbc.49.1428956617806; Mon, 13 Apr 2015 13:23:37 -0700 (PDT) Received: from ?IPv6:2406:e007:474a:1:28cc:dc4c:9703:6781? ([2406:e007:474a:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id ef15sm8212170pad.38.2015.04.13.13.23.34 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Apr 2015 13:23:36 -0700 (PDT) Message-ID: <552C25C6.4040307@gmail.com> Date: Tue, 14 Apr 2015 08:23:34 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Michael Richardson , Michael Behringer , Anima WG References: <55219C7C.1050608@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F2DCE6@xmb-rcd-x14.cisco.com> <552875C0.8000609@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F4FDDE8@nkgeml512-mbx.china.huawei.com> <25755.1428932296@sandelman.ca> In-Reply-To: <25755.1428932296@sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Anima domain/node ID format question X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 20:23:40 -0000 On 14/04/2015 01:38, Michael Richardson wrote: > > Sheng Jiang wrote: > >> I'm extending this conversation to the list, with permission. The > >> assumption here is that (regardless of how the ownership and security > >> bootstrap dicussion ends up), the nodes in an autonomic network will be > >> identified by a Node ID within a domain identified by a Domain ID. > > > Allow me to be divergent a little bit. Why single domain ID? If an > > autonomic node can only have one domain ID, the domain management could > > be rigescent. Then we have to handle something, like domain mergence, > > renumbering, etc. If we decouple the node from its belonging domain, it > > means a node could have virtual ids that belong to different domain or > > group. Then, maybe we do not have to have group concept? > > I think we shouldn't try to boil the ocean dry before inventing electricity. > I can buy the renumbering argument, but not really. I think that if there is > a merge (or more accurately, an acquisition, therefore a transfer of > ownership), then I think that it is acceptable, even required, that either > the autonomic bootstrap occur again, or that the existing autonomic control > plane is used to replace the LDevID. Oh, I understood Sheng to be intending something quite different. A large network (many thousands of nodes) might need some administrative sub-structure of domains, and an autonomic device might need to be trusted in more than one of those domains. Think about Venn diagrams of overlapping domains. > I think that re-initializing the autonomic control plane should never cause > anything untoward to happen to the production network, so we don't need to > worry about causing a flag day to the entire network. That's a good goal, but I don't see the connection. Brian From nobody Mon Apr 13 13:41:04 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02CE01A6F30 for ; Mon, 13 Apr 2015 13:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G52CWRJqUpqd for ; Mon, 13 Apr 2015 13:41:02 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1473C1A6F2E for ; Mon, 13 Apr 2015 13:41:02 -0700 (PDT) Received: by pacyx8 with SMTP id yx8so113688881pac.1 for ; Mon, 13 Apr 2015 13:41:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Rpg1r2dQgNiT/X20Us4i2fQzh+Lfsb50ogaaU7Orn/s=; b=P5j9SNBRvQhryYglDkDDw5eZMlvRBjf/fGTtSlP0CJL4mlnd+ccg2avjDUPtN177IM nzWwp4cenHorU/MXBE0E2vzFIGbdeU4fzVqZ34DdWxBvTz6Ydbz47nyunljkO3DBJHmC OonAR9B9tljJs9UR6Df5ejhOFG+ZkfoG3TR2Z+aqUbjPmt2fAfN0i/ZuMjvL8lJklJY3 TLo1JWHfYlTDK7N+eRFK6/iZfxZFuRYVw8PqtadCZI1Kw0K/gc5Q+mEGZHBmNKlK9FA8 52mLwseaZFVDoaawB2nfRXyZvQVvdG8/Z1yQKNw9dyljEnxcJGqXlWRf3M4Gjzi4kHy9 F36w== X-Received: by 10.70.35.6 with SMTP id d6mr29495136pdj.166.1428957661682; Mon, 13 Apr 2015 13:41:01 -0700 (PDT) Received: from ?IPv6:2406:e007:474a:1:28cc:dc4c:9703:6781? ([2406:e007:474a:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id fu7sm8229831pac.26.2015.04.13.13.40.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Apr 2015 13:41:00 -0700 (PDT) Message-ID: <552C29DA.50501@gmail.com> Date: Tue, 14 Apr 2015 08:40:58 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Michael Richardson , "anima@ietf.org" References: <5511E12E.9050002@gmx.net> <7912.1427385447@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D95700F@szxeml557-mbs.china.huawei.com> <1F85BE1D-44A3-420A-8852-A4BA0DE213AC@cisco.com> <247ADDB2-807D-4AB5-A814-58381A929EB5@cisco.com> <551BC405.3070204@gridmerge.com> <77FA386512F0D748BC7C02C36EB1106D95C712@szxeml557-mbs.china.huawei.com> <93110A7A-4FD8-4D30-B833-5AC516B54BFB@cisco.com> <5526E134.7060208@gmail.com> <21336.1428616625@sandelman.ca> <5527106A.10106@gmail.com> <15763.1428681312@sandelman.ca> <24238.1428693167@sandelman.ca> <55282EA2.6070409@gmail.com> <4D76E559-9E91-434C-8B2D-CAFDE3EFB1B4@cisco.com> <5529620D .7010102@bogus.com> <9477.1428794235@sandelman.! ca> <5 529C150.8010500@gmail.com> <10862.1428937095@sandelman.ca> In-Reply-To: <10862.1428937095@sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Ownership Concept X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 20:41:04 -0000 On 14/04/2015 02:58, Michael Richardson wrote: > > Brian E Carpenter wrote: > >> My claim is also that we should consider the entirely online, zero-touch > >> situation, and consider the work-arounds for not being online as requiring a > >> mitigation proceedure. > > > 1. The comments tagged above as max> were actually brian> > > (and if everybody used the de facto standard quoting convention for plain > > text email, we wouldn't have that confusion). > > My fault, trying to interpret a really long/deep thread with lots of stupid quoting. > And... which standard would that be? :-) I wonder about that myself, but I think that >>> came from Berkeley mail. > > 2. I do object to your choice of words ("work-around" and "mitigation"). They > > are just alternative methods, which will be used for reasons that aren't > > our business. I submit that our business is to make the Anima infrastructure > > work equally well (and equally securely) in each case. > > I think it is useful to discuss why you don't like my words, and why I don't > like the words: "alternatives methods", because I think that there could be > something deeper here. > > As I see it, we are about to define a sequence of steps {A->B->C->D->E}, which > leads to creation of a secure autonomic control plane, on which intents will > be communicated, and resources distributed/allocated. > > I think that all devices need to be at a well defined step in this process, and > it might be that we have to write some state machines that deal with how to > go forward, backwards, and when factory reset is the only way forward, and > when it must in fact be forbidden. > > As such, if devices arrive at step C via alternative methods, having never gone > through steps A, and B, then there may be some things that we can not do in > the process. Those alternative methods must now become documented and so > really we now have a sequence that looks like: > > {(W->X->Y),(A->B)}->C->D->E. > > and we can not say, if D fails, go back to B, because maybe it arrived via X > instead. So that's why I used the terms "mitigation" --- we will instead > have a process that looks like: > > W Q > v v > A---> B ---> C > > Where W and Q are distinct ways of getting to A or B from scratch. If one > arrives via W->A, then if we say, "go back to B", then it's clear one can do > that. If one arrives via Q->B, then when one says, "go back to B", it might > mean one has to go back to Q, and perform the step to get to B again. > > There is no path W->Q here. Q is a mitigation for the device (or morely the > device's supply chain) not having the A step available. Maybe I'm being > pedantic, and maybe I'm violently agreeing with Brian's intention, but not > his words. Indeed, we mainly agree. There is a point at which a device has been enrolled with the relevant CA, and after that all devices are equally trustworthy. There are several ways to get to that point. I think we're arguing about whether one of those ways should be regarded as canonical. Operationally, of course, it would be much better if there was only one way, but in the real world that won't happen. Brian From nobody Mon Apr 13 17:06:17 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B10921B2A09 for ; Mon, 13 Apr 2015 17:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41zGlQq7PzNB for ; Mon, 13 Apr 2015 17:06:15 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4CB71B2A02 for ; Mon, 13 Apr 2015 17:06:14 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 12F75E1AE for ; Mon, 13 Apr 2015 20:17:16 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id AB73563B76; Mon, 13 Apr 2015 20:06:13 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 96312636A2 for ; Mon, 13 Apr 2015 20:06:13 -0400 (EDT) From: Michael Richardson To: Anima WG In-Reply-To: <552C25C6.4040307@gmail.com> References: <55219C7C.1050608@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F2DCE6@xmb-rcd-x14.cisco.com> <552875C0.8000609@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F4FDDE8@nkgeml512-mbx.china.huawei.com> <25755.1428932296@sandelman.ca> <552C25C6.4040307@gmail.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Anima] Anima domain/node ID format question X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 00:06:16 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> I think we shouldn't try to boil the ocean dry before inventing electricity. >> I can buy the renumbering argument, but not really. I think that if there is >> a merge (or more accurately, an acquisition, therefore a transfer of >> ownership), then I think that it is acceptable, even required, that either >> the autonomic bootstrap occur again, or that the existing autonomic control >> plane is used to replace the LDevID. > Oh, I understood Sheng to be intending something quite different. > A large network (many thousands of nodes) might need some administrative > sub-structure of domains, and an autonomic device might need to be trusted > in more than one of those domains. Think about Venn diagrams of overlapping > domains. It seems to me that if it needs to be trusted in more than one domain than that either calls for a domain that contains everything as the trust anchor, (so it's not overlapping that we care about, but sub-domains), or we need to have cross-domain trust. I don't know what it means for a device to be trusted by a domain, but I guess, not administrated by that domain. As long as there is a >> I think that re-initializing the autonomic control plane should never cause >> anything untoward to happen to the production network, so we don't need to >> worry about causing a flag day to the entire network. > That's a good goal, but I don't see the connection. (re)numbering can mean rebooting the autonomic bootstrap process. If you can do that without affecting what the devices are supposed to be doing, then you can renumber or re-trust-bootstrap the nodes as often as you wish. (In this case, I had assumed they are routers, and routing packets in a production network is what they are supposed to be doing) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVSxZ9YCLcPvd0N1lAQL1AQf/acBNTSyNssJ6ERzk1X8hB43pBnqMHJgK 2dm9uj8ekDZxW0GjuiQurFemHgOW8LyqFbu6HbpzeDn6LCem0vkW+8rmT2GWZw5Y GZdzvI9IgzwAoAtNHrhPHU/KaaZhaX0MD7n1VEZyzaxfwZrucEgd9AmgVJxKOkbM gImy/ms4Gr5457mPepfILEw6tkDKLpK3P3LVj0yD3aFVB2J8ayhntIzcPJRpn1+i ptbYls10gh+1KqA9VXWpGMNAe/7bYAl/5ZYFI2ruCJSo1ZmzDY6XUwnx+Py99Jyu NCSFqbr7RxNwxGr2fWLhoTbaYAsBbj6I9G+5RDNex2khhuEynEgfhQ== =YrpL -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Apr 14 00:28:04 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E141B34C1 for ; Tue, 14 Apr 2015 00:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ag3jAIri0Mz for ; Tue, 14 Apr 2015 00:28:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76B101B34C2 for ; Tue, 14 Apr 2015 00:28:01 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRJ18040; Tue, 14 Apr 2015 07:28:00 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 14 Apr 2015 08:27:58 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.135]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Tue, 14 Apr 2015 15:27:52 +0800 From: Sheng Jiang To: Brian E Carpenter , Michael Richardson , Michael Behringer , Anima WG Thread-Topic: [Anima] Anima domain/node ID format question Thread-Index: AQHQc/ULSeLRxwNrLECNjpvkEvwdE51KIn6ggABNrACAAHE9AIABNeng Date: Tue, 14 Apr 2015 07:27:50 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B925F500A8B@nkgeml512-mbx.china.huawei.com> References: <55219C7C.1050608@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F2DCE6@xmb-rcd-x14.cisco.com> <552875C0.8000609@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F4FDDE8@nkgeml512-mbx.china.huawei.com> <25755.1428932296@sandelman.ca> <552C25C6.4040307@gmail.com> In-Reply-To: <552C25C6.4040307@gmail.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.197] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] Anima domain/node ID format question X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 07:28:03 -0000 SSBiZWxpZXZlIHdlIHdlcmUgdGFsa2luZyBhYm91dCB0d28gZGlmZmVyZW50IGNvbmNlcHRzIG9m IGRvbWFpbjogYSkgZG9tYWluIGZvciB0aGUgZGV2aWNlIG93bmVyc2hpcCwgYikgZG9tYWlucyBm b3IgbmV0d29yayBhZG1pbmlzdHJhdGl2ZSBwdXJwb3NlLiBJIHdhcyBqdW1wIHRoaW5raW5nIHRo ZSBsYXR0ZXIgd2hpbGUgeW91IHByb2JhYmx5IGZvY3VzZWQgb24gdGhlIGZvcm1lci4gSSB3YXMg dGhpbmtpbmcgd2hldGhlciB0aGV5IHR3byBjb25jZXB0cyBjb3VsZCByZXVzZSB0aGUgc2FtZSBk b21haW4gSUQuIEFjY29yZGluZyB0byB0aGUgZGlzY3Vzc2lvbiwgaXQgc2VlbXMgYSBzaW5nbGUg ZG9tYWluIElEIGRlZGljYXRlZCBmb3Igb3duZXJzaGlwIGlzIGdvb2QuIFRoZW4sIHdlIG1heSBj b21lIGJhY2sgdG8gc29tZXRoaW5nIGxpa2UgZ3JvdXAgSURzIGxhdGVyIHRvIGZ1bGZpbGwgdGhl IHJlcXVpcmVtZW50cyBvZiBhZG1pbmlzdHJhdGl2ZSBkb21haW5zIGFuZCBwdXJwb3NlIHdpdGhp biBhIHNhbWUgYXV0b25vbWljIG5ldHdvcmsuDQoNCkJlc3QgcmVnYXJkcywNCg0KU2hlbmcNCg0K Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogQW5pbWEgW21haWx0bzphbmltYS1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQnJpYW4gRQ0KPkNhcnBlbnRlcg0KPlNlbnQ6 IFR1ZXNkYXksIEFwcmlsIDE0LCAyMDE1IDQ6MjQgQU0NCj5UbzogTWljaGFlbCBSaWNoYXJkc29u OyBNaWNoYWVsIEJlaHJpbmdlcjsgQW5pbWEgV0cNCj5TdWJqZWN0OiBSZTogW0FuaW1hXSBBbmlt YSBkb21haW4vbm9kZSBJRCBmb3JtYXQgcXVlc3Rpb24NCj4NCj5PbiAxNC8wNC8yMDE1IDAxOjM4 LCBNaWNoYWVsIFJpY2hhcmRzb24gd3JvdGU6DQo+Pg0KPj4gU2hlbmcgSmlhbmcgPGppYW5nc2hl bmdAaHVhd2VpLmNvbT4gd3JvdGU6DQo+PiAgICAgPj4gSSdtIGV4dGVuZGluZyB0aGlzIGNvbnZl cnNhdGlvbiB0byB0aGUgbGlzdCwgd2l0aCBwZXJtaXNzaW9uLiBUaGUNCj4+ICAgICA+PiBhc3N1 bXB0aW9uIGhlcmUgaXMgdGhhdCAocmVnYXJkbGVzcyBvZiBob3cgdGhlIG93bmVyc2hpcCBhbmQN Cj5zZWN1cml0eQ0KPj4gICAgID4+IGJvb3RzdHJhcCBkaWN1c3Npb24gZW5kcyB1cCksIHRoZSBu b2RlcyBpbiBhbiBhdXRvbm9taWMgbmV0d29yaw0KPndpbGwgYmUNCj4+ICAgICA+PiBpZGVudGlm aWVkIGJ5IGEgTm9kZSBJRCB3aXRoaW4gYSBkb21haW4gaWRlbnRpZmllZCBieSBhIERvbWFpbiBJ RC4NCj4+DQo+PiAgICAgPiBBbGxvdyBtZSB0byBiZSBkaXZlcmdlbnQgYSBsaXR0bGUgYml0LiBX aHkgc2luZ2xlIGRvbWFpbiBJRD8gSWYgYW4NCj4+ICAgICA+IGF1dG9ub21pYyBub2RlIGNhbiBv bmx5IGhhdmUgb25lIGRvbWFpbiBJRCwgdGhlIGRvbWFpbg0KPm1hbmFnZW1lbnQgY291bGQNCj4+ ICAgICA+IGJlIHJpZ2VzY2VudC4gVGhlbiB3ZSBoYXZlIHRvIGhhbmRsZSBzb21ldGhpbmcsIGxp a2UgZG9tYWluDQo+bWVyZ2VuY2UsDQo+PiAgICAgPiByZW51bWJlcmluZywgZXRjLiBJZiB3ZSBk ZWNvdXBsZSB0aGUgbm9kZSBmcm9tIGl0cyBiZWxvbmdpbmcNCj5kb21haW4sIGl0DQo+PiAgICAg PiBtZWFucyBhIG5vZGUgY291bGQgaGF2ZSB2aXJ0dWFsIGlkcyB0aGF0IGJlbG9uZyB0byBkaWZm ZXJlbnQgZG9tYWluDQo+b3INCj4+ICAgICA+IGdyb3VwLiBUaGVuLCBtYXliZSB3ZSBkbyBub3Qg aGF2ZSB0byBoYXZlIGdyb3VwIGNvbmNlcHQ/DQo+Pg0KPj4gSSB0aGluayB3ZSBzaG91bGRuJ3Qg dHJ5IHRvIGJvaWwgdGhlIG9jZWFuIGRyeSBiZWZvcmUgaW52ZW50aW5nIGVsZWN0cmljaXR5Lg0K Pj4gSSBjYW4gYnV5IHRoZSByZW51bWJlcmluZyBhcmd1bWVudCwgYnV0IG5vdCByZWFsbHkuICBJ IHRoaW5rIHRoYXQgaWYgdGhlcmUgaXMNCj4+IGEgbWVyZ2UgKG9yIG1vcmUgYWNjdXJhdGVseSwg YW4gYWNxdWlzaXRpb24sIHRoZXJlZm9yZSBhIHRyYW5zZmVyIG9mDQo+PiBvd25lcnNoaXApLCB0 aGVuIEkgdGhpbmsgdGhhdCBpdCBpcyBhY2NlcHRhYmxlLCBldmVuIHJlcXVpcmVkLCB0aGF0IGVp dGhlcg0KPj4gdGhlIGF1dG9ub21pYyBib290c3RyYXAgb2NjdXIgYWdhaW4sIG9yIHRoYXQgdGhl IGV4aXN0aW5nIGF1dG9ub21pYw0KPmNvbnRyb2wNCj4+IHBsYW5lIGlzIHVzZWQgdG8gcmVwbGFj ZSB0aGUgTERldklELg0KPg0KPk9oLCBJIHVuZGVyc3Rvb2QgU2hlbmcgdG8gYmUgaW50ZW5kaW5n IHNvbWV0aGluZyBxdWl0ZSBkaWZmZXJlbnQuDQo+QSBsYXJnZSBuZXR3b3JrIChtYW55IHRob3Vz YW5kcyBvZiBub2RlcykgbWlnaHQgbmVlZCBzb21lIGFkbWluaXN0cmF0aXZlDQo+c3ViLXN0cnVj dHVyZSBvZiBkb21haW5zLCBhbmQgYW4gYXV0b25vbWljIGRldmljZSBtaWdodCBuZWVkIHRvIGJl IHRydXN0ZWQNCj5pbiBtb3JlIHRoYW4gb25lIG9mIHRob3NlIGRvbWFpbnMuIFRoaW5rIGFib3V0 IFZlbm4gZGlhZ3JhbXMgb2YNCj5vdmVybGFwcGluZw0KPmRvbWFpbnMuDQo+DQo+PiBJIHRoaW5r IHRoYXQgcmUtaW5pdGlhbGl6aW5nIHRoZSBhdXRvbm9taWMgY29udHJvbCBwbGFuZSBzaG91bGQg bmV2ZXIgY2F1c2UNCj4+IGFueXRoaW5nIHVudG93YXJkIHRvIGhhcHBlbiB0byB0aGUgcHJvZHVj dGlvbiBuZXR3b3JrLCBzbyB3ZSBkb24ndCBuZWVkDQo+dG8NCj4+IHdvcnJ5IGFib3V0IGNhdXNp bmcgYSBmbGFnIGRheSB0byB0aGUgZW50aXJlIG5ldHdvcmsuDQo+DQo+VGhhdCdzIGEgZ29vZCBn b2FsLCBidXQgSSBkb24ndCBzZWUgdGhlIGNvbm5lY3Rpb24uDQo+DQo+ICAgIEJyaWFuDQo+DQo+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5BbmltYSBt YWlsaW5nIGxpc3QNCj5BbmltYUBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vYW5pbWENCg== From nobody Tue Apr 14 11:32:13 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 895311A8A9A for ; Tue, 14 Apr 2015 11:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.811 X-Spam-Level: X-Spam-Status: No, score=-11.811 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eLv4GolCR5h for ; Tue, 14 Apr 2015 11:32:09 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A0321A8A59 for ; Tue, 14 Apr 2015 11:32:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6329; q=dns/txt; s=iport; t=1429036329; x=1430245929; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4hJ6vM9Cxfxx4uBkaql0N6m2gEWZ6kPKRhXcVXaC7MU=; b=DeRPyAvSy+YGRLvN+Nfgjq4+ZjYx/mhiIUaLtVZAM7nf+8CSkzNecvTu wnGWnaZ5JQVRcvNyYhcZYyuXBXah+34y/ZzE1mSD4GOhwqgpTk2Pa+D6L tAL5HPfgYger07A9s1bL7CiVWCbX7L3lfRtNL74Cb7KVZJm0Gn+DTrBLu M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AXBQCLXC1V/5xdJa1cgwxSXAXNPgKBSEwBAQEBAQF+hCABAQMBdAUFCwIBCA44MiUCBA4FG4gHCMxNAQEBAQEBAQEBAQEBAQEBAQEBARmLK4QPIhgzB4MXgRYBBIYmimiGJYNsjAuIYSKCAxyBUG+BCzl/AQEB X-IronPort-AV: E=Sophos;i="5.11,577,1422921600"; d="scan'208";a="411774308" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 14 Apr 2015 18:32:08 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t3EIW8Kg004291 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Apr 2015 18:32:08 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.90]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Tue, 14 Apr 2015 13:32:08 -0500 From: "Max Pritikin (pritikin)" To: Kent Watsen Thread-Topic: [Anima] Ownership Concept Thread-Index: AQHQZn+Wm4eAxWuLS02QOiRijuPZe50siH6AgAErG4CAAORAgIAAqhaAgAAKs4CAAAlUAIAAbsyA///G6uSAA1+gAIACsoiAgAKxFICADBw9AIABC7AAgAAXzACAABhtgIAAH9sAgAENXQCAAAikgIAALpGAgAAQoQCAAAfigIAAOQuAgAXsYgA= Date: Tue, 14 Apr 2015 18:32:07 +0000 Message-ID: References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> <5512DE41.6030209@gmail.com> <77FA386512F0D748BC7C02C36EB1106D956D45@szxeml557-mbs.china.huawei.com> <7912.1427385447@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D95700F@szxeml557-mbs.china.huawei.com> <1F85BE1D-44A3-420A-8852-A4BA0DE213AC@cisco.com> <247ADDB2-807D-4AB5-A814-58381A929EB5@cisco.com> <551BC405.3070204@gridmerge.com> <77FA386512F0D748BC7C02C36EB1106D95C712@szxeml557-mbs.china.huawei.com> <93110A7A-4FD8-4D30-B833-5AC516B54BFB@cisco.com> <5526E134.7060208@gmail.com> <21336.1428616625@sandelman.ca> <5527106A.10106@gmail.com> <15763.1428681312@sandelman.ca> <24238.1428693167@sandelman.ca> <55282EA2.6070409@gmail.com> <4D76E559-9E91-434C-8B2D-CAFDE3EFB1B4@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.232.82] Content-Type: text/plain; charset="Windows-1252" Content-ID: <09B088C04429684FA3561E2066E1A862@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Michael Richardson , "anima@ietf.org" Subject: Re: [Anima] Ownership Concept X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 18:32:11 -0000 On Apr 10, 2015, at 6:04 PM, Kent Watsen wrote: >=20 >=20 >> I personally disagree with the assertion that somebody with physical >> possession of the device in factory default state should be able to =B3t= ake >> ownership=B2 of the device without engaging with the vendor/cloud servic= e. >=20 > I agree emphatically. >=20 >=20 >> I understand that there is a long history of this model and folks are >> reluctant to give it up =8B so I expect that we=B9ll have to deal with i= t for >> a short while longer. I think a pragmatic position is to declare such >> activities as out-of-scope since they=B9re clearly NOT a zero touch mode= l. >> This would avoid needing to weaken the zero-touch threat model to deal >> with an inherently problematic use case. >=20 > Also agree. A device that has been pre-staged (manually configured) is n= o > longer at factory default and hence no bootstrapping process will occur. >=20 > As a corollary to this, in order to thwart interdiction attacks, > installers should always factory reset equipment as the first step to the > bootstrapping process. >=20 >=20 >> The only ways I know to mitigate that threat are to use TCG style >> measured boot with remote attestation. This is something I agree with bu= t >> since it requires hardware=8A I think the best approach is to layer that >> level of security on top of whatever inline zero-touch protocols we come >> up with (e.g. declare it out-of-scope here since the mitigation is also >> out-of-scope). >=20 > Agreed. The only pragmatic mitigation to interdiction is the TCG measure= d > boot with remote attestation, but even then it's defeatable with enough > determination and resources. For that matter, an IDevID can only be > trusted if an HSM like a TPM is used. >=20 > IMO, equipment without said protections are laughably insecure. If we > were to introduce levels is security, it might look like: >=20 > Unprotected HSM-protocted TPM-protected > IDevID IDevID secure boot > ----------- ------------- ------------- > Gold : x x > Silver : x > Bronze : x >=20 >=20 > Bronze-level equipment can implement the bootstrapping protocol, but > they're not suitable for critical deployments. >=20 >=20 > Swinging the conversation around, it seems that the two proposals readout > like this (hopefully it's a fair and accurate assessment): >=20 >=20 > NETCONF Zero-touch > ------------------ >=20 > What: An offline process whereby a vendor (or delegate) signs a voucher > that allows an owner to sign the bootstrapping data. >=20 > Pros: Addresses the problem directly (e.g., owners, vouchers, etc.) > How bootstrapping data is accessed doesn't matter (http, usb, nfc, > etc.) > No degradation in security when deployed on private networks. > Results in configuration (not just keys) >=20 > Cons: It will be difficult to track ownership through some supply chains >=20 >=20 >=20 > Bootstrapping Keyinfra > ---------------------- >=20 > What: An online process whereby a vendor (or delegate) signs a voucher > indicating that it is okay with the device joining the domain. >=20 > Pros: Avoids supply-chain tracking issues. >=20 > Cons: Unclear security guarantees provided by local policies. I was under the impression that the local policies _should_ be able to set = the security guarantees =97 this this characteristic is a =93pro=94. :)=20 > Security degraded on private networks. I=92m not following this assertion. How is security degraded on a private n= etworks? What is the threat you are thinking of and how is it mitigated by = the netconf zero-touch approach?=20 >=20 > Also, both solutions rely on the device proving itself to the network > using an IDevID. For Zero-touch, the IDevID is only used after the devic= e > has processed the bootstrapping data (e.g., it's configured to call home)= . In the early version draft-kwatsen-netconf-zerotouch-01 uses the IDevID ear= ly on:=20 "When the device is accessing a Configuration Server URI that it was shipped with (i.e., not discovered while initializing its networking, it MUST do so by appending the fingerprint of its entity certificate to the URI's string=94 But I don=92t see an equivalent in draft-ietf-netconf-zerotouch-02. How doe= s the bootstrap server know which ownership voucher to provide if it doesn= =92t receive the IDevID information early in the process?=20 > For Keyinfra, the IDevID is used by the device during the enrollment > process. > Some additional thoughts: >=20 > - The keyinfra solution could blend in the ownership voucher concept. > That is, a MASA could dynamically sign a voucher to a registrar that > could then sign the bootstrapping data for the device. I agree. I can envision a scenario where the client could accept either a M= ASA generated =93authorization token=94 (which we could rename a =93logged = authorization=94 or something) -or- a ownership voucher. I=92d signal what = the client supports via extensions placed in the IDevID. > - We seems that unnatural contortions are being performed to support > consumer grade equipment (e.g., home net), where security is opt-in > at best. The MASA =93logged authorization=94 approach was selected because it suppor= ts both consumer grade equipment and complex supply chains. I agree that ow= nership vouchers are fairly straightforward in comparison but it is too nar= row to cover all the use cases.=20 > - We should see if there are ways to mitigate the supply chain issues. > Maybe a kiosk or a QRC printed on the receipt at Best Buys? I=92d be interested in such solutions. The problem I see is that these appr= oaches involve =93public=94 information printed onto the receipt or onto th= e chassis or packaging of the device. That is a low security mechanism and = could be used to, for example, minimize the risk of unrelated parties claim= ing a device but aren=92t sufficient to provide a truly secure supply chain= .=20 - max >=20 >=20 >=20 > Thanks, > Kent >=20 >=20 From nobody Tue Apr 14 13:16:44 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7102F1AD09F for ; Tue, 14 Apr 2015 13:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VW5wV_39aGSM for ; Tue, 14 Apr 2015 13:16:39 -0700 (PDT) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2C6F1AD09B for ; Tue, 14 Apr 2015 13:16:38 -0700 (PDT) Received: by pdbqa5 with SMTP id qa5so24347282pdb.1 for ; Tue, 14 Apr 2015 13:16:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=IJaA31wkFXZcpYL0kGldVMH90fx8WVhCcWVdMlIIS5A=; b=jqgxqR1Pbtw19GZC9jD2kseaWTGOy+L8rPEltUR/CHSfRLSb1DMbNDz1DixsYjKo08 vFFl2/jXsF9LaBaax8QNngupPON4o6SQQSVxTm4NXKG6TtCMr+UHvVMbVZw4IVAng5yV qBtiT/1a55vcLTz3J1/G0cZp3ceTx30n9F/iiBLTrZCaIuZ3vfefjJ4jgQKLyWj8aHh4 MB3qz/BkCx/Ew3K9EoYgXWy3+n3VMSJAMVO+n4BJHJKUfj4McHtvRhxsEQVP5tP2kAKe 3NR5hwgIrWAq3KszNhXghQwT9ytOIhTwv4hOMRgmffqsnWyPmlI/Vy6FV6CJIS1VjYrr hQbw== X-Received: by 10.66.139.109 with SMTP id qx13mr11177944pab.110.1429042598583; Tue, 14 Apr 2015 13:16:38 -0700 (PDT) Received: from ?IPv6:2406:e007:632e:1:28cc:dc4c:9703:6781? ([2406:e007:632e:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id wa4sm1925185pab.17.2015.04.14.13.16.35 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Apr 2015 13:16:37 -0700 (PDT) Message-ID: <552D75A5.6010502@gmail.com> Date: Wed, 15 Apr 2015 08:16:37 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Max Pritikin (pritikin)" , Kent Watsen References: <5511E12E.9050002@gmx.net> <7912.1427385447@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D95700F@szxeml557-mbs.china.huawei.com> <1F85BE1D-44A3-420A-8852-A4BA0DE213AC@cisco.com> <247ADDB2-807D-4AB5-A814-58381A929EB5@cisco.com> <551BC405.3070204@gridmerge.com> <77FA386512F0D748BC7C02C36EB1106D95C712@szxeml557-mbs.china.huawei.com> <93110A7A-4FD8-4D30-B833-5AC516B54BFB@cisco.com> <5526E134.7060208@gmail.com> <21336.1428616625@sandelman.ca> <5527106A.10106@gmail.com> <15763.1428681312@sandelman.ca> <24238.1428693167@sandelman.ca> <55282EA2.6070409@gmail.com> <4D76E559-9E91-434C-8B2D-CAFDE3EFB1B4@cisco.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Michael Richardson , "anima@ietf.org" Subject: Re: [Anima] Ownership Concept X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 20:16:41 -0000 On 15/04/2015 06:32, Max Pritikin (pritikin) wrote: >=20 > On Apr 10, 2015, at 6:04 PM, Kent Watsen wrote: >=20 >> >> >>> I personally disagree with the assertion that somebody with physical >>> possession of the device in factory default state should be able to =C2= =B3take >>> ownership=C2=B2 of the device without engaging with the vendor/cloud = service. >> >> I agree emphatically. I can see how vendors might agree on that. I don't think that corporate purchasers will agree at all, especially those with their own strong view= s on security and trust. Consider the case of a military customer in countr= y X buying equipment from a manufacturer in country Y. I can't imagine them accepting the need for even a momentary engagement with the manufacturer.= The risk of a backdoor is too high. Similarly, if two companies are in competition but one of them needs to buy equipment from the other. Brian From nobody Tue Apr 14 17:14:04 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF7C1AC431 for ; Tue, 14 Apr 2015 17:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgwPEBtqTdl6 for ; Tue, 14 Apr 2015 17:14:01 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 260FE1AC41F for ; Tue, 14 Apr 2015 17:14:01 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6B87AE1BA for ; Tue, 14 Apr 2015 20:25:05 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 8453D63B76; Tue, 14 Apr 2015 20:13:59 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6E465636B6 for ; Tue, 14 Apr 2015 20:13:59 -0400 (EDT) From: Michael Richardson To: "anima\@ietf.org" In-Reply-To: <552D75A5.6010502@gmail.com> References: <5511E12E.9050002@gmx.net> <7912.1427385447@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D95700F@szxeml557-mbs.china.huawei.com> <1F85BE1D-44A3-420A-8852-A4BA0DE213AC@cisco.com> <247ADDB2-807D-4AB5-A814-58381A929EB5@cisco.com> <551BC405.3070204@gridmerge.com> <77FA386512F0D748BC7C02C36EB1106D95C712@szxeml557-mbs.china.huawei.com> <93110A7A-4FD8-4D30-B833-5AC516B54BFB@cisco.com> <5526E134.7060208@gmail.com> <21336.1428616625@sandelman.ca> <5527106A.10106@gmail.com> <15763.1428681312@sandelman.ca> <24238.1428693167@sandelman.ca> <55282EA2.6070409@gmail.com> <4D76E559-9E91-434C-8B2D-CAFDE3EFB1B4@cisco.com> <552D75A5.6010502@gmail.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Anima] Ownership Concept X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 00:14:03 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Brian E Carpenter wrote: >> On Apr 10, 2015, at 6:04 PM, Kent Watsen wrote: >> >>> >>> >>>> I personally disagree with the assertion that somebody with physic= al >>>> possession of the device in factory default state should be able t= o =C2=B3take >>>> ownership=C2=B2 of the device without engaging with the vendor/clo= ud service. >>> >>> I agree emphatically. > I can see how vendors might agree on that. I don't think that corpora= te > purchasers will agree at all, especially those with their own strong = views > on security and trust. Consider the case of a military customer in co= untry X > buying equipment from a manufacturer in country Y. I can't imagine th= em > accepting the need for even a momentary engagement with the manufactu= rer. > The risk of a backdoor is too high. I thought about this situation greatly. If it is unacceptable for X to ever talk to Y's enrollment server, even in some unclassified provisioning lab, then really, X would never buy Y's equipment. At some point, the Y equipment might need new firmware from Y's web site... are you saying they would never download that either? Is this realistic? {My government has banned procurement entirely from some companies} > Similarly, if two companies are in competition but one of them needs = to > buy equipment from the other. It seems broken from the outset... I don't buy the argument. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVS2tR4CLcPvd0N1lAQJvTgf/W+Dkk5RPhrwOMiHDac9PFJCq7NNpFU0F jrcygzNyq9Wa/o/A/9Sp5Oc6DBYnAqSVSrMkkYbchDd6tTVdCOKmJQ0iiSfJ6USn BJ/gTZTWurebLVTvr8ayvb2AmFNDI5ABzGhDeWSEe3GhEA2rpefyVQti6HacQAq4 GV/+LJ7WfisWRHQvti4ZkRScs27f7e763WeHBrzwEeg0pN2Vg2WL5741nZYgfhg2 +fobpWh3xtJHyMf1H033SKsvHYGCKiFFjdWbBTFLHhB/D7g4M0TJwL/FF7jegVaI sbJPIyONZG8vtpLjhISZFR20JWyRWPOeF+Bj/GCUhEFSNxY8tbRXkA== =Oefu -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Apr 14 18:30:03 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA8F61B2B28 for ; Tue, 14 Apr 2015 18:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biUCAG4ydT2D for ; Tue, 14 Apr 2015 18:30:00 -0700 (PDT) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C67D1B2B26 for ; Tue, 14 Apr 2015 18:30:00 -0700 (PDT) Received: by pdbqd1 with SMTP id qd1so32539826pdb.2 for ; Tue, 14 Apr 2015 18:29:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=QwdUfKe/2cBnaRZIEgg8tGK81G87fJFd3Tm3+pPdrek=; b=SdyhcrmuMFgVGspSK+C1TL0RuM9XVuPypJFwP3kvViwN5fXXW2Vd7UqYISPCXAy66b 4bnEOYNpnQ5JNxVm3oa+mWWCT8YZR8NzOvwHxMSmBsOI9xdMC2MDfKW1KgaY4lLp1FnU hbFWyyiq84MkIY7p0heECHOzmlEqeD+V5rtPgeAoZL3a6XkBi57sBPeoLd1JlRuFwG7H YdlzCWYkyg8LZjJQ6pqtsAi9M5Kfd4q6fB/5TW+Sbvj44UDWhe09pITCpjdWIz9EkOL1 OzGUFQbJPYBflKGqpVzLmn9Mn/GrITjIQWix2Do+hsEEAFdCPJt6IWCaNtKGbHKJXijl +bCQ== X-Received: by 10.66.100.165 with SMTP id ez5mr41306443pab.153.1429061399567; Tue, 14 Apr 2015 18:29:59 -0700 (PDT) Received: from ?IPv6:2406:e007:632e:1:28cc:dc4c:9703:6781? ([2406:e007:632e:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id a11sm2309616pdj.54.2015.04.14.18.29.56 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Apr 2015 18:29:58 -0700 (PDT) Message-ID: <552DBF16.7080003@gmail.com> Date: Wed, 15 Apr 2015 13:29:58 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Michael Richardson , "anima@ietf.org" References: <5511E12E.9050002@gmx.net> <77FA386512F0D748BC7C02C36EB1106D95700F@szxeml557-mbs.china.huawei.com> <1F85BE1D-44A3-420A-8852-A4BA0DE213AC@cisco.com> <247ADDB2-807D-4AB5-A814-58381A929EB5@cisco.com> <551BC405.3070204@gridmerge.com> <77FA386512F0D748BC7C02C36EB1106D95C712@szxeml557-mbs.china.huawei.com> <93110A7A-4FD8-4D30-B833-5AC516B54BFB@cisco.com> <5526E134.7060208@gmail.com> <21336.1428616625@sandelman.ca> <5527106A.10106@gmail.com> <15763.1428681312@sandelman.ca> <24238.1428693167@sandelman.ca> <55282EA2.6070409@gmail.com> <4D76E559-9E91-434C-8B2D-CAFDE3EFB1B4@cisco.com> <552D75A5.6010502@gmail.com> <27812.1429056839@sandelman.ca> In-Reply-To: <27812.1429056839@sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] Ownership Concept X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 01:30:02 -0000 Michael, On 15/04/2015 12:13, Michael Richardson wrote: >=20 > Brian E Carpenter wrote: > >> On Apr 10, 2015, at 6:04 PM, Kent Watsen w= rote: > >> > >>> > >>> > >>>> I personally disagree with the assertion that somebody with ph= ysical > >>>> possession of the device in factory default state should be ab= le to =C2=B3take > >>>> ownership=C2=B2 of the device without engaging with the vendor= /cloud service. > >>> > >>> I agree emphatically. >=20 > > I can see how vendors might agree on that. I don't think that cor= porate > > purchasers will agree at all, especially those with their own str= ong views > > on security and trust. Consider the case of a military customer i= n country X > > buying equipment from a manufacturer in country Y. I can't imagin= e them > > accepting the need for even a momentary engagement with the manuf= acturer. > > The risk of a backdoor is too high. >=20 > I thought about this situation greatly. > If it is unacceptable for X to ever talk to Y's enrollment server, even= in > some unclassified provisioning lab, then really, X would never buy Y's > equipment. At some point, the Y equipment might need new firmware from= Y's > web site... are you saying they would never download that either? > Is this realistic? No. Post-STUXNET and post-Snowden, I suppose that any hyper-cautious ente= rprise would download the update into a clean room, scan it carefully and exerci= se it in a test rig before deploying it to live devices. This is the exact o= pposite of consumer behaviour, of course. > {My government has banned procurement entirely from some companies} Precisely for fear of backdoors (and in the case of the US, allegedly because they *knew* that equivalent local products contained back doors).= > > Similarly, if two companies are in competition but one of them ne= eds to > > buy equipment from the other. >=20 > It seems broken from the outset... Nevertheless, it's very common. > I don't buy the argument. In the end, I don't much care except that all basic Anima mechanisms, IMH= O, need to work whatever scenario applies. Brian From nobody Tue Apr 14 18:57:32 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7F11B3098 for ; Tue, 14 Apr 2015 18:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qz4sxr_hbfwd for ; Tue, 14 Apr 2015 18:57:29 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0134.outbound.protection.outlook.com [207.46.100.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFA511B3095 for ; Tue, 14 Apr 2015 18:57:29 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) with Microsoft SMTP Server (TLS) id 15.1.136.25; Wed, 15 Apr 2015 01:57:27 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.204]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.204]) with mapi id 15.01.0136.014; Wed, 15 Apr 2015 01:57:27 +0000 From: Dean Bogdanovic To: Brian E Carpenter Thread-Topic: [Anima] Ownership Concept Thread-Index: AQHQZn+VVX6I84xbD06OnWnWoO+g9J0sNK2AgAErGoCAAORAgIAAqhaAgAAKtICAAAmrgIAAbnSAgAAavACAAwvOAIACsluAgAKxQYCADBw9AIABC7KAgAAXygCAABhtgIAAH9sAgAENXgCAAAihgIAALpOAgAAQoQCAAAffAIAAOQ6AgAXsaYCAAB0ygIAAQlKAgAAVOwCAAAergA== Date: Wed, 15 Apr 2015 01:57:27 +0000 Message-ID: References: <5511E12E.9050002@gmx.net> <77FA386512F0D748BC7C02C36EB1106D95700F@szxeml557-mbs.china.huawei.com> <1F85BE1D-44A3-420A-8852-A4BA0DE213AC@cisco.com> <247ADDB2-807D-4AB5-A814-58381A929EB5@cisco.com> <551BC405.3070204@gridmerge.com> <77FA386512F0D748BC7C02C36EB1106D95C712@szxeml557-mbs.china.huawei.com> <93110A7A-4FD8-4D30-B833-5AC516B54BFB@cisco.com> <5526E134.7060208@gmail.com> <21336.1428616625@sandelman.ca> <5527106A.10106@gmail.com> <15763.1428681312@sandelman.ca> <24238.1428693167@sandelman.ca> <55282EA2.6070409@gmail.com> <4D76E559-9E91-434C-8B2D-CAFDE3EFB1B4@cisco.com> <552D75A5.6010502@gmail.com> <27812.1429056839@sandelman.ca> <552DBF16.7080003@gmail.com> In-Reply-To: <552DBF16.7080003@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB424; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(479174004)(110136001)(82746002)(19580395003)(76176999)(106116001)(33656002)(40100003)(57306001)(2656002)(87936001)(19580405001)(50986999)(99286002)(2950100001)(86362001)(83716003)(62966003)(92566002)(102836002)(93886004)(2900100001)(66066001)(77156002)(36756003)(50226001)(15975445007)(46102003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB424; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BN1PR05MB424; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB424; x-forefront-prvs: 0547116B72 Content-Type: text/plain; charset="iso-8859-1" Content-ID: <81FD5E3BB8EE0E488EF51F4E7FEDABBD@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2015 01:57:27.6874 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB424 Archived-At: Cc: Michael Richardson , "anima@ietf.org" Subject: Re: [Anima] Ownership Concept X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 01:57:32 -0000 It took me a while to read the whole thread and I would go to the basics A data center or network operator (either service provider or enterprise) h= ave to deploy hundreds or thousands of devices. Such orders are usually hig= h touch and vendors know which device goes to such orders. In such scenario= s, it is very expensive to do any pre provisioning or provisioning on site = at installation (will avoid residential scenarios, but those are pretty sim= ilar). Having zero touch capabilities just for those use cases, where only = upon FIRST delivery the zero touch is activated, would be tremendously usef= ul. Ownership model is simpler (as there is possibility to have only one "owner= ") and there are multiple ways to check if the request is coming from the "= right owner". Lets try to solve the use case just for the first owner for c= ustomers that are high touch customers today. For the residential scenarios, that would be very helpful, as residential C= PEs are used until end of their lifetime and the secondary market for such = devices is pretty small IMHO. Dean On Apr 14, 2015, at 9:29 PM, Brian E Carpenter wrote: > Michael, >=20 > On 15/04/2015 12:13, Michael Richardson wrote: >>=20 >> Brian E Carpenter wrote: >>>> On Apr 10, 2015, at 6:04 PM, Kent Watsen wrote: >>>>=20 >>>>>=20 >>>>>=20 >>>>>> I personally disagree with the assertion that somebody with physical >>>>>> possession of the device in factory default state should be able to = =B3take >>>>>> ownership=B2 of the device without engaging with the vendor/cloud se= rvice. >>>>>=20 >>>>> I agree emphatically. >>=20 >>> I can see how vendors might agree on that. I don't think that corporate >>> purchasers will agree at all, especially those with their own strong vi= ews >>> on security and trust. Consider the case of a military customer in coun= try X >>> buying equipment from a manufacturer in country Y. I can't imagine them >>> accepting the need for even a momentary engagement with the manufacture= r. >>> The risk of a backdoor is too high. >>=20 >> I thought about this situation greatly. >> If it is unacceptable for X to ever talk to Y's enrollment server, even = in >> some unclassified provisioning lab, then really, X would never buy Y's >> equipment. At some point, the Y equipment might need new firmware from = Y's >> web site... are you saying they would never download that either? >> Is this realistic? >=20 > No. Post-STUXNET and post-Snowden, I suppose that any hyper-cautious ente= rprise > would download the update into a clean room, scan it carefully and exerci= se > it in a test rig before deploying it to live devices. This is the exact o= pposite > of consumer behaviour, of course. >=20 >> {My government has banned procurement entirely from some companies} >=20 > Precisely for fear of backdoors (and in the case of the US, allegedly > because they *knew* that equivalent local products contained back doors). >=20 >>> Similarly, if two companies are in competition but one of them needs to >>> buy equipment from the other. >>=20 >> It seems broken from the outset... >=20 > Nevertheless, it's very common. >=20 >> I don't buy the argument. >=20 > In the end, I don't much care except that all basic Anima mechanisms, IMH= O, > need to work whatever scenario applies. >=20 > Brian >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Wed Apr 15 08:09:54 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A365D1ACE34 for ; Wed, 15 Apr 2015 08:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2X0sqjfHUqX for ; Wed, 15 Apr 2015 08:09:52 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EAF81ACDFF for ; Wed, 15 Apr 2015 08:09:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2917; q=dns/txt; s=iport; t=1429110589; x=1430320189; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=rCU5OSKLY67ebQmmGQXjdNfJUBGPnK6SGTSYX4Z2QFQ=; b=hcDy05d9gc1vmFPdG4dln3FXBeIufUy6iJM5zSgO97OYNbLuWMP40eZx MfDGgusTyutFOhbmfjCT9tu6FmQdTDd8An2sUKgzfJf55pnsr3JqmbJGt DgaObfspeTAocajljFd7ahpk8Ag1bnNKOK79ScK/Ndf8e9n8GJdqGB6K7 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BKBQBrfi5V/5xdJa1cgwyBLgXNOAKBOkwBAQEBAQF+hCABAQEDAWwKAwULAgEIGC4hESUCBA4FG4d7AwkIsiWNNw2FKwEBAQEBAQEBAQEBAQEBAQEBAQEBGIsrgkiCATMHgxeBFgWRDohEgU2BHY0Xgm6DTSKDb28BgUN/AQEB X-IronPort-AV: E=Sophos;i="5.11,582,1422921600"; d="scan'208";a="408948082" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 15 Apr 2015 15:09:48 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t3FF9m19031017 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Apr 2015 15:09:48 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.90]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Wed, 15 Apr 2015 10:09:48 -0500 From: "Max Pritikin (pritikin)" To: Brian E Carpenter Thread-Topic: [Anima] Ownership Concept Thread-Index: AQHQZn+Wm4eAxWuLS02QOiRijuPZe50siH6AgAErG4CAAORAgIAAqhaAgAAKs4CAAAlUAIAAbsyA///G6uSAA1+gAIACsoiAgAKxFICADBw9AIABC7AAgAAXzACAABhtgIAAH9sAgAENXQCAAAikgIAALpGAgAAQoQCAAAfigIAAOQuAgAXsYgCAAB05gIABPI6A Date: Wed, 15 Apr 2015 15:09:47 +0000 Message-ID: References: <5511E12E.9050002@gmx.net> <7912.1427385447@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D95700F@szxeml557-mbs.china.huawei.com> <1F85BE1D-44A3-420A-8852-A4BA0DE213AC@cisco.com> <247ADDB2-807D-4AB5-A814-58381A929EB5@cisco.com> <551BC405.3070204@gridmerge.com> <77FA386512F0D748BC7C02C36EB1106D95C712@szxeml557-mbs.china.huawei.com> <93110A7A-4FD8-4D30-B833-5AC516B54BFB@cisco.com> <5526E134.7060208@gmail.com> <21336.1428616625@sandelman.ca> <5527106A.10106@gmail.com> <15763.1428681312@sandelman.ca> <24238.1428693167@sandelman.ca> <55282EA2.6070409@gmail.com> <4D76E559-9E91-434C-8B2D-CAFDE3EFB1B4@cisco.com> <552D75A5.6010502@gmail.com> In-Reply-To: <552D75A5.6010502@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.232.82] Content-Type: text/plain; charset="Windows-1252" Content-ID: <095D158ADB86A74FA146316346C2F740@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Michael Richardson , Kent Watsen , "anima@ietf.org" Subject: Re: [Anima] Ownership Concept X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 15:09:53 -0000 On Apr 14, 2015, at 2:16 PM, Brian E Carpenter wrote: > On 15/04/2015 06:32, Max Pritikin (pritikin) wrote: >>=20 >> On Apr 10, 2015, at 6:04 PM, Kent Watsen wrote: >>=20 >>>=20 >>>=20 >>>> I personally disagree with the assertion that somebody with physical >>>> possession of the device in factory default state should be able to = =B3take >>>> ownership=B2 of the device without engaging with the vendor/cloud serv= ice. >>>=20 >>> I agree emphatically. >=20 > I can see how vendors might agree on that. I don't think that corporate > purchasers will agree at all, especially those with their own strong view= s > on security and trust. Consider the case of a military customer in countr= y X > buying equipment from a manufacturer in country Y. I can't imagine them > accepting the need for even a momentary engagement with the manufacturer. > The risk of a backdoor is too high. There is a pretty big =93engagement=94 with the manufacturer when they purc= hase hardware and software. There is also an =93engagement=94 when software= updates, signed by the manufacturer of course, are delivered. As secure b= oot, runtime integrity, threat detections etc are added these =93engagement= s=94 could reasonably occur more often. What makes a zero touch authorizati= on any different?=20 I suspect your concern is that: 1) can this be used as a =93backdoor=94 to gain management control over the= device? We=92ve previously discussed that this bootstrapping only accepted when the= device has been returned to factory defaults. Manufacturer authorization m= ethods provide an additional layer of protection beyond whatever key zeroiz= e method were used during factory reset.=20 2) could inability to repeat bootstrapping result in a bricked device in th= e field?=20 This is a serious concern. The MASA =93nonceless=94 responses have an infin= ite lifetime if necessary. I presume a similar concept would apply to the n= etconf draft. Either of which would require that the authorization blob is = available =93in the field=94. Storing it on the device would be problematic= as it would have been erased during factory reset. It could be stored else= where or a solution to that could be identified. This strikes me as the mos= t compelling reason to allow physical possession as a backdoor around zero-= touch security mechanisms - although hopefully we at least provide a soluti= on with associated =93MAY=94 language. =20 > Similarly, if two companies are in competition but one of them needs to > buy equipment from the other. Buying equipment from a suspected attacker assumes that the vendor provided= secure boot integrity protections are highly trusted! I don=92t see this a= s directly related to the problem at hand (it exists either way).=20 - max >=20 > Brian >=20 From nobody Wed Apr 15 08:51:56 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3231A912D for ; Wed, 15 Apr 2015 08:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmVRFPF7AA-T for ; Wed, 15 Apr 2015 08:51:53 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D7441ACE33 for ; Wed, 15 Apr 2015 08:51:53 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 07B742009E for ; Wed, 15 Apr 2015 12:03:00 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id E4F9763B76; Wed, 15 Apr 2015 11:51:51 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id CCDA3636B6 for ; Wed, 15 Apr 2015 11:51:51 -0400 (EDT) From: Michael Richardson To: "anima\@ietf.org" In-Reply-To: <552DBF16.7080003@gmail.com> References: <5511E12E.9050002@gmx.net> <77FA386512F0D748BC7C02C36EB1106D95700F@szxeml557-mbs.china.huawei.com> <1F85BE1D-44A3-420A-8852-A4BA0DE213AC@cisco.com> <247ADDB2-807D-4AB5-A814-58381A929EB5@cisco.com> <551BC405.3070204@gridmerge.com> <77FA386512F0D748BC7C02C36EB1106D95C712@szxeml557-mbs.china.huawei.com> <93110A7A-4FD8-4D30-B833-5AC516B54BFB@cisco.com> <5526E134.7060208@gmail.com> <21336.1428616625@sandelman.ca> <5527106A.10106@gmail.com> <15763.1428681312@sandelman.ca> <24238.1428693167@sandelman.ca> <55282EA2.6070409@gmail.com> <4D76E559-9E91-434C-8B2D-CAFDE3EFB1B4@cisco.com> <552D75A5.6010502@gmail.com> <27812.1429056839@sandelman.ca> <552DBF16.7080003@gma il.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Anima] Ownership Concept X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 15:51:55 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Brian E Carpenter wrote: >> > Similarly, if two companies are in competition but one of them nee= ds >> to > buy equipment from the other. >>=20 >> It seems broken from the outset... > Nevertheless, it's very common. >> I don't buy the argument. > In the end, I don't much care except that all basic Anima mechanisms, > IMHO, need to work whatever scenario applies. Well, I think, given a craft terminal and appropriate provisioning of a locally significant trust anchor and certificate, that we can arrange to sk= ip the "call home" step. I'm just not willing to build it in as a core part of the protocol. As I said, I'm happy if it's an alternate path. One might ask why even do ANIMA in such a situation, but given a situation = where one builds-to-inventory, and then ships, it makes sense. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVS6JF4CLcPvd0N1lAQLcKgf/eEwxtJXREQn8ObJlWgICr5+LPMl8Ut+V 6Laxarv7F775NquakWaZoFZUM3KfEHgO4KVRntB0+FgkhznGnRGygvgRgdbwBb0o XAblpEw9aNOslu5PQ0/FeBy0JPxNBw0Vs1+uEftwDl+1VwvcQKbSAsqJJcPn/YjB bgjUnOqYR/g2wMPrRbWtkIvpdfoCCH3AvyriqJ9RSumpptKJ94RcxzPlc2iwUlBR 0uKcFd6eHEf5eDHlHXJjrlfZR5ysGHGoGYhyrlFfAEA/1hkcTnqdoixwL5D/9ht6 fslLk1klY7JgKW5Ugu69GlbLrTDpi7ivBSeW01P3oGGIbn2PqrgKJQ== =Dt5q -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Apr 15 10:54:40 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8001B2ED2 for ; Wed, 15 Apr 2015 10:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPwO11RRlhfk for ; Wed, 15 Apr 2015 10:54:37 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0767.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::767]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A50021B2EAA for ; Wed, 15 Apr 2015 10:54:36 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.1.136.25; Wed, 15 Apr 2015 17:54:17 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.233]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.233]) with mapi id 15.01.0136.026; Wed, 15 Apr 2015 17:54:17 +0000 From: Kent Watsen To: "Max Pritikin (pritikin)" Thread-Topic: [Anima] Ownership Concept Thread-Index: AQHQZn+WmG3Pkztd4UiFW+kyT70z+Z0sNK2AgAErGoCAAORAgIAAqhaAgAAKtICAAAmrgIAAbnSAgAAavACAAwvOAIACsluAgAKxQYCADBw9AIABC7KAgAAXygCAABhtgIAAH9sAgAENXgCAAAihgIAALpOAgAAQoQCAAAffAP//9gCAgAYvd4CAAUSzAA== Date: Wed, 15 Apr 2015 17:54:17 +0000 Message-ID: References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> <5512DE41.6030209@gmail.com> <77FA386512F0D748BC7C02C36EB1106D956D45@szxeml557-mbs.china.huawei.com> <7912.1427385447@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D95700F@szxeml557-mbs.china.huawei.com> <1F85BE1D-44A3-420A-8852-A4BA0DE213AC@cisco.com> <247ADDB2-807D-4AB5-A814-58381A929EB5@cisco.com> <551BC405.3070204@gridmerge.com> <77FA386512F0D748BC7C02C36EB1106D95C712@szxeml557-mbs.china.huawei.com> <93110A7A-4FD8-4D30-B833-5AC516B54BFB@cisco.com> <5526E134.7060208@gmail.com> <21336.1428616625@sandelman.ca> <5527106A.10106@gmail.com> <15763.1428681312@sandelman.ca> <24238.1428693167@sandelman.ca> <55282EA2.6070409@gmail.com> <4D76E559-9E91-434C-8B2D-CAFDE3EFB1B4@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: cisco.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.14] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(102836002)(106116001)(62966003)(2950100001)(2900100001)(4001350100001)(76176999)(50986999)(54356999)(46102003)(86362001)(93886004)(77156002)(92566002)(110136001)(87936001)(36756003)(40100003)(2656002)(122556002)(99286002)(66066001)(83506001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:CO1PR05MB460; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB460; x-forefront-prvs: 0547116B72 Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2015 17:54:17.3038 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB460 Archived-At: Cc: Michael Richardson , "anima@ietf.org" Subject: Re: [Anima] Ownership Concept X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 17:54:39 -0000 Hi Max, >I was under the impression that the local policies _should_ be able to >set the security guarantees =8B this this characteristic is a =B3pro=B2. := ) True, true, but it's hand-waving language that I can't get my head around how its realized. This is why I wrote "unclear security". The issue is that bootstrapping-keyinfra provides a mechanism that can be used as part of a bootstrapping solution, but it's not the entire solution, and not knowing the other parts leaves the solution unclear. >> Security degraded on private networks. > >I=B9m not following this assertion. How is security degraded on a private >networks? What is the threat you are thinking of and how is it mitigated >by the netconf zero-touch approach? I may have misspoken, please correct me if so, but my understanding is that the MASA doesn't run on a private network, hence it's up to the Registrars to make a local policy decision. Asserting that a log has been created in an auditable location offers some protection, but without MASA, what's the Registrar suppose to do? There could be a simple explanation but, again, this goes to my not understanding the complete solution. In the netconf zero-touch approach, the bootstrapping data is signed by the rightful-owner's private key. How the bootstrapping data is provided to the device (over WAN, LAN, or off a USB flash drive) doesn't alter the fact that the data is signed and hence equally trustworthy in all cases. >In the early version draft-kwatsen-netconf-zerotouch-01 uses the IDevID >early on: > "When the device is accessing a Configuration Server URI that it was > shipped with (i.e., not discovered while initializing its networking, > it MUST do so by appending the fingerprint of its entity certificate > to the URI's string=B2 >But I don=B9t see an equivalent in draft-ietf-netconf-zerotouch-02. How >does the bootstrap server know which ownership voucher to provide if it >doesn=B9t receive the IDevID information early in the process? The current version simplifies it to just the device's unique-identifier (see examples in Section A.2). Basically, I'm on the fence if the unique-id (e.g., serial-number) should be used directly, or if it's too structured and can lead to an enumeration attack and o a potential loss of privacy. Rest assured that the data is still safe, but others may have gleaned it, learning details that might be used to launch a larger attack (e.g., the tolopolgy of the network). One remediation step is to use a less structured ID - for instance, the md5-hash of the unique-id would cause even statistical distribution over a 16-byte value-space. Another remediation could be to enable the rightful owner to both sign and *encrypt* the bootstrap data. Encrypted using the device's public key, as found in its IDevID. But this means that now the device's IDevID (not it's unique-id), would have to be provided to the rightful owner (e.g., in an email containing shipping information). The question here mainly is if this improvement in privacy (not security) is worth the additional hassle... >> For Keyinfra, the IDevID is used by the device during the enrollment >> process. >> Some additional thoughts: >>=20 >> - The keyinfra solution could blend in the ownership voucher concept. >> That is, a MASA could dynamically sign a voucher to a registrar that >> could then sign the bootstrapping data for the device. > >I agree. I can envision a scenario where the client could accept either a >MASA generated =B3authorization token=B2 (which we could rename a =B3logge= d >authorization=B2 or something) -or- a ownership voucher. I=B9d signal what >the client supports via extensions placed in the IDevID. Interesting suggestion. This is worth exploring, perhaps as an aspect of a wholistic keyinfra solution... >> - It seems that unnatural contortions are being performed to support >> consumer grade equipment (e.g., home net), where security is opt-in >> at best. > >The MASA =B3logged authorization=B2 approach was selected because it suppo= rts >both consumer grade equipment and complex supply chains. I agree that >ownership vouchers are fairly straightforward in comparison but it is too >narrow to cover all the use cases. Exactly. I'm beginning to think that these are fundamentally different use-cases. On one hand, we have an already high-touch sales process, where the overhead of an additional vendor interaction is not a big deal, and yet uncompromising security is needed (this is what netconf zerotouch is going after). And on the other hand, we have a potentially no-touch sales process, where the overhead of an additional vendor interaction is a non-starter, and security is not a big deal anyway (this is homenet's space). Bootstrapping-keyinfra is trying to target both, which is no easy feat.. >> - We should see if there are ways to mitigate the supply chain issues. >> Maybe a kiosk or a QRC printed on the receipt at Best Buys? > >I=B9d be interested in such solutions. The problem I see is that these >approaches involve =B3public=B2 information printed onto the receipt or on= to >the chassis or packaging of the device. That is a low security mechanism >and could be used to, for example, minimize the risk of unrelated parties >claiming a device but aren=B9t sufficient to provide a truly secure supply >chain. That is indeed the risk, and we should only view this as a strategy to try a handle consumer-grade equipment...and not used for equipment provided by a secure supply chain. From nobody Wed Apr 15 14:03:23 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA7D1A8F4D for ; Wed, 15 Apr 2015 14:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QcEFRyXvp5Y for ; Wed, 15 Apr 2015 14:03:20 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF6ED1A8F4B for ; Wed, 15 Apr 2015 14:03:19 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8F3262009E for ; Wed, 15 Apr 2015 17:14:27 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id A8DE463B76; Wed, 15 Apr 2015 17:03:18 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 92582636A2 for ; Wed, 15 Apr 2015 17:03:18 -0400 (EDT) From: Michael Richardson To: "anima\@ietf.org" In-Reply-To: References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> <5512DE41.6030209@gmail.com> <77FA386512F0D748BC7C02C36EB1106D956D45@szxeml557-mbs.china.huawei.com> <7912.1427385447@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D95700F@szxeml557-mbs.china.huawei.com> <1F85BE1D-44A3-420A-8852-A4BA0DE213AC@cisco.com> <247ADDB2-807D-4AB5-A814-58381A929EB5@cisco.com> <551BC405.3070204@gridmerge.com> <77FA386512F0D748BC7C02C36EB1106D95C712@szxeml557-mbs.china.huawei.com> <93110A7A-4FD8-4D30-B833-5AC516B54BFB@cisco.com> <5526E134.7060208@gmail.com> <21336.1428616625@sandelman.ca> <5527106A.10106@gmail.com> <15763.1428681312@sandelman.ca> <24238.1428693167@sandelman.ca> <55282EA2.6070409@gmail.com> <4D76E559-9E91-434C-8B2D-CAFDE3EFB1B4@cisco.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Anima] Ownership Concept X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 21:03:22 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable comments inline. Kent Watsen wrote: >> I=C2=B9m not following this assertion. How is security degraded on a >> private networks? What is the threat you are thinking of and how is = it >> mitigated by the netconf zero-touch approach? > I may have misspoken, please correct me if so, but my understanding is > that the MASA doesn't run on a private network, hence it's up to the > Registrars to make a local policy decision. Asserting that a log has > been created in an auditable location offers some protection, but > without MASA, what's the Registrar suppose to do? There could be a > simple explanation but, again, this goes to my not understanding the > complete solution. yes, I also don't understand the multiple-MASA, or partitioned-MASA situation. As far as I understood, unless there is a canonical MASA for a given device or all the MASA flood fill data (perhaps bitcoin block-chain like), then the increased security due to the audit process of the MASA is reduced. I just steal your device, put it on my private network, and it's good. >> In the early version draft-kwatsen-netconf-zerotouch-01 uses the >> IDevID early on: "When the device is accessing a Configuration Server >> URI that it was shipped with (i.e., not discovered while initializing >> its networking, it MUST do so by appending the fingerprint of its >> entity certificate to the URI's string=C2=B2 But I don=C2=B9t see an= equivalent >> in draft-ietf-netconf-zerotouch-02. How does the bootstrap server kn= ow >> which ownership voucher to provide if it doesn=C2=B9t receive the ID= evID >> information early in the process? > The current version simplifies it to just the device's > unique-identifier (see examples in Section A.2). Basically, I'm on t= he > fence if the unique-id (e.g., serial-number) should be used directly, > or if it's too structured and can lead to an enumeration attack and o= a > potential loss of privacy. Rest assured that the data is still safe, > but others may have gleaned it, learning details that might be used to > launch a larger attack (e.g., the tolopolgy of the network). One > remediation step is to use a less structured ID - for instance, the > md5-hash of the unique-id would cause even statistical distribution > over a 16-byte value-space. Another remediation could be to enable t= he > rightful owner to both sign and *encrypt* the bootstrap data. > Encrypted using the device's public key, as found in its IDevID. But > this means that now the device's IDevID (not it's unique-id), would > have to be provided to the rightful owner (e.g., in an email containi= ng > shipping information). The question here mainly is if this improveme= nt > in privacy (not security) is worth the additional hassle... I'm generally skeptical about privacy improvements by having non-enumerable IDs. I don't think that there is any privacy improvement from changing the observation from unique-ID=3D00001 to unique-ID=3DMDAwMDEK, if it's always the same. Now, the question is, what is the enumeration attack you are worried about? I agree that it might be beneficial to eliminate that, but maybe it doesn't matter.=20=20 >> I agree. I can envision a scenario where the client could accept >> either a MASA generated =C2=B3authorization token=C2=B2 (which we co= uld rename a >> =C2=B3logged authorization=C2=B2 or something) -or- a ownership vouc= her. I=C2=B9d >> signal what the client supports via extensions placed in the IDevID. > Interesting suggestion. This is worth exploring, perhaps as an aspect > of a wholistic keyinfra solution... Yes, I agree. I prefer "logged authentication token", btw. >>> - It seems that unnatural contortions are being performed to support >>> consumer grade equipment (e.g., home net), where security is opt-in >>> at best. >>=20 >> The MASA =C2=B3logged authorization=C2=B2 approach was selected beca= use it >> supports both consumer grade equipment and complex supply chains. I >> agree that ownership vouchers are fairly straightforward in comparis= on >> but it is too narrow to cover all the use cases. > Exactly. I'm beginning to think that these are fundamentally differe= nt > use-cases. On one hand, we have an already high-touch sales process, > where the overhead of an additional vendor interaction is not a big > deal, and yet uncompromising security is needed (this is what netconf > zerotouch is going after). And on the other hand, we have a > potentially no-touch sales process, where the overhead of an addition= al > vendor interaction is a non-starter, and security is not a big deal > anyway (this is homenet's space). Bootstrapping-keyinfra is trying to > target both, which is no easy feat.. I actually disagree that the security of the homenet space is "not a big de= al". This is what got us bot-nets. If someone can gain control over millions of light bulbs, and can turn them on/off at the same time, it's a really really really big deal. Having said that, I believe that a supply-chain interaction (which might not go all the way back to the vendor) is potentially acceptable in the long ru= n. We just have to have a way to get product deployed without a chicken/egg situation.=20 =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVS7SFoCLcPvd0N1lAQKXFAgAkk0mVa+fRdX6NuIkplF4V133bg9lRe80 s3j8QJN7b4oRhNkNT8Zo/WCHsHcYzRA4vizsNNI1z7Axysto32/dY8LJKnlaA/Ym MfNZl/4RrhPZYTX5XqpX3Gzxq96G0qvOjFyBVaWTX31XOwngXEGd1jz+VN+OkCnl v6OnmQ1kUGnyvLMbgIHCypPbSsM4eR9HZYmYa92F6sRLXDM5++f31Cy2mSq5O5by zpE8JIm6yBEauxWK3BFswqB3xFwSypBt/EXws2Y28arxZ9T88EEKA7MExnNcnXo6 OuON3XyIEqjb9BBqhnrr59bPwp184/tESt8X2nu+AVjwlcPDvyw7yw== =ULO5 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Apr 15 20:28:28 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 676B91B2E6E for ; Wed, 15 Apr 2015 20:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26DCzSUWIb6W for ; Wed, 15 Apr 2015 20:28:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BDEC1B2E43 for ; Wed, 15 Apr 2015 20:28:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRL71325; Thu, 16 Apr 2015 03:28:22 +0000 (GMT) Received: from SZXEML430-HUB.china.huawei.com (10.82.67.185) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 16 Apr 2015 04:28:21 +0100 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.131]) by szxeml430-hub.china.huawei.com ([10.82.67.185]) with mapi id 14.03.0158.001; Thu, 16 Apr 2015 11:28:18 +0800 From: "Hedanping (Ana)" To: Brian E Carpenter , Michael Richardson , "anima@ietf.org" Thread-Topic: [Anima] Ownership Concept Thread-Index: AQHQZn+XTQng45mwMk+HZqqnogMqdJ0rrpGAgAErGoCAAWoPYIAAJEeAgACJpQD//4q5gIAAbnWAgAAavACAAwvOAIACsluAgAKxQYCADJZlwIAAkYqAgAAXygCAABhtgIAAH9sAgAENXgCAAAiggIAALpSAgAAQoQCAAAfeAIAAOQ+AgAXsaICAAB0zgIAAQlKAgAAVOgCAAh3JAA== Date: Thu, 16 Apr 2015 03:28:17 +0000 Message-ID: <77FA386512F0D748BC7C02C36EB1106D95DFF0@szxeml557-mbs.china.huawei.com> References: <5511E12E.9050002@gmx.net> <77FA386512F0D748BC7C02C36EB1106D95700F@szxeml557-mbs.china.huawei.com> <1F85BE1D-44A3-420A-8852-A4BA0DE213AC@cisco.com> <247ADDB2-807D-4AB5-A814-58381A929EB5@cisco.com> <551BC405.3070204@gridmerge.com> <77FA386512F0D748BC7C02C36EB1106D95C712@szxeml557-mbs.china.huawei.com> <93110A7A-4FD8-4D30-B833-5AC516B54BFB@cisco.com> <5526E134.7060208@gmail.com> <21336.1428616625@sandelman.ca> <5527106A.10106@gmail.com> <15763.1428681312@sandelman.ca> <24238.1428693167@sandelman.ca> <55282EA2.6070409@gmail.com> <4D76E559-9E91-434C-8B2D-CAFDE3EFB1B4@cisco.com> <552D75A5.6010502@gmail.com> <27812.1429056839@sandelman.ca> <552DBF16.7080003@gmail.com> In-Reply-To: <552DBF16.7080003@gmail.com> Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.94.103] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] Ownership Concept X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 03:28:27 -0000 SGksDQpQbGVhc2Ugc2VlIG15IHJlcGx5IGlubGluZS4NCg0KICA+LS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCiAgPkZyb206IEFuaW1hIFttYWlsdG86YW5pbWEtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIEJyaWFuIEUgQ2FycGVudGVyDQogID5TZW50OiBXZWRuZXNkYXksIEFwcmls IDE1LCAyMDE1IDk6MzAgQU0NCiAgPlRvOiBNaWNoYWVsIFJpY2hhcmRzb247IGFuaW1hQGlldGYu b3JnDQogID5TdWJqZWN0OiBSZTogW0FuaW1hXSBPd25lcnNoaXAgQ29uY2VwdA0KICA+DQogID5N aWNoYWVsLA0KICA+DQogID5PbiAxNS8wNC8yMDE1IDEyOjEzLCBNaWNoYWVsIFJpY2hhcmRzb24g d3JvdGU6DQogID4+DQogID4+IEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBn bWFpbC5jb20+IHdyb3RlOg0KICA+PiAgICAgPj4gT24gQXByIDEwLCAyMDE1LCBhdCA2OjA0IFBN LCBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4NCiAgPndyb3RlOg0KICA+PiAgICAg Pj4NCiAgPj4gICAgID4+Pg0KICA+PiAgICAgPj4+DQogID4+ICAgICA+Pj4+IEkgcGVyc29uYWxs eSBkaXNhZ3JlZSB3aXRoIHRoZSBhc3NlcnRpb24gdGhhdCBzb21lYm9keSB3aXRoDQogID5waHlz aWNhbA0KICA+PiAgICAgPj4+PiBwb3NzZXNzaW9uIG9mIHRoZSBkZXZpY2UgaW4gZmFjdG9yeSBk ZWZhdWx0IHN0YXRlIHNob3VsZCBiZSBhYmxlIHRvDQogID7Cs3Rha2UNCiAgPj4gICAgID4+Pj4g b3duZXJzaGlwwrIgb2YgdGhlIGRldmljZSB3aXRob3V0IGVuZ2FnaW5nIHdpdGggdGhlDQogID52 ZW5kb3IvY2xvdWQgc2VydmljZS4NCiAgPj4gICAgID4+Pg0KICA+PiAgICAgPj4+IEkgYWdyZWUg ZW1waGF0aWNhbGx5Lg0KICA+Pg0KICA+PiAgICAgPiBJIGNhbiBzZWUgaG93IHZlbmRvcnMgbWln aHQgYWdyZWUgb24gdGhhdC4gSSBkb24ndCB0aGluayB0aGF0DQogID5jb3Jwb3JhdGUNCiAgPj4g ICAgID4gcHVyY2hhc2VycyB3aWxsIGFncmVlIGF0IGFsbCwgZXNwZWNpYWxseSB0aG9zZSB3aXRo IHRoZWlyIG93biBzdHJvbmcNCiAgPnZpZXdzDQogID4+ICAgICA+IG9uIHNlY3VyaXR5IGFuZCB0 cnVzdC4gQ29uc2lkZXIgdGhlIGNhc2Ugb2YgYSBtaWxpdGFyeSBjdXN0b21lciBpbg0KICA+Y291 bnRyeSBYDQogID4+ICAgICA+IGJ1eWluZyBlcXVpcG1lbnQgZnJvbSBhIG1hbnVmYWN0dXJlciBp biBjb3VudHJ5IFkuIEkgY2FuJ3QgaW1hZ2luZQ0KICA+dGhlbQ0KICA+PiAgICAgPiBhY2NlcHRp bmcgdGhlIG5lZWQgZm9yIGV2ZW4gYSBtb21lbnRhcnkgZW5nYWdlbWVudCB3aXRoIHRoZQ0KICA+ bWFudWZhY3R1cmVyLg0KICA+PiAgICAgPiBUaGUgcmlzayBvZiBhIGJhY2tkb29yIGlzIHRvbyBo aWdoLg0KICA+Pg0KICA+PiBJIHRob3VnaHQgYWJvdXQgdGhpcyBzaXR1YXRpb24gZ3JlYXRseS4N CiAgPj4gSWYgaXQgaXMgdW5hY2NlcHRhYmxlIGZvciBYIHRvIGV2ZXIgdGFsayB0byBZJ3MgZW5y b2xsbWVudCBzZXJ2ZXIsDQogID4+IGV2ZW4gaW4gc29tZSB1bmNsYXNzaWZpZWQgcHJvdmlzaW9u aW5nIGxhYiwgdGhlbiByZWFsbHksIFggd291bGQgbmV2ZXINCiAgPj4gYnV5IFkncyBlcXVpcG1l bnQuICBBdCBzb21lIHBvaW50LCB0aGUgWSBlcXVpcG1lbnQgbWlnaHQgbmVlZCBuZXcNCiAgPj4g ZmlybXdhcmUgZnJvbSBZJ3Mgd2ViIHNpdGUuLi4gYXJlIHlvdSBzYXlpbmcgdGhleSB3b3VsZCBu ZXZlciBkb3dubG9hZCB0aGF0DQogID5laXRoZXI/DQogID4+IElzIHRoaXMgcmVhbGlzdGljPw0K ICA+DQogID5Oby4gUG9zdC1TVFVYTkVUIGFuZCBwb3N0LVNub3dkZW4sIEkgc3VwcG9zZSB0aGF0 IGFueSBoeXBlci1jYXV0aW91cw0KICA+ZW50ZXJwcmlzZSB3b3VsZCBkb3dubG9hZCB0aGUgdXBk YXRlIGludG8gYSBjbGVhbiByb29tLCBzY2FuIGl0IGNhcmVmdWxseSBhbmQNCiAgPmV4ZXJjaXNl IGl0IGluIGEgdGVzdCByaWcgYmVmb3JlIGRlcGxveWluZyBpdCB0byBsaXZlIGRldmljZXMuIFRo aXMgaXMgdGhlIGV4YWN0DQogID5vcHBvc2l0ZSBvZiBjb25zdW1lciBiZWhhdmlvdXIsIG9mIGNv dXJzZS4NCiAgPg0KDQpXaGV0aGVyIHRvIHVwZGF0ZSBzb2Z0d2FyZSBpcyB1c3VhbGx5IGRldGVy bWluZWQgYnkgdGhlIG93bmVyIG9mIHRoZSBkZXZpY2UuIEJlc2lkZXMsIHRoZSBkZXZpY2UgYW5k IHRoZSBuZXR3b3JrIGJhc2ljYWxseSBzaG91bGRuJ3Qgc3RvcCB3b3JraW5nIG5vIG1hdHRlciB0 aGUgc29mdHdhcmUgaXMgdXBkYXRlZCBvciBub3QuDQpBIG1haW4gZGlmZmVyZW5jZSBiZXR3ZWVu IHNvZnR3YXJlIHVwZGF0ZSBzZXJ2ZXIgYW5kIE1BU0EgaXMgdGhhdCBNQVNBJ1MgYXV0aG9yaXph dGlvbiB0b2tlbiBkZXRlcm1pbmVzIG5ldHdvcmtpbmcuIA0KDQpJIHN1bW1hcml6ZSBNQVNBJ3Mg d29yayBpbiB0aGUgZHJhZnQsIGNvcnJlY3QgbWUgaWYgSSBhbSB3cm9uZzoNCjEuIGNoZWNrIGRv bWFpbiBjb25mbGljdGlvbiBvZiBhIGpvaW5pbmcgZGV2aWNlLi0+VGhpcyBjb3VsZCBmb3JiaWQg dGhlIHN0b2xlbiBkZXZpY2UgYmVpbmcgdXNlZCBieSBvdGhlcnMoc2ltaWxhciBhcyBBcHBsZSBw cm9kdWN0cyksIGhvd2V2ZXIgYSBkZXZpY2UgY2FuIGJlbG9uZyB0byBvbmUgb3duZXIgYXQgYSB0 aW1lIGJ1dCBtaWdodCBiZWxvbmcgdG8gZGlmZmVyZW50IGRvbWFpbnMvc3ViLWRvbWFpbnMsIGFn YWluIHdlIGZhbGwgaW50byB0aGUgZGlzY3Vzc2lvbiBvZiB3aGV0aGVyICdkb21haW4gaWQ9PSBv d25lciBpZCcsIGFuZCBJTU8sIHRoZSBhbnN3ZXIgaXMgTm8uIA0KMi4gcmVtb3RlbHkgYXVkaXQg ZXZlbnQuLT53aGV0aGVyIHRoZSBpbmZvcm1hdGlvbiBpcyByZW1vdGVseSBhdWRpdGVkIHNob3Vs ZCBub3QgaW1wYWN0IGRldmljZSBqb2luaW5nLg0KMy4gdmFsaWRhdGUgdGhlIHJlZ2lzdHJhciBm b3IgdGhlIGpvaW5pbmcgZGV2aWNlLi0+dGhlIHZhbGlkYXRpb24gY291bGQgYmUgZG9uZSBsb2Nh bGx5IGFzIHdlbGwuDQoNCkkgZG9uJ3QgaGF2ZSBhbnkgY2x1ZSB3aHkgTUFTQSBzaG91bGQgcGFy dGljaXBhdGUgaW4gYm9vdHN0cmFwcGluZyhldmVuIGFzIGFuIG9wdGlvbikgYnkgY29uc2lkZXJp bmcgdGhlIGFib3ZlIHRocmVlIGl0ZW1zLg0KSG93ZXZlciwgSU1PLCBhcyBNQVNBIGlzIGFscmVh ZHkgb3B0aW9uYWwgaW4gdGhlIGN1cnJlbnQgdmVyc2lvbiwgaXQgY291bGQgYmUgdXNlZCB0byBy ZWFsaXplIGEgbW9yZSB2YWx1YWJsZSB0YXNrKGlmIHJlcXVpcmVkKSBhbmQgbm90IG9ubHkgYXQg dGhlIGJvb3RzdHJhcHBpbmcgcGhhc2UgdG8gdmFsaWRhdGUgdGhlIGludGVncml0eSBvZiB0aGUg am9pbmluZyBkZXZpY2UvYWxsIHRoZSBleGlzdGluZyBkZXZpY2VzIGluIHRoZSBkb21haW4gYW5k IGFsZXJ0IGRvbWFpbiBpZiBhbnkgYWJub3JtYWxpdHkgaGFwcGVuLiANCg0KQW5hDQoNCg0K From nobody Mon Apr 20 14:03:08 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F821B31C4 for ; Mon, 20 Apr 2015 14:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lF88-3jWXTs for ; Mon, 20 Apr 2015 14:03:05 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BFCC1B31A8 for ; Mon, 20 Apr 2015 14:03:05 -0700 (PDT) Received: by pabsx10 with SMTP id sx10so218281311pab.3 for ; Mon, 20 Apr 2015 14:03:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=L6tx75tIksOZGowdcq6H69JhS+Xs/+uZAsTbsqvI5jM=; b=mW+5mXVuLD4NC2bdyDWRHfuYxCiWZNWulEuYFvHZnExOcuIwj7sxVfzOM3JiCfOjmH TqPIO8TXGzsH6Pl2vaej0cWCQzoSlHnT5d2BRbufvfyEtl+8rQbySMUILOQPLdr7bqKU Vc/V57eizRVh2YZLNpFc5kJOHj0TAq6+B4wL9TqP1q3pow4Iu5j+3ADNV6+JCR3ly7+x Vq66ryhaUMIJW1Zkgi43VVlP74oJocDcPpOzwigqIs8GPHt4+JX+Rk+F/hCQatEzkjQE qQCXpZ0YC74uITD9reflfJW5r+0zePOocnjuN6wNqQoOdXaMAd9Iy+k7fGqvZGwQ7A0N MtkA== X-Received: by 10.68.231.66 with SMTP id te2mr31478692pbc.118.1429563785339; Mon, 20 Apr 2015 14:03:05 -0700 (PDT) Received: from ?IPv6:2406:e007:679c:1:28cc:dc4c:9703:6781? ([2406:e007:679c:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id ae9sm19215708pac.25.2015.04.20.14.03.02 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Apr 2015 14:03:04 -0700 (PDT) Message-ID: <55356988.1040806@gmail.com> Date: Tue, 21 Apr 2015 09:03:04 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Anima WG References: <20150420205729.30661.85680.idtracker@ietfa.amsl.com> In-Reply-To: <20150420205729.30661.85680.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-carpenter-anima-gdn-protocol-03.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 21:03:07 -0000 Hi, This is updated in several ways: Removed intrinsic security, required external security Format changes to allow ADNCP co-existence Recognized DNS-SD as alternative discovery method Editorial improvements Please read and comment. This is not by any means a final proposal and we really need feedback from the group. Regards Brian Carpenter On 21/04/2015 08:57, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : A Generic Discovery and Negotiation Protocol for Autonomic Networking > Authors : Brian Carpenter > Bing Liu > Filename : draft-carpenter-anima-gdn-protocol-03.txt > Pages : 40 > Date : 2015-04-20 > > Abstract: > This document establishes requirements for a protocol that enables > intelligent devices to dynamically discover peer devices, to > synchronize state with them, and to negotiate parameter settings > mutually with them. The document then defines a general protocol for > discovery, synchronization and negotiation, while the technical > objectives for specific scenarios are to be described in separate > documents. An Appendix briefly discusses existing protocols with > comparable features. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-carpenter-anima-gdn-protocol/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-carpenter-anima-gdn-protocol-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-carpenter-anima-gdn-protocol-03 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Mon Apr 20 20:49:55 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 628E71A901F for ; Mon, 20 Apr 2015 20:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDROLl3lZibN for ; Mon, 20 Apr 2015 20:49:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E8D41A8974 for ; Mon, 20 Apr 2015 20:49:52 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRQ16646; Tue, 21 Apr 2015 03:49:50 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 21 Apr 2015 04:49:49 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.135]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Tue, 21 Apr 2015 11:49:44 +0800 From: Sheng Jiang To: Brian E Carpenter , Anima WG Thread-Topic: [Anima] I-D Action: draft-carpenter-anima-gdn-protocol-03.txt Thread-Index: AQHQe61sgfNV/qNVXEOR50865R5jKp1WvQSA Date: Tue, 21 Apr 2015 03:49:43 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B925F50377F@nkgeml512-mbx.china.huawei.com> References: <20150420205729.30661.85680.idtracker@ietfa.amsl.com> <55356988.1040806@gmail.com> In-Reply-To: <55356988.1040806@gmail.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.197] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] I-D Action: draft-carpenter-anima-gdn-protocol-03.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 03:49:54 -0000 SGksIEJyaWFuLA0KDQpBIGZldyBmZWVkYmFjayBpbiBsaW5lcy4gSSBvbmx5IHJlYWQgdGhlIGRp ZmYuDQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IEFuaW1hIFttYWlsdG86 YW5pbWEtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJyaWFuIEUNCj5DYXJwZW50ZXIN Cj5TZW50OiBUdWVzZGF5LCBBcHJpbCAyMSwgMjAxNSA1OjAzIEFNDQo+VG86IEFuaW1hIFdHDQo+ U3ViamVjdDogUmU6IFtBbmltYV0gSS1EIEFjdGlvbjogZHJhZnQtY2FycGVudGVyLWFuaW1hLWdk bi1wcm90b2NvbC0wMy50eHQNCj4NCj5IaSwNCj4NCj5UaGlzIGlzIHVwZGF0ZWQgaW4gc2V2ZXJh bCB3YXlzOg0KPg0KPiBSZW1vdmVkIGludHJpbnNpYyBzZWN1cml0eSwgcmVxdWlyZWQgZXh0ZXJu YWwgc2VjdXJpdHkNCg0KSW4gcHJpbmNpcGxlLCB0aGlzIGlzIGZpbmUuIEJ1dCB0aGUgY3VycmVu dCB0ZXh0IG9mIGV4dGVybmFsIHNlY3VyaXR5IGFyZSB1bmNsZWFyLCBwYXJ0aWN1bGFybHksIG9u IGhvdyB0byBib3VuZCB3aXRoIFRMUyBvciBEVExTLg0KDQpBbHNvLCBpbiBzZWN0aW9uIDMuMy4x LCAiSWYgdGhpcyBpcyBpbXBvc3NpYmxlICh0byBydW4gd2l0aGluIEFDUCksIC4uLiIuIFRoZXJl IGFyZSB0d28gaXNzdWVzIGluIHRoaXMgc2VudGVuY2U6IGEpIGhvdyB0byBkZWZpbmUgb3IgZGV0 ZWN0IGltcG9zc2libGU7IGIpIHNob3VsZCBpdCBiZSBhbGxvd2VkIHRoZSBBTiBub2RlIGNob29z ZSBub3QgdG8gdXNlIEFDUCBldmVuIHdoZW4gQUNQIGlzIGF2YWlsYWJsZS4gRm9yIHRoZSBzZWNv bmQgcG9pbnQsIEkgY2FuIHVuZGVyc3RhbmQgZm9yIGF1dG9ub21pYyBwdXJwb3NlLCB3ZSBtYXkg bm90IHdhbnQgdG9vIG11Y2ggYWx0ZXJuYXRpdmUgKG90aGVyd2lzZSwgdGhlIEFOIG5vZGUgbWF5 IGRlcGVuZCBvbiBjb25maWd1cmF0aW9uIHRvIGNob29zZSkuIElmIHNvLCBpdCB3b3VsZCBiZSBo ZWxwIHRvIGNsYXJpZnkgdGhlIGRlc2lnbiBwdXJwb3NlLCBoZXJlOyBhbmQgaXQgcmVxdWVzdHMg YSBjbGVhciBiZWhhdmlvciBzcGVjaWZpY2F0aW9uIHRvIGRldGVjdCB0aGUgYXZhaWxhYmlsaXR5 IG9mIEFDUC4NCg0KVGhlIG5ldyBzZWN0aW9uIDMuMy4yIGlzIHNsdXIuIFRoaXMgd2lsbCBjZXJ0 YWlubHkgaW50cm9kdWNlIGNvbmZ1c2lvbiBmb3IgaW1wbGVtZW50b3JzLiBUaGUgd2F5IHRoYXQg c2hvcnQgbWVzc2FnZXMgdXNlIFVTUCBhbmQgbG9uZ2VyIG1lc3NhZ2VzIHVzZSBUQ1AgaXMgbm90 IGZlYXNpYmxlLiBUQ1AgYXJlIHNlc3Npb25zIGZvciBhIHNldCBvZiBtZXNzYWdlIGV4Y2hhbmdp bmcuIElmIGEgc2Vzc2lvbiBzdGFydHMgZnJvbSBhIHNob3J0IG1lc3NhZ2UsIHRoZW4gb25lIG9m IGZvbGxvdy11cCBtZXNzYWdlIGlzIGEgbG9uZyBtZXNzYWdlLCBJIGRvbid0IHRoaW5rIHRoZSBj b21tdW5pY2F0aW9uIHBhaXIgY2FuIGNoYW5nZSBmcm9tIFVEUCB0byBUQ1AuIFZpY2UgdmVyc2Uu DQoNCkJ5IHJlbW92aW5nIERldmljZSBJZGVudGlmaWVyIGFuZCB0YWcsIHRoZSBjdXJyZW50IGRv Y3VtZW50IHNlZW1zIG9wZW4gYSBkZXNpZ24gaG9sZSBvbiBob3cgdG8gaWRlbnRpZnkgdGhlIGNv bW11bmljYXRpb24gcGVlcnMuIEkgYW0gbm90IHN1cmUgSVAgYWRkcmVzc2VzLCB3aGljaCBhcmUg bm9ybWFsbHkgbG9jYXRvcnMsIGFyZSBzdWZmaWNpZW50IGFuZCBlZmZpY2llbnQgdG8gYmUgdGhl IGlkZW50aWZpZXIuIEFsdGhvdWdoIHRoZXJlIGlzIGEgbmV3bHkgYWRkZWQgRGV2aWNlIElkZW50 aXR5IE9wdGlvbiBpbiBuZXcgMy43LjYsIGl0IGlzIHVuY2xlYXIgaG93IHRvIHVzZSBpdCAoYmVz aWRlcyB0aGUgZGVmaW5pdGlvbiBzZXNzaW9uLCBub3doZXJlIGhhdmUgbWVudGlvbmVkIGl0KS4N Cg0KDQo+IEZvcm1hdCBjaGFuZ2VzIHRvIGFsbG93IEFETkNQIGNvLWV4aXN0ZW5jZQ0KPiBSZWNv Z25pemVkIEROUy1TRCBhcyBhbHRlcm5hdGl2ZSBkaXNjb3ZlcnkgbWV0aG9kDQoNCkkgZ3Vlc3Mg dGhlIGRvY3VtZW50IHNob3VsZCBlbXBoYXNpcyB0aGF0IG5lZ290aWF0aW9uIGFyZSBpbmRlcGVu ZGVudCBmcm9tIGRpc2NvdmVyeSwgYWx0aG91Z2ggdGhlIHJhcGlkIGRpc2NvdmVyeSBtb2RlbCBp bmNsdWRlcyB0aGUgZmlyc3Qgc3RlcCBvZiBhIG5lZ290aWF0aW9uLg0KDQpCZXN0IHJlZ2FyZHMs DQoNClNoZW5nDQoNCj4gRWRpdG9yaWFsIGltcHJvdmVtZW50cw0KPg0KPlBsZWFzZSByZWFkIGFu ZCBjb21tZW50LiBUaGlzIGlzIG5vdCBieSBhbnkgbWVhbnMgYSBmaW5hbCBwcm9wb3NhbA0KPmFu ZCB3ZSByZWFsbHkgbmVlZCBmZWVkYmFjayBmcm9tIHRoZSBncm91cC4NCj4NCj5SZWdhcmRzDQo+ ICAgQnJpYW4gQ2FycGVudGVyDQo+DQo+T24gMjEvMDQvMjAxNSAwODo1NywgaW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnIHdyb3RlOg0KPj4NCj4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWls YWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cw0KPmRpcmVjdG9yaWVzLg0KPj4N Cj4+DQo+PiAgICAgICAgIFRpdGxlICAgICAgICAgICA6IEEgR2VuZXJpYyBEaXNjb3ZlcnkgYW5k IE5lZ290aWF0aW9uIFByb3RvY29sDQo+Zm9yIEF1dG9ub21pYyBOZXR3b3JraW5nDQo+PiAgICAg ICAgIEF1dGhvcnMgICAgICAgICA6IEJyaWFuIENhcnBlbnRlcg0KPj4gICAgICAgICAgICAgICAg ICAgICAgICAgICBCaW5nIExpdQ0KPj4gCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWNhcnBlbnRl ci1hbmltYS1nZG4tcHJvdG9jb2wtMDMudHh0DQo+PiAJUGFnZXMgICAgICAgICAgIDogNDANCj4+ IAlEYXRlICAgICAgICAgICAgOiAyMDE1LTA0LTIwDQo+Pg0KPj4gQWJzdHJhY3Q6DQo+PiAgICBU aGlzIGRvY3VtZW50IGVzdGFibGlzaGVzIHJlcXVpcmVtZW50cyBmb3IgYSBwcm90b2NvbCB0aGF0 IGVuYWJsZXMNCj4+ICAgIGludGVsbGlnZW50IGRldmljZXMgdG8gZHluYW1pY2FsbHkgZGlzY292 ZXIgcGVlciBkZXZpY2VzLCB0bw0KPj4gICAgc3luY2hyb25pemUgc3RhdGUgd2l0aCB0aGVtLCBh bmQgdG8gbmVnb3RpYXRlIHBhcmFtZXRlciBzZXR0aW5ncw0KPj4gICAgbXV0dWFsbHkgd2l0aCB0 aGVtLiAgVGhlIGRvY3VtZW50IHRoZW4gZGVmaW5lcyBhIGdlbmVyYWwgcHJvdG9jb2wNCj5mb3IN Cj4+ICAgIGRpc2NvdmVyeSwgc3luY2hyb25pemF0aW9uIGFuZCBuZWdvdGlhdGlvbiwgd2hpbGUg dGhlIHRlY2huaWNhbA0KPj4gICAgb2JqZWN0aXZlcyBmb3Igc3BlY2lmaWMgc2NlbmFyaW9zIGFy ZSB0byBiZSBkZXNjcmliZWQgaW4gc2VwYXJhdGUNCj4+ICAgIGRvY3VtZW50cy4gIEFuIEFwcGVu ZGl4IGJyaWVmbHkgZGlzY3Vzc2VzIGV4aXN0aW5nIHByb3RvY29scyB3aXRoDQo+PiAgICBjb21w YXJhYmxlIGZlYXR1cmVzLg0KPj4NCj4+DQo+PiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMg cGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWNhcnBlbnRlci1hbmltYS1nZG4tcHJvdG9jb2wvDQo+Pg0KPj4gVGhlcmUncyBh bHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+PiBodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1jYXJwZW50ZXItYW5pbWEtZ2RuLXByb3RvY29sLTAzDQo+Pg0KPj4g QSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPj4gaHR0 cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtY2FycGVudGVyLWFuaW1hLWdkbi1w cm90b2NvbC0wMw0KPj4NCj4+DQo+PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291 cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPnN1Ym1pc3Npb24NCj4+IHVudGlsIHRo ZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5v cmcuDQo+Pg0KPj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1v dXMgRlRQIGF0Og0KPj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4+DQo+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gSS1E LUFubm91bmNlIG1haWxpbmcgbGlzdA0KPj4gSS1ELUFubm91bmNlQGlldGYub3JnDQo+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZQ0KPj4gSW50ZXJu ZXQtRHJhZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwNCj4+ IG9yIGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0DQo+Pg0KPg0KPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+QW5pbWEgbWFp bGluZyBsaXN0DQo+QW5pbWFAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2FuaW1hDQo= From nobody Mon Apr 20 21:49:31 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F151B2CD7 for ; Mon, 20 Apr 2015 21:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edZFEQjxmzzu for ; Mon, 20 Apr 2015 21:49:27 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EDA11B2CB7 for ; Mon, 20 Apr 2015 21:49:27 -0700 (PDT) Received: by pabtp1 with SMTP id tp1so229175379pab.2 for ; Mon, 20 Apr 2015 21:49:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=FFppLghrWcG5VT7QvRWL9snoRZ6Qi/T2QZBIBzc38oM=; b=YhggWxuJfM08052czgHC9b203PdHUPj7658l+9LuoSBbx79RhFgiV3DhDr92zVqtCB Vx1OR+vQ3QjQ8g8MQOGv3FvpW8QZMZXbca+n97BBnhVc8b+jE2+fut+0CoXh7c/kd5bB wvKip0IFp+HHHQPYdP1ZpovxeWKKV8MByo15JZaTwyl4zeNLH5fwAFWddkqvTuqQqIRM ZPOZ8Jv/JyIs1253XwTSsey9ucUKW1XUmP0qF8CwCPaexqoEiX+TT/N5NWsmU57uIWhB 1Uhh/nz7pXqGBjLIxrFUSfgkDGInPbkrcPX6pFhuZyMH5PomwuGxOw9JLJ6roikwnFKy 17DA== X-Received: by 10.70.45.16 with SMTP id i16mr34021191pdm.51.1429591767253; Mon, 20 Apr 2015 21:49:27 -0700 (PDT) Received: from ?IPv6:2406:e007:679c:1:28cc:dc4c:9703:6781? ([2406:e007:679c:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id jc6sm582052pbd.4.2015.04.20.21.49.24 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Apr 2015 21:49:26 -0700 (PDT) Message-ID: <5535D6D7.9010908@gmail.com> Date: Tue, 21 Apr 2015 16:49:27 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Sheng Jiang , Anima WG References: <20150420205729.30661.85680.idtracker@ietfa.amsl.com> <55356988.1040806@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F50377F@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B925F50377F@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-carpenter-anima-gdn-protocol-03.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 04:49:30 -0000 Hi Sheng, thanks for the comments. On 21/04/2015 15:49, Sheng Jiang wrote: > Hi, Brian, > > A few feedback in lines. I only read the diff. > >> -----Original Message----- >> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E >> Carpenter >> Sent: Tuesday, April 21, 2015 5:03 AM >> To: Anima WG >> Subject: Re: [Anima] I-D Action: draft-carpenter-anima-gdn-protocol-03.txt >> >> Hi, >> >> This is updated in several ways: >> >> Removed intrinsic security, required external security > > In principle, this is fine. But the current text of external security are unclear, particularly, on how to bound with TLS or DTLS. I agree. This clearly needs to be made more precise as we go forward. > Also, in section 3.3.1, "If this is impossible (to run within ACP), ...". There are two issues in this sentence: a) how to define or detect impossible; Yes, I would like to hear from the ACP authors about that. > b) should it be allowed the AN node choose not to use ACP even when ACP is available. My opinion was no, and a strict interpretation of the RFC 2119 "SHOULD" is needed. We can make it more clear, of course. > For the second point, I can understand for autonomic purpose, we may not want too much alternative (otherwise, the AN node may depend on configuration to choose). If so, it would be help to clarify the design purpose, here; and it requests a clear behavior specification to detect the availability of ACP. > > The new section 3.3.2 is slur. This will certainly introduce confusion for implementors. The way that short messages use USP and longer messages use TCP is not feasible. TCP are sessions for a set of message exchanging. If a session starts from a short message, then one of follow-up message is a long message, I don't think the communication pair can change from UDP to TCP. Vice verse. We should study how DNS handles this issue. The problem should be the same. > > By removing Device Identifier and tag, the current document seems open a design hole on how to identify the communication peers. I am not sure IP addresses, which are normally locators, are sufficient and efficient to be the identifier. I was assuming that ACP or (D)TLS would guarantee identity. Maybe that is naive? > Although there is a newly added Device Identity Option in new 3.7.6, it is unclear how to use it (besides the definition session, nowhere have mentioned it). Yes. It is a placeholder for now. If we need it, we have to expand it, but that is not clear yet and we would like some help from security experts. >> Format changes to allow ADNCP co-existence >> Recognized DNS-SD as alternative discovery method > > I guess the document should emphasis that negotiation are independent from discovery, although the rapid discovery model includes the first step of a negotiation. Yes, that could be stated clearly in the High-Level Design Choices. Regards Brian > > Best regards, > > Sheng > >> Editorial improvements >> >> Please read and comment. This is not by any means a final proposal >> and we really need feedback from the group. >> >> Regards >> Brian Carpenter >> >> On 21/04/2015 08:57, internet-drafts@ietf.org wrote: >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >>> >>> >>> Title : A Generic Discovery and Negotiation Protocol >> for Autonomic Networking >>> Authors : Brian Carpenter >>> Bing Liu >>> Filename : draft-carpenter-anima-gdn-protocol-03.txt >>> Pages : 40 >>> Date : 2015-04-20 >>> >>> Abstract: >>> This document establishes requirements for a protocol that enables >>> intelligent devices to dynamically discover peer devices, to >>> synchronize state with them, and to negotiate parameter settings >>> mutually with them. The document then defines a general protocol >> for >>> discovery, synchronization and negotiation, while the technical >>> objectives for specific scenarios are to be described in separate >>> documents. An Appendix briefly discusses existing protocols with >>> comparable features. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-carpenter-anima-gdn-protocol/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-carpenter-anima-gdn-protocol-03 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-carpenter-anima-gdn-protocol-03 >>> >>> >>> Please note that it may take a couple of minutes from the time of >> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima From nobody Tue Apr 21 17:41:37 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333961B2F8B for ; Tue, 21 Apr 2015 17:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97tQF6deuJwq for ; Tue, 21 Apr 2015 17:41:34 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A29FB1B2F8A for ; Tue, 21 Apr 2015 17:41:34 -0700 (PDT) Received: by pdbnk13 with SMTP id nk13so257506900pdb.0 for ; Tue, 21 Apr 2015 17:41:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=8kxZX7JbwJ4kApYC0AQ3XHf4/ctA5D37GCJvE0jBtek=; b=HYwJ1GZkeYSnFVU7zkryPuCoFGpJjvZe5vt7ZSc0ro4H42k8lI1qYKY9KyB57nvdbC drjvefwa8RONeCGLntHxC0/3IFvCZiXP4kMee9naBHP0OYS/pJdNv4d9eGvPXfwtPWzu vTqlKq67g+qAa/+CDwEajqaS+1/aU8sEWB49fEQ0MWVbhdwIErDWdcehyA8mxX4nbdLK t5fB407cMDBOdSXKlO+evqhnvHuQSFChCzrEfoev6CUdEBxI+lhtWFvdNFTy+jHJbz2C fReAs9Tt+gER0lq/gqIDYC82WU0/IkqVBG3KhJ3bK8TSyzwLS1Vq7FlCQ36cnMrX8Ve6 wWYQ== X-Received: by 10.70.118.194 with SMTP id ko2mr42502662pdb.162.1429663294375; Tue, 21 Apr 2015 17:41:34 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by mx.google.com with ESMTPSA id x4sm3197231pdl.55.2015.04.21.17.41.31 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Apr 2015 17:41:32 -0700 (PDT) Message-ID: <5536EE40.30705@gmail.com> Date: Wed, 22 Apr 2015 12:41:36 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Anima WG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Multicast in the ACP? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 00:41:36 -0000 This is a question to the authors of draft-behringer-anima-autonomic-control-plane. The discovery component of GDNP includes link-local multicast messages. As far as we know, there is no way to secure these messages, but by definition they are only intended for autonomic nodes, which should all be part of the ACP. So, is there any way to support secure link-local multicast within the ACP? Brian From nobody Wed Apr 22 09:46:40 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDE171A0033 for ; Wed, 22 Apr 2015 09:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3hJMP7m6NYr for ; Wed, 22 Apr 2015 09:46:38 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 918FB1B37FA for ; Wed, 22 Apr 2015 09:46:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3856; q=dns/txt; s=iport; t=1429721184; x=1430930784; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ZuMdvgVvwrhPuU7qaCf+7rJrT1EkteNzs3Xo6gY2GYI=; b=lz20JqGuoHIKLw6CueB+yd0BLRwfak+FqJ66rGVQNrZm1Wke40ALqJ7/ 2qCVy4OdZ+pDQB7q/hh0CNhkojgF4c+3GiWrgV7PhudrMiIL2a64KjtUd 8V5/vhjH4GokVxEEX7fSiZYjngfwjE3Zf1KRZzPpWMiXlKJ/O0O2JkRji g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BiBAAzzzdV/5JdJa1bgwxSXAWDE8IKZgmBT4YEAhyBHDgUAQEBAQEBAYEKhCABAQEEIxFDDgQCAQgRBAEBAwIGHQMCAgIwFAEGAQEFAwIEEwgBiCINt2mVAQEBAQEBAQEBAQEBAQEBAQEBAQEBGIEhihaEUzgGgmIvgRYFkTuEAYdLO4MCgm6NZCKCHhmBPG+BRIEAAQEB X-IronPort-AV: E=Sophos;i="5.11,624,1422921600"; d="scan'208";a="143585023" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-2.cisco.com with ESMTP; 22 Apr 2015 16:46:23 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t3MGkNUM011503 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 22 Apr 2015 16:46:23 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.216]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Wed, 22 Apr 2015 11:46:23 -0500 From: "Michael Behringer (mbehring)" To: Anima WG Thread-Topic: New Version Notification for draft-behringer-anima-autonomic-addressing-00.txt Thread-Index: AQHQfNcbOn7wiUyjeUOLCb4h9AXCM51Y5cKA Date: Wed, 22 Apr 2015 16:46:23 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22F5FE4E@xmb-rcd-x14.cisco.com> References: <20150422083359.25790.38929.idtracker@ietfa.amsl.com> In-Reply-To: <20150422083359.25790.38929.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.133] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Anima] FW: New Version Notification for draft-behringer-anima-autonomic-addressing-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 16:46:40 -0000 QU5JTUEsIA0KDQpMb29raW5nIGF0IHRoZSByZWZlcmVuY2UgbW9kZWwsIGFkZHJlc3NpbmcgaXMg YW4gaW1wb3J0YW50IHBhcnQuIEkndmUgYmVlbiBoZXNpdGF0aW5nIG9uIGhvdyB0byBwdXQgbWF0 ZXJpYWxzIGludG8gdGhlIHJlZmVyZW5jZSBtb2RlbCB0aGF0IG1heSBzdGlsbCBldm9sdmUgaW4g YSBkaWZmZXJlbnQgZGlyZWN0aW9uLCBhbmQgSSB0aGluayBpdGVtcyBzdWNoIGFzIGFkZHJlc3Np bmcgd2hlcmUgd2UgZXNzZW50aWFsbHkgbmVlZCB0byBzZXR0bGUgb24gYSBjb21tb24gbW9kZWwg bWF5IGJlIGJldHRlciBkaXNjdXNzZWQgb3V0c2lkZSB0aGUgcmVmZXJlbmNlIG1vZGVsIGZvciBu b3cuIA0KDQpTbywgaW4gdGhlIGVuZCBJIHB1c2hlZCB0aGUgdGV4dCBhcyBhIHNlcGFyYXRlIGRy YWZ0IGZvciBub3csIHdpdGggdGhlIGV4cGVjdGF0aW9uIHRoYXQgYW4gYWRkcmVzc2luZyBjb25j ZXB0IHdpbGwgbWVyZ2UgaW50byB0aGUgcmVmZXJlbmNlIG1vZGVsIGxhdGVyIG9uLiBCdXQgaXQg d2lsbCBsaWtlbHkgZXZvbHZlIGZyb20gdGhlIGJlbG93LiANCg0KU28gcGxlYXNlIHJlYWQgdGhl IGJlbG93IGNvdXBsZSBvZiBwYWdlcyBpbiB0aGlzIGxpZ2h0LiBJdCBpcyBkb2N1bWVudGluZyB3 aGF0IENpc2NvJ3MgYXV0b25vbWljIGltcGxlbWVudGF0aW9uIGlzIGRvaW5nIHJpZ2h0IG5vdy4g VGhlcmUgYXJlIG1hbnkgd2F5cyB0byBkbyB0aGlzLCBzbyBJIHdvdWxkIGVuY291cmFnZSBwZW9w bGUgd2l0aCBvdGhlciBpZGVhcyB0byBhbHNvIHB1Ymxpc2ggdGhlbSAob3IgYXQgbGVhc3Qgc2Vu ZCB0aGUgcHJvcG9zZWQgdGV4dCB0byB0aGUgbGlzdCkgc28gdGhhdCB3ZSBjYW4gaGF2ZSBhIGZy dWl0ZnVsIGRpc2N1c3Npb24uIA0KDQpNaWNoYWVsDQoNClBTOiBJIHB1Ymxpc2hlZCB0aGlzIGRv YyB5ZXN0ZXJkYXksIGJ1dCBmb3Jnb3QgdG8gYWRkIHRoZSAiYW5pbWEiIGluIHRoZSB0aXRsZSwg c28gdGhpcyBvbmUgaXMganVzdCBhIHJlLXBvc3Qgd2l0aCB0aGUgY29ycmVjdCB0aXRsZS4gDQoN Cg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+IFNlbnQ6IDIyIEFw cmlsIDIwMTUgMTA6MzQNCj4gVG86IE1pY2hhZWwgQmVocmluZ2VyIChtYmVocmluZyk7IE1pY2hh ZWwgQmVocmluZ2VyIChtYmVocmluZykNCj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1iZWhyaW5nZXItYW5pbWEtYXV0b25vbWljLQ0KPiBhZGRyZXNzaW5nLTAw LnR4dA0KPiANCj4gDQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1iZWhyaW5nZXItYW5p bWEtYXV0b25vbWljLWFkZHJlc3NpbmctMDAudHh0DQo+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBz dWJtaXR0ZWQgYnkgTWljaGFlbCBILiBCZWhyaW5nZXIgYW5kIHBvc3RlZCB0byB0aGUNCj4gSUVU RiByZXBvc2l0b3J5Lg0KPiANCj4gTmFtZToJCWRyYWZ0LWJlaHJpbmdlci1hbmltYS1hdXRvbm9t aWMtYWRkcmVzc2luZw0KPiBSZXZpc2lvbjoJMDANCj4gVGl0bGU6CQlBbiBBdXRvbm9taWMgSVB2 NiBBZGRyZXNzaW5nIFNjaGVtZQ0KPiBEb2N1bWVudCBkYXRlOgkyMDE1LTA0LTIyDQo+IEdyb3Vw OgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+IFBhZ2VzOgkJNQ0KPiBVUkw6ICAgICAgICAgICAg aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYmVocmluZ2VyLWFuaW1h LQ0KPiBhdXRvbm9taWMtYWRkcmVzc2luZy0wMC50eHQNCj4gU3RhdHVzOiAgICAgICAgIGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJlaHJpbmdlci1hbmltYS0NCj4gYXV0 b25vbWljLWFkZHJlc3NpbmcvDQo+IEh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1iZWhyaW5nZXItYW5pbWEtYXV0b25vbWljLQ0KPiBhZGRyZXNzaW5nLTAw DQo+IA0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgZ2Vu ZXJpYyBJUHY2IGFkZHJlc3Npbmcgc2NoZW1lIHdoaWNoIGlzDQo+ICAgIHN1aXRhYmxlIGZvciBh dXRvbm9taWMgbm9kZXMsIHdoZXJlIG5vZGUgYWRkcmVzc2luZyBtdXN0IG5vdCBkZXBlbmQNCj4g ICAgb24gYSBjZW50cmFsbHkgbWFuYWdlZCBzY2hlbWUuICBJdCBhc3N1bWVzIGEgdW5pcXVlIGRv bWFpbiBuYW1lIGFuZA0KPiAgICBkZXZpY2UgbmFtZSwgYW5kIGF1dG9tYXRpY2FsbHkgZGVyaXZl cyBhIHVuaXF1ZSBJUHY2IGFkZHJlc3MgZnJvbQ0KPiAgICB0aG9zZS4gIFRoZSBzY2hlbWUgYWxs b3dzIGZvciBhIGZsYXQgYWRkcmVzcyBoaWVyYXJjaHkgYXMgd2VsbCBhcw0KPiAgICBvcHRpb25h bGx5LCB3aGVuIHJlcXVpcmVkLCB0aGUgZGVmaW5pdGlvbiBvZiB6b25lcyB3aGljaCBhcmUNCj4g ICAgYWdncmVnYXRhYmxlLiAgVGhpcyBkb2N1bWVudCBpcyBmb3IgZGlzY3Vzc2lvbiByaWdodCBu b3c7IHRoZSBmaW5hbA0KPiAgICBhZGRyZXNzaW5nIHNjaGVtZSBzaG91bGQgcHJvYmFibHkgbW92 ZSBpbnRvDQo+ICAgIFtJLUQuYmVocmluZ2VyLWFuaW1hLXJlZmVyZW5jZS1tb2RlbF0uDQo+IA0K PiANCj4gDQo+IA0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1p bnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2 ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+IA0KPiBU aGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Wed Apr 22 09:47:00 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 063A81A923C for ; Wed, 22 Apr 2015 09:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyTv_NhSM8xA for ; Wed, 22 Apr 2015 09:46:57 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D88471B37F4 for ; Wed, 22 Apr 2015 09:46:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=742; q=dns/txt; s=iport; t=1429721213; x=1430930813; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=8ROw3RN0wMIz6gT5mTqhpafdvJf5L6ShdYQrQQ4+okQ=; b=IohncKb0BkCk30xjPUvqw+YclgvIGGH+z9e3uhh8akpgYBKziQOw4joM ft2n5WRmfvR4lF01uSJ/WoGu1W6MenJi4t1Tzo0IrvzzPcFExktV+YBqp 5J7r1zpyRD2nIVhSe8qNE5G6SfW89AjtlU0LTdJJNJjkJv0Fg7uZW9eEx U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BcBAAk0DdV/5BdJa1bgwyBM8UdZgmHUwKBODgUAQEBAQEBAYEKhCABAQEDATpECwIBCCIUEDIlAgQBGogbCMx8AQEBAQEBAQEBAQEBAQEBAQEbizeEUziDF4EWAQSRO59bIoNzgjOBAAEBAQ X-IronPort-AV: E=Sophos;i="5.11,624,1422921600"; d="scan'208";a="143590861" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-4.cisco.com with ESMTP; 22 Apr 2015 16:46:52 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t3MGkqnl019615 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Apr 2015 16:46:52 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.216]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Wed, 22 Apr 2015 11:46:51 -0500 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , Anima WG Thread-Topic: [Anima] Multicast in the ACP? Thread-Index: AQHQfJUaUwzFV/cxjEm04y5x0wsfl51Y9lZg Date: Wed, 22 Apr 2015 16:46:51 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22F5FE63@xmb-rcd-x14.cisco.com> References: <5536EE40.30705@gmail.com> In-Reply-To: <5536EE40.30705@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.133] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Multicast in the ACP? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 16:46:59 -0000 Brian,=20 > The discovery component of GDNP includes link-local multicast messages. > As far as we know, there is no way to secure these messages, but by > definition they are only intended for autonomic nodes, which should all b= e > part of the ACP. >=20 > So, is there any way to support secure link-local multicast within the AC= P? The ACP as described in draft-behringer-anima-autonomic-control-plane is ba= sed on a hop by hop tunnel infrastructure. So far those tunnels are all poi= nt to point. I guess you can send a link-local multicast packet through suc= h a tunnel, and it would automatically benefit from the security of that tu= nnel. But of course there is only one other node on that "link".=20 Michael From nobody Wed Apr 22 13:09:18 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B924C1B39E6 for ; Wed, 22 Apr 2015 13:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFveEfjOt87U for ; Wed, 22 Apr 2015 13:09:15 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82E1F1B39DC for ; Wed, 22 Apr 2015 13:09:15 -0700 (PDT) Received: by pdea3 with SMTP id a3so283632157pde.3 for ; Wed, 22 Apr 2015 13:09:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5g+/CFES4ZHjXgyGziaJ86XGeS+8F7wTXzQChGQORsc=; b=dlo84pUZGwV+fhJJElGNRPHVEljK3Fm4hdf5KOYls+cNAU6kMaOizXgTRd3i/5Hz19 UdK8pDSmeoP7100RQJ2tZdNo1tyFdhVennng5plM9MPg3F0yABz9ZyeN7tzVXI7csxTJ zj2q33VQ7mCrS4oUT14vwR2mqRB7qWk6yT6OyJ1S5vHzKORCSe/vygtGgKIeIa8pEqAO WAzXhHomIozSIg1kxMs8r3QUpedqc/7c5MgreEnc+cfYz/u9dcG7nZAfHNyJkFuCnh9U KkblRwQUnewKt5JZyqtoOWd5ZA6hTm22sf/4qCIIvg8xuehFghmf1YxF69WG46fG+sia l76g== X-Received: by 10.66.224.109 with SMTP id rb13mr49095044pac.133.1429733355251; Wed, 22 Apr 2015 13:09:15 -0700 (PDT) Received: from ?IPv6:2406:e007:55fb:1:28cc:dc4c:9703:6781? ([2406:e007:55fb:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id xm7sm5965385pac.28.2015.04.22.13.09.12 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Apr 2015 13:09:14 -0700 (PDT) Message-ID: <5537FFEF.9020308@gmail.com> Date: Thu, 23 Apr 2015 08:09:19 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Michael Behringer (mbehring)" , Anima WG References: <5536EE40.30705@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F5FE63@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22F5FE63@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Multicast in the ACP? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 20:09:16 -0000 On 23/04/2015 04:46, Michael Behringer (mbehring) wrote: > Brian, > >> The discovery component of GDNP includes link-local multicast messages. >> As far as we know, there is no way to secure these messages, but by >> definition they are only intended for autonomic nodes, which should all be >> part of the ACP. >> >> So, is there any way to support secure link-local multicast within the ACP? > > The ACP as described in draft-behringer-anima-autonomic-control-plane is based on a hop by hop tunnel infrastructure. So far those tunnels are all point to point. I guess you can send a link-local multicast packet through such a tunnel, and it would automatically benefit from the security of that tunnel. But of course there is only one other node on that "link". Right, so we would have to specify a "replicast", where the sender copies the message to each ACP tunnel. That seems like a lot of overhead. Brian From nobody Wed Apr 22 14:26:41 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA321A911B for ; Wed, 22 Apr 2015 14:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZI3b3vrkptPe for ; Wed, 22 Apr 2015 14:26:36 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD1511A8AF7 for ; Wed, 22 Apr 2015 14:26:35 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 503D4203BC for ; Wed, 22 Apr 2015 17:38:08 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id EF19963B76; Wed, 22 Apr 2015 17:26:34 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id DD46D63784 for ; Wed, 22 Apr 2015 17:26:34 -0400 (EDT) From: Michael Richardson To: Anima WG In-Reply-To: <5537FFEF.9020308@gmail.com> References: <5536EE40.30705@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F5FE63@xmb-rcd-x14.cisco.com> <5537FFEF.9020308@gmail.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Anima] Multicast in the ACP? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 21:26:38 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >>> The discovery component of GDNP includes link-local multicast >>> messages. As far as we know, there is no way to secure these >>> messages, but by definition they are only intended for autonomic >>> nodes, which should all be part of the ACP. >>> >>> So, is there any way to support secure link-local multicast within >>> the ACP? >> >> The ACP as described in draft-behringer-anima-autonomic-control-plane >> is based on a hop by hop tunnel infrastructure. So far those tunnels >> are all point to point. I guess you can send a link-local multicast >> packet through such a tunnel, and it would automatically benefit from >> the security of that tunnel. But of course there is only one other >> node on that "link". > Right, so we would have to specify a "replicast", where the sender > copies the message to each ACP tunnel. That seems like a lot of > overhead. http://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/ describes a way to do multicast across that collection of links... that is if we can ever get it through the IESG. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVTgSCoCLcPvd0N1lAQKSgQgAjO/1BnvEeH55H4YIfaH4KCkj8/yGw8UO uraGQzBLAcRWM6jIQC+Y/xBWfmPdby8VA9ad0bFd78Iq9hXxRhSqgmFmRVZMGjn3 aS8GJDDz0NB/NIsPESH9dwKow4b6dcqF1UlqMRPIPomN6H+rM8HmK28MtiJgg/k7 nYqPFGXjulAa0KF87XtHFQVHAQVDv9mPHnOUi/rahCPJZLPY7tELOhp9YTfGUu6q iYIBxYdQP5LYkeLgmSvhQZsXonIsIVv/SUobl/eU2qxYEB/WcajfoNifkeF5+q2q ZeN12tYqegPGv/ho6oHucGJoeASM5OuXfuzWV75HTCGqJ4aKcst74A== =8+bw -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Apr 22 15:56:05 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 687AD1B2CD8 for ; Wed, 22 Apr 2015 15:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LOny4zzwyhp for ; Wed, 22 Apr 2015 15:56:01 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E5211B2CC3 for ; Wed, 22 Apr 2015 15:56:01 -0700 (PDT) Received: by pdbnk13 with SMTP id nk13so1115221pdb.0 for ; Wed, 22 Apr 2015 15:56:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=zSuyb3D5vlWVPlFsYgmF8V6aAOLuMUWXRSBGTdbOA10=; b=sI5atuH96bzTVfb5AAQHSJfdwAeli4oQOiIjAfKl0oiqbaO/1L/YQc3zTO2sz7LVbe 1X8Sg8AURV80UPQmIGaUVDgunXYuGNB2C/a/3bOkZ/OzFscAbJzLu0Y5dVHmDWTFcvFF EX+DOxAJwZrihw0p5tzA/m34F9VaiTzjx7h3r5kpWHQyFT0XFh+MeKuXKX49oSLLo7ef C7vLtrwSrTaOyehOocYcyaNyvHF/Bj3/uIcThWgG/i/Z5s/vMrI5IPv9xXriGR/AkgXZ 2/3BF0wDA5Ce726sbL8kQ2Y2s8tasxjVm95KnRWtLArEdNrbbTLSJ0Y/CgNJc1XPN545 LbCg== X-Received: by 10.66.55.104 with SMTP id r8mr46808680pap.75.1429743360976; Wed, 22 Apr 2015 15:56:00 -0700 (PDT) Received: from ?IPv6:2406:e007:55fb:1:28cc:dc4c:9703:6781? ([2406:e007:55fb:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id qd8sm6032637pbc.71.2015.04.22.15.55.58 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Apr 2015 15:55:59 -0700 (PDT) Message-ID: <55382705.3060605@gmail.com> Date: Thu, 23 Apr 2015 10:56:05 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: anima@ietf.org References: <5536EE40.30705@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F5FE63@xmb-rcd-x14.cisco.com> <5537FFEF.9020308@gmail.com> <10795.1429737994@sandelman.ca> In-Reply-To: <10795.1429737994@sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Multicast in the ACP? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 22:56:03 -0000 On 23/04/2015 09:26, Michael Richardson wrote: > > Brian E Carpenter wrote: > >>> The discovery component of GDNP includes link-local multicast > >>> messages. As far as we know, there is no way to secure these > >>> messages, but by definition they are only intended for autonomic > >>> nodes, which should all be part of the ACP. > >>> > >>> So, is there any way to support secure link-local multicast within > >>> the ACP? > >> > >> The ACP as described in draft-behringer-anima-autonomic-control-plane > >> is based on a hop by hop tunnel infrastructure. So far those tunnels > >> are all point to point. I guess you can send a link-local multicast > >> packet through such a tunnel, and it would automatically benefit from > >> the security of that tunnel. But of course there is only one other > >> node on that "link". > > > Right, so we would have to specify a "replicast", where the sender > > copies the message to each ACP tunnel. That seems like a lot of > > overhead. > > http://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/ > describes a way to do multicast across that collection of links... that is if > we can ever get it through the IESG. Interesting. That looks like overkill for ACPs that run over non-constrained networks, but it suggests to me that we need a modular approach, so that it could be used in networks that call for it. Brian From nobody Thu Apr 23 02:23:05 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 870361A8FD6 for ; Thu, 23 Apr 2015 02:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGicM_uEpSv5 for ; Thu, 23 Apr 2015 02:23:02 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C7281A8F46 for ; Thu, 23 Apr 2015 02:22:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1864; q=dns/txt; s=iport; t=1429780967; x=1430990567; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=m1ewSjs6WGc21rKkPdsC9eZJEJucF44p02k8laT0ARU=; b=iF5CfWi/UJW8XX/8k/WmtNbHU2FdbC4cVEUeXXpf9GJGOfWfQR+z7QGT lwgkAJbNjNT3EVqu2Lg2fSUcPcgMC3XRbla9UeANMczPGRXlBML/VVw+V Qbi6MbupudU2h6T0qrcmXZoTtuibnui76xfTV2eb68ycr8VO868PJhzwH E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CZBACOuThV/4UNJK1bgwyBLgWDFcJAZgmHUwIcgRw4FAEBAQEBAQGBCoQgAQEBBCMRUQQCAQgRBAEBAQICBh0DAgICHxEUAQgIAgQBEgiIDwMRtzOPTQ2FNwEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIYoWgk2CBhYiBoJiL4EWAQSRQYhhkEGGSyODc28BgUOBAAEBAQ X-IronPort-AV: E=Sophos;i="5.11,629,1422921600"; d="scan'208";a="143770016" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-3.cisco.com with ESMTP; 23 Apr 2015 09:21:21 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t3N9LLKJ004560 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Apr 2015 09:21:21 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.216]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Thu, 23 Apr 2015 04:21:21 -0500 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , Anima WG Thread-Topic: [Anima] Multicast in the ACP? Thread-Index: AQHQfJUaUwzFV/cxjEm04y5x0wsfl51Y9lZggADUv4CAAIkukA== Date: Thu, 23 Apr 2015 09:21:20 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22F626F8@xmb-rcd-x14.cisco.com> References: <5536EE40.30705@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F5FE63@xmb-rcd-x14.cisco.com> <5537FFEF.9020308@gmail.com> In-Reply-To: <5537FFEF.9020308@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.219.66] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Multicast in the ACP? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 09:23:03 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciBb bWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbV0NCj4gU2VudDogMjIgQXByaWwgMjAx NSAyMjowOQ0KPiBUbzogTWljaGFlbCBCZWhyaW5nZXIgKG1iZWhyaW5nKTsgQW5pbWEgV0cNCj4g U3ViamVjdDogUmU6IFtBbmltYV0gTXVsdGljYXN0IGluIHRoZSBBQ1A/DQo+IA0KPiBPbiAyMy8w NC8yMDE1IDA0OjQ2LCBNaWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpIHdyb3RlOg0KPiA+IEJy aWFuLA0KPiA+DQo+ID4+IFRoZSBkaXNjb3ZlcnkgY29tcG9uZW50IG9mIEdETlAgaW5jbHVkZXMg bGluay1sb2NhbCBtdWx0aWNhc3QNCj4gbWVzc2FnZXMuDQo+ID4+IEFzIGZhciBhcyB3ZSBrbm93 LCB0aGVyZSBpcyBubyB3YXkgdG8gc2VjdXJlIHRoZXNlIG1lc3NhZ2VzLCBidXQgYnkNCj4gPj4g ZGVmaW5pdGlvbiB0aGV5IGFyZSBvbmx5IGludGVuZGVkIGZvciBhdXRvbm9taWMgbm9kZXMsIHdo aWNoIHNob3VsZA0KPiA+PiBhbGwgYmUgcGFydCBvZiB0aGUgQUNQLg0KPiA+Pg0KPiA+PiBTbywg aXMgdGhlcmUgYW55IHdheSB0byBzdXBwb3J0IHNlY3VyZSBsaW5rLWxvY2FsIG11bHRpY2FzdCB3 aXRoaW4gdGhlDQo+IEFDUD8NCj4gPg0KPiA+IFRoZSBBQ1AgYXMgZGVzY3JpYmVkIGluIGRyYWZ0 LWJlaHJpbmdlci1hbmltYS1hdXRvbm9taWMtY29udHJvbC1wbGFuZQ0KPiBpcyBiYXNlZCBvbiBh IGhvcCBieSBob3AgdHVubmVsIGluZnJhc3RydWN0dXJlLiBTbyBmYXIgdGhvc2UgdHVubmVscyBh cmUgYWxsDQo+IHBvaW50IHRvIHBvaW50LiBJIGd1ZXNzIHlvdSBjYW4gc2VuZCBhIGxpbmstbG9j YWwgbXVsdGljYXN0IHBhY2tldCB0aHJvdWdoDQo+IHN1Y2ggYSB0dW5uZWwsIGFuZCBpdCB3b3Vs ZCBhdXRvbWF0aWNhbGx5IGJlbmVmaXQgZnJvbSB0aGUgc2VjdXJpdHkgb2YgdGhhdA0KPiB0dW5u ZWwuIEJ1dCBvZiBjb3Vyc2UgdGhlcmUgaXMgb25seSBvbmUgb3RoZXIgbm9kZSBvbiB0aGF0ICJs aW5rIi4NCj4gDQo+IFJpZ2h0LCBzbyB3ZSB3b3VsZCBoYXZlIHRvIHNwZWNpZnkgYSAicmVwbGlj YXN0Iiwgd2hlcmUgdGhlIHNlbmRlciBjb3BpZXMNCj4gdGhlIG1lc3NhZ2UgdG8gZWFjaCBBQ1Ag dHVubmVsLiBUaGF0IHNlZW1zIGxpa2UgYSBsb3Qgb2Ygb3ZlcmhlYWQuDQoNCk5vdCBzdXJlIEkn bSB3aXRoIHlvdS4gQSB0dW5uZWwgaXMgcHJlc2VudGVkIGxpa2UgYW4gaW50ZXJmYWNlLiBXaGV0 aGVyIHlvdSBzZW5kIHRoZSBwYWNrZXQgb3V0IGEgbm9ybWFsIGludGVyZmFjZSBvciBhIHR1bm5l bCBpcyB0aGUgc2FtZT8gQ2FuIHlvdSBleHBhbmQ/IC4uLg0KDQpNaWNoYWVsDQoNCg== From nobody Thu Apr 23 07:42:06 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4421A914D for ; Thu, 23 Apr 2015 07:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGZ2hhQGvmdJ for ; Thu, 23 Apr 2015 07:42:02 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 929E11A9169 for ; Thu, 23 Apr 2015 07:41:44 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2B8B2203B9 for ; Thu, 23 Apr 2015 10:53:19 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 5141563B86; Thu, 23 Apr 2015 10:41:43 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3C14763784 for ; Thu, 23 Apr 2015 10:41:43 -0400 (EDT) From: Michael Richardson To: anima@ietf.org In-Reply-To: <55382705.3060605@gmail.com> References: <5536EE40.30705@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F5FE63@xmb-rcd-x14.cisco.com> <5537FFEF.9020308@gmail.com> <10795.1429737994@sandelman.ca> <55382705.3060605@gmail.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Anima] Multicast in the ACP? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 14:42:05 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> >> The ACP as described in >> draft-behringer-anima-autonomic-control-plane >> is based on a hop by >> hop tunnel infrastructure. So far those tunnels >> are all point to >> point. I guess you can send a link-local multicast >> packet through >> such a tunnel, and it would automatically benefit from >> the security >> of that tunnel. But of course there is only one other >> node on that >> "link". >> >> > Right, so we would have to specify a "replicast", where the sender > >> copies the message to each ACP tunnel. That seems like a lot of > >> overhead. >> >> http://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/ >> describes a way to do multicast across that collection of >> links... that is if we can ever get it through the IESG. > Interesting. That looks like overkill for ACPs that run over > non-constrained networks, but it suggests to me that we need a modular > approach, so that it could be used in networks that call for it. Given that the ACP's forwarding plane might be implemented in the control plane processor, the mismatch between link speeds and available processing power might cause one to conclude that while the network isn't constrained, the router is! I would consider, for instance, implementing the ACP as a user-space virtual-machine in the control plane processor. User-Mode-Linux can be compiled to run on a bunch of POSIX platforms, although Linux and FreeBSD are the ones most often tested. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVTkEpoCLcPvd0N1lAQIcoAf/TtZ/qPTDikFznn6IexJg8+AKSpDhbpnO xolbIlINQsWy7ZTD4Qbo6ry5Ks/TiIJPzX9+PRETFeFrrcONpU6BkFfuyykNuUfH ekXabPAOwj0pNGpuP44j+6OC55iME0W/f2CATqjmIXmE/ky4vAG7RcnUUMBYpTYG 1Zg7uOzbbz/3WmOaA9fbmNlX6GaCl9e7wKSRrZpKtkMyPJJvus/uRGKa4xfCuoNy Vfv2UyIuWvEyIMoiq3Gu27D3Hm+YljkheOuY+Wd9K2heTSJdFBDzCxM5MTtNofpn ahdyqFjtTs4HfZEgkA32m91EariKdahAgyx4PAR65NJNLbzyyf+ekg== =8APq -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Apr 23 07:45:44 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04CD81A1A8E for ; Thu, 23 Apr 2015 07:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hA0cjAEagMBf for ; Thu, 23 Apr 2015 07:45:41 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFB6F1A92EE for ; Thu, 23 Apr 2015 07:45:22 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CA737203B9; Thu, 23 Apr 2015 10:56:57 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id D8E7263B86; Thu, 23 Apr 2015 10:45:21 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id BF4CF63784; Thu, 23 Apr 2015 10:45:21 -0400 (EDT) From: Michael Richardson To: "Michael Behringer \(mbehring\)" In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22F626F8@xmb-rcd-x14.cisco.com> References: <5536EE40.30705@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F5FE63@xmb-rcd-x14.cisco.com> <5537FFEF.9020308@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F626F8@xmb-rcd-x14.cisco.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Cc: Anima WG Subject: Re: [Anima] Multicast in the ACP? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 14:45:44 -0000 --=-=-= Content-Type: text/plain Michael Behringer (mbehring) wrote: >> Right, so we would have to specify a "replicast", where the sender >> copies the message to each ACP tunnel. That seems like a lot of >> overhead. > Not sure I'm with you. A tunnel is presented like an interface. Whether > you send the packet out a normal interface or a tunnel is the same? Can > you expand? ... As I understand it, (and I haven't read a document that specifies this: it was just hallway conversation, but maybe your latest round has something), the tunnel is an IPv6-over-IPsec-over-link-layer. I can even imagine, in order to get the traffic up to where it needs to be, that we might even consider running the ESP(-and-IKE)-over-UDP on a port!=500. (ESP-o-UDP is usually used for IPv4 NAT traversal...) As such, this traffic might never get seen (on purpose) by any of the ASICs that know how to do efficiently do multicast... -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVTkFgYCLcPvd0N1lAQJLjgf9Gi5NrrrcuOe5KDyEA9AbGsAX2r70jWgN x/t0qXw9McT4A9boIqoC8rglbes+fzrFXnbMBpk8a/JKVKyLqHeqFT07cyfUQyyo cKURBYhUk4gQDAN3TS4Rg4gi3SZuaqWvRAPtPv8New+UXQ2yUJpCOWa7k44t2a0A OMvjh2kR2szmLp6DTNUC2AyezPfsn9ccYddLeT9vRaHMxUZTlUIlJGmwNG8L9iRg J99jvGeyFFFD0eDOhmQ+wo6CYivgXyCqTxr/JYJX7rNDtegqZxdbQiUjn1vY3tj6 lxAS57OVJjQlghd3QUs46lLCjpOrCEoFJVwCk0MQ+1qo31eNMyX5Ag== =R2A+ -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Apr 23 09:29:00 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA751A872E for ; Thu, 23 Apr 2015 09:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mYGXqZ2Tk58 for ; Thu, 23 Apr 2015 09:28:56 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE8B31A1BF5 for ; Thu, 23 Apr 2015 09:28:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6891; q=dns/txt; s=iport; t=1429806518; x=1431016118; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=X16hXhsIcQ/1pPgh2oEkpIr2roMoHe3BB2Fwzpd4FxY=; b=AZODDzn9cXQJwxX5ALKALEkgzucDKSHjyhFSGkE+6pDfs2tGKw4a33nI t0RgsZaOsce3J8aUpDMzmaodnU6H9XB2V0PKlhgRnOQ83TrG1URKd4Moy O/stIqaSgQpQT5UdFmS6B3bdsDiihY/mAsBhMo/oHiA6/ErP+feRsllKW s=; X-IronPort-AV: E=Sophos;i="5.11,632,1422921600"; d="scan'208";a="143946461" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-4.cisco.com with ESMTP; 23 Apr 2015 16:28:38 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t3NGSbov023238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Apr 2015 16:28:38 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t3NGSbD0009908; Thu, 23 Apr 2015 09:28:37 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t3NGSbuu009907; Thu, 23 Apr 2015 09:28:37 -0700 Date: Thu, 23 Apr 2015 09:28:37 -0700 From: Toerless Eckert To: "Michael Behringer (mbehring)" Message-ID: <20150423162837.GA4069@cisco.com> References: <20150422083359.25790.38929.idtracker@ietfa.amsl.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F5FE4E@xmb-rcd-x14.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22F5FE4E@xmb-rcd-x14.cisco.com> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Anima WG Subject: Re: [Anima] FW: New Version Notification for draft-behringer-anima-autonomic-addressing-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 16:28:58 -0000 Thanks Michael When planning for OSS AN implementation (SNBI), we see that we would like to have multiple addresses per AN-node: AN nodes should hae an aggregateable address range: - Agents in the AN-node could then have their own address and the basic forwarding element functions of AN (AN-FE) do not have to bother sharing the address. - Implementations become a lot easier. Especially commercial implementations where additional agents or the like running in some VM would already today usually have different addresses than eg: the routers loopback address. - When attaching AN to a NOC-LAN it would be great if the AN router could hand out addresses to the NOC machines automatically. These addresses toos hould be from the domains address range. That way we would have a very simple option for our security model. So here is what i would propose: Type = 0: stays unchanged: Used for AN routers that can't do better Type = 1/2: New semantic: Device-ID: 24-bit-OUI 8-bit-registrar-id 16-bit-device-id 16-bit-logical-node-address Explanation: 16-bit-device ID as in the current draft, each enrolled AN device gets a different number. That device then has the last 16 bits to assign to internal functions. 16-bit-logical-node-address 0 must be used for the AN-FE function. Instead of 48 bits for registrar ID this leaves us with just 32 bits: 24-bit-OUI + 8-bit registrar-ID. Keeping the OUI in the format allows for different vendors to figure out separately how to let users assign the registrar-ID when they have multiple. Each AN node has now 2 /112 bit address prefixes. Type 1 is for all "internal" functions. Internal means that those functions share the domain certificate of the AN-device (eg: agents). Type 2 is external equipment in the NOC to which the AN device handed out an address from its /112 block. These devices will use their own domain certificate. There are still a bunch of important insecure protocols required in network OAM. TFTP for example (yes i know there is a security option coming now... its just an example). AN devices can decide whether they want to permit such insecure protocols for example only if the device has a type 2 AN address because that indicates that an AN device did hand out out that Type 2 address. And one can even derive the Type 1 address of that AN device from the Type 2 address and layer more security inside AN on this. So in the end a lot more flexible use of those glorious 128 bits of addressing, albeit at the expense of likely having to manually assign an 8-bit registrar-ID to every registrar manually. And this is just a suggestion - food for thought. Any improvements welcome. cheers Toerless In commercial products this would make implementation even more This would be likely even more worthwhile in commercial devices. Agent would be running in some VM/container context and the actual AN-router would certainly have more challenges handing out the same IPv6 address it uses internally as loopback for all its services (routing, ssh, SNMP,...). Sounds also security wise as good separation. Thirdly, imagine out the same IPv6 address that it uses as a key security Imagine a commercial If we want to modularily split up autonomic forwarding (FE) from autonomic agents, this can be done a lot easier when the agent can have their own address. That allows to model them as one or multiple IPv6 hosts beind a virtual internal network link connected to the AN-FE. it would help the AN goals a lot if individual AN nodes could get On Wed, Apr 22, 2015 at 04:46:23PM +0000, Michael Behringer (mbehring) wrote: > ANIMA, > > Looking at the reference model, addressing is an important part. I've been hesitating on how to put materials into the reference model that may still evolve in a different direction, and I think items such as addressing where we essentially need to settle on a common model may be better discussed outside the reference model for now. > > So, in the end I pushed the text as a separate draft for now, with the expectation that an addressing concept will merge into the reference model later on. But it will likely evolve from the below. > > So please read the below couple of pages in this light. It is documenting what Cisco's autonomic implementation is doing right now. There are many ways to do this, so I would encourage people with other ideas to also publish them (or at least send the proposed text to the list) so that we can have a fruitful discussion. > > Michael > > PS: I published this doc yesterday, but forgot to add the "anima" in the title, so this one is just a re-post with the correct title. > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: 22 April 2015 10:34 > > To: Michael Behringer (mbehring); Michael Behringer (mbehring) > > Subject: New Version Notification for draft-behringer-anima-autonomic- > > addressing-00.txt > > > > > > A new version of I-D, draft-behringer-anima-autonomic-addressing-00.txt > > has been successfully submitted by Michael H. Behringer and posted to the > > IETF repository. > > > > Name: draft-behringer-anima-autonomic-addressing > > Revision: 00 > > Title: An Autonomic IPv6 Addressing Scheme > > Document date: 2015-04-22 > > Group: Individual Submission > > Pages: 5 > > URL: http://www.ietf.org/internet-drafts/draft-behringer-anima- > > autonomic-addressing-00.txt > > Status: https://datatracker.ietf.org/doc/draft-behringer-anima- > > autonomic-addressing/ > > Htmlized: http://tools.ietf.org/html/draft-behringer-anima-autonomic- > > addressing-00 > > > > > > Abstract: > > This document describes a generic IPv6 addressing scheme which is > > suitable for autonomic nodes, where node addressing must not depend > > on a centrally managed scheme. It assumes a unique domain name and > > device name, and automatically derives a unique IPv6 address from > > those. The scheme allows for a flat address hierarchy as well as > > optionally, when required, the definition of zones which are > > aggregatable. This document is for discussion right now; the final > > addressing scheme should probably move into > > [I-D.behringer-anima-reference-model]. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Thu Apr 23 09:45:32 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DFA61AC44B for ; Thu, 23 Apr 2015 09:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4VFPI2nlgVY for ; Thu, 23 Apr 2015 09:45:23 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FDE31AC3CD for ; Thu, 23 Apr 2015 09:45:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=601; q=dns/txt; s=iport; t=1429807522; x=1431017122; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=aTAwLL/Vy0TYUxuqadFO8Llq1m7Pev15rBWREpfrnMM=; b=jmFzt/TUlKo0U8S6Q5fKmDCCFsSjLHHmKMNii49A0dLje5Wfl03Jn0s4 VWxNArHdlNYTGBRNUN6v7OqJ2lEifU9D22qXErc9ARTceip5s09Q6y4qh dQves1s2YHE5djK18zwKS4v/9CSqoornSehdvQdzDt5dIc7M342Gn3OxY Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BUBABxIDlV/4QNJK1bgwyBM8U5ZgmHVQKBNjgUAQEBAQEBAYEKhCIBBDpRASoUQiYBBBuII6gppD0BAQEBBgEBAQEBHZAKg0+BFgWRSqAAI4N0gjOBAAEBAQ X-IronPort-AV: E=Sophos;i="5.11,632,1422921600"; d="scan'208";a="143944251" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-5.cisco.com with ESMTP; 23 Apr 2015 16:45:21 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t3NGjLuc007194 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 23 Apr 2015 16:45:21 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.216]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Thu, 23 Apr 2015 11:45:21 -0500 From: "Michael Behringer (mbehring)" To: Anima WG Thread-Topic: Addressing: Do we need link addressing? Thread-Index: AdB9rwu1/EpJW7+cS0uz4MXtLBy7DQ== Date: Thu, 23 Apr 2015 16:45:21 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22F62DBD@xmb-rcd-x14.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.133] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Anima] Addressing: Do we need link addressing? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 16:45:24 -0000 ANIMA WG,=20 I'd like to raise a question to the list for discussion: Do we need to crea= te autonomic link addressing?=20 Here is my view: We need to distinguish about addressing done in the Autono= mic Networking Infrastructure, and addressing configured and managed by an = operator. For the Autonomic Networking Infrastructure, which serves autonom= ic service agents, I do not think we need routable addresses on links, and = suggest to use only link-local addressing. So the only addressing we should= make routable are loopback addresses on devices.=20 Thoughts? Michael =20 From nobody Thu Apr 23 10:03:45 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E78991ACD98 for ; Thu, 23 Apr 2015 10:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0dR_XKieADH for ; Thu, 23 Apr 2015 10:03:38 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBE7F1AC437 for ; Thu, 23 Apr 2015 10:03:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1418; q=dns/txt; s=iport; t=1429808604; x=1431018204; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=NPnTmTQSoR3vX7cNpiNVGhzuVDGthk6v0Hp72bZan4Q=; b=Au0pR4i0xIpQSxUbo0e+PJnhNV3DhCLS/XOw4p+1v6Hlm9WQuPdOe04p 8Cukyk3EAJ5midbruUN1hDajO+RHQlzxosO6ThXiQPND9aiT34EGEgbuy lqDSSpADk+g8PSTTu/X8dW/jSXVxjMcPwi07mzomQkiZigdDu6X3Aktqh s=; X-IronPort-AV: E=Sophos;i="5.11,632,1422921600"; d="scan'208";a="143951210" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-2.cisco.com with ESMTP; 23 Apr 2015 17:03:23 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t3NH3ME3015532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Apr 2015 17:03:23 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t3NH3Moc012285; Thu, 23 Apr 2015 10:03:22 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t3NH3Ltp012283; Thu, 23 Apr 2015 10:03:21 -0700 Date: Thu, 23 Apr 2015 10:03:21 -0700 From: Toerless Eckert To: Michael Richardson Message-ID: <20150423170321.GA11499@cisco.com> References: <5536EE40.30705@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F5FE63@xmb-rcd-x14.cisco.com> <5537FFEF.9020308@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F626F8@xmb-rcd-x14.cisco.com> <16186.1429800321@sandelman.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16186.1429800321@sandelman.ca> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Anima WG , "Michael Behringer \(mbehring\)" Subject: Re: [Anima] Multicast in the ACP? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 17:03:44 -0000 Michael: Whatever we do for message distribution should work for whatever secure hop-by-hop connectivity we use. IPsec has benefits of HW-acceleration support in routers. dTLS has benefits of ease of implemention at process level. On Thu, Apr 23, 2015 at 10:45:21AM -0400, Michael Richardson wrote: > > Michael Behringer (mbehring) wrote: > >> Right, so we would have to specify a "replicast", where the sender > >> copies the message to each ACP tunnel. That seems like a lot of > >> overhead. > > > Not sure I'm with you. A tunnel is presented like an interface. Whether > > you send the packet out a normal interface or a tunnel is the same? Can > > you expand? ... > > As I understand it, (and I haven't read a document that specifies this: it > was just hallway conversation, but maybe your latest round has something), > the tunnel is an IPv6-over-IPsec-over-link-layer. > > I can even imagine, in order to get the traffic up to where it needs to be, > that we might even consider running the ESP(-and-IKE)-over-UDP on a port!=500. > (ESP-o-UDP is usually used for IPv4 NAT traversal...) > > As such, this traffic might never get seen (on purpose) by any of the ASICs > that know how to do efficiently do multicast... > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- From nobody Thu Apr 23 10:16:27 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8971ACDC2 for ; Thu, 23 Apr 2015 10:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgIn8gQIJCAG for ; Thu, 23 Apr 2015 10:16:21 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B63531ACDB4 for ; Thu, 23 Apr 2015 10:16:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1658; q=dns/txt; s=iport; t=1429809367; x=1431018967; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=nJZLXxO0utQ021sVh51Up+3OuaJZo36b83DHKb4qk3w=; b=UUzQAInELy4tgqAlKrCHMT+btQFyuT1Sitef5CaFoHRTnNfIOrqPPPpi gaw6McRfITIPjh4z1qGETBHPAYDqDMdwqPUwW5tJGTaN8VEQWQGXPb8du l41dJLKhf0XvD2RqeeEwH4C9jNHvBMwWaFy3MOLjeSjGzuskMhDV2Z+rd I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ASBQAXKDlV/5ldJa1bgwxSXMd0CoYEAoE2TAEBAQEBAYELhCEBAQQBAQE3NAsQCxgJJQ8FEzYTiCsNzF8BAQEBAQEBAQEBAQEBAQEBAQEBAQETBIs3hDlLB4MXgRYFi1SQKgGBIpBbg04jYIFYgVweMYJEAQEB X-IronPort-AV: E=Sophos;i="5.11,632,1422921600"; d="scan'208";a="414605699" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 23 Apr 2015 17:16:06 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t3NHG5kt031786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Apr 2015 17:16:06 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t3NHG5XA013116; Thu, 23 Apr 2015 10:16:05 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t3NHG46C013115; Thu, 23 Apr 2015 10:16:04 -0700 Date: Thu, 23 Apr 2015 10:16:04 -0700 From: Toerless Eckert To: Brian E Carpenter Message-ID: <20150423171604.GB11499@cisco.com> References: <5536EE40.30705@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5536EE40.30705@gmail.com> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Anima WG Subject: Re: [Anima] GDNP: flooding discovery or announcement (was: Multicast in the ACP?) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 17:16:26 -0000 As contributor: Brian: I think there is a more fundamental decision for GDNP, and we discussed this a bit during our discussions last IETF: I understand there are two basic approaches to distributed discovery (meaning: no central component): a) The service-client sends out a request which gets flooded and the server replies. b) The server sends out an announcements which gets flooded and the service client remembers it and uses when needed. Your approach is a). mDNS flooding is a bit of a hybrid between a) and b). The opaque LSA mechanisms popping up in IGPs these days are b). I am worried about scaling of a) when there are a lot of clients. I would guess in AN we have few services and many clients - most services, every AN device is a client of. Does that not mean we should have flooding of announcements instead of flooding of queries ? Of course, the mechanism could have both... Cheers Toerless On Wed, Apr 22, 2015 at 12:41:36PM +1200, Brian E Carpenter wrote: > This is a question to the authors of draft-behringer-anima-autonomic-control-plane. > > The discovery component of GDNP includes link-local multicast > messages. As far as we know, there is no way to secure these > messages, but by definition they are only intended for > autonomic nodes, which should all be part of the ACP. > > So, is there any way to support secure link-local multicast > within the ACP? > > Brian > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- Toerless Eckert, eckert@cisco.com From nobody Thu Apr 23 10:40:02 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D471B310A for ; Thu, 23 Apr 2015 10:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0QCFHlamuDt for ; Thu, 23 Apr 2015 10:39:58 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EDC31B30F9 for ; Thu, 23 Apr 2015 10:39:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1034; q=dns/txt; s=iport; t=1429810772; x=1431020372; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=AkjITHuzYIQkzbqb0Opkja+Y1ey55saOzgAKZcJrBis=; b=kJbdr/1BlGlshbltczqnXfN2+TAIrdUOBPpnwgf9ZAeF1RK71pIr5vrC b76KXtat25U9TaOO2VeWdN52ZZrDaMQlJGF01YpRGzVynC2ABH2l5cQS+ itCHNpEc1zcSH7E7JEpEZzFfM+S7idaXo9HZC7dsO66HmvvTnPupmvb8/ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BtBAD/LTlV/40NJK1bgwxSXcYjCYFRhgQCgTY4FAEBAQEBAQGBCoQhAQEEOj8QCxgJJQ8FSYg+DcxnAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4s3hQQHgxeBFgWLVIl3hjMBgV6TbSNggzQegnUBAQE X-IronPort-AV: E=Sophos;i="5.11,632,1422921600"; d="scan'208";a="143964313" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-6.cisco.com with ESMTP; 23 Apr 2015 17:39:22 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t3NHdL0d017122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Apr 2015 17:39:21 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t3NHdKKq014635; Thu, 23 Apr 2015 10:39:20 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t3NHdKCn014634; Thu, 23 Apr 2015 10:39:20 -0700 Date: Thu, 23 Apr 2015 10:39:20 -0700 From: Toerless Eckert To: Michael Richardson Message-ID: <20150423173920.GC11499@cisco.com> References: <5536EE40.30705@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F5FE63@xmb-rcd-x14.cisco.com> <5537FFEF.9020308@gmail.com> <10795.1429737994@sandelman.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10795.1429737994@sandelman.ca> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Anima WG Subject: Re: [Anima] Multicast in the ACP? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 17:40:00 -0000 [individual] On Wed, Apr 22, 2015 at 05:26:34PM -0400, Michael Richardson wrote: > http://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/ > describes a way to do multicast across that collection of links... that is if > we can ever get it through the IESG. MPL is flooding with sequence numbers for loop/duplicate avoidance. It then uses Trickle for link transmission which also doing link-level duplicate avoidance by sequence number (observing what others have sent, do not send yourself again). Kinda like CSMA/SA (Send Avoidance ;-) If we have p2p secure associations between neighbors, there will likely not be a lot of benefit for the Trickle part though, so might end up having some amount of overdesign for what we need. I also would prefer the idea of hop-by-hop reliable forwarding. All this datagram multicasting across slow/unreliable networks is IMHO a mistake. MPL could introduce that hop-by-hop reliability i think it doesn't do it so far, and its reinventing reliability. Toerless From nobody Thu Apr 23 11:10:48 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB44E1B312C for ; Thu, 23 Apr 2015 11:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZg_mTK8w8hG for ; Thu, 23 Apr 2015 11:10:46 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52E231AD352 for ; Thu, 23 Apr 2015 11:10:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1214; q=dns/txt; s=iport; t=1429812638; x=1431022238; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=41v/IpK9UDM01bPEXP8KLcg5T3Q3eBDVJcBgZAbF8po=; b=aQl8qbsk+9qVyXyhKyltmENlUAfCnnFvycGvWybPUk5HEsOnJkK28w/O zxhOkrbnX3hXv4YqBk8ASqy1q6jheCKvasdIGFcskRPLR/t79R4227Ojo JKU1Jr1CaNmN3HhiI5svAz/jHwolNk5sJSSkRXhVG6qZxy5jTHoraUHln Q=; X-IronPort-AV: E=Sophos;i="5.11,633,1422921600"; d="scan'208";a="414268856" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 23 Apr 2015 18:10:37 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t3NIAblZ003751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Apr 2015 18:10:37 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t3NIAaMg016774; Thu, 23 Apr 2015 11:10:36 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t3NIAao5016773; Thu, 23 Apr 2015 11:10:36 -0700 Date: Thu, 23 Apr 2015 11:10:36 -0700 From: Toerless Eckert To: "Michael Behringer (mbehring)" Message-ID: <20150423181036.GD11499@cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22F62DBD@xmb-rcd-x14.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22F62DBD@xmb-rcd-x14.cisco.com> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Anima WG Subject: Re: [Anima] Addressing: Do we need link addressing? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 18:10:47 -0000 [individual] +1 Would recommend folks to to read up on RFC7404 to understand the pro/cons for the general case. IMHO none of the mentioned caveats applies to ANI, so it is the ideal case to leverage 7404. Wrt to 7404 text: I don't think using loopback from NMS operations is a caveat, IMHO its a benefit, especially when you have as in ANI a zero-touch routing protocol announcing it. On Thu, Apr 23, 2015 at 04:45:21PM +0000, Michael Behringer (mbehring) wrote: > ANIMA WG, > > I'd like to raise a question to the list for discussion: Do we need to create autonomic link addressing? > > Here is my view: We need to distinguish about addressing done in the Autonomic Networking Infrastructure, and addressing configured and managed by an operator. For the Autonomic Networking Infrastructure, which serves autonomic service agents, I do not think we need routable addresses on links, and suggest to use only link-local addressing. So the only addressing we should make routable are loopback addresses on devices. > > Thoughts? > Michael > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Thu Apr 23 13:19:49 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3FA1B32E0 for ; Thu, 23 Apr 2015 13:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amQiZmxi8YIP for ; Thu, 23 Apr 2015 13:19:47 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74E971B32EC for ; Thu, 23 Apr 2015 13:19:37 -0700 (PDT) Received: by pabtp1 with SMTP id tp1so27325244pab.2 for ; Thu, 23 Apr 2015 13:19:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Dg52Md1nYIXY1HT+DkAtmuL+Mw7YmseujEP1VDHBVZI=; b=HnyinV+r4m5O2cPoDOc9TkEvUsIFQMwopY0Kg168vW7KsNDSLBFsOAYu+tW1FHbAVG YgsiBtxg7Y89ArcnPYbkJPPGFCEAbi8vAafzPGTav2rB5RKzV0HXvnPFiTKXVAAO+PoZ T2SNb0Yfof5eXolNKpOFw7U+SRyqh5bpMM8w2DLqCiN+84OWs8jVZUrY/bsj576dRjnb tWa6e7LuyhUqz3CXlfIXMbpKhQn2pSW0H1K9fOiDjJ1MovaNHFHrZF9SGinI0t9QGHp3 ND7GCQ/iAaHDRoqk5dDd6Ij4U0JrKWALjZ8OT41m0QwcYF+OJVkKJQYWZQbqji/F+mkS a7QQ== X-Received: by 10.70.129.202 with SMTP id ny10mr8447850pdb.107.1429820377072; Thu, 23 Apr 2015 13:19:37 -0700 (PDT) Received: from ?IPv6:2406:e007:6a88:1:28cc:dc4c:9703:6781? ([2406:e007:6a88:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id os7sm8939047pdb.51.2015.04.23.13.19.34 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Apr 2015 13:19:35 -0700 (PDT) Message-ID: <553953E0.8090308@gmail.com> Date: Fri, 24 Apr 2015 08:19:44 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Michael Behringer (mbehring)" , Anima WG References: <5536EE40.30705@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F5FE63@xmb-rcd-x14.cisco.com> <5537FFEF.9020308@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F626F8@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22F626F8@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Multicast in the ACP? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 20:19:48 -0000 On 23/04/2015 21:21, Michael Behringer (mbehring) wrote: >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: 22 April 2015 22:09 >> To: Michael Behringer (mbehring); Anima WG >> Subject: Re: [Anima] Multicast in the ACP? >> >> On 23/04/2015 04:46, Michael Behringer (mbehring) wrote: >>> Brian, >>> >>>> The discovery component of GDNP includes link-local multicast >> messages. >>>> As far as we know, there is no way to secure these messages, but by >>>> definition they are only intended for autonomic nodes, which should >>>> all be part of the ACP. >>>> >>>> So, is there any way to support secure link-local multicast within the >> ACP? >>> >>> The ACP as described in draft-behringer-anima-autonomic-control-plane >> is based on a hop by hop tunnel infrastructure. So far those tunnels are all >> point to point. I guess you can send a link-local multicast packet through >> such a tunnel, and it would automatically benefit from the security of that >> tunnel. But of course there is only one other node on that "link". >> >> Right, so we would have to specify a "replicast", where the sender copies >> the message to each ACP tunnel. That seems like a lot of overhead. > > Not sure I'm with you. A tunnel is presented like an interface. Whether you send the packet out a normal interface or a tunnel is the same? Can you expand? ... If I want to send a discovery message to all autonomic nodes on the same physical link as me, as far as I can see I have two choices: 1. Send one insecure link-local multicast packet. 2. Send a copy of the message to each ACP tunnel interface (because I have a link-local tunnel to each other autonomic node on the same link). So if I have 10 peers in the ACP on the same link, I either send one insecure multicast packet or 10 secure copies of the same packet. (This doesn't need a multicast protocol, just a "send a copy to everybody" API.) Brian From nobody Thu Apr 23 13:27:30 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B59A1B3321 for ; Thu, 23 Apr 2015 13:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gg7GNXQSa_TY for ; Thu, 23 Apr 2015 13:27:27 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F3D41B3318 for ; Thu, 23 Apr 2015 13:27:04 -0700 (PDT) Received: by pabsx10 with SMTP id sx10so27493674pab.3 for ; Thu, 23 Apr 2015 13:27:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=PAmDS4qYU3GDq5DfScjJspRx24S+8m9VUfjmji6AN2A=; b=kEYbB8C3uzEmeR9tOqxZbeSQ8vK7mgEjVU32EVaorqdb4mHFSqyGFUv85+gX97YOTu gu1WaCJv0iIWSRjQPwOHOqznOSncAWigpOzlB5h/IL3UPmxHH1o6m1HOGlZuh2nsKbUh HpvOCAlqdA6JVz9oW1hXD1P4SZoaCHSXuGi92A6hc7GudFw4QlRi4h6Qo5UpOWo4yoG2 RoKmKnh4b6MAMiEE+dk3ojWDH2xga+BzmfwVyINp2CUHLI4ZPAJQg/X46TFxhmLg1sA3 qZCemVkw+KFuxKA2VU4y3mYd/N41g9trS9zHh3p6H1BnsLs7DrqdkTS4JCCqU7HV+tAy piCA== X-Received: by 10.70.127.138 with SMTP id ng10mr8527056pdb.111.1429820824179; Thu, 23 Apr 2015 13:27:04 -0700 (PDT) Received: from ?IPv6:2406:e007:6a88:1:28cc:dc4c:9703:6781? ([2406:e007:6a88:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id l5sm8883018pbq.15.2015.04.23.13.27.00 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Apr 2015 13:27:03 -0700 (PDT) Message-ID: <5539559F.2020406@gmail.com> Date: Fri, 24 Apr 2015 08:27:11 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Toerless Eckert , "Michael Behringer (mbehring)" References: <20150422083359.25790.38929.idtracker@ietfa.amsl.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F5FE4E@xmb-rcd-x14.cisco.com> <20150423162837.GA4069@cisco.com> In-Reply-To: <20150423162837.GA4069@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Anima WG Subject: Re: [Anima] FW: New Version Notification for draft-behringer-anima-autonomic-addressing-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 20:27:29 -0000 Hi Toerless, Excuse front posting, but this is a general comment since I think the specifics depend on other discussions first. You use the word "manually". I think that needs to be forbidden from our vocabulary. Regards Brian On 24/04/2015 04:28, Toerless Eckert wrote: > Thanks Michael > > When planning for OSS AN implementation (SNBI), we see that we > would like to have multiple addresses per AN-node: > > AN nodes should hae an aggregateable address range: > - Agents in the AN-node could then have their own address and the > basic forwarding element functions of AN (AN-FE) do not have to > bother sharing the address. > - Implementations become a lot easier. Especially commercial > implementations where additional agents or the like running > in some VM would already today usually have different addresses > than eg: the routers loopback address. > - When attaching AN to a NOC-LAN it would be great if the AN > router could hand out addresses to the NOC machines automatically. > These addresses toos hould be from the domains address range. > That way we would have a very simple option for our security model. > > So here is what i would propose: > > Type = 0: stays unchanged: Used for AN routers that can't do better > > Type = 1/2: New semantic: > > Device-ID: > 24-bit-OUI 8-bit-registrar-id 16-bit-device-id 16-bit-logical-node-address > > Explanation: > 16-bit-device ID as in the current draft, each enrolled AN device > gets a different number. That device then has the last 16 > bits to assign to internal functions. 16-bit-logical-node-address 0 > must be used for the AN-FE function. > > Instead of 48 bits for registrar ID this leaves us with just 32 bits: > 24-bit-OUI + 8-bit registrar-ID. Keeping the OUI in the format allows > for different vendors to figure out separately how to let users > assign the registrar-ID when they have multiple. > > Each AN node has now 2 /112 bit address prefixes. Type 1 is for > all "internal" functions. Internal means that those functions share > the domain certificate of the AN-device (eg: agents). > > Type 2 is external equipment in the NOC to which the AN device > handed out an address from its /112 block. These devices will > use their own domain certificate. > > There are still a bunch of important insecure protocols required in > network OAM. TFTP for example (yes i know there is a security option > coming now... its just an example). AN devices can decide whether > they want to permit such insecure protocols for example only if > the device has a type 2 AN address because that indicates that > an AN device did hand out out that Type 2 address. And one can > even derive the Type 1 address of that AN device from the Type 2 > address and layer more security inside AN on this. > > So in the end a lot more flexible use of those glorious 128 bits of > addressing, albeit at the expense of likely having to manually > assign an 8-bit registrar-ID to every registrar manually. > > And this is just a suggestion - food for thought. Any improvements > welcome. > > cheers > Toerless > > > > > In commercial products this would make implementation even more > This would be likely even more worthwhile in commercial devices. > Agent would be running in some VM/container context and the > actual AN-router would certainly have more challenges handing > out the same IPv6 address it uses internally as loopback for > all its services (routing, ssh, SNMP,...). Sounds also security > wise as good separation. > > Thirdly, imagine > out the same IPv6 address that it uses as a key security > > Imagine a commercial > If we want to modularily split up autonomic forwarding (FE) from > autonomic agents, this can be done a lot easier when the agent > can have their own address. That allows to model them as one > or multiple IPv6 hosts beind a virtual internal network link > connected to the AN-FE. > > it would help the AN goals a lot if individual AN nodes could get > > > On Wed, Apr 22, 2015 at 04:46:23PM +0000, Michael Behringer (mbehring) wrote: >> ANIMA, >> >> Looking at the reference model, addressing is an important part. I've been hesitating on how to put materials into the reference model that may still evolve in a different direction, and I think items such as addressing where we essentially need to settle on a common model may be better discussed outside the reference model for now. >> >> So, in the end I pushed the text as a separate draft for now, with the expectation that an addressing concept will merge into the reference model later on. But it will likely evolve from the below. >> >> So please read the below couple of pages in this light. It is documenting what Cisco's autonomic implementation is doing right now. There are many ways to do this, so I would encourage people with other ideas to also publish them (or at least send the proposed text to the list) so that we can have a fruitful discussion. >> >> Michael >> >> PS: I published this doc yesterday, but forgot to add the "anima" in the title, so this one is just a re-post with the correct title. >> >> >>> -----Original Message----- >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> Sent: 22 April 2015 10:34 >>> To: Michael Behringer (mbehring); Michael Behringer (mbehring) >>> Subject: New Version Notification for draft-behringer-anima-autonomic- >>> addressing-00.txt >>> >>> >>> A new version of I-D, draft-behringer-anima-autonomic-addressing-00.txt >>> has been successfully submitted by Michael H. Behringer and posted to the >>> IETF repository. >>> >>> Name: draft-behringer-anima-autonomic-addressing >>> Revision: 00 >>> Title: An Autonomic IPv6 Addressing Scheme >>> Document date: 2015-04-22 >>> Group: Individual Submission >>> Pages: 5 >>> URL: http://www.ietf.org/internet-drafts/draft-behringer-anima- >>> autonomic-addressing-00.txt >>> Status: https://datatracker.ietf.org/doc/draft-behringer-anima- >>> autonomic-addressing/ >>> Htmlized: http://tools.ietf.org/html/draft-behringer-anima-autonomic- >>> addressing-00 >>> >>> >>> Abstract: >>> This document describes a generic IPv6 addressing scheme which is >>> suitable for autonomic nodes, where node addressing must not depend >>> on a centrally managed scheme. It assumes a unique domain name and >>> device name, and automatically derives a unique IPv6 address from >>> those. The scheme allows for a flat address hierarchy as well as >>> optionally, when required, the definition of zones which are >>> aggregatable. This document is for discussion right now; the final >>> addressing scheme should probably move into >>> [I-D.behringer-anima-reference-model]. >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Thu Apr 23 13:47:35 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 503BE1B33CB for ; Thu, 23 Apr 2015 13:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvKxJ8NwCQGI for ; Thu, 23 Apr 2015 13:47:32 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B729D1B339D for ; Thu, 23 Apr 2015 13:47:21 -0700 (PDT) Received: by pacwv17 with SMTP id wv17so5914715pac.0 for ; Thu, 23 Apr 2015 13:47:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=AaCc8VTLC/oJ/qtDm3HWQ9X6gEQUKDDlV6gNqOG9+6Y=; b=fFIkDUwpPmiQzFDmtZuU7OL9KcayL0zKpGCICWSJSTC/rNJ5jHOHgp40WiZor8CAXV fWdLhTikhj9lC/uU9QewlEM6Rb42tCUgQhkuio+sWvyUorov7PhUtcNyntnI8SUo/htX kaJDErQQ3k5ppjc5iVQWBsreFAritJiqHPscx2Lau/Pmtp9HLg6VDBRr802eYSBBIaCR CYywmfRpf6LG7E4k4HGSfPxNTL5AAgHQd3S0Ht28137cBGqcLgeFh+FDmipKRWDeS/Tb d8L6z/XsRXpFJB9E3u18IlZfWPWHL41w9IMnt7KzvW6QJWiyVdVA3WywMOjd6A0SXxI0 OIUA== X-Received: by 10.70.118.101 with SMTP id kl5mr8572549pdb.129.1429822041482; Thu, 23 Apr 2015 13:47:21 -0700 (PDT) Received: from ?IPv6:2406:e007:6a88:1:28cc:dc4c:9703:6781? ([2406:e007:6a88:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id xo3sm6956440pbb.74.2015.04.23.13.47.18 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Apr 2015 13:47:20 -0700 (PDT) Message-ID: <55395A60.1000401@gmail.com> Date: Fri, 24 Apr 2015 08:47:28 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Toerless Eckert References: <5536EE40.30705@gmail.com> <20150423171604.GB11499@cisco.com> In-Reply-To: <20150423171604.GB11499@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Anima WG Subject: Re: [Anima] GDNP: flooding discovery or announcement X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 20:47:34 -0000 Hi Toerless, On 24/04/2015 05:16, Toerless Eckert wrote: > As contributor: > > Brian: > > I think there is a more fundamental decision for GDNP, and > we discussed this a bit during our discussions last IETF: > > I understand there are two basic approaches to distributed discovery (meaning: > no central component): > > a) The service-client sends out a request which gets flooded > and the server replies. > b) The server sends out an announcements which gets flooded and > the service client remembers it and uses when needed. > > Your approach is a). Yes, but it's a conservative version of a) with explicit caching by the relays and with an explicit throttle on the relayed messages. As a victim of ARP broadcast storms in my youth, I am very much aware of the risks. > mDNS flooding is a bit of a hybrid between > a) and b). The opaque LSA mechanisms popping up in IGPs these > days are b). > > I am worried about scaling of a) when there are a lot of clients. Well, we're talking about ASAs discovering each other. I see that as a peer relationship, not a server-client relationship, so I'm not sure the scaling problem is quite that bad. Perhaps we need to invent some scenarios to get a feeling for the numbers. > I would guess in AN we have few services and many clients - most > services, every AN device is a client of. > > Does that not mean we should have flooding of announcements > instead of flooding of queries ? > > Of course, the mechanism could have both... Yes. In fact we had a half-baked "unsolicited response" in version -02 to do exactly that - effectively preload the discovery caches. That would largely avoid the relaying of queries off-link. We took it out of version -03 because it was half-baked, but if the WG wants, of course we can reinstate it. I'm pretty sure we will always need the query flooding, to support nodes that spend a lot of time asleep; see the reasons why IPv6 needs "resilient RS". Regards Brian > > Cheers > Toerless > > On Wed, Apr 22, 2015 at 12:41:36PM +1200, Brian E Carpenter wrote: >> This is a question to the authors of draft-behringer-anima-autonomic-control-plane. >> >> The discovery component of GDNP includes link-local multicast >> messages. As far as we know, there is no way to secure these >> messages, but by definition they are only intended for >> autonomic nodes, which should all be part of the ACP. >> >> So, is there any way to support secure link-local multicast >> within the ACP? >> >> Brian >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > From nobody Thu Apr 23 14:02:54 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E46921B3424 for ; Thu, 23 Apr 2015 14:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SssUWy1rJD6 for ; Thu, 23 Apr 2015 14:02:51 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F6B71B3418 for ; Thu, 23 Apr 2015 14:02:36 -0700 (PDT) Received: by pdbnk13 with SMTP id nk13so28621804pdb.0 for ; Thu, 23 Apr 2015 14:02:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=z9PzLvmjBwVCgvXyECXbadc1Hlakk7QUTtYuzfH5t7Q=; b=bzpVU3/y+KuuZrWd5kWaJbx6pBacMBUUinGeOrxOlgCHJGVyZ9b6fIld+Y6ShtcmfM XBuSBZCFmc7qeY3FiUunyYbr8JGq6T/2mqNjIuCQ6/kEm5rJGiBehR9otfyHYjAbvzwV ShIeC1JRnPmxk45CJm/CWd8Q6L6goUnNBoiCqglSn53AJ18kuvIp9xjYzBRrulRObzVQ ovs6AfeetWGgPJORknoxxlzD/6VRDoOpudt9ccEfH9TyMsXu+3eD0EXT9xkWQQspKmQ6 RSvP7398hfKNZt2quBFUJ9+e1Ru7k5l4k5UTFwUVmjOfRyLZDpERoMC6AR+Umwxx1iCT JakA== X-Received: by 10.66.124.201 with SMTP id mk9mr8806060pab.132.1429822955753; Thu, 23 Apr 2015 14:02:35 -0700 (PDT) Received: from ?IPv6:2406:e007:6a88:1:28cc:dc4c:9703:6781? ([2406:e007:6a88:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id xz1sm8928007pbb.47.2015.04.23.14.02.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Apr 2015 14:02:34 -0700 (PDT) Message-ID: <55395DF3.3000702@gmail.com> Date: Fri, 24 Apr 2015 09:02:43 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Michael Behringer (mbehring)" , Anima WG References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22F62DBD@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22F62DBD@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Addressing: Do we need link addressing? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 21:02:53 -0000 On 24/04/2015 04:45, Michael Behringer (mbehring) wrote: > ANIMA WG, > > I'd like to raise a question to the list for discussion: Do we need to create autonomic link addressing? > > Here is my view: We need to distinguish about addressing done in the Autonomic Networking Infrastructure, and addressing configured and managed by an operator. For the Autonomic Networking Infrastructure, which serves autonomic service agents, I do not think we need routable addresses on links, and suggest to use only link-local addressing. So the only addressing we should make routable are loopback addresses on devices. Firstly, yes, we should clearly separate the addressing realm used by ASAs to communicate between themselves from the addressing realm(s) used by the user network. (I made that "realm(s)" because in the case of highly virtualized data centres etc., there might be many tenant addressing realms. And of course those addressing realms might well be administered by certain ASAs.) So here, we are talking about the addressing realm used by the ASAs to talk to each other. But now we come to a branching point. Michael wants everybody to have a distinct ACP. I think that's a fine idea but I want to keep the option where there is no ACP, but the ASAs simply communicate using IP among themselves. In that mode there's nothing special about addressing; for example all ASAs could be numbered out of a specific ULA prefix, which would be the AN addressing realm, but they don't need to be routers. So in that mode, no, there is no restriction to link-local addressing. Back to Michael's model. I have a question. If ASA Alpha on a given link wants to communicate with ASA Beta on another link, what addresses are used? Brian > > Thoughts? > Michael > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > . > From nobody Fri Apr 24 01:34:31 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056141B35D9 for ; Fri, 24 Apr 2015 01:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zModucIro7_J for ; Fri, 24 Apr 2015 01:34:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 459CD1B35D3 for ; Fri, 24 Apr 2015 01:34:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRU00428; Fri, 24 Apr 2015 08:34:12 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 24 Apr 2015 09:34:12 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.93]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Fri, 24 Apr 2015 16:34:08 +0800 From: "Liubing (Leo)" To: "anima@ietf.org" Thread-Topic: Addressing-interface addressing Thread-Index: AdB+aWxBd2bophqyRBWx7u68gJs1cw== Date: Fri, 24 Apr 2015 08:34:08 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F457CEEBF5F@nkgeml506-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Anima] Addressing-interface addressing X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 08:34:30 -0000 Hi Dear all, This is another topic regarding to autonomic addressing. For autonomic network infrastructure, is it sufficient to self-assign the d= evices' interfaces link-local addresses? Do we need to assign the interface= s ULA/GUA addresses in some scenarios? I think RFC7404 already has some good discussion, that pinging/traceroute/m= pls/rsvp-te might have some problem if there are only link-local addresses = on the interfaces. Do we need to consider these factors in autonomic networ= king infrastructure? Best regards, Bing From nobody Fri Apr 24 02:23:20 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B981B36A5 for ; Fri, 24 Apr 2015 02:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJsR2zteZBeN for ; Fri, 24 Apr 2015 02:23:18 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB6A41B36A4 for ; Fri, 24 Apr 2015 02:23:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4964; q=dns/txt; s=iport; t=1429867397; x=1431076997; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=H11nnA0w7WRGDfcV5g13X6H6u18giUBau8dCDs/JJKI=; b=OMhXBm1LTyVS7ioE2GSKKvZwHIs9ixgPuU1mD7nUD0wsGLKTsSgonOlU +VTcHZgdwcdrRoLvBa/uoBiHBGCRqgJIkv77aopGmUbyR958HgEnav4Qe lUuUYuTL5qap3t6wvoOx89qLyjtT5HpgtCaztIuTozm2cMwwt5HyX/+MI c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AgBQBXCjpV/4ENJK1bgwyBM4MVwjFmCYdVAhyBHDgUAQEBAQEBAYEKhCABAQEDASMRSgsCAQgaAgYgAgICMBUQAgQBGogbCLZ9lHgBAQEBAQEBAQEBAQEBAQEBAQEagSGKFoRTOIJoL4EWBZFKoAAjgWWCD4IzgQABAQE X-IronPort-AV: E=Sophos;i="5.11,638,1422921600"; d="scan'208";a="144047474" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-8.cisco.com with ESMTP; 24 Apr 2015 09:23:17 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t3O9NH6M019918 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Apr 2015 09:23:17 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.216]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Fri, 24 Apr 2015 04:23:17 -0500 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , Anima WG Thread-Topic: [Anima] Addressing: Do we need link addressing? Thread-Index: AQHQfgjYAXZmx4yzL0mHwaaCBM8J2J1b4TEA Date: Fri, 24 Apr 2015 09:23:16 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22F63344@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22F62DBD@xmb-rcd-x14.cisco.com> <55395DF3.3000702@gmail.com> In-Reply-To: <55395DF3.3000702@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.133] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Addressing: Do we need link addressing? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 09:23:19 -0000 PiA+IEknZCBsaWtlIHRvIHJhaXNlIGEgcXVlc3Rpb24gdG8gdGhlIGxpc3QgZm9yIGRpc2N1c3Np b246IERvIHdlIG5lZWQgdG8gY3JlYXRlDQo+IGF1dG9ub21pYyBsaW5rIGFkZHJlc3Npbmc/DQo+ ID4NCj4gPiBIZXJlIGlzIG15IHZpZXc6IFdlIG5lZWQgdG8gZGlzdGluZ3Vpc2ggYWJvdXQgYWRk cmVzc2luZyBkb25lIGluIHRoZQ0KPiBBdXRvbm9taWMgTmV0d29ya2luZyBJbmZyYXN0cnVjdHVy ZSwgYW5kIGFkZHJlc3NpbmcgY29uZmlndXJlZCBhbmQNCj4gbWFuYWdlZCBieSBhbiBvcGVyYXRv ci4gRm9yIHRoZSBBdXRvbm9taWMgTmV0d29ya2luZyBJbmZyYXN0cnVjdHVyZSwNCj4gd2hpY2gg c2VydmVzIGF1dG9ub21pYyBzZXJ2aWNlIGFnZW50cywgSSBkbyBub3QgdGhpbmsgd2UgbmVlZCBy b3V0YWJsZQ0KPiBhZGRyZXNzZXMgb24gbGlua3MsIGFuZCBzdWdnZXN0IHRvIHVzZSBvbmx5IGxp bmstbG9jYWwgYWRkcmVzc2luZy4gU28gdGhlIG9ubHkNCj4gYWRkcmVzc2luZyB3ZSBzaG91bGQg bWFrZSByb3V0YWJsZSBhcmUgbG9vcGJhY2sgYWRkcmVzc2VzIG9uIGRldmljZXMuDQo+IA0KPiBG aXJzdGx5LCB5ZXMsIHdlIHNob3VsZCBjbGVhcmx5IHNlcGFyYXRlIHRoZSBhZGRyZXNzaW5nIHJl YWxtIHVzZWQgYnkgQVNBcw0KPiB0byBjb21tdW5pY2F0ZSBiZXR3ZWVuIHRoZW1zZWx2ZXMgZnJv bSB0aGUgYWRkcmVzc2luZyByZWFsbShzKSB1c2VkIGJ5DQo+IHRoZSB1c2VyIG5ldHdvcmsuDQo+ IChJIG1hZGUgdGhhdCAicmVhbG0ocykiIGJlY2F1c2UgaW4gdGhlIGNhc2Ugb2YgaGlnaGx5IHZp cnR1YWxpemVkIGRhdGEgY2VudHJlcw0KPiBldGMuLCB0aGVyZSBtaWdodCBiZSBtYW55IHRlbmFu dCBhZGRyZXNzaW5nIHJlYWxtcy4gQW5kIG9mIGNvdXJzZSB0aG9zZQ0KPiBhZGRyZXNzaW5nIHJl YWxtcyBtaWdodCB3ZWxsIGJlIGFkbWluaXN0ZXJlZCBieSBjZXJ0YWluIEFTQXMuKSBTbyBoZXJl LCB3ZQ0KPiBhcmUgdGFsa2luZyBhYm91dCB0aGUgYWRkcmVzc2luZyByZWFsbSB1c2VkIGJ5IHRo ZSBBU0FzIHRvIHRhbGsgdG8gZWFjaA0KPiBvdGhlci4NCg0KU28gZmFyIC0gd2UncmUgaW4gc3lu YyEgOi0pICAgQWJzb2x1dGVseSBhZ3JlZSBvbiB0aGUgcmVhbG0ocykgKFBsdXJhbCkuIFNpbmds ZSByZWFsbSBkb2VzIG5vdCBtYWtlIHNlbnNlIHRoZXNlIGRheXMuIA0KIA0KPiBCdXQgbm93IHdl IGNvbWUgdG8gYSBicmFuY2hpbmcgcG9pbnQuIE1pY2hhZWwgd2FudHMgZXZlcnlib2R5IHRvIGhh dmUgYQ0KPiBkaXN0aW5jdCBBQ1AuIEkgdGhpbmsgdGhhdCdzIGEgZmluZSBpZGVhIGJ1dCBJIHdh bnQgdG8ga2VlcCB0aGUgb3B0aW9uIHdoZXJlDQo+IHRoZXJlIGlzIG5vIEFDUCwgYnV0IHRoZSBB U0FzIHNpbXBseSBjb21tdW5pY2F0ZSB1c2luZyBJUCBhbW9uZw0KPiB0aGVtc2VsdmVzLiBJbiB0 aGF0IG1vZGUgdGhlcmUncyBub3RoaW5nIHNwZWNpYWwgYWJvdXQgYWRkcmVzc2luZzsgZm9yDQo+ IGV4YW1wbGUgYWxsIEFTQXMgY291bGQgYmUgbnVtYmVyZWQgb3V0IG9mIGEgc3BlY2lmaWMgVUxB IHByZWZpeCwgd2hpY2gNCj4gd291bGQgYmUgdGhlIEFOIGFkZHJlc3NpbmcgcmVhbG0sIGJ1dCB0 aGV5IGRvbid0IG5lZWQgdG8gYmUgcm91dGVycy4gU28gaW4NCj4gdGhhdCBtb2RlLCBubywgdGhl cmUgaXMgbm8gcmVzdHJpY3Rpb24gdG8gbGluay1sb2NhbCBhZGRyZXNzaW5nLg0KDQpXZSBkb24n dCBkaXNhZ3JlZSBhY3R1YWxseSA7LSkgICBXaGlsZSBJIHNlZSBhIG51bWJlciBvZiByZWFsIGFk dmFudGFnZXMgb2YgdGhlIEFDUCwgdGhlcmUgbWF5IHdlbGwgYmUgZW52aXJvbm1lbnRzIHdoZXJl IHRoZSBBQ1AgaXNuJ3QgZmVhc2libGUgZm9yIG9uZSByZWFzb24gb3IgYW5vdGhlci4gQ29uc3Ry YWluZWQgZGV2aWNlcyBjb3VsZCBiZSBvbmUgc3VjaCBjYXNlLiANCg0KU28sIGFzc3VtZSB0aGF0 IEFTQXMgcnVuIGluIHRoZSBkYXRhIHBsYW5lIG9mIHRoZSBuZXR3b3JrLCBhbmQgTk9UIGluIGEg c2VwYXJhdGUgQUNQLiBJIGNsYWltIHRoZSBmdW5kYW1lbnRhbHMgb2YgdGhlIGRpc2N1c3Npb24g YXBwbHkgaGVyZSBhcyB3ZWxsLiBJbiBwYXJ0aWN1bGFyOiANCg0KLSB3ZSB3YW50IGEgc3BlY2lm aWMgcmVhbG0gZm9yIHRoZSBhdXRvbm9taWMgc2VydmljZSBhZ2VudHMsIGluZGVwZW5kZW50IG9m IHdoYXQgYW4gYWRtaW4gY29uZmlndXJlcy4gIFNvOiBBU0EgdXNlcyBhdXRvbm9taWNhbGx5IHNl dCB1cCBhZGRyZXNzaW5nOyAibm9ybWFsIiBjb25maWd1cmVkIHByb2Nlc3NlcyB1c2UgdGhlIGNv bmZpZ3VyZWQgYWRkcmVzc2luZy4gV2l0aCBJUHY2IHRoaXMgc2hvdWxkbid0IGJlIGFuIGlzc3Vl LiBUaGlzIGF1dG9ub21pYyByZWFsbSBzaG91bGRuJ3QgYmUgY29uZmlndXJhYmxlOyBpdCBzaG91 bGQganVzdCBoYXBwZW4gKGp1c3QgbGlrZSBpbiB0aGUgQUNQKS4gU28gdGhlIGFkbWluIGNhbm5v dCBtZXNzIHVwIHRoZSBhZGRyZXNzaW5nIG9mIHRoZSBBU0FzLiBIZSBDQU4gbWVzcyB1cCByb3V0 aW5nIGlmIHRoZXJlJ3Mgbm8gc2VwYXJhdGUgQUNQLCBidXQgdGhhdCdzIGEgY2hvaWNlIHdlJ2xs IGhhdmUgdG8gbWFrZS4gDQoNCi0gSXQgd291bGQgYmUgbmljZSAoYWx0aG91Z2ggbm90IG1hbmRh dG9yeSkgaWYgdGhlIHNhbWUgYWRkcmVzc2luZyB3ZSB1c2UgaW5zaWRlIHRoZSBBQ1Agd291bGQg YXBwbHkgaGVyZSB0b28uIA0KDQotIHRoZSBsaW5rIGxvY2FsIGRpc2N1c3Npb24gRE9FUyBhcHBs eSBhbHNvIGluIHRoZSBkYXRhIHBsYW5lLCBpbiBteSBvcGluaW9uLCBhbmQgSSB3b3VsZCBtYWtl IHRoZSBzYW1lIGNsYWltIHRoYXQgSSBtYWRlIGZvciB0aGUgQUNQOiBJIHRoaW5rIHRoZSBhdXRv bm9taWMgaW5mcmFzdHJ1Y3R1cmUgc2hvdWxkbid0IGFzc2lnbiBhbnkgcm91dGFibGUgbGluayBh ZGRyZXNzaW5nIGZvciB0aGUgYXV0b25vbWljIHByb2Nlc3Nlcy4gKFdoYXQgdGhlIHVzZXIgZG9l cyBpcyBpbmRlcGVuZGVudCBvZiB0aGlzKS4gDQoNCi0gTm90ZTogVGhlcmUgbWF5IHdlbGwgYmUg YW4gQVNBIHRoYXQgYXNzaWducyAqdXNlciBzcGFjZSogYWRkcmVzc2luZywgdG8gYmUgdXNlZCBm b3IgdGhlIG5vcm1hbCBkYXRhIHBsYW5lLCBhbmQgU2hlbmcncyB1c2UgY2FzZSBkcmFmdCBpcyBh biBleGFtcGxlIG9mIG9uZS4gVGhpcyBpcyBwZXJmZWN0bHkgbGVnaXRpbWF0ZS4gVG8gcmUtc3Rh dGU6IFdlIGRvbid0IHdhbnQgYXV0b25vbWljYWxseSBzZXQgdXAgcm91dGFibGUgbGluayBhZGRy ZXNzaW5nICpmb3IgYXV0b25vbWljIHRyYWZmaWMqLiANCg0KPiBCYWNrIHRvIE1pY2hhZWwncyBt b2RlbC4gSSBoYXZlIGEgcXVlc3Rpb24uIElmIEFTQSBBbHBoYSBvbiBhIGdpdmVuIGxpbmsNCj4g d2FudHMgdG8gY29tbXVuaWNhdGUgd2l0aCBBU0EgQmV0YSBvbiBhbm90aGVyIGxpbmssIHdoYXQg YWRkcmVzc2VzIGFyZQ0KPiB1c2VkPw0KDQpJbiBteSBtaW5kOiBUaGUgcm91dGFibGUgVUxBIGFk ZHJlc3NlcyB0aGF0IHdlIGRlc2NyaWJlIGluIGRyYWZ0LWJlaHJpbmdlci1hbmltYS1hdXRvbm9t aWMtYWRkcmVzc2luZy4gQVNBcyBjb21tdW5pY2F0ZSB3aXRoIHRoZSBsb29wYmFjayBhZGRyZXNz ZXMgb2YgdGhlIG5vZGVzLiANCg0KTWljaGFlbA0KDQoNCg== From nobody Fri Apr 24 04:08:44 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A73581A899D for ; Fri, 24 Apr 2015 04:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNb3kB40N1zR for ; Fri, 24 Apr 2015 04:08:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22A431A899F for ; Fri, 24 Apr 2015 04:08:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVH21257; Fri, 24 Apr 2015 11:08:14 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 24 Apr 2015 12:08:03 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.93]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Fri, 24 Apr 2015 19:07:56 +0800 From: "Liubing (Leo)" To: "Michael Behringer (mbehring)" , Brian E Carpenter , Anima WG Thread-Topic: Addressing: Consensus on Separate Addressing Realms?-//RE: [Anima] Addressing: Do we need link addressing? Thread-Index: AdB9rwu1/EpJW7+cS0uz4MXtLBy7DQAFr1qAABndCAAAExt+oA== Date: Fri, 24 Apr 2015 11:07:56 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F457CEEBFF1@nkgeml506-mbx.china.huawei.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22F62DBD@xmb-rcd-x14.cisco.com> <55395DF3.3000702@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F63344@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22F63344@xmb-rcd-x14.cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Anima] Addressing: Consensus on Separate Addressing Realms?-//RE: Addressing: Do we need link addressing? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 11:08:42 -0000 Hi Michael, Brian, and all, Please allow me to fork this thread into another specific topic: do we need= separated addressing realm for ASAs communication? I see we've already had some good discussion, so let's confirm whether we c= ould reach consensus on this specific topic in this WG.=20 Let me briefly summarize current discussion here (please correct me if I ma= ke something wrong): - Requirement: we need separate addressing realm for communication between = Autonomic Service Agents. a) when there is ACP, since ACP uses separate addressing realm, the ASAs = are also naturally in a separated addressing realm. b) when there is NO ACP: b-1: use the draft-behringer-anima-autonomic-addressing to number the a= utonomic nodes ULAs on loopback interfaces. b-2: use the same prefix ( the normal data plane prefix) for autonomic = nodes. The ASAs communication is just in the normal data plane. >From the separate addressing realm perspective, the b-2 should NOT be the c= hoice. However, the b-2 could also be autonomic if [I.D.jiang-anima-prefix-= management] applies. So please allow me confirm two questions: 1. Do we reach consensus on separate addressing realm for ASAs? 2. Do we also count b-2 option in or not? Best regards, Bing > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael > Behringer (mbehring) > Sent: Friday, April 24, 2015 5:23 PM > To: Brian E Carpenter; Anima WG > Subject: Re: [Anima] Addressing: Do we need link addressing? >=20 > > > I'd like to raise a question to the list for discussion: Do we need > > > to create > > autonomic link addressing? > > > > > > Here is my view: We need to distinguish about addressing done in the > > Autonomic Networking Infrastructure, and addressing configured and > > managed by an operator. For the Autonomic Networking Infrastructure, > > which serves autonomic service agents, I do not think we need routable > > addresses on links, and suggest to use only link-local addressing. So > > the only addressing we should make routable are loopback addresses on > devices. > > > > Firstly, yes, we should clearly separate the addressing realm used by > > ASAs to communicate between themselves from the addressing realm(s) > > used by the user network. > > (I made that "realm(s)" because in the case of highly virtualized data > > centres etc., there might be many tenant addressing realms. And of > > course those addressing realms might well be administered by certain > > ASAs.) So here, we are talking about the addressing realm used by the > > ASAs to talk to each other. >=20 > So far - we're in sync! :-) Absolutely agree on the realm(s) (Plural). = Single > realm does not make sense these days. >=20 > > But now we come to a branching point. Michael wants everybody to have > > a distinct ACP. I think that's a fine idea but I want to keep the > > option where there is no ACP, but the ASAs simply communicate using IP > > among themselves. In that mode there's nothing special about > > addressing; for example all ASAs could be numbered out of a specific > > ULA prefix, which would be the AN addressing realm, but they don't > > need to be routers. So in that mode, no, there is no restriction to lin= k-local > addressing. >=20 > We don't disagree actually ;-) While I see a number of real advantages = of > the ACP, there may well be environments where the ACP isn't feasible for > one reason or another. Constrained devices could be one such case. >=20 > So, assume that ASAs run in the data plane of the network, and NOT in a > separate ACP. I claim the fundamentals of the discussion apply here as we= ll. > In particular: >=20 > - we want a specific realm for the autonomic service agents, independent = of > what an admin configures. So: ASA uses autonomically set up addressing; > "normal" configured processes use the configured addressing. With IPv6 th= is > shouldn't be an issue. This autonomic realm shouldn't be configurable; it > should just happen (just like in the ACP). So the admin cannot mess up th= e > addressing of the ASAs. He CAN mess up routing if there's no separate ACP= , > but that's a choice we'll have to make. >=20 > - It would be nice (although not mandatory) if the same addressing we use > inside the ACP would apply here too. >=20 > - the link local discussion DOES apply also in the data plane, in my opin= ion, > and I would make the same claim that I made for the ACP: I think the > autonomic infrastructure shouldn't assign any routable link addressing fo= r > the autonomic processes. (What the user does is independent of this). >=20 > - Note: There may well be an ASA that assigns *user space* addressing, to= be > used for the normal data plane, and Sheng's use case draft is an example = of > one. This is perfectly legitimate. To re-state: We don't want autonomical= ly > set up routable link addressing *for autonomic traffic*. >=20 > > Back to Michael's model. I have a question. If ASA Alpha on a given > > link wants to communicate with ASA Beta on another link, what > > addresses are used? >=20 > In my mind: The routable ULA addresses that we describe in > draft-behringer-anima-autonomic-addressing. ASAs communicate with the > loopback addresses of the nodes. >=20 > Michael >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Fri Apr 24 05:06:53 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 132CE1ACD05 for ; Fri, 24 Apr 2015 05:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XeY5YtrAVMOW for ; Fri, 24 Apr 2015 05:06:47 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAA601ACD0C for ; Fri, 24 Apr 2015 05:06:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6764; q=dns/txt; s=iport; t=1429877207; x=1431086807; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=KgZtoTks+KK/Y4yiNV3nWC+YSf/Frcm3D/HQbdGkYRM=; b=eZSTUEyw5ToAM0AcBWZdPIltegg8nT6SnVTcMVz6oJAxumdPorx+RqX3 QGCCVr0QpOVXEg8p4w1CdOs3pTof76AE1TPbB01UmBDPkpBYduvHbNGDZ yLMyVuYZUARLskyaBKM9NWTh9yFZeivuP498Oq6Jv5x+LEbxuriT8uY13 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AjBQBWMTpV/5xdJa1bgwxSXAXFW2YJgUcKhgQCgTs4FAEBAQEBAQGBCoQgAQEBAwEBAQEkEzQQBwQCAQgRBAEBCxQFBAcnCxQJCAIEARIIiBsIDct7AQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLN4RTOAaDEYEWBZFKi1eDRZBkI4FlU4E8b4FEgQABAQE X-IronPort-AV: E=Sophos;i="5.11,639,1422921600"; d="scan'208";a="144202370" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-6.cisco.com with ESMTP; 24 Apr 2015 12:06:46 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t3OC6jxE005319 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Apr 2015 12:06:46 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.216]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Fri, 24 Apr 2015 07:06:45 -0500 From: "Michael Behringer (mbehring)" To: "Liubing (Leo)" , Brian E Carpenter , Anima WG Thread-Topic: Addressing: Consensus on Separate Addressing Realms?-//RE: [Anima] Addressing: Do we need link addressing? Thread-Index: AQHQfgjYAXZmx4yzL0mHwaaCBM8J2J1b4TEAgAB0ZAD//7tacA== Date: Fri, 24 Apr 2015 12:06:45 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22F634DE@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22F62DBD@xmb-rcd-x14.cisco.com> <55395DF3.3000702@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F63344@xmb-rcd-x14.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F457CEEBFF1@nkgeml506-mbx.china.huawei.com> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F457CEEBFF1@nkgeml506-mbx.china.huawei.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.133] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Addressing: Consensus on Separate Addressing Realms?-//RE: Addressing: Do we need link addressing? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 12:06:52 -0000 > -----Original Message----- > From: Liubing (Leo) [mailto:leo.liubing@huawei.com] > Sent: 24 April 2015 13:08 > To: Michael Behringer (mbehring); Brian E Carpenter; Anima WG > Subject: Addressing: Consensus on Separate Addressing Realms?-//RE: > [Anima] Addressing: Do we need link addressing? >=20 > Hi Michael, Brian, and all, >=20 > Please allow me to fork this thread into another specific topic: do we ne= ed > separated addressing realm for ASAs communication? > I see we've already had some good discussion, so let's confirm whether we > could reach consensus on this specific topic in this WG. >=20 > Let me briefly summarize current discussion here (please correct me if I > make something wrong): > - Requirement: we need separate addressing realm for communication > between Autonomic Service Agents. > a) when there is ACP, since ACP uses separate addressing realm, the ASA= s > are also naturally in a separated addressing realm. > b) when there is NO ACP: > b-1: use the draft-behringer-anima-autonomic-addressing to number the > autonomic nodes ULAs on loopback interfaces. > b-2: use the same prefix ( the normal data plane prefix) for autonomi= c > nodes. The ASAs communication is just in the normal data plane. >=20 > From the separate addressing realm perspective, the b-2 should NOT be the > choice. However, the b-2 could also be autonomic if [I.D.jiang-anima-pref= ix- > management] applies. >=20 > So please allow me confirm two questions: > 1. Do we reach consensus on separate addressing realm for ASAs? > 2. Do we also count b-2 option in or not? The discussion is just starting so I doubt we can call consensus at this po= int.=20 I strongly favour a separate addressing scheme for ASAs, even in the case w= here there is no separation.=20 Arguments in favour:=20 - consistent way of addressing autonomic nodes. As an ASA developer you kno= w what you'll get.=20 - I would make this addressing scheme not configurable or modifyable. It's = an autonomic process. --> stability - Therefore: Address (mis-) configuration has little chance to interfere wi= th the autonomic addressing. (Of course for true separation you still benef= it from the ACP).=20 - and: It's cheap - I see no reason to *not* do it.=20 Michael =20 > Best regards, > Bing >=20 >=20 >=20 > > -----Original Message----- > > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael > > Behringer (mbehring) > > Sent: Friday, April 24, 2015 5:23 PM > > To: Brian E Carpenter; Anima WG > > Subject: Re: [Anima] Addressing: Do we need link addressing? > > > > > > I'd like to raise a question to the list for discussion: Do we > > > > need to create > > > autonomic link addressing? > > > > > > > > Here is my view: We need to distinguish about addressing done in > > > > the > > > Autonomic Networking Infrastructure, and addressing configured and > > > managed by an operator. For the Autonomic Networking Infrastructure, > > > which serves autonomic service agents, I do not think we need > > > routable addresses on links, and suggest to use only link-local > > > addressing. So the only addressing we should make routable are > > > loopback addresses on > > devices. > > > > > > Firstly, yes, we should clearly separate the addressing realm used > > > by ASAs to communicate between themselves from the addressing > > > realm(s) used by the user network. > > > (I made that "realm(s)" because in the case of highly virtualized > > > data centres etc., there might be many tenant addressing realms. And > > > of course those addressing realms might well be administered by > > > certain > > > ASAs.) So here, we are talking about the addressing realm used by > > > the ASAs to talk to each other. > > > > So far - we're in sync! :-) Absolutely agree on the realm(s) (Plural)= . Single > > realm does not make sense these days. > > > > > But now we come to a branching point. Michael wants everybody to > > > have a distinct ACP. I think that's a fine idea but I want to keep > > > the option where there is no ACP, but the ASAs simply communicate > > > using IP among themselves. In that mode there's nothing special > > > about addressing; for example all ASAs could be numbered out of a > > > specific ULA prefix, which would be the AN addressing realm, but > > > they don't need to be routers. So in that mode, no, there is no > > > restriction to link-local > > addressing. > > > > We don't disagree actually ;-) While I see a number of real advantage= s of > > the ACP, there may well be environments where the ACP isn't feasible > > for one reason or another. Constrained devices could be one such case. > > > > So, assume that ASAs run in the data plane of the network, and NOT in > > a separate ACP. I claim the fundamentals of the discussion apply here a= s > well. > > In particular: > > > > - we want a specific realm for the autonomic service agents, > > independent of what an admin configures. So: ASA uses autonomically > > set up addressing; "normal" configured processes use the configured > > addressing. With IPv6 this shouldn't be an issue. This autonomic realm > > shouldn't be configurable; it should just happen (just like in the > > ACP). So the admin cannot mess up the addressing of the ASAs. He CAN > > mess up routing if there's no separate ACP, but that's a choice we'll h= ave > to make. > > > > - It would be nice (although not mandatory) if the same addressing we > > use inside the ACP would apply here too. > > > > - the link local discussion DOES apply also in the data plane, in my > > opinion, and I would make the same claim that I made for the ACP: I > > think the autonomic infrastructure shouldn't assign any routable link > > addressing for the autonomic processes. (What the user does is > independent of this). > > > > - Note: There may well be an ASA that assigns *user space* addressing, > > to be used for the normal data plane, and Sheng's use case draft is an > > example of one. This is perfectly legitimate. To re-state: We don't > > want autonomically set up routable link addressing *for autonomic > traffic*. > > > > > Back to Michael's model. I have a question. If ASA Alpha on a given > > > link wants to communicate with ASA Beta on another link, what > > > addresses are used? > > > > In my mind: The routable ULA addresses that we describe in > > draft-behringer-anima-autonomic-addressing. ASAs communicate with > the > > loopback addresses of the nodes. > > > > Michael > > > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima From nobody Fri Apr 24 08:10:09 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8C61A8955 for ; Fri, 24 Apr 2015 08:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXTceOQ39UHU for ; Fri, 24 Apr 2015 08:10:07 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF7BC1A896C for ; Fri, 24 Apr 2015 08:10:06 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 3CCFE203B2; Fri, 24 Apr 2015 11:21:45 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id C761963B86; Fri, 24 Apr 2015 11:10:05 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id B1AED63784; Fri, 24 Apr 2015 11:10:05 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter In-Reply-To: <55395DF3.3000702@gmail.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22F62DBD@xmb-rcd-x14.cisco.com> <55395DF3.3000702@gmail.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Cc: Anima WG , "Michael Behringer \(mbehring\)" Subject: Re: [Anima] Addressing: Do we need link addressing? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 15:10:08 -0000 Brian E Carpenter wrote: > But now we come to a branching point. Michael wants everybody to have a > distinct ACP. I think you must mean Michael Behringer? :-) > I think that's a fine idea but I want to keep the option > where there is no ACP, but the ASAs simply communicate using IP among > themselves. So I think that the "simply communicate using IP" is not the opposite of "everybody to have a distinct ACP". I'd think that the opposite of: "everybody to have a distinct ACP". is: "the ACP is shared between different Autonomous Systems ("enterprises")" but, clearly that's not what you meant. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Fri Apr 24 09:24:26 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91AAD1ACD03 for ; Fri, 24 Apr 2015 09:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MIZ2kTLB3Y6 for ; Fri, 24 Apr 2015 09:24:16 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFEE11ACD59 for ; Fri, 24 Apr 2015 09:24:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39559; q=dns/txt; s=iport; t=1429892656; x=1431102256; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=9yhBNruvsEBqvKX3RnVFIFFa3iKhlrhSfCO9ereR84s=; b=GXeMBvNj8+EnNll7BcvmBp/Hc7v0/ICuF3vKib7cuUMNAk67IzGuJ9u3 EvOa2j+fzr9VFqHmXgXctuz66P9QO64zjKQoS9NISDKvqH+WCkkObU6QK d/oudCjgBY0bilsPJ+FPYlQSG64zQVmp0AlxQwX7Tz32Ft98dhLPitdvN 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C+BgC3bTpV/5RdJa1RCoJFR1JcBcVoPIF6AQmGBAKBPkwBAQEBAQGBC4QgAQEBAwEBAQEqQQQFBwcEAgEIEQQBAQsWAQYHJwsUCAEIAgQBEggBiBoIDcwkAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4s3hCAHLC0KAQaDEYEWBY8ygiGEAYdZPYMLjR2DTiOBZVOBPG+BRIEAAQEB X-IronPort-AV: E=Sophos;i="5.11,641,1422921600"; d="scan'208,217";a="411417863" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-1.cisco.com with ESMTP; 24 Apr 2015 16:24:13 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t3OGOCAj031594 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Apr 2015 16:24:12 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.216]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Fri, 24 Apr 2015 11:24:12 -0500 From: "Michael Behringer (mbehring)" To: Jonathan Hansford , "anima@ietf.org" Thread-Topic: [Anima] FW: New Version Notification for draft-behringer-anima-reference-model-00.txt Thread-Index: AQHP6gYZB9uNzRaalkiKtw9phnM8u5w0OEMggFH3uQCA10lp8A== Date: Fri, 24 Apr 2015 16:24:12 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22F63A43@xmb-rcd-x14.cisco.com> References: <20141017123010.13535.51699.idtracker@ietfa.amsl.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF21C816CE@xmb-rcd-x14.cisco.com> <113f01d012cf$badb0330$30910990$@hansfords.net> In-Reply-To: <113f01d012cf$badb0330$30910990$@hansfords.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.133] Content-Type: multipart/alternative; boundary="_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22F63A43xmbrcdx14ciscoc_" MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] FW: New Version Notification for draft-behringer-anima-reference-model-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 16:24:25 -0000 --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22F63A43xmbrcdx14ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jonathan, Thanks for your comments. In the new version, your comments are addressed a= s mentioned inline... From: Jonathan Hansford [mailto:jonathan@hansfords.net] Sent: 08 December 2014 11:14 To: Michael Behringer (mbehring); anima@ietf.org Subject: RE: [Anima] FW: New Version Notification for draft-behringer-anima= -reference-model-00.txt Hi, I know you are looking for high level comments, but I'm just getting my hea= d round the goals of anima and have some low level editorial comments. Hope= you don't mind: * Section 2, MASA: o Is MASA an acronym? I assume the ASA stands for Autonomic Service Agent= , but I could be wrong. * s/The MASA is service/The MASA is a service MB: fixed, and acronym expanded. * Section 3: I just don't understand the 2nd sentence. Is it trying= to say that section 2 describes the "boxes"? If so, wouldn't it be better = to say 'Section 2, The Network View, describes the "boxes".'? Or are you tr= ying to say section 3 describes the boxes identified in section 2? Is the i= ntent to have a diagram in section 2 that has boxes, lines and arrows (see = section 7)? MB: Agree, confusing, and doesn't add much. I simply removed it. * Section 3.1: * This states there are two levels inside an autonomic node but the= n only appears to mention one: 'the level of autonomic service agents'. Is = the other level the autonomic networking infrastructure? If so, perhaps it = could say 'Fundamentally, there are two levels inside an autonomic node: th= at of the autonomic service agents and that of the autonomic networking inf= rastructure, with the former using the functions of the latter.' MB: Done. * Though "Intent" is capitalised in this section, it isn't anywhere= else (figure 1 and section 7.3). I presume in each case this is a referenc= e to Intent as defined in draft-irtf-nmrg-autonomic-network-definitions, in= which case drawing the definition through and capitalising throughout migh= t be a good idea. MB: Thanks for calling this out. We decided to capitalise Intent, to distin= guish it from the "normal" word. Fixed now. * Section 7: o Again, a confusing reference to section 2. * Do you mean the "summary" of autonomic interactions forms the ACP= ? Summary doesn't feel like the right word. Might "totality" be better? MB: Good suggestion, adopted! * Section 7.1: * You identify information as being provided through configuration = or northbound interfaces and indicate autonomic functions should only minim= ally rely on the interfaces. Does that imply a greater reliance on configur= ation, or should it minimally rely on both configuration and the interfaces= ? MB: Addressed through new text by Brian. o s/neigbhour/neighbour * Section 9.1: s/in theory by attempted/in theory be attempted MB: Both fixed. See next version, shortly. Thanks for your feedback! Michael Jonathan > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael > Behringer (mbehring) > Sent: 17 October 2014 13:32 > To: anima@ietf.org > Subject: [Anima] FW: New Version Notification for draft-behringer-anima- > reference-model-00.txt > > Here the first version of the reference draft. The sections need a lot mo= re > work, but the structure should be a good starting point. Before diving in= to > the details (where we'll have no doubt lots of detailed comments), I'd li= ke to > ask specifically about high level comments regarding structure, what is > missing, etc. > > Michael > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto= :internet-drafts@ietf.org] > > Sent: 17 October 2014 14:30 > > To: Michael Behringer (mbehring); Brian E. Carpenter; Michael > > Behringer (mbehring); Toerless Eckert (eckert); Brian Carpenter; > > Toerless Eckert > > (eckert) > > Subject: New Version Notification for draft-behringer-anima-reference- > > model-00.txt > > > > > > A new version of I-D, draft-behringer-anima-reference-model-00.txt > > has been successfully submitted by Michael H. Behringer and posted to > > the IETF repository. > > > > Name: draft-behringer-anima-reference-model > > Revision: 00 > > Title: A Reference Model for Autonomic Ne= tworking > > Document date: 2014-10-17 > > Group: Individual Submission > > Pages: 9 > > URL: http://www.ietf.org/internet-drafts/draft-behringer-ani= ma- > > reference-model-00.txt > > Status: https://datatracker.ietf.org/doc/draft-behringer-anima- > > reference-model/ > > Htmlized: http://tools.ietf.org/html/draft-behringer-anima-refere= nce- > > model-00 > > > > > > Abstract: > > This document describes a reference model for Autonomic Networking. > > The goal is to define how the various elements in an autonomic > > context work together, to describe their interfaces and relations. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at tools.i= etf.org. > > > > The IETF Secretariat > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22F63A43xmbrcdx14ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Jonathan,

=  

= Thanks for your comments. In= the new version, your comments are addressed as mentioned inline…

=  

From:<= /b> Jonathan Hansford [mailto:jonathan@hansfords.net]
Sent: 08 December 2014 11:14=
To: Michael Behringer (mbehr= ing); anima@ietf.org
Subject: RE: [Anima] FW: New= Version Notification for draft-behringer-anima-reference-model-00.txt=

 

Hi,

 

I know you are looking for high level comments, but IR= 17;m just getting my head round the goals of anima and have some low level = editorial comments. Hope you don’t mind:

= ·<= span style=3D"font-size:7.0pt;font-family:"Times New Roman","= ;serif"">         Section 2, MASA:

= o   Is MASA an acronym? I assume the ASA stands for Autonomic Ser= vice Agent, but I could be wrong.

·         s/The MASA is service/The MASA= is a service

 <= /font>

MB: fixed, and acronym ex= panded.

 <= /font>

= ·<= span style=3D"font-size:7.0pt;font-family:"Times New Roman","= ;serif"">         Section 3: I just don’t understand the 2nd s= entence. Is it trying to say that section 2 describes the “boxes̶= 1;? If so, wouldn’t it be better to say ‘Section 2, The Network= View, describes the “boxes”.‘? Or are you trying to say = section 3 describes the boxes identified in section 2? Is the intent to have a dia= gram in section 2 that has boxes, lines and arrows (see section 7)?

 <= /font>

MB: Agree, confusing, and= doesn’t add much. I simply removed it.

 <= /font>

= ·<= span style=3D"font-size:7.0pt;font-family:"Times New Roman","= ;serif"">         Section 3.1:

·         This states there are two leve= ls inside an autonomic node but then only appears to mention one: ‘th= e level of autonomic service agents’. Is the other level the autonomi= c networking infrastructure? If so, perhaps it could say ‘Fundamentally, there are two levels inside an autonomi= c node: that of the autonomic service agents and that of the autonomic netw= orking infrastructure, with the former using the functions of the latter.&#= 8217;

 <= /font>

MB: Done.

 <= /font>

·         Though “Intent” is= capitalised in this section, it isn’t anywhere else (figure 1 and se= ction 7.3). I presume in each case this is a reference to Intent as defined= in draft-irtf-nmrg-autonomic-network-definitions, in which case drawing the definition through and capitalising throughout m= ight be a good idea.

 <= /font>

MB: Thanks for calling th= is out. We decided to capitalise Intent, to distinguish it from the “= normal” word. Fixed now.

 <= /font>

= ·<= span style=3D"font-size:7.0pt;font-family:"Times New Roman","= ;serif"">         Section 7:

= o   Again, a confusing reference to section 2.

·         Do you mean the “summary= ” of autonomic interactions forms the ACP? Summary doesn’t feel= like the right word. Might “totality” be better?

 <= /font>

MB: Good suggestion, adop= ted!

 <= /font>

= ·<= span style=3D"font-size:7.0pt;font-family:"Times New Roman","= ;serif"">         Section 7.1:

·         You identify information as be= ing provided through configuration or northbound interfaces and indicate au= tonomic functions should only minimally rely on the interfaces. Does that i= mply a greater reliance on configuration, or should it minimally rely on both configuration and the interfaces?

 <= /font>

MB: Addressed through new= text by Brian.

 <= /font>

= o   s/neigbhour/neighbour

= ·<= span style=3D"font-size:7.0pt;font-family:"Times New Roman","= ;serif"">         Section 9.1: s/in theory by attempted/in theory be attempted<= o:p>

 <= /font>

MB: Both fixed. See next = version, shortly.

 <= /font>

Thanks for your feedback!=

Michael=

 <= /font>

 <= /font>

Jonathan

 

> ---= --Original Message-----

> Fro= m: Anima [mailto:anima-bounces@ie= tf.org] On Behalf Of Michael

> Beh= ringer (mbehring)

> Sen= t: 17 October 2014 13:32

> To:= anima@ietf.org

> Sub= ject: [Anima] FW: New Version Notification for draft-behringer-anima-

> ref= erence-model-00.txt

>

> Here the first version of the reference draft. The s= ections need a lot more

> work, but the structure should be a good starting po= int. Before diving into

> the details (where we'll have no doubt lots of detai= led comments), I'd like to

> ask specifically about high level comments regarding= structure, what is

> missing, etc.

>

> Michael

>

>

> > -----Original Message-----

> > From: internet-drafts@ietf.org [mailto:internet-= drafts@ietf.org]

> > Sent: 17 October 2014 14:30

> > To: Michael Behringer (mbehring); Brian E. Carp= enter; Michael

> > Behringer (mbehring); Toerless Eckert (eckert);= Brian Carpenter;

> > Toerless Eckert

> > (eckert)

> > Subject: New Version Notification for draft-beh= ringer-anima-reference-

> > model-00.txt

> >

> >

> > A new version of I-D, draft-behringer-anima-ref= erence-model-00.txt

> > has been successfully submitted by Michael H. B= ehringer and posted to

> > the IETF repository.

> >

> > Name:       =             &nb= sp;       draft-behringer-anima-reference-mod= el

> > Revision:      00=

> > Title:       = ;            &n= bsp;           A Referenc= e Model for Autonomic Networking

> > Document date:     &nb= sp;  2014-10-17

> > Group:       = ;            &n= bsp;      Individual Submission<= /font>

> > Pages:       = ;            &n= bsp;       9

> > URL:       &= nbsp;    htt= p://www.ietf.org/internet-drafts/draft-behringer-anima-

> > reference-model-00.txt=

> > Status:      &nbs= p;  https:= //datatracker.ietf.org/doc/draft-behringer-anima-

> > reference-model/

> > Htmlized:       ht= tp://tools.ietf.org/html/draft-behringer-anima-reference-=

> > model-00

> >

> >

> > Abstract:

> >    This document describes a ref= erence model for Autonomic Networking.

> >    The goal is to define how the= various elements in an autonomic

> >    context work together, to des= cribe their interfaces and relations.

> >

> >

> >

> >

> > Please note that it may take a couple of minute= s from the time of

> > submission until the htmlized version and diff = are available at tools.ietf.org.

> >

> > The IETF Secretariat

>

> _______________________________________________=

> Anima mailing list

> Anima@ietf.org

> https://www.ietf.o= rg/mailman/listinfo/anima

--_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22F63A43xmbrcdx14ciscoc_-- From nobody Fri Apr 24 09:38:40 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3400A1ACCF8 for ; Fri, 24 Apr 2015 09:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abaZyr9WOYPn for ; Fri, 24 Apr 2015 09:38:37 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56B151B2B9F for ; Fri, 24 Apr 2015 09:38:34 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id EE6A6203C0 for ; Fri, 24 Apr 2015 12:50:12 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 49F6963B86; Fri, 24 Apr 2015 12:38:33 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3550363784 for ; Fri, 24 Apr 2015 12:38:33 -0400 (EDT) From: Michael Richardson To: "anima\@ietf.org" In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F457CEEBF5F@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F457CEEBF5F@nkgeml506-mbx.china.huawei.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Anima] Addressing-interface addressing X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 16:38:39 -0000 --=-=-= Content-Type: text/plain Liubing (Leo) wrote: > This is another topic regarding to autonomic addressing. > For autonomic network infrastructure, is it sufficient to self-assign > the devices' interfaces link-local addresses? Do we need to assign the > interfaces ULA/GUA addresses in some scenarios? I think that the answer depends upon which interface you are talking about. The only way that I can see that we can use and also route link-local addresses would be if we are in fact creating some kind of NBMA interface for an ACP "LAN". I don't think that's a good idea. I think it is better to use a ULA (and I have said I favour a ULA-C approach) on a loopback interface. I am happy to use SLAAC or Stable-Private (7217) for that address. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVTpxiICLcPvd0N1lAQLwQwgAt27XQMn8772rpWs3pEs9AeSyVLf4mOpT 2z1Nnqm71YbN6S2ZiNlw8nvJj1bO1PSRDsjT5IOQqiivY5ISamvLwjwL7JMmA2mV bbs91319RJC77k5hclQH3gEnb9wMV96be1zWFt2opvg73Od2pyNqj6tJGHxlA7gi kY/TxHj/AYv4PTeHUHfG752U0wfgHptlWL3tX6m1V6v60BxoY2tTPca7stdcScTF OM9rfOO/X3MUn+1dgyhq76Tp1GTk2oyZZh1x0oWy9oo3WcpPITzDVJ7bHvDFADIz oyx0tmV22IA368XG3MOtO7pyPNvJdMnxCxhEwGH/JWS0Ym3gt1WCiw== =/ojY -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Apr 24 09:43:46 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC201B375F for ; Fri, 24 Apr 2015 09:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjqPYmxKA5vv for ; Fri, 24 Apr 2015 09:43:43 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C1CB1B3762 for ; Fri, 24 Apr 2015 09:43:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3350; q=dns/txt; s=iport; t=1429893825; x=1431103425; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=C7/Dnsz8ri9/4dREdlznlZ7crigalr/DOYrk+fe1uQY=; b=THbS07g4ed9WYwE9EA0CyPowK3MzOwIrt0B8geLZh34LGVW89OoRZIbP dKoAa3VcEt1LWDau06khLpfx3/4OuCvcWyt9jE2W+0mLye3lq/WwvmwYY yuHmAo8ZjKJd64zT/8PwVNopgWGp3k8o/ypnHRUswCPl0As6Rz8wkaxAt s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CoBAB5cTpV/4gNJK1bgwxSVwUFgxXCU2YJgVGGBAIcgSI4FAEBAQEBAQGBCoQgAQEBBCMRPgUOBAIBCBEEAQEDAgYdAwICAjAUAQYBAQUDAgQTCAESiBAIBbcxlHEBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGKFoQrKDgGgmIvgRYFkVOEAYdZPYMLkGsjg3RvgQJCgQABAQE X-IronPort-AV: E=Sophos;i="5.11,641,1422921600"; d="scan'208";a="144294437" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-4.cisco.com with ESMTP; 24 Apr 2015 16:43:44 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t3OGhgGS000864 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 24 Apr 2015 16:43:42 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.216]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Fri, 24 Apr 2015 11:43:41 -0500 From: "Michael Behringer (mbehring)" To: "anima@ietf.org" Thread-Topic: New Version Notification for draft-behringer-anima-reference-model-01.txt Thread-Index: AQHQfq0q+vgFVuOKEU6RpHDqdIyu951cXTSQ Date: Fri, 24 Apr 2015 16:43:40 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22F63B1C@xmb-rcd-x14.cisco.com> References: <20150424163855.24848.63742.idtracker@ietfa.amsl.com> In-Reply-To: <20150424163855.24848.63742.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.133] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Anima] FW: New Version Notification for draft-behringer-anima-reference-model-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 16:43:44 -0000 V0csIGJlbG93IHRoZSBuZXcgdmVyc2lvbiBvZiB0aGUgcmVmZXJlbmNlIG1vZGVsLCB3aXRoIHF1 aXRlIGEgbG90IG9mIGVkaXRzIGFuZCBuZXcgdGV4dC4gDQoNCiJiaWciIGNoYW5nZXM6IA0KLSBp bmNsdWRlcyBhIG5ldyBzZWN0aW9uIGZyb20gTGF1cmVudCBvbiBjb29yZGluYXRpb24NCi0gbmV3 IHNlY3Rpb25zIG9uIGRpc2NvdmVyeSBhbmQgbmVnb3RpYXRpb24gZnJvbSBCcmlhbi4NCi0gc29t ZSBjb250ZW50IGFuZCBkaXNjdXNzaW9uIHBvaW50cyBvbiBhZGRyZXNzaW5nLiBCaW5nIGNvbnRy aWJ1dGVkIGEgbG90IGhlcmUsIGJ1dCB0aGUgY3VycmVudCB0ZXh0IGlzIG1vcmUgb2YgYSBjb2xs ZWN0aW9uIG9mIHdoYXQgbmVlZHMgdG8gYmUgZGlzY3Vzc2VkLiANCi0gbG90cyBvZiBzbWFsbCBl ZGl0cywgY2xhcmlmaWNhdGlvbnMsIGV0Yy4gDQoNCkkgYmVsaWV2ZSB3ZSBoYXZlIGFkZHJlc3Nl ZCBhbGwgY29tbWVudHMgcmVjZWl2ZWQgc28gZmFyLCB3aXRoIHRoZSBleGNlcHRpb24gb2YgdGhl IGluY2x1c2lvbiBvZiB0aGUgRE5BLiBJIGhhdmUgYSBmZXcgZG91YnRzIGFib3V0IHRoYXQsIHNv IGRpZG4ndCBpbmNsdWRlIGl0IHlldC4gTGV0J3MgZGlzY3VzcyB0aGF0IHNlcGFyYXRlbHkuIA0K DQpMb29raW5nIGZvcndhcmQgdG8gZ2V0dGluZyBtb3JlIGZlZWRiYWNrIQ0KTWljaGFlbA0KDQoN Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGll dGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPiBTZW50OiAyNCBBcHJp bCAyMDE1IDE4OjM5DQo+IFRvOiBMYXVyZW50IENpYXZhZ2xpYTsgVG9lcmxlc3MgRWNrZXJ0IChl Y2tlcnQpOyBNaWNoYWVsIEJlaHJpbmdlcg0KPiAobWJlaHJpbmcpOyBCcmlhbiBFLiBDYXJwZW50 ZXI7IExhdXJlbnQgQ2lhdmFnbGlhOyBNaWNoYWVsIEJlaHJpbmdlcg0KPiAobWJlaHJpbmcpOyBC aW5nIExpdTsgQnJpYW4gQ2FycGVudGVyOyBUb2VybGVzcyBFY2tlcnQgKGVja2VydCk7IEJpbmcg TGl1DQo+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYmVocmlu Z2VyLWFuaW1hLXJlZmVyZW5jZS0NCj4gbW9kZWwtMDEudHh0DQo+IA0KPiANCj4gQSBuZXcgdmVy c2lvbiBvZiBJLUQsIGRyYWZ0LWJlaHJpbmdlci1hbmltYS1yZWZlcmVuY2UtbW9kZWwtMDEudHh0 DQo+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTWljaGFlbCBILiBCZWhyaW5n ZXIgYW5kIHBvc3RlZCB0byB0aGUNCj4gSUVURiByZXBvc2l0b3J5Lg0KPiANCj4gTmFtZToJCWRy YWZ0LWJlaHJpbmdlci1hbmltYS1yZWZlcmVuY2UtbW9kZWwNCj4gUmV2aXNpb246CTAxDQo+IFRp dGxlOgkJQSBSZWZlcmVuY2UgTW9kZWwgZm9yIEF1dG9ub21pYyBOZXR3b3JraW5nDQo+IERvY3Vt ZW50IGRhdGU6CTIwMTUtMDQtMjQNCj4gR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4g UGFnZXM6CQkxMw0KPiBVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtYmVocmluZ2VyLWFuaW1hLQ0KPiByZWZlcmVuY2UtbW9kZWwtMDEudHh0 DQo+IFN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1iZWhyaW5nZXItYW5pbWEtDQo+IHJlZmVyZW5jZS1tb2RlbC8NCj4gSHRtbGl6ZWQ6ICAgICAg IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJlaHJpbmdlci1hbmltYS1yZWZlcmVu Y2UtDQo+IG1vZGVsLTAxDQo+IERpZmY6ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1iZWhyaW5nZXItYW5pbWEtDQo+IHJlZmVyZW5jZS1tb2RlbC0wMQ0K PiANCj4gQWJzdHJhY3Q6DQo+ICAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgcmVmZXJlbmNl IG1vZGVsIGZvciBBdXRvbm9taWMgTmV0d29ya2luZy4NCj4gICAgVGhlIGdvYWwgaXMgdG8gZGVm aW5lIGhvdyB0aGUgdmFyaW91cyBlbGVtZW50cyBpbiBhbiBhdXRvbm9taWMNCj4gICAgY29udGV4 dCB3b3JrIHRvZ2V0aGVyLCB0byBkZXNjcmliZSB0aGVpciBpbnRlcmZhY2VzIGFuZCByZWxhdGlv bnMuDQo+ICAgIFdoaWxlIHRoZSBkb2N1bWVudCBpcyB3cml0dGVuIGFzIGdlbmVyYWxseSBhcyBw b3NzaWJsZSwgdGhlIGluaXRpYWwNCj4gICAgc29sdXRpb25zIGFyZSBsaW1pdGVkIHRvIHRoZSBj aGFydGVyZWQgc2NvcGUgb2YgdGhlIFdHLg0KPiANCj4gDQo+IA0KPiANCj4gUGxlYXNlIG5vdGUg dGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4g c3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxh YmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Fri Apr 24 12:49:13 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B52E1A0113 for ; Fri, 24 Apr 2015 12:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eiUNRQPun0Q7 for ; Fri, 24 Apr 2015 12:49:10 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A911C1A0100 for ; Fri, 24 Apr 2015 12:49:10 -0700 (PDT) Received: by pabtp1 with SMTP id tp1so57011527pab.2 for ; Fri, 24 Apr 2015 12:49:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=C3WOccgko0lRrjdjqGV7EAD87yao9uciCuquwWHylZg=; b=t3c+viuRp44gZBtEoWmT3/a6KbPjMnObqEemZxFnj0lSYLJ4dhnIK9QJxvH2n3qtwR 1gieCsPnqcDbnvtx3s+l7gkami1NSskEk7z2WoYfzJC5bceweiw4AJ/u8SvRfFAggGCZ 15jtRX7UHQzmthFhVf+LDPdEYts3iWpYYYWorM6H1Q0+kgi2NAMdZ6d0lV7J5ZNkMP/Z gZ2QGOlL6biZY3t+/B5G7juwTd9gzsGq4RKtH945RsQ2vwGhi8+y5Raai04OdU8VmNzY dp/ixyAzNz46X70OzHyyqgzmCyHyL0N2O8rC8reWyqUBd6HeTCu1e+cmzejtNfv52f+2 vs/w== X-Received: by 10.70.131.33 with SMTP id oj1mr65767pdb.3.1429904950366; Fri, 24 Apr 2015 12:49:10 -0700 (PDT) Received: from ?IPv6:2406:e007:419a:1:28cc:dc4c:9703:6781? ([2406:e007:419a:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id ax2sm11982676pac.21.2015.04.24.12.49.07 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Apr 2015 12:49:09 -0700 (PDT) Message-ID: <553A9E3F.1020008@gmail.com> Date: Sat, 25 Apr 2015 07:49:19 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: anima@ietf.org References: <8AE0F17B87264D4CAC7DE0AA6C406F457CEEBF5F@nkgeml506-mbx.china.huawei.com> <14310.1429893513@sandelman.ca> In-Reply-To: <14310.1429893513@sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Addressing-interface addressing X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 19:49:12 -0000 On 25/04/2015 04:38, Michael Richardson wrote: > > Liubing (Leo) wrote: > > This is another topic regarding to autonomic addressing. > > > For autonomic network infrastructure, is it sufficient to self-assign > > the devices' interfaces link-local addresses? Do we need to assign the > > interfaces ULA/GUA addresses in some scenarios? > > I think that the answer depends upon which interface you are talking about. > > The only way that I can see that we can use and also route link-local > addresses would be if we are in fact creating some kind of NBMA interface > for an ACP "LAN". > > I don't think that's a good idea. I think it is better to use a ULA I agree. Otherwise, how do nodes on different links communication independently of the user-visible addressing scheme? > (and I > have said I favour a ULA-C approach) on a loopback interface. IMHO we don't need -C. That would imply yet another external dependency (on a non-existent registry that has no funding model anyway). Vanilla ULA works fine. Regards Brian > I am happy to > use SLAAC or Stable-Private (7217) for that address. > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Fri Apr 24 13:01:52 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F851A1A83 for ; Fri, 24 Apr 2015 13:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K01xFANUBzd9 for ; Fri, 24 Apr 2015 13:01:49 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D2121A1AC6 for ; Fri, 24 Apr 2015 13:01:49 -0700 (PDT) Received: by pdbqd1 with SMTP id qd1so57613218pdb.2 for ; Fri, 24 Apr 2015 13:01:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=HdEFr3TW8cJMdqxwRCYytFYEKkDcXncF6oAhxrkDx0w=; b=S2k4RnZ+YY58FO+yJe4wrsatEIrCEMNGchaYDrGBcU3IsmG19rMWGs6Nk23TSEUw6l VdW83X1vDUbEln+I2TvBZ7hHFiuDQ7ui2TsR+fzA2mHq8uD/MgY7u4n9o5+6QuvmCfol Jl57JzS9Zz9jZWdKJqFP+Sdh4IhwLnv5jOUdeACVd/seb0moT69fe/y9MkyVuuQa26Os C+2mLnoRJgYoRAbrhAgpVJMe+g8hjWaOlJbLWLLl4rBBBvxY13SluGIfPbAESjkw+YZz okWXnOqcfKfCyRmTBG4L3HZ3YlOJw+cIGDxkH1qBLKOnOkPdBVLrBr2B1hWKuAB93+WF CwEQ== X-Received: by 10.68.215.9 with SMTP id oe9mr159642pbc.146.1429905709292; Fri, 24 Apr 2015 13:01:49 -0700 (PDT) Received: from ?IPv6:2406:e007:419a:1:28cc:dc4c:9703:6781? ([2406:e007:419a:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id ae9sm12002219pac.25.2015.04.24.13.01.46 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Apr 2015 13:01:48 -0700 (PDT) Message-ID: <553AA136.40107@gmail.com> Date: Sat, 25 Apr 2015 08:01:58 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Michael Richardson References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22F62DBD@xmb-rcd-x14.cisco.com> <55395DF3.3000702@gmail.com> <28117.1429888205@sandelman.ca> In-Reply-To: <28117.1429888205@sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Anima WG , "Michael Behringer \(mbehring\)" Subject: Re: [Anima] Addressing: Do we need link addressing? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 20:01:50 -0000 On 25/04/2015 03:10, Michael Richardson wrote: > Brian E Carpenter wrote: > > But now we come to a branching point. Michael wants everybody to have a > > distinct ACP. > > I think you must mean Michael Behringer? :-) Yes, sorry about the ambiguous address. > > > I think that's a fine idea but I want to keep the option > > where there is no ACP, but the ASAs simply communicate using IP among > > themselves. > > So I think that the "simply communicate using IP" is not the opposite of > "everybody to have a distinct ACP". > I'd think that the opposite of: > "everybody to have a distinct ACP". > is: > "the ACP is shared between different Autonomous Systems ("enterprises")" > > but, clearly that's not what you meant. No, because we need security and trust boundaries between enterprises. There is an interesting systems-level question there though - can a service level agreement between two operators allow certain autonomic operations across the border between the two operators? As a test case, consider autonomic configuration of inter-provider QoS (compare draft-ietf-tsvwg-diffserv-intercon). In the GDNP draft we touch very briefly on this: On the other hand, a limited negotiation model might be deployed based on a limited trust relationship. For example, between two administrative domains, devices might also exchange limited information and negotiate some particular configurations based on a limited conventional or contractual trust relationship. Brian From nobody Fri Apr 24 13:06:28 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F83F1A1ADD for ; Fri, 24 Apr 2015 13:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usHR_QNC-eu5 for ; Fri, 24 Apr 2015 13:06:24 -0700 (PDT) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0464E1A1B00 for ; Fri, 24 Apr 2015 13:06:20 -0700 (PDT) Received: by pdbnk13 with SMTP id nk13so57662208pdb.0 for ; Fri, 24 Apr 2015 13:06:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=IOx6hLpAbY8qLOHxWgtxAjFckOAqyxFicrZ/qKueg7w=; b=qQaJ0WGRDNu1o7cUhaCzt6UnmmkslgFXGqe7ppWg84uTDOJe9vxNENGE59D1oppf9T jcnIC4zMd47PnnMJdwdRvY1M7+Pyj1K0/kXyOb6QYyPzjPm1vVN6Nrbntzy0I2OPoD9h tLXePyD5BNyCgv3lJxq5FWnTbgLk+hdvBTS0L/uYK7j5X+tpDuFOSZxAVDz3Brt2ESSG AmYw6MvJ0g/CNR2xVdHSAU7Z6p1jtjj38x7ok4qS+Yrd76K6ynaVcb9PnbeeWHbTybLE PiAy0a6WZLmvKTF/2k9zCsOld9DTiHG3iajUzmh0Fsjnd1FJ4cBSQ3pTFT+xiV1dMcoC HkzA== X-Received: by 10.70.51.67 with SMTP id i3mr88753pdo.145.1429905979747; Fri, 24 Apr 2015 13:06:19 -0700 (PDT) Received: from ?IPv6:2406:e007:419a:1:28cc:dc4c:9703:6781? ([2406:e007:419a:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id oj10sm11928636pdb.38.2015.04.24.13.06.14 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Apr 2015 13:06:17 -0700 (PDT) Message-ID: <553AA242.2040908@gmail.com> Date: Sat, 25 Apr 2015 08:06:26 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Michael Behringer (mbehring)" , "Liubing (Leo)" , Anima WG References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22F62DBD@xmb-rcd-x14.cisco.com> <55395DF3.3000702@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F63344@xmb-rcd-x14.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F457CEEBFF1@nkgeml506-mbx.china.huawei.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F634DE@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22F634DE@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Addressing: Consensus on Separate Addressing Realms?-//RE: Addressing: Do we need link addressing? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 20:06:26 -0000 On 25/04/2015 00:06, Michael Behringer (mbehring) wrote: >> -----Original Message----- >> From: Liubing (Leo) [mailto:leo.liubing@huawei.com] >> Sent: 24 April 2015 13:08 >> To: Michael Behringer (mbehring); Brian E Carpenter; Anima WG >> Subject: Addressing: Consensus on Separate Addressing Realms?-//RE: >> [Anima] Addressing: Do we need link addressing? >> >> Hi Michael, Brian, and all, >> >> Please allow me to fork this thread into another specific topic: do we need >> separated addressing realm for ASAs communication? >> I see we've already had some good discussion, so let's confirm whether we >> could reach consensus on this specific topic in this WG. >> >> Let me briefly summarize current discussion here (please correct me if I >> make something wrong): >> - Requirement: we need separate addressing realm for communication >> between Autonomic Service Agents. >> a) when there is ACP, since ACP uses separate addressing realm, the ASAs >> are also naturally in a separated addressing realm. >> b) when there is NO ACP: >> b-1: use the draft-behringer-anima-autonomic-addressing to number the >> autonomic nodes ULAs on loopback interfaces. >> b-2: use the same prefix ( the normal data plane prefix) for autonomic >> nodes. The ASAs communication is just in the normal data plane. >> >> From the separate addressing realm perspective, the b-2 should NOT be the >> choice. However, the b-2 could also be autonomic if [I.D.jiang-anima-prefix- >> management] applies. >> >> So please allow me confirm two questions: >> 1. Do we reach consensus on separate addressing realm for ASAs? >> 2. Do we also count b-2 option in or not? > > The discussion is just starting so I doubt we can call consensus at this point. > > I strongly favour a separate addressing scheme for ASAs, even in the case where there is no separation. > > Arguments in favour: > - consistent way of addressing autonomic nodes. As an ASA developer you know what you'll get. > - I would make this addressing scheme not configurable or modifyable. It's an autonomic process. --> stability > - Therefore: Address (mis-) configuration has little chance to interfere with the autonomic addressing. (Of course for true separation you still benefit from the ACP). > - and: It's cheap - I see no reason to *not* do it. I tend to agree with Michael B on this. There is the minor point that I just raised in response to Michael R: what if we have a specific use case that crosses the normal (enterprise-based) trust boundary? For that particular case, we might have to run an autonomic process in public address space. Of course, it would still need to be secured (e.g. with TLS). Brian > > Michael > >> Best regards, >> Bing >> >> >> >>> -----Original Message----- >>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael >>> Behringer (mbehring) >>> Sent: Friday, April 24, 2015 5:23 PM >>> To: Brian E Carpenter; Anima WG >>> Subject: Re: [Anima] Addressing: Do we need link addressing? >>> >>>>> I'd like to raise a question to the list for discussion: Do we >>>>> need to create >>>> autonomic link addressing? >>>>> >>>>> Here is my view: We need to distinguish about addressing done in >>>>> the >>>> Autonomic Networking Infrastructure, and addressing configured and >>>> managed by an operator. For the Autonomic Networking Infrastructure, >>>> which serves autonomic service agents, I do not think we need >>>> routable addresses on links, and suggest to use only link-local >>>> addressing. So the only addressing we should make routable are >>>> loopback addresses on >>> devices. >>>> >>>> Firstly, yes, we should clearly separate the addressing realm used >>>> by ASAs to communicate between themselves from the addressing >>>> realm(s) used by the user network. >>>> (I made that "realm(s)" because in the case of highly virtualized >>>> data centres etc., there might be many tenant addressing realms. And >>>> of course those addressing realms might well be administered by >>>> certain >>>> ASAs.) So here, we are talking about the addressing realm used by >>>> the ASAs to talk to each other. >>> >>> So far - we're in sync! :-) Absolutely agree on the realm(s) (Plural). Single >>> realm does not make sense these days. >>> >>>> But now we come to a branching point. Michael wants everybody to >>>> have a distinct ACP. I think that's a fine idea but I want to keep >>>> the option where there is no ACP, but the ASAs simply communicate >>>> using IP among themselves. In that mode there's nothing special >>>> about addressing; for example all ASAs could be numbered out of a >>>> specific ULA prefix, which would be the AN addressing realm, but >>>> they don't need to be routers. So in that mode, no, there is no >>>> restriction to link-local >>> addressing. >>> >>> We don't disagree actually ;-) While I see a number of real advantages of >>> the ACP, there may well be environments where the ACP isn't feasible >>> for one reason or another. Constrained devices could be one such case. >>> >>> So, assume that ASAs run in the data plane of the network, and NOT in >>> a separate ACP. I claim the fundamentals of the discussion apply here as >> well. >>> In particular: >>> >>> - we want a specific realm for the autonomic service agents, >>> independent of what an admin configures. So: ASA uses autonomically >>> set up addressing; "normal" configured processes use the configured >>> addressing. With IPv6 this shouldn't be an issue. This autonomic realm >>> shouldn't be configurable; it should just happen (just like in the >>> ACP). So the admin cannot mess up the addressing of the ASAs. He CAN >>> mess up routing if there's no separate ACP, but that's a choice we'll have >> to make. >>> >>> - It would be nice (although not mandatory) if the same addressing we >>> use inside the ACP would apply here too. >>> >>> - the link local discussion DOES apply also in the data plane, in my >>> opinion, and I would make the same claim that I made for the ACP: I >>> think the autonomic infrastructure shouldn't assign any routable link >>> addressing for the autonomic processes. (What the user does is >> independent of this). >>> >>> - Note: There may well be an ASA that assigns *user space* addressing, >>> to be used for the normal data plane, and Sheng's use case draft is an >>> example of one. This is perfectly legitimate. To re-state: We don't >>> want autonomically set up routable link addressing *for autonomic >> traffic*. >>> >>>> Back to Michael's model. I have a question. If ASA Alpha on a given >>>> link wants to communicate with ASA Beta on another link, what >>>> addresses are used? >>> >>> In my mind: The routable ULA addresses that we describe in >>> draft-behringer-anima-autonomic-addressing. ASAs communicate with >> the >>> loopback addresses of the nodes. >>> >>> Michael >>> >>> >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima > From nobody Fri Apr 24 14:12:04 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB6E1AC3DB for ; Fri, 24 Apr 2015 14:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99hL1_zw33zI for ; Fri, 24 Apr 2015 14:12:02 -0700 (PDT) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10A6E1AC3D5 for ; Fri, 24 Apr 2015 14:12:02 -0700 (PDT) Received: by qcrf4 with SMTP id f4so32595033qcr.0 for ; Fri, 24 Apr 2015 14:12:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=Qb0rvxnl3l6HqbJbR0nKPrzbwIvyBv5xmna7Gaj8YZ0=; b=v1BZVfPepObcWHmD6ceaMs5poKiGMskb8GIOH2xwjB6Zn6/wtDjIuhCZVNC7q7a2KA lvD2paLa7zzXZrGOuUDt13kGfnJsz+bGvX2j9jLca7mzndHuv1MuVFXpv9BVh6l09tD4 bf6nfMmtwkWhd+gt/m2IyWXmDpa4sBdkXJ0OsyuT3o6CK4/JCT31H+qacA5MQHXtDEkS iFLo5lUwt4Lnl/DeG/eO/1XrANlH2fk+NZszre6amkFpzS/fD1/DxoSRqUxR97OxyvIO 3dXnl/yGsdezXcnOIqYqPGYXFTc9UX7pTaI/oNFLl3d5z8yFsZZRpgzDb0+D4ZKp0Kdt YrQA== MIME-Version: 1.0 X-Received: by 10.55.20.136 with SMTP id 8mr782774qku.16.1429909921321; Fri, 24 Apr 2015 14:12:01 -0700 (PDT) Sender: mcharlesr@gmail.com Received: by 10.140.166.3 with HTTP; Fri, 24 Apr 2015 14:12:00 -0700 (PDT) Received: by 10.140.166.3 with HTTP; Fri, 24 Apr 2015 14:12:00 -0700 (PDT) Date: Fri, 24 Apr 2015 17:12:00 -0400 X-Google-Sender-Auth: PoS2bNEOgchk7A532hdfUlWI8nM Message-ID: From: Michael Richardson To: anima@ietf.org Content-Type: multipart/alternative; boundary=001a114001aeebd71d05147ed811 Archived-At: Subject: [Anima] Behringer anima autonimic addressing document X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 21:12:03 -0000 --001a114001aeebd71d05147ed811 Content-Type: text/plain; charset=UTF-8 behringer-anima-autonomic-addressing-00 on the bus just now. The assumption here is that each node was imprinted with a domain name, and either generated its own hostname, ("gsr12000-a13bf9a" would suffice to start) or was assigned one. But, the entity that did this did not bother to tell each machine a ULA to use. Further, noting that routing algorithms such RPL can distribute prefixes via PIOs in the downward DIO, as well HNCP/DNCP can also do the same and also settle conflicts among chosen ULAs.... I am not sure why deriving a ULA from a name (that needs to configured) is a good thing. --001a114001aeebd71d05147ed811 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

behringer-anima-autonomic-addressing-00 on the bus just now.=

The assumption here is that each node was imprinted with a d= omain name, and either generated its own hostname, ("gsr12000-a13bf9a&= quot; would suffice to start) or was assigned one.
But, the entity that did this did not bother to tell each machine a ULA to = use.=C2=A0 Further, noting that routing algorithms such RPL can distribute = prefixes via PIOs in the downward DIO, as well HNCP/DNCP can also do the sa= me and also settle conflicts among chosen ULAs....
I am not sure why deriving a ULA from a name (that needs to configured) is = a good thing.

--001a114001aeebd71d05147ed811-- From nobody Sat Apr 25 17:25:39 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A881B32D6 for ; Sat, 25 Apr 2015 17:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GSqa-ASthRJ for ; Sat, 25 Apr 2015 17:25:37 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A30961B32D3 for ; Sat, 25 Apr 2015 17:25:33 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B27B0203B1 for ; Sat, 25 Apr 2015 20:37:16 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 6533F63B86; Sat, 25 Apr 2015 20:25:32 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4B43B636A2 for ; Sat, 25 Apr 2015 20:25:32 -0400 (EDT) From: Michael Richardson To: Anima WG In-Reply-To: <553AA136.40107@gmail.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22F62DBD@xmb-rcd-x14.cisco.com> <55395DF3.3000702@gmail.com> <28117.1429888205@sandelman.ca> <553AA136.40107@gmail.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Anima] Addressing: Do we need link addressing? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2015 00:25:38 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> So I think that the "simply communicate using IP" is not the opposite >> of "everybody to have a distinct ACP". I'd think that the opposite >> of: "everybody to have a distinct ACP". is: "the ACP is shared >> between different Autonomous Systems ("enterprises")" >> >> but, clearly that's not what you meant. > No, because we need security and trust boundaries between > enterprises. There is an interesting systems-level question there > though - can a service level agreement between two operators allow > certain autonomic operations across the border between the two > operators? As a test case, consider autonomic configuration of > inter-provider QoS (compare draft-ietf-tsvwg-diffserv-intercon). We could consider running an/the Autonomic resource allocation/discovery protocol between providers, but I would suggest that it would never run through the ACP, rather it would between GUAs of the routers, I think. Perhaps we will figure out how to configure this autonomically later, but for the moment, I would claim it would require a higher-level trust relationship in order setup/enable, and is therefore out of scope. (Maybe someone can later on figure out how to merge SIDR address/ASN delegations with an autonomic enabled BGP to enable an intent on both sides to enable a cross-realm diffserv signaling protocol). -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVTwweICLcPvd0N1lAQIUKQf9FPJpyE4/c1IXf/PL3JZvbIdUaz/03n/+ DO8ciFuCMYqgQFxbqXXrPoS0Re8blzHmEfSm7z2LXO1mHqWicoRmGsbZzhcGstNB +hELKuQ4EfXq/zKgDSyAaROp/GsjoYRNRTvylNUJLFLNwVol/hI1llW3fVo3F1fH zSHpzJo04AhZxiC/eYYC8tLDYxCEhXOwaVydxwGfdYTHlVmLO1JXcbItVbaAOnEB wR/uNaN334OCL8lwMCm60JzhmBw8Cv+Z0xQp6zycaOkqVsY5XCHIpnX1EE9UEvNW 5EdJ6y+R0pgsf710xsq+dpgTxnYEOd5KFUIs4tYAAFIVmgpyD8J5+Q== =69SK -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Apr 25 19:04:16 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0D31B3420 for ; Sat, 25 Apr 2015 19:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXx2RdXJvu1E for ; Sat, 25 Apr 2015 19:04:13 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7994B1B341F for ; Sat, 25 Apr 2015 19:04:13 -0700 (PDT) Received: by pdbnk13 with SMTP id nk13so88787783pdb.0 for ; Sat, 25 Apr 2015 19:04:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=nAyjWp76qCfxUH5sS+ftAdeVl3sKdVmu/pMy8WQ0eY0=; b=fi1kE2qsd3wobC999zKMp3W3xLhEYWLt4CBsH9yqzODNhWkE/WWAn1nqlItrGv4RCX qB9XseeqVW8HU+arIEa8ZbjU+1t5xSJ5zskM9jt8+PnHe9gfBQchLpO+MRaWlSxCMm2w JOdtRhTEmTXoHLHCTTaHaTxTaKiGdqXE5Qd1zNvXYAPjoWUDancGX5W3WOAOMtauAhJK DcYmOaOjjWTl7KvsEIgmcC2S2WfS/i3mUUTSpMEq/xHSaf6q0HoOCvSn/z1LeauIxcmb iYz+JF83PCWKQvSPiZRXddIdjA/+L0rJTf1jHKvfNAPwQ/Jb/Isdjo/xErPDx0ruviED uCRw== X-Received: by 10.66.117.233 with SMTP id kh9mr10290728pab.103.1430013853230; Sat, 25 Apr 2015 19:04:13 -0700 (PDT) Received: from ?IPv6:2406:e007:56fa:1:28cc:dc4c:9703:6781? ([2406:e007:56fa:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id yy2sm15136651pbb.6.2015.04.25.19.04.10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Apr 2015 19:04:12 -0700 (PDT) Message-ID: <553C4799.7000805@gmail.com> Date: Sun, 26 Apr 2015 14:04:09 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Michael Richardson , Anima WG References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22F62DBD@xmb-rcd-x14.cisco.com> <55395DF3.3000702@gmail.com> <28117.1429888205@sandelman.ca> <553AA136.40107@gmail.com> <21524.1430007932@sandelman.ca> In-Reply-To: <21524.1430007932@sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Addressing: Do we need link addressing? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2015 02:04:15 -0000 Michael, I fully agree, we can defer this question for now, as long as the protocol design is agnostic on address scope. Brian On 26/04/2015 12:25, Michael Richardson wrote: > > Brian E Carpenter wrote: > >> So I think that the "simply communicate using IP" is not the opposite > >> of "everybody to have a distinct ACP". I'd think that the opposite > >> of: "everybody to have a distinct ACP". is: "the ACP is shared > >> between different Autonomous Systems ("enterprises")" > >> > >> but, clearly that's not what you meant. > > > No, because we need security and trust boundaries between > > enterprises. There is an interesting systems-level question there > > though - can a service level agreement between two operators allow > > certain autonomic operations across the border between the two > > operators? As a test case, consider autonomic configuration of > > inter-provider QoS (compare draft-ietf-tsvwg-diffserv-intercon). > > We could consider running an/the Autonomic resource allocation/discovery > protocol between providers, but I would suggest that it would never run > through the ACP, rather it would between GUAs of the routers, I think. > > Perhaps we will figure out how to configure this autonomically later, but for > the moment, I would claim it would require a higher-level trust relationship > in order setup/enable, and is therefore out of scope. (Maybe someone can > later on figure out how to merge SIDR address/ASN delegations with an autonomic > enabled BGP to enable an intent on both sides to enable a cross-realm > diffserv signaling protocol). > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Sun Apr 26 21:02:07 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A691B2DAC for ; Sun, 26 Apr 2015 21:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqDUS86AffXm for ; Sun, 26 Apr 2015 21:02:04 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 408761B2DAA for ; Sun, 26 Apr 2015 21:02:04 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVJ05875; Mon, 27 Apr 2015 04:02:02 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 27 Apr 2015 05:02:01 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.135]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Mon, 27 Apr 2015 12:01:55 +0800 From: Sheng Jiang To: Toerless Eckert , Brian E Carpenter Thread-Topic: [Anima] GDNP: flooding discovery or announcement (was: Multicast in the ACP?) Thread-Index: AQHQfek/e9dEqgG1nU25ZKweoWpyiZ1gQC/w Date: Mon, 27 Apr 2015 04:01:54 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B925F505B8B@nkgeml512-mbx.china.huawei.com> References: <5536EE40.30705@gmail.com> <20150423171604.GB11499@cisco.com> In-Reply-To: <20150423171604.GB11499@cisco.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.197] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Anima WG Subject: Re: [Anima] GDNP: flooding discovery or announcement (was: Multicast in the ACP?) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 04:02:06 -0000 SGksIFRvZXJsZXNzIGFuZCBCcmlhbiwNCg0KSSBhbSBub3Qgc3VyZSB0aGUgYXNzdW1wdGlvbiB3 ZSBoYXZlIHRoZSBzZXJ2ZXJzIGluIEF1dG9ub21pYyBOZXR3b3JrIChhbHRob3VnaCB0aGUgbWVz c2FnZSBleGNoYW5nZSBtYXkgYmUgaW4gc2VydmVyL2NsaWVudCBtb2RlbCB3aGVuIGl0IGhhcHBl bnMgaW4gYSBjZXJ0YWluIHBhaXIgZGV2aWNlcykuIFRoaXMgYXNzdW1wdGlvbiB3b3VsZCBnaXZl IHVzIHJvYnVzdG5lc3MgaXNzdWUuIEluIG91ciBjaGFydGVyLCB3ZSBjbGFpbSB0byB3b3JrIG9u ICJkaXN0cmlidXRlZCBuZXR3b3JrIGVsZW1lbnRzIi4gU28sIGl0IGlzIGJldHRlciB0byBhc3N1 bWUgZXZlcnkgbmV0d29yayBlbGVtZW50IGlzIHRoZSBzYW1lIGFuZCB0cnkgdG8gTk9UIGRlcGVu ZCBvbiBhbnkgY2VudHJhbGl6ZWQgc2VydmVycyBhcyBtdWNoIGFzIHdlIGNhbi4gVGhhdCBzYXlz LCBpbiB0aGUgZGlzY292ZXJ5IGNhc2UsIHdlIHNob3VsZCBub3QgZGVwZW5kZW50IG9uIGFueSBo ZWxwIGZyb20gYW55IGNlbnRyYWxpemVkIHNlcnZlcnMuDQoNCkJlc3QgcmVnYXJkcywNCg0KU2hl bmcNCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogQW5pbWEgW21haWx0bzph bmltYS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVG9lcmxlc3MgRWNrZXJ0DQo+U2Vu dDogRnJpZGF5LCBBcHJpbCAyNCwgMjAxNSAxOjE2IEFNDQo+VG86IEJyaWFuIEUgQ2FycGVudGVy DQo+Q2M6IEFuaW1hIFdHDQo+U3ViamVjdDogUmU6IFtBbmltYV0gR0ROUDogZmxvb2RpbmcgZGlz Y292ZXJ5IG9yIGFubm91bmNlbWVudCAod2FzOg0KPk11bHRpY2FzdCBpbiB0aGUgQUNQPykNCj4N Cj5BcyBjb250cmlidXRvcjoNCj4NCj5CcmlhbjoNCj4NCj5JIHRoaW5rIHRoZXJlIGlzIGEgbW9y ZSBmdW5kYW1lbnRhbCBkZWNpc2lvbiBmb3IgR0ROUCwgYW5kDQo+d2UgZGlzY3Vzc2VkIHRoaXMg YSBiaXQgZHVyaW5nIG91ciBkaXNjdXNzaW9ucyBsYXN0IElFVEY6DQo+DQo+SSB1bmRlcnN0YW5k IHRoZXJlIGFyZSB0d28gYmFzaWMgYXBwcm9hY2hlcyB0byBkaXN0cmlidXRlZCBkaXNjb3ZlcnkN Cj4obWVhbmluZzoNCj5ubyBjZW50cmFsIGNvbXBvbmVudCk6DQo+DQo+YSkgVGhlIHNlcnZpY2Ut Y2xpZW50IHNlbmRzIG91dCBhIHJlcXVlc3Qgd2hpY2ggZ2V0cyBmbG9vZGVkDQo+ICAgYW5kIHRo ZSBzZXJ2ZXIgcmVwbGllcy4NCj5iKSBUaGUgc2VydmVyIHNlbmRzIG91dCBhbiBhbm5vdW5jZW1l bnRzIHdoaWNoIGdldHMgZmxvb2RlZCBhbmQNCj4gICB0aGUgc2VydmljZSBjbGllbnQgcmVtZW1i ZXJzIGl0IGFuZCB1c2VzIHdoZW4gbmVlZGVkLg0KPg0KPllvdXIgYXBwcm9hY2ggaXMgYSkuIG1E TlMgZmxvb2RpbmcgaXMgYSBiaXQgb2YgYSBoeWJyaWQgYmV0d2Vlbg0KPmEpIGFuZCBiKS4gVGhl IG9wYXF1ZSBMU0EgbWVjaGFuaXNtcyBwb3BwaW5nIHVwIGluIElHUHMgdGhlc2UNCj5kYXlzIGFy ZSBiKS4NCj4NCj5JIGFtIHdvcnJpZWQgYWJvdXQgc2NhbGluZyBvZiBhKSB3aGVuIHRoZXJlIGFy ZSBhIGxvdCBvZiBjbGllbnRzLg0KPg0KPkkgd291bGQgZ3Vlc3MgaW4gQU4gd2UgaGF2ZSBmZXcg c2VydmljZXMgYW5kIG1hbnkgY2xpZW50cyAtIG1vc3QNCj5zZXJ2aWNlcywgZXZlcnkgQU4gZGV2 aWNlIGlzIGEgY2xpZW50IG9mLg0KPg0KPkRvZXMgdGhhdCBub3QgbWVhbiB3ZSBzaG91bGQgaGF2 ZSBmbG9vZGluZyBvZiBhbm5vdW5jZW1lbnRzDQo+aW5zdGVhZCBvZiBmbG9vZGluZyBvZiBxdWVy aWVzID8NCj4NCj5PZiBjb3Vyc2UsIHRoZSBtZWNoYW5pc20gY291bGQgaGF2ZSBib3RoLi4uDQo+ DQo+Q2hlZXJzDQo+ICAgIFRvZXJsZXNzDQo+DQo+T24gV2VkLCBBcHIgMjIsIDIwMTUgYXQgMTI6 NDE6MzZQTSArMTIwMCwgQnJpYW4gRSBDYXJwZW50ZXIgd3JvdGU6DQo+PiBUaGlzIGlzIGEgcXVl c3Rpb24gdG8gdGhlIGF1dGhvcnMgb2YNCj5kcmFmdC1iZWhyaW5nZXItYW5pbWEtYXV0b25vbWlj LWNvbnRyb2wtcGxhbmUuDQo+Pg0KPj4gVGhlIGRpc2NvdmVyeSBjb21wb25lbnQgb2YgR0ROUCBp bmNsdWRlcyBsaW5rLWxvY2FsIG11bHRpY2FzdA0KPj4gbWVzc2FnZXMuIEFzIGZhciBhcyB3ZSBr bm93LCB0aGVyZSBpcyBubyB3YXkgdG8gc2VjdXJlIHRoZXNlDQo+PiBtZXNzYWdlcywgYnV0IGJ5 IGRlZmluaXRpb24gdGhleSBhcmUgb25seSBpbnRlbmRlZCBmb3INCj4+IGF1dG9ub21pYyBub2Rl cywgd2hpY2ggc2hvdWxkIGFsbCBiZSBwYXJ0IG9mIHRoZSBBQ1AuDQo+Pg0KPj4gU28sIGlzIHRo ZXJlIGFueSB3YXkgdG8gc3VwcG9ydCBzZWN1cmUgbGluay1sb2NhbCBtdWx0aWNhc3QNCj4+IHdp dGhpbiB0aGUgQUNQPw0KPj4NCj4+ICAgICBCcmlhbg0KPj4NCj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBBbmltYSBtYWlsaW5nIGxpc3QNCj4+ IEFuaW1hQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2FuaW1hDQo+DQo+LS0NCj4tLS0NCj5Ub2VybGVzcyBFY2tlcnQsIGVja2VydEBjaXNjby5jb20N Cj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPkFu aW1hIG1haWxpbmcgbGlzdA0KPkFuaW1hQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9hbmltYQ0K From nobody Sun Apr 26 21:29:06 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5681B2DDD for ; Sun, 26 Apr 2015 21:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8beLuMlZZpB for ; Sun, 26 Apr 2015 21:29:02 -0700 (PDT) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B104D1B2DE2 for ; Sun, 26 Apr 2015 21:28:55 -0700 (PDT) Received: by pdbnk13 with SMTP id nk13so115236932pdb.0 for ; Sun, 26 Apr 2015 21:28:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=v4TKulZMAU+4SA/Sda7OJvZKS78FyTrIx+c9r5kDM7k=; b=aSo7h4G5Rmj7OUoxdJpcMzy42a2Myh1qZX9T42xppQQIIw0jMhnK6/VKaae0ttkcJb apL7EakzMuG/rachCQ/5N+7T5P/HkDMEje7QJQ6nw084t+THu/6a8iTT16P++7MUfib/ dgrsh8ydaKVtP7j4TPXfTyQRXgR0PkgQOYoksSAmCcLrgNjhZ+KLpO0M1PnkNHOAuT+n TU3cr6WvYu8PH0zlyrhnJxD/GSx8CimOWvXx+5JYObK3Osur+AwGVPm+Y3G4uiY6Byr2 mJmlytDiWFwQuPiQW0IDah1Ddd9FxxG0aKLQT95HGFWH5RG8XlgtI8Xby5sJZ9Ix6XuR Rs2g== X-Received: by 10.68.213.135 with SMTP id ns7mr18577330pbc.157.1430108935361; Sun, 26 Apr 2015 21:28:55 -0700 (PDT) Received: from ?IPv6:2406:e007:6ca2:1:28cc:dc4c:9703:6781? ([2406:e007:6ca2:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id m4sm17830336pdo.78.2015.04.26.21.28.52 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Apr 2015 21:28:53 -0700 (PDT) Message-ID: <553DBB02.70309@gmail.com> Date: Mon, 27 Apr 2015 16:28:50 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Anima WG References: <20150422083359.25790.65028.idtracker@ietfa.amsl.com> In-Reply-To: <20150422083359.25790.65028.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-behringer-anima-autonomic-addressing-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 04:29:04 -0000 Hi, Thanks for separating this proposal out. I have few comments & questions. > This scheme targets exclusively loopback addresses of nodes. I have a lot of trouble with this usage of "loopback address", which has nothing to do with looping anything back. In IPv6, loopback means only one thing that I can find in the specifications, in RFC4291: "2.5.3. The Loopback Address The unicast address 0:0:0:0:0:0:0:1 is called the loopback address." I would be much more comfortable if we said what I think is actually meant, even though it takes a few more words: This scheme targets exclusively the addresses assigned to the virtual interface(s) used for autonomic communications in each autonomic node. Then, the next sentence: > We > assume that link-local addressing is used on the interfaces of links. My first idea for a fix was We assume that link-local addressing is used on the physical interfaces of links. but even that might not apply in a nested virtual environment of some kind, unless we plan to *require* that Autonomic Nodes always have access to physical interfaces. Maybe the simplest thing to do with this sentence is delete it, because the important point is that the draft describes addressing for an AN overlay. > We assume that each node has two unique properties: > > o A domain name: All devices in a domain share the same domain name. > > o A node name: This name MUST be unique inside the domain. So, since the name is used to generate an address, how does a node communicate before it discovers its domain and acquires its own FQDN? In particular, how does it do so securely? I don't understand the full sequence of events from power-on in factory condition to up and running with this type of ULA. > An example of a full node name is "node17.domain.com" Technically, that's an FQDN. To respect IETF conventions, you need to say "node17.example.com", especially since domain.com is an actual DNS registrar that you can call on +18004033568. > The fields are defined as follows: > > o FD: The prefix to indicate that the address is a ULA prefix. I suggest: o fd: The hexadecimal prefix to indicate that the address is a locally assigned ULA prefix. (lower case to respect http://tools.ietf.org/html/rfc5952#section-4.3, other changes for clarity). > o Zone ID: That's a confusing name, since Zone ID already has a very specific meaning in IPv6 (RFC 4007, RFC 6874). > The device ID is derived as follows: In an Autonomic Network, a > registrar is enrolling new devices. As part of the enrolment process > the registrar assigns a number to the device, which is unique for > this registrar, but not necessarily unique in the domain. The 64 bit > device ID is then composed as: > > o 48 bit: Registrar ID, a number unique inside the domain that > identifies the registrar which assigned the name to the device. A > MAC address of the registrar can be used for this purpose. > > o 16 bit: Device ID, a number which is unique for a given registrar, > to identify the device. This can be a sequentially assigned > number. Hmm. This seems to be constraining the registrar mechanism quite considerably. Also, 16 bits of ID might conceivably be an issue in a very large network (100k nodes doesn't seem out of question). And if you have this mechanism, why mention the FQDN, since you don't use it? > Another way to introduce hierarchy is to use sub-domains in the > naming scheme. The node names "node17.subdomainA.domain.com" and > "node4.subdomainB.domain.com" would automatically lead to different > ULA prefixes,... Two comments here. 1. Tying DNS "topology" to routing topology is bit unrealistic; when nodes move around, you don't want them to get renamed as well as renumbered. 2. To clarify, is the intention that the 40 bit hash would be over the FQDN minus the first token? Brian From nobody Sun Apr 26 21:32:43 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C71B1B2DE1 for ; Sun, 26 Apr 2015 21:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZtIZVz22rCPL for ; Sun, 26 Apr 2015 21:32:40 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FA841B2DE0 for ; Sun, 26 Apr 2015 21:32:40 -0700 (PDT) Received: by pacwv17 with SMTP id wv17so94186916pac.0 for ; Sun, 26 Apr 2015 21:32:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=w6yGUMP4m2piAqMca6j5OO48i3Zv1SfeGDIov46IPJs=; b=FJ4b5LXTOJSOmIoad54DNxayrnyVgkXFAegcKlY37bn6cdONvZsoSk0zeek79ws4mp 4Y5Y7iLq5SRe0U1sGUEuqevyKAv0wt/7Ndji/S1C13V/gszUF7pyMHwroNGcjR869i2c YS7H10EhZxQiW47FVl7hgZPSV/CIChVv7lFb3JGp6t8OOKswk/QuE9PZORcm+6tkwdhs LewLcwcLkt2ZvYhLMVXdZ2+JmnnGzgE8UcJovd4RCWA5OPXRMys9i5sCheT9oNq5047O gkxDguae8Xi0CG2Xq4dMYVcYP0XXpr2vKIeCfELio4NLfUWqNXUlz6oOQGuaB1euEhaM 3MMg== X-Received: by 10.70.129.202 with SMTP id ny10mr18474429pdb.107.1430109159995; Sun, 26 Apr 2015 21:32:39 -0700 (PDT) Received: from ?IPv6:2406:e007:6ca2:1:28cc:dc4c:9703:6781? ([2406:e007:6ca2:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id zs5sm17933110pac.11.2015.04.26.21.32.36 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Apr 2015 21:32:38 -0700 (PDT) Message-ID: <553DBBE2.1050606@gmail.com> Date: Mon, 27 Apr 2015 16:32:34 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Sheng Jiang , Toerless Eckert References: <5536EE40.30705@gmail.com> <20150423171604.GB11499@cisco.com> <5D36713D8A4E7348A7E10DF7437A4B925F505B8B@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B925F505B8B@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Anima WG Subject: Re: [Anima] GDNP: flooding discovery or announcement X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 04:32:42 -0000 On 27/04/2015 16:01, Sheng Jiang wrote: > Hi, Toerless and Brian, > > I am not sure the assumption we have the servers in Autonomic Network (although the message exchange may be in server/client model when it happens in a certain pair devices). This assumption would give us robustness issue. In our charter, we claim to work on "distributed network elements". So, it is better to assume every network element is the same and try to NOT depend on any centralized servers as much as we can. That says, in the discovery case, we should not dependent on any help from any centralized servers. Agreed, or let us say: there are no special features for centralized servers. If such a server exists, it can use the general mechanisms. Brian > > Best regards, > > Sheng > >> -----Original Message----- >> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Toerless Eckert >> Sent: Friday, April 24, 2015 1:16 AM >> To: Brian E Carpenter >> Cc: Anima WG >> Subject: Re: [Anima] GDNP: flooding discovery or announcement (was: >> Multicast in the ACP?) >> >> As contributor: >> >> Brian: >> >> I think there is a more fundamental decision for GDNP, and >> we discussed this a bit during our discussions last IETF: >> >> I understand there are two basic approaches to distributed discovery >> (meaning: >> no central component): >> >> a) The service-client sends out a request which gets flooded >> and the server replies. >> b) The server sends out an announcements which gets flooded and >> the service client remembers it and uses when needed. >> >> Your approach is a). mDNS flooding is a bit of a hybrid between >> a) and b). The opaque LSA mechanisms popping up in IGPs these >> days are b). >> >> I am worried about scaling of a) when there are a lot of clients. >> >> I would guess in AN we have few services and many clients - most >> services, every AN device is a client of. >> >> Does that not mean we should have flooding of announcements >> instead of flooding of queries ? >> >> Of course, the mechanism could have both... >> >> Cheers >> Toerless >> >> On Wed, Apr 22, 2015 at 12:41:36PM +1200, Brian E Carpenter wrote: >>> This is a question to the authors of >> draft-behringer-anima-autonomic-control-plane. >>> >>> The discovery component of GDNP includes link-local multicast >>> messages. As far as we know, there is no way to secure these >>> messages, but by definition they are only intended for >>> autonomic nodes, which should all be part of the ACP. >>> >>> So, is there any way to support secure link-local multicast >>> within the ACP? >>> >>> Brian >>> >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima >> >> -- >> --- >> Toerless Eckert, eckert@cisco.com >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima From nobody Sun Apr 26 23:10:03 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4D7A1B2E9A for ; Sun, 26 Apr 2015 23:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfsGCX3uyHw8 for ; Sun, 26 Apr 2015 23:10:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E9991B2E96 for ; Sun, 26 Apr 2015 23:09:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVJ15275; Mon, 27 Apr 2015 06:09:58 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 27 Apr 2015 07:09:58 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.135]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Mon, 27 Apr 2015 14:09:52 +0800 From: Sheng Jiang To: Brian E Carpenter , "Michael Behringer (mbehring)" , Anima WG Thread-Topic: [Anima] Multicast in the ACP? Thread-Index: AQHQfJUcEZh9UQTSQ0SWVar+cR9pup1YuJaAgAA4kYCAAN1KAIAAt/QAgAXg1JA= Date: Mon, 27 Apr 2015 06:09:51 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B925F505C0F@nkgeml512-mbx.china.huawei.com> References: <5536EE40.30705@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F5FE63@xmb-rcd-x14.cisco.com> <5537FFEF.9020308@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F626F8@xmb-rcd-x14.cisco.com> <553953E0.8090308@gmail.com> In-Reply-To: <553953E0.8090308@gmail.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.197] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] Multicast in the ACP? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 06:10:01 -0000 Pj4+Pj4gVGhlIGRpc2NvdmVyeSBjb21wb25lbnQgb2YgR0ROUCBpbmNsdWRlcyBsaW5rLWxvY2Fs IG11bHRpY2FzdA0KPj4+IG1lc3NhZ2VzLg0KPj4+Pj4gQXMgZmFyIGFzIHdlIGtub3csIHRoZXJl IGlzIG5vIHdheSB0byBzZWN1cmUgdGhlc2UgbWVzc2FnZXMsIGJ1dCBieQ0KPj4+Pj4gZGVmaW5p dGlvbiB0aGV5IGFyZSBvbmx5IGludGVuZGVkIGZvciBhdXRvbm9taWMgbm9kZXMsIHdoaWNoIHNo b3VsZA0KPj4+Pj4gYWxsIGJlIHBhcnQgb2YgdGhlIEFDUC4NCj4+Pj4+DQo+Pj4+PiBTbywgaXMg dGhlcmUgYW55IHdheSB0byBzdXBwb3J0IHNlY3VyZSBsaW5rLWxvY2FsIG11bHRpY2FzdCB3aXRo aW4gdGhlDQo+Pj4gQUNQPw0KPj4+Pg0KPj4+PiBUaGUgQUNQIGFzIGRlc2NyaWJlZCBpbiBkcmFm dC1iZWhyaW5nZXItYW5pbWEtYXV0b25vbWljLWNvbnRyb2wtcGxhbmUNCj4+PiBpcyBiYXNlZCBv biBhIGhvcCBieSBob3AgdHVubmVsIGluZnJhc3RydWN0dXJlLiBTbyBmYXIgdGhvc2UgdHVubmVs cyBhcmUgYWxsDQo+Pj4gcG9pbnQgdG8gcG9pbnQuIEkgZ3Vlc3MgeW91IGNhbiBzZW5kIGEgbGlu ay1sb2NhbCBtdWx0aWNhc3QgcGFja2V0IHRocm91Z2gNCj4+PiBzdWNoIGEgdHVubmVsLCBhbmQg aXQgd291bGQgYXV0b21hdGljYWxseSBiZW5lZml0IGZyb20gdGhlIHNlY3VyaXR5IG9mIHRoYXQN Cj4+PiB0dW5uZWwuIEJ1dCBvZiBjb3Vyc2UgdGhlcmUgaXMgb25seSBvbmUgb3RoZXIgbm9kZSBv biB0aGF0ICJsaW5rIi4NCj4+Pg0KPj4+IFJpZ2h0LCBzbyB3ZSB3b3VsZCBoYXZlIHRvIHNwZWNp ZnkgYSAicmVwbGljYXN0Iiwgd2hlcmUgdGhlIHNlbmRlciBjb3BpZXMNCj4+PiB0aGUgbWVzc2Fn ZSB0byBlYWNoIEFDUCB0dW5uZWwuIFRoYXQgc2VlbXMgbGlrZSBhIGxvdCBvZiBvdmVyaGVhZC4N Cj4+DQo+PiBOb3Qgc3VyZSBJJ20gd2l0aCB5b3UuIEEgdHVubmVsIGlzIHByZXNlbnRlZCBsaWtl IGFuIGludGVyZmFjZS4gV2hldGhlciB5b3UNCj5zZW5kIHRoZSBwYWNrZXQgb3V0IGEgbm9ybWFs IGludGVyZmFjZSBvciBhIHR1bm5lbCBpcyB0aGUgc2FtZT8gQ2FuIHlvdQ0KPmV4cGFuZD8gLi4u DQo+DQo+SWYgSSB3YW50IHRvIHNlbmQgYSBkaXNjb3ZlcnkgbWVzc2FnZSB0byBhbGwgYXV0b25v bWljIG5vZGVzIG9uIHRoZSBzYW1lDQo+cGh5c2ljYWwgbGluayBhcyBtZSwgYXMgZmFyIGFzIEkg Y2FuIHNlZSBJIGhhdmUgdHdvIGNob2ljZXM6DQo+DQo+MS4gU2VuZCBvbmUgaW5zZWN1cmUgbGlu ay1sb2NhbCBtdWx0aWNhc3QgcGFja2V0Lg0KPjIuIFNlbmQgYSBjb3B5IG9mIHRoZSBtZXNzYWdl IHRvIGVhY2ggQUNQIHR1bm5lbCBpbnRlcmZhY2UgKGJlY2F1c2UgSSBoYXZlDQo+YSBsaW5rLWxv Y2FsIHR1bm5lbCB0byBlYWNoIG90aGVyIGF1dG9ub21pYyBub2RlIG9uIHRoZSBzYW1lIGxpbmsp Lg0KPg0KPlNvIGlmIEkgaGF2ZSAxMCBwZWVycyBpbiB0aGUgQUNQIG9uIHRoZSBzYW1lIGxpbmss IEkgZWl0aGVyIHNlbmQgb25lDQo+aW5zZWN1cmUgbXVsdGljYXN0IHBhY2tldCBvciAxMCBzZWN1 cmUgY29waWVzIG9mIHRoZSBzYW1lIHBhY2tldC4NCj4NCj4oVGhpcyBkb2Vzbid0IG5lZWQgYSBt dWx0aWNhc3QgcHJvdG9jb2wsIGp1c3QgYSAic2VuZCBhIGNvcHkgdG8NCj5ldmVyeWJvZHkiIEFQ SS4pDQoNCk15IGludGVyZXN0IGhlcmUgaXMgYmV5b25kIGEgc2luZ2xlIHBoeXNpY2FsIGxpbmsu IFNpbmNlIEFDUCBoYXMgaW4gdGhlb3J5IGVzdGFibGlzaCB0aGUgcG9zc2liaWxpdHkgdG8gY29t bXVuaWNhdGlvbiB3aXRoIGFueSBhdXRvbm9taWMgbm9kZSBpbiB0aGUgZG9tYWluLCBjYW4gd2Ug YnJvYWRjYXN0ICh0aGUgc2FtZSwgaXQgZG9lcyBOT1QgbmVlZCB0byBiZSBtdWx0aWNhc3QpIHRv IGFsbCB0aGVzZSBub2RlPyBUaGlzIHdvdWxkIGJlIGEgdmVyeSB1c2VmdWwgZnVuY3Rpb24gdG8g aGF2ZSwgcGFydGljdWxhcmx5IHdoZW4gaXQgaGFzIGJlZW4gc2VjdXJlZCBhbmQgc2VwYXJhdGVk IGZyb20gZGF0YSBwbGFuZSBieSBBQ1AuDQoNCkJlc3QgcmVnYXJkcywNCg0KU2hlbmcNCg0KPiAg IEJyaWFuDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj5BbmltYSBtYWlsaW5nIGxpc3QNCj5BbmltYUBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWENCg== From nobody Mon Apr 27 01:30:04 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB1BE1B2F05 for ; Mon, 27 Apr 2015 01:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxFgvDC7p8RM for ; Mon, 27 Apr 2015 01:30:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A692E1B2F03 for ; Mon, 27 Apr 2015 01:29:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRW23079; Mon, 27 Apr 2015 08:29:58 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 27 Apr 2015 09:29:52 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.135]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Mon, 27 Apr 2015 16:29:31 +0800 From: Sheng Jiang To: Brian E Carpenter , "Michael Behringer (mbehring)" , "Liubing (Leo)" , Anima WG Thread-Topic: [Anima] Addressing: Consensus on Separate Addressing Realms?-//RE: Addressing: Do we need link addressing? Thread-Index: AQHQfoIaPG+METjUfEG0Kfrci46A+J1biyOAgACGBgCABHT4kA== Date: Mon, 27 Apr 2015 08:29:31 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B925F505C6E@nkgeml512-mbx.china.huawei.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22F62DBD@xmb-rcd-x14.cisco.com> <55395DF3.3000702@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F63344@xmb-rcd-x14.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F457CEEBFF1@nkgeml506-mbx.china.huawei.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F634DE@xmb-rcd-x14.cisco.com> <553AA242.2040908@gmail.com> In-Reply-To: <553AA242.2040908@gmail.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.197] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] Addressing: Consensus on Separate Addressing Realms?-//RE: Addressing: Do we need link addressing? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 08:30:02 -0000 SGksIEJpbmcgJiBCcmlhbiwNCg0KRmlyc3RseSwgSSBoYXZlIHRvIHBvaW50IG91dCB0aGF0IEFT QXMgYXJlIGZ1bmN0aW9ucy4gVGhleSBkbyBOT1QgaGF2ZSBhZGRyZXNzZXMuIFdoYXQgd2UgYXJl IGRpc2N1c3NpbmcgaXMgdGhlIGNvbW11bmljYXRpb24gY2hhbm5lbHMgYW5kIHRoZWlyIGNvcnJl c3BvbmRlbnQgYWRkcmVzc2VzIHRoYXQgQVNBcyB1c2UgdG8gZXhjaGFuZ2UgY29udHJvbGxpbmcg bWVzc2FnZXMuDQoNClRoZW4sIEkgYWdyZWUgdGhlIGNvbnRyb2xsaW5nIG1lc3NhZ2UgZXhjaGFu Z2luZyBzaG91bGQgZ28gdGhyb3VnaCB0aGUgQUNQIHdoaWNoIGhhcyBzZXBhcmF0ZSBhZGRyZXNz aW5nIHJlYWxtLiBJbiB0aGUgY2FzZSB0aGF0IEFDUCBpcyBub3QgYXZhaWxhYmxlIG9yIG5vdCBj aG9zZW4sIHRoZSBjb250cm9sbGluZyBtZXNzYWdlIGV4Y2hhbmdpbmcgc2hvdWxkIGJlIGRvbmUg d2l0aCBuZWNlc3Nhcnkgc2VjdXJpdHkgbWVjaGFuaXNtLiBXaGV0aGVyIGl0IHVzZXMgVUxBcyBv ciBvdGhlciBkYXRhIHBsYW5lIGFkZHJlc3NlcywgSSBkb24ndCBzZWUgbXVjaCBkaWZmZXJlbnQu IFVubGVzcyB0aGUgbmV0d29yayB1c2VzIGRpZmZlcmVudCBtZWNoYW5pc20gdG8gYnVpbGQgdXAg cm91dGluZyBmb3IgVUxBLCB0aGVuLCBVTEEgbWF5IGJlIHVzZWQgYXMgYmFja3VwIGNvbW11bmlj YXRpb24gd2F5IHdoZW4gZGF0YSBwbGFuZSBjcmFzaGVkLiBIb3dldmVyLCB3aXRob3V0IHRoZSBh bmFseXNpcyBvbiB0aGUgc3BlY2lmaWMgbWVjaGFuaXNtIHRoYXQgdXNlZCB0byBidWlsZCB1cCBy b3V0aW5nIGZvciBVTEEsIEkgZG9uJ3QgdGhpbmsgdXNpbmcgVUxBIGl0c2VsZiBpcyBhbnkgbW9y ZSByZWxpYWJsZSB0aGFuIG90aGVyIGNvbW11bmljYXRpb24gaW4gdGhlIG5vcm1hbCBkYXRhIHBs YW5lLg0KDQpCZXN0IHJlZ2FyZHMsDQoNClNoZW5nDQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPkZyb206IEFuaW1hIFttYWlsdG86YW5pbWEtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIEJyaWFuIEUNCj5DYXJwZW50ZXINCj5TZW50OiBTYXR1cmRheSwgQXByaWwgMjUsIDIw MTUgNDowNiBBTQ0KPlRvOiBNaWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpOyBMaXViaW5nIChM ZW8pOyBBbmltYSBXRw0KPlN1YmplY3Q6IFJlOiBbQW5pbWFdIEFkZHJlc3Npbmc6IENvbnNlbnN1 cyBvbiBTZXBhcmF0ZSBBZGRyZXNzaW5nDQo+UmVhbG1zPy0vL1JFOiBBZGRyZXNzaW5nOiBEbyB3 ZSBuZWVkIGxpbmsgYWRkcmVzc2luZz8NCj4NCj5PbiAyNS8wNC8yMDE1IDAwOjA2LCBNaWNoYWVs IEJlaHJpbmdlciAobWJlaHJpbmcpIHdyb3RlOg0KPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+Pj4gRnJvbTogTGl1YmluZyAoTGVvKSBbbWFpbHRvOmxlby5saXViaW5nQGh1YXdlaS5j b21dDQo+Pj4gU2VudDogMjQgQXByaWwgMjAxNSAxMzowOA0KPj4+IFRvOiBNaWNoYWVsIEJlaHJp bmdlciAobWJlaHJpbmcpOyBCcmlhbiBFIENhcnBlbnRlcjsgQW5pbWEgV0cNCj4+PiBTdWJqZWN0 OiBBZGRyZXNzaW5nOiBDb25zZW5zdXMgb24gU2VwYXJhdGUgQWRkcmVzc2luZyBSZWFsbXM/LS8v UkU6DQo+Pj4gW0FuaW1hXSBBZGRyZXNzaW5nOiBEbyB3ZSBuZWVkIGxpbmsgYWRkcmVzc2luZz8N Cj4+Pg0KPj4+IEhpIE1pY2hhZWwsIEJyaWFuLCBhbmQgYWxsLA0KPj4+DQo+Pj4gUGxlYXNlIGFs bG93IG1lIHRvIGZvcmsgdGhpcyB0aHJlYWQgaW50byBhbm90aGVyIHNwZWNpZmljIHRvcGljOiBk byB3ZSBuZWVkDQo+Pj4gc2VwYXJhdGVkIGFkZHJlc3NpbmcgcmVhbG0gZm9yIEFTQXMgY29tbXVu aWNhdGlvbj8NCj4+PiBJIHNlZSB3ZSd2ZSBhbHJlYWR5IGhhZCBzb21lIGdvb2QgZGlzY3Vzc2lv biwgc28gbGV0J3MgY29uZmlybSB3aGV0aGVyIHdlDQo+Pj4gY291bGQgcmVhY2ggY29uc2Vuc3Vz IG9uIHRoaXMgc3BlY2lmaWMgdG9waWMgaW4gdGhpcyBXRy4NCj4+Pg0KPj4+IExldCBtZSBicmll Zmx5IHN1bW1hcml6ZSBjdXJyZW50IGRpc2N1c3Npb24gaGVyZSAocGxlYXNlIGNvcnJlY3QgbWUg aWYgSQ0KPj4+IG1ha2Ugc29tZXRoaW5nIHdyb25nKToNCj4+PiAtIFJlcXVpcmVtZW50OiB3ZSBu ZWVkIHNlcGFyYXRlIGFkZHJlc3NpbmcgcmVhbG0gZm9yIGNvbW11bmljYXRpb24NCj4+PiBiZXR3 ZWVuIEF1dG9ub21pYyBTZXJ2aWNlIEFnZW50cy4NCj4+PiAgIGEpIHdoZW4gdGhlcmUgaXMgQUNQ LCBzaW5jZSBBQ1AgdXNlcyBzZXBhcmF0ZSBhZGRyZXNzaW5nIHJlYWxtLCB0aGUNCj5BU0FzDQo+ Pj4gYXJlIGFsc28gbmF0dXJhbGx5IGluIGEgc2VwYXJhdGVkIGFkZHJlc3NpbmcgcmVhbG0uDQo+ Pj4gICBiKSB3aGVuIHRoZXJlIGlzIE5PIEFDUDoNCj4+PiAgICAgYi0xOiB1c2UgdGhlIGRyYWZ0 LWJlaHJpbmdlci1hbmltYS1hdXRvbm9taWMtYWRkcmVzc2luZyB0byBudW1iZXINCj50aGUNCj4+ PiBhdXRvbm9taWMgbm9kZXMgVUxBcyBvbiBsb29wYmFjayBpbnRlcmZhY2VzLg0KPj4+ICAgICBi LTI6IHVzZSB0aGUgc2FtZSBwcmVmaXggKCB0aGUgbm9ybWFsIGRhdGEgcGxhbmUgcHJlZml4KSBm b3INCj5hdXRvbm9taWMNCj4+PiBub2Rlcy4gVGhlIEFTQXMgY29tbXVuaWNhdGlvbiBpcyBqdXN0 IGluIHRoZSBub3JtYWwgZGF0YSBwbGFuZS4NCj4+Pg0KPj4+IEZyb20gdGhlIHNlcGFyYXRlIGFk ZHJlc3NpbmcgcmVhbG0gcGVyc3BlY3RpdmUsIHRoZSBiLTIgc2hvdWxkIE5PVCBiZQ0KPnRoZQ0K Pj4+IGNob2ljZS4gSG93ZXZlciwgdGhlIGItMiBjb3VsZCBhbHNvIGJlIGF1dG9ub21pYyBpZg0K PltJLkQuamlhbmctYW5pbWEtcHJlZml4LQ0KPj4+IG1hbmFnZW1lbnRdIGFwcGxpZXMuDQo+Pj4N Cj4+PiBTbyBwbGVhc2UgYWxsb3cgbWUgY29uZmlybSB0d28gcXVlc3Rpb25zOg0KPj4+IDEuIERv IHdlIHJlYWNoIGNvbnNlbnN1cyBvbiBzZXBhcmF0ZSBhZGRyZXNzaW5nIHJlYWxtIGZvciBBU0Fz Pw0KPj4+IDIuIERvIHdlIGFsc28gY291bnQgYi0yIG9wdGlvbiBpbiBvciBub3Q/DQo+Pg0KPj4g VGhlIGRpc2N1c3Npb24gaXMganVzdCBzdGFydGluZyBzbyBJIGRvdWJ0IHdlIGNhbiBjYWxsIGNv bnNlbnN1cyBhdCB0aGlzIHBvaW50Lg0KPj4NCj4+IEkgc3Ryb25nbHkgZmF2b3VyIGEgc2VwYXJh dGUgYWRkcmVzc2luZyBzY2hlbWUgZm9yIEFTQXMsIGV2ZW4gaW4gdGhlIGNhc2UNCj53aGVyZSB0 aGVyZSBpcyBubyBzZXBhcmF0aW9uLg0KPj4NCj4+IEFyZ3VtZW50cyBpbiBmYXZvdXI6DQo+PiAt IGNvbnNpc3RlbnQgd2F5IG9mIGFkZHJlc3NpbmcgYXV0b25vbWljIG5vZGVzLiBBcyBhbiBBU0Eg ZGV2ZWxvcGVyIHlvdQ0KPmtub3cgd2hhdCB5b3UnbGwgZ2V0Lg0KPj4gLSBJIHdvdWxkIG1ha2Ug dGhpcyBhZGRyZXNzaW5nIHNjaGVtZSBub3QgY29uZmlndXJhYmxlIG9yIG1vZGlmeWFibGUuIEl0 J3MNCj5hbiBhdXRvbm9taWMgcHJvY2Vzcy4gLS0+IHN0YWJpbGl0eQ0KPj4gLSBUaGVyZWZvcmU6 IEFkZHJlc3MgKG1pcy0pIGNvbmZpZ3VyYXRpb24gaGFzIGxpdHRsZSBjaGFuY2UgdG8gaW50ZXJm ZXJlIHdpdGgNCj50aGUgYXV0b25vbWljIGFkZHJlc3NpbmcuIChPZiBjb3Vyc2UgZm9yIHRydWUg c2VwYXJhdGlvbiB5b3Ugc3RpbGwgYmVuZWZpdA0KPmZyb20gdGhlIEFDUCkuDQo+PiAtIGFuZDog SXQncyBjaGVhcCAtIEkgc2VlIG5vIHJlYXNvbiB0byAqbm90KiBkbyBpdC4NCj4NCj5JIHRlbmQg dG8gYWdyZWUgd2l0aCBNaWNoYWVsIEIgb24gdGhpcy4gVGhlcmUgaXMgdGhlIG1pbm9yIHBvaW50 IHRoYXQgSQ0KPmp1c3QgcmFpc2VkIGluIHJlc3BvbnNlIHRvIE1pY2hhZWwgUjogd2hhdCBpZiB3 ZSBoYXZlIGEgc3BlY2lmaWMgdXNlIGNhc2UNCj50aGF0IGNyb3NzZXMgdGhlIG5vcm1hbCAoZW50 ZXJwcmlzZS1iYXNlZCkgdHJ1c3QgYm91bmRhcnk/IEZvciB0aGF0IHBhcnRpY3VsYXINCj5jYXNl LCB3ZSBtaWdodCBoYXZlIHRvIHJ1biBhbiBhdXRvbm9taWMgcHJvY2VzcyBpbiBwdWJsaWMgYWRk cmVzcyBzcGFjZS4NCj5PZiBjb3Vyc2UsIGl0IHdvdWxkIHN0aWxsIG5lZWQgdG8gYmUgc2VjdXJl ZCAoZS5nLiB3aXRoIFRMUykuDQo+DQo+ICAgQnJpYW4NCj4NCj4+DQo+PiBNaWNoYWVsDQo+Pg0K Pj4+IEJlc3QgcmVnYXJkcywNCj4+PiBCaW5nDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+IEZyb206IEFuaW1hIFttYWlsdG86YW5pbWEtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1pY2hhZWwNCj4+Pj4gQmVocmluZ2VyIChtYmVocmlu ZykNCj4+Pj4gU2VudDogRnJpZGF5LCBBcHJpbCAyNCwgMjAxNSA1OjIzIFBNDQo+Pj4+IFRvOiBC cmlhbiBFIENhcnBlbnRlcjsgQW5pbWEgV0cNCj4+Pj4gU3ViamVjdDogUmU6IFtBbmltYV0gQWRk cmVzc2luZzogRG8gd2UgbmVlZCBsaW5rIGFkZHJlc3Npbmc/DQo+Pj4+DQo+Pj4+Pj4gSSdkIGxp a2UgdG8gcmFpc2UgYSBxdWVzdGlvbiB0byB0aGUgbGlzdCBmb3IgZGlzY3Vzc2lvbjogRG8gd2UN Cj4+Pj4+PiBuZWVkIHRvIGNyZWF0ZQ0KPj4+Pj4gYXV0b25vbWljIGxpbmsgYWRkcmVzc2luZz8N Cj4+Pj4+Pg0KPj4+Pj4+IEhlcmUgaXMgbXkgdmlldzogV2UgbmVlZCB0byBkaXN0aW5ndWlzaCBh Ym91dCBhZGRyZXNzaW5nIGRvbmUgaW4NCj4+Pj4+PiB0aGUNCj4+Pj4+IEF1dG9ub21pYyBOZXR3 b3JraW5nIEluZnJhc3RydWN0dXJlLCBhbmQgYWRkcmVzc2luZyBjb25maWd1cmVkIGFuZA0KPj4+ Pj4gbWFuYWdlZCBieSBhbiBvcGVyYXRvci4gRm9yIHRoZSBBdXRvbm9taWMgTmV0d29ya2luZyBJ bmZyYXN0cnVjdHVyZSwNCj4+Pj4+IHdoaWNoIHNlcnZlcyBhdXRvbm9taWMgc2VydmljZSBhZ2Vu dHMsIEkgZG8gbm90IHRoaW5rIHdlIG5lZWQNCj4+Pj4+IHJvdXRhYmxlIGFkZHJlc3NlcyBvbiBs aW5rcywgYW5kIHN1Z2dlc3QgdG8gdXNlIG9ubHkgbGluay1sb2NhbA0KPj4+Pj4gYWRkcmVzc2lu Zy4gU28gdGhlIG9ubHkgYWRkcmVzc2luZyB3ZSBzaG91bGQgbWFrZSByb3V0YWJsZSBhcmUNCj4+ Pj4+IGxvb3BiYWNrIGFkZHJlc3NlcyBvbg0KPj4+PiBkZXZpY2VzLg0KPj4+Pj4NCj4+Pj4+IEZp cnN0bHksIHllcywgd2Ugc2hvdWxkIGNsZWFybHkgc2VwYXJhdGUgdGhlIGFkZHJlc3NpbmcgcmVh bG0gdXNlZA0KPj4+Pj4gYnkgQVNBcyB0byBjb21tdW5pY2F0ZSBiZXR3ZWVuIHRoZW1zZWx2ZXMg ZnJvbSB0aGUgYWRkcmVzc2luZw0KPj4+Pj4gcmVhbG0ocykgdXNlZCBieSB0aGUgdXNlciBuZXR3 b3JrLg0KPj4+Pj4gKEkgbWFkZSB0aGF0ICJyZWFsbShzKSIgYmVjYXVzZSBpbiB0aGUgY2FzZSBv ZiBoaWdobHkgdmlydHVhbGl6ZWQNCj4+Pj4+IGRhdGEgY2VudHJlcyBldGMuLCB0aGVyZSBtaWdo dCBiZSBtYW55IHRlbmFudCBhZGRyZXNzaW5nIHJlYWxtcy4gQW5kDQo+Pj4+PiBvZiBjb3Vyc2Ug dGhvc2UgYWRkcmVzc2luZyByZWFsbXMgbWlnaHQgd2VsbCBiZSBhZG1pbmlzdGVyZWQgYnkNCj4+ Pj4+IGNlcnRhaW4NCj4+Pj4+IEFTQXMuKSBTbyBoZXJlLCB3ZSBhcmUgdGFsa2luZyBhYm91dCB0 aGUgYWRkcmVzc2luZyByZWFsbSB1c2VkIGJ5DQo+Pj4+PiB0aGUgQVNBcyB0byB0YWxrIHRvIGVh Y2ggb3RoZXIuDQo+Pj4+DQo+Pj4+IFNvIGZhciAtIHdlJ3JlIGluIHN5bmMhIDotKSAgIEFic29s dXRlbHkgYWdyZWUgb24gdGhlIHJlYWxtKHMpIChQbHVyYWwpLg0KPlNpbmdsZQ0KPj4+PiByZWFs bSBkb2VzIG5vdCBtYWtlIHNlbnNlIHRoZXNlIGRheXMuDQo+Pj4+DQo+Pj4+PiBCdXQgbm93IHdl IGNvbWUgdG8gYSBicmFuY2hpbmcgcG9pbnQuIE1pY2hhZWwgd2FudHMgZXZlcnlib2R5IHRvDQo+ Pj4+PiBoYXZlIGEgZGlzdGluY3QgQUNQLiBJIHRoaW5rIHRoYXQncyBhIGZpbmUgaWRlYSBidXQg SSB3YW50IHRvIGtlZXANCj4+Pj4+IHRoZSBvcHRpb24gd2hlcmUgdGhlcmUgaXMgbm8gQUNQLCBi dXQgdGhlIEFTQXMgc2ltcGx5IGNvbW11bmljYXRlDQo+Pj4+PiB1c2luZyBJUCBhbW9uZyB0aGVt c2VsdmVzLiBJbiB0aGF0IG1vZGUgdGhlcmUncyBub3RoaW5nIHNwZWNpYWwNCj4+Pj4+IGFib3V0 IGFkZHJlc3Npbmc7IGZvciBleGFtcGxlIGFsbCBBU0FzIGNvdWxkIGJlIG51bWJlcmVkIG91dCBv ZiBhDQo+Pj4+PiBzcGVjaWZpYyBVTEEgcHJlZml4LCB3aGljaCB3b3VsZCBiZSB0aGUgQU4gYWRk cmVzc2luZyByZWFsbSwgYnV0DQo+Pj4+PiB0aGV5IGRvbid0IG5lZWQgdG8gYmUgcm91dGVycy4g U28gaW4gdGhhdCBtb2RlLCBubywgdGhlcmUgaXMgbm8NCj4+Pj4+IHJlc3RyaWN0aW9uIHRvIGxp bmstbG9jYWwNCj4+Pj4gYWRkcmVzc2luZy4NCj4+Pj4NCj4+Pj4gV2UgZG9uJ3QgZGlzYWdyZWUg YWN0dWFsbHkgOy0pICAgV2hpbGUgSSBzZWUgYSBudW1iZXIgb2YgcmVhbCBhZHZhbnRhZ2VzDQo+ b2YNCj4+Pj4gdGhlIEFDUCwgdGhlcmUgbWF5IHdlbGwgYmUgZW52aXJvbm1lbnRzIHdoZXJlIHRo ZSBBQ1AgaXNuJ3QgZmVhc2libGUNCj4+Pj4gZm9yIG9uZSByZWFzb24gb3IgYW5vdGhlci4gQ29u c3RyYWluZWQgZGV2aWNlcyBjb3VsZCBiZSBvbmUgc3VjaCBjYXNlLg0KPj4+Pg0KPj4+PiBTbywg YXNzdW1lIHRoYXQgQVNBcyBydW4gaW4gdGhlIGRhdGEgcGxhbmUgb2YgdGhlIG5ldHdvcmssIGFu ZCBOT1QgaW4NCj4+Pj4gYSBzZXBhcmF0ZSBBQ1AuIEkgY2xhaW0gdGhlIGZ1bmRhbWVudGFscyBv ZiB0aGUgZGlzY3Vzc2lvbiBhcHBseSBoZXJlIGFzDQo+Pj4gd2VsbC4NCj4+Pj4gSW4gcGFydGlj dWxhcjoNCj4+Pj4NCj4+Pj4gLSB3ZSB3YW50IGEgc3BlY2lmaWMgcmVhbG0gZm9yIHRoZSBhdXRv bm9taWMgc2VydmljZSBhZ2VudHMsDQo+Pj4+IGluZGVwZW5kZW50IG9mIHdoYXQgYW4gYWRtaW4g Y29uZmlndXJlcy4gIFNvOiBBU0EgdXNlcyBhdXRvbm9taWNhbGx5DQo+Pj4+IHNldCB1cCBhZGRy ZXNzaW5nOyAibm9ybWFsIiBjb25maWd1cmVkIHByb2Nlc3NlcyB1c2UgdGhlIGNvbmZpZ3VyZWQN Cj4+Pj4gYWRkcmVzc2luZy4gV2l0aCBJUHY2IHRoaXMgc2hvdWxkbid0IGJlIGFuIGlzc3VlLiBU aGlzIGF1dG9ub21pYyByZWFsbQ0KPj4+PiBzaG91bGRuJ3QgYmUgY29uZmlndXJhYmxlOyBpdCBz aG91bGQganVzdCBoYXBwZW4gKGp1c3QgbGlrZSBpbiB0aGUNCj4+Pj4gQUNQKS4gU28gdGhlIGFk bWluIGNhbm5vdCBtZXNzIHVwIHRoZSBhZGRyZXNzaW5nIG9mIHRoZSBBU0FzLiBIZSBDQU4NCj4+ Pj4gbWVzcyB1cCByb3V0aW5nIGlmIHRoZXJlJ3Mgbm8gc2VwYXJhdGUgQUNQLCBidXQgdGhhdCdz IGEgY2hvaWNlIHdlJ2xsIGhhdmUNCj4+PiB0byBtYWtlLg0KPj4+Pg0KPj4+PiAtIEl0IHdvdWxk IGJlIG5pY2UgKGFsdGhvdWdoIG5vdCBtYW5kYXRvcnkpIGlmIHRoZSBzYW1lIGFkZHJlc3Npbmcg d2UNCj4+Pj4gdXNlIGluc2lkZSB0aGUgQUNQIHdvdWxkIGFwcGx5IGhlcmUgdG9vLg0KPj4+Pg0K Pj4+PiAtIHRoZSBsaW5rIGxvY2FsIGRpc2N1c3Npb24gRE9FUyBhcHBseSBhbHNvIGluIHRoZSBk YXRhIHBsYW5lLCBpbiBteQ0KPj4+PiBvcGluaW9uLCBhbmQgSSB3b3VsZCBtYWtlIHRoZSBzYW1l IGNsYWltIHRoYXQgSSBtYWRlIGZvciB0aGUgQUNQOiBJDQo+Pj4+IHRoaW5rIHRoZSBhdXRvbm9t aWMgaW5mcmFzdHJ1Y3R1cmUgc2hvdWxkbid0IGFzc2lnbiBhbnkgcm91dGFibGUgbGluaw0KPj4+ PiBhZGRyZXNzaW5nIGZvciB0aGUgYXV0b25vbWljIHByb2Nlc3Nlcy4gKFdoYXQgdGhlIHVzZXIg ZG9lcyBpcw0KPj4+IGluZGVwZW5kZW50IG9mIHRoaXMpLg0KPj4+Pg0KPj4+PiAtIE5vdGU6IFRo ZXJlIG1heSB3ZWxsIGJlIGFuIEFTQSB0aGF0IGFzc2lnbnMgKnVzZXIgc3BhY2UqIGFkZHJlc3Np bmcsDQo+Pj4+IHRvIGJlIHVzZWQgZm9yIHRoZSBub3JtYWwgZGF0YSBwbGFuZSwgYW5kIFNoZW5n J3MgdXNlIGNhc2UgZHJhZnQgaXMgYW4NCj4+Pj4gZXhhbXBsZSBvZiBvbmUuIFRoaXMgaXMgcGVy ZmVjdGx5IGxlZ2l0aW1hdGUuIFRvIHJlLXN0YXRlOiBXZSBkb24ndA0KPj4+PiB3YW50IGF1dG9u b21pY2FsbHkgc2V0IHVwIHJvdXRhYmxlIGxpbmsgYWRkcmVzc2luZyAqZm9yIGF1dG9ub21pYw0K Pj4+IHRyYWZmaWMqLg0KPj4+Pg0KPj4+Pj4gQmFjayB0byBNaWNoYWVsJ3MgbW9kZWwuIEkgaGF2 ZSBhIHF1ZXN0aW9uLiBJZiBBU0EgQWxwaGEgb24gYSBnaXZlbg0KPj4+Pj4gbGluayB3YW50cyB0 byBjb21tdW5pY2F0ZSB3aXRoIEFTQSBCZXRhIG9uIGFub3RoZXIgbGluaywgd2hhdA0KPj4+Pj4g YWRkcmVzc2VzIGFyZSB1c2VkPw0KPj4+Pg0KPj4+PiBJbiBteSBtaW5kOiBUaGUgcm91dGFibGUg VUxBIGFkZHJlc3NlcyB0aGF0IHdlIGRlc2NyaWJlIGluDQo+Pj4+IGRyYWZ0LWJlaHJpbmdlci1h bmltYS1hdXRvbm9taWMtYWRkcmVzc2luZy4gQVNBcyBjb21tdW5pY2F0ZSB3aXRoDQo+Pj4gdGhl DQo+Pj4+IGxvb3BiYWNrIGFkZHJlc3NlcyBvZiB0aGUgbm9kZXMuDQo+Pj4+DQo+Pj4+IE1pY2hh ZWwNCj4+Pj4NCj4+Pj4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+Pj4gQW5pbWEgbWFpbGluZyBsaXN0DQo+Pj4+IEFuaW1hQGlldGYub3Jn DQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWENCj4+DQo+ DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5Bbmlt YSBtYWlsaW5nIGxpc3QNCj5BbmltYUBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vYW5pbWENCg== From nobody Mon Apr 27 03:02:32 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6308A1B2FD0 for ; Mon, 27 Apr 2015 03:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4_1K-lsoqHmh for ; Mon, 27 Apr 2015 03:02:28 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C27C1A8747 for ; Mon, 27 Apr 2015 03:02:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVJ47265; Mon, 27 Apr 2015 10:02:26 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 27 Apr 2015 11:02:24 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.135]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Mon, 27 Apr 2015 18:02:13 +0800 From: Sheng Jiang To: Anima WG Thread-Topic: Call for Volunteer - ANIMA signaling design team Thread-Index: AdCA0TZKxUuNJo5JTqiT8YUJ8Qmo5A== Date: Mon, 27 Apr 2015 10:02:13 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B925F505D45@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.197] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Toerless Eckert , "Liubing \(Leo\)" , "anima-chairs@tools.ietf.org" Subject: [Anima] Call for Volunteer - ANIMA signaling design team X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 10:02:30 -0000 SGksIGFsbCwNCg0KV2UgYXJlIGNhbGxpbmcgZm9yIHZvbHVudGVlcnMgdG8gZm9ybSBhIGRlc2ln biB0aW1lIGZvciBBTklNQSBzaWduYWxpbmcgZGVzaWduIHRlYW0uIFRoZSBjaGFpcnMgaGFzIGFz c2lnbmVkIHR3byBlZGl0b3JzIChCcmlhbiBDYXJwZW50ZXIgYW5kIEJpbmcgTGl1KSwgd2UgYXJl IGV4cGVjdGluZyB1cCB0byA0IG1haW4gY29udHJpYnV0b3JzLiBUaGUgY2hhcnRlciwgaW5pdGlh bCBnb2FsIGFuZCB0YXJnZXQgZGF0ZSBmb3IgdGhlIHNpZ25hbGluZyBkZXNpZ24gdGVhbSBpcyBp bnRyb2R1Y2VkIGJlbG93LiBJdCBhbHNvIGF2YWlsYWJsZSBpbiB0aGUgZGVzaWduIHRlYW0gd2lr aSBwYWdlLg0KDQpodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9hbmltYS90cmFjL3dpa2kv U2lnbmFsaW5nDQoNCkJlY2F1c2Ugb2YgdGhlIGludGVuZGVkIGRlc2lnbiB0ZWFtIHdvcmssIHdl IGV4cGVjdCB0aGF0IHRoZSBkZXNpZ24gdGVhbSBtZW1iZXJzIHdvdWxkIG5lZWQgdG8gc3BlbmQg YXQgbGVhc3QgaGFsZiBhIGRheSBwZXIgd2VlayBvbiB0aGlzIHByb2plY3QgZm9yIG1heWJlIDQu LjYgbW9udGgsIGJ1dCBpdCBzaG91bGQgYmVjb21lIGxlc3MgYWZ0ZXJ3YXJkcy4gV2Ugd291bGQg bGlrZSB0byBsaW1pdCB0aGUgZGVzaWduIHRlYW0gdG8gb25lIHllYXIgKG9yIHNob3J0ZXIgaWYg dGhlIGdvYWxzIGFyZSByZWFjaGVkIGZhc3RlciBvZiBjb3Vyc2UpLg0KDQpBcyBXRyBjaGFpcnMg d2Ugd2lsbCBwYXJ0aWNpcGF0ZSBhbmQgaGVscCBvZiBjb3Vyc2UgaW4gdGhlIGRlc2lnbiB0ZWFt IHByaW1hcmlseSBmb3IgbG9naXN0aWNzLiBJbiBwcmluY2lwbGUsIHRoZSBkZXNpZ24gdGVhbSBk aXNjdXNzaW9ucyBzaG91bGQgYmUgb3BlbiBmb3IgYWxsIEFOSU1BIHBhcnRpY2lwYXRvcnMuIFBl b3BsZSB3aG8gaXMgaW50ZXJlc3RlZCwgYnV0IGRvIG5vdCBoYXZlIGVub3VnaCB0aW1lIHRvIGNv bW1pdCwgY291bGQgYWxzbyBiZSBhYmxlIHRvIHBhcnRpY2lwYXRlIGFuZCBtYWtlIGNvbnRyaWJ1 dGlvbnMgb3IgY29tbWVudHMuDQoNClRoaXMgY2FsbCBpcyBsYXN0IGZvciBvbmUgd2Vlay4gSXQg ZW5kcyBNYXkgM3JkLCBTdW5kYXkuIFBsZWFzZSByZXBseSBiZWZvcmUgaXQgaWYgeW91IGFyZSBp bnRlcmVzdGVkIGluIHRoZSBjb21taXRtZW50Lg0KDQpDaGFydGVyIGZvciB0aGUgc2lnbmFsaW5n IGRlc2lnbiB0ZWFtDQoNClRoZSBBbmltYSBXRyBjaGFydGVyIHN0YXRlcyBhIHJlcXVpcmVtZW50 IGZvciBkaXNjb3ZlcnkgYW5kIG5lZ290aWF0aW9uIG1lY2hhbmlzbXMgdG8gZW5hYmxlIGNsb3Nl ZC1sb29wIGludGVyYWN0aW9uIGJldHdlZW4gYXV0b25vbWljIG5vZGVzLiBJdCBhbHNvIHN0YXRl cyB0aGUgZ29hbCBvZiBkZXZlbG9waW5nIG9uZSBvciBtb3JlIHByb3RvY29sIHNwZWNpZmljYXRp b25zIChvciBleHRlbnNpb25zIHRvIGV4aXN0aW5nIHByb3RvY29scykgdG8gYWNoaWV2ZSB0aGVz ZSBnb2Fscy4gVGhlcmUgaXMgYW4gZXhpc3RpbmcgZHJhZnQgcmVxdWlyZW1lbnRzIGFuYWx5c2lz LCB3aG9zZSBtYWluIHBvaW50cyBpbmNsdWRlDQoNCiAgIC0gc3VwcG9ydCBmb3IgYW55IHR5cGUg b2YgbmV0d29yayBvYmplY3RpdmUgcGFyYW1ldGVyOw0KICAgLSBkaXNjb3ZlcnkgbXVzdCBzdXBw b3J0IGFueSB0b3BvbG9neSBhbmQgYm9vdHN0cmFwIHNjZW5hcmlvOw0KICAgLSBzeW5jaHJvbml6 ZSBwYXJhbWV0ZXJzIHdpdGggb3RoZXIgbm9kZXMgaW5kaXZpZHVhbGx5IG9yIGJ5IGZsb29kaW5n Ow0KICAgLSBuZWdvdGlhdGUgcGFyYW1ldGVycyB3aXRoIG90aGVyIG5vZGVzOw0KICAgLSBhbHdh eXMgc2VjdXJlLg0KDQpBIHNpbXBsZSBUTFYgZm9ybWF0IGlzIHByb3Bvc2VkIGZvciB0aGUgcHJv dG9jb2wgZGVzaWduLiBCaW5hcnkgb3IgbmFtZS1iYXNlZCBkaXNjb3ZlcnkgYXJlIHByb3Bvc2Vk IGFzIGFsdGVybmF0aXZlIGRpc2NvdmVyeSBhcHByb2FjaGVzLg0KDQpUaGUgcHVycG9zZSBvZiB0 aGUgZGVzaWduIHRlYW0gaXMgdG8gYW5hbHl6ZSB0aGVzZSBpc3N1ZXMgYW5kIHJlY29tbWVuZCBh IGNvbWJpbmVkIGFwcHJvYWNoIHRvIHRoZSB3b3JraW5nIGdyb3VwLCBwcmVmZXJhYmx5IGluIHRo ZSBmb3JtIG9mIG9uZSBkcmFmdCBvciBhIHNtYWxsIHNldCBvZiBjb29yZGluYXRlZCBkcmFmdHMu IFRoZSBwcm9wb3NlZCBhcHByb2FjaCBzaG91bGQgYmUgc3VpdGFibGUgZm9yIHVzZSBieSB0aGUg QXV0b25vbWljIENvbnRyb2wgUGxhbmUsIGFuZCBmb3Igb3RoZXIgdXNlIGNhc2VzIGluY2x1ZGlu ZyB0aG9zZSBsaXN0ZWQgaW4gdGhlIEFuaW1hIFdHIGNoYXJ0ZXIuDQoNCkluIHByZXBhcmluZyB0 aGUgcmVjb21tZW5kYXRpb24sIHRoZSBkZXNpZ24gdGVhbSB3aWxsIHZlcmlmeSBhbmQgdXBkYXRl IHRoZSBleGlzdGluZyByZXF1aXJlbWVudHMgYW5kIHVuZGVyc3RhbmQgdGhlIHJlbGV2YW50IHVz ZSBjYXNlcy4gSG93ZXZlciwgZG9jdW1lbnRpbmcgYW5kIHNvbHZpbmcgdXNlIGNhc2VzIGlzIG91 dCBvZiBzY29wZSBmb3IgdGhlIGRlc2lnbiB0ZWFtLiBUaGUgZGVzaWduIHRlYW0gaXMgZW5jb3Vy YWdlZCB0byBkZXZlbG9wIHByb3RvY29sIHdhbGt0aHJvdWdocyBhbmQgYW4gYWJzdHJhY3QgQVBJ IGFzIGFpZHMgdG8gdW5kZXJzdGFuZGluZy4gVGhlIGRlc2lnbiB0ZWFtIGlzIG5vdCBpdHNlbGYg ZXhwZWN0ZWQgdG8gcHJvZHVjZSBjb2RlLCBidXQgZWFzZSBvZiBpbXBsZW1lbnRhdGlvbiBpcyBh biBpbXBvcnRhbnQgY29uc2lkZXJhdGlvbi4NCg0KVGhlIGRyYWZ0KHMpIHNob3VsZCBiZSBkZWxp dmVyZWQgYnkgdGhlIEp1bHkgMjAxNSBJRVRGICgyMDE1LTA3LTA2IGN1dG9mZiBkYXRlKS4NCg0K SW5pdGlhbCBHb2Fscw0KDQogICAtIFZhbGlkYXRlIGFuZCB1cGRhdGUgdGhlIGV4aXN0aW5nIGxp c3Qgb2YgcmVxdWlyZW1lbnRzICjigItodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1j YXJwZW50ZXItYW5pbWEtZ2RuLXByb3RvY29sI3NlY3Rpb24tMikgYWdhaW5zdCBib290c3RyYXAg YW5kIEFDUCBkcmFmdHMgKGFuZCBvcHRpb25hbGx5IGFnYWluc3Qgb3RoZXIgdXNlIGNhc2UgdmFs aWRhdGlvbiBkcmFmdHMpLiBUYXJnZXQgZGF0ZTogZW5kIE1heS4NCiAgIC0gUmVjb21tZW5kIGhv dyB0aGUgb3RoZXIgbWlsZXN0b25lIGNvbXBvbmVudHMgb2YgQU5JTUEgKGJvb3RzdHJhcCwgQUNQ LCB2YWxpZGF0aW9uIGRyYWZ0cykgc2hvdWxkIHVzZSB0aGUgc2lnbmFsaW5nIHByb3RvY29sKHMp LiBBcyBhIHNpZGUtZWZmZWN0LCBjcml0aXF1ZSB0aGUgcHJvcG9zYWwgb24gdGhlIHRhYmxlICji gItodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2FycGVudGVyLWFuaW1hLWdkbi1w cm90b2NvbCNzZWN0aW9uLTMpLg0KDQpUYXJnZXQgZGF0ZTogbWlkIEp1bmUuDQoNCkJlc3QgcmVn YXJkcywNCg0KVG9lcmxlc3MgKyBTaGVuZw0K From nobody Mon Apr 27 11:15:54 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D14F41A90BD for ; Mon, 27 Apr 2015 11:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKiruHK7hMoD for ; Mon, 27 Apr 2015 11:15:49 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E0DF1A90AB for ; Mon, 27 Apr 2015 11:15:49 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so88737285lbb.2 for ; Mon, 27 Apr 2015 11:15:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=mWDM8JgEHrygne2QBHe7jCZegyGuKvuSDPQmOyYaRuk=; b=bmvknwLyRbiT+JPQzIOnRG29MTt4dCVDs7+icViFyC+NE4VpbNVQaressnlXM/orFE E8nc9mc3OTJPCTbtOFhWnj4lY2JfY3AF1hXSw5e4iBzQ4lnzCWR5DZYV/e+vRvIQLT8+ pNkc3RNeoSJVSeSk+7WVPf43pXI31036dmK4d+SLSGLaoVyu3nsFIXTsznx0KPnHa/Ss OkrLXdFneISNQjl7VvF450pGRJPy5EC5fEH2Ymxev1/tlERIQXFGs31lQGsI+kpZAlEm j6q4KRCHfLCCVRvBtr2v1eRIojsLEVIJZTlNsJwyWdVJX0ptaW0xprHBIio5FfGAhHud Aspg== MIME-Version: 1.0 X-Received: by 10.152.115.205 with SMTP id jq13mr10834874lab.2.1430158547816; Mon, 27 Apr 2015 11:15:47 -0700 (PDT) Sender: jeferson.nobre@gmail.com Received: by 10.112.252.198 with HTTP; Mon, 27 Apr 2015 11:15:47 -0700 (PDT) In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B925F505D45@nkgeml512-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B925F505D45@nkgeml512-mbx.china.huawei.com> Date: Mon, 27 Apr 2015 15:15:47 -0300 X-Google-Sender-Auth: nsPbNABcfNyZbb38JAvs-UjK-e4 Message-ID: From: =?UTF-8?Q?J=C3=A9ferson_Campos_Nobre?= To: Sheng Jiang Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Toerless Eckert , "Liubing \(Leo\)" , Anima WG , "anima-chairs@tools.ietf.org" Subject: Re: [Anima] Call for Volunteer - ANIMA signaling design team X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 18:15:52 -0000 Dear Chairs. I volunteer for the signaling design team. As a side note, I was not able to join the anima-signaling mailing list via the URL provided in the wiki. Cheers. J=C3=A9ferson Campos Nobre PhD Student Computer Networks Group - Institute of Informatics Federal University of Rio Grande do Sul http://www.inf.ufrgs.br/~jcnobre On Mon, Apr 27, 2015 at 7:02 AM, Sheng Jiang wrote: > Hi, all, > > We are calling for volunteers to form a design time for ANIMA signaling d= esign team. The chairs has assigned two editors (Brian Carpenter and Bing L= iu), we are expecting up to 4 main contributors. The charter, initial goal = and target date for the signaling design team is introduced below. It also = available in the design team wiki page. > > http://trac.tools.ietf.org/wg/anima/trac/wiki/Signaling > > Because of the intended design team work, we expect that the design team = members would need to spend at least half a day per week on this project fo= r maybe 4..6 month, but it should become less afterwards. We would like to = limit the design team to one year (or shorter if the goals are reached fast= er of course). > > As WG chairs we will participate and help of course in the design team pr= imarily for logistics. In principle, the design team discussions should be = open for all ANIMA participators. People who is interested, but do not have= enough time to commit, could also be able to participate and make contribu= tions or comments. > > This call is last for one week. It ends May 3rd, Sunday. Please reply bef= ore it if you are interested in the commitment. > > Charter for the signaling design team > > The Anima WG charter states a requirement for discovery and negotiation m= echanisms to enable closed-loop interaction between autonomic nodes. It als= o states the goal of developing one or more protocol specifications (or ext= ensions to existing protocols) to achieve these goals. There is an existing= draft requirements analysis, whose main points include > > - support for any type of network objective parameter; > - discovery must support any topology and bootstrap scenario; > - synchronize parameters with other nodes individually or by flooding; > - negotiate parameters with other nodes; > - always secure. > > A simple TLV format is proposed for the protocol design. Binary or name-b= ased discovery are proposed as alternative discovery approaches. > > The purpose of the design team is to analyze these issues and recommend a= combined approach to the working group, preferably in the form of one draf= t or a small set of coordinated drafts. The proposed approach should be sui= table for use by the Autonomic Control Plane, and for other use cases inclu= ding those listed in the Anima WG charter. > > In preparing the recommendation, the design team will verify and update t= he existing requirements and understand the relevant use cases. However, do= cumenting and solving use cases is out of scope for the design team. The de= sign team is encouraged to develop protocol walkthroughs and an abstract AP= I as aids to understanding. The design team is not itself expected to produ= ce code, but ease of implementation is an important consideration. > > The draft(s) should be delivered by the July 2015 IETF (2015-07-06 cutoff= date). > > Initial Goals > > - Validate and update the existing list of requirements (http://tools.= ietf.org/html/draft-carpenter-anima-gdn-protocol#section-2) against bootstr= ap and ACP drafts (and optionally against other use case validation drafts)= . Target date: end May. > - Recommend how the other milestone components of ANIMA (bootstrap, AC= P, validation drafts) should use the signaling protocol(s). As a side-effec= t, critique the proposal on the table (https://tools.ietf.org/html/draft-ca= rpenter-anima-gdn-protocol#section-3). > > Target date: mid June. > > Best regards, > > Toerless + Sheng > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Mon Apr 27 12:53:42 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAEB51A88EC for ; Mon, 27 Apr 2015 12:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVHy-VtZB9eg for ; Mon, 27 Apr 2015 12:53:39 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F4D11A88DB for ; Mon, 27 Apr 2015 12:53:39 -0700 (PDT) Received: by pabsx10 with SMTP id sx10so140030981pab.3 for ; Mon, 27 Apr 2015 12:53:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=XVqqgUsocJFFze4U5qkVVax/3THH9JwVEZHIwn3eOX8=; b=IuoZNsQSbVhXI1PukQYPktsVGNqGEnstD665mTMg1y+BIqHh7gUskzLwmUgck2LoD5 cSijPw/3QhoQFD+c2y9Enifre/4XHi7sN0nKApukuD+1vECH6Nd36TuLT4s3403q+wCu jMNaCS6rN0VhACiit09ltPY7wrLCrR2Ftbh3J5iLctz2O12Dg2mqmm2nQwQdKPPMzxiQ aEG4X5Z6dB6U2EOduuRU0GGXlXDydYU8vY+26pJ8JJXjwvZNKS95UoZGRwE1gokn1GFn L992Cypq/52vQIu6OOAoNSGQmSyAap2FTsHSzAMA8KfqogKy5FTKnXs8gJoJrDkZGell ukCg== X-Received: by 10.70.51.67 with SMTP id i3mr25251673pdo.145.1430164419089; Mon, 27 Apr 2015 12:53:39 -0700 (PDT) Received: from ?IPv6:2406:e007:45a6:1:28cc:dc4c:9703:6781? ([2406:e007:45a6:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id cy5sm20224516pdb.85.2015.04.27.12.53.34 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Apr 2015 12:53:37 -0700 (PDT) Message-ID: <553E93B9.8050501@gmail.com> Date: Tue, 28 Apr 2015 07:53:29 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Sheng Jiang , "Michael Behringer (mbehring)" , "Liubing (Leo)" , Anima WG References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22F62DBD@xmb-rcd-x14.cisco.com> <55395DF3.3000702@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F63344@xmb-rcd-x14.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F457CEEBFF1@nkgeml506-mbx.china.huawei.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F634DE@xmb-rcd-x14.cisco.com> <553AA242.2040908@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F505C6E@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B925F505C6E@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Addressing: Consensus on Separate Addressing Realms?-//RE: Addressing: Do we need link addressing? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 19:53:42 -0000 On 27/04/2015 20:29, Sheng Jiang wrote: > Hi, Bing & Brian, > > Firstly, I have to point out that ASAs are functions. They do NOT have addresses. What we are discussing is the communication channels and their correspondent addresses that ASAs use to exchange controlling messages. > > Then, I agree the controlling message exchanging should go through the ACP which has separate addressing realm. In the case that ACP is not available or not chosen, the controlling message exchanging should be done with necessary security mechanism. Whether it uses ULAs or other data plane addresses, I don't see much different. Unless the network uses different mechanism to build up routing for ULA, then, ULA may be used as backup communication way when data plane crashed. However, without the analysis on the specific mechanism that used to build up routing for ULA, I don't think using ULA itself is any more reliable than other communication in the normal data plane. There is one difference - if the network gets disconnected from the Internet, and is reconnected later with a different prefix, the ULA communication will not be affected. That could affect small networks but not large enterprises. From every other aspect, I agree there is no difference. Regards Brian > > Best regards, > > Sheng > >> -----Original Message----- >> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E >> Carpenter >> Sent: Saturday, April 25, 2015 4:06 AM >> To: Michael Behringer (mbehring); Liubing (Leo); Anima WG >> Subject: Re: [Anima] Addressing: Consensus on Separate Addressing >> Realms?-//RE: Addressing: Do we need link addressing? >> >> On 25/04/2015 00:06, Michael Behringer (mbehring) wrote: >>>> -----Original Message----- >>>> From: Liubing (Leo) [mailto:leo.liubing@huawei.com] >>>> Sent: 24 April 2015 13:08 >>>> To: Michael Behringer (mbehring); Brian E Carpenter; Anima WG >>>> Subject: Addressing: Consensus on Separate Addressing Realms?-//RE: >>>> [Anima] Addressing: Do we need link addressing? >>>> >>>> Hi Michael, Brian, and all, >>>> >>>> Please allow me to fork this thread into another specific topic: do we need >>>> separated addressing realm for ASAs communication? >>>> I see we've already had some good discussion, so let's confirm whether we >>>> could reach consensus on this specific topic in this WG. >>>> >>>> Let me briefly summarize current discussion here (please correct me if I >>>> make something wrong): >>>> - Requirement: we need separate addressing realm for communication >>>> between Autonomic Service Agents. >>>> a) when there is ACP, since ACP uses separate addressing realm, the >> ASAs >>>> are also naturally in a separated addressing realm. >>>> b) when there is NO ACP: >>>> b-1: use the draft-behringer-anima-autonomic-addressing to number >> the >>>> autonomic nodes ULAs on loopback interfaces. >>>> b-2: use the same prefix ( the normal data plane prefix) for >> autonomic >>>> nodes. The ASAs communication is just in the normal data plane. >>>> >>>> From the separate addressing realm perspective, the b-2 should NOT be >> the >>>> choice. However, the b-2 could also be autonomic if >> [I.D.jiang-anima-prefix- >>>> management] applies. >>>> >>>> So please allow me confirm two questions: >>>> 1. Do we reach consensus on separate addressing realm for ASAs? >>>> 2. Do we also count b-2 option in or not? >>> >>> The discussion is just starting so I doubt we can call consensus at this point. >>> >>> I strongly favour a separate addressing scheme for ASAs, even in the case >> where there is no separation. >>> >>> Arguments in favour: >>> - consistent way of addressing autonomic nodes. As an ASA developer you >> know what you'll get. >>> - I would make this addressing scheme not configurable or modifyable. It's >> an autonomic process. --> stability >>> - Therefore: Address (mis-) configuration has little chance to interfere with >> the autonomic addressing. (Of course for true separation you still benefit >>from the ACP). >>> - and: It's cheap - I see no reason to *not* do it. >> >> I tend to agree with Michael B on this. There is the minor point that I >> just raised in response to Michael R: what if we have a specific use case >> that crosses the normal (enterprise-based) trust boundary? For that particular >> case, we might have to run an autonomic process in public address space. >> Of course, it would still need to be secured (e.g. with TLS). >> >> Brian >> >>> >>> Michael >>> >>>> Best regards, >>>> Bing >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael >>>>> Behringer (mbehring) >>>>> Sent: Friday, April 24, 2015 5:23 PM >>>>> To: Brian E Carpenter; Anima WG >>>>> Subject: Re: [Anima] Addressing: Do we need link addressing? >>>>> >>>>>>> I'd like to raise a question to the list for discussion: Do we >>>>>>> need to create >>>>>> autonomic link addressing? >>>>>>> >>>>>>> Here is my view: We need to distinguish about addressing done in >>>>>>> the >>>>>> Autonomic Networking Infrastructure, and addressing configured and >>>>>> managed by an operator. For the Autonomic Networking Infrastructure, >>>>>> which serves autonomic service agents, I do not think we need >>>>>> routable addresses on links, and suggest to use only link-local >>>>>> addressing. So the only addressing we should make routable are >>>>>> loopback addresses on >>>>> devices. >>>>>> >>>>>> Firstly, yes, we should clearly separate the addressing realm used >>>>>> by ASAs to communicate between themselves from the addressing >>>>>> realm(s) used by the user network. >>>>>> (I made that "realm(s)" because in the case of highly virtualized >>>>>> data centres etc., there might be many tenant addressing realms. And >>>>>> of course those addressing realms might well be administered by >>>>>> certain >>>>>> ASAs.) So here, we are talking about the addressing realm used by >>>>>> the ASAs to talk to each other. >>>>> >>>>> So far - we're in sync! :-) Absolutely agree on the realm(s) (Plural). >> Single >>>>> realm does not make sense these days. >>>>> >>>>>> But now we come to a branching point. Michael wants everybody to >>>>>> have a distinct ACP. I think that's a fine idea but I want to keep >>>>>> the option where there is no ACP, but the ASAs simply communicate >>>>>> using IP among themselves. In that mode there's nothing special >>>>>> about addressing; for example all ASAs could be numbered out of a >>>>>> specific ULA prefix, which would be the AN addressing realm, but >>>>>> they don't need to be routers. So in that mode, no, there is no >>>>>> restriction to link-local >>>>> addressing. >>>>> >>>>> We don't disagree actually ;-) While I see a number of real advantages >> of >>>>> the ACP, there may well be environments where the ACP isn't feasible >>>>> for one reason or another. Constrained devices could be one such case. >>>>> >>>>> So, assume that ASAs run in the data plane of the network, and NOT in >>>>> a separate ACP. I claim the fundamentals of the discussion apply here as >>>> well. >>>>> In particular: >>>>> >>>>> - we want a specific realm for the autonomic service agents, >>>>> independent of what an admin configures. So: ASA uses autonomically >>>>> set up addressing; "normal" configured processes use the configured >>>>> addressing. With IPv6 this shouldn't be an issue. This autonomic realm >>>>> shouldn't be configurable; it should just happen (just like in the >>>>> ACP). So the admin cannot mess up the addressing of the ASAs. He CAN >>>>> mess up routing if there's no separate ACP, but that's a choice we'll have >>>> to make. >>>>> >>>>> - It would be nice (although not mandatory) if the same addressing we >>>>> use inside the ACP would apply here too. >>>>> >>>>> - the link local discussion DOES apply also in the data plane, in my >>>>> opinion, and I would make the same claim that I made for the ACP: I >>>>> think the autonomic infrastructure shouldn't assign any routable link >>>>> addressing for the autonomic processes. (What the user does is >>>> independent of this). >>>>> >>>>> - Note: There may well be an ASA that assigns *user space* addressing, >>>>> to be used for the normal data plane, and Sheng's use case draft is an >>>>> example of one. This is perfectly legitimate. To re-state: We don't >>>>> want autonomically set up routable link addressing *for autonomic >>>> traffic*. >>>>> >>>>>> Back to Michael's model. I have a question. If ASA Alpha on a given >>>>>> link wants to communicate with ASA Beta on another link, what >>>>>> addresses are used? >>>>> >>>>> In my mind: The routable ULA addresses that we describe in >>>>> draft-behringer-anima-autonomic-addressing. ASAs communicate with >>>> the >>>>> loopback addresses of the nodes. >>>>> >>>>> Michael >>>>> >>>>> >>>>> _______________________________________________ >>>>> Anima mailing list >>>>> Anima@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/anima >>> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima From nobody Mon Apr 27 12:55:35 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 410C71A88D9 for ; Mon, 27 Apr 2015 12:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxvDc9yy7tKp for ; Mon, 27 Apr 2015 12:55:33 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 583321A8883 for ; Mon, 27 Apr 2015 12:55:33 -0700 (PDT) Received: by pacyx8 with SMTP id yx8so139990853pac.1 for ; Mon, 27 Apr 2015 12:55:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=f+rynNIJCk2RCI9NMdYC2SfWp9DqXr86Ta5BO9WV4So=; b=rOTh+fHSrqzcTQhAPpuS0GyIX95UqNI8KzNYVv7fqTXJ3WmHUEvU4Nk0y1KOSakh00 4F+sBxjpwOBmKWpBi0CwPQkGSkFoBaS5N7+8eMcEDQEzDfC8e0cPbS7nMfQgyIYPZ/KW PpQwSIqEbNEU26+K86JPGc+xvw+2LVJiafUEiXBArPe4ePp4ONmw1QahwkfxyBAwFFz5 454p2GwL0H0q8dWScrtDkFEAWEERHC+kR9uz9LMCjuADyCstFuEVxBvMV5FyR7EF4uN6 2Zg70MkCBXWqTbTWUYI+KneAiIjWKw3+Fucg4nbftPACgdqXxYuBUfyaLbHrDmMsfWCa 0mow== X-Received: by 10.68.166.132 with SMTP id zg4mr24930088pbb.5.1430164533104; Mon, 27 Apr 2015 12:55:33 -0700 (PDT) Received: from ?IPv6:2406:e007:45a6:1:28cc:dc4c:9703:6781? ([2406:e007:45a6:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id z5sm20143685pbt.54.2015.04.27.12.55.28 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Apr 2015 12:55:32 -0700 (PDT) Message-ID: <553E9430.8080903@gmail.com> Date: Tue, 28 Apr 2015 07:55:28 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: =?UTF-8?B?SsOpZmVyc29uIENhbXBvcyBOb2JyZQ==?= , Sheng Jiang References: <5D36713D8A4E7348A7E10DF7437A4B925F505D45@nkgeml512-mbx.china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Toerless Eckert , Anima WG , "Liubing \(Leo\)" , "anima-chairs@tools.ietf.org" Subject: Re: [Anima] Call for Volunteer - ANIMA signaling design team X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 19:55:35 -0000 On 28/04/2015 06:15, J=C3=A9ferson Campos Nobre wrote: > Dear Chairs. > I volunteer for the signaling design team. > As a side note, I was not able to join the anima-signaling mailing > list via the URL provided in the wiki. Yes, it looks like the list hasn't been created yet, one of the WG chairs= is taking care of that. Brian > Cheers. >=20 > J=C3=A9ferson Campos Nobre > PhD Student > Computer Networks Group - Institute of Informatics > Federal University of Rio Grande do Sul > http://www.inf.ufrgs.br/~jcnobre >=20 > On Mon, Apr 27, 2015 at 7:02 AM, Sheng Jiang wr= ote: >> Hi, all, >> >> We are calling for volunteers to form a design time for ANIMA signalin= g design team. The chairs has assigned two editors (Brian Carpenter and B= ing Liu), we are expecting up to 4 main contributors. The charter, initia= l goal and target date for the signaling design team is introduced below.= It also available in the design team wiki page. >> >> http://trac.tools.ietf.org/wg/anima/trac/wiki/Signaling >> >> Because of the intended design team work, we expect that the design te= am members would need to spend at least half a day per week on this proje= ct for maybe 4..6 month, but it should become less afterwards. We would l= ike to limit the design team to one year (or shorter if the goals are rea= ched faster of course). >> >> As WG chairs we will participate and help of course in the design team= primarily for logistics. In principle, the design team discussions shoul= d be open for all ANIMA participators. People who is interested, but do n= ot have enough time to commit, could also be able to participate and make= contributions or comments. >> >> This call is last for one week. It ends May 3rd, Sunday. Please reply = before it if you are interested in the commitment. >> >> Charter for the signaling design team >> >> The Anima WG charter states a requirement for discovery and negotiatio= n mechanisms to enable closed-loop interaction between autonomic nodes. I= t also states the goal of developing one or more protocol specifications = (or extensions to existing protocols) to achieve these goals. There is an= existing draft requirements analysis, whose main points include >> >> - support for any type of network objective parameter; >> - discovery must support any topology and bootstrap scenario; >> - synchronize parameters with other nodes individually or by floodi= ng; >> - negotiate parameters with other nodes; >> - always secure. >> >> A simple TLV format is proposed for the protocol design. Binary or nam= e-based discovery are proposed as alternative discovery approaches. >> >> The purpose of the design team is to analyze these issues and recommen= d a combined approach to the working group, preferably in the form of one= draft or a small set of coordinated drafts. The proposed approach should= be suitable for use by the Autonomic Control Plane, and for other use ca= ses including those listed in the Anima WG charter. >> >> In preparing the recommendation, the design team will verify and updat= e the existing requirements and understand the relevant use cases. Howeve= r, documenting and solving use cases is out of scope for the design team.= The design team is encouraged to develop protocol walkthroughs and an ab= stract API as aids to understanding. The design team is not itself expect= ed to produce code, but ease of implementation is an important considerat= ion. >> >> The draft(s) should be delivered by the July 2015 IETF (2015-07-06 cut= off date). >> >> Initial Goals >> >> - Validate and update the existing list of requirements (http://too= ls.ietf.org/html/draft-carpenter-anima-gdn-protocol#section-2) against bo= otstrap and ACP drafts (and optionally against other use case validation = drafts). Target date: end May. >> - Recommend how the other milestone components of ANIMA (bootstrap,= ACP, validation drafts) should use the signaling protocol(s). As a side-= effect, critique the proposal on the table (https://tools.ietf.org/html/d= raft-carpenter-anima-gdn-protocol#section-3). >> >> Target date: mid June. >> >> Best regards, >> >> Toerless + Sheng >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 From nobody Mon Apr 27 14:23:07 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABD191A8A4E for ; Mon, 27 Apr 2015 14:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhghccAkBmjD for ; Mon, 27 Apr 2015 14:23:04 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CEA91A8977 for ; Mon, 27 Apr 2015 14:23:04 -0700 (PDT) Received: from [172.16.125.17] ([212.156.144.66]) by mrelay.perfora.net (mreueus002) with ESMTPA (Nemesis) id 0Lw0KJ-1ZNKRc1lDZ-017lqP; Mon, 27 Apr 2015 23:22:46 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_BABCFCF9-29FE-465A-B47A-4924AEEF93EB" From: Alper Yegin In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B925F505D45@nkgeml512-mbx.china.huawei.com> Date: Tue, 28 Apr 2015 00:22:38 +0300 Message-Id: References: <5D36713D8A4E7348A7E10DF7437A4B925F505D45@nkgeml512-mbx.china.huawei.com> To: Sheng Jiang X-Mailer: Apple Mail (2.1283) X-Provags-ID: V03:K0:jMHFuKjRoffRKHShtp2IvsPdS4AzjYXOfZu9oDqcWZRPUSFQ7Sa YYWIYwawFR9DoJ/kMsOCWowm2XezKPm1Yi3IQktdL7dEvJtC/KffzrMQqP4gUkUO/b8NHeP OjF2YGvTjj9+ocYl/ztMN9UsujfPUmvmsN9bCwC2G5qw0cIlVFRA+/so7cO3J66m64HnEOc Tbbs+IeMWzMPRmUYicw4w== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: Toerless Eckert , "Liubing \(Leo\)" , Anima WG , "anima-chairs@tools.ietf.org" Subject: Re: [Anima] Call for Volunteer - ANIMA signaling design team X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 21:23:06 -0000 --Apple-Mail=_BABCFCF9-29FE-465A-B47A-4924AEEF93EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Sheng, IETF 92 proceedings had stated: Would like to start building design teams for a) bootstrap=20 and b) signaling, which are milestone building blocks. So, what you've announced is one of the two design teams to be created, = right? Alper On Apr 27, 2015, at 1:02 PM, Sheng Jiang wrote: > Hi, all, >=20 > We are calling for volunteers to form a design time for ANIMA = signaling design team. The chairs has assigned two editors (Brian = Carpenter and Bing Liu), we are expecting up to 4 main contributors. The = charter, initial goal and target date for the signaling design team is = introduced below. It also available in the design team wiki page. >=20 > http://trac.tools.ietf.org/wg/anima/trac/wiki/Signaling >=20 > Because of the intended design team work, we expect that the design = team members would need to spend at least half a day per week on this = project for maybe 4..6 month, but it should become less afterwards. We = would like to limit the design team to one year (or shorter if the goals = are reached faster of course). >=20 > As WG chairs we will participate and help of course in the design team = primarily for logistics. In principle, the design team discussions = should be open for all ANIMA participators. People who is interested, = but do not have enough time to commit, could also be able to participate = and make contributions or comments. >=20 > This call is last for one week. It ends May 3rd, Sunday. Please reply = before it if you are interested in the commitment. >=20 > Charter for the signaling design team >=20 > The Anima WG charter states a requirement for discovery and = negotiation mechanisms to enable closed-loop interaction between = autonomic nodes. It also states the goal of developing one or more = protocol specifications (or extensions to existing protocols) to achieve = these goals. There is an existing draft requirements analysis, whose = main points include >=20 > - support for any type of network objective parameter; > - discovery must support any topology and bootstrap scenario; > - synchronize parameters with other nodes individually or by = flooding; > - negotiate parameters with other nodes; > - always secure. >=20 > A simple TLV format is proposed for the protocol design. Binary or = name-based discovery are proposed as alternative discovery approaches. >=20 > The purpose of the design team is to analyze these issues and = recommend a combined approach to the working group, preferably in the = form of one draft or a small set of coordinated drafts. The proposed = approach should be suitable for use by the Autonomic Control Plane, and = for other use cases including those listed in the Anima WG charter. >=20 > In preparing the recommendation, the design team will verify and = update the existing requirements and understand the relevant use cases. = However, documenting and solving use cases is out of scope for the = design team. The design team is encouraged to develop protocol = walkthroughs and an abstract API as aids to understanding. The design = team is not itself expected to produce code, but ease of implementation = is an important consideration. >=20 > The draft(s) should be delivered by the July 2015 IETF (2015-07-06 = cutoff date). >=20 > Initial Goals >=20 > - Validate and update the existing list of requirements = (=E2=80=8Bhttp://tools.ietf.org/html/draft-carpenter-anima-gdn-protocol#se= ction-2) against bootstrap and ACP drafts (and optionally against other = use case validation drafts). Target date: end May. > - Recommend how the other milestone components of ANIMA (bootstrap, = ACP, validation drafts) should use the signaling protocol(s). As a = side-effect, critique the proposal on the table = (=E2=80=8Bhttps://tools.ietf.org/html/draft-carpenter-anima-gdn-protocol#s= ection-3). >=20 > Target date: mid June. >=20 > Best regards, >=20 > Toerless + Sheng > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima --Apple-Mail=_BABCFCF9-29FE-465A-B47A-4924AEEF93EB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello = Sheng,

IETF 92 proceedings had = stated:

Would like to start building design teams for a) bootstrap=20=

      and b) signaling, which are milestone building =
blocks.

So, what you've announced = is one of the two design teams to be created, = right?


Alper



On Apr 27, 2015, at 1:02 PM, = Sheng Jiang wrote:

Hi, = all,

We are calling for volunteers to form a design time for = ANIMA signaling design team. The chairs has assigned two editors (Brian = Carpenter and Bing Liu), we are expecting up to 4 main contributors. The = charter, initial goal and target date for the signaling design team is = introduced below. It also available in the design team wiki = page.

http://tr= ac.tools.ietf.org/wg/anima/trac/wiki/Signaling

Because of the = intended design team work, we expect that the design team members would = need to spend at least half a day per week on this project for maybe = 4..6 month, but it should become less afterwards. We would like to limit = the design team to one year (or shorter if the goals are reached faster = of course).

As WG chairs we will participate and help of course = in the design team primarily for logistics. In principle, the design = team discussions should be open for all ANIMA participators. People who = is interested, but do not have enough time to commit, could also be able = to participate and make contributions or comments.

This call is = last for one week. It ends May 3rd, Sunday. Please reply before it if = you are interested in the commitment.

Charter for the signaling = design team

The Anima WG charter states a requirement for = discovery and negotiation mechanisms to enable closed-loop interaction = between autonomic nodes. It also states the goal of developing one or = more protocol specifications (or extensions to existing protocols) to = achieve these goals. There is an existing draft requirements analysis, = whose main points include

  - support for any type of = network objective parameter;
  - discovery must support = any topology and bootstrap scenario;
  - synchronize = parameters with other nodes individually or by flooding;
=   - negotiate parameters with other nodes;
  - = always secure.

A simple TLV format is proposed for the protocol = design. Binary or name-based discovery are proposed as alternative = discovery approaches.

The purpose of the design team is to = analyze these issues and recommend a combined approach to the working = group, preferably in the form of one draft or a small set of coordinated = drafts. The proposed approach should be suitable for use by the = Autonomic Control Plane, and for other use cases including those listed = in the Anima WG charter.

In preparing the recommendation, the = design team will verify and update the existing requirements and = understand the relevant use cases. However, documenting and solving use = cases is out of scope for the design team. The design team is encouraged = to develop protocol walkthroughs and an abstract API as aids to = understanding. The design team is not itself expected to produce code, = but ease of implementation is an important consideration.

The = draft(s) should be delivered by the July 2015 IETF (2015-07-06 cutoff = date).

Initial Goals

  - Validate and update = the existing list of requirements = (=E2=80=8Bhttp://tools.ietf.org/html/draft-carpenter-anima-gdn-protocol#se= ction-2) against bootstrap and ACP drafts (and optionally against other = use case validation drafts). Target date: end May.
  - = Recommend how the other milestone components of ANIMA (bootstrap, ACP, = validation drafts) should use the signaling protocol(s). As a = side-effect, critique the proposal on the table = (=E2=80=8Bhttps://tools.ietf.org/html/draft-carpenter-anima-gdn-protocol#s= ection-3).

Target date: mid June.

Best = regards,

Toerless + = Sheng
_______________________________________________
Anima = mailing = list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
<= /div>

= --Apple-Mail=_BABCFCF9-29FE-465A-B47A-4924AEEF93EB-- From nobody Mon Apr 27 17:51:55 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 829DA1ACDCF for ; Mon, 27 Apr 2015 17:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQpJVM5_bdgz for ; Mon, 27 Apr 2015 17:51:51 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 756671ACDD2 for ; Mon, 27 Apr 2015 17:51:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRX00476; Tue, 28 Apr 2015 00:51:48 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Apr 2015 01:51:47 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.135]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Tue, 28 Apr 2015 08:51:35 +0800 From: Sheng Jiang To: Brian E Carpenter , "Michael Behringer (mbehring)" , "Liubing (Leo)" , Anima WG Thread-Topic: [Anima] Addressing: Consensus on Separate Addressing Realms?-//RE: Addressing: Do we need link addressing? Thread-Index: AQHQfoIaPG+METjUfEG0Kfrci46A+J1biyOAgACGBgCABHT4kIAAPmiAgADYYwA= Date: Tue, 28 Apr 2015 00:51:34 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B925F50617C@nkgeml512-mbx.china.huawei.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22F62DBD@xmb-rcd-x14.cisco.com> <55395DF3.3000702@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F63344@xmb-rcd-x14.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F457CEEBFF1@nkgeml506-mbx.china.huawei.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F634DE@xmb-rcd-x14.cisco.com> <553AA242.2040908@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F505C6E@nkgeml512-mbx.china.huawei.com> <553E93B9.8050501@gmail.com> In-Reply-To: <553E93B9.8050501@gmail.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.197] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] Addressing: Consensus on Separate Addressing Realms?-//RE: Addressing: Do we need link addressing? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 00:51:54 -0000 Pj4gRmlyc3RseSwgSSBoYXZlIHRvIHBvaW50IG91dCB0aGF0IEFTQXMgYXJlIGZ1bmN0aW9ucy4g VGhleSBkbyBOT1QgaGF2ZQ0KPmFkZHJlc3Nlcy4gV2hhdCB3ZSBhcmUgZGlzY3Vzc2luZyBpcyB0 aGUgY29tbXVuaWNhdGlvbiBjaGFubmVscyBhbmQgdGhlaXINCj5jb3JyZXNwb25kZW50IGFkZHJl c3NlcyB0aGF0IEFTQXMgdXNlIHRvIGV4Y2hhbmdlIGNvbnRyb2xsaW5nIG1lc3NhZ2VzLg0KPj4N Cj4+IFRoZW4sIEkgYWdyZWUgdGhlIGNvbnRyb2xsaW5nIG1lc3NhZ2UgZXhjaGFuZ2luZyBzaG91 bGQgZ28gdGhyb3VnaCB0aGUNCj5BQ1Agd2hpY2ggaGFzIHNlcGFyYXRlIGFkZHJlc3NpbmcgcmVh bG0uIEluIHRoZSBjYXNlIHRoYXQgQUNQIGlzIG5vdCBhdmFpbGFibGUNCj5vciBub3QgY2hvc2Vu LCB0aGUgY29udHJvbGxpbmcgbWVzc2FnZSBleGNoYW5naW5nIHNob3VsZCBiZSBkb25lIHdpdGgN Cj5uZWNlc3Nhcnkgc2VjdXJpdHkgbWVjaGFuaXNtLiBXaGV0aGVyIGl0IHVzZXMgVUxBcyBvciBv dGhlciBkYXRhIHBsYW5lDQo+YWRkcmVzc2VzLCBJIGRvbid0IHNlZSBtdWNoIGRpZmZlcmVudC4g VW5sZXNzIHRoZSBuZXR3b3JrIHVzZXMgZGlmZmVyZW50DQo+bWVjaGFuaXNtIHRvIGJ1aWxkIHVw IHJvdXRpbmcgZm9yIFVMQSwgdGhlbiwgVUxBIG1heSBiZSB1c2VkIGFzIGJhY2t1cA0KPmNvbW11 bmljYXRpb24gd2F5IHdoZW4gZGF0YSBwbGFuZSBjcmFzaGVkLiBIb3dldmVyLCB3aXRob3V0IHRo ZSBhbmFseXNpcw0KPm9uIHRoZSBzcGVjaWZpYyBtZWNoYW5pc20gdGhhdCB1c2VkIHRvIGJ1aWxk IHVwIHJvdXRpbmcgZm9yIFVMQSwgSSBkb24ndCB0aGluaw0KPnVzaW5nIFVMQSBpdHNlbGYgaXMg YW55IG1vcmUgcmVsaWFibGUgdGhhbiBvdGhlciBjb21tdW5pY2F0aW9uIGluIHRoZSBub3JtYWwN Cj5kYXRhIHBsYW5lLg0KPg0KPlRoZXJlIGlzIG9uZSBkaWZmZXJlbmNlIC0gaWYgdGhlIG5ldHdv cmsgZ2V0cyBkaXNjb25uZWN0ZWQgZnJvbSB0aGUgSW50ZXJuZXQsDQo+YW5kIGlzIHJlY29ubmVj dGVkIGxhdGVyIHdpdGggYSBkaWZmZXJlbnQgcHJlZml4LCB0aGUgVUxBIGNvbW11bmljYXRpb24g d2lsbA0KPm5vdA0KPmJlIGFmZmVjdGVkLiBUaGF0IGNvdWxkIGFmZmVjdCBzbWFsbCBuZXR3b3Jr cyBidXQgbm90IGxhcmdlIGVudGVycHJpc2VzLiBGcm9tDQo+ZXZlcnkgb3RoZXIgYXNwZWN0LCBJ IGFncmVlIHRoZXJlIGlzIG5vIGRpZmZlcmVuY2UuDQoNClNvLCBhcmUgeW91IHRhbGtpbmcgYWJv dXQgdXNpbmcgVUxBIGFkZHJlc3MgYXMgdGhlIGRldmljZSBpZGVudGlmaWVyPyBJZiBzbywgbWF5 IGJlIHllcywgSSBhbSBub3Qgc3VyZS4gV2UgYXJlIG5vdCBleHBsb3JlIHRoZSBkZXZpY2UgaWRl bnRpZmllciB5ZXQuIFNvIGZhciwgZnJvbSB0aGUgcmVhY2hhYmlsaXR5IHBlcnNwZWN0aXZlLCBV TEEgZG9lcyBub3QgbWFrZSBtdWNoIGRpZmZlcmVudCBhcyBpdCBhbHNvIGdvZXMgdGhyb3VnaCB0 aGUgbm9ybWFsIGRhdGEgcGxhbmUuDQoNClJlZ2FyZHMsDQoNClNoZW5nDQoNCj5SZWdhcmRzDQo+ ICBCcmlhbg0KPg0KPj4NCj4+IEJlc3QgcmVnYXJkcywNCj4+DQo+PiBTaGVuZw0KPj4NCj4+PiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+IEZyb206IEFuaW1hIFttYWlsdG86YW5pbWEt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJyaWFuIEUNCj4+PiBDYXJwZW50ZXINCj4+ PiBTZW50OiBTYXR1cmRheSwgQXByaWwgMjUsIDIwMTUgNDowNiBBTQ0KPj4+IFRvOiBNaWNoYWVs IEJlaHJpbmdlciAobWJlaHJpbmcpOyBMaXViaW5nIChMZW8pOyBBbmltYSBXRw0KPj4+IFN1Ympl Y3Q6IFJlOiBbQW5pbWFdIEFkZHJlc3Npbmc6IENvbnNlbnN1cyBvbiBTZXBhcmF0ZSBBZGRyZXNz aW5nDQo+Pj4gUmVhbG1zPy0vL1JFOiBBZGRyZXNzaW5nOiBEbyB3ZSBuZWVkIGxpbmsgYWRkcmVz c2luZz8NCj4+Pg0KPj4+IE9uIDI1LzA0LzIwMTUgMDA6MDYsIE1pY2hhZWwgQmVocmluZ2VyICht YmVocmluZykgd3JvdGU6DQo+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4g RnJvbTogTGl1YmluZyAoTGVvKSBbbWFpbHRvOmxlby5saXViaW5nQGh1YXdlaS5jb21dDQo+Pj4+ PiBTZW50OiAyNCBBcHJpbCAyMDE1IDEzOjA4DQo+Pj4+PiBUbzogTWljaGFlbCBCZWhyaW5nZXIg KG1iZWhyaW5nKTsgQnJpYW4gRSBDYXJwZW50ZXI7IEFuaW1hIFdHDQo+Pj4+PiBTdWJqZWN0OiBB ZGRyZXNzaW5nOiBDb25zZW5zdXMgb24gU2VwYXJhdGUgQWRkcmVzc2luZyBSZWFsbXM/LS8vUkU6 DQo+Pj4+PiBbQW5pbWFdIEFkZHJlc3Npbmc6IERvIHdlIG5lZWQgbGluayBhZGRyZXNzaW5nPw0K Pj4+Pj4NCj4+Pj4+IEhpIE1pY2hhZWwsIEJyaWFuLCBhbmQgYWxsLA0KPj4+Pj4NCj4+Pj4+IFBs ZWFzZSBhbGxvdyBtZSB0byBmb3JrIHRoaXMgdGhyZWFkIGludG8gYW5vdGhlciBzcGVjaWZpYyB0 b3BpYzogZG8gd2UNCj5uZWVkDQo+Pj4+PiBzZXBhcmF0ZWQgYWRkcmVzc2luZyByZWFsbSBmb3Ig QVNBcyBjb21tdW5pY2F0aW9uPw0KPj4+Pj4gSSBzZWUgd2UndmUgYWxyZWFkeSBoYWQgc29tZSBn b29kIGRpc2N1c3Npb24sIHNvIGxldCdzIGNvbmZpcm0gd2hldGhlcg0KPndlDQo+Pj4+PiBjb3Vs ZCByZWFjaCBjb25zZW5zdXMgb24gdGhpcyBzcGVjaWZpYyB0b3BpYyBpbiB0aGlzIFdHLg0KPj4+ Pj4NCj4+Pj4+IExldCBtZSBicmllZmx5IHN1bW1hcml6ZSBjdXJyZW50IGRpc2N1c3Npb24gaGVy ZSAocGxlYXNlIGNvcnJlY3QgbWUgaWYgSQ0KPj4+Pj4gbWFrZSBzb21ldGhpbmcgd3JvbmcpOg0K Pj4+Pj4gLSBSZXF1aXJlbWVudDogd2UgbmVlZCBzZXBhcmF0ZSBhZGRyZXNzaW5nIHJlYWxtIGZv ciBjb21tdW5pY2F0aW9uDQo+Pj4+PiBiZXR3ZWVuIEF1dG9ub21pYyBTZXJ2aWNlIEFnZW50cy4N Cj4+Pj4+ICAgYSkgd2hlbiB0aGVyZSBpcyBBQ1AsIHNpbmNlIEFDUCB1c2VzIHNlcGFyYXRlIGFk ZHJlc3NpbmcgcmVhbG0sIHRoZQ0KPj4+IEFTQXMNCj4+Pj4+IGFyZSBhbHNvIG5hdHVyYWxseSBp biBhIHNlcGFyYXRlZCBhZGRyZXNzaW5nIHJlYWxtLg0KPj4+Pj4gICBiKSB3aGVuIHRoZXJlIGlz IE5PIEFDUDoNCj4+Pj4+ICAgICBiLTE6IHVzZSB0aGUgZHJhZnQtYmVocmluZ2VyLWFuaW1hLWF1 dG9ub21pYy1hZGRyZXNzaW5nIHRvDQo+bnVtYmVyDQo+Pj4gdGhlDQo+Pj4+PiBhdXRvbm9taWMg bm9kZXMgVUxBcyBvbiBsb29wYmFjayBpbnRlcmZhY2VzLg0KPj4+Pj4gICAgIGItMjogdXNlIHRo ZSBzYW1lIHByZWZpeCAoIHRoZSBub3JtYWwgZGF0YSBwbGFuZSBwcmVmaXgpIGZvcg0KPj4+IGF1 dG9ub21pYw0KPj4+Pj4gbm9kZXMuIFRoZSBBU0FzIGNvbW11bmljYXRpb24gaXMganVzdCBpbiB0 aGUgbm9ybWFsIGRhdGEgcGxhbmUuDQo+Pj4+Pg0KPj4+Pj4gRnJvbSB0aGUgc2VwYXJhdGUgYWRk cmVzc2luZyByZWFsbSBwZXJzcGVjdGl2ZSwgdGhlIGItMiBzaG91bGQgTk9UIGJlDQo+Pj4gdGhl DQo+Pj4+PiBjaG9pY2UuIEhvd2V2ZXIsIHRoZSBiLTIgY291bGQgYWxzbyBiZSBhdXRvbm9taWMg aWYNCj4+PiBbSS5ELmppYW5nLWFuaW1hLXByZWZpeC0NCj4+Pj4+IG1hbmFnZW1lbnRdIGFwcGxp ZXMuDQo+Pj4+Pg0KPj4+Pj4gU28gcGxlYXNlIGFsbG93IG1lIGNvbmZpcm0gdHdvIHF1ZXN0aW9u czoNCj4+Pj4+IDEuIERvIHdlIHJlYWNoIGNvbnNlbnN1cyBvbiBzZXBhcmF0ZSBhZGRyZXNzaW5n IHJlYWxtIGZvciBBU0FzPw0KPj4+Pj4gMi4gRG8gd2UgYWxzbyBjb3VudCBiLTIgb3B0aW9uIGlu IG9yIG5vdD8NCj4+Pj4NCj4+Pj4gVGhlIGRpc2N1c3Npb24gaXMganVzdCBzdGFydGluZyBzbyBJ IGRvdWJ0IHdlIGNhbiBjYWxsIGNvbnNlbnN1cyBhdCB0aGlzDQo+cG9pbnQuDQo+Pj4+DQo+Pj4+ IEkgc3Ryb25nbHkgZmF2b3VyIGEgc2VwYXJhdGUgYWRkcmVzc2luZyBzY2hlbWUgZm9yIEFTQXMs IGV2ZW4gaW4gdGhlIGNhc2UNCj4+PiB3aGVyZSB0aGVyZSBpcyBubyBzZXBhcmF0aW9uLg0KPj4+ Pg0KPj4+PiBBcmd1bWVudHMgaW4gZmF2b3VyOg0KPj4+PiAtIGNvbnNpc3RlbnQgd2F5IG9mIGFk ZHJlc3NpbmcgYXV0b25vbWljIG5vZGVzLiBBcyBhbiBBU0EgZGV2ZWxvcGVyDQo+eW91DQo+Pj4g a25vdyB3aGF0IHlvdSdsbCBnZXQuDQo+Pj4+IC0gSSB3b3VsZCBtYWtlIHRoaXMgYWRkcmVzc2lu ZyBzY2hlbWUgbm90IGNvbmZpZ3VyYWJsZSBvciBtb2RpZnlhYmxlLg0KPkl0J3MNCj4+PiBhbiBh dXRvbm9taWMgcHJvY2Vzcy4gLS0+IHN0YWJpbGl0eQ0KPj4+PiAtIFRoZXJlZm9yZTogQWRkcmVz cyAobWlzLSkgY29uZmlndXJhdGlvbiBoYXMgbGl0dGxlIGNoYW5jZSB0byBpbnRlcmZlcmUNCj53 aXRoDQo+Pj4gdGhlIGF1dG9ub21pYyBhZGRyZXNzaW5nLiAoT2YgY291cnNlIGZvciB0cnVlIHNl cGFyYXRpb24geW91IHN0aWxsIGJlbmVmaXQNCj4+PmZyb20gdGhlIEFDUCkuDQo+Pj4+IC0gYW5k OiBJdCdzIGNoZWFwIC0gSSBzZWUgbm8gcmVhc29uIHRvICpub3QqIGRvIGl0Lg0KPj4+DQo+Pj4g SSB0ZW5kIHRvIGFncmVlIHdpdGggTWljaGFlbCBCIG9uIHRoaXMuIFRoZXJlIGlzIHRoZSBtaW5v ciBwb2ludCB0aGF0IEkNCj4+PiBqdXN0IHJhaXNlZCBpbiByZXNwb25zZSB0byBNaWNoYWVsIFI6 IHdoYXQgaWYgd2UgaGF2ZSBhIHNwZWNpZmljIHVzZSBjYXNlDQo+Pj4gdGhhdCBjcm9zc2VzIHRo ZSBub3JtYWwgKGVudGVycHJpc2UtYmFzZWQpIHRydXN0IGJvdW5kYXJ5PyBGb3IgdGhhdA0KPnBh cnRpY3VsYXINCj4+PiBjYXNlLCB3ZSBtaWdodCBoYXZlIHRvIHJ1biBhbiBhdXRvbm9taWMgcHJv Y2VzcyBpbiBwdWJsaWMgYWRkcmVzcyBzcGFjZS4NCj4+PiBPZiBjb3Vyc2UsIGl0IHdvdWxkIHN0 aWxsIG5lZWQgdG8gYmUgc2VjdXJlZCAoZS5nLiB3aXRoIFRMUykuDQo+Pj4NCj4+PiAgIEJyaWFu DQo+Pj4NCj4+Pj4NCj4+Pj4gTWljaGFlbA0KPj4+Pg0KPj4+Pj4gQmVzdCByZWdhcmRzLA0KPj4+ Pj4gQmluZw0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+Pj4+Pj4gRnJvbTogQW5pbWEgW21haWx0bzphbmltYS1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgTWljaGFlbA0KPj4+Pj4+IEJlaHJpbmdlciAobWJlaHJpbmcpDQo+Pj4+ Pj4gU2VudDogRnJpZGF5LCBBcHJpbCAyNCwgMjAxNSA1OjIzIFBNDQo+Pj4+Pj4gVG86IEJyaWFu IEUgQ2FycGVudGVyOyBBbmltYSBXRw0KPj4+Pj4+IFN1YmplY3Q6IFJlOiBbQW5pbWFdIEFkZHJl c3Npbmc6IERvIHdlIG5lZWQgbGluayBhZGRyZXNzaW5nPw0KPj4+Pj4+DQo+Pj4+Pj4+PiBJJ2Qg bGlrZSB0byByYWlzZSBhIHF1ZXN0aW9uIHRvIHRoZSBsaXN0IGZvciBkaXNjdXNzaW9uOiBEbyB3 ZQ0KPj4+Pj4+Pj4gbmVlZCB0byBjcmVhdGUNCj4+Pj4+Pj4gYXV0b25vbWljIGxpbmsgYWRkcmVz c2luZz8NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBIZXJlIGlzIG15IHZpZXc6IFdlIG5lZWQgdG8gZGlz dGluZ3Vpc2ggYWJvdXQgYWRkcmVzc2luZyBkb25lIGluDQo+Pj4+Pj4+PiB0aGUNCj4+Pj4+Pj4g QXV0b25vbWljIE5ldHdvcmtpbmcgSW5mcmFzdHJ1Y3R1cmUsIGFuZCBhZGRyZXNzaW5nIGNvbmZp Z3VyZWQgYW5kDQo+Pj4+Pj4+IG1hbmFnZWQgYnkgYW4gb3BlcmF0b3IuIEZvciB0aGUgQXV0b25v bWljIE5ldHdvcmtpbmcNCj5JbmZyYXN0cnVjdHVyZSwNCj4+Pj4+Pj4gd2hpY2ggc2VydmVzIGF1 dG9ub21pYyBzZXJ2aWNlIGFnZW50cywgSSBkbyBub3QgdGhpbmsgd2UgbmVlZA0KPj4+Pj4+PiBy b3V0YWJsZSBhZGRyZXNzZXMgb24gbGlua3MsIGFuZCBzdWdnZXN0IHRvIHVzZSBvbmx5IGxpbmst bG9jYWwNCj4+Pj4+Pj4gYWRkcmVzc2luZy4gU28gdGhlIG9ubHkgYWRkcmVzc2luZyB3ZSBzaG91 bGQgbWFrZSByb3V0YWJsZSBhcmUNCj4+Pj4+Pj4gbG9vcGJhY2sgYWRkcmVzc2VzIG9uDQo+Pj4+ Pj4gZGV2aWNlcy4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gRmlyc3RseSwgeWVzLCB3ZSBzaG91bGQgY2xl YXJseSBzZXBhcmF0ZSB0aGUgYWRkcmVzc2luZyByZWFsbSB1c2VkDQo+Pj4+Pj4+IGJ5IEFTQXMg dG8gY29tbXVuaWNhdGUgYmV0d2VlbiB0aGVtc2VsdmVzIGZyb20gdGhlIGFkZHJlc3NpbmcNCj4+ Pj4+Pj4gcmVhbG0ocykgdXNlZCBieSB0aGUgdXNlciBuZXR3b3JrLg0KPj4+Pj4+PiAoSSBtYWRl IHRoYXQgInJlYWxtKHMpIiBiZWNhdXNlIGluIHRoZSBjYXNlIG9mIGhpZ2hseSB2aXJ0dWFsaXpl ZA0KPj4+Pj4+PiBkYXRhIGNlbnRyZXMgZXRjLiwgdGhlcmUgbWlnaHQgYmUgbWFueSB0ZW5hbnQg YWRkcmVzc2luZyByZWFsbXMuIEFuZA0KPj4+Pj4+PiBvZiBjb3Vyc2UgdGhvc2UgYWRkcmVzc2lu ZyByZWFsbXMgbWlnaHQgd2VsbCBiZSBhZG1pbmlzdGVyZWQgYnkNCj4+Pj4+Pj4gY2VydGFpbg0K Pj4+Pj4+PiBBU0FzLikgU28gaGVyZSwgd2UgYXJlIHRhbGtpbmcgYWJvdXQgdGhlIGFkZHJlc3Np bmcgcmVhbG0gdXNlZCBieQ0KPj4+Pj4+PiB0aGUgQVNBcyB0byB0YWxrIHRvIGVhY2ggb3RoZXIu DQo+Pj4+Pj4NCj4+Pj4+PiBTbyBmYXIgLSB3ZSdyZSBpbiBzeW5jISA6LSkgICBBYnNvbHV0ZWx5 IGFncmVlIG9uIHRoZSByZWFsbShzKSAoUGx1cmFsKS4NCj4+PiBTaW5nbGUNCj4+Pj4+PiByZWFs bSBkb2VzIG5vdCBtYWtlIHNlbnNlIHRoZXNlIGRheXMuDQo+Pj4+Pj4NCj4+Pj4+Pj4gQnV0IG5v dyB3ZSBjb21lIHRvIGEgYnJhbmNoaW5nIHBvaW50LiBNaWNoYWVsIHdhbnRzIGV2ZXJ5Ym9keSB0 bw0KPj4+Pj4+PiBoYXZlIGEgZGlzdGluY3QgQUNQLiBJIHRoaW5rIHRoYXQncyBhIGZpbmUgaWRl YSBidXQgSSB3YW50IHRvIGtlZXANCj4+Pj4+Pj4gdGhlIG9wdGlvbiB3aGVyZSB0aGVyZSBpcyBu byBBQ1AsIGJ1dCB0aGUgQVNBcyBzaW1wbHkgY29tbXVuaWNhdGUNCj4+Pj4+Pj4gdXNpbmcgSVAg YW1vbmcgdGhlbXNlbHZlcy4gSW4gdGhhdCBtb2RlIHRoZXJlJ3Mgbm90aGluZyBzcGVjaWFsDQo+ Pj4+Pj4+IGFib3V0IGFkZHJlc3Npbmc7IGZvciBleGFtcGxlIGFsbCBBU0FzIGNvdWxkIGJlIG51 bWJlcmVkIG91dCBvZiBhDQo+Pj4+Pj4+IHNwZWNpZmljIFVMQSBwcmVmaXgsIHdoaWNoIHdvdWxk IGJlIHRoZSBBTiBhZGRyZXNzaW5nIHJlYWxtLCBidXQNCj4+Pj4+Pj4gdGhleSBkb24ndCBuZWVk IHRvIGJlIHJvdXRlcnMuIFNvIGluIHRoYXQgbW9kZSwgbm8sIHRoZXJlIGlzIG5vDQo+Pj4+Pj4+ IHJlc3RyaWN0aW9uIHRvIGxpbmstbG9jYWwNCj4+Pj4+PiBhZGRyZXNzaW5nLg0KPj4+Pj4+DQo+ Pj4+Pj4gV2UgZG9uJ3QgZGlzYWdyZWUgYWN0dWFsbHkgOy0pICAgV2hpbGUgSSBzZWUgYSBudW1i ZXIgb2YgcmVhbA0KPmFkdmFudGFnZXMNCj4+PiBvZg0KPj4+Pj4+IHRoZSBBQ1AsIHRoZXJlIG1h eSB3ZWxsIGJlIGVudmlyb25tZW50cyB3aGVyZSB0aGUgQUNQIGlzbid0IGZlYXNpYmxlDQo+Pj4+ Pj4gZm9yIG9uZSByZWFzb24gb3IgYW5vdGhlci4gQ29uc3RyYWluZWQgZGV2aWNlcyBjb3VsZCBi ZSBvbmUgc3VjaCBjYXNlLg0KPj4+Pj4+DQo+Pj4+Pj4gU28sIGFzc3VtZSB0aGF0IEFTQXMgcnVu IGluIHRoZSBkYXRhIHBsYW5lIG9mIHRoZSBuZXR3b3JrLCBhbmQgTk9UIGluDQo+Pj4+Pj4gYSBz ZXBhcmF0ZSBBQ1AuIEkgY2xhaW0gdGhlIGZ1bmRhbWVudGFscyBvZiB0aGUgZGlzY3Vzc2lvbiBh cHBseSBoZXJlDQo+YXMNCj4+Pj4+IHdlbGwuDQo+Pj4+Pj4gSW4gcGFydGljdWxhcjoNCj4+Pj4+ Pg0KPj4+Pj4+IC0gd2Ugd2FudCBhIHNwZWNpZmljIHJlYWxtIGZvciB0aGUgYXV0b25vbWljIHNl cnZpY2UgYWdlbnRzLA0KPj4+Pj4+IGluZGVwZW5kZW50IG9mIHdoYXQgYW4gYWRtaW4gY29uZmln dXJlcy4gIFNvOiBBU0EgdXNlcw0KPmF1dG9ub21pY2FsbHkNCj4+Pj4+PiBzZXQgdXAgYWRkcmVz c2luZzsgIm5vcm1hbCIgY29uZmlndXJlZCBwcm9jZXNzZXMgdXNlIHRoZSBjb25maWd1cmVkDQo+ Pj4+Pj4gYWRkcmVzc2luZy4gV2l0aCBJUHY2IHRoaXMgc2hvdWxkbid0IGJlIGFuIGlzc3VlLiBU aGlzIGF1dG9ub21pYyByZWFsbQ0KPj4+Pj4+IHNob3VsZG4ndCBiZSBjb25maWd1cmFibGU7IGl0 IHNob3VsZCBqdXN0IGhhcHBlbiAoanVzdCBsaWtlIGluIHRoZQ0KPj4+Pj4+IEFDUCkuIFNvIHRo ZSBhZG1pbiBjYW5ub3QgbWVzcyB1cCB0aGUgYWRkcmVzc2luZyBvZiB0aGUgQVNBcy4gSGUgQ0FO DQo+Pj4+Pj4gbWVzcyB1cCByb3V0aW5nIGlmIHRoZXJlJ3Mgbm8gc2VwYXJhdGUgQUNQLCBidXQg dGhhdCdzIGEgY2hvaWNlIHdlJ2xsDQo+aGF2ZQ0KPj4+Pj4gdG8gbWFrZS4NCj4+Pj4+Pg0KPj4+ Pj4+IC0gSXQgd291bGQgYmUgbmljZSAoYWx0aG91Z2ggbm90IG1hbmRhdG9yeSkgaWYgdGhlIHNh bWUgYWRkcmVzc2luZyB3ZQ0KPj4+Pj4+IHVzZSBpbnNpZGUgdGhlIEFDUCB3b3VsZCBhcHBseSBo ZXJlIHRvby4NCj4+Pj4+Pg0KPj4+Pj4+IC0gdGhlIGxpbmsgbG9jYWwgZGlzY3Vzc2lvbiBET0VT IGFwcGx5IGFsc28gaW4gdGhlIGRhdGEgcGxhbmUsIGluIG15DQo+Pj4+Pj4gb3BpbmlvbiwgYW5k IEkgd291bGQgbWFrZSB0aGUgc2FtZSBjbGFpbSB0aGF0IEkgbWFkZSBmb3IgdGhlIEFDUDogSQ0K Pj4+Pj4+IHRoaW5rIHRoZSBhdXRvbm9taWMgaW5mcmFzdHJ1Y3R1cmUgc2hvdWxkbid0IGFzc2ln biBhbnkgcm91dGFibGUgbGluaw0KPj4+Pj4+IGFkZHJlc3NpbmcgZm9yIHRoZSBhdXRvbm9taWMg cHJvY2Vzc2VzLiAoV2hhdCB0aGUgdXNlciBkb2VzIGlzDQo+Pj4+PiBpbmRlcGVuZGVudCBvZiB0 aGlzKS4NCj4+Pj4+Pg0KPj4+Pj4+IC0gTm90ZTogVGhlcmUgbWF5IHdlbGwgYmUgYW4gQVNBIHRo YXQgYXNzaWducyAqdXNlciBzcGFjZSogYWRkcmVzc2luZywNCj4+Pj4+PiB0byBiZSB1c2VkIGZv ciB0aGUgbm9ybWFsIGRhdGEgcGxhbmUsIGFuZCBTaGVuZydzIHVzZSBjYXNlIGRyYWZ0IGlzIGFu DQo+Pj4+Pj4gZXhhbXBsZSBvZiBvbmUuIFRoaXMgaXMgcGVyZmVjdGx5IGxlZ2l0aW1hdGUuIFRv IHJlLXN0YXRlOiBXZSBkb24ndA0KPj4+Pj4+IHdhbnQgYXV0b25vbWljYWxseSBzZXQgdXAgcm91 dGFibGUgbGluayBhZGRyZXNzaW5nICpmb3IgYXV0b25vbWljDQo+Pj4+PiB0cmFmZmljKi4NCj4+ Pj4+Pg0KPj4+Pj4+PiBCYWNrIHRvIE1pY2hhZWwncyBtb2RlbC4gSSBoYXZlIGEgcXVlc3Rpb24u IElmIEFTQSBBbHBoYSBvbiBhIGdpdmVuDQo+Pj4+Pj4+IGxpbmsgd2FudHMgdG8gY29tbXVuaWNh dGUgd2l0aCBBU0EgQmV0YSBvbiBhbm90aGVyIGxpbmssIHdoYXQNCj4+Pj4+Pj4gYWRkcmVzc2Vz IGFyZSB1c2VkPw0KPj4+Pj4+DQo+Pj4+Pj4gSW4gbXkgbWluZDogVGhlIHJvdXRhYmxlIFVMQSBh ZGRyZXNzZXMgdGhhdCB3ZSBkZXNjcmliZSBpbg0KPj4+Pj4+IGRyYWZ0LWJlaHJpbmdlci1hbmlt YS1hdXRvbm9taWMtYWRkcmVzc2luZy4gQVNBcyBjb21tdW5pY2F0ZSB3aXRoDQo+Pj4+PiB0aGUN Cj4+Pj4+PiBsb29wYmFjayBhZGRyZXNzZXMgb2YgdGhlIG5vZGVzLg0KPj4+Pj4+DQo+Pj4+Pj4g TWljaGFlbA0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+IEFuaW1hIG1haWxpbmcgbGlzdA0KPj4+Pj4+ IEFuaW1hQGlldGYub3JnDQo+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9hbmltYQ0KPj4+Pg0KPj4+DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+PiBBbmltYSBtYWlsaW5nIGxpc3QNCj4+PiBBbmltYUBpZXRm Lm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWENCg== From nobody Mon Apr 27 18:02:46 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37401ACDD8 for ; Mon, 27 Apr 2015 18:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjtJ_1-M9B5B for ; Mon, 27 Apr 2015 18:02:42 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 560331ACDD3 for ; Mon, 27 Apr 2015 18:02:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRX00954; Tue, 28 Apr 2015 01:02:39 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Apr 2015 02:02:37 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.135]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Tue, 28 Apr 2015 09:02:29 +0800 From: Sheng Jiang To: Alper Yegin Thread-Topic: [Anima] Call for Volunteer - ANIMA signaling design team Thread-Index: AdCA0TZKxUuNJo5JTqiT8YUJ8Qmo5AAHATAAABgRIwA= Date: Tue, 28 Apr 2015 01:02:28 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B925F5061A7@nkgeml512-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B925F505D45@nkgeml512-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.197] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B925F5061A7nkgeml512mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Toerless Eckert , "Liubing \(Leo\)" , Anima WG , "anima-chairs@tools.ietf.org" Subject: Re: [Anima] Call for Volunteer - ANIMA signaling design team X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 01:02:45 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B925F5061A7nkgeml512mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIGFsbCwNCg0KVGhpcyBpcyBhIHByb2dyZXNzIGNsYXJpZmljYXRpb24gZm9yIFdHIHdoaWxl IGl0IGlzIGFsc28gcmVwbHkgdG8gQWxwZXIuDQoNClllcywgd2UgYXJlIHBsYW5uaW5nIHRvIGZv cm0gdHdvIGRlc2lnbiB0ZWFtcyBmb3IgYm9vdHN0cmFwcGluZyBhbmQgc2lnbmFsaW5nLiBTbyBm YXIsIHdlIG9ubHkgYW5ub3VuY2VkIHRoZSBDYWxsIGZvciBWb2x1bnRlZXIgZm9yIHNpZ25hbGlu ZyBkZXNpZ24gdGVhbS4gVGhlIGJvb3RzdHJhcHBpbmcgY2FsbCBmb3Igdm9sdW50ZWVyIHdvdWxk IHByb2JhYmx5IGJlIG5leHQgd2Vlay4gV2UgZGlkIHRoaXMgcGFydGlhbGx5IGJlY2F1c2Ugd2Ug Y291bGQgbGlrZSB0byBtYWtlIHRoZSBwcm9jZXNzZXMgY2xlYXIgc2VwYXJhdGVkIHRvIGF2b2lk IGNvbmZ1c2lvbiwgYWxzbyBiZWNhdXNlIHRoZSBib290c3RyYXBwaW5nIGVkaXRvcnMgYW5kIGNo YXJ0ZXIgaGF2ZSBub3QgcmVhZHkgeWV0Lg0KDQpUaGUgcmVzcG9uc2UgZm9yIGNhbGwtZm9yLXZv bHVudGVlciBzaG91bGQgZ28gdG8gV0cgY2hhaXJzIGFuZCBlZGl0b3JzIGRpcmVjdGx5LiBJdCBp cyBub3QgbmVlZGVkIHRvIGJlIGluIG1haWwgbGlzdC4NCg0KVGhlIGFzc2lnbmVkIGVkaXRvcnMg YW5kIFdHIGNoYWlycyB3b3VsZCBwaWNrIHVwIHRoZSBkZXNpZ24gdGVhbSBtZW1iZXJzIGFmdGVy IHRoZSBjYWxsIGVuZHMuIFNvLCB0aGUgc2lnbmFsaW5nIGRlc2lnbiB0ZWFtIHdvdWxkIGJlIGFu bm91bmNlZCBsYXRlciBuZXh0IHdlZWsuDQoNCkNyZWF0aW5nIHRoZSBtYWlsIGxpc3RzIGZvciB0 aGUgZGVzaWduIHRlYW0gbmVlZHMgYXBwcm92YWwgZnJvbSBvdXIgcmVzcG9uc2libGUgQUQuIEFz IGxvbmcgYXMgdGhlIG1haWwgbGlzdHMgYXJlIGF2YWlsYWJsZSwgd2Ugd2lsbCBhbHNvIG1ha2Ug YW5ub3VuY2VtZW50IGluIHRoZSBtYWlsIGxpc3QuIEFzIHdlIHNhaWQsIHRoZSBkZXNpZ24gdGVh bSBkaXNjdXNzaW9ucyBzaG91bGQgYmUgb3BlbiBmb3IgYWxsIEFOSU1BIHBhcnRpY2lwYXRvcnMu IFBlb3BsZSB3aG8gaXMgaW50ZXJlc3RlZCwgYnV0IG5vdCBpbiB0aGUgZGVzaWduIHRlYW0sIGNv dWxkIGFsc28gYmUgYWJsZSB0byBwYXJ0aWNpcGF0ZSBhbmQgbWFrZSBjb250cmlidXRpb25zIG9y IGNvbW1lbnRzLg0KDQpCZXN0IHJlZ2FyZHMsDQoNClNoZW5nDQoNCkZyb206IEFscGVyIFllZ2lu IFttYWlsdG86YWxwZXIueWVnaW5AeWVnaW4ub3JnXQ0KU2VudDogVHVlc2RheSwgQXByaWwgMjgs IDIwMTUgNToyMyBBTQ0KVG86IFNoZW5nIEppYW5nDQpDYzogQW5pbWEgV0c7IFRvZXJsZXNzIEVj a2VydDsgTGl1YmluZyAoTGVvKTsgYW5pbWEtY2hhaXJzQHRvb2xzLmlldGYub3JnDQpTdWJqZWN0 OiBSZTogW0FuaW1hXSBDYWxsIGZvciBWb2x1bnRlZXIgLSBBTklNQSBzaWduYWxpbmcgZGVzaWdu IHRlYW0NCg0KSGVsbG8gU2hlbmcsDQoNCklFVEYgOTIgcHJvY2VlZGluZ3MgaGFkIHN0YXRlZDoN Cg0KDQpXb3VsZCBsaWtlIHRvIHN0YXJ0IGJ1aWxkaW5nIGRlc2lnbiB0ZWFtcyBmb3IgYSkgYm9v dHN0cmFwDQoNCiAgICAgIGFuZCBiKSBzaWduYWxpbmcsIHdoaWNoIGFyZSBtaWxlc3RvbmUgYnVp bGRpbmcgYmxvY2tzLg0KDQpTbywgd2hhdCB5b3UndmUgYW5ub3VuY2VkIGlzIG9uZSBvZiB0aGUg dHdvIGRlc2lnbiB0ZWFtcyB0byBiZSBjcmVhdGVkLCByaWdodD8NCg0KDQpBbHBlcg0KDQoNCg0K T24gQXByIDI3LCAyMDE1LCBhdCAxOjAyIFBNLCBTaGVuZyBKaWFuZyB3cm90ZToNCg0KDQpIaSwg YWxsLA0KDQpXZSBhcmUgY2FsbGluZyBmb3Igdm9sdW50ZWVycyB0byBmb3JtIGEgZGVzaWduIHRp bWUgZm9yIEFOSU1BIHNpZ25hbGluZyBkZXNpZ24gdGVhbS4gVGhlIGNoYWlycyBoYXMgYXNzaWdu ZWQgdHdvIGVkaXRvcnMgKEJyaWFuIENhcnBlbnRlciBhbmQgQmluZyBMaXUpLCB3ZSBhcmUgZXhw ZWN0aW5nIHVwIHRvIDQgbWFpbiBjb250cmlidXRvcnMuIFRoZSBjaGFydGVyLCBpbml0aWFsIGdv YWwgYW5kIHRhcmdldCBkYXRlIGZvciB0aGUgc2lnbmFsaW5nIGRlc2lnbiB0ZWFtIGlzIGludHJv ZHVjZWQgYmVsb3cuIEl0IGFsc28gYXZhaWxhYmxlIGluIHRoZSBkZXNpZ24gdGVhbSB3aWtpIHBh Z2UuDQoNCmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2FuaW1hL3RyYWMvd2lraS9TaWdu YWxpbmcNCg0KQmVjYXVzZSBvZiB0aGUgaW50ZW5kZWQgZGVzaWduIHRlYW0gd29yaywgd2UgZXhw ZWN0IHRoYXQgdGhlIGRlc2lnbiB0ZWFtIG1lbWJlcnMgd291bGQgbmVlZCB0byBzcGVuZCBhdCBs ZWFzdCBoYWxmIGEgZGF5IHBlciB3ZWVrIG9uIHRoaXMgcHJvamVjdCBmb3IgbWF5YmUgNC4uNiBt b250aCwgYnV0IGl0IHNob3VsZCBiZWNvbWUgbGVzcyBhZnRlcndhcmRzLiBXZSB3b3VsZCBsaWtl IHRvIGxpbWl0IHRoZSBkZXNpZ24gdGVhbSB0byBvbmUgeWVhciAob3Igc2hvcnRlciBpZiB0aGUg Z29hbHMgYXJlIHJlYWNoZWQgZmFzdGVyIG9mIGNvdXJzZSkuDQoNCkFzIFdHIGNoYWlycyB3ZSB3 aWxsIHBhcnRpY2lwYXRlIGFuZCBoZWxwIG9mIGNvdXJzZSBpbiB0aGUgZGVzaWduIHRlYW0gcHJp bWFyaWx5IGZvciBsb2dpc3RpY3MuIEluIHByaW5jaXBsZSwgdGhlIGRlc2lnbiB0ZWFtIGRpc2N1 c3Npb25zIHNob3VsZCBiZSBvcGVuIGZvciBhbGwgQU5JTUEgcGFydGljaXBhdG9ycy4gUGVvcGxl IHdobyBpcyBpbnRlcmVzdGVkLCBidXQgZG8gbm90IGhhdmUgZW5vdWdoIHRpbWUgdG8gY29tbWl0 LCBjb3VsZCBhbHNvIGJlIGFibGUgdG8gcGFydGljaXBhdGUgYW5kIG1ha2UgY29udHJpYnV0aW9u cyBvciBjb21tZW50cy4NCg0KVGhpcyBjYWxsIGlzIGxhc3QgZm9yIG9uZSB3ZWVrLiBJdCBlbmRz IE1heSAzcmQsIFN1bmRheS4gUGxlYXNlIHJlcGx5IGJlZm9yZSBpdCBpZiB5b3UgYXJlIGludGVy ZXN0ZWQgaW4gdGhlIGNvbW1pdG1lbnQuDQoNCkNoYXJ0ZXIgZm9yIHRoZSBzaWduYWxpbmcgZGVz aWduIHRlYW0NCg0KVGhlIEFuaW1hIFdHIGNoYXJ0ZXIgc3RhdGVzIGEgcmVxdWlyZW1lbnQgZm9y IGRpc2NvdmVyeSBhbmQgbmVnb3RpYXRpb24gbWVjaGFuaXNtcyB0byBlbmFibGUgY2xvc2VkLWxv b3AgaW50ZXJhY3Rpb24gYmV0d2VlbiBhdXRvbm9taWMgbm9kZXMuIEl0IGFsc28gc3RhdGVzIHRo ZSBnb2FsIG9mIGRldmVsb3Bpbmcgb25lIG9yIG1vcmUgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbnMg KG9yIGV4dGVuc2lvbnMgdG8gZXhpc3RpbmcgcHJvdG9jb2xzKSB0byBhY2hpZXZlIHRoZXNlIGdv YWxzLiBUaGVyZSBpcyBhbiBleGlzdGluZyBkcmFmdCByZXF1aXJlbWVudHMgYW5hbHlzaXMsIHdo b3NlIG1haW4gcG9pbnRzIGluY2x1ZGUNCg0KICAtIHN1cHBvcnQgZm9yIGFueSB0eXBlIG9mIG5l dHdvcmsgb2JqZWN0aXZlIHBhcmFtZXRlcjsNCiAgLSBkaXNjb3ZlcnkgbXVzdCBzdXBwb3J0IGFu eSB0b3BvbG9neSBhbmQgYm9vdHN0cmFwIHNjZW5hcmlvOw0KICAtIHN5bmNocm9uaXplIHBhcmFt ZXRlcnMgd2l0aCBvdGhlciBub2RlcyBpbmRpdmlkdWFsbHkgb3IgYnkgZmxvb2Rpbmc7DQogIC0g bmVnb3RpYXRlIHBhcmFtZXRlcnMgd2l0aCBvdGhlciBub2RlczsNCiAgLSBhbHdheXMgc2VjdXJl Lg0KDQpBIHNpbXBsZSBUTFYgZm9ybWF0IGlzIHByb3Bvc2VkIGZvciB0aGUgcHJvdG9jb2wgZGVz aWduLiBCaW5hcnkgb3IgbmFtZS1iYXNlZCBkaXNjb3ZlcnkgYXJlIHByb3Bvc2VkIGFzIGFsdGVy bmF0aXZlIGRpc2NvdmVyeSBhcHByb2FjaGVzLg0KDQpUaGUgcHVycG9zZSBvZiB0aGUgZGVzaWdu IHRlYW0gaXMgdG8gYW5hbHl6ZSB0aGVzZSBpc3N1ZXMgYW5kIHJlY29tbWVuZCBhIGNvbWJpbmVk IGFwcHJvYWNoIHRvIHRoZSB3b3JraW5nIGdyb3VwLCBwcmVmZXJhYmx5IGluIHRoZSBmb3JtIG9m IG9uZSBkcmFmdCBvciBhIHNtYWxsIHNldCBvZiBjb29yZGluYXRlZCBkcmFmdHMuIFRoZSBwcm9w b3NlZCBhcHByb2FjaCBzaG91bGQgYmUgc3VpdGFibGUgZm9yIHVzZSBieSB0aGUgQXV0b25vbWlj IENvbnRyb2wgUGxhbmUsIGFuZCBmb3Igb3RoZXIgdXNlIGNhc2VzIGluY2x1ZGluZyB0aG9zZSBs aXN0ZWQgaW4gdGhlIEFuaW1hIFdHIGNoYXJ0ZXIuDQoNCkluIHByZXBhcmluZyB0aGUgcmVjb21t ZW5kYXRpb24sIHRoZSBkZXNpZ24gdGVhbSB3aWxsIHZlcmlmeSBhbmQgdXBkYXRlIHRoZSBleGlz dGluZyByZXF1aXJlbWVudHMgYW5kIHVuZGVyc3RhbmQgdGhlIHJlbGV2YW50IHVzZSBjYXNlcy4g SG93ZXZlciwgZG9jdW1lbnRpbmcgYW5kIHNvbHZpbmcgdXNlIGNhc2VzIGlzIG91dCBvZiBzY29w ZSBmb3IgdGhlIGRlc2lnbiB0ZWFtLiBUaGUgZGVzaWduIHRlYW0gaXMgZW5jb3VyYWdlZCB0byBk ZXZlbG9wIHByb3RvY29sIHdhbGt0aHJvdWdocyBhbmQgYW4gYWJzdHJhY3QgQVBJIGFzIGFpZHMg dG8gdW5kZXJzdGFuZGluZy4gVGhlIGRlc2lnbiB0ZWFtIGlzIG5vdCBpdHNlbGYgZXhwZWN0ZWQg dG8gcHJvZHVjZSBjb2RlLCBidXQgZWFzZSBvZiBpbXBsZW1lbnRhdGlvbiBpcyBhbiBpbXBvcnRh bnQgY29uc2lkZXJhdGlvbi4NCg0KVGhlIGRyYWZ0KHMpIHNob3VsZCBiZSBkZWxpdmVyZWQgYnkg dGhlIEp1bHkgMjAxNSBJRVRGICgyMDE1LTA3LTA2IGN1dG9mZiBkYXRlKS4NCg0KSW5pdGlhbCBH b2Fscw0KDQogIC0gVmFsaWRhdGUgYW5kIHVwZGF0ZSB0aGUgZXhpc3RpbmcgbGlzdCBvZiByZXF1 aXJlbWVudHMgKOKAi2h0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNhcnBlbnRlci1h bmltYS1nZG4tcHJvdG9jb2wjc2VjdGlvbi0yKSBhZ2FpbnN0IGJvb3RzdHJhcCBhbmQgQUNQIGRy YWZ0cyAoYW5kIG9wdGlvbmFsbHkgYWdhaW5zdCBvdGhlciB1c2UgY2FzZSB2YWxpZGF0aW9uIGRy YWZ0cykuIFRhcmdldCBkYXRlOiBlbmQgTWF5Lg0KICAtIFJlY29tbWVuZCBob3cgdGhlIG90aGVy IG1pbGVzdG9uZSBjb21wb25lbnRzIG9mIEFOSU1BIChib290c3RyYXAsIEFDUCwgdmFsaWRhdGlv biBkcmFmdHMpIHNob3VsZCB1c2UgdGhlIHNpZ25hbGluZyBwcm90b2NvbChzKS4gQXMgYSBzaWRl LWVmZmVjdCwgY3JpdGlxdWUgdGhlIHByb3Bvc2FsIG9uIHRoZSB0YWJsZSAo4oCLaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNhcnBlbnRlci1hbmltYS1nZG4tcHJvdG9jb2wjc2Vj dGlvbi0zKS4NCg0KVGFyZ2V0IGRhdGU6IG1pZCBKdW5lLg0KDQpCZXN0IHJlZ2FyZHMsDQoNClRv ZXJsZXNzICsgU2hlbmcNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpBbmltYSBtYWlsaW5nIGxpc3QNCkFuaW1hQGlldGYub3JnPG1haWx0bzpBbmltYUBp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWENCg0K --_000_5D36713D8A4E7348A7E10DF7437A4B925F5061A7nkgeml512mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIg MiA2IDkgNCAyIDUgOCAzIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0K YTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5N c29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVy cGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbWFy Z2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5IVE1MQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRN TCDpooTorr7moLzlvI8gQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFy Z2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkhpLCBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlRoaXMgaXMgYSBwcm9ncmVzcyBjbGFyaWZpY2F0aW9uIGZvciBXRyB3aGlsZSBpdCBpcyBhbHNv IHJlcGx5IHRvIEFscGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ZZXMs IHdlIGFyZSBwbGFubmluZyB0byBmb3JtIHR3byBkZXNpZ24gdGVhbXMgZm9yIGJvb3RzdHJhcHBp bmcgYW5kIHNpZ25hbGluZy4gU28gZmFyLCB3ZSBvbmx5IGFubm91bmNlZCB0aGUgQ2FsbCBmb3Ig Vm9sdW50ZWVyIGZvciBzaWduYWxpbmcgZGVzaWduDQogdGVhbS4gVGhlIGJvb3RzdHJhcHBpbmcg Y2FsbCBmb3Igdm9sdW50ZWVyIHdvdWxkIHByb2JhYmx5IGJlIG5leHQgd2Vlay4gV2UgZGlkIHRo aXMgcGFydGlhbGx5IGJlY2F1c2Ugd2UgY291bGQgbGlrZSB0byBtYWtlIHRoZSBwcm9jZXNzZXMg Y2xlYXIgc2VwYXJhdGVkIHRvIGF2b2lkIGNvbmZ1c2lvbiwgYWxzbyBiZWNhdXNlIHRoZSBib290 c3RyYXBwaW5nIGVkaXRvcnMgYW5kIGNoYXJ0ZXIgaGF2ZSBub3QgcmVhZHkgeWV0LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgcmVzcG9uc2UgZm9yIGNhbGwtZm9yLXZv bHVudGVlciBzaG91bGQgZ28gdG8gV0cgY2hhaXJzIGFuZCBlZGl0b3JzIGRpcmVjdGx5LiBJdCBp cyBub3QgbmVlZGVkIHRvIGJlIGluIG1haWwgbGlzdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+VGhlIGFzc2lnbmVkIGVkaXRvcnMgYW5kIFdHIGNoYWlycyB3b3VsZCBwaWNr IHVwIHRoZSBkZXNpZ24gdGVhbSBtZW1iZXJzIGFmdGVyIHRoZSBjYWxsIGVuZHMuIFNvLCB0aGUg c2lnbmFsaW5nIGRlc2lnbiB0ZWFtIHdvdWxkIGJlIGFubm91bmNlZA0KIGxhdGVyIG5leHQgd2Vl ay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q3JlYXRpbmcgdGhlIG1haWwg bGlzdHMgZm9yIHRoZSBkZXNpZ24gdGVhbSBuZWVkcyBhcHByb3ZhbCBmcm9tIG91ciByZXNwb25z aWJsZSBBRC4gQXMgbG9uZyBhcyB0aGUgbWFpbCBsaXN0cyBhcmUgYXZhaWxhYmxlLCB3ZSB3aWxs IGFsc28gbWFrZQ0KIGFubm91bmNlbWVudCBpbiB0aGUgbWFpbCBsaXN0LiBBcyB3ZSBzYWlkLCB0 aGUgZGVzaWduIHRlYW0gZGlzY3Vzc2lvbnMgc2hvdWxkIGJlIG9wZW4gZm9yIGFsbCBBTklNQSBw YXJ0aWNpcGF0b3JzLiBQZW9wbGUgd2hvIGlzIGludGVyZXN0ZWQsIGJ1dCBub3QgaW4gdGhlIGRl c2lnbiB0ZWFtLCBjb3VsZCBhbHNvIGJlIGFibGUgdG8gcGFydGljaXBhdGUgYW5kIG1ha2UgY29u dHJpYnV0aW9ucyBvciBjb21tZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TaGVu ZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBBbHBlciBZZWdpbiBbbWFpbHRvOmFscGVyLnll Z2luQHllZ2luLm9yZ10NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBBcHJpbCAyOCwgMjAx NSA1OjIzIEFNPGJyPg0KPGI+VG86PC9iPiBTaGVuZyBKaWFuZzxicj4NCjxiPkNjOjwvYj4gQW5p bWEgV0c7IFRvZXJsZXNzIEVja2VydDsgTGl1YmluZyAoTGVvKTsgYW5pbWEtY2hhaXJzQHRvb2xz LmlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbQW5pbWFdIENhbGwgZm9yIFZvbHVu dGVlciAtIEFOSU1BIHNpZ25hbGluZyBkZXNpZ24gdGVhbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPkhlbGxvIFNoZW5nLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5JRVRGIDkyIHByb2NlZWRpbmdzIGhhZCBzdGF0ZWQ6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwcmUgc3R5bGU9InRleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiAxOy13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDt3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7d2hpdGUtc3BhY2U6cHJlLXdyYXA7 d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+ V291bGQgbGlrZSB0byBzdGFydCBidWlsZGluZyBkZXNpZ24gdGVhbXMgZm9yIGEpIGJvb3RzdHJh cCA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YW5kIGIp IHNpZ25hbGluZywgd2hpY2ggYXJlIG1pbGVzdG9uZSBidWlsZGluZyBibG9ja3MuPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+U28sIHdo YXQgeW91J3ZlIGFubm91bmNlZCBpcyBvbmUgb2YgdGhlIHR3byBkZXNpZ24gdGVhbXMgdG8gYmUg Y3JlYXRlZCwgcmlnaHQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFscGVyPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBBcHIgMjcs IDIwMTUsIGF0IDE6MDIgUE0sIFNoZW5nIEppYW5nIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4N Cjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+SGksIGFsbCw8YnI+DQo8YnI+DQpXZSBhcmUgY2FsbGluZyBm b3Igdm9sdW50ZWVycyB0byBmb3JtIGEgZGVzaWduIHRpbWUgZm9yIEFOSU1BIHNpZ25hbGluZyBk ZXNpZ24gdGVhbS4gVGhlIGNoYWlycyBoYXMgYXNzaWduZWQgdHdvIGVkaXRvcnMgKEJyaWFuIENh cnBlbnRlciBhbmQgQmluZyBMaXUpLCB3ZSBhcmUgZXhwZWN0aW5nIHVwIHRvIDQgbWFpbiBjb250 cmlidXRvcnMuIFRoZSBjaGFydGVyLCBpbml0aWFsIGdvYWwgYW5kIHRhcmdldCBkYXRlIGZvciB0 aGUgc2lnbmFsaW5nDQogZGVzaWduIHRlYW0gaXMgaW50cm9kdWNlZCBiZWxvdy4gSXQgYWxzbyBh dmFpbGFibGUgaW4gdGhlIGRlc2lnbiB0ZWFtIHdpa2kgcGFnZS48YnI+DQo8YnI+DQo8YSBocmVm PSJodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9hbmltYS90cmFjL3dpa2kvU2lnbmFsaW5n Ij5odHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9hbmltYS90cmFjL3dpa2kvU2lnbmFsaW5n PC9hPjxicj4NCjxicj4NCkJlY2F1c2Ugb2YgdGhlIGludGVuZGVkIGRlc2lnbiB0ZWFtIHdvcmss IHdlIGV4cGVjdCB0aGF0IHRoZSBkZXNpZ24gdGVhbSBtZW1iZXJzIHdvdWxkIG5lZWQgdG8gc3Bl bmQgYXQgbGVhc3QgaGFsZiBhIGRheSBwZXIgd2VlayBvbiB0aGlzIHByb2plY3QgZm9yIG1heWJl IDQuLjYgbW9udGgsIGJ1dCBpdCBzaG91bGQgYmVjb21lIGxlc3MgYWZ0ZXJ3YXJkcy4gV2Ugd291 bGQgbGlrZSB0byBsaW1pdCB0aGUgZGVzaWduIHRlYW0gdG8gb25lIHllYXINCiAob3Igc2hvcnRl ciBpZiB0aGUgZ29hbHMgYXJlIHJlYWNoZWQgZmFzdGVyIG9mIGNvdXJzZSkuPGJyPg0KPGJyPg0K QXMgV0cgY2hhaXJzIHdlIHdpbGwgcGFydGljaXBhdGUgYW5kIGhlbHAgb2YgY291cnNlIGluIHRo ZSBkZXNpZ24gdGVhbSBwcmltYXJpbHkgZm9yIGxvZ2lzdGljcy4gSW4gcHJpbmNpcGxlLCB0aGUg ZGVzaWduIHRlYW0gZGlzY3Vzc2lvbnMgc2hvdWxkIGJlIG9wZW4gZm9yIGFsbCBBTklNQSBwYXJ0 aWNpcGF0b3JzLiBQZW9wbGUgd2hvIGlzIGludGVyZXN0ZWQsIGJ1dCBkbyBub3QgaGF2ZSBlbm91 Z2ggdGltZSB0byBjb21taXQsIGNvdWxkIGFsc28NCiBiZSBhYmxlIHRvIHBhcnRpY2lwYXRlIGFu ZCBtYWtlIGNvbnRyaWJ1dGlvbnMgb3IgY29tbWVudHMuPGJyPg0KPGJyPg0KVGhpcyBjYWxsIGlz IGxhc3QgZm9yIG9uZSB3ZWVrLiBJdCBlbmRzIE1heSAzcmQsIFN1bmRheS4gUGxlYXNlIHJlcGx5 IGJlZm9yZSBpdCBpZiB5b3UgYXJlIGludGVyZXN0ZWQgaW4gdGhlIGNvbW1pdG1lbnQuPGJyPg0K PGJyPg0KQ2hhcnRlciBmb3IgdGhlIHNpZ25hbGluZyBkZXNpZ24gdGVhbTxicj4NCjxicj4NClRo ZSBBbmltYSBXRyBjaGFydGVyIHN0YXRlcyBhIHJlcXVpcmVtZW50IGZvciBkaXNjb3ZlcnkgYW5k IG5lZ290aWF0aW9uIG1lY2hhbmlzbXMgdG8gZW5hYmxlIGNsb3NlZC1sb29wIGludGVyYWN0aW9u IGJldHdlZW4gYXV0b25vbWljIG5vZGVzLiBJdCBhbHNvIHN0YXRlcyB0aGUgZ29hbCBvZiBkZXZl bG9waW5nIG9uZSBvciBtb3JlIHByb3RvY29sIHNwZWNpZmljYXRpb25zIChvciBleHRlbnNpb25z IHRvIGV4aXN0aW5nIHByb3RvY29scykgdG8NCiBhY2hpZXZlIHRoZXNlIGdvYWxzLiBUaGVyZSBp cyBhbiBleGlzdGluZyBkcmFmdCByZXF1aXJlbWVudHMgYW5hbHlzaXMsIHdob3NlIG1haW4gcG9p bnRzIGluY2x1ZGU8YnI+DQo8YnI+DQombmJzcDsmbmJzcDstIHN1cHBvcnQgZm9yIGFueSB0eXBl IG9mIG5ldHdvcmsgb2JqZWN0aXZlIHBhcmFtZXRlcjs8YnI+DQombmJzcDsmbmJzcDstIGRpc2Nv dmVyeSBtdXN0IHN1cHBvcnQgYW55IHRvcG9sb2d5IGFuZCBib290c3RyYXAgc2NlbmFyaW87PGJy Pg0KJm5ic3A7Jm5ic3A7LSBzeW5jaHJvbml6ZSBwYXJhbWV0ZXJzIHdpdGggb3RoZXIgbm9kZXMg aW5kaXZpZHVhbGx5IG9yIGJ5IGZsb29kaW5nOzxicj4NCiZuYnNwOyZuYnNwOy0gbmVnb3RpYXRl IHBhcmFtZXRlcnMgd2l0aCBvdGhlciBub2Rlczs8YnI+DQombmJzcDsmbmJzcDstIGFsd2F5cyBz ZWN1cmUuPGJyPg0KPGJyPg0KQSBzaW1wbGUgVExWIGZvcm1hdCBpcyBwcm9wb3NlZCBmb3IgdGhl IHByb3RvY29sIGRlc2lnbi4gQmluYXJ5IG9yIG5hbWUtYmFzZWQgZGlzY292ZXJ5IGFyZSBwcm9w b3NlZCBhcyBhbHRlcm5hdGl2ZSBkaXNjb3ZlcnkgYXBwcm9hY2hlcy48YnI+DQo8YnI+DQpUaGUg cHVycG9zZSBvZiB0aGUgZGVzaWduIHRlYW0gaXMgdG8gYW5hbHl6ZSB0aGVzZSBpc3N1ZXMgYW5k IHJlY29tbWVuZCBhIGNvbWJpbmVkIGFwcHJvYWNoIHRvIHRoZSB3b3JraW5nIGdyb3VwLCBwcmVm ZXJhYmx5IGluIHRoZSBmb3JtIG9mIG9uZSBkcmFmdCBvciBhIHNtYWxsIHNldCBvZiBjb29yZGlu YXRlZCBkcmFmdHMuIFRoZSBwcm9wb3NlZCBhcHByb2FjaCBzaG91bGQgYmUgc3VpdGFibGUgZm9y IHVzZSBieSB0aGUgQXV0b25vbWljIENvbnRyb2wNCiBQbGFuZSwgYW5kIGZvciBvdGhlciB1c2Ug Y2FzZXMgaW5jbHVkaW5nIHRob3NlIGxpc3RlZCBpbiB0aGUgQW5pbWEgV0cgY2hhcnRlci48YnI+ DQo8YnI+DQpJbiBwcmVwYXJpbmcgdGhlIHJlY29tbWVuZGF0aW9uLCB0aGUgZGVzaWduIHRlYW0g d2lsbCB2ZXJpZnkgYW5kIHVwZGF0ZSB0aGUgZXhpc3RpbmcgcmVxdWlyZW1lbnRzIGFuZCB1bmRl cnN0YW5kIHRoZSByZWxldmFudCB1c2UgY2FzZXMuIEhvd2V2ZXIsIGRvY3VtZW50aW5nIGFuZCBz b2x2aW5nIHVzZSBjYXNlcyBpcyBvdXQgb2Ygc2NvcGUgZm9yIHRoZSBkZXNpZ24gdGVhbS4gVGhl IGRlc2lnbiB0ZWFtIGlzIGVuY291cmFnZWQgdG8gZGV2ZWxvcA0KIHByb3RvY29sIHdhbGt0aHJv dWdocyBhbmQgYW4gYWJzdHJhY3QgQVBJIGFzIGFpZHMgdG8gdW5kZXJzdGFuZGluZy4gVGhlIGRl c2lnbiB0ZWFtIGlzIG5vdCBpdHNlbGYgZXhwZWN0ZWQgdG8gcHJvZHVjZSBjb2RlLCBidXQgZWFz ZSBvZiBpbXBsZW1lbnRhdGlvbiBpcyBhbiBpbXBvcnRhbnQgY29uc2lkZXJhdGlvbi48YnI+DQo8 YnI+DQpUaGUgZHJhZnQocykgc2hvdWxkIGJlIGRlbGl2ZXJlZCBieSB0aGUgSnVseSAyMDE1IElF VEYgKDIwMTUtMDctMDYgY3V0b2ZmIGRhdGUpLjxicj4NCjxicj4NCkluaXRpYWwgR29hbHM8YnI+ DQo8YnI+DQombmJzcDsmbmJzcDstIFZhbGlkYXRlIGFuZCB1cGRhdGUgdGhlIGV4aXN0aW5nIGxp c3Qgb2YgcmVxdWlyZW1lbnRzICg8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O01TIE1pbmNobyZxdW90OyI+4oCLPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jYXJwZW50ZXItYW5pbWEtZ2RuLXByb3Rv Y29sI3NlY3Rpb24tMiI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2FycGVudGVy LWFuaW1hLWdkbi1wcm90b2NvbCNzZWN0aW9uLTI8L2E+KQ0KIGFnYWluc3QgYm9vdHN0cmFwIGFu ZCBBQ1AgZHJhZnRzIChhbmQgb3B0aW9uYWxseSBhZ2FpbnN0IG90aGVyIHVzZSBjYXNlIHZhbGlk YXRpb24gZHJhZnRzKS4gVGFyZ2V0IGRhdGU6IGVuZCBNYXkuPGJyPg0KJm5ic3A7Jm5ic3A7LSBS ZWNvbW1lbmQgaG93IHRoZSBvdGhlciBtaWxlc3RvbmUgY29tcG9uZW50cyBvZiBBTklNQSAoYm9v dHN0cmFwLCBBQ1AsIHZhbGlkYXRpb24gZHJhZnRzKSBzaG91bGQgdXNlIHRoZSBzaWduYWxpbmcg cHJvdG9jb2wocykuIEFzIGEgc2lkZS1lZmZlY3QsIGNyaXRpcXVlIHRoZSBwcm9wb3NhbCBvbiB0 aGUgdGFibGUgKDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgTWluY2hv JnF1b3Q7Ij7igIs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jYXJwZW50ZXItYW5pbWEtZ2RuLXByb3RvY29sI3NlY3Rp b24tMyI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNhcnBlbnRlci1hbmltYS1n ZG4tcHJvdG9jb2wjc2VjdGlvbi0zPC9hPikuPGJyPg0KPGJyPg0KVGFyZ2V0IGRhdGU6IG1pZCBK dW5lLjxicj4NCjxicj4NCkJlc3QgcmVnYXJkcyw8YnI+DQo8YnI+DQpUb2VybGVzcyAmIzQzOyBT aGVuZzxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KQW5pbWEgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkFuaW1hQGlldGYu b3JnIj5BbmltYUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2FuaW1hPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5D36713D8A4E7348A7E10DF7437A4B925F5061A7nkgeml512mbxchi_-- From nobody Mon Apr 27 18:56:13 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C25E1ACE13 for ; Mon, 27 Apr 2015 18:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mAiZFYrm1TH for ; Mon, 27 Apr 2015 18:56:09 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBA0B1ACE0F for ; Mon, 27 Apr 2015 18:56:09 -0700 (PDT) Received: by pacwv17 with SMTP id wv17so126302371pac.0 for ; Mon, 27 Apr 2015 18:56:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0pERvkel4EZA8IKyhl+CE44HpxfjMoFEFVfmJaJh/tQ=; b=wirvE1q4iDh4bBAmp6Ce0vuFQR4x9xdfMeZ/YWef6y0qk5qgxyevwkPevzXdLBr+ba vnTdDjUQR6eTWjFBAMS00/oBpWnF+qxoC029YNleLuUArmEYvkBY6bkKQTuqHagjcn0V 6PW59i8xQg3c+7DENtAQlkj7lM6tNjufOdzCVUvqmp7K8ljnQR88KVuIheRtSGHJw5oo Y2YbqRSiIZplVZf/ncyYTTenLk14uf8Jjtf65gmOJ9BZ/72XWPE7qMtoZP3d+UyWghvC u5mvjmRl62m/4go3LxcugWBjW7wv9+QvszMJ7q7H0c7PdUVb2p9HJC5/PbkXAcWEr9/h /lMQ== X-Received: by 10.66.141.38 with SMTP id rl6mr27070415pab.25.1430186169422; Mon, 27 Apr 2015 18:56:09 -0700 (PDT) Received: from [172.24.48.117] (wireless-nat-21.auckland.ac.nz. [130.216.30.132]) by mx.google.com with ESMTPSA id gs7sm3505690pbc.6.2015.04.27.18.56.04 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Apr 2015 18:56:08 -0700 (PDT) Message-ID: <553EE8B4.8070603@gmail.com> Date: Tue, 28 Apr 2015 13:56:04 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Sheng Jiang , "Michael Behringer (mbehring)" , "Liubing (Leo)" , Anima WG References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22F62DBD@xmb-rcd-x14.cisco.com> <55395DF3.3000702@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F63344@xmb-rcd-x14.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F457CEEBFF1@nkgeml506-mbx.china.huawei.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F634DE@xmb-rcd-x14.cisco.com> <553AA242.2040908@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F505C6E@nkgeml512-mbx.china.huawei.com> <553E93B9.8050501@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F50617C@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B925F50617C@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Addressing: Consensus on Separate Addressing Realms?-//RE: Addressing: Do we need link addressing? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 01:56:12 -0000 On 28/04/2015 12:51, Sheng Jiang wrote: >>> Firstly, I have to point out that ASAs are functions. They do NOT have >> addresses. What we are discussing is the communication channels and their >> correspondent addresses that ASAs use to exchange controlling messages. >>> >>> Then, I agree the controlling message exchanging should go through the >> ACP which has separate addressing realm. In the case that ACP is not available >> or not chosen, the controlling message exchanging should be done with >> necessary security mechanism. Whether it uses ULAs or other data plane >> addresses, I don't see much different. Unless the network uses different >> mechanism to build up routing for ULA, then, ULA may be used as backup >> communication way when data plane crashed. However, without the analysis >> on the specific mechanism that used to build up routing for ULA, I don't think >> using ULA itself is any more reliable than other communication in the normal >> data plane. >> >> There is one difference - if the network gets disconnected from the Internet, >> and is reconnected later with a different prefix, the ULA communication will >> not >> be affected. That could affect small networks but not large enterprises. From >> every other aspect, I agree there is no difference. > > So, are you talking about using ULA address as the device identifier? If so, may be yes, I am not sure. We are not explore the device identifier yet. So far, from the reachability perspective, ULA does not make much different as it also goes through the normal data plane. No, I'm not referring to authenticated identity, only to addressing for the control plane. Although I'm not convinced by the behringer-anima-autonomic-addressing model, I do see the value of control plane addressing that is independent of the Internet and never needs renumbering. In my mind it is a secure session (ACP or just TLS) that authenticates identity. Regards Brian > > Regards, > > Sheng > >> Regards >> Brian >> >>> >>> Best regards, >>> >>> Sheng >>> >>>> -----Original Message----- >>>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E >>>> Carpenter >>>> Sent: Saturday, April 25, 2015 4:06 AM >>>> To: Michael Behringer (mbehring); Liubing (Leo); Anima WG >>>> Subject: Re: [Anima] Addressing: Consensus on Separate Addressing >>>> Realms?-//RE: Addressing: Do we need link addressing? >>>> >>>> On 25/04/2015 00:06, Michael Behringer (mbehring) wrote: >>>>>> -----Original Message----- >>>>>> From: Liubing (Leo) [mailto:leo.liubing@huawei.com] >>>>>> Sent: 24 April 2015 13:08 >>>>>> To: Michael Behringer (mbehring); Brian E Carpenter; Anima WG >>>>>> Subject: Addressing: Consensus on Separate Addressing Realms?-//RE: >>>>>> [Anima] Addressing: Do we need link addressing? >>>>>> >>>>>> Hi Michael, Brian, and all, >>>>>> >>>>>> Please allow me to fork this thread into another specific topic: do we >> need >>>>>> separated addressing realm for ASAs communication? >>>>>> I see we've already had some good discussion, so let's confirm whether >> we >>>>>> could reach consensus on this specific topic in this WG. >>>>>> >>>>>> Let me briefly summarize current discussion here (please correct me if I >>>>>> make something wrong): >>>>>> - Requirement: we need separate addressing realm for communication >>>>>> between Autonomic Service Agents. >>>>>> a) when there is ACP, since ACP uses separate addressing realm, the >>>> ASAs >>>>>> are also naturally in a separated addressing realm. >>>>>> b) when there is NO ACP: >>>>>> b-1: use the draft-behringer-anima-autonomic-addressing to >> number >>>> the >>>>>> autonomic nodes ULAs on loopback interfaces. >>>>>> b-2: use the same prefix ( the normal data plane prefix) for >>>> autonomic >>>>>> nodes. The ASAs communication is just in the normal data plane. >>>>>> >>>>>> From the separate addressing realm perspective, the b-2 should NOT be >>>> the >>>>>> choice. However, the b-2 could also be autonomic if >>>> [I.D.jiang-anima-prefix- >>>>>> management] applies. >>>>>> >>>>>> So please allow me confirm two questions: >>>>>> 1. Do we reach consensus on separate addressing realm for ASAs? >>>>>> 2. Do we also count b-2 option in or not? >>>>> >>>>> The discussion is just starting so I doubt we can call consensus at this >> point. >>>>> >>>>> I strongly favour a separate addressing scheme for ASAs, even in the case >>>> where there is no separation. >>>>> >>>>> Arguments in favour: >>>>> - consistent way of addressing autonomic nodes. As an ASA developer >> you >>>> know what you'll get. >>>>> - I would make this addressing scheme not configurable or modifyable. >> It's >>>> an autonomic process. --> stability >>>>> - Therefore: Address (mis-) configuration has little chance to interfere >> with >>>> the autonomic addressing. (Of course for true separation you still benefit >>> >from the ACP). >>>>> - and: It's cheap - I see no reason to *not* do it. >>>> >>>> I tend to agree with Michael B on this. There is the minor point that I >>>> just raised in response to Michael R: what if we have a specific use case >>>> that crosses the normal (enterprise-based) trust boundary? For that >> particular >>>> case, we might have to run an autonomic process in public address space. >>>> Of course, it would still need to be secured (e.g. with TLS). >>>> >>>> Brian >>>> >>>>> >>>>> Michael >>>>> >>>>>> Best regards, >>>>>> Bing >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael >>>>>>> Behringer (mbehring) >>>>>>> Sent: Friday, April 24, 2015 5:23 PM >>>>>>> To: Brian E Carpenter; Anima WG >>>>>>> Subject: Re: [Anima] Addressing: Do we need link addressing? >>>>>>> >>>>>>>>> I'd like to raise a question to the list for discussion: Do we >>>>>>>>> need to create >>>>>>>> autonomic link addressing? >>>>>>>>> >>>>>>>>> Here is my view: We need to distinguish about addressing done in >>>>>>>>> the >>>>>>>> Autonomic Networking Infrastructure, and addressing configured and >>>>>>>> managed by an operator. For the Autonomic Networking >> Infrastructure, >>>>>>>> which serves autonomic service agents, I do not think we need >>>>>>>> routable addresses on links, and suggest to use only link-local >>>>>>>> addressing. So the only addressing we should make routable are >>>>>>>> loopback addresses on >>>>>>> devices. >>>>>>>> >>>>>>>> Firstly, yes, we should clearly separate the addressing realm used >>>>>>>> by ASAs to communicate between themselves from the addressing >>>>>>>> realm(s) used by the user network. >>>>>>>> (I made that "realm(s)" because in the case of highly virtualized >>>>>>>> data centres etc., there might be many tenant addressing realms. And >>>>>>>> of course those addressing realms might well be administered by >>>>>>>> certain >>>>>>>> ASAs.) So here, we are talking about the addressing realm used by >>>>>>>> the ASAs to talk to each other. >>>>>>> >>>>>>> So far - we're in sync! :-) Absolutely agree on the realm(s) (Plural). >>>> Single >>>>>>> realm does not make sense these days. >>>>>>> >>>>>>>> But now we come to a branching point. Michael wants everybody to >>>>>>>> have a distinct ACP. I think that's a fine idea but I want to keep >>>>>>>> the option where there is no ACP, but the ASAs simply communicate >>>>>>>> using IP among themselves. In that mode there's nothing special >>>>>>>> about addressing; for example all ASAs could be numbered out of a >>>>>>>> specific ULA prefix, which would be the AN addressing realm, but >>>>>>>> they don't need to be routers. So in that mode, no, there is no >>>>>>>> restriction to link-local >>>>>>> addressing. >>>>>>> >>>>>>> We don't disagree actually ;-) While I see a number of real >> advantages >>>> of >>>>>>> the ACP, there may well be environments where the ACP isn't feasible >>>>>>> for one reason or another. Constrained devices could be one such case. >>>>>>> >>>>>>> So, assume that ASAs run in the data plane of the network, and NOT in >>>>>>> a separate ACP. I claim the fundamentals of the discussion apply here >> as >>>>>> well. >>>>>>> In particular: >>>>>>> >>>>>>> - we want a specific realm for the autonomic service agents, >>>>>>> independent of what an admin configures. So: ASA uses >> autonomically >>>>>>> set up addressing; "normal" configured processes use the configured >>>>>>> addressing. With IPv6 this shouldn't be an issue. This autonomic realm >>>>>>> shouldn't be configurable; it should just happen (just like in the >>>>>>> ACP). So the admin cannot mess up the addressing of the ASAs. He CAN >>>>>>> mess up routing if there's no separate ACP, but that's a choice we'll >> have >>>>>> to make. >>>>>>> >>>>>>> - It would be nice (although not mandatory) if the same addressing we >>>>>>> use inside the ACP would apply here too. >>>>>>> >>>>>>> - the link local discussion DOES apply also in the data plane, in my >>>>>>> opinion, and I would make the same claim that I made for the ACP: I >>>>>>> think the autonomic infrastructure shouldn't assign any routable link >>>>>>> addressing for the autonomic processes. (What the user does is >>>>>> independent of this). >>>>>>> >>>>>>> - Note: There may well be an ASA that assigns *user space* addressing, >>>>>>> to be used for the normal data plane, and Sheng's use case draft is an >>>>>>> example of one. This is perfectly legitimate. To re-state: We don't >>>>>>> want autonomically set up routable link addressing *for autonomic >>>>>> traffic*. >>>>>>> >>>>>>>> Back to Michael's model. I have a question. If ASA Alpha on a given >>>>>>>> link wants to communicate with ASA Beta on another link, what >>>>>>>> addresses are used? >>>>>>> >>>>>>> In my mind: The routable ULA addresses that we describe in >>>>>>> draft-behringer-anima-autonomic-addressing. ASAs communicate with >>>>>> the >>>>>>> loopback addresses of the nodes. >>>>>>> >>>>>>> Michael >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Anima mailing list >>>>>>> Anima@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/anima >>>>> >>>> >>>> _______________________________________________ >>>> Anima mailing list >>>> Anima@ietf.org >>>> https://www.ietf.org/mailman/listinfo/anima From nobody Mon Apr 27 19:08:37 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 526431ACE17 for ; Mon, 27 Apr 2015 19:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vPtWRI6n_je for ; Mon, 27 Apr 2015 19:08:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 289091ACE16 for ; Mon, 27 Apr 2015 19:08:33 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRX04348; Tue, 28 Apr 2015 02:08:31 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Apr 2015 03:08:30 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.93]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Tue, 28 Apr 2015 10:08:21 +0800 From: "Liubing (Leo)" To: Brian E Carpenter , Sheng Jiang , "Michael Behringer (mbehring)" , Anima WG Thread-Topic: [Anima] Addressing: Consensus on Separate Addressing Realms?-//RE: Addressing: Do we need link addressing? Thread-Index: AQHQgMRMjCNeBaT3KEKLWyVGznbWVZ1gwASAgADpVhA= Date: Tue, 28 Apr 2015 02:08:21 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F457CEECA4A@nkgeml506-mbx.china.huawei.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22F62DBD@xmb-rcd-x14.cisco.com> <55395DF3.3000702@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F63344@xmb-rcd-x14.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F457CEEBFF1@nkgeml506-mbx.china.huawei.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F634DE@xmb-rcd-x14.cisco.com> <553AA242.2040908@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F505C6E@nkgeml512-mbx.china.huawei.com> <553E93B9.8050501@gmail.com> In-Reply-To: <553E93B9.8050501@gmail.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.117] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] Addressing: Consensus on Separate Addressing Realms?-//RE: Addressing: Do we need link addressing? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 02:08:36 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciBb bWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbV0NCj4gU2VudDogVHVlc2RheSwgQXBy aWwgMjgsIDIwMTUgMzo1MyBBTQ0KPiBUbzogU2hlbmcgSmlhbmc7IE1pY2hhZWwgQmVocmluZ2Vy IChtYmVocmluZyk7IExpdWJpbmcgKExlbyk7IEFuaW1hIFdHDQo+IFN1YmplY3Q6IFJlOiBbQW5p bWFdIEFkZHJlc3Npbmc6IENvbnNlbnN1cyBvbiBTZXBhcmF0ZSBBZGRyZXNzaW5nDQo+IFJlYWxt cz8tLy9SRTogQWRkcmVzc2luZzogRG8gd2UgbmVlZCBsaW5rIGFkZHJlc3Npbmc/DQo+IA0KPiBP biAyNy8wNC8yMDE1IDIwOjI5LCBTaGVuZyBKaWFuZyB3cm90ZToNCj4gPiBIaSwgQmluZyAmIEJy aWFuLA0KPiA+DQo+ID4gRmlyc3RseSwgSSBoYXZlIHRvIHBvaW50IG91dCB0aGF0IEFTQXMgYXJl IGZ1bmN0aW9ucy4gVGhleSBkbyBOT1QgaGF2ZQ0KPiBhZGRyZXNzZXMuIFdoYXQgd2UgYXJlIGRp c2N1c3NpbmcgaXMgdGhlIGNvbW11bmljYXRpb24gY2hhbm5lbHMgYW5kIHRoZWlyDQo+IGNvcnJl c3BvbmRlbnQgYWRkcmVzc2VzIHRoYXQgQVNBcyB1c2UgdG8gZXhjaGFuZ2UgY29udHJvbGxpbmcg bWVzc2FnZXMuDQo+ID4NCj4gPiBUaGVuLCBJIGFncmVlIHRoZSBjb250cm9sbGluZyBtZXNzYWdl IGV4Y2hhbmdpbmcgc2hvdWxkIGdvIHRocm91Z2ggdGhlDQo+IEFDUCB3aGljaCBoYXMgc2VwYXJh dGUgYWRkcmVzc2luZyByZWFsbS4gSW4gdGhlIGNhc2UgdGhhdCBBQ1AgaXMgbm90DQo+IGF2YWls YWJsZSBvciBub3QgY2hvc2VuLCB0aGUgY29udHJvbGxpbmcgbWVzc2FnZSBleGNoYW5naW5nIHNo b3VsZCBiZSBkb25lDQo+IHdpdGggbmVjZXNzYXJ5IHNlY3VyaXR5IG1lY2hhbmlzbS4gV2hldGhl ciBpdCB1c2VzIFVMQXMgb3Igb3RoZXIgZGF0YQ0KPiBwbGFuZSBhZGRyZXNzZXMsIEkgZG9uJ3Qg c2VlIG11Y2ggZGlmZmVyZW50LiBVbmxlc3MgdGhlIG5ldHdvcmsgdXNlcw0KPiBkaWZmZXJlbnQg bWVjaGFuaXNtIHRvIGJ1aWxkIHVwIHJvdXRpbmcgZm9yIFVMQSwgdGhlbiwgVUxBIG1heSBiZSB1 c2VkIGFzDQo+IGJhY2t1cCBjb21tdW5pY2F0aW9uIHdheSB3aGVuIGRhdGEgcGxhbmUgY3Jhc2hl ZC4gSG93ZXZlciwgd2l0aG91dCB0aGUNCj4gYW5hbHlzaXMgb24gdGhlIHNwZWNpZmljIG1lY2hh bmlzbSB0aGF0IHVzZWQgdG8gYnVpbGQgdXAgcm91dGluZyBmb3IgVUxBLCBJDQo+IGRvbid0IHRo aW5rIHVzaW5nIFVMQSBpdHNlbGYgaXMgYW55IG1vcmUgcmVsaWFibGUgdGhhbiBvdGhlciBjb21t dW5pY2F0aW9uIGluDQo+IHRoZSBub3JtYWwgZGF0YSBwbGFuZS4NCj4gDQo+IFRoZXJlIGlzIG9u ZSBkaWZmZXJlbmNlIC0gaWYgdGhlIG5ldHdvcmsgZ2V0cyBkaXNjb25uZWN0ZWQgZnJvbSB0aGUg SW50ZXJuZXQsDQo+IGFuZCBpcyByZWNvbm5lY3RlZCBsYXRlciB3aXRoIGEgZGlmZmVyZW50IHBy ZWZpeCwgdGhlIFVMQSBjb21tdW5pY2F0aW9uIHdpbGwNCj4gbm90IGJlIGFmZmVjdGVkLiANCltC aW5nXSBUaGlzIGlzIGFjdHVhbGx5IG9uZSBvZiB0aGUgc3VnZ2VzdGlvbnMgZm9yIGVhc2Ugb2Yg cmVudW1iZXJpbmcgZGVzY3JpYmVkIGluIFJGQzY4Nzk6DQoiRm9yIGVudGVycHJpc2UgbmV0d29y a3MsIHVzaW5nIFVMQSBzaW11bHRhbmVvdXNseSB3aXRoDQogICBQQSBhZGRyZXNzZXMgY2FuIHBy b3ZpZGUgYSBsb2NhbCByb3V0aW5nIHBsYW5lIGxvZ2ljYWxseSBzZXBhcmF0ZWQNCiAgIGZyb20g dGhlIGdsb2JhbCByb3V0aW5nIHBsYW5lLiAgVGhlIGJlbmVmaXQgaXMgdG8gZW5zdXJlIHN0YWJs ZSBhbmQNCiAgIHNwZWNpZmljIGxvY2FsIGNvbW11bmljYXRpb24gcmVnYXJkbGVzcyBvZiBhbnkg SVNQIHVwbGluayBmYWlsdXJlLg0KICAgVGhpcyBiZW5lZml0IGlzIGVzcGVjaWFsbHkgbWVhbmlu Z2Z1bCBmb3IgcmVudW1iZXJpbmcuIg0KDQpIb3dldmVyLCBpdCBzZWVtcyBsaWtlIGl0J3Mgbm90 IHNvbGlkIGVub3VnaCB0byBhc3NpZ24gVUxBcyBmb3IgQVNBcyBjb21tdW5pY2F0aW9uIHdoZW4g dGhlcmUgaXMgbm8gQUNQIG9ubHkgaW4gdGVybXMgb2YgcmVudW1iZXJpbmcgY29uc2lkZXJhdGlv bi4NCk9uZSB0aGluZyBJIHRob3VnaHQgd2FzIHRoYXQgVUxBcyBhc3NpZ25tZW50IGNvdWxkIGJl IGd1YXJhbnRlZWQgZnVsbHktYXV0b25vbWljIGF0IGFueSB0aW1lOyBpdCBpcyBpbmRlcGVuZGVu dCBvZiBTTEFBQyB3aGljaCByZWxpZXMgb24gcHJlLWNvbmZpZ3VyYXRpb25zIG9uIHRoZSByb3V0 ZXJzLg0KQXJlIHRoZXJlIGFueSBvdGhlciByZWFzb25zIHRoYXQgc3VwcG9ydCBzZXBhcmF0aW5n IHRoZSBBU0FzIGFkZHJlc3Npbmcgc2NoZW1lIGZyb20gdGhlIGRhdGEgcGxhbmUgYWRkcmVzc2lu Zz8NCg0KQmVzdCByZWdhcmRzLA0KQmluZw0KDQo+IFRoYXQgY291bGQgYWZmZWN0IHNtYWxsIG5l dHdvcmtzIGJ1dCBub3QgbGFyZ2UgZW50ZXJwcmlzZXMuDQo+IEZyb20gZXZlcnkgb3RoZXIgYXNw ZWN0LCBJIGFncmVlIHRoZXJlIGlzIG5vIGRpZmZlcmVuY2UuDQo+IA0KPiBSZWdhcmRzDQo+ICAg QnJpYW4NCj4gDQo+ID4NCj4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4NCj4gPiBTaGVuZw0KPiA+DQo+ ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IEFuaW1hIFttYWlsdG86 YW5pbWEtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJyaWFuIEUNCj4gPj4gQ2FycGVu dGVyDQo+ID4+IFNlbnQ6IFNhdHVyZGF5LCBBcHJpbCAyNSwgMjAxNSA0OjA2IEFNDQo+ID4+IFRv OiBNaWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpOyBMaXViaW5nIChMZW8pOyBBbmltYSBXRw0K PiA+PiBTdWJqZWN0OiBSZTogW0FuaW1hXSBBZGRyZXNzaW5nOiBDb25zZW5zdXMgb24gU2VwYXJh dGUgQWRkcmVzc2luZw0KPiA+PiBSZWFsbXM/LS8vUkU6IEFkZHJlc3Npbmc6IERvIHdlIG5lZWQg bGluayBhZGRyZXNzaW5nPw0KPiA+Pg0KPiA+PiBPbiAyNS8wNC8yMDE1IDAwOjA2LCBNaWNoYWVs IEJlaHJpbmdlciAobWJlaHJpbmcpIHdyb3RlOg0KPiA+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+ID4+Pj4gRnJvbTogTGl1YmluZyAoTGVvKSBbbWFpbHRvOmxlby5saXViaW5nQGh1 YXdlaS5jb21dDQo+ID4+Pj4gU2VudDogMjQgQXByaWwgMjAxNSAxMzowOA0KPiA+Pj4+IFRvOiBN aWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpOyBCcmlhbiBFIENhcnBlbnRlcjsgQW5pbWEgV0cN Cj4gPj4+PiBTdWJqZWN0OiBBZGRyZXNzaW5nOiBDb25zZW5zdXMgb24gU2VwYXJhdGUgQWRkcmVz c2luZyBSZWFsbXM/LS8vUkU6DQo+ID4+Pj4gW0FuaW1hXSBBZGRyZXNzaW5nOiBEbyB3ZSBuZWVk IGxpbmsgYWRkcmVzc2luZz8NCj4gPj4+Pg0KPiA+Pj4+IEhpIE1pY2hhZWwsIEJyaWFuLCBhbmQg YWxsLA0KPiA+Pj4+DQo+ID4+Pj4gUGxlYXNlIGFsbG93IG1lIHRvIGZvcmsgdGhpcyB0aHJlYWQg aW50byBhbm90aGVyIHNwZWNpZmljIHRvcGljOiBkbw0KPiA+Pj4+IHdlIG5lZWQgc2VwYXJhdGVk IGFkZHJlc3NpbmcgcmVhbG0gZm9yIEFTQXMgY29tbXVuaWNhdGlvbj8NCj4gPj4+PiBJIHNlZSB3 ZSd2ZSBhbHJlYWR5IGhhZCBzb21lIGdvb2QgZGlzY3Vzc2lvbiwgc28gbGV0J3MgY29uZmlybQ0K PiA+Pj4+IHdoZXRoZXIgd2UgY291bGQgcmVhY2ggY29uc2Vuc3VzIG9uIHRoaXMgc3BlY2lmaWMg dG9waWMgaW4gdGhpcyBXRy4NCj4gPj4+Pg0KPiA+Pj4+IExldCBtZSBicmllZmx5IHN1bW1hcml6 ZSBjdXJyZW50IGRpc2N1c3Npb24gaGVyZSAocGxlYXNlIGNvcnJlY3QgbWUNCj4gPj4+PiBpZiBJ IG1ha2Ugc29tZXRoaW5nIHdyb25nKToNCj4gPj4+PiAtIFJlcXVpcmVtZW50OiB3ZSBuZWVkIHNl cGFyYXRlIGFkZHJlc3NpbmcgcmVhbG0gZm9yIGNvbW11bmljYXRpb24NCj4gPj4+PiBiZXR3ZWVu IEF1dG9ub21pYyBTZXJ2aWNlIEFnZW50cy4NCj4gPj4+PiAgIGEpIHdoZW4gdGhlcmUgaXMgQUNQ LCBzaW5jZSBBQ1AgdXNlcyBzZXBhcmF0ZSBhZGRyZXNzaW5nIHJlYWxtLA0KPiA+Pj4+IHRoZQ0K PiA+PiBBU0FzDQo+ID4+Pj4gYXJlIGFsc28gbmF0dXJhbGx5IGluIGEgc2VwYXJhdGVkIGFkZHJl c3NpbmcgcmVhbG0uDQo+ID4+Pj4gICBiKSB3aGVuIHRoZXJlIGlzIE5PIEFDUDoNCj4gPj4+PiAg ICAgYi0xOiB1c2UgdGhlIGRyYWZ0LWJlaHJpbmdlci1hbmltYS1hdXRvbm9taWMtYWRkcmVzc2lu ZyB0bw0KPiA+Pj4+IG51bWJlcg0KPiA+PiB0aGUNCj4gPj4+PiBhdXRvbm9taWMgbm9kZXMgVUxB cyBvbiBsb29wYmFjayBpbnRlcmZhY2VzLg0KPiA+Pj4+ICAgICBiLTI6IHVzZSB0aGUgc2FtZSBw cmVmaXggKCB0aGUgbm9ybWFsIGRhdGEgcGxhbmUgcHJlZml4KSBmb3INCj4gPj4gYXV0b25vbWlj DQo+ID4+Pj4gbm9kZXMuIFRoZSBBU0FzIGNvbW11bmljYXRpb24gaXMganVzdCBpbiB0aGUgbm9y bWFsIGRhdGEgcGxhbmUuDQo+ID4+Pj4NCj4gPj4+PiBGcm9tIHRoZSBzZXBhcmF0ZSBhZGRyZXNz aW5nIHJlYWxtIHBlcnNwZWN0aXZlLCB0aGUgYi0yIHNob3VsZCBOT1QNCj4gPj4+PiBiZQ0KPiA+ PiB0aGUNCj4gPj4+PiBjaG9pY2UuIEhvd2V2ZXIsIHRoZSBiLTIgY291bGQgYWxzbyBiZSBhdXRv bm9taWMgaWYNCj4gPj4gW0kuRC5qaWFuZy1hbmltYS1wcmVmaXgtDQo+ID4+Pj4gbWFuYWdlbWVu dF0gYXBwbGllcy4NCj4gPj4+Pg0KPiA+Pj4+IFNvIHBsZWFzZSBhbGxvdyBtZSBjb25maXJtIHR3 byBxdWVzdGlvbnM6DQo+ID4+Pj4gMS4gRG8gd2UgcmVhY2ggY29uc2Vuc3VzIG9uIHNlcGFyYXRl IGFkZHJlc3NpbmcgcmVhbG0gZm9yIEFTQXM/DQo+ID4+Pj4gMi4gRG8gd2UgYWxzbyBjb3VudCBi LTIgb3B0aW9uIGluIG9yIG5vdD8NCj4gPj4+DQo+ID4+PiBUaGUgZGlzY3Vzc2lvbiBpcyBqdXN0 IHN0YXJ0aW5nIHNvIEkgZG91YnQgd2UgY2FuIGNhbGwgY29uc2Vuc3VzIGF0IHRoaXMNCj4gcG9p bnQuDQo+ID4+Pg0KPiA+Pj4gSSBzdHJvbmdseSBmYXZvdXIgYSBzZXBhcmF0ZSBhZGRyZXNzaW5n IHNjaGVtZSBmb3IgQVNBcywgZXZlbiBpbiB0aGUNCj4gPj4+IGNhc2UNCj4gPj4gd2hlcmUgdGhl cmUgaXMgbm8gc2VwYXJhdGlvbi4NCj4gPj4+DQo+ID4+PiBBcmd1bWVudHMgaW4gZmF2b3VyOg0K PiA+Pj4gLSBjb25zaXN0ZW50IHdheSBvZiBhZGRyZXNzaW5nIGF1dG9ub21pYyBub2Rlcy4gQXMg YW4gQVNBIGRldmVsb3Blcg0KPiA+Pj4geW91DQo+ID4+IGtub3cgd2hhdCB5b3UnbGwgZ2V0Lg0K PiA+Pj4gLSBJIHdvdWxkIG1ha2UgdGhpcyBhZGRyZXNzaW5nIHNjaGVtZSBub3QgY29uZmlndXJh YmxlIG9yDQo+ID4+PiBtb2RpZnlhYmxlLiBJdCdzDQo+ID4+IGFuIGF1dG9ub21pYyBwcm9jZXNz LiAtLT4gc3RhYmlsaXR5DQo+ID4+PiAtIFRoZXJlZm9yZTogQWRkcmVzcyAobWlzLSkgY29uZmln dXJhdGlvbiBoYXMgbGl0dGxlIGNoYW5jZSB0bw0KPiA+Pj4gaW50ZXJmZXJlIHdpdGgNCj4gPj4g dGhlIGF1dG9ub21pYyBhZGRyZXNzaW5nLiAoT2YgY291cnNlIGZvciB0cnVlIHNlcGFyYXRpb24g eW91IHN0aWxsDQo+ID4+YmVuZWZpdCBmcm9tIHRoZSBBQ1ApLg0KPiA+Pj4gLSBhbmQ6IEl0J3Mg Y2hlYXAgLSBJIHNlZSBubyByZWFzb24gdG8gKm5vdCogZG8gaXQuDQo+ID4+DQo+ID4+IEkgdGVu ZCB0byBhZ3JlZSB3aXRoIE1pY2hhZWwgQiBvbiB0aGlzLiBUaGVyZSBpcyB0aGUgbWlub3IgcG9p bnQgdGhhdA0KPiA+PiBJIGp1c3QgcmFpc2VkIGluIHJlc3BvbnNlIHRvIE1pY2hhZWwgUjogd2hh dCBpZiB3ZSBoYXZlIGEgc3BlY2lmaWMNCj4gPj4gdXNlIGNhc2UgdGhhdCBjcm9zc2VzIHRoZSBu b3JtYWwgKGVudGVycHJpc2UtYmFzZWQpIHRydXN0IGJvdW5kYXJ5Pw0KPiA+PiBGb3IgdGhhdCBw YXJ0aWN1bGFyIGNhc2UsIHdlIG1pZ2h0IGhhdmUgdG8gcnVuIGFuIGF1dG9ub21pYyBwcm9jZXNz IGluDQo+IHB1YmxpYyBhZGRyZXNzIHNwYWNlLg0KPiA+PiBPZiBjb3Vyc2UsIGl0IHdvdWxkIHN0 aWxsIG5lZWQgdG8gYmUgc2VjdXJlZCAoZS5nLiB3aXRoIFRMUykuDQo+ID4+DQo+ID4+ICAgQnJp YW4NCj4gPj4NCj4gPj4+DQo+ID4+PiBNaWNoYWVsDQo+ID4+Pg0KPiA+Pj4+IEJlc3QgcmVnYXJk cywNCj4gPj4+PiBCaW5nDQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+Pj4+IEZyb206IEFuaW1hIFttYWlsdG86YW5pbWEtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1pY2hhZWwNCj4gPj4+Pj4gQmVocmluZ2VyICht YmVocmluZykNCj4gPj4+Pj4gU2VudDogRnJpZGF5LCBBcHJpbCAyNCwgMjAxNSA1OjIzIFBNDQo+ ID4+Pj4+IFRvOiBCcmlhbiBFIENhcnBlbnRlcjsgQW5pbWEgV0cNCj4gPj4+Pj4gU3ViamVjdDog UmU6IFtBbmltYV0gQWRkcmVzc2luZzogRG8gd2UgbmVlZCBsaW5rIGFkZHJlc3Npbmc/DQo+ID4+ Pj4+DQo+ID4+Pj4+Pj4gSSdkIGxpa2UgdG8gcmFpc2UgYSBxdWVzdGlvbiB0byB0aGUgbGlzdCBm b3IgZGlzY3Vzc2lvbjogRG8gd2UNCj4gPj4+Pj4+PiBuZWVkIHRvIGNyZWF0ZQ0KPiA+Pj4+Pj4g YXV0b25vbWljIGxpbmsgYWRkcmVzc2luZz8NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IEhlcmUgaXMg bXkgdmlldzogV2UgbmVlZCB0byBkaXN0aW5ndWlzaCBhYm91dCBhZGRyZXNzaW5nIGRvbmUgaW4N Cj4gPj4+Pj4+PiB0aGUNCj4gPj4+Pj4+IEF1dG9ub21pYyBOZXR3b3JraW5nIEluZnJhc3RydWN0 dXJlLCBhbmQgYWRkcmVzc2luZyBjb25maWd1cmVkDQo+ID4+Pj4+PiBhbmQgbWFuYWdlZCBieSBh biBvcGVyYXRvci4gRm9yIHRoZSBBdXRvbm9taWMgTmV0d29ya2luZw0KPiA+Pj4+Pj4gSW5mcmFz dHJ1Y3R1cmUsIHdoaWNoIHNlcnZlcyBhdXRvbm9taWMgc2VydmljZSBhZ2VudHMsIEkgZG8gbm90 DQo+ID4+Pj4+PiB0aGluayB3ZSBuZWVkIHJvdXRhYmxlIGFkZHJlc3NlcyBvbiBsaW5rcywgYW5k IHN1Z2dlc3QgdG8gdXNlDQo+ID4+Pj4+PiBvbmx5IGxpbmstbG9jYWwgYWRkcmVzc2luZy4gU28g dGhlIG9ubHkgYWRkcmVzc2luZyB3ZSBzaG91bGQgbWFrZQ0KPiA+Pj4+Pj4gcm91dGFibGUgYXJl IGxvb3BiYWNrIGFkZHJlc3NlcyBvbg0KPiA+Pj4+PiBkZXZpY2VzLg0KPiA+Pj4+Pj4NCj4gPj4+ Pj4+IEZpcnN0bHksIHllcywgd2Ugc2hvdWxkIGNsZWFybHkgc2VwYXJhdGUgdGhlIGFkZHJlc3Np bmcgcmVhbG0NCj4gPj4+Pj4+IHVzZWQgYnkgQVNBcyB0byBjb21tdW5pY2F0ZSBiZXR3ZWVuIHRo ZW1zZWx2ZXMgZnJvbSB0aGUNCj4gPj4+Pj4+IGFkZHJlc3NpbmcNCj4gPj4+Pj4+IHJlYWxtKHMp IHVzZWQgYnkgdGhlIHVzZXIgbmV0d29yay4NCj4gPj4+Pj4+IChJIG1hZGUgdGhhdCAicmVhbG0o cykiIGJlY2F1c2UgaW4gdGhlIGNhc2Ugb2YgaGlnaGx5IHZpcnR1YWxpemVkDQo+ID4+Pj4+PiBk YXRhIGNlbnRyZXMgZXRjLiwgdGhlcmUgbWlnaHQgYmUgbWFueSB0ZW5hbnQgYWRkcmVzc2luZyBy ZWFsbXMuDQo+ID4+Pj4+PiBBbmQgb2YgY291cnNlIHRob3NlIGFkZHJlc3NpbmcgcmVhbG1zIG1p Z2h0IHdlbGwgYmUgYWRtaW5pc3RlcmVkDQo+ID4+Pj4+PiBieSBjZXJ0YWluDQo+ID4+Pj4+PiBB U0FzLikgU28gaGVyZSwgd2UgYXJlIHRhbGtpbmcgYWJvdXQgdGhlIGFkZHJlc3NpbmcgcmVhbG0g dXNlZCBieQ0KPiA+Pj4+Pj4gdGhlIEFTQXMgdG8gdGFsayB0byBlYWNoIG90aGVyLg0KPiA+Pj4+ Pg0KPiA+Pj4+PiBTbyBmYXIgLSB3ZSdyZSBpbiBzeW5jISA6LSkgICBBYnNvbHV0ZWx5IGFncmVl IG9uIHRoZSByZWFsbShzKSAoUGx1cmFsKS4NCj4gPj4gU2luZ2xlDQo+ID4+Pj4+IHJlYWxtIGRv ZXMgbm90IG1ha2Ugc2Vuc2UgdGhlc2UgZGF5cy4NCj4gPj4+Pj4NCj4gPj4+Pj4+IEJ1dCBub3cg d2UgY29tZSB0byBhIGJyYW5jaGluZyBwb2ludC4gTWljaGFlbCB3YW50cyBldmVyeWJvZHkgdG8N Cj4gPj4+Pj4+IGhhdmUgYSBkaXN0aW5jdCBBQ1AuIEkgdGhpbmsgdGhhdCdzIGEgZmluZSBpZGVh IGJ1dCBJIHdhbnQgdG8NCj4gPj4+Pj4+IGtlZXAgdGhlIG9wdGlvbiB3aGVyZSB0aGVyZSBpcyBu byBBQ1AsIGJ1dCB0aGUgQVNBcyBzaW1wbHkNCj4gPj4+Pj4+IGNvbW11bmljYXRlIHVzaW5nIElQ IGFtb25nIHRoZW1zZWx2ZXMuIEluIHRoYXQgbW9kZSB0aGVyZSdzDQo+ID4+Pj4+PiBub3RoaW5n IHNwZWNpYWwgYWJvdXQgYWRkcmVzc2luZzsgZm9yIGV4YW1wbGUgYWxsIEFTQXMgY291bGQgYmUN Cj4gPj4+Pj4+IG51bWJlcmVkIG91dCBvZiBhIHNwZWNpZmljIFVMQSBwcmVmaXgsIHdoaWNoIHdv dWxkIGJlIHRoZSBBTg0KPiA+Pj4+Pj4gYWRkcmVzc2luZyByZWFsbSwgYnV0IHRoZXkgZG9uJ3Qg bmVlZCB0byBiZSByb3V0ZXJzLiBTbyBpbiB0aGF0DQo+ID4+Pj4+PiBtb2RlLCBubywgdGhlcmUg aXMgbm8gcmVzdHJpY3Rpb24gdG8gbGluay1sb2NhbA0KPiA+Pj4+PiBhZGRyZXNzaW5nLg0KPiA+ Pj4+Pg0KPiA+Pj4+PiBXZSBkb24ndCBkaXNhZ3JlZSBhY3R1YWxseSA7LSkgICBXaGlsZSBJIHNl ZSBhIG51bWJlciBvZiByZWFsDQo+IGFkdmFudGFnZXMNCj4gPj4gb2YNCj4gPj4+Pj4gdGhlIEFD UCwgdGhlcmUgbWF5IHdlbGwgYmUgZW52aXJvbm1lbnRzIHdoZXJlIHRoZSBBQ1AgaXNuJ3QNCj4g Pj4+Pj4gZmVhc2libGUgZm9yIG9uZSByZWFzb24gb3IgYW5vdGhlci4gQ29uc3RyYWluZWQgZGV2 aWNlcyBjb3VsZCBiZSBvbmUNCj4gc3VjaCBjYXNlLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBTbywgYXNz dW1lIHRoYXQgQVNBcyBydW4gaW4gdGhlIGRhdGEgcGxhbmUgb2YgdGhlIG5ldHdvcmssIGFuZCBO T1QNCj4gPj4+Pj4gaW4gYSBzZXBhcmF0ZSBBQ1AuIEkgY2xhaW0gdGhlIGZ1bmRhbWVudGFscyBv ZiB0aGUgZGlzY3Vzc2lvbg0KPiA+Pj4+PiBhcHBseSBoZXJlIGFzDQo+ID4+Pj4gd2VsbC4NCj4g Pj4+Pj4gSW4gcGFydGljdWxhcjoNCj4gPj4+Pj4NCj4gPj4+Pj4gLSB3ZSB3YW50IGEgc3BlY2lm aWMgcmVhbG0gZm9yIHRoZSBhdXRvbm9taWMgc2VydmljZSBhZ2VudHMsDQo+ID4+Pj4+IGluZGVw ZW5kZW50IG9mIHdoYXQgYW4gYWRtaW4gY29uZmlndXJlcy4gIFNvOiBBU0EgdXNlcw0KPiA+Pj4+ PiBhdXRvbm9taWNhbGx5IHNldCB1cCBhZGRyZXNzaW5nOyAibm9ybWFsIiBjb25maWd1cmVkIHBy b2Nlc3NlcyB1c2UNCj4gPj4+Pj4gdGhlIGNvbmZpZ3VyZWQgYWRkcmVzc2luZy4gV2l0aCBJUHY2 IHRoaXMgc2hvdWxkbid0IGJlIGFuIGlzc3VlLg0KPiA+Pj4+PiBUaGlzIGF1dG9ub21pYyByZWFs bSBzaG91bGRuJ3QgYmUgY29uZmlndXJhYmxlOyBpdCBzaG91bGQganVzdA0KPiA+Pj4+PiBoYXBw ZW4gKGp1c3QgbGlrZSBpbiB0aGUgQUNQKS4gU28gdGhlIGFkbWluIGNhbm5vdCBtZXNzIHVwIHRo ZQ0KPiA+Pj4+PiBhZGRyZXNzaW5nIG9mIHRoZSBBU0FzLiBIZSBDQU4gbWVzcyB1cCByb3V0aW5n IGlmIHRoZXJlJ3Mgbm8NCj4gPj4+Pj4gc2VwYXJhdGUgQUNQLCBidXQgdGhhdCdzIGEgY2hvaWNl IHdlJ2xsIGhhdmUNCj4gPj4+PiB0byBtYWtlLg0KPiA+Pj4+Pg0KPiA+Pj4+PiAtIEl0IHdvdWxk IGJlIG5pY2UgKGFsdGhvdWdoIG5vdCBtYW5kYXRvcnkpIGlmIHRoZSBzYW1lIGFkZHJlc3NpbmcN Cj4gPj4+Pj4gd2UgdXNlIGluc2lkZSB0aGUgQUNQIHdvdWxkIGFwcGx5IGhlcmUgdG9vLg0KPiA+ Pj4+Pg0KPiA+Pj4+PiAtIHRoZSBsaW5rIGxvY2FsIGRpc2N1c3Npb24gRE9FUyBhcHBseSBhbHNv IGluIHRoZSBkYXRhIHBsYW5lLCBpbg0KPiA+Pj4+PiBteSBvcGluaW9uLCBhbmQgSSB3b3VsZCBt YWtlIHRoZSBzYW1lIGNsYWltIHRoYXQgSSBtYWRlIGZvciB0aGUNCj4gPj4+Pj4gQUNQOiBJIHRo aW5rIHRoZSBhdXRvbm9taWMgaW5mcmFzdHJ1Y3R1cmUgc2hvdWxkbid0IGFzc2lnbiBhbnkNCj4g Pj4+Pj4gcm91dGFibGUgbGluayBhZGRyZXNzaW5nIGZvciB0aGUgYXV0b25vbWljIHByb2Nlc3Nl cy4gKFdoYXQgdGhlDQo+ID4+Pj4+IHVzZXIgZG9lcyBpcw0KPiA+Pj4+IGluZGVwZW5kZW50IG9m IHRoaXMpLg0KPiA+Pj4+Pg0KPiA+Pj4+PiAtIE5vdGU6IFRoZXJlIG1heSB3ZWxsIGJlIGFuIEFT QSB0aGF0IGFzc2lnbnMgKnVzZXIgc3BhY2UqDQo+ID4+Pj4+IGFkZHJlc3NpbmcsIHRvIGJlIHVz ZWQgZm9yIHRoZSBub3JtYWwgZGF0YSBwbGFuZSwgYW5kIFNoZW5nJ3MgdXNlDQo+ID4+Pj4+IGNh c2UgZHJhZnQgaXMgYW4gZXhhbXBsZSBvZiBvbmUuIFRoaXMgaXMgcGVyZmVjdGx5IGxlZ2l0aW1h dGUuIFRvDQo+ID4+Pj4+IHJlLXN0YXRlOiBXZSBkb24ndCB3YW50IGF1dG9ub21pY2FsbHkgc2V0 IHVwIHJvdXRhYmxlIGxpbmsNCj4gPj4+Pj4gYWRkcmVzc2luZyAqZm9yIGF1dG9ub21pYw0KPiA+ Pj4+IHRyYWZmaWMqLg0KPiA+Pj4+Pg0KPiA+Pj4+Pj4gQmFjayB0byBNaWNoYWVsJ3MgbW9kZWwu IEkgaGF2ZSBhIHF1ZXN0aW9uLiBJZiBBU0EgQWxwaGEgb24gYQ0KPiA+Pj4+Pj4gZ2l2ZW4gbGlu ayB3YW50cyB0byBjb21tdW5pY2F0ZSB3aXRoIEFTQSBCZXRhIG9uIGFub3RoZXIgbGluaywNCj4g Pj4+Pj4+IHdoYXQgYWRkcmVzc2VzIGFyZSB1c2VkPw0KPiA+Pj4+Pg0KPiA+Pj4+PiBJbiBteSBt aW5kOiBUaGUgcm91dGFibGUgVUxBIGFkZHJlc3NlcyB0aGF0IHdlIGRlc2NyaWJlIGluDQo+ID4+ Pj4+IGRyYWZ0LWJlaHJpbmdlci1hbmltYS1hdXRvbm9taWMtYWRkcmVzc2luZy4gQVNBcyBjb21t dW5pY2F0ZQ0KPiB3aXRoDQo+ID4+Pj4gdGhlDQo+ID4+Pj4+IGxvb3BiYWNrIGFkZHJlc3NlcyBv ZiB0aGUgbm9kZXMuDQo+ID4+Pj4+DQo+ID4+Pj4+IE1pY2hhZWwNCj4gPj4+Pj4NCj4gPj4+Pj4N Cj4gPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPj4+Pj4gQW5pbWEgbWFpbGluZyBsaXN0DQo+ID4+Pj4+IEFuaW1hQGlldGYub3JnDQo+ID4+ Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWENCj4gPj4+DQo+ ID4+DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4+IEFuaW1hIG1haWxpbmcgbGlzdA0KPiA+PiBBbmltYUBpZXRmLm9yZw0KPiA+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hDQo= From nobody Thu Apr 30 07:50:09 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18ED31B2C7C for ; Thu, 30 Apr 2015 07:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNJnbVmbXBEW for ; Thu, 30 Apr 2015 07:50:03 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0B3F1B2C77 for ; Thu, 30 Apr 2015 07:50:00 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 7B4D01E1C2253; Thu, 30 Apr 2015 14:49:56 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t3UEnvaH003224 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Apr 2015 16:49:58 +0200 Received: from [172.27.204.62] (135.239.27.40) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 30 Apr 2015 16:49:57 +0200 Message-ID: <55424114.1010000@alcatel-lucent.com> Date: Thu, 30 Apr 2015 16:49:56 +0200 From: Laurent Ciavaglia Organization: Alcatel-Lucent Bell Labs France User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Sheng Jiang , Anima WG References: <5D36713D8A4E7348A7E10DF7437A4B925F505D45@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B925F505D45@nkgeml512-mbx.china.huawei.com> Content-Type: multipart/alternative; boundary="------------000603090604040801080605" X-Originating-IP: [135.239.27.40] Archived-At: Cc: Toerless Eckert , "Liubing \(Leo\)" , "anima-chairs@tools.ietf.org" Subject: Re: [Anima] Call for Volunteer - ANIMA signaling design team X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 14:50:07 -0000 --------------000603090604040801080605 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Dear Sheng, all, I would like to volunteer for the ANIMA signaling design team. However, the mission statement (as described below) is not fully clear to me, thus I would suggest we (ANIMA WG) spend some cycles to clarify the mission, the objectives and relationship with other components / work items of ANIMA. Thanks, best regards, Laurent. On 27/04/2015 12:02, Sheng Jiang wrote: > Hi, all, > > We are calling for volunteers to form a design time for ANIMA signaling design team. The chairs has assigned two editors (Brian Carpenter and Bing Liu), we are expecting up to 4 main contributors. The charter, initial goal and target date for the signaling design team is introduced below. It also available in the design team wiki page. > > http://trac.tools.ietf.org/wg/anima/trac/wiki/Signaling > > Because of the intended design team work, we expect that the design team members would need to spend at least half a day per week on this project for maybe 4..6 month, but it should become less afterwards. We would like to limit the design team to one year (or shorter if the goals are reached faster of course). > > As WG chairs we will participate and help of course in the design team primarily for logistics. In principle, the design team discussions should be open for all ANIMA participators. People who is interested, but do not have enough time to commit, could also be able to participate and make contributions or comments. > > This call is last for one week. It ends May 3rd, Sunday. Please reply before it if you are interested in the commitment. > > Charter for the signaling design team > > The Anima WG charter states a requirement for discovery and negotiation mechanisms to enable closed-loop interaction between autonomic nodes. It also states the goal of developing one or more protocol specifications (or extensions to existing protocols) to achieve these goals. There is an existing draft requirements analysis, whose main points include > > - support for any type of network objective parameter; > - discovery must support any topology and bootstrap scenario; > - synchronize parameters with other nodes individually or by flooding; > - negotiate parameters with other nodes; > - always secure. > > A simple TLV format is proposed for the protocol design. Binary or name-based discovery are proposed as alternative discovery approaches. > > The purpose of the design team is to analyze these issues and recommend a combined approach to the working group, preferably in the form of one draft or a small set of coordinated drafts. The proposed approach should be suitable for use by the Autonomic Control Plane, and for other use cases including those listed in the Anima WG charter. > > In preparing the recommendation, the design team will verify and update the existing requirements and understand the relevant use cases. However, documenting and solving use cases is out of scope for the design team. The design team is encouraged to develop protocol walkthroughs and an abstract API as aids to understanding. The design team is not itself expected to produce code, but ease of implementation is an important consideration. > > The draft(s) should be delivered by the July 2015 IETF (2015-07-06 cutoff date). > > Initial Goals > > - Validate and update the existing list of requirements (​http://tools.ietf.org/html/draft-carpenter-anima-gdn-protocol#section-2) against bootstrap and ACP drafts (and optionally against other use case validation drafts). Target date: end May. > - Recommend how the other milestone components of ANIMA (bootstrap, ACP, validation drafts) should use the signaling protocol(s). As a side-effect, critique the proposal on the table (​https://tools.ietf.org/html/draft-carpenter-anima-gdn-protocol#section-3). > > Target date: mid June. > > Best regards, > > Toerless + Sheng > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- Bien cordialement, Best regards, *Laurent Ciavaglia* Secure Cloud Networking Bell Labs | Alcatel Lucent phone: +33 160 402 636 email: laurent.ciavaglia@alcatel-lucent.com linkedin: laurentciavaglia address: Route de Villejust | 91620 Nozay | France --------------000603090604040801080605 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit Dear Sheng, all,

I would like to volunteer for the ANIMA signaling design team.
However, the mission statement (as described below) is not fully clear to me, thus I would suggest we (ANIMA WG) spend some cycles to clarify the mission, the objectives and relationship with other components / work items of ANIMA.

Thanks, best regards, Laurent.


On 27/04/2015 12:02, Sheng Jiang wrote:
Hi, all,

We are calling for volunteers to form a design time for ANIMA signaling design team. The chairs has assigned two editors (Brian Carpenter and Bing Liu), we are expecting up to 4 main contributors. The charter, initial goal and target date for the signaling design team is introduced below. It also available in the design team wiki page.

http://trac.tools.ietf.org/wg/anima/trac/wiki/Signaling

Because of the intended design team work, we expect that the design team members would need to spend at least half a day per week on this project for maybe 4..6 month, but it should become less afterwards. We would like to limit the design team to one year (or shorter if the goals are reached faster of course).

As WG chairs we will participate and help of course in the design team primarily for logistics. In principle, the design team discussions should be open for all ANIMA participators. People who is interested, but do not have enough time to commit, could also be able to participate and make contributions or comments.

This call is last for one week. It ends May 3rd, Sunday. Please reply before it if you are interested in the commitment.

Charter for the signaling design team

The Anima WG charter states a requirement for discovery and negotiation mechanisms to enable closed-loop interaction between autonomic nodes. It also states the goal of developing one or more protocol specifications (or extensions to existing protocols) to achieve these goals. There is an existing draft requirements analysis, whose main points include

   - support for any type of network objective parameter;
   - discovery must support any topology and bootstrap scenario;
   - synchronize parameters with other nodes individually or by flooding;
   - negotiate parameters with other nodes;
   - always secure.

A simple TLV format is proposed for the protocol design. Binary or name-based discovery are proposed as alternative discovery approaches.

The purpose of the design team is to analyze these issues and recommend a combined approach to the working group, preferably in the form of one draft or a small set of coordinated drafts. The proposed approach should be suitable for use by the Autonomic Control Plane, and for other use cases including those listed in the Anima WG charter.

In preparing the recommendation, the design team will verify and update the existing requirements and understand the relevant use cases. However, documenting and solving use cases is out of scope for the design team. The design team is encouraged to develop protocol walkthroughs and an abstract API as aids to understanding. The design team is not itself expected to produce code, but ease of implementation is an important consideration.

The draft(s) should be delivered by the July 2015 IETF (2015-07-06 cutoff date).

Initial Goals

   - Validate and update the existing list of requirements (​http://tools.ietf.org/html/draft-carpenter-anima-gdn-protocol#section-2) against bootstrap and ACP drafts (and optionally against other use case validation drafts). Target date: end May.
   - Recommend how the other milestone components of ANIMA (bootstrap, ACP, validation drafts) should use the signaling protocol(s). As a side-effect, critique the proposal on the table (​https://tools.ietf.org/html/draft-carpenter-anima-gdn-protocol#section-3).

Target date: mid June.

Best regards,

Toerless + Sheng
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

--

Bien cordialement, Best regards,

 

Laurent Ciavaglia

Secure Cloud Networking

Bell Labs | Alcatel Lucent

 

phone: +33 160 402 636

email: laurent.ciavaglia@alcatel-lucent.com

linkedin: laurentciavaglia

address: Route de Villejust | 91620 Nozay | France

--------------000603090604040801080605-- From nobody Thu Apr 30 13:07:45 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C21301A8A56 for ; Thu, 30 Apr 2015 13:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MiH6kHfEg6Y for ; Thu, 30 Apr 2015 13:07:41 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A374F1A0181 for ; Thu, 30 Apr 2015 13:07:41 -0700 (PDT) Received: by pdbqa5 with SMTP id qa5so70822347pdb.1 for ; Thu, 30 Apr 2015 13:07:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=sZPOQtrqQ21q93aVUrLHLsdoHvmDAL7vPI66AbTWFfc=; b=kuNt8SU9jfLaBHKID1xa0RI6UE/bEjjx+esMYUUXiYpoSVPru4wh+RCWnmcReGBQ67 hsnInHpxxVRrgAHuGFHb95XHDscmOdk3DxQr9nm7SNGnYHyiNg2pt0zHhRuS6XAWh4YQ 8Ki4ydw8bfl7T4jzVjYA+oXBlnEbfnFOJTzYmzegOu0xw1B1ZJfSiRajvAe1FfztdClV NMz8KIn/06DhDon0MHvgrwB5VPX7AKK+MMXkAjAPrSN2r3kznPIp8iNlcoztrsPMKZAv BEJU8KPxx/0IfmwLT+UrwEG77tGCfOtK1ihonR9llu7c0ZpPAevKX5MI2xLsmv8b5d7X 6RmA== X-Received: by 10.68.185.4 with SMTP id ey4mr11663090pbc.12.1430424461180; Thu, 30 Apr 2015 13:07:41 -0700 (PDT) Received: from ?IPv6:2406:e007:502b:1:28cc:dc4c:9703:6781? ([2406:e007:502b:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id gs7sm2971064pbc.6.2015.04.30.13.07.36 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Apr 2015 13:07:40 -0700 (PDT) Message-ID: <554284A7.9020904@gmail.com> Date: Fri, 01 May 2015 07:38:15 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Laurent Ciavaglia , Sheng Jiang , Anima WG References: <5D36713D8A4E7348A7E10DF7437A4B925F505D45@nkgeml512-mbx.china.huawei.com> <55424114.1010000@alcatel-lucent.com> In-Reply-To: <55424114.1010000@alcatel-lucent.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Toerless Eckert , "Liubing \(Leo\)" , "anima-chairs@tools.ietf.org" Subject: Re: [Anima] Call for Volunteer - ANIMA signaling design team X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 20:07:43 -0000 Laurent, Can you be specific about what is unclear? Can you reduce it to individua= l issues, which we can track at http://trac.tools.ietf.org/wg/anima/trac/wiki/Open%20Issues even before t= he team has officially started? Also - how things fit together is the topic of https://tools.ietf.org/htm= l/draft-behringer-anima-reference-model-01 so maybe that is where we should add explanations. (To be vey specific about my thoughts, the only way to tell whether the p= roposed signaling protocol is adequate is to do what is described in the design team charter: confront it with some of the use ca= ses, as described in the two initial goals.) Regards Brian On 01/05/2015 02:49, Laurent Ciavaglia wrote: > Dear Sheng, all, >=20 > I would like to volunteer for the ANIMA signaling design team. > However, the mission statement (as described below) is not fully clear = to me, thus I would suggest we (ANIMA WG) spend some > cycles to clarify the mission, the objectives and relationship with oth= er components / work items of ANIMA. >=20 > Thanks, best regards, Laurent. >=20 >=20 > On 27/04/2015 12:02, Sheng Jiang wrote: >> Hi, all, >> >> We are calling for volunteers to form a design time for ANIMA signalin= g design team. The chairs has assigned two editors >> (Brian Carpenter and Bing Liu), we are expecting up to 4 main contribu= tors. The charter, initial goal and target date for the >> signaling design team is introduced below. It also available in the de= sign team wiki page. >> >> http://trac.tools.ietf.org/wg/anima/trac/wiki/Signaling >> >> Because of the intended design team work, we expect that the design te= am members would need to spend at least half a day per >> week on this project for maybe 4..6 month, but it should become less a= fterwards. We would like to limit the design team to one >> year (or shorter if the goals are reached faster of course). >> >> As WG chairs we will participate and help of course in the design team= primarily for logistics. In principle, the design team >> discussions should be open for all ANIMA participators. People who is = interested, but do not have enough time to commit, could >> also be able to participate and make contributions or comments. >> >> This call is last for one week. It ends May 3rd, Sunday. Please reply = before it if you are interested in the commitment. >> >> Charter for the signaling design team >> >> The Anima WG charter states a requirement for discovery and negotiatio= n mechanisms to enable closed-loop interaction between >> autonomic nodes. It also states the goal of developing one or more pro= tocol specifications (or extensions to existing >> protocols) to achieve these goals. There is an existing draft requirem= ents analysis, whose main points include >> >> - support for any type of network objective parameter; >> - discovery must support any topology and bootstrap scenario; >> - synchronize parameters with other nodes individually or by flood= ing; >> - negotiate parameters with other nodes; >> - always secure. >> >> A simple TLV format is proposed for the protocol design. Binary or nam= e-based discovery are proposed as alternative discovery >> approaches. >> >> The purpose of the design team is to analyze these issues and recommen= d a combined approach to the working group, preferably >> in the form of one draft or a small set of coordinated drafts. The pro= posed approach should be suitable for use by the >> Autonomic Control Plane, and for other use cases including those liste= d in the Anima WG charter. >> >> In preparing the recommendation, the design team will verify and updat= e the existing requirements and understand the relevant >> use cases. However, documenting and solving use cases is out of scope = for the design team. The design team is encouraged to >> develop protocol walkthroughs and an abstract API as aids to understan= ding. The design team is not itself expected to produce >> code, but ease of implementation is an important consideration. >> >> The draft(s) should be delivered by the July 2015 IETF (2015-07-06 cut= off date). >> >> Initial Goals >> >> - Validate and update the existing list of requirements (=E2=80=8B= >> http://tools.ietf.org/html/draft-carpenter-anima-gdn-protocol#section-= 2) against bootstrap and ACP drafts (and optionally >> against other use case validation drafts). Target date: end May. >> - Recommend how the other milestone components of ANIMA (bootstrap= , ACP, validation drafts) should use the signaling >> protocol(s). As a side-effect, critique the proposal on the table (=E2= =80=8B >> https://tools.ietf.org/html/draft-carpenter-anima-gdn-protocol#section= -3). >> >> Target date: mid June. >> >> Best regards, >> >> Toerless + Sheng >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >=20 >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20