From nobody Sun Mar 1 14:28:36 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 571BC1A1BCD for ; Sun, 1 Mar 2015 14:28:35 -0800 (PST) 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_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_34=0.6, 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 Y6bueIyXMbwr for ; Sun, 1 Mar 2015 14:28:33 -0800 (PST) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::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 764C81A0024 for ; Sun, 1 Mar 2015 14:28:33 -0800 (PST) Received: by padbj1 with SMTP id bj1so12461535pad.11 for ; Sun, 01 Mar 2015 14:28:32 -0800 (PST) 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=6t8VCSOyTROIAZB4qYuqNn1qGQ3yiScSICr+UMVB6d4=; b=w8PE3uYVZYunU0Hvi0XLaX+xcG/3CqGkRl3O+VVhE+pLDJuXjiJER4ncpDZVdHz7t3 lyFPofkCF8K/98iYDaO+D3w5N0xmb/FD1UeXh6L2xZK2vhp9TyDXJJLYLh4QtMno1Q6R maHnbiuRqwo0/PSxKgCBkE98v0MddVhHAK3FZFXY8ei2bYkZsrABtF6aPlejyZwtMrjb vRwj2BRrdIWkCjeUoKNW6VxinEpUo9dqeRRaNVO+DAd7kp+hg+2rOCBx1+U5fAzwuqh7 sQjPlqesXD+1bIpS5TNrk7kFTd9sqFy7Az/irJyhjk5jZnbsCDk2lfTmnO8dfyebBFC5 oySw== X-Received: by 10.66.169.137 with SMTP id ae9mr37507560pac.7.1425248912723; Sun, 01 Mar 2015 14:28:32 -0800 (PST) Received: from ?IPv6:2406:e007:5ef9:1:28cc:dc4c:9703:6781? ([2406:e007:5ef9:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id a1sm4336816pdk.16.2015.03.01.14.28.13 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Mar 2015 14:28:14 -0800 (PST) Message-ID: <54F3927C.202@gmail.com> Date: Mon, 02 Mar 2015 11:28:12 +1300 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.5.0 MIME-Version: 1.0 To: Anima WG References: <20150220084151.13713.88982.idtracker@ietfa.amsl.com> In-Reply-To: <20150220084151.13713.88982.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Comments on draft-behringer-anima-autonomic-control-plane-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: Sun, 01 Mar 2015 22:28:35 -0000 Hi, I went through this more carefully than the previous version, so I have a number of questions and comments: > 1. Introduction ... > The Autonomic Control Plane serves several purposes: It would be useful to state explicitly that these purposes can co-exist. ... > The ACP therefore supports directly Autonomic Networking functions, > as described in [I-D.behringer-anima-reference-model]. ... and it can, for example, directly carry GDNP traffic. > 2. Problem Statement > > An "Autonomic Control Plane" (ACP) provides a solution to some of > today's operational challenges. These fall into three broad > categories: > > o Bootstrapping a network while devices are not yet configured. > Bootstrapping a new device typically requires all devices between > the controller and the new device to be completely and correctly > addressed, configured and secured. Therefore, bootstrapping a > network happens in layers around the controller. This bullet has a strong SDN flavour due to the word "controller". While SDN is certainly a valid use case, I'm not sure we want to emphasise it here. I think there are a couple of missing problems at the end of this section: o Running an autonomic networking protocol such as GDNP when the rest of the network apart from the ACP is out of order. o Need for a stable substrate for management traffic when the network as a whole is variable due to dynamic virtualization of any kind. > 3.3. Authenticating Neighbors ... > Authentication could be a function of a generic Adjacency Discovery > protocol, for example the "Generic Discovery and Negotiation > Protocol" GDNP described in [I-D.carpenter-anima-gdn-protocol]. I'm not sure about that statement, on reflection. It's certainly on the table to leave authentication to a secure transport layer. > 3.5. Channel Establishment > > After authentication and capability negotiation autonomic nodes > establish a secure channel towards their direct AN neighbors with > the above negotiated parameters. In order to be independent of > configured link addresses, these channels can be implemented in > several ways: > > o As a secure IP tunnel (e.g., IPsec, DTLS, etc.) I would like TLS to be listed too. UDP+DTLS is a fairly complex beast with startup costs and MTU issues, and I think we seriously need to consider TLS instead. ... > Since channels are established between adjacent neighbors, the > resulting overlay network does hop by hop encryption. Each node > decrypts incoming traffic from the ACP, and encrypts outgoing traffic > to its neighbors in the ACP. Routing is discussed in Section 3.8. I have several issues here (and the routing discussion doesn't solve them). 1. It's well understood that we need a link-local mode because of bootstrapping, fault conditions, etc. But... 2. When distant nodes need to communicate, that simply doesn't work, which is why we give them ULAs and need a routing protocol. 3. So there is something missing in your description. How does a packet from Node A, which isn't a router, get to Node B, which isn't a router, on some other link? 4. In a large network I expect the ACP to be reasonably busy. So hop by hop encryption and decryption seems like an unreasonable overhead. Certainly in GDNP we are assuming normal layer 3 end-to-end connectivity between Node A and Node B, with e2e security. > 3.7. Addressing in the ACP > > The channels explained above only establish communication between two > adjacent neighbors. In order for the communication to happen across > multiple hops, the autonomic control plane requires internal network > wide valid addresses and routing. Each autonomic node must create a > loop back interface with a network wide unique address inside the ACP > context mentioned in Section 3.6. The second sentence is actually in contradiction with what I just quoted from section 3.5. But I agree with it. However, on the third sentence and its implications you lose me. Why would you do something as bizarre as inventing a fictitious interface instead of deploying a ULA prefix across the ACP? (I must have read the previous version carelessly not to spot this.) Making the Global ID of the ULA prefix a hash of the domain ID is a fine idea. But I would much prefer the subnet prefixes to be real ones without the consequent risk of clashes, and conventional RAs and SLAAC within the ACP on each link. The interface IDs should probably follow draft-ietf-6man-default-iids. > 3.8. Routing in the ACP > > Once ULA address are set up all autonomic entities should run a > routing protocol within the autonomic control plane context. I don't like that. I don't think that nodes which aren't already routers should be obliged to run a routing protocol. Please remember that in a large carrier network you might easily be asking for 100000 nodes to operate a routing protocol. It just isn't necessary; the ACP nodes that happen to be routers can do this. ... > The routing protocol inside the ACP should be light weight and highly > scalable to ensure that the ACP does not become a limiting factor in > network scalability. We suggest the use of RPL as one such protocol > which is light weight and scales well for the control plane traffic. I think it's way too soon to select a protocol. For now we can sit back and watch the homenet debate, but the scaling issues are very different. My gut feeling is that different types of autonomic network will need different solutions. > 3.9. Connecting a Controller / NMS system Doesn't this section overlap with draft-eckert-anima-stable-connectivity? > 4. Self-Healing Properties ... > o If an existing device gets revoked, it will automatically be > denied access to the ACP as its domain certificate will be validated > against a Certificate Revocation List during authentication. Excuse my ignorance, but will that instantly kill any open IPsec, TLS or DTLS associations? ... > After a network partition, a merge will just establish the previous > status, Nit: s/merge/re-merge/ to make the context clear. > 5. Self-Protection Properties ... > The ULA addresses are only reachable inside the ACP context, > therefore unreachable from the data plane. Nit: 'data plane' is a bit vague IMHO. I think it would more precise to say: As long as there is no leakage from the ACP routing protocol, the ULA addresses are only reachable inside the ACP context, therefore unreachable from the user environment or any external point of attack. > 6. Use Cases for the ACP Hmm. To me, this section seems completely redundant with Section 2. Regards Brian Carpenter From nobody Sun Mar 1 17:22: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 7DF9E1A8A1A; Fri, 20 Feb 2015 04:12:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RZQtkP3iS4Wv; Fri, 20 Feb 2015 04:12:19 -0800 (PST) Received: from mailscan1.extendcp.co.uk (mailscan34.extendcp.co.uk [79.170.42.6]) (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 7E69A1A6F3D; Fri, 20 Feb 2015 03:59:36 -0800 (PST) Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mailscan2.extendcp.co.uk) by mailscan-g75.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1YOmF4-0002ma-N3; Fri, 20 Feb 2015 11:59:34 +0000 Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mail41.extendcp.co.uk) by mailscan2.extendcp.co.uk with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1YOmF2-0008EX-Ag; Fri, 20 Feb 2015 11:59:34 +0000 Received: from host86-171-66-135.range86-171.btcentralplus.com ([86.171.66.135] helo=[192.168.0.6]) by mail41.extendcp.com with esmtpsa (UNKNOWN:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1YOmEx-0005Ur-B4; Fri, 20 Feb 2015 11:59:28 +0000 Message-ID: <54E7219B.6040006@gridmerge.com> Date: Fri, 20 Feb 2015 11:59:23 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Hedanping (Ana)" , Michael Richardson References: <77FA386512F0D748BC7C02C36EB1106D921776@szxeml557-mbs.china.huawei.com> <6426.1422664463@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com> In-Reply-To: <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050800090303060805030500" X-Authenticated-As: robert.cragie@gridmerge.com X-Extend-Src: mailout Archived-At: X-Mailman-Approved-At: Sun, 01 Mar 2015 17:22:38 -0800 Cc: "anima@ietf.org" , "6tisch-security@ietf.org" <6tisch-security@ietf.org>, "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Anima] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things 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: Fri, 20 Feb 2015 12:12:24 -0000 This is a cryptographically signed message in MIME format. --------------ms050800090303060805030500 Content-Type: multipart/alternative; boundary="------------050601010308030707080601" This is a multi-part message in MIME format. --------------050601010308030707080601 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi Danping, I have some general comments on the draft and some additional comments=20 inline, bracketed by General comments: I think the general model is good but could be simplified to two cases: 1) Where the authenticator is in direct communication 2) Where the authenticator is not in direct communication (relay case) My reasoning is because: a) There isn't much distinction between RFD and FFD from an=20 authentication perspective b) There isn't much distinction between joining an existing network and=20 initial joining If you think there are distinctions, then they need clarifying. Other points: * "Because IEEE 802.15.4 maximum payload size is 128 Bytes, a standard security bootstrapping protocol should be light-weight with low complexity.": I think it would be better to say "should ideally be light-weight with low complexity". There may be requirements where high security strength is required and therefore this will necessarily involve more communication overhead and processing. * I think the hierarchical joining description is generally useful. * It is conceivable for an RFD to communicate directly with a 6LBR so I don't think that should be excluded from Figure 1 * "[I-D.pritikin-anima-bootstrapping-keyinfra] proposes a zero-touch bootstrapping key infrastructure to allow joining device securely and automatically bootstraps itself based on 802.1AR certificate.=20 It can't be directly used in 802.15.4 devices due to the high security complexity and heavy communication overhead.": I disagree with this statement. We used this approach in ZigBee IP. I agree some may think the communication overhead "heavy" but that doesn't mean it can't be done. The associated security complexity is also becoming less onerous as crypto accelerators become built into hardware and cores. * The document mentions a couple of protocols (EAP and PANA) but doesn't go into enough detail on how those are deployed. Also, there are other choices. The document could give generic names to the particular communications and then add a section to give examples. Robert On 02/02/2015 08:13, Hedanping (Ana) wrote: > Hi Michael, > Thank you for the interest and the questions are illuminating. Please s= ee my reply inline. > > > I have added a number of CCs, I think that this fits into ANIMA best= =2E > > > > > Hedanping (Ana) wrote: > > > A new draft is submitted, it's about the security bootstrappin= g > > > architecture and methods for IoT networks that implement IETF > > protocols > > > (e.g. 6LoWPAN, 6lo, RPL, AODV, DSR) over IEEE 802.15.4. > > > Two types of bootstrapping methods are developed: network leve= l > > > bootstrapping and joining device level bootstrapping > > > > > The link is: > > > http://tools.ietf.org/html/draft-he-iot-security-bootstrapping= -00 > > > > I read the document with great interest. > > I found that you explained the incremental boot-strapping process qu= ite well, > > and nobody has clearly articulated the process yet. People have jus= t assumed > > that everyone knows this process, but really it needs to get written= down, so I > > thank you for doing that. > > Thank you for the praise. As it is the initial version, more discussion= s and comments are needed to make it better. I agree that it has not generally been articulated well. To some=20 extent, it is because up to now, there has been no "the one way to do=20 it". Therefore, something ZigBee IP is a profile which defines one=20 particular way of doing it. There are other ways as well, of course. I=20 guess the question is whether it can be generalised sufficiently to be=20 generally applicable and whether that is in fact worth doing > > > > > Given that: > > > > Because IEEE 802.15.4 maximum payload size is 128 Bytes, a standa= rd > > security bootstrapping protocol should be light-weight with low > > complexity. The protocol must allow for commissioning of devices= > > > > I was surprised that the draft then suggested EAP with PANA as a tra= nsport: I realise that PANA/EAP/EAP-TLS gets roundly criticised for being=20 "heavyweight". Indeed, there are overheads in the use of these three=20 very well-established protocols which could be removed in certain cases. = However, this would result in the development of new protocols. Having=20 done a lot of work in looking at DTLS options, I can confidently say=20 that the difference at the end of the day is quite small > > > > If EAP is used, PANA can be used to relay the authentication mess= age > > from configured FFDs to 6LBR. If the validation is successful, t= he > > IP address and network key are generated and delivered to the FFD= =2E > > > > But, EAP-TLS with PANA is exactly what the Zigbee IP specification h= as specified. > > Do you envision any changes from that specification? > > Zigbee IP specification was developed to enable IP address for Zigbee a= pplication, thus the protocol stack are built on IETF's standards, includ= ing EAP-TLS. > As discussed in many working groups, TLS might result in a significant = amount of retransmissions due to unreliable communication capability of t= he network and device, thus energy will be consumed fast. > I think EAP over DTLS /profiled DTLS could be a good option. EAP-TLS only uses TLS handshakes carried as EAP payloads, therefore = has little to do with TLS as it is normally used, i.e. over TCP. If you=20 then start to look at the difference between EAP-TLS (over UDP) and DTLS = handshakes over UDP, there is actually not much difference. In some=20 areas, EAP is actually preferable (fragmentation and header overhead) > > > A minority of people had prefered this mechanism for 6tisch-security= , but > > none stepped forward to write up that mechanism. Perhaps this draf= t could > > fulfill that need? > > Yes, we should describe more clearly on this mechanism, and maybe this = draft is a right place. It would be great if folks in the mailing list ma= ke comments and contribution on this technical point. I am happy to write up that mechanism > > > You write that the IP address would be generated; usually that occur= s via > > distribution of PIOs via ND (router-adveristments) or RPL. Were you= going to > > suggest something else here? > > According to my knowledge, IP address can be generated once a device is= authenticated to network access, afterwards, other further protocols can= use IP to communicate. > Besides, PANA needs IP as well. The incremental bootstrapping takes adv= antage of such IP address generation mechanism, so that PANA can be run w= ithout any problem. ZigBee IP solved this problem by using SLAAC IPv6 addresses based=20 on the EUI-64. These can be used in PANA straight away without the need=20 for any other configuration > =20 > > > From the ANIMA and 6tisch-security point of view, my view is that th= is is all > > about the choice of certificates for the TLS setup. Do you have any= view on > > how that might work? > > For unconstrained environment, I agree with you. But when it comes to c= onstrained device and constrained network communication, TLS might not be= a good choice as mentioned before. Certificate is not a good choice eith= er due to the high cost. > I would like to say: it is about the choice of credential type for secu= re channel setup. The good candidates of credential types are Raw public = key, Physical Unclonable Function (PUF). There certainly are overheads in certificates but in the 802.1AR=20 scenario (draft-pritikin-anima-bootstrapping-keyinfra-01) it has clear=20 value. > > > > > The 6tisch-security bootstrap process aims to create a > > YANG/CBOR-over-CoAP-over-DTLS session between a Join Coordinator and= the > > Joining Node: over that management link, security (and timeslot sche= duling) > > would be provisioned. > > CoAP-DTLS coincides with my idea. > Yang sounds like at a higher level, but I think EAP is actually the mec= hanism running behind ^_^ Again, in this document, it might be better to abstract this=20 session and describe what it is used for > > > Regards, > Ana > > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo > --------------050601010308030707080601 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Danping,

I have some general comments on the draft and some additional comments inline, bracketed by <RCC></RCC>

General comments:

I think the general model is good but could be simplified to two cases:

1) Where the authenticator is in direct communication
2) Where the authenticator is not in direct communication (relay case)

My reasoning is because:

a) There isn't much distinction between RFD and FFD from an authentication perspective
b) There isn't much distinction between joining an existing network and initial joining

If you think there are distinctions, then they need clarifying.

Other points:

  • "Because IEEE 802.15.4 maximum payload size is 128 Bytes, a standard security bootstrapping protocol should be light-weight with low complexity.": I think it would be better to say "should ideally be light-weight with low complexity". There may be requirements where high security strength is required and therefore this will necessarily involve more communication overhead and processing.
  • I think the hierarchical joining description is generally useful.
  • It is conceivable for an RFD to communicate directly with a 6LBR so I don't think that should be excluded from Figure 1
  • "[I-D.pritikin-anima-bootstrapping-keyinfra] proposes a zero-touch bootstrapping key infrastructure to allow joining device securely and automatically bootstraps itself based on 802.1AR certificate.=A0 It can't be directly used in 802.15.4 devices due to the high security complexity and heavy communication overhead.": I disagree with this statement. We used this approach in ZigBee IP. I agree some may think the communication overhead "heavy" but that doesn't mean it can't be done. The associated security complexity is also becoming less onerous as crypto accelerators become built into hardware and cores.
  • The document mentions a couple of protocols (EAP and PANA) but doesn't go into enough detail on how those are deployed. Also, there are other choices. The document could give generic names to the particular communications and then add a section to give examples.
Robert

On 02/02/2015 08:13, Hedanping (Ana) wrote:
Hi Michael,
Thank you for the interest and the questions are illuminating. Please see=
 my reply inline.

	> I have added a number of CCs, I think that this fits into ANIMA bes=
t.
	>=20

	> Hedanping (Ana) <ana.hedanping@huawei.com> wrote:
	>     > A new draft is submitted, it's about the security bootstra=
pping
	>     > architecture and methods for IoT networks that implement I=
ETF
	> protocols
	>     > (e.g. 6LoWPAN, 6lo, RPL, AODV, DSR) over IEEE 802.15.4.
	>     > Two types of bootstrapping methods are developed: network =
level
	>     > bootstrapping and joining device level bootstrapping
	>=20
	>     > The link is:
	>     > http://tools.ietf.org=
/html/draft-he-iot-security-bootstrapping-00
	>=20
	> I read the document with great interest.
	> I found that you explained the incremental boot-strapping process q=
uite well,
	> and nobody has clearly articulated the process yet.  People have ju=
st assumed
	> that everyone knows this process, but really it needs to get writte=
n down, so I
	> thank you for doing that.

Thank you for the praise. As it is the initial version, more discussions =
and comments are needed to make it better.
<RCC>I agree that it has not generally been articulated well. To some extent, it is because up to now, there has been no "the one way to do it". Therefore, something ZigBee IP is a profile which defines one particular way of doing it. There are other ways as well, of course. I guess the question is whether it can be generalised sufficiently to be generally applicable and whether that is in fact worth doing</RCC>

	>=20
	> Given that:
	>=20
	>    Because IEEE 802.15.4 maximum payload size is 128 Bytes, a stand=
ard
	>    security bootstrapping protocol should be light-weight with low
	>    complexity.  The protocol must allow for commissioning of device=
s
	>=20
	> I was surprised that the draft then suggested EAP with PANA as a tr=
ansport:
<RCC>I realise that PANA/EAP/EAP-TLS gets roundly criticised for being "heavyweight". Indeed, there are overheads in the use of these three very well-established protocols which could be removed in certain cases. However, this would result in the development of new protocols. Having done a lot of work in looking at DTLS options, I can confidently say that the difference at the end of the day is quite small</RCC>
	>=20
	>    If EAP is used, PANA can be used to relay the authentication mes=
sage
	>    from configured FFDs to 6LBR.  If the validation is successful, =
the
	>    IP address and network key are generated and delivered to the FF=
D.
	>=20
	> But, EAP-TLS with PANA is exactly what the Zigbee IP specification =
has specified.
	> Do you envision any changes from that specification?

Zigbee IP specification was developed to enable IP address for Zigbee app=
lication, thus the protocol stack are built on IETF's standards, includin=
g EAP-TLS.=20
As discussed in many working groups, TLS might result in a significant am=
ount of retransmissions due to unreliable communication capability of the=
 network and device, thus energy will be consumed fast.
I think EAP over DTLS /profiled DTLS could be a good option.
<RCC>EAP-TLS only uses TLS handshakes carried as EAP payloads, therefore has little to do with TLS as it is normally used, i.e. over TCP. If you then start to look at the difference between EAP-TLS (over UDP) and DTLS handshakes over UDP, there is actually not much difference. In some areas, EAP is actually preferable (fragmentation and header overhead)</RCC>

	> A minority of people had prefered this mechanism for 6tisch-securit=
y, but
	> none stepped forward to write up that mechanism.   Perhaps this dra=
ft could
	> fulfill that need?

Yes, we should describe more clearly on this mechanism, and maybe this dr=
aft is a right place. It would be great if folks in the mailing list make=
 comments and contribution on this technical point.
<RCC>I am happy to write up that mechanism</RCC>

	> You write that the IP address would be generated; usually that occu=
rs via
	> distribution of PIOs via ND (router-adveristments) or RPL.  Were yo=
u going to
	> suggest something else here?

According to my knowledge, IP address can be generated once a device is a=
uthenticated to network access, afterwards, other further protocols can u=
se IP to communicate.=20
Besides, PANA needs IP as well. The incremental bootstrapping takes advan=
tage of such IP address generation mechanism, so that PANA can be run wit=
hout any problem.
<RCC>ZigBee IP solved this problem by using SLAAC IPv6 addresses based on the EUI-64. These can be used in PANA straight away without the need for any other configuration</RCC>
 =20

	> From the ANIMA and 6tisch-security point of view, my view is that t=
his is all
	> about the choice of certificates for the TLS setup.  Do you have an=
y view on
	> how that might work?

For unconstrained environment, I agree with you. But when it comes to con=
strained device and constrained network communication, TLS might not be a=
 good choice as mentioned before. Certificate is not a good choice either=
 due to the high cost.=20
I would like to say: it is about the choice of credential type for secure=
 channel setup. The good candidates of credential types are Raw public ke=
y, Physical Unclonable Function (PUF).
<RCC>There certainly are overheads in certificates but in the 802.1AR scenario (draft-pritikin-anima-bootstrapping-keyinfra-01) it has clear value.</RCC>

	>=20
	> The 6tisch-security bootstrap process aims to create a
	> YANG/CBOR-over-CoAP-over-DTLS session between a Join Coordinator an=
d the
	> Joining Node: over that management link, security (and timeslot sch=
eduling)
	> would be provisioned.

CoAP-DTLS coincides with my idea.
Yang sounds like at a higher level, but I think EAP is actually the mecha=
nism running behind ^_^
<RCC>Again, in this document, it might be better to abstract this session and describe what it is used for</RCC>


Regards,
Ana

_______________________________________________
6lo mailing list
6lo@ie=
tf.org
https://www.ietf.org/mailman/listinfo/6lo

--------------050601010308030707080601-- --------------ms050800090303060805030500 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 Fw0xNTAyMjAxMTU5MjNaMCMGCSqGSIb3DQEJBDEWBBSkwnacLig9x1g2LdxfgFLiEn6PNjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG+BgkrBgEEAYI3EAQxgbAwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhEAkJNVgmy0T3j/sFnejfTMyTCBwAYLKoZIhvcNAQkQAgsxgbCgga0w gZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8g UlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkJNVgmy0 T3j/sFnejfTMyTANBgkqhkiG9w0BAQEFAASCAQA3+lWPT8cwem8tujuK0tJ8hDdQvhohWR/b DG7ssVPkLyK8OETtkiKDzuBAL4Ux2Yxcujb7fPW90sxptw1sZnGSdon8DmufweaD1670SxVR nST0pRHSbMZ1COjdUF2xnYPFVyrtidfYPK7MwAmAJ2WC+OdBoLmIiBYOrZteOcq9MoRdIJl0 v21rDG/e+CMiLACwwOeNjOHCZ52RHI3k5O40Gm1tW9tOKdYiyhU2E55BmKtmUoCxcW1vuQLX kl9pmFEwMyNtoQmNKaXF36taabYQb/HByugM2Fqnq+7qtxTOU0EDlrCdaneZEJqy4BWvUSCX N57tj0QIJcZJQMpd10dxAAAAAAAA --------------ms050800090303060805030500-- From nobody Sun Mar 1 17:22: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 DA6901A1B0D; Thu, 26 Feb 2015 09:47:24 -0800 (PST) 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 dpmSOeoRrfm6; Thu, 26 Feb 2015 09:47:23 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 298121A1E0B; Thu, 26 Feb 2015 09:47:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=402; q=dns/txt; s=iport; t=1424972843; x=1426182443; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=/Eu8m4YI91vvqX+8PqyJZzQEt76vvV/isISZFtXlFjU=; b=Pk02cKVjD2Rxyy4xFRReyvn9aHhaCJietTA9ZIQjpX6wfgzbY0ocPKQC Bt/GGhwi2uiJFoy8d364L5/rdsn+YuEfrCjFiYQeuerVV+cdKVUic6hL+ XLnVJZ4e8W6iFlMwTeZS06/N1/eZjt4iUVOuGYeE4zgWJMd1nxfwdNUDc Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BXBQA0W+9U/xbLJq1bg1RavBCFeYVuAoFxAQEBAQEBfIQQAQECAjhAARALGAkWBAsJAwIBAgFFBgEMAQcBAYgrDcQHkxMBAQEBAQEBAQEBAQEBAQEBAQEBARiLE4RuB4QrAQSKWI5chmmMYCOCAhwUgVogMQGCQgEBAQ X-IronPort-AV: E=Sophos;i="5.09,653,1418083200"; d="scan'208";a="357426570" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 26 Feb 2015 17:47:21 +0000 Received: from [10.131.65.104] (dhcp-10-131-65-104.cisco.com [10.131.65.104]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t1QHlKVB017860; Thu, 26 Feb 2015 17:47:20 GMT Message-ID: <54EF5C27.1040400@cisco.com> Date: Thu, 26 Feb 2015 12:47:19 -0500 From: Paul Duffy Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Hannes Tschofenig , Brian E Carpenter , consultancy@vanderstok.org References: <77FA386512F0D748BC7C02C36EB1106D921776@szxeml557-mbs.china.huawei.com> <6426.1422664463@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com> <54E7219B.6040006@gridmerge.com> <54E72846.20807@gmx.net> <54E7824A.4040906@gmail.com> <54E86F9A.8020104@gmx.net> <54E8D442.6020909@gmail.com> <54EB4F24.7030609@gmx.net> In-Reply-To: <54EB4F24.7030609@gmx.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Sun, 01 Mar 2015 17:22:38 -0800 Cc: Michael Richardson , "Hedanping \(Ana\)" , anima@ietf.org, 6tisch-security@ietf.org, robert.cragie@gridmerge.com Subject: Re: [Anima] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: paduffy@cisco.com List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 17:47:25 -0000 On 2/23/2015 11:02 AM, Hannes Tschofenig wrote: >> At least draft-pritikin-anima-bootstrapping-keyinfra builds pn >> IEEE 802.1AR. > To be honest, I am a bit doubtful about the value of the IEEE 802.1AR > specification. > > "Cisco Connected Grid Security for Field Area Network" http://www.cisco.com/web/strategy/docs/energy/C11-696279-00_cgs_fan_white_paper.pdf Page 3 Cheers From nobody Sun Mar 1 17:22: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 88A951A88BF for ; Thu, 26 Feb 2015 14:32:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 lRDfKIvTCOn8 for ; Thu, 26 Feb 2015 14:31:59 -0800 (PST) Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com [209.85.192.180]) (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 419491A8877 for ; Thu, 26 Feb 2015 14:31:59 -0800 (PST) Received: by pdjz10 with SMTP id z10so16147892pdj.12 for ; Thu, 26 Feb 2015 14:31:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=HUzJsfaOYNjZOzkrJsLQ9nWA68bfmeASgy6Widc4vh8=; b=dsJArnVIKpFh2JZwQ99WZm8p4z43NHIzR0WhxGutsLYuzb5NKBH2XyhBniEwwmLOgN PBIq8HMHW0QpO9oIbwblRjehc4JlNOteokCN5DIzw1CNH44UMX1BNLsJiC7pd82nbMJB gRaFahmS8ro8/91dessaKvn3d83eDT52ZAnprte/QwNiATklq/Mot27Sxv7oNfsEaToc RiJd3GW/PWX0F0MmE/5PMWsfZYIDHOxIJ0wadWG6Zx7rRedjgFjoZkVf/Xdvuq+xgd8t KMxMQfCnMSUGZqjC/OrvKRVYBaF1L43LV5RE9g93FYDTgq1CyzrLC+3zQMOkfNqqw7Bl Y+ww== X-Gm-Message-State: ALoCoQnLkChVBpWr89QV1mHrDIj2gjqkpqI4CuHUKFU5aPseSzZkKJWO7heB456sr8Cnq+Piqdco X-Received: by 10.68.206.72 with SMTP id lm8mr18473518pbc.15.1424989918900; Thu, 26 Feb 2015 14:31:58 -0800 (PST) Received: from [10.70.48.35] ([207.140.31.138]) by mx.google.com with ESMTPSA id ny1sm1914368pbb.77.2015.02.26.14.31.57 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Feb 2015 14:31:58 -0800 (PST) Message-ID: <54EF9EDF.2090508@berkeley.edu> Date: Thu, 26 Feb 2015 14:31:59 -0800 From: Kris Pister User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Brian E Carpenter , "Hedanping (Ana)" , "robert.cragie@gridmerge.com" , Michael Richardson , Behcet Sarikaya References: <77FA386512F0D748BC7C02C36EB1106D92F855@szxeml557-mbs.china.huawei.com> <77FA386512F0D748BC7C02C36EB1106D92F887@szxeml557-mbs.china.huawei.com> <54EE1D2E.5040707@gmail.com> <77FA386512F0D748BC7C02C36EB1106D92FAEF@szxeml557-mbs.china.huawei.com> <54EF72BF.3070603@gmail.com> In-Reply-To: <54EF72BF.3070603@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Sun, 01 Mar 2015 17:22:38 -0800 Cc: "6tisch-security@ietf.org" <6tisch-security@ietf.org>, "anima@ietf.org" , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Anima] [6tisch-security] [6lo] Device vs network bootstrapping [Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things] 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, 26 Feb 2015 22:32:01 -0000 Brian - > What we need is a generic solution that doesn't care about which L2 > technology is involved, because we are trying to establish trust at > a level above L3 routing. This is a fine goal, and it may be exactly what 6lo or some other group should be working on, but I think that it is out of scope for 6tisch. What we need to do is figure out who to trust to configure a very specific L2, with very specific constraints. If we can leverage other more general work that's great, but the constraints of 4e/TSCH are likely to push 6top-configuration trust in a different direction. ksjp On 2/26/2015 11:23 AM, Brian E Carpenter wrote: > Below... > > On 26/02/2015 19:18, Hedanping (Ana) wrote: >> Hi Brian, >> Please see my reply inline. >> >> > -----Original Message----- >> > From: 6lo [mailto:6lo-bounces@ietf.org] On Behalf Of Brian E Carpenter >> > Sent: Thursday, February 26, 2015 3:06 AM >> > To: Hedanping (Ana); robert.cragie@gridmerge.com; Michael Richardson; >> > Behcet Sarikaya >> > Cc: 6tisch-security@ietf.org; anima@ietf.org; 6lo@ietf.org >> > Subject: [6lo] Device vs network bootstrapping [Comments needed for Security >> > Bootstrapping of IEEE 802.15.4 based Internet of Things] >> > >> > Hi, >> > >> > On 26/02/2015 03:48, Hedanping (Ana) wrote: >> > ... >> > > IMHO, there are distinctions between the network level bootstrapping >> > > and joining device level bootstrapping. Network level bootstrapping >> > > includes at least two cases: network start-up case and >> > > re-commissioning case. The bootstrapping network level bootstrapping >> > > request should be different from that of joining device level request >> > > in order to converge efficiently. I agree that they need to be clarified. >> > >> > How does a device that has just been switched on know whether it is joining >> > an existing network or is simply one of many devices that are attempting to >> > form a new network? >> > >> The device can learn from its neighbors about the network state. For instance, from the bits indicating network ID and device type in hello/beaconing message, the device knows whether a neighbor belongs to an existing network or it is a 'new' device as well, and whether the neighbor has ability to forward/verify authentication message. >> >> > How does a set of devices that are attempting to form a new network know >> > that they are re-commissioning a previously existing network? >> > >> Again, the state can be learnt by exchanging the network ID that devices belonged to >> >> > The only safe assumption seem to be that devices cannot know these things. >> > Autonomic devices have no state at power-on. >> > >> The devices cannot know these things by themselves, but through collaboration it is possible. From this aspect, I do not object that autonomic devices have no state at power-on. > OK. With my Anima hat on, I see a strong need for a solution that does > not have any specific L2 technology dependence. What you describe here > works for a specific technology with specific bits set in L2 packets. > What we need is a generic solution that doesn't care about which L2 > technology is involved, because we are trying to establish trust at > a level above L3 routing. > > Brian > > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security From nobody Sun Mar 1 22:10: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 58C8A1A0029 for ; Sun, 1 Mar 2015 22:10:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] 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 jRBCZGIWkDEN for ; Sun, 1 Mar 2015 22:10:38 -0800 (PST) Received: from jenni1.inet.fi (mta-out1.inet.fi [62.71.2.203]) by ietfa.amsl.com (Postfix) with ESMTP id E60D01A004A for ; Sun, 1 Mar 2015 22:10:29 -0800 (PST) Received: from poro.lan (80.220.64.126) by jenni1.inet.fi (8.5.142.08) (authenticated as stenma-47) id 54E3C703018A97D9; Mon, 2 Mar 2015 08:10:27 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Markus Stenberg In-Reply-To: <54F3927C.202@gmail.com> Date: Mon, 2 Mar 2015 08:10:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150220084151.13713.88982.idtracker@ietfa.amsl.com> <54F3927C.202@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Markus Stenberg , Anima WG Subject: Re: [Anima] Comments on draft-behringer-anima-autonomic-control-plane-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: Mon, 02 Mar 2015 06:10:39 -0000 (Mostly lurking) On 2.3.2015, at 0.28, Brian E Carpenter = wrote: >> 4. Self-Healing Properties > ... >> o If an existing device gets revoked, it will automatically be=20 >> denied access to the ACP as its domain certificate will be validated=20= >> against a Certificate Revocation List during authentication. > Excuse my ignorance, but will that instantly kill any open IPsec, > TLS or DTLS associations? Nope. Some implementation-specific magic might do this, but standards = essentially do it only at connection opening time (IKEv2 for IPsec, = TLS/DTLS handshake). Cheers, -Markus= From nobody Mon Mar 2 00:19:12 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 9E6691A6EF2 for ; Mon, 2 Mar 2015 00:19:10 -0800 (PST) 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 htc98kXFoHZF for ; Mon, 2 Mar 2015 00:19:09 -0800 (PST) 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 9F6DD1A6EF1 for ; Mon, 2 Mar 2015 00:19:07 -0800 (PST) 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 BTD58524; Mon, 02 Mar 2015 08:19:06 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Mar 2015 08:19:05 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.106]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Mon, 2 Mar 2015 16:18:58 +0800 From: Sheng Jiang To: Brian E Carpenter , Markus Stenberg Thread-Topic: DNCP + X != GDNP [ Call for agenda ANIMA @ IETF92] Thread-Index: AQHQSh0JpmjIzd4LFUGOYj8unSbmwJzz3DsAgADTTQCAFD4sgA== Date: Mon, 2 Mar 2015 08:18:57 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923B053D5D@nkgeml512-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B923B0455C9@nkgeml512-mbx.china.huawei.com> <02817548-0AD9-4AE4-B5B1-F97B53C5154E@iki.fi> <54E24207.5000803@gmail.com> <082248A1-BB56-43B4-972D-4F9CA1980FCF@iki.fi> <54E39160.5070607@gmail.com> In-Reply-To: <54E39160.5070607@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@ietf.org" , "anima-chairs@tools.ietf.org" Subject: Re: [Anima] DNCP + X != GDNP [ Call for agenda ANIMA @ IETF92] 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, 02 Mar 2015 08:19:10 -0000 SGksIEJyaWFuIGFuZCBNYXJrdXMsDQoNCkkgd2lsbCBhcnJhbmdlIHlvdXIgcHJlc2VudGF0aW9u IG5leHQgdG8gZWFjaCBvdGhlciBhbmQgaGF2ZSBhIGNvbWJpbmVkIG1pYyBkaXNjdXNzaW9uIGFm dGVyd2FyZHMuIFdlIHNob3VsZCBoYXZlIGFyb3VuZCB0aW1lIHRvZ2V0aGVyLiBJIGFsc28gZW5j b3VyYWdlIHlvdSBhbmQgdGhlIG90aGVyIGNvYXV0aG9ycyBvZiB0aGVzZSB0d28gZG9jdW1lbnRz IHRvIGhhdmUgYSBwcmUtbWVldGluZyBkaXNjdXNzaW9uIGluIERhbGxhcy4gSSB3b3VsZCBsaWtl IHRvIGpvaW4geW91LCB0b28uDQoNCkJlc3QgcmVnYXJkcywNCg0KU2hlbmcNCg0KPi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogQnJpYW4gRSBDYXJwZW50ZXIgW21haWx0bzpicmlh bi5lLmNhcnBlbnRlckBnbWFpbC5jb21dDQo+U2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAxOCwg MjAxNSAzOjA3IEFNDQo+VG86IE1hcmt1cyBTdGVuYmVyZw0KPkNjOiBTaGVuZyBKaWFuZzsgYW5p bWFAaWV0Zi5vcmc7IGFuaW1hLWNoYWlyc0B0b29scy5pZXRmLm9yZw0KPlN1YmplY3Q6IFJlOiBE TkNQICsgWCAhPSBHRE5QIFsgQ2FsbCBmb3IgYWdlbmRhIEFOSU1BIEAgSUVURjkyXQ0KPg0KPk9u IDE3LzAyLzIwMTUgMTk6MzAsIE1hcmt1cyBTdGVuYmVyZyB3cm90ZToNCj4+IE9uIDE2LjIuMjAx NSwgYXQgMjEuMTYsIEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5j b20+DQo+d3JvdGU6DQo+Pj4gQXMgZm9yIHRoZSBudW1iZXIgb2YgcGFnZXMgb2YgdGV4dCwgSSB0 aGluayB0aGF0IG1haW5seSBkZXBlbmRzIHdoZXJlDQo+Pj4geW91IGNob29zZSB0byB3cml0ZSBk b3duIHRoZSBkZXRhaWxzLCBpbmNsdWRpbmcgYmFja2dyb3VuZCBpbmZvcm1hdGlvbiwNCj4+PiBy ZXF1aXJlbWVudHMsIHRoZW9yeSBvZiBvcGVyYXRpb24gYW5kIGFsdGVybmF0aXZlcy4gV2UgY2hv c2UgdG8gcHV0IGFsbA0KPj4+IG9mIGl0IGludG8gb25lIGRvY3VtZW50IGZvciBHRE5QLg0KPj4N Cj4+IFllcywgR0ROUCBzcGVjIGlzIGhlYXZ5IG9uIHRoZW9yeS9yZXF1aXJlbWVudHMgKGFuZCBj b21wYXJpc29ucyB0byBzb21lDQo+ZGVncmVlKS4NCj4+DQo+PiBIb3dldmVyLCBnaXZlbiB0aGUg ZG9jdW1lbnQsIGl0IGlzIGNvbXBsZXRlbHkgdW5jbGVhciB0byBtZSBob3cgaXQgd291bGQNCj53 b3JrIGluIHByYWN0aXNlIChhbmQgZ2l2ZW4gdGhlIGxhdGl0dWRlIGFsbG93ZWQgdG8gdGhlIGlu ZGl2aWR1YWwgb2JqZWN0aXZlcywNCj5wZXJoYXBzIGludGVudGlvbmFsbHkgc28pLiBUaGUgVE9E TyBsaXN0IGlzIGEgKHBhcnRpYWwpIGluZGljYXRvciBvZiB0aGF0Lg0KPg0KPlRoZXJlIHdpbGwg YmUgYSBuZXcgdmVyc2lvbiBzb29uIHdoZXJlIHRoZSBUTyBETyBsaXN0IGlzIHF1aXRlIGEgYml0 IHNob3J0ZXIsDQo+YW5kIGhvcGVmdWxseSB0aGVyZSB3aWxsIGJlIHRpbWUgaW4gRGFsbGFzIGZv ciBhIHByb3RvY29sIHdhbGstdGhyb3VnaCwgYnV0DQo+eW91IGFyZSBjb3JyZWN0LCB3ZSBhcmUg aW50ZW50aW9uYWxseSBiZWluZyBnZW5lcmljIGluIHRoaXMgZHJhZnQuDQo+DQo+PiBJIGRvIG5v dCBtaW5kIHRoZSB0aGVvcnkvcmVxdWlyZW1lbnRzIHBhcnRzICh0aGV5IGFyZSBza2lwcGFibGUg aWYgbm90DQo+aW50ZXJlc3RlZCBpbiB0aGVtIGFmdGVyIGFsbCksIGJ1dCB0aGUgbGFjayBvZiBj b25jcmV0ZQ0KPmRldGFpbCBJIGZpbmQgc29tZXdoYXQgZGlzdHJhY3RpbmcuDQo+Pg0KPj4gUGVy aGFwcyBpdCBpcyBqdXN0IGEgZGlmZmVyZW5jZSBvZiBvcGluaW9uIG9uIHdoYXQgc2hvdWxkIGJl IHRoZSBsZWFkaW5nIHBhcnQNCj5vZiBhbiBlZmZvcnQgOykNCj4NCj5JIGtub3cgZXhhY3RseSB3 aGF0IHlvdSBtZWFuLiBSZW1lbWJlciB0aGF0IHRoZXJlIGlzIHNvbWUgcHJvdG90eXBlIGNvZGUs DQo+dGhvdWdoLg0KPlRoZSBuZXh0IHZlcnNpb24gZG9lcyAoSU1OU0hPKSB0aWUgZG93biBhIGxv dCBtb3JlIGRldGFpbHMsIHRvIHRoZSBwb2ludA0KPndoZXJlDQo+SSBmZWVsIEkgY291bGQgYXQg bGVhc3Qgd3JpdGUgYSBwc2V1ZG8tY29kZSB2ZXJzaW9uIG9mIHRoZSB3aG9sZSB0aGluZy4gQW5k IG15DQo+Y28tYXV0aG9yIGlzIG9uIHRoZSBob29rIHRvIHVwZGF0ZSB0aGUgcHJvdG90eXBlIGNv ZGUgd2hlbiB0aW1lIHBlcm1pdHMuDQo+DQo+ICAgIEJyaWFuDQo+DQo+PiBDaGVlcnMsDQo+Pg0K Pj4gLU1hcmt1cw0KPj4NCj4+DQo= From nobody Mon Mar 2 00:49:24 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 CB0921A6FF7 for ; Mon, 2 Mar 2015 00:49:23 -0800 (PST) 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_44=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 8fzC3pGrlDrW for ; Mon, 2 Mar 2015 00:49:22 -0800 (PST) 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 C17EF1A6FF8 for ; Mon, 2 Mar 2015 00:49:20 -0800 (PST) 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 BPU01383; Mon, 02 Mar 2015 08:49:18 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Mar 2015 08:48:56 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.106]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Mon, 2 Mar 2015 16:48:47 +0800 From: Sheng Jiang To: Brian E Carpenter , Markus Stenberg Thread-Topic: DNCP + X != GDNP [ Call for agenda ANIMA @ IETF92] Thread-Index: AQHQSh0JpmjIzd4LFUGOYj8unSbmwJzz3DsAgADTTQCAFD4sgIAACO0g Date: Mon, 2 Mar 2015 08:48:47 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923B053DE2@nkgeml512-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B923B0455C9@nkgeml512-mbx.china.huawei.com> <02817548-0AD9-4AE4-B5B1-F97B53C5154E@iki.fi> <54E24207.5000803@gmail.com> <082248A1-BB56-43B4-972D-4F9CA1980FCF@iki.fi> <54E39160.5070607@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B923B053D5D@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923B053D5D@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@ietf.org" , "anima-chairs@tools.ietf.org" Subject: Re: [Anima] DNCP + X != GDNP [ Call for agenda ANIMA @ IETF92] 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, 02 Mar 2015 08:49:24 -0000 T29wcy4uLiBJIG1pc3NlZCB0aGUgdGltZSBsZW5ndGggaW4gdGhlIHByZXZpb3VzIGVtYWlsLiBK dXN0IGdldCBiYWNrIGZyb20gbG9uZyBob2xpZGF5IGFuZCBoYXZlIG5vdCBzd2l0Y2ggdGhlIG1v ZGVsIGVudGlyZWx5LiA7KQ0KDQpGb3Igbm93LCB3ZSBoYXZlIGFsbG9jYXRlZCA0NSBtaW5zIGZv ciBHRE5QIGFuZCBETkNQIHRvZ2V0aGVyLiBUaGUgcGxhbiBpcyAoZ2l2aW5nIHRoYXQgR0ROUCBp cyB0YXJnZXRpbmcgYSBkZWxpdmVyYWJsZSBpdGVtIGluIEFOSU1BIGNoYXJ0ZXIsIHNvIG1vcmUg dGltZSk6DQoNCiAgIEdETlAgLSAyMCBtaW4NCiAgIEROQ1AgKEhvbWVuZXQpIC0gMTAgbWluDQog ICBDb21iaW5lIGRpc2N1c3Npb24gZm9yIEdETlAmRE5DUCAtIDE1IG1pbiANCg0KQmVzdCByZWdh cmRzLA0KDQpTaGVuZw0KDQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBBbmlt YSBbbWFpbHRvOmFuaW1hLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTaGVuZyBKaWFu Zw0KPlNlbnQ6IE1vbmRheSwgTWFyY2ggMDIsIDIwMTUgNDoxOSBQTQ0KPlRvOiBCcmlhbiBFIENh cnBlbnRlcjsgTWFya3VzIFN0ZW5iZXJnDQo+Q2M6IGFuaW1hQGlldGYub3JnOyBhbmltYS1jaGFp cnNAdG9vbHMuaWV0Zi5vcmcNCj5TdWJqZWN0OiBSZTogW0FuaW1hXSBETkNQICsgWCAhPSBHRE5Q IFsgQ2FsbCBmb3IgYWdlbmRhIEFOSU1BIEAgSUVURjkyXQ0KPg0KPkhpLCBCcmlhbiBhbmQgTWFy a3VzLA0KPg0KPkkgd2lsbCBhcnJhbmdlIHlvdXIgcHJlc2VudGF0aW9uIG5leHQgdG8gZWFjaCBv dGhlciBhbmQgaGF2ZSBhIGNvbWJpbmVkIG1pYw0KPmRpc2N1c3Npb24gYWZ0ZXJ3YXJkcy4gV2Ug c2hvdWxkIGhhdmUgYXJvdW5kIHRpbWUgdG9nZXRoZXIuIEkgYWxzbw0KPmVuY291cmFnZSB5b3Ug YW5kIHRoZSBvdGhlciBjb2F1dGhvcnMgb2YgdGhlc2UgdHdvIGRvY3VtZW50cyB0byBoYXZlIGEN Cj5wcmUtbWVldGluZyBkaXNjdXNzaW9uIGluIERhbGxhcy4gSSB3b3VsZCBsaWtlIHRvIGpvaW4g eW91LCB0b28uDQo+DQo+QmVzdCByZWdhcmRzLA0KPg0KPlNoZW5nDQo+DQo+Pi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+PkZyb206IEJyaWFuIEUgQ2FycGVudGVyIFttYWlsdG86YnJpYW4u ZS5jYXJwZW50ZXJAZ21haWwuY29tXQ0KPj5TZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDE4LCAy MDE1IDM6MDcgQU0NCj4+VG86IE1hcmt1cyBTdGVuYmVyZw0KPj5DYzogU2hlbmcgSmlhbmc7IGFu aW1hQGlldGYub3JnOyBhbmltYS1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcNCj4+U3ViamVjdDogUmU6 IEROQ1AgKyBYICE9IEdETlAgWyBDYWxsIGZvciBhZ2VuZGEgQU5JTUEgQCBJRVRGOTJdDQo+Pg0K Pj5PbiAxNy8wMi8yMDE1IDE5OjMwLCBNYXJrdXMgU3RlbmJlcmcgd3JvdGU6DQo+Pj4gT24gMTYu Mi4yMDE1LCBhdCAyMS4xNiwgQnJpYW4gRSBDYXJwZW50ZXIgPGJyaWFuLmUuY2FycGVudGVyQGdt YWlsLmNvbT4NCj4+d3JvdGU6DQo+Pj4+IEFzIGZvciB0aGUgbnVtYmVyIG9mIHBhZ2VzIG9mIHRl eHQsIEkgdGhpbmsgdGhhdCBtYWlubHkgZGVwZW5kcyB3aGVyZQ0KPj4+PiB5b3UgY2hvb3NlIHRv IHdyaXRlIGRvd24gdGhlIGRldGFpbHMsIGluY2x1ZGluZyBiYWNrZ3JvdW5kIGluZm9ybWF0aW9u LA0KPj4+PiByZXF1aXJlbWVudHMsIHRoZW9yeSBvZiBvcGVyYXRpb24gYW5kIGFsdGVybmF0aXZl cy4gV2UgY2hvc2UgdG8gcHV0IGFsbA0KPj4+PiBvZiBpdCBpbnRvIG9uZSBkb2N1bWVudCBmb3Ig R0ROUC4NCj4+Pg0KPj4+IFllcywgR0ROUCBzcGVjIGlzIGhlYXZ5IG9uIHRoZW9yeS9yZXF1aXJl bWVudHMgKGFuZCBjb21wYXJpc29ucyB0bw0KPnNvbWUNCj4+ZGVncmVlKS4NCj4+Pg0KPj4+IEhv d2V2ZXIsIGdpdmVuIHRoZSBkb2N1bWVudCwgaXQgaXMgY29tcGxldGVseSB1bmNsZWFyIHRvIG1l IGhvdyBpdCB3b3VsZA0KPj53b3JrIGluIHByYWN0aXNlIChhbmQgZ2l2ZW4gdGhlIGxhdGl0dWRl IGFsbG93ZWQgdG8gdGhlIGluZGl2aWR1YWwgb2JqZWN0aXZlcywNCj4+cGVyaGFwcyBpbnRlbnRp b25hbGx5IHNvKS4gVGhlIFRPRE8gbGlzdCBpcyBhIChwYXJ0aWFsKSBpbmRpY2F0b3Igb2YgdGhh dC4NCj4+DQo+PlRoZXJlIHdpbGwgYmUgYSBuZXcgdmVyc2lvbiBzb29uIHdoZXJlIHRoZSBUTyBE TyBsaXN0IGlzIHF1aXRlIGEgYml0IHNob3J0ZXIsDQo+PmFuZCBob3BlZnVsbHkgdGhlcmUgd2ls bCBiZSB0aW1lIGluIERhbGxhcyBmb3IgYSBwcm90b2NvbCB3YWxrLXRocm91Z2gsIGJ1dA0KPj55 b3UgYXJlIGNvcnJlY3QsIHdlIGFyZSBpbnRlbnRpb25hbGx5IGJlaW5nIGdlbmVyaWMgaW4gdGhp cyBkcmFmdC4NCj4+DQo+Pj4gSSBkbyBub3QgbWluZCB0aGUgdGhlb3J5L3JlcXVpcmVtZW50cyBw YXJ0cyAodGhleSBhcmUgc2tpcHBhYmxlIGlmIG5vdA0KPj5pbnRlcmVzdGVkIGluIHRoZW0gYWZ0 ZXIgYWxsKSwgYnV0IHRoZSBsYWNrIG9mIGNvbmNyZXRlDQo+PmRldGFpbCBJIGZpbmQgc29tZXdo YXQgZGlzdHJhY3RpbmcuDQo+Pj4NCj4+PiBQZXJoYXBzIGl0IGlzIGp1c3QgYSBkaWZmZXJlbmNl IG9mIG9waW5pb24gb24gd2hhdCBzaG91bGQgYmUgdGhlIGxlYWRpbmcgcGFydA0KPj5vZiBhbiBl ZmZvcnQgOykNCj4+DQo+Pkkga25vdyBleGFjdGx5IHdoYXQgeW91IG1lYW4uIFJlbWVtYmVyIHRo YXQgdGhlcmUgaXMgc29tZSBwcm90b3R5cGUNCj5jb2RlLA0KPj50aG91Z2guDQo+PlRoZSBuZXh0 IHZlcnNpb24gZG9lcyAoSU1OU0hPKSB0aWUgZG93biBhIGxvdCBtb3JlIGRldGFpbHMsIHRvIHRo ZSBwb2ludA0KPj53aGVyZQ0KPj5JIGZlZWwgSSBjb3VsZCBhdCBsZWFzdCB3cml0ZSBhIHBzZXVk by1jb2RlIHZlcnNpb24gb2YgdGhlIHdob2xlIHRoaW5nLiBBbmQgbXkNCj4+Y28tYXV0aG9yIGlz IG9uIHRoZSBob29rIHRvIHVwZGF0ZSB0aGUgcHJvdG90eXBlIGNvZGUgd2hlbiB0aW1lIHBlcm1p dHMuDQo+Pg0KPj4gICAgQnJpYW4NCj4+DQo+Pj4gQ2hlZXJzLA0KPj4+DQo+Pj4gLU1hcmt1cw0K Pj4+DQo+Pj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPkFuaW1hIG1haWxpbmcgbGlzdA0KPkFuaW1hQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYQ0K From nobody Mon Mar 2 01:06: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 B44041A0370 for ; Mon, 2 Mar 2015 01:06:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.521 X-Spam-Level: X-Spam-Status: No, score=-0.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] 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 oRZ5SN-NI40B for ; Mon, 2 Mar 2015 01:06:17 -0800 (PST) Received: from kirsi1.inet.fi (mta-out1.inet.fi [62.71.2.195]) by ietfa.amsl.com (Postfix) with ESMTP id 905721A00F5 for ; Mon, 2 Mar 2015 01:06:17 -0800 (PST) Received: from poro.lan (80.220.64.126) by kirsi1.inet.fi (8.5.142.08) (authenticated as stenma-47) id 54E3C71101932509; Mon, 2 Mar 2015 11:06:13 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Markus Stenberg In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923B053DE2@nkgeml512-mbx.china.huawei.com> Date: Mon, 2 Mar 2015 11:06:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <683E566E-E063-4772-BDE0-36F0FF74322A@iki.fi> References: <5D36713D8A4E7348A7E10DF7437A4B923B0455C9@nkgeml512-mbx.china.huawei.com> <02817548-0AD9-4AE4-B5B1-F97B53C5154E@iki.fi> <54E24207.5000803@gmail.com> <082248A1-BB56-43B4-972D-4F9CA1980FCF@iki.fi> <54E39160.5070607@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B923B053D5D@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923B053DE2@nkgeml512-mbx.china.huawei.com> To: Sheng Jiang X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Markus Stenberg , "anima@ietf.org" , "anima-chairs@tools.ietf.org" Subject: Re: [Anima] DNCP + X != GDNP [ Call for agenda ANIMA @ IETF92] 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, 02 Mar 2015 09:06:19 -0000 On 2.3.2015, at 10.48, Sheng Jiang wrote: > Oops... I missed the time length in the previous email. Just get back = from long holiday and have not switch the model entirely. ;) >=20 > For now, we have allocated 45 mins for GDNP and DNCP together. The = plan is (giving that GDNP is targeting a deliverable item in ANIMA = charter, so more time): >=20 > GDNP - 20 min > DNCP (Homenet) - 10 min > Combine discussion for GDNP&DNCP - 15 min=20 Well, DNCP + X is also targeting ANIMA charter. But 10 minutes should = be enough to present the general idea in any case. The draft will be out = sometime this week. Cheers, -Markus= From nobody Mon Mar 2 01:25: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 B461F1A0362 for ; Mon, 2 Mar 2015 01:25:03 -0800 (PST) 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_44=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 anenRlrMpDTI for ; Mon, 2 Mar 2015 01:25:02 -0800 (PST) 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 046521A00B6 for ; Mon, 2 Mar 2015 01:25:01 -0800 (PST) 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 BPU06023; Mon, 02 Mar 2015 09:25:00 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Mar 2015 09:24:58 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.106]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Mon, 2 Mar 2015 17:24:49 +0800 From: Sheng Jiang To: Markus Stenberg Thread-Topic: [Anima] DNCP + X != GDNP [ Call for agenda ANIMA @ IETF92] Thread-Index: AQHQSh0JpmjIzd4LFUGOYj8unSbmwJzz3DsAgADTTQCAFD4sgIAACO0g//9/SACAAIpDwA== Date: Mon, 2 Mar 2015 09:24:48 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923B053E09@nkgeml512-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B923B0455C9@nkgeml512-mbx.china.huawei.com> <02817548-0AD9-4AE4-B5B1-F97B53C5154E@iki.fi> <54E24207.5000803@gmail.com> <082248A1-BB56-43B4-972D-4F9CA1980FCF@iki.fi> <54E39160.5070607@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B923B053D5D@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923B053DE2@nkgeml512-mbx.china.huawei.com> <683E566E-E063-4772-BDE0-36F0FF74322A@iki.fi> In-Reply-To: <683E566E-E063-4772-BDE0-36F0FF74322A@iki.fi> 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@ietf.org" , "anima-chairs@tools.ietf.org" Subject: Re: [Anima] DNCP + X != GDNP [ Call for agenda ANIMA @ IETF92] 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, 02 Mar 2015 09:25:03 -0000 Pj4gRm9yIG5vdywgd2UgaGF2ZSBhbGxvY2F0ZWQgNDUgbWlucyBmb3IgR0ROUCBhbmQgRE5DUCB0 b2dldGhlci4gVGhlIHBsYW4NCj5pcyAoZ2l2aW5nIHRoYXQgR0ROUCBpcyB0YXJnZXRpbmcgYSBk ZWxpdmVyYWJsZSBpdGVtIGluIEFOSU1BIGNoYXJ0ZXIsIHNvIG1vcmUNCj50aW1lKToNCj4+DQo+ PiAgIEdETlAgLSAyMCBtaW4NCj4+ICAgRE5DUCAoSG9tZW5ldCkgLSAxMCBtaW4NCj4+ICAgQ29t YmluZSBkaXNjdXNzaW9uIGZvciBHRE5QJkROQ1AgLSAxNSBtaW4NCj4NCj5XZWxsLCBETkNQICsg WCBpcyBhbHNvIHRhcmdldGluZyBBTklNQSBjaGFydGVyLg0KDQpZZXMuIFNvLCB5b3UgY2FuIGhh dmUgMTUgbWluIGlmIHlvdSBuZWVkZWQuIEZvciBub3csIEkgY2FuIG9ubHkgcmVsb2NhdGUgdGhl IGFkZGl0aW9uYWwgNSBtaW5zIGZyb20gdGhlIGRpc2N1c3Npb24gdGltZS4gU28sIGl0IGlzIHVw IHRvIHlvdSB3aGV0aGVyIHlvdSB3YW50IG1vcmUgZm9yIHByZXNlbnRhdGlvbiBvciBkaXNjdXNz aW9uLiA6KQ0KDQpCZXN0IHJlZ2FyZHMsDQoNClNoZW5nDQoNCj5CdXQgMTAgbWludXRlcyBzaG91 bGQgYmUNCj5lbm91Z2ggdG8gcHJlc2VudCB0aGUgZ2VuZXJhbCBpZGVhIGluIGFueSBjYXNlLiBU aGUgZHJhZnQgd2lsbCBiZSBvdXQNCj5zb21ldGltZSB0aGlzIHdlZWsuDQo+DQo+Q2hlZXJzLA0K Pg0KPi1NYXJrdXMNCg== From nobody Mon Mar 2 11:21: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 D2AEC1A88F0 for ; Mon, 2 Mar 2015 11:21:29 -0800 (PST) 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 lQELaAvb_-P5 for ; Mon, 2 Mar 2015 11:21:28 -0800 (PST) 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 896E01A6FF9 for ; Mon, 2 Mar 2015 11:21:28 -0800 (PST) Received: by pdjz10 with SMTP id z10so41763670pdj.12 for ; Mon, 02 Mar 2015 11:21:27 -0800 (PST) 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=QWhi4sdcpoZK/5uWbwO/aVjvaXyjYiomRH8Z6AFRfWo=; b=m+9IKPBNmB61Hh7jqVuSChtW+lOUJiTAT5aajcqws7dfIKsR7M0bBSIUtCES9T9Xap I26nf51HbXbkPrjdWEftblNVC4ZoodeUHk5wCupHcdri4xkNQS9WL5BMNhrFRXYxCViU nPD8BMN1GjuzMSq2+BiwvpJcD54PH3luE62DxHj7C0Bpo797rRDdJT23c+fHmjVLeDby zmbLrqjM00BbHzTgguT8gFkUW0lwq0ZpM8YJtoonzxRiekcZmV/aAIEg9TuC8quQIfCp pRJ4o0hyRNGNsAVD8evAkJ8v2lDuoByYqpbOh6yGuRCUfe1aaryatSkmNKHqRVv2Swby kENQ== X-Received: by 10.68.205.227 with SMTP id lj3mr49286565pbc.143.1425324087757; Mon, 02 Mar 2015 11:21:27 -0800 (PST) Received: from ?IPv6:2406:e007:7777:1:28cc:dc4c:9703:6781? ([2406:e007:7777:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id bc4sm12880419pac.4.2015.03.02.11.21.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Mar 2015 11:21:26 -0800 (PST) Message-ID: <54F4B835.2060009@gmail.com> Date: Tue, 03 Mar 2015 08:21:25 +1300 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.5.0 MIME-Version: 1.0 To: Markus Stenberg References: <20150220084151.13713.88982.idtracker@ietfa.amsl.com> <54F3927C.202@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Anima WG Subject: Re: [Anima] Comments on draft-behringer-anima-autonomic-control-plane-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: Mon, 02 Mar 2015 19:21:30 -0000 On 02/03/2015 19:10, Markus Stenberg wrote: > (Mostly lurking) > > On 2.3.2015, at 0.28, Brian E Carpenter wrote: >>> 4. Self-Healing Properties >> ... >>> o If an existing device gets revoked, it will automatically be >>> denied access to the ACP as its domain certificate will be validated >>> against a Certificate Revocation List during authentication. >> Excuse my ignorance, but will that instantly kill any open IPsec, >> TLS or DTLS associations? > > Nope. Some implementation-specific magic might do this, but standards essentially do it only at connection opening time (IKEv2 for IPsec, TLS/DTLS handshake). Ahah. So that leaves an attack window open, if a node is suborned and revoked, as long as it has open security associations. That suggests that there should be an arbitrary lifetime for all SAs. Brian From nobody Mon Mar 2 16:32: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 75C4E1A8AEB for ; Mon, 2 Mar 2015 16:32:27 -0800 (PST) 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 8P_edzzt6XQp for ; Mon, 2 Mar 2015 16:32:26 -0800 (PST) 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 E3D021A8ABC for ; Mon, 2 Mar 2015 16:32:25 -0800 (PST) Received: by pablj1 with SMTP id lj1so9589156pab.10 for ; Mon, 02 Mar 2015 16:32:25 -0800 (PST) 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=aOcFCubsyvJLVSNCJJSjwxpXdPgp9NWTZ4xrCqOlJeU=; b=NVFTCgJCpBOo33qXpLDqsd1PBq9Vez6lGxULj/tLRrxm1cg0qKFwNyHqTRqxQOiAzF gfxostgLqCq65xsVA+wvop+8EocKeTS6+vNz4PvNfYuzagLkbwyz8QfLlVAHHu+0HDzt V4QRpiprZcAAJl3Y806bnFNU5wvma+aqXwg0jwD2iyHoMgv4VFmh26wDsr3+om7ovR8c +ASpqoONvqjvcxWSybBmVr3tkDXlS1FAh7NG8a1hPo5msLbY5FiWh6SoZ2OirOiHk+3n a2s001D3ByJE8//cyV/540WrqPAxTvF+H5XsahJB0yXAeevY2lVOSvRa4IkRMAGTtX2y hXvQ== X-Received: by 10.70.132.103 with SMTP id ot7mr51611690pdb.158.1425342744228; Mon, 02 Mar 2015 16:32:24 -0800 (PST) Received: from [172.24.47.81] (wireless-nat-21.auckland.ac.nz. [130.216.30.132]) by mx.google.com with ESMTPSA id gi6sm12973318pbd.93.2015.03.02.16.32.21 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Mar 2015 16:32:23 -0800 (PST) Message-ID: <54F50116.9000501@gmail.com> Date: Tue, 03 Mar 2015 13:32:22 +1300 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.5.0 MIME-Version: 1.0 To: Anima WG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] DNA 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, 03 Mar 2015 00:32:27 -0000 Should we be considering the aims and mechanisms of the old Detecting Network Attachment (DNA) work in the IETF, and specifically the mechanisms standardised by RFC 4436 (v4) and RFC 6059 (v6)? At the least, should we be assuming that autonomic nodes will use these mechanisms as a matter of course? Or is that science fiction? (Thanks to Brian Haberman for reminding me of this work.) Regards Brian Carpenter From nobody Mon Mar 2 18:04: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 68AC41A909D for ; Mon, 2 Mar 2015 18:04:12 -0800 (PST) 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 hJgKbc2vG16q for ; Mon, 2 Mar 2015 18:04:10 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 95FC91A909C for ; Mon, 2 Mar 2015 18:04:10 -0800 (PST) Received: from divertimento.lan (c-71-233-43-215.hsd1.nh.comcast.net [71.233.43.215]) by toccata.fugue.com (Postfix) with ESMTPSA id C8FB823802DE; Mon, 2 Mar 2015 21:04:09 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <54F50116.9000501@gmail.com> Date: Mon, 2 Mar 2015 21:04:05 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <46E8AE45-3B6A-4CA0-92EA-F5E463C1D47C@fugue.com> References: <54F50116.9000501@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Anima WG Subject: Re: [Anima] DNA 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, 03 Mar 2015 02:04:12 -0000 On Mar 2, 2015, at 7:32 PM, Brian E Carpenter = wrote: > At the least, should we be assuming that autonomic nodes > will use these mechanisms as a matter of course? Or is > that science fiction? Regular nodes seem to use them. Why wouldn't autonomic nodes? From nobody Mon Mar 2 18:45: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 0C0791A0122 for ; Mon, 2 Mar 2015 18:45:52 -0800 (PST) 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 q4H7SkTLzvOt for ; Mon, 2 Mar 2015 18:45:51 -0800 (PST) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::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 D7B411A00FD for ; Mon, 2 Mar 2015 18:45:50 -0800 (PST) Received: by pdbfl12 with SMTP id fl12so13368763pdb.5 for ; Mon, 02 Mar 2015 18:45:50 -0800 (PST) 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=mgT1ZJUohvQ+5qcoCGLjJdXO0yuGZPmEc1/i/a00t2Q=; b=KQRmoTbm1sF1ybZznpIWvSPkixzKT/TV6xK3tJzLJQFKBlaeXDwArko2+VEkg8O8q1 DWU9NswQf7nKcAbloLLRschN4v+WVCYv69e24CvrC+XrlyNvT7TxPxIOSp9Is5sJk5M4 zRzirPDS4biBSBnHFl2IVO/fklTNT0BlKtQ3LLqYSSCgG85jzkMO4zt+/ih7Ns44WQF0 biwpqfedJWezLn5bIXKhPCLOaDMARB98MWMFnX4CF21ibRsMwBOqSNGpSjqcjCNA5YPG Un/0wY4/EFFFIQBohdOsfnXik3qMp0qUCqxJWO1+enWXPCjyMRWg8wpuEcZVGAlH04ik w7ow== X-Received: by 10.68.221.34 with SMTP id qb2mr51511179pbc.47.1425350750149; Mon, 02 Mar 2015 18:45:50 -0800 (PST) Received: from ?IPv6:2406:e007:7777:1:28cc:dc4c:9703:6781? ([2406:e007:7777:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id iy2sm10009566pbb.22.2015.03.02.18.45.47 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Mar 2015 18:45:49 -0800 (PST) Message-ID: <54F5205C.9020302@gmail.com> Date: Tue, 03 Mar 2015 15:45:48 +1300 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.5.0 MIME-Version: 1.0 To: Ted Lemon References: <54F50116.9000501@gmail.com> <46E8AE45-3B6A-4CA0-92EA-F5E463C1D47C@fugue.com> In-Reply-To: <46E8AE45-3B6A-4CA0-92EA-F5E463C1D47C@fugue.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Anima WG Subject: Re: [Anima] DNA 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, 03 Mar 2015 02:45:52 -0000 On 03/03/2015 15:04, Ted Lemon wrote: > On Mar 2, 2015, at 7:32 PM, Brian E Carpenter wrote: >> At the least, should we be assuming that autonomic nodes >> will use these mechanisms as a matter of course? Or is >> that science fiction? > > Regular nodes seem to use them. Why wouldn't autonomic nodes? I guess my question is whether we regard them as mandatory. Brian From nobody Mon Mar 2 19:23: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 0989C1A0141 for ; Mon, 2 Mar 2015 19:23:22 -0800 (PST) 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 eN5Kg0x5k7Fa for ; Mon, 2 Mar 2015 19:23:20 -0800 (PST) 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 AEBE31A026A for ; Mon, 2 Mar 2015 19:23:19 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPU86677; Tue, 03 Mar 2015 03:23:18 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Mar 2015 03:23:17 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.106]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Tue, 3 Mar 2015 11:23:12 +0800 From: Sheng Jiang To: Brian E Carpenter , Ted Lemon Thread-Topic: [Anima] DNA Thread-Index: AQHQVUmKEm8UJIU2q0asUAKi3f9lvJ0Je/eAgAALqACAAI8doA== Date: Tue, 3 Mar 2015 03:23:11 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923B054B46@nkgeml512-mbx.china.huawei.com> References: <54F50116.9000501@gmail.com> <46E8AE45-3B6A-4CA0-92EA-F5E463C1D47C@fugue.com> <54F5205C.9020302@gmail.com> In-Reply-To: <54F5205C.9020302@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] DNA 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, 03 Mar 2015 03:23:22 -0000 Pk9uIDAzLzAzLzIwMTUgMTU6MDQsIFRlZCBMZW1vbiB3cm90ZToNCj4+IE9uIE1hciAyLCAyMDE1 LCBhdCA3OjMyIFBNLCBCcmlhbiBFIENhcnBlbnRlcg0KPjxicmlhbi5lLmNhcnBlbnRlckBnbWFp bC5jb20+IHdyb3RlOg0KPj4+IEF0IHRoZSBsZWFzdCwgc2hvdWxkIHdlIGJlIGFzc3VtaW5nIHRo YXQgYXV0b25vbWljIG5vZGVzDQo+Pj4gd2lsbCB1c2UgdGhlc2UgbWVjaGFuaXNtcyBhcyBhIG1h dHRlciBvZiBjb3Vyc2U/IE9yIGlzDQo+Pj4gdGhhdCBzY2llbmNlIGZpY3Rpb24/DQo+Pg0KPj4g UmVndWxhciBub2RlcyBzZWVtIHRvIHVzZSB0aGVtLiAgIFdoeSB3b3VsZG4ndCBhdXRvbm9taWMg bm9kZXM/DQo+DQo+SSBndWVzcyBteSBxdWVzdGlvbiBpcyB3aGV0aGVyIHdlIHJlZ2FyZCB0aGVt IGFzIG1hbmRhdG9yeS4NCg0KV2hlcmUgY2FuIHdlIG1ha2UgdGhlbSBtYW5kYXRvcnk/IFllcywg dGhleSBhcmUgcmVhc29uYWJsZSBmdW5jdGlvbnMgZm9yIGF1dG9ub21pYyBub2Rlcy4gQnV0IHdl IGRvIG5vdCBoYXZlIGFuIGludGVncmF0ZWQgcmVxdWlyZW1lbnRzIGZvciBhdXRvbm9taWMgbm9k ZXMsIG5laXRoZXIgZm9yIGF1dG9ub21pYyBuZXR3b3JrIGFyY2hpdGVjdHVyZS4gVGhlIG9ubHkg b3BpbmlvbiBJIGNhbiB0aGluayBvdXQgaXMgdG8gcmVkZXNpZ24gdGhlIG1lY2hhbmlzbXMgYW5k IHRyeSB0byBlbWJlZCB0aGVtIGludG8gQU5JTUEgUHJvdG9jb2xzLCBmb3Igd2hpY2ggSSBkb24n dCB0aGluayBpcyByaWdodCB0aGluZyB0byBkby4NCg0KQmVzdCByZWdhcmRzLA0KDQpTaGVuZw0K DQo+ICAgQnJpYW4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPkFuaW1hIG1haWxpbmcgbGlzdA0KPkFuaW1hQGlldGYub3JnDQo+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYQ0K From nobody Mon Mar 2 20:02: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 9E4501A03C7 for ; Mon, 2 Mar 2015 20:02:56 -0800 (PST) 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 NFTeQ_tDHSZB for ; Mon, 2 Mar 2015 20:02:55 -0800 (PST) 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 531551A03A0 for ; Mon, 2 Mar 2015 20:02:50 -0800 (PST) Received: by pdjp10 with SMTP id p10so7813684pdj.10 for ; Mon, 02 Mar 2015 20:02:49 -0800 (PST) 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=6bEq3dX1m0Zr+B4meI2IyyzI8ZOjMt3wWCU6+JuoxsA=; b=oWndgSdGY13q4xbmWb1U/llxGXRe7VL2QZOAP7V7LJiQ1AfECvV0CqgMc9j8V4vRP0 Gv3tvRTeSUixBvmc0H3fdx62gS41eVh8bdCpuPhTu0dFJLVYud6vqP/FluKWHJya4CBZ MjI1NngPbj7BkU7+ooLTLGazkeRTa9IejeUxsAOboxCwNQZQTu0Oyzq1lpbg9lN/e73H p0wtyiYhfOxRWpxNPCrcbKfrcRl3Wy816xY6p7t8fy2FpW2NeLwrHGZhs8vNwGHDIMiP ue6UmJwS6B/UCt3HGQOtgXsUEROOSrHwGr/WGDxgtdi4xriMjHZ+qCKjJuwGneQ+M3Jz z35Q== X-Received: by 10.67.3.105 with SMTP id bv9mr51554672pad.149.1425355369553; Mon, 02 Mar 2015 20:02:49 -0800 (PST) Received: from ?IPv6:2406:e007:7777:1:28cc:dc4c:9703:6781? ([2406:e007:7777:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id uy8sm13372774pbc.31.2015.03.02.20.02.46 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Mar 2015 20:02:48 -0800 (PST) Message-ID: <54F53268.8020803@gmail.com> Date: Tue, 03 Mar 2015 17:02:48 +1300 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.5.0 MIME-Version: 1.0 To: Sheng Jiang , Ted Lemon References: <54F50116.9000501@gmail.com> <46E8AE45-3B6A-4CA0-92EA-F5E463C1D47C@fugue.com> <54F5205C.9020302@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B923B054B46@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923B054B46@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Anima WG Subject: Re: [Anima] DNA 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, 03 Mar 2015 04:02:56 -0000 Regards Brian Carpenter http://orcid.org/0000-0001-7924-6182 On 03/03/2015 16:23, Sheng Jiang wrote: >> On 03/03/2015 15:04, Ted Lemon wrote: >>> On Mar 2, 2015, at 7:32 PM, Brian E Carpenter >> wrote: >>>> At the least, should we be assuming that autonomic nodes will >>>> use these mechanisms as a matter of course? Or is that science >>>> fiction? >>> >>> Regular nodes seem to use them. Why wouldn't autonomic nodes? >> >> I guess my question is whether we regard them as mandatory. > > Where can we make them mandatory? Yes, they are reasonable functions > for autonomic nodes. But we do not have an integrated requirements > for autonomic nodes, neither for autonomic network architecture. The > only opinion I can think out is to redesign the mechanisms and try > to embed them into ANIMA Protocols, for which I don't think is right > thing to do. I agree, except that the ACP draft might say something about the need to detect loss of connectivity. The issue could also be mentioned in the reference-model draft, I guess. It's also an example of existing autonomic behavior, so perhaps should have been mentioned in the NMRG document. Regards Brian From nobody Tue Mar 3 04:51:10 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 B36101A6EE1 for ; Tue, 3 Mar 2015 04:51:08 -0800 (PST) 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 SHEbSeYOGUBR for ; Tue, 3 Mar 2015 04:51:07 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 08BDB1A3BA7 for ; Tue, 3 Mar 2015 04:51:07 -0800 (PST) Received: from [10.0.20.107] (c-71-233-43-215.hsd1.nh.comcast.net [71.233.43.215]) by toccata.fugue.com (Postfix) with ESMTPSA id BF70623803F0; Tue, 3 Mar 2015 07:51:05 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923B054B46@nkgeml512-mbx.china.huawei.com> Date: Tue, 3 Mar 2015 07:51:03 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <295A41C5-166E-4AF4-A04D-83A575CEA277@fugue.com> References: <54F50116.9000501@gmail.com> <46E8AE45-3B6A-4CA0-92EA-F5E463C1D47C@fugue.com> <54F5205C.9020302@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B923B054B46@nkgeml512-mbx.china.huawei.com> To: Sheng Jiang X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Anima WG Subject: Re: [Anima] DNA 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, 03 Mar 2015 12:51:08 -0000 On Mar 2, 2015, at 10:23 PM, Sheng Jiang wrote: > Where can we make them mandatory? Yes, they are reasonable functions = for autonomic nodes. But we do not have an integrated requirements for = autonomic nodes, neither for autonomic network architecture. The only = opinion I can think out is to redesign the mechanisms and try to embed = them into ANIMA Protocols, for which I don't think is right thing to do. Why not make the ones that are dependable mandatory? Do you think that = layer 2 stuff shouldn't be mentioned in Anima documents? DNA makes = stacks' behavior a lot better in general, although occasionally it can = result in unnecessary brief outages when a cable is unplugged and = plugged back in to the same network, but for Anima devices isn't this = kind of a non-problem? From nobody Tue Mar 3 08:36: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 170471ABD35; Tue, 3 Mar 2015 08:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 K163m-MPMomP; Tue, 3 Mar 2015 08:36:28 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 D3DA51ABC74; Tue, 3 Mar 2015 08:36:25 -0800 (PST) Received: from [192.168.131.140] ([80.92.121.102]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M54fe-1XZ6vX3iog-00zDbI; Tue, 03 Mar 2015 17:36:18 +0100 Message-ID: <54F5E2FF.4040205@gmx.net> Date: Tue, 03 Mar 2015 17:36:15 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Brian E Carpenter , sarikaya@ieee.org References: <77FA386512F0D748BC7C02C36EB1106D921776@szxeml557-mbs.china.huawei.com> <6426.1422664463@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com> <54E7219B.6040006@gridmerge.com> <54E72846.20807@gmx.net> <54E7824A.4040906@gmail.com> <54E86F9A.8020104@gmx.net> <54E8D442.6020909@gmail.com> <54EB4F24.7030609@gmx.net> <54EE6E31.8030609@gmail.com> In-Reply-To: <54EE6E31.8030609@gmail.com> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="VWbSTnxSw30HJdhWAVDPbRoVObgChRHkh" X-Provags-ID: V03:K0:LRh17iwgsHV0eepGyT5UgHbtU1yv3Z6bm+eF0ChQXRnhitb7HXQ B0ajzcoyGaegF05OkjJFx8eqnlNAClMXImka6qzrPRAPyUPkDAoBJBNjuT5y9W8YDOxjxYB xz7mbR7dBetxRRXAigY3nGOKvkam7pM3UWKfgpO/jHCTFj0YjkEcVL72fsp3bdP9/RlhkiP jhj/f+itCWgqz4D9ObCmA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: consultancy@vanderstok.org, 6tisch-security <6tisch-security@ietf.org>, Michael Richardson , "Hedanping \(Ana\)" , robert.cragie@gridmerge.com, "6lo@ietf.org" <6lo@ietf.org>, "anima@ietf.org" Subject: Re: [Anima] Thread [Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things] 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, 03 Mar 2015 16:36:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VWbSTnxSw30HJdhWAVDPbRoVObgChRHkh Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable At the moment the specifications are only available to Thread members since the specification is still work in progress. I don't know when it will be finalized and released to the wider public. Regarding the liaison I do not have an opinion about the value of it. Ciao Hannes On 02/26/2015 01:52 AM, Brian E Carpenter wrote: > On 26/02/2015 10:25, Behcet Sarikaya wrote: >=20 > ... >>>> I know nothing about Thread, whatever and whoever it is. >>> >>> Here is an intro document: >>> http://threadgroup.org/Portals/0/documents/events/ThreadIntro.pdf >=20 > Thanks for that. It seems to have all the downsides of secretive ad hoc= > membership-based consortia, except for the upside of a RAND-RF IPR > policy. >=20 >> I think we need to clarify here that Thread Group is formed to deal >> with home environments. >> >> Enterprise or industrial environments seem to be excluded. >=20 > So far. The boundary between this and larger building services > networks is pretty fuzzy, isn't it? >=20 > In any case, should we (the WGs on copy, and perhaps some others) > be asking the IAB to arrange a meaningful liaison with Thread? >=20 > Back at Hannes: is there a spec for their approach to security > enrollment? >=20 > Brian >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 --VWbSTnxSw30HJdhWAVDPbRoVObgChRHkh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU9eL/AAoJEGhJURNOOiAtfFMH/RqiDU7G4ZNPZ/DWYd3zDuS8 IpESok4AXPjTCWyqVUT28bvSpY/ac0hNF8HEm9XVf7HTB6v8omj99Vbrq8xQYlVb hc728crXBRMlWCPbJVT7jkELr8u0GqgVGtnNsA66FBsy82b4n6q0Xy69yv6WRd0J dzxbS6yAQDO11mkzhcZwpnMhUY+Wt/gX2jB3Nrn22mkX/hJoPsg7fel2BZ8kC0Dm R+dA7K9tVSS1q7OfoqHE3GQsihSq+pY1eOTTFrIZC0hxbDoXGZIMVtVbW4DnfAN8 yvR1xngnRQ87WrW3yl8KlO88UrMcNszMJOo1X7/Zbzs4ZSOvoHJU835J+w0/aNY= =uyxv -----END PGP SIGNATURE----- --VWbSTnxSw30HJdhWAVDPbRoVObgChRHkh-- From nobody Tue Mar 3 09:22: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 64DB01AC3A2; Tue, 3 Mar 2015 09:22:32 -0800 (PST) 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 kJp-6nSe8gjZ; Tue, 3 Mar 2015 09:22:30 -0800 (PST) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::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 895431AC39F; Tue, 3 Mar 2015 09:22:30 -0800 (PST) Received: by mail-qg0-f42.google.com with SMTP id z60so13214832qgd.1; Tue, 03 Mar 2015 09:22:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sksr5EzFf8346o8IUja5bBUmlACYohsLZin0xwIpp68=; b=XMmV16CpMmKicnj5hJ6/idVaiDLDIAz+ZOuXtjVpXXG5PP3s7XWs0GmRsLfH4fW4qc EFz9po1eQocvGxVp2oufpq3azn4yrj0Y10f2toWEHvqA4BZ+bBvoK2+eDjAzuR6g4PIn S+IzW+D1kCI7qkmvqssBCePwQThfzfncriQRoKuGy9YW94PiYayX+o8RRP5QxKiYXB7N s1oMkiV7UEJ4Ltg65q4N6YSZBen9eebkzY4FOfO665SBC3PwBRAdwYkpUJD7A6P8VOMW OhixLQVfL88MSmuAeKUlXcsmVkqtyPgjgq2pBs8o+oEqQU05GyJqR4mgIyMCdD7iWAwl Q1JA== X-Received: by 10.140.232.135 with SMTP id d129mr6940534qhc.90.1425403349727; Tue, 03 Mar 2015 09:22:29 -0800 (PST) Received: from ?IPv6:2001:420:c0c4:1006::17c? ([2001:420:c0c4:1006::17c]) by mx.google.com with ESMTPSA id i51sm757016qgf.19.2015.03.03.09.22.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Mar 2015 09:22:29 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ralph Droms In-Reply-To: <54F5E2FF.4040205@gmx.net> Date: Tue, 3 Mar 2015 12:22:25 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8B0B30B7-D6E8-4ECE-991B-AF1AC9087A45@gmail.com> References: <77FA386512F0D748BC7C02C36EB1106D921776@szxeml557-mbs.china.huawei.com> <6426.1422664463@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com> <54E7219B.6040006@gridmerge.com> <54E72846.20807@gmx.net> <54E7824A.4040906@gmail.com> <54E86F9A.8020104@gmx.net> <54E8D442.6020909@gmail.com> <54EB4F24.7030609@gmx.net> <54EE6E31.8030609@gmail.com> <54F5E2FF.4040205@gmx.net> To: Hannes Tschofenig , Brian E Carpenter X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: consultancy@vanderstok.org, 6tisch-security <6tisch-security@ietf.org>, Michael Richardson , "Hedanping \(Ana\)" , Robert Cragie , sarikaya@ieee.org, "6lo@ietf.org" <6lo@ietf.org>, "anima@ietf.org" Subject: Re: [Anima] [6lo] Thread [Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things] 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, 03 Mar 2015 17:22:32 -0000 Brian, Hannes ... > On Mar 3, 2015, at 11:36 AM 3/3/15, Hannes Tschofenig = wrote: >=20 > At the moment the specifications are only available to Thread members > since the specification is still work in progress. >=20 > I don't know when it will be finalized and released to the wider = public. >=20 > Regarding the liaison I do not have an opinion about the value of it. >=20 > Ciao > Hannes >=20 >=20 > On 02/26/2015 01:52 AM, Brian E Carpenter wrote: >> On 26/02/2015 10:25, Behcet Sarikaya wrote: >>=20 >> ... >>>>> I know nothing about Thread, whatever and whoever it is. >>>>=20 >>>> Here is an intro document: >>>> http://threadgroup.org/Portals/0/documents/events/ThreadIntro.pdf >>=20 >> Thanks for that. It seems to have all the downsides of secretive ad = hoc >> membership-based consortia, except for the upside of a RAND-RF IPR >> policy. >>=20 >>> I think we need to clarify here that Thread Group is formed to deal >>> with home environments. >>>=20 >>> Enterprise or industrial environments seem to be excluded. >>=20 >> So far. The boundary between this and larger building services >> networks is pretty fuzzy, isn't it? >>=20 >> In any case, should we (the WGs on copy, and perhaps some others) >> be asking the IAB to arrange a meaningful liaison with Thread? I've opened a discussion within the IAB Liaison Oversight program = regarding establishment of a liaison relationship with Thread. - Ralph >>=20 >> Back at Hannes: is there a spec for their approach to security >> enrollment? >>=20 >> Brian >>=20 >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >>=20 >=20 > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo From nobody Tue Mar 3 11:35: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 7652D1A88BC; Tue, 3 Mar 2015 11:34:56 -0800 (PST) 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 S5B0iSbxFtCK; Tue, 3 Mar 2015 11:34:55 -0800 (PST) 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 BFA981A1BAC; Tue, 3 Mar 2015 11:34:54 -0800 (PST) Received: by pdbfl12 with SMTP id fl12so19631706pdb.5; Tue, 03 Mar 2015 11:34:54 -0800 (PST) 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=vpGAIREio1DPxlIUle2nu30xU33j5GAbJGaxC2f09/k=; b=oXawI2icKNXyCsmdHR5bSDzKQPvZc1Y/KHHEk4IhVLWoAoeqj7HQzSLCXgZMvM2Vy4 8lme4Ih0QEPLl18UCGCmONemliFQqGqIsqI4CiJ5vCL6zeHVMxSTkEz17id8DTSTnm6t AdZTffBBSsEadKUPeCeaeASqlPyDm7Mbp0yu1NiK8q/P1yWNzEJ453oV1VLP6v0SINiW Kn4iBHg4dvtIwnOqk5T+UBdYX2tlDW41f5q6IxS6ytnF9wQxwhWa9q73jyquMG4zi70e mHJ8ygh3s6TMjl64wC/6V6dTMLoMU8h0xK6c8M7vtJB2soAo4KHN2+eyclm9BupfU2tp wWUQ== X-Received: by 10.66.221.227 with SMTP id qh3mr631438pac.1.1425411294032; Tue, 03 Mar 2015 11:34:54 -0800 (PST) Received: from ?IPv6:2406:e007:4f85:1:28cc:dc4c:9703:6781? ([2406:e007:4f85:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id vf6sm1790073pbc.18.2015.03.03.11.34.48 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Mar 2015 11:34:52 -0800 (PST) Message-ID: <54F60CD2.7030001@gmail.com> Date: Wed, 04 Mar 2015 08:34:42 +1300 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.5.0 MIME-Version: 1.0 To: Hannes Tschofenig , sarikaya@ieee.org References: <77FA386512F0D748BC7C02C36EB1106D921776@szxeml557-mbs.china.huawei.com> <6426.1422664463@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com> <54E7219B.6040006@gridmerge.com> <54E72846.20807@gmx.net> <54E7824A.4040906@gmail.com> <54E86F9A.8020104@gmx.net> <54E8D442.6020909@gmail.com> <54EB4F24.7030609@gmx.net> <54EE6E31.8030609@gmail.com> <54F5E2FF.4040205@gmx.net> In-Reply-To: <54F5E2FF.4040205@gmx.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: consultancy@vanderstok.org, 6tisch-security <6tisch-security@ietf.org>, Michael Richardson , "Hedanping \(Ana\)" , robert.cragie@gridmerge.com, "6lo@ietf.org" <6lo@ietf.org>, "anima@ietf.org" Subject: Re: [Anima] Thread [Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things] 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, 03 Mar 2015 19:34:56 -0000 On 04/03/2015 05:36, Hannes Tschofenig wrote: > At the moment the specifications are only available to Thread members > since the specification is still work in progress. > > I don't know when it will be finalized and released to the wider public. > > Regarding the liaison I do not have an opinion about the value of it. It is precisely to get access before the work is finalised, so that it can be reviewed by all the right people. We know that closed standards development produces bad standards. Brian > Ciao > Hannes > > > On 02/26/2015 01:52 AM, Brian E Carpenter wrote: >> On 26/02/2015 10:25, Behcet Sarikaya wrote: >> >> ... >>>>> I know nothing about Thread, whatever and whoever it is. >>>> >>>> Here is an intro document: >>>> http://threadgroup.org/Portals/0/documents/events/ThreadIntro.pdf >> >> Thanks for that. It seems to have all the downsides of secretive ad hoc >> membership-based consortia, except for the upside of a RAND-RF IPR >> policy. >> >>> I think we need to clarify here that Thread Group is formed to deal >>> with home environments. >>> >>> Enterprise or industrial environments seem to be excluded. >> >> So far. The boundary between this and larger building services >> networks is pretty fuzzy, isn't it? >> >> In any case, should we (the WGs on copy, and perhaps some others) >> be asking the IAB to arrange a meaningful liaison with Thread? >> >> Back at Hannes: is there a spec for their approach to security >> enrollment? >> >> Brian >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> > From nobody Tue Mar 3 13:30: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 D5C3D1ACD0C; Tue, 3 Mar 2015 13:30:12 -0800 (PST) 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 2Wk4nvSkofNM; Tue, 3 Mar 2015 13:30:08 -0800 (PST) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::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 D4F8B1ACCE2; Tue, 3 Mar 2015 13:30:07 -0800 (PST) Received: by igkb16 with SMTP id b16so31772229igk.1; Tue, 03 Mar 2015 13:30:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=hgiv8ugGdIEVlg9Bmf6uFvz+ErnJ1JGvcmIOKeGF2Pk=; b=P6/SEZ+Grc4hG1QqgJoDZmhBxW7l4MOVfoSndziWGy6j1yhdm3AsnZPypsd4CXwYm1 MWzC7Ln6eLOhA604LhUBZVIhWLvLw7l+P8GFZr9dXPsGtSeCPQ5oGeL/AMO75tGPaQde VYkr+nA9lxgiSMK0MESpxM7BfCetEvehApTmvDW6pWmTeLbTDv4GKr7nEus+GFFNTUZ2 3gUZlvTGhIWPb/7i3wyrH0l8GjMZQc7wqouu4YgkgNqsrsMWtVkg2UfuLvukkfFdozKs LRybn33rR6IL1MFw8E8HrPquziLwRiWSgLsaOOeOKk1Tig5qTJUELhb+9xyPpTQlA1Uv d55g== X-Received: by 10.107.133.220 with SMTP id p89mr4911598ioi.63.1425418206962; Tue, 03 Mar 2015 13:30:06 -0800 (PST) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id e196sm1642370ioe.40.2015.03.03.13.30.05 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Mar 2015 13:30:06 -0800 (PST) Message-ID: <54F627D2.5090806@gmail.com> Date: Tue, 03 Mar 2015 16:29:54 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Brian E Carpenter , Hannes Tschofenig , sarikaya@ieee.org References: <77FA386512F0D748BC7C02C36EB1106D921776@szxeml557-mbs.china.huawei.com> <6426.1422664463@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com> <54E7219B.6040006@gridmerge.com> <54E72846.20807@gmx.net> <54E7824A.4040906@gmail.com> <54E86F9A.8020104@gmx.net> <54E8D442.6020909@gmail.com> <54EB4F24.7030609@gmx.net> <54EE6E31.8030609@gmail.com> <54F5E2FF.4040205@gmx.net> <54F60CD2.7030001@gmail.com> In-Reply-To: <54F60CD2.7030001@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: consultancy@vanderstok.org, 6tisch-security <6tisch-security@ietf.org>, Michael Richardson , "Hedanping \(Ana\)" , robert.cragie@gridmerge.com, "6lo@ietf.org" <6lo@ietf.org>, "anima@ietf.org" Subject: [Anima] (Fair) competition in pursuing ideas and dreams is good (was: Re: [6tisch-security] Thread [Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things]) 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, 03 Mar 2015 21:30:13 -0000 Dear colleagues: I don't understand all the excitement here: everyone is free to draw up architectural blueprints and complete designs to their liking. This can be done in the attic, as company-internal project, with an industry consortium, or with SDOs, such as IETF. There is no way of knowing what people dream up in their attic or in a "secret" project X type of effort. Or, is the fear that IETF will loose its lustre? Competition (without bullying) is good and is an enticement to consider solid designs and thinking outside of the "we-did-this-20-years-ago-like-this-and-therefore-have-to-stick-to-this" box (the flaky ones will end up with marketing and PR departments of competing efforts to poke fun at). Best regards, Rene On 3/3/2015 2:34 PM, Brian E Carpenter wrote: > On 04/03/2015 05:36, Hannes Tschofenig wrote: >> At the moment the specifications are only available to Thread members >> since the specification is still work in progress. >> >> I don't know when it will be finalized and released to the wider public. >> >> Regarding the liaison I do not have an opinion about the value of it. > It is precisely to get access before the work is finalised, so that it > can be reviewed by all the right people. We know that closed standards > development produces bad standards. > > Brian > >> Ciao >> Hannes >> >> >> On 02/26/2015 01:52 AM, Brian E Carpenter wrote: >>> On 26/02/2015 10:25, Behcet Sarikaya wrote: >>> >>> ... >>>>>> I know nothing about Thread, whatever and whoever it is. >>>>> Here is an intro document: >>>>> http://threadgroup.org/Portals/0/documents/events/ThreadIntro.pdf >>> Thanks for that. It seems to have all the downsides of secretive ad hoc >>> membership-based consortia, except for the upside of a RAND-RF IPR >>> policy. >>> >>>> I think we need to clarify here that Thread Group is formed to deal >>>> with home environments. >>>> >>>> Enterprise or industrial environments seem to be excluded. >>> So far. The boundary between this and larger building services >>> networks is pretty fuzzy, isn't it? >>> >>> In any case, should we (the WGs on copy, and perhaps some others) >>> be asking the IAB to arrange a meaningful liaison with Thread? >>> >>> Back at Hannes: is there a spec for their approach to security >>> enrollment? >>> >>> Brian >>> >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima >>> > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From nobody Tue Mar 3 14:06: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 D80691ACDE3; Tue, 3 Mar 2015 14:06:30 -0800 (PST) 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 bbjMy7UX7tie; Tue, 3 Mar 2015 14:06:28 -0800 (PST) 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 1DF131ACDE5; Tue, 3 Mar 2015 14:06:25 -0800 (PST) Received: by padfb1 with SMTP id fb1so18395220pad.7; Tue, 03 Mar 2015 14:06:24 -0800 (PST) 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=b5Zwk1+kac9uMKQstRi5lX6XxUQbq1u6ElFemF+UDlg=; b=u+wY535A9FM/z39kAuBKHer7DkQdOHAEceXirAyQ1CPyf/xVcDZYuoxfCET6HP+PpQ WKQ5JuSdXIWmnrF/oFLMGJ5FWqA+YpCRBRWgiS0UcjUPuk/P4XGX+drQePbagsZBWa1X eOwO6+WZ4KeRfHQdxTeZMLgLNFAQY+JlOx5+WaKQBNPKT/LkgbQXysuFpsBi+Mm6C0Dt 1vu087ghkR6MFkYwuGcxb5BaM4ChhPKG4H0hAKHHk/bZY9nF09P70tKOsZyVGUKNf0sf gszeyzk4b2y6546P3ZRqp+cuBNgEezSbD6LQ0wl3v/bvzjWb70wDrbqjtXwxhVZXCJr4 sTNw== X-Received: by 10.66.218.10 with SMTP id pc10mr1551637pac.116.1425420384329; Tue, 03 Mar 2015 14:06:24 -0800 (PST) Received: from ?IPv6:2406:e007:4f85:1:28cc:dc4c:9703:6781? ([2406:e007:4f85:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id bc5sm1927351pdb.47.2015.03.03.14.06.18 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Mar 2015 14:06:23 -0800 (PST) Message-ID: <54F6305E.8060704@gmail.com> Date: Wed, 04 Mar 2015 11:06:22 +1300 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.5.0 MIME-Version: 1.0 To: Rene Struik , Hannes Tschofenig , sarikaya@ieee.org References: <77FA386512F0D748BC7C02C36EB1106D921776@szxeml557-mbs.china.huawei.com> <6426.1422664463@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com> <54E7219B.6040006@gridmerge.com> <54E72846.20807@gmx.net> <54E7824A.4040906@gmail.com> <54E86F9A.8020104@gmx.net> <54E8D442.6020909@gmail.com> <54EB4F24.7030609@gmx.net> <54EE6E31.8030609@gmail.com> <54F5E2FF.4040205@gmx.net> <54F60CD2.7030001@gmail.com> <54F627D2.5090806@gmail.com> In-Reply-To: <54F627D2.5090806@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: consultancy@vanderstok.org, 6tisch-security <6tisch-security@ietf.org>, Michael Richardson , "Hedanping \(Ana\)" , robert.cragie@gridmerge.com, "6lo@ietf.org" <6lo@ietf.org>, "anima@ietf.org" Subject: Re: [Anima] (Fair) competition in pursuing ideas and dreams is good 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, 03 Mar 2015 22:06:31 -0000 Regards Brian Carpenter http://orcid.org/0000-0001-7924-6182 On 04/03/2015 10:29, Rene Struik wrote: > Dear colleagues: > > I don't understand all the excitement here: everyone is free to draw up > architectural blueprints and complete designs to their liking. This can > be done in the attic, as company-internal project, with an industry > consortium, or with SDOs, such as IETF. There is no way of knowing what > people dream up in their attic or in a "secret" project X type of > effort. Or, is the fear that IETF will loose its lustre? No. The fear (and it has been realised many times in the past) is that a closed consortium will agree on and start shipping a solution which does not mesh well with the rest of the Internet. A liaison arrangement can help to avoid that. Brian > Competition (without bullying) is good and is an enticement to consider > solid designs and thinking outside of the > "we-did-this-20-years-ago-like-this-and-therefore-have-to-stick-to-this" > box (the flaky ones will end up with marketing and PR departments of > competing efforts to poke fun at). > > Best regards, Rene > > > On 3/3/2015 2:34 PM, Brian E Carpenter wrote: >> On 04/03/2015 05:36, Hannes Tschofenig wrote: >>> At the moment the specifications are only available to Thread members >>> since the specification is still work in progress. >>> >>> I don't know when it will be finalized and released to the wider public. >>> >>> Regarding the liaison I do not have an opinion about the value of it. >> It is precisely to get access before the work is finalised, so that it >> can be reviewed by all the right people. We know that closed standards >> development produces bad standards. >> >> Brian >> >>> Ciao >>> Hannes >>> >>> >>> On 02/26/2015 01:52 AM, Brian E Carpenter wrote: >>>> On 26/02/2015 10:25, Behcet Sarikaya wrote: >>>> >>>> ... >>>>>>> I know nothing about Thread, whatever and whoever it is. >>>>>> Here is an intro document: >>>>>> http://threadgroup.org/Portals/0/documents/events/ThreadIntro.pdf >>>> Thanks for that. It seems to have all the downsides of secretive ad hoc >>>> membership-based consortia, except for the upside of a RAND-RF IPR >>>> policy. >>>> >>>>> I think we need to clarify here that Thread Group is formed to deal >>>>> with home environments. >>>>> >>>>> Enterprise or industrial environments seem to be excluded. >>>> So far. The boundary between this and larger building services >>>> networks is pretty fuzzy, isn't it? >>>> >>>> In any case, should we (the WGs on copy, and perhaps some others) >>>> be asking the IAB to arrange a meaningful liaison with Thread? >>>> >>>> Back at Hannes: is there a spec for their approach to security >>>> enrollment? >>>> >>>> Brian >>>> >>>> _______________________________________________ >>>> Anima mailing list >>>> Anima@ietf.org >>>> https://www.ietf.org/mailman/listinfo/anima >>>> >> _______________________________________________ >> 6tisch-security mailing list >> 6tisch-security@ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch-security > > From nobody Tue Mar 3 16:39: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 000051A88E7 for ; Tue, 3 Mar 2015 16:38:58 -0800 (PST) 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 UTf9VHEFO1bw for ; Tue, 3 Mar 2015 16:38:57 -0800 (PST) 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 6EE191A887A for ; Tue, 3 Mar 2015 16:38:55 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPV92256; Wed, 04 Mar 2015 00:38:53 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Mar 2015 00:38:53 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.106]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Wed, 4 Mar 2015 08:38:45 +0800 From: Sheng Jiang To: Ted Lemon Thread-Topic: [Anima] DNA Thread-Index: AQHQVUmKEm8UJIU2q0asUAKi3f9lvJ0Je/eAgAALqACAAI8doIAAGf6AgAFJMfA= Date: Wed, 4 Mar 2015 00:38:44 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923B05522F@nkgeml512-mbx.china.huawei.com> References: <54F50116.9000501@gmail.com> <46E8AE45-3B6A-4CA0-92EA-F5E463C1D47C@fugue.com> <54F5205C.9020302@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B923B054B46@nkgeml512-mbx.china.huawei.com> <295A41C5-166E-4AF4-A04D-83A575CEA277@fugue.com> In-Reply-To: <295A41C5-166E-4AF4-A04D-83A575CEA277@fugue.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] DNA 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, 04 Mar 2015 00:38:59 -0000 Pk9uIE1hciAyLCAyMDE1LCBhdCAxMDoyMyBQTSwgU2hlbmcgSmlhbmcgPGppYW5nc2hlbmdAaHVh d2VpLmNvbT4gd3JvdGU6DQo+PiBXaGVyZSBjYW4gd2UgbWFrZSB0aGVtIG1hbmRhdG9yeT8gWWVz LCB0aGV5IGFyZSByZWFzb25hYmxlIGZ1bmN0aW9ucw0KPmZvciBhdXRvbm9taWMgbm9kZXMuIEJ1 dCB3ZSBkbyBub3QgaGF2ZSBhbiBpbnRlZ3JhdGVkIHJlcXVpcmVtZW50cyBmb3INCj5hdXRvbm9t aWMgbm9kZXMsIG5laXRoZXIgZm9yIGF1dG9ub21pYyBuZXR3b3JrIGFyY2hpdGVjdHVyZS4gVGhl IG9ubHkNCj5vcGluaW9uIEkgY2FuIHRoaW5rIG91dCBpcyB0byByZWRlc2lnbiB0aGUgbWVjaGFu aXNtcyBhbmQgdHJ5IHRvIGVtYmVkIHRoZW0NCj5pbnRvIEFOSU1BIFByb3RvY29scywgZm9yIHdo aWNoIEkgZG9uJ3QgdGhpbmsgaXMgcmlnaHQgdGhpbmcgdG8gZG8uDQo+DQo+V2h5IG5vdCBtYWtl IHRoZSBvbmVzIHRoYXQgYXJlIGRlcGVuZGFibGUgbWFuZGF0b3J5PyAgIERvIHlvdSB0aGluayB0 aGF0DQo+bGF5ZXIgMiBzdHVmZiBzaG91bGRuJ3QgYmUgbWVudGlvbmVkIGluIEFuaW1hIGRvY3Vt ZW50cz8gICANCg0KT2YgY291cnNlLCB0aGVyZSBpcyBubyBhbnkgcmVzdHJpY3Rpb24gdGhhdCBs YXllciAyIHN0dWZmIHNob3VsZG4ndCBiZSBtZW50aW9uZWQgaW4gQW5pbWEgZG9jdW1lbnRzLiBN eSBwb2ludCB3YXMgdGhlcmUgaXMgbm90IGEgc3VpdGFibGUgZG9jdW1lbnQgaW4gb3VyIGN1cnJl bnQgcGxhbiBkZWxpdmVyYWJsZXMgdG8gY29udGFpbiB0aGlzIG1hbmRhdG9yeS4gV2UgZG8gbm90 IGhhdmUgYSBkb2N1bWVudCBmb3IgcmVxdWlyZW1lbnRzIG9mIEFOSU1BIGRldmljZXMsIG5laXRo ZXIgZm9yIEFOSU1BIGFyY2hpdGVjdHVyZS4gUmVmZXJlbmNlIG1vZGVsIG1heSBiZSBhIGRvY3Vt ZW50IHRvIG1lbnRpb24gaXQsIGJ1dCBpdCBpcyBhbiBpbmZvcm1hdGlvbmFsIGRvY3VtZW50LCB3 aGljaCBjYW5ub3QgbWFrZSBhbnkgbWFuZGF0b3J5IHJlcXVpcmVtZW50cy4NCg0KT2YgY291cnNl LCB3ZSBjYW4gaGF2ZSBhIG5ldyBkb2N1bWVudCBmb3IgdGhpcyBhbmQgZm9yIG90aGVyIHJlcXVp cmVtZW50cyBvZiBBTklNQSBkZXZpY2VzLiBBbmQgd2UgY291bGQgbWFrZSBpdCBtaWxlc3RvbmUg bGF0ZXIgd2l0aCBhcHByb3ZhbCBmcm9tIHRoZSByZXNwb25zaWJsZSBBcmVhIERpcmVjdG9yIG9y IGJ5IHJlLWNoYXJ0ZXJpbmcuIEJ1dCBJIGRvbid0IHRoaW5rIHdlIGhhdmUga25vdyBlbm91Z2gg dG8gbWFrZSBhIGZ1bGwgcmVxdWlyZW1lbnRzIHlldC4NCg0KQmVzdCByZWdhcmRzLA0KDQpTaGVu Zw0KDQo+RE5BIG1ha2VzDQo+c3RhY2tzJyBiZWhhdmlvciBhIGxvdCBiZXR0ZXIgaW4gZ2VuZXJh bCwgYWx0aG91Z2ggb2NjYXNpb25hbGx5IGl0IGNhbiByZXN1bHQgaW4NCj51bm5lY2Vzc2FyeSBi cmllZiBvdXRhZ2VzIHdoZW4gYSBjYWJsZSBpcyB1bnBsdWdnZWQgYW5kIHBsdWdnZWQgYmFjayBp biB0bw0KPnRoZSBzYW1lIG5ldHdvcmssIGJ1dCBmb3IgQW5pbWEgZGV2aWNlcyBpc24ndCB0aGlz IGtpbmQgb2YgYSBub24tcHJvYmxlbT8NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPkFuaW1hIG1haWxpbmcgbGlzdA0KPkFuaW1hQGlldGYub3Jn DQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYQ0K From nobody Tue Mar 3 17:22: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 997191A8A14; Tue, 3 Mar 2015 17:22:33 -0800 (PST) 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 xis2mLUpONAn; Tue, 3 Mar 2015 17:22:31 -0800 (PST) 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 651421A89B0; Tue, 3 Mar 2015 17:22:29 -0800 (PST) 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 BPV94301; Wed, 04 Mar 2015 01:22:27 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Mar 2015 01:22:25 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.106]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Wed, 4 Mar 2015 09:22:15 +0800 From: Sheng Jiang To: Brian E Carpenter , Rene Struik , Hannes Tschofenig , "sarikaya@ieee.org" Thread-Topic: [Anima] (Fair) competition in pursuing ideas and dreams is good Thread-Index: AQHQVf5Yt+Bbp/HXr028aaO2paWO+Z0Lg/Fw Date: Wed, 4 Mar 2015 01:22:15 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923B0552CD@nkgeml512-mbx.china.huawei.com> References: <77FA386512F0D748BC7C02C36EB1106D921776@szxeml557-mbs.china.huawei.com> <6426.1422664463@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com> <54E7219B.6040006@gridmerge.com> <54E72846.20807@gmx.net> <54E7824A.4040906@gmail.com> <54E86F9A.8020104@gmx.net> <54E8D442.6020909@gmail.com> <54EB4F24.7030609@gmx.net> <54EE6E31.8030609@gmail.com> <54F5E2FF.4040205@gmx.net> <54F60CD2.7030001@gmail.com> <54F627D2.5090806@gmail.com> <54F6305E.8060704@gmail.com> In-Reply-To: <54F6305E.8060704@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: "consultancy@vanderstok.org" , 6tisch-security <6tisch-security@ietf.org>, Michael Richardson , "Hedanping \(Ana\)" , "robert.cragie@gridmerge.com" , "6lo@ietf.org" <6lo@ietf.org>, "anima@ietf.org" Subject: Re: [Anima] (Fair) competition in pursuing ideas and dreams is good 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, 04 Mar 2015 01:22:33 -0000 Pk9uIDA0LzAzLzIwMTUgMTA6MjksIFJlbmUgU3RydWlrIHdyb3RlOg0KPj4gRGVhciBjb2xsZWFn dWVzOg0KPj4NCj4+IEkgZG9uJ3QgdW5kZXJzdGFuZCBhbGwgdGhlIGV4Y2l0ZW1lbnQgaGVyZTog ZXZlcnlvbmUgaXMgZnJlZSB0byBkcmF3IHVwDQo+PiBhcmNoaXRlY3R1cmFsIGJsdWVwcmludHMg YW5kIGNvbXBsZXRlIGRlc2lnbnMgdG8gdGhlaXIgbGlraW5nLiBUaGlzIGNhbg0KPj4gYmUgZG9u ZSBpbiB0aGUgYXR0aWMsIGFzIGNvbXBhbnktaW50ZXJuYWwgcHJvamVjdCwgd2l0aCBhbiBpbmR1 c3RyeQ0KPj4gY29uc29ydGl1bSwgb3Igd2l0aCBTRE9zLCBzdWNoIGFzIElFVEYuIFRoZXJlIGlz ICBubyB3YXkgb2Yga25vd2luZyB3aGF0DQo+PiBwZW9wbGUgZHJlYW0gdXAgaW4gdGhlaXIgYXR0 aWMgb3IgaW4gYSAic2VjcmV0IiBwcm9qZWN0IFggdHlwZSBvZg0KPj4gZWZmb3J0LiBPciwgaXMg dGhlIGZlYXIgdGhhdCBJRVRGIHdpbGwgbG9vc2UgaXRzIGx1c3RyZT8NCj4NCj5Oby4gVGhlIGZl YXIgKGFuZCBpdCBoYXMgYmVlbiByZWFsaXNlZCBtYW55IHRpbWVzIGluIHRoZSBwYXN0KSBpcw0K PnRoYXQgYSBjbG9zZWQgY29uc29ydGl1bSB3aWxsIGFncmVlIG9uIGFuZCBzdGFydCBzaGlwcGlu ZyBhIHNvbHV0aW9uDQo+d2hpY2ggZG9lcyBub3QgbWVzaCB3ZWxsIHdpdGggdGhlIHJlc3Qgb2Yg dGhlIEludGVybmV0LiBBIGxpYWlzb24NCj5hcnJhbmdlbWVudCBjYW4gaGVscCB0byBhdm9pZCB0 aGF0Lg0KDQpUaGUgSUVURiBpcyBtYWlubHkgYSBzdGFuZGFyZGl6YXRpb24gb3JnYW5pemF0aW9u LiBNb3N0IG9mIGVmZm9ydHMgaW4gSUVURiBpcyBmb3IgaW50ZXJvcGVyYXRpb24uIElFVEYgcHJv ZHVjZXMgYSBidW5jaCBvZiBvcGVuIHN0YW5kYXJkcywgbm8gc2VjcmV0IGF0IGFsbC4gVGhlbiBl dmVyeSBjb21wYW55IGNhbiBpbXBsZW1lbnRhdGlvbiB0aGUgaW50ZXJmYWNlIGZvbGxvd2luZyB0 aGVzZSBzdGFuZGFyZHMuIE9mIGNvdXJzZSwgdGhlcmUgYXJlIG1hbnkgaW50ZXJuYWwgaW1wbGVt ZW50YXRpb24sIHdoaWNoIGRvZXMgbm90IG5lZWQgaW50ZXJvcGVyYXRpb24gd2l0aCBvdGhlciBk ZXZpY2VzLCBhbmQgdGhleSBjYW4gYmUgY2xvc2VkIG9yIHNlY3JldC4gRGV2aWNlcyBjYW4gdGhl biBpbnRlcm9wZXJhdGUgd2l0aCBlYWNoIG90aGVyIGFzIGxvbmcgYXMgdGhlIGFsbCBmb2xsb3dp bmcgdGhlIHNhbWUgc3RhbmRhcmRzLg0KDQpDb25zZXF1ZW50bHksIHRoZSBtYWluIGVmZm9ydHMg b2Ygc3RhbmRhcmRpemF0aW9uIGFjdHVhbGx5IGNvbXByb21pc2UgcmF0aGVyIHRoYW4gY29tcGV0 aXRpb24uIEl0IGlzIGFsbCBwYXJ0aWNpcGF0b3JzIHRvIHdvcmsgdG9nZXRoZXIgdG93YXJkcyBh IGNvbnNlbnN1cywgd2hpY2ggbW9zdCBvZiBwZW9wbGUgY291bGQgbGl2ZSB3aXRoIChpbiB3aGlj aCBtYXliZSBldmVyeWJvZHkgaGF2ZSBzb21ldGhpbmcgdW5zYXRpc2ZpZWQuKSBTbywgcGVvcGxl IGFyZSBlbmNvdXJhZ2VkIHRvIGRpc2N1c3MsIGNvb3JkaW5hdGUsIG1lcmdlIGFuZCBtYWtlIGNv bXByb21pc2VzLiBXb3JraW5nIGFsb25nIGFuZCBwcm9kdWNpbmcgc2V2ZXJhbCBjb21wZXRpdGlv biBzb2x1dGlvbnMgd291bGQgTk9UIGJlIGdvb2QgaW4gYW55IHN0YW5kYXJkaXphdGlvbiBvcmdh bml6YXRpb25zLg0KDQo+ICAgIEJyaWFuDQo+DQo+PiBDb21wZXRpdGlvbiAod2l0aG91dCBidWxs eWluZykgaXMgZ29vZCBhbmQgaXMgYW4gZW50aWNlbWVudCB0byBjb25zaWRlcg0KPj4gc29saWQg ZGVzaWducyBhbmQgdGhpbmtpbmcgb3V0c2lkZSBvZiB0aGUNCj4+ICJ3ZS1kaWQtdGhpcy0yMC15 ZWFycy1hZ28tbGlrZS10aGlzLWFuZC10aGVyZWZvcmUtaGF2ZS10by1zdGljay10by10aGlzIg0K Pj4gYm94ICh0aGUgZmxha3kgb25lcyB3aWxsIGVuZCB1cCB3aXRoIG1hcmtldGluZyBhbmQgUFIg ZGVwYXJ0bWVudHMgb2YNCj4+IGNvbXBldGluZyBlZmZvcnRzIHRvIHBva2UgZnVuIGF0KS4NCj4+ DQo+PiBCZXN0IHJlZ2FyZHMsIFJlbmUNCj4+DQo+Pg0KPj4gT24gMy8zLzIwMTUgMjozNCBQTSwg QnJpYW4gRSBDYXJwZW50ZXIgd3JvdGU6DQo+Pj4gT24gMDQvMDMvMjAxNSAwNTozNiwgSGFubmVz IFRzY2hvZmVuaWcgd3JvdGU6DQo+Pj4+IEF0IHRoZSBtb21lbnQgdGhlIHNwZWNpZmljYXRpb25z IGFyZSBvbmx5IGF2YWlsYWJsZSB0byBUaHJlYWQgbWVtYmVycw0KPj4+PiBzaW5jZSB0aGUgc3Bl Y2lmaWNhdGlvbiBpcyBzdGlsbCB3b3JrIGluIHByb2dyZXNzLg0KPj4+Pg0KPj4+PiBJIGRvbid0 IGtub3cgd2hlbiBpdCB3aWxsIGJlIGZpbmFsaXplZCBhbmQgcmVsZWFzZWQgdG8gdGhlIHdpZGVy IHB1YmxpYy4NCj4+Pj4NCj4+Pj4gUmVnYXJkaW5nIHRoZSBsaWFpc29uIEkgZG8gbm90IGhhdmUg YW4gb3BpbmlvbiBhYm91dCB0aGUgdmFsdWUgb2YgaXQuDQo+Pj4gSXQgaXMgcHJlY2lzZWx5IHRv IGdldCBhY2Nlc3MgYmVmb3JlIHRoZSB3b3JrIGlzIGZpbmFsaXNlZCwgc28gdGhhdCBpdA0KPj4+ IGNhbiBiZSByZXZpZXdlZCBieSBhbGwgdGhlIHJpZ2h0IHBlb3BsZS4gV2Uga25vdyB0aGF0IGNs b3NlZCBzdGFuZGFyZHMNCj4+PiBkZXZlbG9wbWVudCBwcm9kdWNlcyBiYWQgc3RhbmRhcmRzLg0K Pj4+DQo+Pj4gICAgICBCcmlhbg0KPj4+DQo+Pj4+IENpYW8NCj4+Pj4gSGFubmVzDQo+Pj4+DQo+ Pj4+DQo+Pj4+IE9uIDAyLzI2LzIwMTUgMDE6NTIgQU0sIEJyaWFuIEUgQ2FycGVudGVyIHdyb3Rl Og0KPj4+Pj4gT24gMjYvMDIvMjAxNSAxMDoyNSwgQmVoY2V0IFNhcmlrYXlhIHdyb3RlOg0KPj4+ Pj4NCj4+Pj4+IC4uLg0KPj4+Pj4+Pj4gSSBrbm93IG5vdGhpbmcgYWJvdXQgVGhyZWFkLCB3aGF0 ZXZlciBhbmQgd2hvZXZlciBpdCBpcy4NCj4+Pj4+Pj4gSGVyZSBpcyBhbiBpbnRybyBkb2N1bWVu dDoNCj4+Pj4+Pj4gaHR0cDovL3RocmVhZGdyb3VwLm9yZy9Qb3J0YWxzLzAvZG9jdW1lbnRzL2V2 ZW50cy9UaHJlYWRJbnRyby5wZGYNCj4+Pj4+IFRoYW5rcyBmb3IgdGhhdC4gSXQgc2VlbXMgdG8g aGF2ZSBhbGwgdGhlIGRvd25zaWRlcyBvZiBzZWNyZXRpdmUgYWQgaG9jDQo+Pj4+PiBtZW1iZXJz aGlwLWJhc2VkIGNvbnNvcnRpYSwgZXhjZXB0IGZvciB0aGUgdXBzaWRlIG9mIGEgUkFORC1SRiBJ UFINCj4+Pj4+IHBvbGljeS4NCj4+Pj4+DQo+Pj4+Pj4gSSB0aGluayB3ZSBuZWVkIHRvIGNsYXJp ZnkgaGVyZSB0aGF0IFRocmVhZCBHcm91cCBpcyBmb3JtZWQgdG8gZGVhbA0KPj4+Pj4+IHdpdGgg aG9tZSBlbnZpcm9ubWVudHMuDQo+Pj4+Pj4NCj4+Pj4+PiBFbnRlcnByaXNlIG9yIGluZHVzdHJp YWwgZW52aXJvbm1lbnRzIHNlZW0gdG8gYmUgZXhjbHVkZWQuDQo+Pj4+PiBTbyBmYXIuIFRoZSBi b3VuZGFyeSBiZXR3ZWVuIHRoaXMgYW5kIGxhcmdlciBidWlsZGluZyBzZXJ2aWNlcw0KPj4+Pj4g bmV0d29ya3MgaXMgcHJldHR5IGZ1enp5LCBpc24ndCBpdD8NCj4+Pj4+DQo+Pj4+PiBJbiBhbnkg Y2FzZSwgc2hvdWxkIHdlICh0aGUgV0dzIG9uIGNvcHksIGFuZCBwZXJoYXBzIHNvbWUgb3RoZXJz KQ0KPj4+Pj4gYmUgYXNraW5nIHRoZSBJQUIgdG8gYXJyYW5nZSBhIG1lYW5pbmdmdWwgbGlhaXNv biB3aXRoIFRocmVhZD8NCj4+Pj4+DQo+Pj4+PiBCYWNrIGF0IEhhbm5lczogaXMgdGhlcmUgYSBz cGVjIGZvciB0aGVpciBhcHByb2FjaCB0byBzZWN1cml0eQ0KPj4+Pj4gZW5yb2xsbWVudD8NCj4+ Pj4+DQo+Pj4+PiAgICAgQnJpYW4NCj4+Pj4+DQo+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4gQW5pbWEgbWFpbGluZyBsaXN0DQo+Pj4+ PiBBbmltYUBpZXRmLm9yZw0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9hbmltYQ0KPj4+Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4+IDZ0aXNjaC1zZWN1cml0eSBtYWlsaW5nIGxpc3QNCj4+PiA2dGlz Y2gtc2VjdXJpdHlAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvLzZ0aXNjaC1zZWN1cml0eQ0KPj4NCj4+DQo+DQo+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj5BbmltYSBtYWlsaW5nIGxpc3QNCj5BbmltYUBp ZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWENCg== From nobody Tue Mar 3 19:39: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 6F0C61A017A; Tue, 3 Mar 2015 19:38:59 -0800 (PST) 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 1K_Y0B_NDRKn; Tue, 3 Mar 2015 19:38:57 -0800 (PST) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::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 0AB141A0174; Tue, 3 Mar 2015 19:38:57 -0800 (PST) Received: by igal13 with SMTP id l13so30896960iga.1; Tue, 03 Mar 2015 19:38:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=eUM8iqJTtQtzYYqeEfpJg+kEfZdAYZV7QUzKKzyKOyY=; b=fsemaUC/TwtTkzS+x5g4xl+Evo9EGp5C+JMik2J5qnSbIERJN2zIV3vmqgx9XhdaZt p+jlGzgMArZCa6SnFWIVeciPEnDHK1Y8R8NKtKmqzOj2gzs7w+y3HrKwCwlmoeBymTDB LdRUJLP/oal9NYUDTllZcrcmU706bsc/o6mrYY+rd5L/LdcOcDpUf2fzCZayekzQxn+b q585rAgU1VSaiyD7y5vqrdfi2VTKoasYldRGpi3khzmebV2tvStOXfD8i2LgCFZtSOVL W2TqYsVnMpO19jXxKh/PsdpsCexYjPMzoI0Hmo8eMfDwBimhgIRr293lz3gaXhvYIa1/ +kFA== X-Received: by 10.50.79.161 with SMTP id k1mr7524021igx.14.1425440336536; Tue, 03 Mar 2015 19:38:56 -0800 (PST) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id t41sm2193205ioi.0.2015.03.03.19.38.55 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Mar 2015 19:38:56 -0800 (PST) Message-ID: <54F67E42.4090304@gmail.com> Date: Tue, 03 Mar 2015 22:38:42 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Sheng Jiang , Brian E Carpenter , Hannes Tschofenig , "sarikaya@ieee.org" References: <77FA386512F0D748BC7C02C36EB1106D921776@szxeml557-mbs.china.huawei.com> <6426.1422664463@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com> <54E7219B.6040006@gridmerge.com> <54E72846.20807@gmx.net> <54E7824A.4040906@gmail.com> <54E86F9A.8020104@gmx.net> <54E8D442.6020909@gmail.com> <54EB4F24.7030609@gmx.net> <54EE6E31.8030609@gmail.com> <54F5E2FF.4040205@gmx.net> <54F60CD2.7030001@gmail.com> <54F627D2.5090806@gmail.com> <54F6305E.8060704@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B923B0552CD@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923B0552CD@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "consultancy@vanderstok.org" , 6tisch-security <6tisch-security@ietf.org>, Michael Richardson , "Hedanping \(Ana\)" , "robert.cragie@gridmerge.com" , "6lo@ietf.org" <6lo@ietf.org>, "anima@ietf.org" Subject: Re: [Anima] (Fair) competition in pursuing ideas and dreams is good 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, 04 Mar 2015 03:38:59 -0000 Hi Sheng: I think you quite misinterpreted my email: I was just commenting on guessing games re what industry consortia or others may have up their sleeves (not easy to control or influence). From the numerous emails, I got the impression that "Thread" was actually spelled as "Threat". This email exchange would never have happened if it would have been another "Attic project X". Of course, all goodies re striving for convergence and for consensus apply (where discussion re relative technical merit could be viewed as competition of ideas [and what IETF often does quite liberally]). Rene On 3/3/2015 8:22 PM, Sheng Jiang wrote: >> On 04/03/2015 10:29, Rene Struik wrote: >>> Dear colleagues: >>> >>> I don't understand all the excitement here: everyone is free to draw up >>> architectural blueprints and complete designs to their liking. This can >>> be done in the attic, as company-internal project, with an industry >>> consortium, or with SDOs, such as IETF. There is no way of knowing what >>> people dream up in their attic or in a "secret" project X type of >>> effort. Or, is the fear that IETF will loose its lustre? >> No. The fear (and it has been realised many times in the past) is >> that a closed consortium will agree on and start shipping a solution >> which does not mesh well with the rest of the Internet. A liaison >> arrangement can help to avoid that. > The IETF is mainly a standardization organization. Most of efforts in IETF is for interoperation. IETF produces a bunch of open standards, no secret at all. Then every company can implementation the interface following these standards. Of course, there are many internal implementation, which does not need interoperation with other devices, and they can be closed or secret. Devices can then interoperate with each other as long as the all following the same standards. > > Consequently, the main efforts of standardization actually compromise rather than competition. It is all participators to work together towards a consensus, which most of people could live with (in which maybe everybody have something unsatisfied.) So, people are encouraged to discuss, coordinate, merge and make compromises. Working along and producing several competition solutions would NOT be good in any standardization organizations. > >> Brian >> >>> Competition (without bullying) is good and is an enticement to consider >>> solid designs and thinking outside of the >>> "we-did-this-20-years-ago-like-this-and-therefore-have-to-stick-to-this" >>> box (the flaky ones will end up with marketing and PR departments of >>> competing efforts to poke fun at). >>> >>> Best regards, Rene >>> >>> >>> On 3/3/2015 2:34 PM, Brian E Carpenter wrote: >>>> On 04/03/2015 05:36, Hannes Tschofenig wrote: >>>>> At the moment the specifications are only available to Thread members >>>>> since the specification is still work in progress. >>>>> >>>>> I don't know when it will be finalized and released to the wider public. >>>>> >>>>> Regarding the liaison I do not have an opinion about the value of it. >>>> It is precisely to get access before the work is finalised, so that it >>>> can be reviewed by all the right people. We know that closed standards >>>> development produces bad standards. >>>> >>>> Brian >>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> >>>>> On 02/26/2015 01:52 AM, Brian E Carpenter wrote: >>>>>> On 26/02/2015 10:25, Behcet Sarikaya wrote: >>>>>> >>>>>> ... >>>>>>>>> I know nothing about Thread, whatever and whoever it is. >>>>>>>> Here is an intro document: >>>>>>>> http://threadgroup.org/Portals/0/documents/events/ThreadIntro.pdf >>>>>> Thanks for that. It seems to have all the downsides of secretive ad hoc >>>>>> membership-based consortia, except for the upside of a RAND-RF IPR >>>>>> policy. >>>>>> >>>>>>> I think we need to clarify here that Thread Group is formed to deal >>>>>>> with home environments. >>>>>>> >>>>>>> Enterprise or industrial environments seem to be excluded. >>>>>> So far. The boundary between this and larger building services >>>>>> networks is pretty fuzzy, isn't it? >>>>>> >>>>>> In any case, should we (the WGs on copy, and perhaps some others) >>>>>> be asking the IAB to arrange a meaningful liaison with Thread? >>>>>> >>>>>> Back at Hannes: is there a spec for their approach to security >>>>>> enrollment? >>>>>> >>>>>> Brian >>>>>> >>>>>> _______________________________________________ >>>>>> Anima mailing list >>>>>> Anima@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/anima >>>>>> >>>> _______________________________________________ >>>> 6tisch-security mailing list >>>> 6tisch-security@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6tisch-security >>> >> _______________________________________________ >> 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 -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From nobody Tue Mar 3 21: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 7E80A1A038C; Tue, 3 Mar 2015 21:45:30 -0800 (PST) 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 PLwMUe2HA2Ek; Tue, 3 Mar 2015 21:45:28 -0800 (PST) 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 29E4F1A00B0; Tue, 3 Mar 2015 21:45:26 -0800 (PST) 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 BTG15547; Wed, 04 Mar 2015 05:45:24 +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; Wed, 4 Mar 2015 05:45:22 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.106]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Wed, 4 Mar 2015 13:45:13 +0800 From: Sheng Jiang To: Rene Struik , Brian E Carpenter , Hannes Tschofenig , "sarikaya@ieee.org" Thread-Topic: [Anima] (Fair) competition in pursuing ideas and dreams is good Thread-Index: AQHQVf5Yt+Bbp/HXr028aaO2paWO+Z0Lg/Fw//+jYQCAAJj6YA== Date: Wed, 4 Mar 2015 05:45:12 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923B0553F5@nkgeml512-mbx.china.huawei.com> References: <77FA386512F0D748BC7C02C36EB1106D921776@szxeml557-mbs.china.huawei.com> <6426.1422664463@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com> <54E7219B.6040006@gridmerge.com> <54E72846.20807@gmx.net> <54E7824A.4040906@gmail.com> <54E86F9A.8020104@gmx.net> <54E8D442.6020909@gmail.com> <54EB4F24.7030609@gmx.net> <54EE6E31.8030609@gmail.com> <54F5E2FF.4040205@gmx.net> <54F60CD2.7030001@gmail.com> <54F627D2.5090806@gmail.com> <54F6305E.8060704@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B923B0552CD@nkgeml512-mbx.china.huawei.com> <54F67E42.4090304@gmail.com> In-Reply-To: <54F67E42.4090304@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: "consultancy@vanderstok.org" , 6tisch-security <6tisch-security@ietf.org>, Michael Richardson , "Hedanping \(Ana\)" , "robert.cragie@gridmerge.com" , "6lo@ietf.org" <6lo@ietf.org>, "anima@ietf.org" Subject: Re: [Anima] (Fair) competition in pursuing ideas and dreams is good 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, 04 Mar 2015 05:45:30 -0000 PkkgdGhpbmsgeW91IHF1aXRlIG1pc2ludGVycHJldGVkIG15IGVtYWlsOiBJIHdhcyBqdXN0IGNv bW1lbnRpbmcgb24NCj5ndWVzc2luZyBnYW1lcyByZSB3aGF0IGluZHVzdHJ5IGNvbnNvcnRpYSBv ciBvdGhlcnMgbWF5IGhhdmUgdXAgdGhlaXINCj5zbGVldmVzIChub3QgZWFzeSB0byBjb250cm9s IG9yIGluZmx1ZW5jZSkuIEZyb20gdGhlIG51bWVyb3VzIGVtYWlscywgSQ0KPmdvdCB0aGUgaW1w cmVzc2lvbiB0aGF0ICJUaHJlYWQiIHdhcyBhY3R1YWxseSBzcGVsbGVkIGFzICJUaHJlYXQiLiBU aGlzDQo+ZW1haWwgZXhjaGFuZ2Ugd291bGQgbmV2ZXIgaGF2ZSBoYXBwZW5lZCBpZiBpdCB3b3Vs ZCBoYXZlIGJlZW4gYW5vdGhlcg0KPiJBdHRpYyBwcm9qZWN0IFgiLg0KDQpTb3JyeSBmb3IgbXkg bWlzaW50ZXJwcmV0LiBJIG1pc3NlZCBhbGwgdGhlIFRocmVhZCBkaXNjdXNzaW9uIGR1ZSB0byBt eSBDaGluZXNlIE5ldyBZZWFyIGhvbGlkYXlzLiBJIHdhcyBzdGlsbCBjYXRjaGluZyB1cC4gTXkg YXBvbG9naXplLg0KDQpGb3J0dW5hdGVseSwgSSBkaWQgbm90IHNheSBzb21ldGhpbmcgd3Jvbmcu IFdoYXQgSSBzYWlkIHJlZ2FyZGluZyB0byBJRVRGIHN0YW5kYXJkaXphdGlvbiwgaW50ZXJvcGVy YXRpb24sIGNvb3JkaW5hdGUsIGFuZCBjb21wcm9taXNlIGlzIGdlbmVyYWxseSByaWdodCBhbmQg Y2FuIGJlIGFwcGxpZWQuDQoNCkJlc3QgcmVnYXJkcywNCg0KU2hlbmcNCg0KPk9mIGNvdXJzZSwg YWxsIGdvb2RpZXMgcmUgc3RyaXZpbmcgZm9yIGNvbnZlcmdlbmNlIGFuZCBmb3IgY29uc2Vuc3Vz DQo+YXBwbHkgKHdoZXJlIGRpc2N1c3Npb24gcmUgcmVsYXRpdmUgdGVjaG5pY2FsIG1lcml0IGNv dWxkIGJlIHZpZXdlZCBhcw0KPmNvbXBldGl0aW9uIG9mIGlkZWFzIFthbmQgd2hhdCBJRVRGIG9m dGVuIGRvZXMgcXVpdGUgbGliZXJhbGx5XSkuDQo+DQo+UmVuZQ0KPg0KPk9uIDMvMy8yMDE1IDg6 MjIgUE0sIFNoZW5nIEppYW5nIHdyb3RlOg0KPj4+IE9uIDA0LzAzLzIwMTUgMTA6MjksIFJlbmUg U3RydWlrIHdyb3RlOg0KPj4+PiBEZWFyIGNvbGxlYWd1ZXM6DQo+Pj4+DQo+Pj4+IEkgZG9uJ3Qg dW5kZXJzdGFuZCBhbGwgdGhlIGV4Y2l0ZW1lbnQgaGVyZTogZXZlcnlvbmUgaXMgZnJlZSB0byBk cmF3IHVwDQo+Pj4+IGFyY2hpdGVjdHVyYWwgYmx1ZXByaW50cyBhbmQgY29tcGxldGUgZGVzaWdu cyB0byB0aGVpciBsaWtpbmcuIFRoaXMgY2FuDQo+Pj4+IGJlIGRvbmUgaW4gdGhlIGF0dGljLCBh cyBjb21wYW55LWludGVybmFsIHByb2plY3QsIHdpdGggYW4gaW5kdXN0cnkNCj4+Pj4gY29uc29y dGl1bSwgb3Igd2l0aCBTRE9zLCBzdWNoIGFzIElFVEYuIFRoZXJlIGlzICBubyB3YXkgb2Yga25v d2luZw0KPndoYXQNCj4+Pj4gcGVvcGxlIGRyZWFtIHVwIGluIHRoZWlyIGF0dGljIG9yIGluIGEg InNlY3JldCIgcHJvamVjdCBYIHR5cGUgb2YNCj4+Pj4gZWZmb3J0LiBPciwgaXMgdGhlIGZlYXIg dGhhdCBJRVRGIHdpbGwgbG9vc2UgaXRzIGx1c3RyZT8NCj4+PiBOby4gVGhlIGZlYXIgKGFuZCBp dCBoYXMgYmVlbiByZWFsaXNlZCBtYW55IHRpbWVzIGluIHRoZSBwYXN0KSBpcw0KPj4+IHRoYXQg YSBjbG9zZWQgY29uc29ydGl1bSB3aWxsIGFncmVlIG9uIGFuZCBzdGFydCBzaGlwcGluZyBhIHNv bHV0aW9uDQo+Pj4gd2hpY2ggZG9lcyBub3QgbWVzaCB3ZWxsIHdpdGggdGhlIHJlc3Qgb2YgdGhl IEludGVybmV0LiBBIGxpYWlzb24NCj4+PiBhcnJhbmdlbWVudCBjYW4gaGVscCB0byBhdm9pZCB0 aGF0Lg0KPj4gVGhlIElFVEYgaXMgbWFpbmx5IGEgc3RhbmRhcmRpemF0aW9uIG9yZ2FuaXphdGlv bi4gTW9zdCBvZiBlZmZvcnRzIGluIElFVEYgaXMNCj5mb3IgaW50ZXJvcGVyYXRpb24uIElFVEYg cHJvZHVjZXMgYSBidW5jaCBvZiBvcGVuIHN0YW5kYXJkcywgbm8gc2VjcmV0IGF0IGFsbC4NCj5U aGVuIGV2ZXJ5IGNvbXBhbnkgY2FuIGltcGxlbWVudGF0aW9uIHRoZSBpbnRlcmZhY2UgZm9sbG93 aW5nIHRoZXNlDQo+c3RhbmRhcmRzLiBPZiBjb3Vyc2UsIHRoZXJlIGFyZSBtYW55IGludGVybmFs IGltcGxlbWVudGF0aW9uLCB3aGljaCBkb2VzDQo+bm90IG5lZWQgaW50ZXJvcGVyYXRpb24gd2l0 aCBvdGhlciBkZXZpY2VzLCBhbmQgdGhleSBjYW4gYmUgY2xvc2VkIG9yIHNlY3JldC4NCj5EZXZp Y2VzIGNhbiB0aGVuIGludGVyb3BlcmF0ZSB3aXRoIGVhY2ggb3RoZXIgYXMgbG9uZyBhcyB0aGUg YWxsIGZvbGxvd2luZyB0aGUNCj5zYW1lIHN0YW5kYXJkcy4NCj4+DQo+PiBDb25zZXF1ZW50bHks IHRoZSBtYWluIGVmZm9ydHMgb2Ygc3RhbmRhcmRpemF0aW9uIGFjdHVhbGx5IGNvbXByb21pc2UN Cj5yYXRoZXIgdGhhbiBjb21wZXRpdGlvbi4gSXQgaXMgYWxsIHBhcnRpY2lwYXRvcnMgdG8gd29y ayB0b2dldGhlciB0b3dhcmRzIGENCj5jb25zZW5zdXMsIHdoaWNoIG1vc3Qgb2YgcGVvcGxlIGNv dWxkIGxpdmUgd2l0aCAoaW4gd2hpY2ggbWF5YmUgZXZlcnlib2R5DQo+aGF2ZSBzb21ldGhpbmcg dW5zYXRpc2ZpZWQuKSBTbywgcGVvcGxlIGFyZSBlbmNvdXJhZ2VkIHRvIGRpc2N1c3MsDQo+Y29v cmRpbmF0ZSwgbWVyZ2UgYW5kIG1ha2UgY29tcHJvbWlzZXMuIFdvcmtpbmcgYWxvbmcgYW5kIHBy b2R1Y2luZw0KPnNldmVyYWwgY29tcGV0aXRpb24gc29sdXRpb25zIHdvdWxkIE5PVCBiZSBnb29k IGluIGFueSBzdGFuZGFyZGl6YXRpb24NCj5vcmdhbml6YXRpb25zLg0KPj4NCj4+PiAgICAgQnJp YW4NCj4+Pg0KPj4+PiBDb21wZXRpdGlvbiAod2l0aG91dCBidWxseWluZykgaXMgZ29vZCBhbmQg aXMgYW4gZW50aWNlbWVudCB0byBjb25zaWRlcg0KPj4+PiBzb2xpZCBkZXNpZ25zIGFuZCB0aGlu a2luZyBvdXRzaWRlIG9mIHRoZQ0KPj4+PiAid2UtZGlkLXRoaXMtMjAteWVhcnMtYWdvLWxpa2Ut dGhpcy1hbmQtdGhlcmVmb3JlLWhhdmUtdG8tc3RpY2stdG8tdGhpcyINCj4+Pj4gYm94ICh0aGUg Zmxha3kgb25lcyB3aWxsIGVuZCB1cCB3aXRoIG1hcmtldGluZyBhbmQgUFIgZGVwYXJ0bWVudHMg b2YNCj4+Pj4gY29tcGV0aW5nIGVmZm9ydHMgdG8gcG9rZSBmdW4gYXQpLg0KPj4+Pg0KPj4+PiBC ZXN0IHJlZ2FyZHMsIFJlbmUNCj4+Pj4NCj4+Pj4NCj4+Pj4gT24gMy8zLzIwMTUgMjozNCBQTSwg QnJpYW4gRSBDYXJwZW50ZXIgd3JvdGU6DQo+Pj4+PiBPbiAwNC8wMy8yMDE1IDA1OjM2LCBIYW5u ZXMgVHNjaG9mZW5pZyB3cm90ZToNCj4+Pj4+PiBBdCB0aGUgbW9tZW50IHRoZSBzcGVjaWZpY2F0 aW9ucyBhcmUgb25seSBhdmFpbGFibGUgdG8gVGhyZWFkDQo+bWVtYmVycw0KPj4+Pj4+IHNpbmNl IHRoZSBzcGVjaWZpY2F0aW9uIGlzIHN0aWxsIHdvcmsgaW4gcHJvZ3Jlc3MuDQo+Pj4+Pj4NCj4+ Pj4+PiBJIGRvbid0IGtub3cgd2hlbiBpdCB3aWxsIGJlIGZpbmFsaXplZCBhbmQgcmVsZWFzZWQg dG8gdGhlIHdpZGVyIHB1YmxpYy4NCj4+Pj4+Pg0KPj4+Pj4+IFJlZ2FyZGluZyB0aGUgbGlhaXNv biBJIGRvIG5vdCBoYXZlIGFuIG9waW5pb24gYWJvdXQgdGhlIHZhbHVlIG9mIGl0Lg0KPj4+Pj4g SXQgaXMgcHJlY2lzZWx5IHRvIGdldCBhY2Nlc3MgYmVmb3JlIHRoZSB3b3JrIGlzIGZpbmFsaXNl ZCwgc28gdGhhdCBpdA0KPj4+Pj4gY2FuIGJlIHJldmlld2VkIGJ5IGFsbCB0aGUgcmlnaHQgcGVv cGxlLiBXZSBrbm93IHRoYXQgY2xvc2VkIHN0YW5kYXJkcw0KPj4+Pj4gZGV2ZWxvcG1lbnQgcHJv ZHVjZXMgYmFkIHN0YW5kYXJkcy4NCj4+Pj4+DQo+Pj4+PiAgICAgICBCcmlhbg0KPj4+Pj4NCj4+ Pj4+PiBDaWFvDQo+Pj4+Pj4gSGFubmVzDQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IE9uIDAyLzI2 LzIwMTUgMDE6NTIgQU0sIEJyaWFuIEUgQ2FycGVudGVyIHdyb3RlOg0KPj4+Pj4+PiBPbiAyNi8w Mi8yMDE1IDEwOjI1LCBCZWhjZXQgU2FyaWtheWEgd3JvdGU6DQo+Pj4+Pj4+DQo+Pj4+Pj4+IC4u Lg0KPj4+Pj4+Pj4+PiBJIGtub3cgbm90aGluZyBhYm91dCBUaHJlYWQsIHdoYXRldmVyIGFuZCB3 aG9ldmVyIGl0IGlzLg0KPj4+Pj4+Pj4+IEhlcmUgaXMgYW4gaW50cm8gZG9jdW1lbnQ6DQo+Pj4+ Pj4+Pj4NCj5odHRwOi8vdGhyZWFkZ3JvdXAub3JnL1BvcnRhbHMvMC9kb2N1bWVudHMvZXZlbnRz L1RocmVhZEludHJvLnBkZg0KPj4+Pj4+PiBUaGFua3MgZm9yIHRoYXQuIEl0IHNlZW1zIHRvIGhh dmUgYWxsIHRoZSBkb3duc2lkZXMgb2Ygc2VjcmV0aXZlIGFkDQo+aG9jDQo+Pj4+Pj4+IG1lbWJl cnNoaXAtYmFzZWQgY29uc29ydGlhLCBleGNlcHQgZm9yIHRoZSB1cHNpZGUgb2YgYSBSQU5ELVJG IElQUg0KPj4+Pj4+PiBwb2xpY3kuDQo+Pj4+Pj4+DQo+Pj4+Pj4+PiBJIHRoaW5rIHdlIG5lZWQg dG8gY2xhcmlmeSBoZXJlIHRoYXQgVGhyZWFkIEdyb3VwIGlzIGZvcm1lZCB0byBkZWFsDQo+Pj4+ Pj4+PiB3aXRoIGhvbWUgZW52aXJvbm1lbnRzLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IEVudGVycHJp c2Ugb3IgaW5kdXN0cmlhbCBlbnZpcm9ubWVudHMgc2VlbSB0byBiZSBleGNsdWRlZC4NCj4+Pj4+ Pj4gU28gZmFyLiBUaGUgYm91bmRhcnkgYmV0d2VlbiB0aGlzIGFuZCBsYXJnZXIgYnVpbGRpbmcg c2VydmljZXMNCj4+Pj4+Pj4gbmV0d29ya3MgaXMgcHJldHR5IGZ1enp5LCBpc24ndCBpdD8NCj4+ Pj4+Pj4NCj4+Pj4+Pj4gSW4gYW55IGNhc2UsIHNob3VsZCB3ZSAodGhlIFdHcyBvbiBjb3B5LCBh bmQgcGVyaGFwcyBzb21lIG90aGVycykNCj4+Pj4+Pj4gYmUgYXNraW5nIHRoZSBJQUIgdG8gYXJy YW5nZSBhIG1lYW5pbmdmdWwgbGlhaXNvbiB3aXRoIFRocmVhZD8NCj4+Pj4+Pj4NCj4+Pj4+Pj4g QmFjayBhdCBIYW5uZXM6IGlzIHRoZXJlIGEgc3BlYyBmb3IgdGhlaXIgYXBwcm9hY2ggdG8gc2Vj dXJpdHkNCj4+Pj4+Pj4gZW5yb2xsbWVudD8NCj4+Pj4+Pj4NCj4+Pj4+Pj4gICAgICBCcmlhbg0K Pj4+Pj4+Pg0KPj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4+Pj4+PiBBbmltYSBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4gQW5pbWFAaWV0Zi5v cmcNCj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYQ0K Pj4+Pj4+Pg0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+Pj4+IDZ0aXNjaC1zZWN1cml0eSBtYWlsaW5nIGxpc3QNCj4+Pj4+IDZ0aXNjaC1z ZWN1cml0eUBpZXRmLm9yZw0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby82dGlzY2gtc2VjdXJpdHkNCj4+Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4+IEFuaW1hIG1haWxpbmcgbGlzdA0KPj4+IEFuaW1h QGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmlt YQ0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ IEFuaW1hIG1haWxpbmcgbGlzdA0KPj4gQW5pbWFAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWENCj4NCj4NCj4tLQ0KPmVtYWlsOiByc3RydWlr LmV4dEBnbWFpbC5jb20gfCBTa3lwZTogcnN0cnVpaw0KPmNlbGw6ICsxICg2NDcpIDg2Ny01NjU4 IHwgVVM6ICsxICg0MTUpIDY5MC03MzYzDQoNCg== From nobody Wed Mar 4 00:03: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 F127F1A06FD; Wed, 4 Mar 2015 00:03:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ly-djpqOP0Rx; Wed, 4 Mar 2015 00:03:49 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 16C9A1A06E9; Wed, 4 Mar 2015 00:03:48 -0800 (PST) Received: from [192.168.131.141] ([80.92.121.102]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LxxNo-1XNqdd0a1c-015Joo; Wed, 04 Mar 2015 09:03:33 +0100 Message-ID: <54F6BC4B.2020101@gmx.net> Date: Wed, 04 Mar 2015 09:03:23 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Brian E Carpenter , sarikaya@ieee.org References: <77FA386512F0D748BC7C02C36EB1106D921776@szxeml557-mbs.china.huawei.com> <6426.1422664463@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com> <54E7219B.6040006@gridmerge.com> <54E72846.20807@gmx.net> <54E7824A.4040906@gmail.com> <54E86F9A.8020104@gmx.net> <54E8D442.6020909@gmail.com> <54EB4F24.7030609@gmx.net> <54EE6E31.8030609@gmail.com> <54F5E2FF.4040205@gmx.net> In-Reply-To: <54F5E2FF.4040205@gmx.net> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="eSvkKfixfDkOnQcjKj8x5FmuwkT5l2VsO" X-Provags-ID: V03:K0:PrrOhxP+RxdYivL6RFsh/lRwPld9fk1b8YrVptmq491qLMifOK1 qBh4RTzTaXpBkw0qUk2c6gcYQ2rwDKXbEbQoQJ39k6JOVlvonJOE5MyjqGKW/zLbKrfk8EM ycZ6rtKUV8diz3wsxyitMHVNH2mULXStfRTUXwFs4AubxYnobgnK8/Tro+S39TZjM8L6tHk KfoEmsy+XzLb1liI4m5wA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: consultancy@vanderstok.org, 6tisch-security <6tisch-security@ietf.org>, Michael Richardson , "Hedanping \(Ana\)" , robert.cragie@gridmerge.com, "6lo@ietf.org" <6lo@ietf.org>, "anima@ietf.org" Subject: Re: [Anima] Thread [Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things] 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, 04 Mar 2015 08:03:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --eSvkKfixfDkOnQcjKj8x5FmuwkT5l2VsO Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I was corrected after I sent the mail below to the list and learned something new (after consulting with my co-worker Robert). The specifications are not yet available to all members but only to a core group of member companies. They will be made available to the them probably in June. If the specs become available publically I will post a link to the list. Ciao Hannes On 03/03/2015 05:36 PM, Hannes Tschofenig wrote: > At the moment the specifications are only available to Thread members > since the specification is still work in progress. >=20 > I don't know when it will be finalized and released to the wider public= =2E >=20 > Regarding the liaison I do not have an opinion about the value of it. >=20 > Ciao > Hannes >=20 >=20 > On 02/26/2015 01:52 AM, Brian E Carpenter wrote: >> On 26/02/2015 10:25, Behcet Sarikaya wrote: >> >> ... >>>>> I know nothing about Thread, whatever and whoever it is. >>>> >>>> Here is an intro document: >>>> http://threadgroup.org/Portals/0/documents/events/ThreadIntro.pdf >> >> Thanks for that. It seems to have all the downsides of secretive ad ho= c >> membership-based consortia, except for the upside of a RAND-RF IPR >> policy. >> >>> I think we need to clarify here that Thread Group is formed to deal >>> with home environments. >>> >>> Enterprise or industrial environments seem to be excluded. >> >> So far. The boundary between this and larger building services >> networks is pretty fuzzy, isn't it? >> >> In any case, should we (the WGs on copy, and perhaps some others) >> be asking the IAB to arrange a meaningful liaison with Thread? >> >> Back at Hannes: is there a spec for their approach to security >> enrollment? >> >> Brian >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> >=20 --eSvkKfixfDkOnQcjKj8x5FmuwkT5l2VsO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU9rxLAAoJEGhJURNOOiAtFuEH/iNOAVyomTg5zNDTzMHaq73V ZL3n/JsSVAgshDvCxZ1hWgtOyLkUTmHS0M+x3w0TjoU8hhFMCLfrWloec+yLDhs7 uWZt8oD5x8iC1j8sejGn+Agmiy1hktOQH7uvOURJH/1bCl6lCGq2MjdubUfc8FEz qyT2kXxdhpMxVrMzVgFsOsPFAD1ZiwIRo9RVCXcNMnmnVMkycqR71s220wIZrrsO cu6znenkEp4CwYNTumiLTW3Af4xEMS/uHmXbsKF4jdA5SI6snhm4+NDzbJeKSDwQ aNC3zWhCpcgo0jCAfoqIwECIy8FscXXR+PyBIhBTYfBvYUF7JI9AJfyHGriW7Xs= =k6c9 -----END PGP SIGNATURE----- --eSvkKfixfDkOnQcjKj8x5FmuwkT5l2VsO-- From nobody Wed Mar 4 00:29: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 1AC9A1A0545; Wed, 4 Mar 2015 00:29:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 5ndsggMcZSJ4; Wed, 4 Mar 2015 00:28:59 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 A16DF1A0A85; Wed, 4 Mar 2015 00:28:58 -0800 (PST) Received: from [192.168.131.141] ([80.92.121.102]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LwrS8-1XR8JC31Oy-016Qay; Wed, 04 Mar 2015 09:28:23 +0100 Message-ID: <54F6C220.8020801@gmx.net> Date: Wed, 04 Mar 2015 09:28:16 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Rene Struik , Sheng Jiang , Brian E Carpenter , "sarikaya@ieee.org" References: <77FA386512F0D748BC7C02C36EB1106D921776@szxeml557-mbs.china.huawei.com> <6426.1422664463@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com> <54E7219B.6040006@gridmerge.com> <54E72846.20807@gmx.net> <54E7824A.4040906@gmail.com> <54E86F9A.8020104@gmx.net> <54E8D442.6020909@gmail.com> <54EB4F24.7030609@gmx.net> <54EE6E31.8030609@gmail.com> <54F5E2FF.4040205@gmx.net> <54F60CD2.7030001@gmail.com> <54F627D2.5090806@gmail.com> <54F6305E.8060704@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B923B0552CD@nkgeml512-mbx.china.huawei.com> <54F67E42.4090304@gmail.com> In-Reply-To: <54F67E42.4090304@gmail.com> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="NEmrGBTiH6CF5QwE1dgrj4jU460e3HTOC" X-Provags-ID: V03:K0:iVpSttWOob3laGLn4O4j8lSVC9OMRheSXVnrIG27ulJ7W1PiTd/ uqEC43bNA6y5wnQ7W5+hOnsmSMJiJ1uJm3KwDAF80lJ87OUpDGk/sZLXuOlzcIxvzTOfJ4H wyO4aCiBJs3P/FKHHHkNU551jtb21ou/3YIMaRaCZNI+GcNE34HAVJ/tcV9X4YcxKM1w2oY /6bC+MvbDIL6L5nNPw63g== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "consultancy@vanderstok.org" , 6tisch-security <6tisch-security@ietf.org>, Michael Richardson , "Hedanping \(Ana\)" , "robert.cragie@gridmerge.com" , "6lo@ietf.org" <6lo@ietf.org>, "anima@ietf.org" Subject: Re: [Anima] (Fair) competition in pursuing ideas and dreams is good 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, 04 Mar 2015 08:29:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NEmrGBTiH6CF5QwE1dgrj4jU460e3HTOC Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable While I agree with you, Rene, I still think it is useful to look at other work that is being done (particularly if they appear relevant to this group). With regards to the security aspects, I believe at least the following efforts appear relevant: * TR69 * OMA LWM2M * Netconf Zerotouch * Certificate management protocols like EST, CMP, etc. * IEEE 802.1AR (Maybe there are others.) Looking at those examples provides ideas about what worked well and what didn't. Ciao Hannes On 03/04/2015 04:38 AM, Rene Struik wrote: > Hi Sheng: >=20 > I think you quite misinterpreted my email: I was just commenting on > guessing games re what industry consortia or others may have up their > sleeves (not easy to control or influence). From the numerous emails, I= > got the impression that "Thread" was actually spelled as "Threat". This= > email exchange would never have happened if it would have been another > "Attic project X". >=20 > Of course, all goodies re striving for convergence and for consensus > apply (where discussion re relative technical merit could be viewed as > competition of ideas [and what IETF often does quite liberally]). >=20 > Rene >=20 > On 3/3/2015 8:22 PM, Sheng Jiang wrote: >>> On 04/03/2015 10:29, Rene Struik wrote: >>>> Dear colleagues: >>>> >>>> I don't understand all the excitement here: everyone is free to draw= up >>>> architectural blueprints and complete designs to their liking. This = can >>>> be done in the attic, as company-internal project, with an industry >>>> consortium, or with SDOs, such as IETF. There is no way of knowing >>>> what >>>> people dream up in their attic or in a "secret" project X type of >>>> effort. Or, is the fear that IETF will loose its lustre? >>> No. The fear (and it has been realised many times in the past) is >>> that a closed consortium will agree on and start shipping a solution >>> which does not mesh well with the rest of the Internet. A liaison >>> arrangement can help to avoid that. >> The IETF is mainly a standardization organization. Most of efforts in >> IETF is for interoperation. IETF produces a bunch of open standards, >> no secret at all. Then every company can implementation the interface >> following these standards. Of course, there are many internal >> implementation, which does not need interoperation with other devices,= >> and they can be closed or secret. Devices can then interoperate with >> each other as long as the all following the same standards. >> >> Consequently, the main efforts of standardization actually compromise >> rather than competition. It is all participators to work together >> towards a consensus, which most of people could live with (in which >> maybe everybody have something unsatisfied.) So, people are encouraged= >> to discuss, coordinate, merge and make compromises. Working along and >> producing several competition solutions would NOT be good in any >> standardization organizations. >> >>> Brian >>> >>>> Competition (without bullying) is good and is an enticement to consi= der >>>> solid designs and thinking outside of the >>>> "we-did-this-20-years-ago-like-this-and-therefore-have-to-stick-to-t= his" >>>> >>>> box (the flaky ones will end up with marketing and PR departments of= >>>> competing efforts to poke fun at). >>>> >>>> Best regards, Rene >>>> >>>> >>>> On 3/3/2015 2:34 PM, Brian E Carpenter wrote: >>>>> On 04/03/2015 05:36, Hannes Tschofenig wrote: >>>>>> At the moment the specifications are only available to Thread memb= ers >>>>>> since the specification is still work in progress. >>>>>> >>>>>> I don't know when it will be finalized and released to the wider >>>>>> public. >>>>>> >>>>>> Regarding the liaison I do not have an opinion about the value of = it. >>>>> It is precisely to get access before the work is finalised, so that= it >>>>> can be reviewed by all the right people. We know that closed standa= rds >>>>> development produces bad standards. >>>>> >>>>> Brian >>>>> >>>>>> Ciao >>>>>> Hannes >>>>>> >>>>>> >>>>>> On 02/26/2015 01:52 AM, Brian E Carpenter wrote: >>>>>>> On 26/02/2015 10:25, Behcet Sarikaya wrote: >>>>>>> >>>>>>> ... >>>>>>>>>> I know nothing about Thread, whatever and whoever it is. >>>>>>>>> Here is an intro document: >>>>>>>>> http://threadgroup.org/Portals/0/documents/events/ThreadIntro.p= df >>>>>>> Thanks for that. It seems to have all the downsides of secretive >>>>>>> ad hoc >>>>>>> membership-based consortia, except for the upside of a RAND-RF IP= R >>>>>>> policy. >>>>>>> >>>>>>>> I think we need to clarify here that Thread Group is formed to d= eal >>>>>>>> with home environments. >>>>>>>> >>>>>>>> Enterprise or industrial environments seem to be excluded. >>>>>>> So far. The boundary between this and larger building services >>>>>>> networks is pretty fuzzy, isn't it? >>>>>>> >>>>>>> In any case, should we (the WGs on copy, and perhaps some others)= >>>>>>> be asking the IAB to arrange a meaningful liaison with Thread? >>>>>>> >>>>>>> Back at Hannes: is there a spec for their approach to security >>>>>>> enrollment? >>>>>>> >>>>>>> Brian >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Anima mailing list >>>>>>> Anima@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/anima >>>>>>> >>>>> _______________________________________________ >>>>> 6tisch-security mailing list >>>>> 6tisch-security@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/6tisch-security >>>> >>> _______________________________________________ >>> 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 >=20 >=20 --NEmrGBTiH6CF5QwE1dgrj4jU460e3HTOC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU9sIgAAoJEGhJURNOOiAtAmEH/iYgv+FuR2VChBj+x2EqpIIf e7Nwc4mLa/Qg8kOjvDD7m+6nYSimmjXJva80qW/xq10iDhZw7j+FUeGpqj/aXEfr DkAuYRK+EKq8lz21gFrN0RRRV2MqsMi3TncJxqkOU/y44f3b3glN5Nf96ojZKncB AjEb4OUhN7WI8HYVglzizN1xovAv9y5AicA2so3CWUeyvOJGx56tpTpFxNeoT9mm QYa5nDc1tz3SZtXPcz/FyuuTcma2sGJ2BT6E7dHCj/gQ+p1HsIvB4drEPyfd2Zbq /qc0vkKEMBuT0GmaK5MDypVmXRiKsxNs5E7Pj0pWioKEUfyLRwY7UxEcIasv0ac= =aPYt -----END PGP SIGNATURE----- --NEmrGBTiH6CF5QwE1dgrj4jU460e3HTOC-- From nobody Wed Mar 4 03:59: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 532351A020D; Wed, 4 Mar 2015 03:59:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=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 TWhpDZKaGCny; Wed, 4 Mar 2015 03:59:53 -0800 (PST) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::9]) (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 02FC71A0276; Wed, 4 Mar 2015 03:59:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1425470391; l=7142; s=domk; d=sandeep.de; h=Content-Type:To:From:Subject:Date:References:In-Reply-To: MIME-Version; bh=ZNsGTm0tvAHGx0Xb86iD491Ykntw7a+SmCooNznFF+Y=; b=SuUxdLa229lQRPy0YrbKNuGwxovb5Jiw4TsMAoBV2M6dCip+SiTtJB391iLcxQ4+UZ3 dvL+FIQ1afbPgGpBUqPkVKWbqdq7vSVKvKnP8KY5S4MwdV0TyW3ls8DqxqaYN8PyOrTb7 Tyvw5XNupEIz8s5JtNXfnKCFyQDk+dCFvps= X-RZG-AUTH: :JWkQc2C7evFfytIRBe7p82UYMzBqkr+YiXEkMUacmkLgvZRJw7/VeQ== X-RZG-CLASS-ID: mo00 Received: from mail-wg0-f47.google.com ([74.125.82.47]) by smtp.strato.de (RZmta 37.3 AUTH) with ESMTPSA id N04c5dr24BxoWKx (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verification FAILED - certificate not trusted)) (Client hostname not verified); Wed, 4 Mar 2015 12:59:50 +0100 (CET) Received: by wgha1 with SMTP id a1so46152574wgh.12; Wed, 04 Mar 2015 03:59:50 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.202.162 with SMTP id kj2mr6810693wjc.19.1425470390201; Wed, 04 Mar 2015 03:59:50 -0800 (PST) Received: by 10.27.97.65 with HTTP; Wed, 4 Mar 2015 03:59:50 -0800 (PST) In-Reply-To: References: <20150304104232.7444.20988.idtracker@ietfa.amsl.com> Date: Wed, 4 Mar 2015 12:59:50 +0100 Message-ID: From: Sandeep Kumar To: 6tisch@ietf.org, anima@ietf.org Content-Type: multipart/alternative; boundary=047d7b3a7f703ef50705107530f4 Archived-At: Subject: [Anima] Fwd: FW: New Version Notification for draft-kumar-6lo-selective-bootstrap-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, 04 Mar 2015 11:59:55 -0000 --047d7b3a7f703ef50705107530f4 Content-Type: text/plain; charset=UTF-8 Cross-posting to other groups that may be interested in the work. Please post comments to the 6lo group. ---------- Forwarded message ---------- Subject: Fwd: FW: New Version Notification for draft-kumar-6lo-selective-bootstrap-00.txt To: 6lo@ietf.org Dear all A new I-D related to secure bootstrapping in professional domains (especially Lighting) has been submitted to the 6lo WG. Your comments are welcome. regards Sandeep -----Original Message----- Subject: New Version Notification for draft-kumar-6lo-selective-bootstrap-00.txt A new version of I-D, draft-kumar-6lo-selective-bootstrap-00.txt has been successfully submitted by Sandeep S. Kumar and posted to the IETF repository. Name: draft-kumar-6lo-selective-bootstrap Revision: 00 Title: Security Bootstrapping over IEEE 802.15.4 in selective order Document date: 2015-03-04 Group: Individual Submission Pages: 21 URL: http://www.ietf.org/internet-drafts/draft-kumar-6lo-selective-bootstrap-00.txt Status: https://datatracker.ietf.org/doc/draft-kumar-6lo-selective-bootstrap/ Htmlized: http://tools.ietf.org/html/draft-kumar-6lo-selective-bootstrap-00 Abstract: Low-resource devices in a Low-resource and Lossy Network (LLN) can be based on a mesh network using the IEEE 802.15.4 link standard. Security in these networks MUST be enforced at the link level. Provisioning the devices in a secure manner with keys (often called security bootstrapping) to encrypt and authenticate the link-layer messages is the subject of this specification. This proposal distinguishes itself from other bootstrap proposals by requiring that the devices can be secured in an order determined by the needs of the installation procedure. Other proposals use an "onion model", where first the devices one-hop away from the initial device (often the border router) are secured, followed by the devices that are one-hop away from already secured devices. 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 ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. --047d7b3a7f703ef50705107530f4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Cross-posting to other groups that may be interested in th= e work. Please post comments to the 6lo group.

---------- Forwarded message ----------
Subject: Fwd: FW: New= Version Notification for draft-kumar-6lo-selective-bootstrap-00.txt
To:= 6lo@ietf.org


Dear all

A new I-D related to secure bo= otstrapping in professional domains (especially Lighting) has been submitte= d to the 6lo WG.=C2=A0

Your comments are welcome.

regards
<= /div>Sandeep





-----Original Message-----
Subject: New Version Notification for draft-kumar-6lo-selective-bootstrap-0= 0.txt


A new version of I-D, draft-kumar-6lo-selective-bootstrap-00.txt
has been successfully submitted by Sandeep S. Kumar and posted to the IETF = repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-kumar-6lo-selective-boo= tstrap
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Security Bootstrapping over IEEE 8= 02.15.4 in selective order
Document date:=C2=A0 2015-03-04
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 21
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ietf.org/internet-drafts/draft-kumar-6lo-selective-bootstra= p-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://d= atatracker.ietf.org/doc/draft-kumar-6lo-selective-bootstrap/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.= org/html/draft-kumar-6lo-selective-bootstrap-00


Abstract:
=C2=A0 =C2=A0Low-resource devices in a Low-resource and Lossy Network (LLN)= can be
=C2=A0 =C2=A0based on a mesh network using the IEEE 802.15.4 link standard.=
=C2=A0 =C2=A0Security in these networks MUST be enforced at the link level.=
=C2=A0 =C2=A0Provisioning the devices in a secure manner with keys (often c= alled
=C2=A0 =C2=A0security bootstrapping) to encrypt and authenticate the link-l= ayer
=C2=A0 =C2=A0messages is the subject of this specification.=C2=A0 This prop= osal
=C2=A0 =C2=A0distinguishes itself from other bootstrap proposals by requiri= ng that
=C2=A0 =C2=A0the devices can be secured in an order determined by the needs= of the
=C2=A0 =C2=A0installation procedure.=C2=A0 Other proposals use an "oni= on model", where
=C2=A0 =C2=A0first the devices one-hop away from the initial device (often = the
=C2=A0 =C2=A0border router) are secured, followed by the devices that are o= ne-hop
=C2=A0 =C2=A0away from already secured devices.




Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


________________________________
The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message.


--047d7b3a7f703ef50705107530f4-- From nobody Wed Mar 4 10:27: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 1E2DA1A1BA3 for ; Wed, 4 Mar 2015 10:27:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_34=0.6, 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 xfRO5pg5CeMF for ; Wed, 4 Mar 2015 10:27:44 -0800 (PST) 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 477031A1BAA for ; Wed, 4 Mar 2015 10:27:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11114; q=dns/txt; s=iport; t=1425493664; x=1426703264; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=FB/DFHpRLhfZdU+ZrTO5h6pnJAJgCxiSct/J/kFUET8=; b=YyrwbgQoBnyEHCK2aJa+Bq/yQPGgPUuW5Dbht5JXBXEtGcUgzbhxVhn+ 6jko3l1GW2JZlQmllrPIjW+NCp91ryiqKZB81AA7G6Bqv7xq1fvzman+R +1nJ3XQB29bxkvox8ofafyMmhyCbnAOzNAMK0If9fAVfwIZbaN5xFEd6t c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CFBwBUTvdU/4gNJK1agwJSWgS+aWmBPgqFcQKBLTgUAQEBAQEBAXyEDwEBAQMBAQEBNy0HEAcEAgEIEQQBAQsUCQcnCxQJCAIEARIIE4gMCA3YAQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEixKEHQEBHjgGgxGBFAWPf4U8P4RrgyWCU4kWg0AjggEdgVBvgQICBxcCBBx/AQEB X-IronPort-AV: E=Sophos;i="5.09,688,1418083200"; d="scan'208";a="128857689" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-8.cisco.com with ESMTP; 04 Mar 2015 18:27:43 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t24IRh3O020907 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Mar 2015 18:27:43 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.229]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Wed, 4 Mar 2015 12:27:43 -0600 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , Anima WG Thread-Topic: [Anima] Comments on draft-behringer-anima-autonomic-control-plane-01.txt Thread-Index: AQHQVG8SMtdO26SCOEy975k2C263t50MoLvg Date: Wed, 4 Mar 2015 18:27:42 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22EE6A68@xmb-rcd-x14.cisco.com> References: <20150220084151.13713.88982.idtracker@ietfa.amsl.com> <54F3927C.202@gmail.com> In-Reply-To: <54F3927C.202@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.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Comments on draft-behringer-anima-autonomic-control-plane-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: Wed, 04 Mar 2015 18:27:47 -0000 Hi Brian, thanks for your comments. Inline... > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E > Carpenter > Sent: 01 March 2015 23:28 > To: Anima WG > Subject: [Anima] Comments on draft-behringer-anima-autonomic-control- > plane-01.txt >=20 > Hi, >=20 > I went through this more carefully than the previous version, so I have a > number of questions and comments: >=20 > > 1. Introduction > ... > > The Autonomic Control Plane serves several purposes: >=20 > It would be useful to state explicitly that these purposes can co-exist. Will be done in next version.=20 > ... > > The ACP therefore supports directly Autonomic Networking functions, as > > described in [I-D.behringer-anima-reference-model]. >=20 > ... and it can, for example, directly carry GDNP traffic. Indeed. However, GDNP can also run in the data plane, for example to negoti= ate the tunnel type for the ACP.=20 > > 2. Problem Statement > > > > An "Autonomic Control Plane" (ACP) provides a solution to some of > > today's operational challenges. These fall into three broad > > categories: > > > > o Bootstrapping a network while devices are not yet configured. > > Bootstrapping a new device typically requires all devices between the > > controller and the new device to be completely and correctly > > addressed, configured and secured. Therefore, bootstrapping a network > > happens in layers around the controller. >=20 > This bullet has a strong SDN flavour due to the word "controller". > While SDN is certainly a valid use case, I'm not sure we want to emphasis= e it > here. I think we do want to emphasise this. To the "quick" reader there is the po= tential misunderstanding that autonomics and SDN are "either or", and this = is clearly not the case. Those two paradigms complement each other nicely. = It is important to remind readers about this.=20 > I think there are a couple of missing problems at the end of this section= : >=20 > o Running an autonomic networking protocol such as GDNP when the rest of > the network apart from the ACP is out of order. Hmmmm... This section evolved from a use case discussion, ie, how the opera= tor sees it. Now of course it's more generic, where such a statement would = make sense. I'll add something along those lines. Good point.=20 > o Need for a stable substrate for management traffic when the network as = a > whole is variable due to dynamic virtualization of any kind. That is covered in the second bullet? If not, then I don't understand your = point?=20 =20 > > 3.3. Authenticating Neighbors > ... > > Authentication could be a function of a generic Adjacency Discovery > > protocol, for example the "Generic Discovery and Negotiation Protocol" > > GDNP described in [I-D.carpenter-anima-gdn-protocol]. >=20 > I'm not sure about that statement, on reflection. It's certainly on the t= able to > leave authentication to a secure transport layer. OK, I'll take that paragraph out for now.=20 =20 > > 3.5. Channel Establishment > > > > After authentication and capability negotiation autonomic nodes > > establish a secure channel towards their direct AN neighbors with the > > above negotiated parameters. In order to be independent of configured > > link addresses, these channels can be implemented in several ways: > > > > o As a secure IP tunnel (e.g., IPsec, DTLS, etc.) >=20 > I would like TLS to be listed too. UDP+DTLS is a fairly complex beast wit= h > startup costs and MTU issues, and I think we seriously need to consider T= LS > instead. Well, those are examples, and don't preclude any other choice. But I can li= st it if you like, no strong feelings ;-)=20 > ... > > Since channels are established between adjacent neighbors, the > > resulting overlay network does hop by hop encryption. Each node > > decrypts incoming traffic from the ACP, and encrypts outgoing traffic > > to its neighbors in the ACP. Routing is discussed in Section 3.8. >=20 > I have several issues here (and the routing discussion doesn't solve them= ). >=20 > 1. It's well understood that we need a link-local mode because of > bootstrapping, fault conditions, etc. But... >=20 > 2. When distant nodes need to communicate, that simply doesn't work, > which is why we give them ULAs and need a routing protocol. >=20 > 3. So there is something missing in your description. How does a packet > from Node A, which isn't a router, get to Node B, which isn't a router, o= n > some other link? The ACP is an overlay network, essentially. Each node maintains a VRF (or s= imilar), and the tunnels mentioned above get plugged into this VRF. Inside = the VRF you define a loopback address, and route through those tunnels. The= net effect is that you have an overlay network, which only depends on link= local addresses in the data plane, yet provides network wide reachability.= =20 So, please tell me:=20 - does this explanation still not answer your question? In which case I don= 't understand your concern. Or:=20 - does it, in which case I need to make the text clearer.=20 > 4. In a large network I expect the ACP to be reasonably busy. So hop by h= op > encryption and decryption seems like an unreasonable overhead. That depends entirely what you want to do with it. And "unreasonable" is ob= jective; all our current experiences indicate that while this looks really = odd at first, it works actually quite well.=20 One key feature of the ACP is that the traffic inside doesn't need to be fu= rther protected. You could of course use non-encrypted tunnels, and secure = all protocols through it separately. In the end that's a tradeoff.=20 > Certainly in GDNP we are assuming normal layer 3 end-to-end connectivity > between Node A and Node B, with e2e security. That is perfectly ok, and works with the currently described ACP.=20 =20 > > 3.7. Addressing in the ACP > > > > The channels explained above only establish communication between > two > > adjacent neighbors. In order for the communication to happen across > > multiple hops, the autonomic control plane requires internal network > > wide valid addresses and routing. Each autonomic node must create a > > loop back interface with a network wide unique address inside the ACP > > context mentioned in Section 3.6. >=20 > The second sentence is actually in contradiction with what I just quoted > from section 3.5.=20 ... then we're not being clear enough.=20 > But I agree with it. However, on the third sentence and its > implications you lose me. Why would you do something as bizarre as > inventing a fictitious interface instead of deploying a ULA prefix across= the > ACP? (I must have read the previous version carelessly not to spot this.) > Making the Global ID of the ULA prefix a hash of the domain ID is a fine = idea. > But I would much prefer the subnet prefixes to be real ones=20 Define "real ones" please - I don't think I understand... > without the > consequent risk of clashes, and conventional RAs and SLAAC within the ACP > on each link. The interface IDs should probably follow draft-ietf-6man- > default-iids. In our model, the ACP only has globally routable addresses on the loopbacks= . There is no link addressing (inside). We don't need it. Simplicity. I'll = point that out.=20 > > 3.8. Routing in the ACP > > > > Once ULA address are set up all autonomic entities should run a > > routing protocol within the autonomic control plane context. >=20 > I don't like that. I don't think that nodes which aren't already routers = should > be obliged to run a routing protocol. Please remember that in a large car= rier > network you might easily be asking for > 100000 nodes to operate a routing protocol. It just isn't necessary; the = ACP > nodes that happen to be routers can do this. Well, if the network is hop by hop, then there is no choice, each hop has t= o run a routing protocol. Of course you need a really lightweight protocol= which scales enormously.=20 =20 > ... > > The routing protocol inside the ACP should be light weight and highly > > scalable to ensure that the ACP does not become a limiting factor in > > network scalability. We suggest the use of RPL as one such protocol > > which is light weight and scales well for the control plane traffic. >=20 > I think it's way too soon to select a protocol. For now we can sit back a= nd > watch the homenet debate, but the scaling issues are very different. > My gut feeling is that different types of autonomic network will need > different solutions. Sure, this is open to debate. We were trying to come up with a solution tha= t works in all contexts, and we believe this to be true (bold statement - f= or debate ;-) =20 > > 3.9. Connecting a Controller / NMS system >=20 > Doesn't this section overlap with draft-eckert-anima-stable-connectivity? There is some overlap. We need to sort that, true.=20 =20 > > 4. Self-Healing Properties > ... > > o If an existing device gets revoked, it will automatically be denied > > access to the ACP as its domain certificate will be validated against > > a Certificate Revocation List during authentication. >=20 > Excuse my ignorance, but will that instantly kill any open IPsec, TLS or = DTLS > associations? That was discussed on another thread, and I think is answered.=20 > ... > > After a network partition, a merge will just establish the previous > > status, >=20 > Nit: s/merge/re-merge/ to make the context clear. Will do.=20 =20 > > 5. Self-Protection Properties > ... > > The ULA addresses are only reachable inside the ACP context, therefore > > unreachable from the data plane. >=20 > Nit: 'data plane' is a bit vague IMHO. I think it would more precise to s= ay: >=20 > As long as there is no leakage from the ACP routing protocol, the ULA > addresses are only reachable inside the ACP context, therefore unreachabl= e > from the user environment or any external point of attack. OK, maybe our wording is vague, but I doubt that "user environment" is any = clearer. :-) =20 I'll think about that one... > > 6. Use Cases for the ACP >=20 > Hmm. To me, this section seems completely redundant with Section 2. Yes, unless we follow your suggestion from above and include protocol discu= ssions here, because then it's not a use case any more. But I see your poin= t and will try to address it in the next version.=20 BTW, it may be useful for discussions on certain points above that have the= risk to take longer, to start a separate mail thread, for ease of use.=20 Thanks for your comments. Please try to clarify where I wasn't clear, I'll = try to get a new version out before the deadline.=20 Michael > Regards > Brian Carpenter >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Wed Mar 4 16:24:19 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 AAAD91A01D8 for ; Wed, 4 Mar 2015 16:24:17 -0800 (PST) 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 IMs4zdljuU32 for ; Wed, 4 Mar 2015 16:24:16 -0800 (PST) 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 61E151A014A for ; Wed, 4 Mar 2015 16:24:16 -0800 (PST) Received: by padet14 with SMTP id et14so13820238pad.11 for ; Wed, 04 Mar 2015 16:24:16 -0800 (PST) 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=jU9EwunUke8Z0Abzdbgz1g2mqoOtUresjCTPHvrT3pk=; b=g+nJHiXWYdUOf5n+htc1OmldTdzR+Hf7JXjtAFvG9GxQfXqUUkPhKp+9XCoUMtW/Xf xPNBPal1s5RShYIOIzxn20GCrqA78M5um++gWc5MeAFuVBieRba3QRtjhiMBN6DgaAcI gCGum9m5p1jb7jOYI2moYQIvF2VgR0wdKIU+7kE7UKgEFFXPGKnNGLSW2Yjo9ZizBtNW qZWwlI8eL7Is2qRd7pRM9L84TE4WxNcYel8D1lTfx86Hrucz9F8I6Pw7IMyrtcq8IqgF me76RdCCmkr850ND4hkscTrcAZnzXeVFAjsxGWHx0cSXQNDW9ZAw4lQPkuighr/lJNxR KTFw== X-Received: by 10.70.128.173 with SMTP id np13mr11003494pdb.33.1425515056135; Wed, 04 Mar 2015 16:24:16 -0800 (PST) Received: from ?IPv6:2406:e007:6617:1:28cc:dc4c:9703:6781? ([2406:e007:6617:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id qu10sm5136976pbc.25.2015.03.04.16.24.10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Mar 2015 16:24:12 -0800 (PST) Message-ID: <54F7A231.4000408@gmail.com> Date: Thu, 05 Mar 2015 13:24:17 +1300 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.5.0 MIME-Version: 1.0 To: "Michael Behringer (mbehring)" , Anima WG References: <20150220084151.13713.88982.idtracker@ietfa.amsl.com> <54F3927C.202@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22EE6A68@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22EE6A68@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] SDN controller [Comments on draft-behringer-anima-autonomic-control-plane-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: Thu, 05 Mar 2015 00:24:17 -0000 (Starting a separate thread for each debatable issue; this is the first one...) On 05/03/2015 07:27, Michael Behringer (mbehring) wrote: >>> 2. Problem Statement >>> >>> An "Autonomic Control Plane" (ACP) provides a solution to some of >>> today's operational challenges. These fall into three broad >>> categories: >>> >>> o Bootstrapping a network while devices are not yet configured. >>> Bootstrapping a new device typically requires all devices between the >>> controller and the new device to be completely and correctly >>> addressed, configured and secured. Therefore, bootstrapping a network >>> happens in layers around the controller. >> >> This bullet has a strong SDN flavour due to the word "controller". >> While SDN is certainly a valid use case, I'm not sure we want to emphasise it >> here. > > I think we do want to emphasise this. To the "quick" reader there is the potential misunderstanding that autonomics and SDN are "either or", and this is clearly not the case. Those two paradigms complement each other nicely. It is important to remind readers about this. Well, I could agree, but in that case I would be even more explicit and write something like: Bootstrapping a new device typically requires all devices between a controlling node (such as an SDN controller)... Brian From nobody Wed Mar 4 16:31:51 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 531C21A01D5 for ; Wed, 4 Mar 2015 16:31:50 -0800 (PST) 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 4hePQFrnD6hx for ; Wed, 4 Mar 2015 16:31:49 -0800 (PST) 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 13FC11A0039 for ; Wed, 4 Mar 2015 16:31:49 -0800 (PST) Received: by padbj1 with SMTP id bj1so4239947pad.12 for ; Wed, 04 Mar 2015 16:31:48 -0800 (PST) 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=MeTkj5zSTD/ErFSKHMKcxFz+Wo3Xac8qbTG3o1WOu30=; b=iCbi6kwtoNrQCszlADYhJjQ/FMZerKSG4tEvgG/pYc4DVDgQx/7ew5viaJ/NAbtYzm P2kpZPCbcJmsxCZss1OkNnb/K9FF7RYVsNHnsJ5pv2hcdLM35yzJA61UCnnQ+FLv3tD3 TFryvbarMbypsg5qSh7QYLv8wYy1XbJkLMjDcVqxgefSgJeMzV9UoHIUv90xGa/unqq0 UE/UjFxmPNx75BbuSwTBVzMXJg6DXTNEzeNtYiN9ayU8GN2PP6fZ3XhLarDXUa49/Asx iaREVjNjHOHP+Ui5XuMr1snKXt9ngVXrkh0rnO+6US1ujHDTFMWSRPNnaG9eDTHrk3vG tDGw== X-Received: by 10.66.250.17 with SMTP id yy17mr11315996pac.18.1425515508735; Wed, 04 Mar 2015 16:31:48 -0800 (PST) Received: from ?IPv6:2406:e007:6617:1:28cc:dc4c:9703:6781? ([2406:e007:6617:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id zz7sm5141151pbc.28.2015.03.04.16.31.45 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Mar 2015 16:31:46 -0800 (PST) Message-ID: <54F7A3F7.4000306@gmail.com> Date: Thu, 05 Mar 2015 13:31:51 +1300 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.5.0 MIME-Version: 1.0 To: "Michael Behringer (mbehring)" , Anima WG References: <20150220084151.13713.88982.idtracker@ietfa.amsl.com> <54F3927C.202@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22EE6A68@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22EE6A68@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Problem statement [Comments on draft-behringer-anima-autonomic-control-plane-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: Thu, 05 Mar 2015 00:31:50 -0000 On 05/03/2015 07:27, Michael Behringer (mbehring) wrote: >>> 2. Problem Statement ... >> I think there are a couple of missing problems at the end of this section: ... >> o Need for a stable substrate for management traffic when the network as a >> whole is variable due to dynamic virtualization of any kind. > > That is covered in the second bullet? If not, then I don't understand your point? That bullet refers to "misconfiguration and routing issues" which seems to mean faults of some kind. I was thinking of scenarios where dynamic reconfiguration of routing was intentional, not an error condition, but we need management traffic to run during the reconfiguration. In other words we use the stable ACP as the tool for reconfiguring routing for the tenant networks. I agree, this could be included in the second bullet. Brian From nobody Wed Mar 4 16:52:51 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 248C71A701A for ; Wed, 4 Mar 2015 16:52:50 -0800 (PST) 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 PFq0y9XveCMo for ; Wed, 4 Mar 2015 16:52:48 -0800 (PST) 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 6BDDA1A7011 for ; Wed, 4 Mar 2015 16:52:48 -0800 (PST) Received: by pablj1 with SMTP id lj1so31758088pab.8 for ; Wed, 04 Mar 2015 16:52:48 -0800 (PST) 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=68M5RYArZ/PqnF5yf8KwtvyvlScg1Eo4tc+QVHqrqCE=; b=PSapMz5MQ9SY4vf57srJqIt7nT/Gg99G6RNq117QKxOaQqpK2y7RXQf+v+u0Mw0pZp oJRpxUN9TCbFIP9G/51LS+rX3O5XA3ydkNATJxX7T+4Hx0N2ysrDgi6uDxP+3xRPI+dM Gnn/xA3CP+CF+wolvTJGaKOxTU6KU8QnRoioLXAbrlG2dZ/ovjtXFQBtiifFE5gAGSbK qWfMz8dhJOu1AVMZ1xuGVVJYS9I8/uH4KtsP2JLUuCBCU9XqmyHuOrDLLIAH9BSIBtJC ghjTfSEWT96J/cRac/BrTiI7OHKZoMJjX83iDFskP63HiL+V8Mp0CphhCrHr/h4RZ2xC kx1w== X-Received: by 10.68.195.10 with SMTP id ia10mr10861664pbc.113.1425516768154; Wed, 04 Mar 2015 16:52:48 -0800 (PST) Received: from ?IPv6:2406:e007:6617:1:28cc:dc4c:9703:6781? ([2406:e007:6617:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id cq5sm5083165pbc.79.2015.03.04.16.52.45 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Mar 2015 16:52:47 -0800 (PST) Message-ID: <54F7A8E3.8010804@gmail.com> Date: Thu, 05 Mar 2015 13:52:51 +1300 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.5.0 MIME-Version: 1.0 To: "Michael Behringer (mbehring)" , Anima WG References: <20150220084151.13713.88982.idtracker@ietfa.amsl.com> <54F3927C.202@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22EE6A68@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22EE6A68@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] VRF etc [Comments on draft-behringer-anima-autonomic-control-plane-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: Thu, 05 Mar 2015 00:52:50 -0000 On 05/03/2015 07:27, Michael Behringer (mbehring) wrote: >>> Since channels are established between adjacent neighbors, the >>> resulting overlay network does hop by hop encryption. Each node >>> decrypts incoming traffic from the ACP, and encrypts outgoing traffic >>> to its neighbors in the ACP. Routing is discussed in Section 3.8. >> >> I have several issues here (and the routing discussion doesn't solve them). >> >> 1. It's well understood that we need a link-local mode because of >> bootstrapping, fault conditions, etc. But... >> >> 2. When distant nodes need to communicate, that simply doesn't work, >> which is why we give them ULAs and need a routing protocol. >> >> 3. So there is something missing in your description. How does a packet >> from Node A, which isn't a router, get to Node B, which isn't a router, on >> some other link? > > The ACP is an overlay network, essentially. Each node maintains a VRF (or similar), and the tunnels mentioned above get plugged into this VRF. Inside the VRF you define a loopback address, and route through those tunnels. The net effect is that you have an overlay network, which only depends on link local addresses in the data plane, yet provides network wide reachability. > > So, please tell me: > - does this explanation still not answer your question? In which case I don't understand your concern. Or: My concern is that I don't see why you would do this rather than just running a native ULA prefix and a regular security protocol. What does the overhead of a VRF, with routing support in every autonomic node, buy you? What failure modes and threats does it exclude, in exchange for the overhead and scaling issues? > - does it, in which case I need to make the text clearer. I think it does need some extra words, because at the moment it only becomes clear on the second or third reading of the document as a whole. Mentioning a VRF helps a lot. >> 4. In a large network I expect the ACP to be reasonably busy. So hop by hop >> encryption and decryption seems like an unreasonable overhead. > > That depends entirely what you want to do with it. And "unreasonable" is objective; all our current experiences indicate that while this looks really odd at first, it works actually quite well. > > One key feature of the ACP is that the traffic inside doesn't need to be further protected. You could of course use non-encrypted tunnels, and secure all protocols through it separately. In the end that's a tradeoff. Yes. And with my GDNP hat on, I believe that we must assume that there are bad actors on the layer below. We'd end up with double encryption. >> Certainly in GDNP we are assuming normal layer 3 end-to-end connectivity >> between Node A and Node B, with e2e security. > > That is perfectly ok, and works with the currently described ACP. > >>> 3.7. Addressing in the ACP >>> >>> The channels explained above only establish communication between >> two >>> adjacent neighbors. In order for the communication to happen across >>> multiple hops, the autonomic control plane requires internal network >>> wide valid addresses and routing. Each autonomic node must create a >>> loop back interface with a network wide unique address inside the ACP >>> context mentioned in Section 3.6. >> >> The second sentence is actually in contradiction with what I just quoted >> from section 3.5. > > ... then we're not being clear enough. That's why I need the extra text about VRF. >> But I agree with it. However, on the third sentence and its >> implications you lose me. Why would you do something as bizarre as >> inventing a fictitious interface instead of deploying a ULA prefix across the >> ACP? (I must have read the previous version carelessly not to spot this.) >> Making the Global ID of the ULA prefix a hash of the domain ID is a fine idea. >> But I would much prefer the subnet prefixes to be real ones > > Define "real ones" please - I don't think I understand... Just a plain, normal domain-wide ULA /48 prefix, with longer prefixes delegated to routers that send regular RAs to hosts that perform regular SLAAC. IPv6 out of the box. As I said, I understand your model, I just don't understand why it's required. (But this comes from someone who believes that VLANs are a really bad idea, too.) Brian From nobody Thu Mar 5 00:13: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 D220C1B2A4F for ; Thu, 5 Mar 2015 00:13:44 -0800 (PST) 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 ZmSLPCdOHYQE for ; Thu, 5 Mar 2015 00:13:43 -0800 (PST) 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 724791B2A3A for ; Thu, 5 Mar 2015 00:13:34 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BTH45873; Thu, 05 Mar 2015 08:13:33 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 5 Mar 2015 08:13:32 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.106]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Thu, 5 Mar 2015 16:13:27 +0800 From: Sheng Jiang To: "anima@ietf.org" Thread-Topic: anima - Requested sessions have been scheduled for IETF 92 Thread-Index: AQHQUty51XWKbZkTbUiTPAxxExJp2J0NkSJQ Date: Thu, 5 Mar 2015 08:13:26 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923B056184@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: Subject: [Anima] FW: anima - Requested sessions have been scheduled 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: Thu, 05 Mar 2015 08:13:45 -0000 SGksIGFsbCwNCg0KQXMgeW91IG1heSBhbHJlYWR5IGZpbmQgb3V0IGZyb20gdGhlIElFVEYgYWdl bmRhLCB3ZSBoYXZlIGJlZW4gc2NoZWR1bGVkIHR3byBzZXNzaW9uIHdpdGggdG90YWwgMy41IGhv dXJzIGFzIGJlbG93LiBUaGUgY2hhaXJzIGFyZSB3b3JraW5nIG9uIHRoZSBhZ2VuZGEuIEJhc2lj YWxseSwgdGhlIFR1ZXNkYXkgc2Vzc2lvbiB3b3VsZCBmb2N1cyBvbiB0aGUgY2xvc2UgZGVsaXZl cmFibGVzIG9mIFdHIG1pbGVzdG9uZXM7IHRoZSBGcmlkYXkgc2Vzc2lvbiB3b3VsZCBiZSB3aWRl ciB3aXRoIG90aGVyIHdvcmsgaXRlbXMgcmVsZXZhbnQgdG8gYXV0b25vbWljIG5ldHdvcmsgYnV0 IG5vdCBpbiB1cmdlbnQgV0cgbWlsZXN0b25lcy4NCg0KPiBhbmltYSBTZXNzaW9uIDEgKDI6MDA6 MDApDQo+ICAgIFR1ZXNkYXksIEFmdGVybm9vbiBTZXNzaW9uIElJIDE1MjAtMTcyMA0KPiAgICBS b29tIE5hbWU6IE9hayAgc2l6ZTogMTYwDQo+ICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAgICBhbmltYSBTZXNzaW9uIDIgKDE6MzA6MDApDQo+ICAg IEZyaWRheSwgQWZ0ZXJub29uIFNlc3Npb24gSSAxMTUwLTEzMjANCj4gICAgUm9vbSBOYW1lOiBQ YXJpc2lhbiBzaXplOiAyMDANCj4gICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQoNCldlIHdpbGwgc2hhcmUgdGhlIHByaW1hcnkgV0cgYWdlbmRhIGVhcmx5 IG5leHQgd2Vlay4NCg0KQmVzdCByZWdhcmRzLA0KDQpTaGVuZyArIFRvZXJsZXNzDQo= From nobody Thu Mar 5 01:47: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 33E441A1B89 for ; Thu, 5 Mar 2015 01:47:51 -0800 (PST) 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 RJhmD14Uh1GD for ; Thu, 5 Mar 2015 01:47:49 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3084D1A1B88 for ; Thu, 5 Mar 2015 01:47:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5869; q=dns/txt; s=iport; t=1425548870; x=1426758470; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=hU5U5d41CEGgxJWYS1lKz92lEhDG5AvGiDCPNUtfOyE=; b=TI4ntJjE5ejj7ey/Urm2Kz9MUB4luG2rTUQqr9hn2BlheOovvpDXviDo aCeuq33wKLu4DvrNdkGyLGKBT+1Wx+3i09Nuv45aA2UM/AxX0qwqY8Hv+ oOhmU+is/hG5jaq+oqJZAOCHzvA01yqXzYCAvpCRZ+V77PChjSTYN56Vt 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DRBwDvJfhU/5hdJa1UBoMCUloEvneCJwqFcQKBMU0BAQEBAQF8hA8BAQEDAQEBATc0EAsCAQgiFBAnCyUCBAESCIgfCA3XegEBAQEBAQEBAQEBAQEBAQEBAQEVBIsUhCsSOIMXgRQFkAWFe4RsgyaCU4kZg0AjggEBHBSBPG+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.11,346,1422921600"; d="scan'208";a="401164462" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 05 Mar 2015 09:47:49 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t259llfg011403 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Mar 2015 09:47:47 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.229]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Thu, 5 Mar 2015 03:47:47 -0600 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , Anima WG Thread-Topic: [Anima] VRF etc [Comments on draft-behringer-anima-autonomic-control-plane-01.txt] Thread-Index: AQHQVt63D4jl5locYEuaerIx/ykJdJ0NkImA Date: Thu, 5 Mar 2015 09:47:47 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22EE7702@xmb-rcd-x14.cisco.com> References: <20150220084151.13713.88982.idtracker@ietfa.amsl.com> <54F3927C.202@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22EE6A68@xmb-rcd-x14.cisco.com> <54F7A8E3.8010804@gmail.com> In-Reply-To: <54F7A8E3.8010804@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.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] VRF etc [Comments on draft-behringer-anima-autonomic-control-plane-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: Thu, 05 Mar 2015 09:47:51 -0000 > > The ACP is an overlay network, essentially. Each node maintains a VRF (= or > similar), and the tunnels mentioned above get plugged into this VRF. Insi= de > the VRF you define a loopback address, and route through those tunnels. > The net effect is that you have an overlay network, which only depends on > link local addresses in the data plane, yet provides network wide > reachability. > > > > So, please tell me: > > - does this explanation still not answer your question? In which case I > don't understand your concern. Or: >=20 > My concern is that I don't see why you would do this rather than just run= ning > a native ULA prefix and a regular security protocol. What does the overhe= ad > of a VRF, with routing support in every autonomic node, buy you? What > failure modes and threats does it exclude, in exchange for the overhead a= nd > scaling issues? The "separate context" as we call it (maybe we should call it differently) = provides separation of error domains. Only with the logical separation can = the ACP operation be mostly independent of the data plane (the other contex= ts).=20 And, the separation isn't the resource issue, really. You could argue (and = I think you are saying exactly this) that you could run a second addressing= and routing instance right in the same data plane, thereby avoiding the ad= ditional context, but then you'd be subject to more error conditions, for e= xample address overlaps.=20 So, to your question "what does it buy me?" - you can mess up all addressin= g, routing, AAA, etc, on a device and still have access to it through this = ACP.=20 =20 > > - does it, in which case I need to make the text clearer. >=20 > I think it does need some extra words, because at the moment it only > becomes clear on the second or third reading of the document as a whole. > Mentioning a VRF helps a lot. OK. I'll look at that, and I'm FULLY aware that this concept is NOT easy to= convey. It *is* very unusual. Any help in how we can make it easier to und= erstand, please really let me know!=20 Maybe I'll add a section "overview" with an ascii art graphics.=20 > >> 4. In a large network I expect the ACP to be reasonably busy. So hop > >> by hop encryption and decryption seems like an unreasonable overhead. > > > > That depends entirely what you want to do with it. And "unreasonable" i= s > objective; all our current experiences indicate that while this looks rea= lly > odd at first, it works actually quite well. > > > > One key feature of the ACP is that the traffic inside doesn't need to b= e > further protected. You could of course use non-encrypted tunnels, and > secure all protocols through it separately. In the end that's a tradeoff. >=20 > Yes. And with my GDNP hat on, I believe that we must assume that there ar= e > bad actors on the layer below. We'd end up with double encryption. I would say that you *can* run protocols insecurely inside the ACP. Now you= can argue that for any protocol that you need also in the global context (= which is the case for GDNP), you may want to secure that protocol anyway. I= think that's ok. > >> Certainly in GDNP we are assuming normal layer 3 end-to-end > >> connectivity between Node A and Node B, with e2e security. > > > > That is perfectly ok, and works with the currently described ACP. > > > >>> 3.7. Addressing in the ACP > >>> > >>> The channels explained above only establish communication between > >> two > >>> adjacent neighbors. In order for the communication to happen across > >>> multiple hops, the autonomic control plane requires internal network > >>> wide valid addresses and routing. Each autonomic node must create a > >>> loop back interface with a network wide unique address inside the > >>> ACP context mentioned in Section 3.6. > >> > >> The second sentence is actually in contradiction with what I just > >> quoted from section 3.5. > > > > ... then we're not being clear enough. >=20 > That's why I need the extra text about VRF. OK, let me work on an "overview" section. I agree with you, additional clar= ity would definitely help.=20 =20 > >> But I agree with it. However, on the third sentence and its > >> implications you lose me. Why would you do something as bizarre as > >> inventing a fictitious interface instead of deploying a ULA prefix > >> across the ACP? (I must have read the previous version carelessly not > >> to spot this.) Making the Global ID of the ULA prefix a hash of the do= main > ID is a fine idea. > >> But I would much prefer the subnet prefixes to be real ones > > > > Define "real ones" please - I don't think I understand... >=20 > Just a plain, normal domain-wide ULA /48 prefix, with longer prefixes > delegated to routers that send regular RAs to hosts that perform regular > SLAAC. IPv6 out of the box. This is essentially what we're doing, minus the RA/SLAAC part. The goal is = that addressing is static for a device, so that I can ALWAYS reach a device= , independently on where it is right now in the topology. The details are t= o some extent up for debate, and we should have that debate.=20 > As I said, I understand your model, I just don't understand why it's requ= ired. > > (But this comes from someone who believes that VLANs are a really bad > idea, too.) :-) Now, I'd like to hear more about that, but that's probably a dinner d= iscussion!=20 Thanks for these substantial comments Brian! I know this model is hard to e= xplain/understand, and really appreciate your help. Your comments really he= lp us understand how to improve the draft.=20 Michael >=20 > Brian >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Thu Mar 5 02:17: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 133BC1A8748 for ; Thu, 5 Mar 2015 02:17:22 -0800 (PST) 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 nqNDwX6q9Ull for ; Thu, 5 Mar 2015 02:17:21 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B4961A1A9C for ; Thu, 5 Mar 2015 02:17:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2050; q=dns/txt; s=iport; t=1425550639; x=1426760239; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=qIGveGHbWDgIZVgLAh51gnxQFPbABA3yasgXCDvg9Sw=; b=bcI1r8KBdDyloQX3poktG1XQQFjCyMoW+saw5dSSj8+MLClV6kePbAOj M95tou3lGMBmhA6kw2wwbAHOaB+c4d1/TfKqDoq48lJdM5/oxqUC1BTZk n6MxgDI9gw9hOBiAZ3e8Y2g6hXocKFmrYTjSUZCYjgmvM9spoozSB3rb+ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AxBgCqaeJU/5xdJa1bgwaBLASCf70TiBsCHHxDAQEBAQEBfIQMAQEBAwEjEUoHBAIBCBEEAQEBAgIGHQMCAgIfERQBCAgCBAESCIgRAwkItyiRSA2FOAEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIYlrgkOBeRYiBoJiLoEUBY84h3GCXoMNgkuGGYJGgz4igjKBPG8BgUN/AQEB X-IronPort-AV: E=Sophos;i="5.11,346,1422921600"; d="scan'208";a="400895476" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 05 Mar 2015 10:17:18 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t25AHIWT001914 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Mar 2015 10:17:18 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.229]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Thu, 5 Mar 2015 04:17:18 -0600 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , Anima WG Thread-Topic: Problem statement [Comments on draft-behringer-anima-autonomic-control-plane-01.txt] Thread-Index: AQHQVtvFmEJJ+jdFs0mchebx7MzhIp0NrL6g Date: Thu, 5 Mar 2015 10:17:17 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22EE77BB@xmb-rcd-x14.cisco.com> References: <20150220084151.13713.88982.idtracker@ietfa.amsl.com> <54F3927C.202@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22EE6A68@xmb-rcd-x14.cisco.com> <54F7A3F7.4000306@gmail.com> In-Reply-To: <54F7A3F7.4000306@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.132] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Problem statement [Comments on draft-behringer-anima-autonomic-control-plane-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: Thu, 05 Mar 2015 10:17:22 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciBb bWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbV0NCj4gU2VudDogMDUgTWFyY2ggMjAx NSAwMTozMg0KPiBUbzogTWljaGFlbCBCZWhyaW5nZXIgKG1iZWhyaW5nKTsgQW5pbWEgV0cNCj4g U3ViamVjdDogUHJvYmxlbSBzdGF0ZW1lbnQgW0NvbW1lbnRzIG9uIGRyYWZ0LWJlaHJpbmdlci1h bmltYS0NCj4gYXV0b25vbWljLWNvbnRyb2wtcGxhbmUtMDEudHh0XQ0KPiANCj4gT24gMDUvMDMv MjAxNSAwNzoyNywgTWljaGFlbCBCZWhyaW5nZXIgKG1iZWhyaW5nKSB3cm90ZToNCj4gDQo+ID4+ PiAyLiAgUHJvYmxlbSBTdGF0ZW1lbnQNCj4gLi4uDQo+ID4+IEkgdGhpbmsgdGhlcmUgYXJlIGEg Y291cGxlIG9mIG1pc3NpbmcgcHJvYmxlbXMgYXQgdGhlIGVuZCBvZiB0aGlzIHNlY3Rpb246DQo+ IC4uLg0KPiA+PiBvIE5lZWQgZm9yIGEgc3RhYmxlIHN1YnN0cmF0ZSBmb3IgbWFuYWdlbWVudCB0 cmFmZmljIHdoZW4gdGhlIG5ldHdvcmsNCj4gPj4gYXMgYSB3aG9sZSBpcyB2YXJpYWJsZSBkdWUg dG8gZHluYW1pYyB2aXJ0dWFsaXphdGlvbiBvZiBhbnkga2luZC4NCj4gPg0KPiA+IFRoYXQgaXMg Y292ZXJlZCBpbiB0aGUgc2Vjb25kIGJ1bGxldD8gSWYgbm90LCB0aGVuIEkgZG9uJ3QgdW5kZXJz dGFuZCB5b3VyDQo+IHBvaW50Pw0KPiANCj4gVGhhdCBidWxsZXQgcmVmZXJzIHRvICJtaXNjb25m aWd1cmF0aW9uIGFuZCByb3V0aW5nIGlzc3VlcyIgd2hpY2ggc2VlbXMgdG8NCj4gbWVhbiBmYXVs dHMgb2Ygc29tZSBraW5kLiBJIHdhcyB0aGlua2luZyBvZiBzY2VuYXJpb3Mgd2hlcmUgZHluYW1p Yw0KPiByZWNvbmZpZ3VyYXRpb24gb2Ygcm91dGluZyB3YXMgaW50ZW50aW9uYWwsIG5vdCBhbiBl cnJvciBjb25kaXRpb24sIGJ1dCB3ZQ0KPiBuZWVkIG1hbmFnZW1lbnQgdHJhZmZpYyB0byBydW4g ZHVyaW5nIHRoZSByZWNvbmZpZ3VyYXRpb24uDQo+IEluIG90aGVyIHdvcmRzIHdlIHVzZSB0aGUg c3RhYmxlIEFDUCBhcyB0aGUgdG9vbCBmb3IgcmVjb25maWd1cmluZyByb3V0aW5nDQo+IGZvciB0 aGUgdGVuYW50IG5ldHdvcmtzLg0KDQpPSywgbm93IEkgdW5kZXJzdGFuZCB5b3UsIHRoYW5rcyBm b3IgY2xhcmlmeWluZy4gVGhpcyBpcyBhY3R1YWxseSB0aGUgaW50ZW50aW9uIG9mIHRoZSAzcmQg YnVsbGV0LiBBbmQgcmUtcmVhZGluZyBpdCwgSSByZWFsbHkgdGhpbmsgd2UgYXJlIGFkZHJlc3Np bmcgdGhpcyBwb2ludC4gUm91dGluZyBjaGFuZ2VzIGFyZSBldmVuIGV4cGxpY2l0bHkgbWVudGlv bmVkIHRoZXJlLiBDYW4geW91IHBsZWFzZSByZS1yZWFkIHRvbyBhbmQgaWYgeW91IGRpc2FncmVl LCBsZXQgdXMga25vdyBob3cgd2UgY291bGQgaW1wcm92ZSBpdD8gDQoNCk1pY2hhZWwNCiANCj4g SSBhZ3JlZSwgdGhpcyBjb3VsZCBiZSBpbmNsdWRlZCBpbiB0aGUgc2Vjb25kIGJ1bGxldC4NCj4g DQo+ICAgICBCcmlhbg0K From nobody Thu Mar 5 02:20: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 6D57E1A8859 for ; Thu, 5 Mar 2015 02:20:36 -0800 (PST) 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 5i81nYvvL57f for ; Thu, 5 Mar 2015 02:20:35 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C901C1A1A6C for ; Thu, 5 Mar 2015 02:20:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=756; q=dns/txt; s=iport; t=1425550836; x=1426760436; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=8MEgZ9d75vVJppHOd6rFMuXzL1t/IwFBh8FHOT8/MAU=; b=TXpQF8ZHA4QQQ+Dsxwn1NNXsfdBX6EnVuV69yTET4SHQVkiGBjAPSDQl srWWQToouTFQA3/9RCE3Y2UNeddKKc/9ygawt8R9TnBQDXfaz36/K+kIs 43U6SzrnUTt/C92XZwhbiP8sEMi9F56/kIDztd659tKkjYw66Vu5SL8QH E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A7CQDvLPhU/5hdJa1agwKBMIMHu3KIIgIcgRZNAQEBAQEBfIQPAQEBAwEjEVUCAQgaAgYgAgICMBUQAgQBGogfCL0Omn4BAQEBAQEBAQEBAQEBAQEBAQEagSGJc4Q9OIJoL4EUAQSQBYU8l30jgjKBPIIzfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,346,1422921600"; d="scan'208";a="397986509" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 05 Mar 2015 10:20:35 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t25AKYZC002439 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Mar 2015 10:20:34 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.229]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Thu, 5 Mar 2015 04:20:33 -0600 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , Anima WG Thread-Topic: SDN controller [Comments on draft-behringer-anima-autonomic-control-plane-01.txt] Thread-Index: AQHQVtq5QwrgoAHGnkizZvAZ7FRAyp0Nra0A Date: Thu, 5 Mar 2015 10:20:33 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22EE77D7@xmb-rcd-x14.cisco.com> References: <20150220084151.13713.88982.idtracker@ietfa.amsl.com> <54F3927C.202@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22EE6A68@xmb-rcd-x14.cisco.com> <54F7A231.4000408@gmail.com> In-Reply-To: <54F7A231.4000408@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.132] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] SDN controller [Comments on draft-behringer-anima-autonomic-control-plane-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: Thu, 05 Mar 2015 10:20:36 -0000 PiA+IEkgdGhpbmsgd2UgZG8gd2FudCB0byBlbXBoYXNpc2UgdGhpcy4gVG8gdGhlICJxdWljayIg cmVhZGVyIHRoZXJlIGlzIHRoZQ0KPiBwb3RlbnRpYWwgbWlzdW5kZXJzdGFuZGluZyB0aGF0IGF1 dG9ub21pY3MgYW5kIFNETiBhcmUgImVpdGhlciBvciIsIGFuZA0KPiB0aGlzIGlzIGNsZWFybHkg bm90IHRoZSBjYXNlLiBUaG9zZSB0d28gcGFyYWRpZ21zIGNvbXBsZW1lbnQgZWFjaCBvdGhlcg0K PiBuaWNlbHkuIEl0IGlzIGltcG9ydGFudCB0byByZW1pbmQgcmVhZGVycyBhYm91dCB0aGlzLg0K PiANCj4gV2VsbCwgSSBjb3VsZCBhZ3JlZSwgYnV0IGluIHRoYXQgY2FzZSBJIHdvdWxkIGJlIGV2 ZW4gbW9yZSBleHBsaWNpdCBhbmQgd3JpdGUNCj4gc29tZXRoaW5nIGxpa2U6DQo+ICAgQm9vdHN0 cmFwcGluZyBhIG5ldyBkZXZpY2UgdHlwaWNhbGx5IHJlcXVpcmVzIGFsbCBkZXZpY2VzIGJldHdl ZW4gYQ0KPiAgIGNvbnRyb2xsaW5nIG5vZGUgKHN1Y2ggYXMgYW4gU0ROIGNvbnRyb2xsZXIpLi4u DQoNCkZpeGVkIGl0LiBUaGFua3MhDQoNCk1pY2hhZWwNCiANCg== From nobody Thu Mar 5 04:16: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 462931A1A79; Thu, 5 Mar 2015 04:16:32 -0800 (PST) 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, 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 4r-emYtF_Kub; Thu, 5 Mar 2015 04:16:29 -0800 (PST) Received: from mailscan1.extendcp.co.uk (mailscan33.extendcp.co.uk [79.170.42.5]) (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 A11541A8773; Thu, 5 Mar 2015 04:16:28 -0800 (PST) Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mailscan2.extendcp.co.uk) by mailscan-g68.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1YTUhW-0006OP-8S; Thu, 05 Mar 2015 12:16:26 +0000 Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mail41.extendcp.co.uk) by mailscan2.extendcp.co.uk with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1YTUhU-0000mA-Ac; Thu, 05 Mar 2015 12:16:26 +0000 Received: from host86-171-66-135.range86-171.btcentralplus.com ([86.171.66.135] helo=[192.168.0.6]) by mail41.extendcp.com with esmtpsa (UNKNOWN:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1YTUhM-0007WM-Kh; Thu, 05 Mar 2015 12:16:17 +0000 Message-ID: <54F8490E.2000005@gridmerge.com> Date: Thu, 05 Mar 2015 12:16:14 +0000 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: Hannes Tschofenig , Rene Struik , Sheng Jiang , Brian E Carpenter , "sarikaya@ieee.org" References: <77FA386512F0D748BC7C02C36EB1106D921776@szxeml557-mbs.china.huawei.com> <6426.1422664463@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D92CC62@szxeml557-mbs.china.huawei.com> <54E7219B.6040006@gridmerge.com> <54E72846.20807@gmx.net> <54E7824A.4040906@gmail.com> <54E86F9A.8020104@gmx.net> <54E8D442.6020909@gmail.com> <54EB4F24.7030609@gmx.net> <54EE6E31.8030609@gmail.com> <54F5E2FF.4040205@gmx.net> <54F60CD2.7030001@gmail.com> <54F627D2.5090806@gmail.com> <54F6305E.8060704@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B923B0552CD@nkgeml512-mbx.china.huawei.com> <54F67E42.4090304@gmail.com> <54F6C220.8020801@gmx.net> In-Reply-To: <54F6C220.8020801@gmx.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090003090204020204000105" X-Authenticated-As: robert.cragie@gridmerge.com X-Extend-Src: mailout Archived-At: Cc: "consultancy@vanderstok.org" , 6tisch-security <6tisch-security@ietf.org>, Michael Richardson , "Hedanping \(Ana\)" , "6lo@ietf.org" <6lo@ietf.org>, "anima@ietf.org" Subject: Re: [Anima] (Fair) competition in pursuing ideas and dreams is good 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: Thu, 05 Mar 2015 12:16:32 -0000 This is a cryptographically signed message in MIME format. --------------ms090003090204020204000105 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable The primary reason for Thread being done in a closed way is to focus on=20 the specification and implementation thereof in a tight and controlled=20 manner. ZigBee IP, which we did in conjunction with the IETF, resulted=20 in continually shifting sands as the specifications kept changing. This=20 meant it took a long time, with implementers continually having to=20 change code, retest etc. This resulted in a lengthy and drawn out=20 development which frankly we can't afford to do in Thread. Sure, there=20 are risks with this approach but the aim is to contribute back on the=20 "rough consensus and running code" basis. This is not a criticism of the = IETF at all; it is simply an approach to manage the unpredictability=20 which will naturally occur in an open development process. A liaison=20 agreement will certainly help and rest assured there are some veterans=20 involved in the Thread development who will make sure it is not too weird= =2E It's no secret that Thread is already based on a number of accepted=20 Internet standards (http://threadgroup.org/Downloads.aspx). We have=20 already successfully demonstrated Thread running in conjunction with=20 another 6LoWPAN implementation, using border routers to connect to a=20 server, with end-to-end CoAP transactions taking place. "6LoWPAN" per se = never has been, nor ever will be an interoperable standard, hence the=20 need for activities like Thread and ZigBee IP to ensure that product=20 certified as such can be interoperable. Robert On 04/03/2015 08:28, Hannes Tschofenig wrote: > While I agree with you, Rene, I still think it is useful to look at > other work that is being done (particularly if they appear relevant to > this group). > > With regards to the security aspects, I believe at least the following > efforts appear relevant: > > * TR69 > * OMA LWM2M > * Netconf Zerotouch > * Certificate management protocols like EST, CMP, etc. > * IEEE 802.1AR > > (Maybe there are others.) > > Looking at those examples provides ideas about what worked well and wha= t > didn't. > > Ciao > Hannes > > On 03/04/2015 04:38 AM, Rene Struik wrote: >> Hi Sheng: >> >> I think you quite misinterpreted my email: I was just commenting on >> guessing games re what industry consortia or others may have up their >> sleeves (not easy to control or influence). From the numerous emails, = I >> got the impression that "Thread" was actually spelled as "Threat". Thi= s >> email exchange would never have happened if it would have been another= >> "Attic project X". >> >> Of course, all goodies re striving for convergence and for consensus >> apply (where discussion re relative technical merit could be viewed as= >> competition of ideas [and what IETF often does quite liberally]). >> >> Rene >> >> On 3/3/2015 8:22 PM, Sheng Jiang wrote: >>>> On 04/03/2015 10:29, Rene Struik wrote: >>>>> Dear colleagues: >>>>> >>>>> I don't understand all the excitement here: everyone is free to dra= w up >>>>> architectural blueprints and complete designs to their liking. This= can >>>>> be done in the attic, as company-internal project, with an industry= >>>>> consortium, or with SDOs, such as IETF. There is no way of knowing= >>>>> what >>>>> people dream up in their attic or in a "secret" project X type of >>>>> effort. Or, is the fear that IETF will loose its lustre? >>>> No. The fear (and it has been realised many times in the past) is >>>> that a closed consortium will agree on and start shipping a solution= >>>> which does not mesh well with the rest of the Internet. A liaison >>>> arrangement can help to avoid that. >>> The IETF is mainly a standardization organization. Most of efforts in= >>> IETF is for interoperation. IETF produces a bunch of open standards, >>> no secret at all. Then every company can implementation the interface= >>> following these standards. Of course, there are many internal >>> implementation, which does not need interoperation with other devices= , >>> and they can be closed or secret. Devices can then interoperate with >>> each other as long as the all following the same standards. >>> >>> Consequently, the main efforts of standardization actually compromise= >>> rather than competition. It is all participators to work together >>> towards a consensus, which most of people could live with (in which >>> maybe everybody have something unsatisfied.) So, people are encourage= d >>> to discuss, coordinate, merge and make compromises. Working along and= >>> producing several competition solutions would NOT be good in any >>> standardization organizations. >>> >>>> Brian >>>> >>>>> Competition (without bullying) is good and is an enticement to cons= ider >>>>> solid designs and thinking outside of the >>>>> "we-did-this-20-years-ago-like-this-and-therefore-have-to-stick-to-= this" >>>>> >>>>> box (the flaky ones will end up with marketing and PR departments o= f >>>>> competing efforts to poke fun at). >>>>> >>>>> Best regards, Rene >>>>> >>>>> >>>>> On 3/3/2015 2:34 PM, Brian E Carpenter wrote: >>>>>> On 04/03/2015 05:36, Hannes Tschofenig wrote: >>>>>>> At the moment the specifications are only available to Thread mem= bers >>>>>>> since the specification is still work in progress. >>>>>>> >>>>>>> I don't know when it will be finalized and released to the wider >>>>>>> public. >>>>>>> >>>>>>> Regarding the liaison I do not have an opinion about the value of= it. >>>>>> It is precisely to get access before the work is finalised, so tha= t it >>>>>> can be reviewed by all the right people. We know that closed stand= ards >>>>>> development produces bad standards. >>>>>> >>>>>> Brian >>>>>> >>>>>>> Ciao >>>>>>> Hannes >>>>>>> >>>>>>> >>>>>>> On 02/26/2015 01:52 AM, Brian E Carpenter wrote: >>>>>>>> On 26/02/2015 10:25, Behcet Sarikaya wrote: >>>>>>>> >>>>>>>> ... >>>>>>>>>>> I know nothing about Thread, whatever and whoever it is. >>>>>>>>>> Here is an intro document: >>>>>>>>>> http://threadgroup.org/Portals/0/documents/events/ThreadIntro.= pdf >>>>>>>> Thanks for that. It seems to have all the downsides of secretive= >>>>>>>> ad hoc >>>>>>>> membership-based consortia, except for the upside of a RAND-RF I= PR >>>>>>>> policy. >>>>>>>> >>>>>>>>> I think we need to clarify here that Thread Group is formed to = deal >>>>>>>>> with home environments. >>>>>>>>> >>>>>>>>> Enterprise or industrial environments seem to be excluded. >>>>>>>> So far. The boundary between this and larger building services >>>>>>>> networks is pretty fuzzy, isn't it? >>>>>>>> >>>>>>>> In any case, should we (the WGs on copy, and perhaps some others= ) >>>>>>>> be asking the IAB to arrange a meaningful liaison with Thread? >>>>>>>> >>>>>>>> Back at Hannes: is there a spec for their approach to security >>>>>>>> enrollment? >>>>>>>> >>>>>>>> Brian >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Anima mailing list >>>>>>>> Anima@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/anima >>>>>>>> >>>>>> _______________________________________________ >>>>>> 6tisch-security mailing list >>>>>> 6tisch-security@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/6tisch-security >>>> _______________________________________________ >>>> 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 >> --------------ms090003090204020204000105 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 Fw0xNTAzMDUxMjE2MTRaMCMGCSqGSIb3DQEJBDEWBBRPLWvc9awtZcRS6qJfUHshfTZY8DBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG+BgkrBgEEAYI3EAQxgbAwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhEAkJNVgmy0T3j/sFnejfTMyTCBwAYLKoZIhvcNAQkQAgsxgbCgga0w gZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8g UlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkJNVgmy0 T3j/sFnejfTMyTANBgkqhkiG9w0BAQEFAASCAQBc9EUcgBriR7dv9aesktnGDuusvi2Dms4b ASJOtfGOqC0lnzVmjaksn0tiTdd9K8Epvp4dSlI7KX4HitsepNQnXRNR4g0UuEFGBmVwsKLF +bPPasA+1u0iv2+KC2ZYmDTmJURaf3LBTJOHHRwrcq1jzO/Xec6a69Ft+dkeA+uMVh/0SQcu dksHvjls+BFJ2X7o8M4hf7y+N3t4S9JV/yyO/jPi1Ieyt3Im0f9lKyTxOmzO87oXR9/p5a/h u04R1Q1LbjAoU96jHrOKb5Wo0BnQSeQdg6KbwcE2LstRwzKz60/NTMu6Ixbrd16SNNDUUnC0 5jCr8oAMsar/a5EEe6ViAAAAAAAA --------------ms090003090204020204000105-- From nobody Thu Mar 5 11:37: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 4037E1A885C for ; Thu, 5 Mar 2015 11:37:45 -0800 (PST) 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 DyHO9PAbBg4i for ; Thu, 5 Mar 2015 11:37:43 -0800 (PST) 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 DA7211A885D for ; Thu, 5 Mar 2015 11:37:41 -0800 (PST) Received: by pdno5 with SMTP id o5so68744613pdn.8 for ; Thu, 05 Mar 2015 11:37:41 -0800 (PST) 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=3tNguPq6rCIMFqUKzDSEH34GXswJE8NnXV2u844GwQk=; b=rr1byEIdq84lcZvgh0LK6+ATVQIA7nl+nzHFu3rYld0JBBbXPrYyj8M8q54PaSC2Iw Wr/W7NPZL4C+sgEc6xauwetxaePboVdU4HcjfUeFV228D50rlLSl5mYfy+1X2zJR+XRT kHfxLZFIvuSfDOnGxXmSPG1XFvMXjvazW6yc/kHERawB4EmJGbsEIuofs/Je6ZCVpuis aaXt0f+xgWn+CeFZ5shnaUzqjNYx5P1avO6agP5qVNOQigF5WfPrBt8WXeiTBwLhgeRZ 2wG1t6IClWae3b12NELTS/ox1xUaK5c1gcMVODLfXQ30Et8hLLmYxOv7q/MhjPeumvAv +2rQ== X-Received: by 10.68.142.169 with SMTP id rx9mr18450077pbb.41.1425584261426; Thu, 05 Mar 2015 11:37:41 -0800 (PST) Received: from ?IPv6:2406:e007:7e38:1:28cc:dc4c:9703:6781? ([2406:e007:7e38:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id bt2sm7742342pad.12.2015.03.05.11.37.38 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Mar 2015 11:37:40 -0800 (PST) Message-ID: <54F8B08B.9040402@gmail.com> Date: Fri, 06 Mar 2015 08:37:47 +1300 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.5.0 MIME-Version: 1.0 To: "Michael Behringer (mbehring)" , Anima WG References: <20150220084151.13713.88982.idtracker@ietfa.amsl.com> <54F3927C.202@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22EE6A68@xmb-rcd-x14.cisco.com> <54F7A3F7.4000306@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22EE77BB@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22EE77BB@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Problem statement [Comments on draft-behringer-anima-autonomic-control-plane-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: Thu, 05 Mar 2015 19:37:45 -0000 On 05/03/2015 23:17, Michael Behringer (mbehring) wrote: >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: 05 March 2015 01:32 >> To: Michael Behringer (mbehring); Anima WG >> Subject: Problem statement [Comments on draft-behringer-anima- >> autonomic-control-plane-01.txt] >> >> On 05/03/2015 07:27, Michael Behringer (mbehring) wrote: >> >>>>> 2. Problem Statement >> ... >>>> I think there are a couple of missing problems at the end of this section: >> ... >>>> o Need for a stable substrate for management traffic when the network >>>> as a whole is variable due to dynamic virtualization of any kind. >>> >>> That is covered in the second bullet? If not, then I don't understand your >> point? >> >> That bullet refers to "misconfiguration and routing issues" which seems to >> mean faults of some kind. I was thinking of scenarios where dynamic >> reconfiguration of routing was intentional, not an error condition, but we >> need management traffic to run during the reconfiguration. >> In other words we use the stable ACP as the tool for reconfiguring routing >> for the tenant networks. > > OK, now I understand you, thanks for clarifying. This is actually the intention of the 3rd bullet. And re-reading it, I really think we are addressing this point. Routing changes are even explicitly mentioned there. Can you please re-read too and if you disagree, let us know how we could improve it? Well, two points about the 3rd bullet: it reads almost as though all networks will be SDN, which is far from universally accepted, and it says the ACP will "simplify" changes, which I think undersells the benefit considerably. It's actually transformational compared to either an inband approach or a traditional separate control plane. (BTW I assume that the ACP would be very valuable for managing SFC too.) I think we are in violent agreement about the intent here. Brian > Michael > >> I agree, this could be included in the second bullet. >> >> Brian From nobody Fri Mar 6 05:39: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 AA58C1ACE0F for ; Fri, 6 Mar 2015 05:39:51 -0800 (PST) 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 e22cKdpw5foq for ; Fri, 6 Mar 2015 05:39:50 -0800 (PST) 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 6C4431ACE03 for ; Fri, 6 Mar 2015 05:39:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2304; q=dns/txt; s=iport; t=1425649192; x=1426858792; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=yB3/CiqMN5hSkCoohEVe6xxGJnVpSjBwsrzQ1InKYkk=; b=Deozt7e7bQKOgyfmqGllVMVtn2ePbXUd4/dG5YA2abR9/rU1wpkQzueG 7rvEtlu1765eO5uR+bn9q/SAvchB2feZ/tTm5oEjD2G7Griw9+tP/ry0P bajhgoJ71Lkc+bZLXoVBibWqbsefNj1fu4XDszX5OufMsLlyGNz5f6sbs 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CfCAAZrflU/4UNJK1cgwaBMIMGvDCIJgIcgRxNAQEBAQEBfIQPAQEBAwEjEUoLAgEIGgIGIAICAjAVEAIEARqIHwi0PppVAQEBAQEBAQEBAQEBAQEBAQEBGoEhiXaEPTiCaC+BFAWQB4pngyaCVIxbI4IygTyCM38BAQE X-IronPort-AV: E=Sophos;i="5.11,352,1422921600"; d="scan'208";a="129554134" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-4.cisco.com with ESMTP; 06 Mar 2015 13:39:51 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t26DdnPs010371 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Mar 2015 13:39:49 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.229]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Fri, 6 Mar 2015 07:39:49 -0600 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , Anima WG Thread-Topic: Problem statement [Comments on draft-behringer-anima-autonomic-control-plane-01.txt] Thread-Index: AQHQVtvFmEJJ+jdFs0mchebx7MzhIp0NrL6ggAEB1oCAAMf9MA== Date: Fri, 6 Mar 2015 13:39:48 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22EE96C6@xmb-rcd-x14.cisco.com> References: <20150220084151.13713.88982.idtracker@ietfa.amsl.com> <54F3927C.202@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22EE6A68@xmb-rcd-x14.cisco.com> <54F7A3F7.4000306@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22EE77BB@xmb-rcd-x14.cisco.com> <54F8B08B.9040402@gmail.com> In-Reply-To: <54F8B08B.9040402@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.132] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Problem statement [Comments on draft-behringer-anima-autonomic-control-plane-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, 06 Mar 2015 13:39:51 -0000 PiA+PiBUaGF0IGJ1bGxldCByZWZlcnMgdG8gIm1pc2NvbmZpZ3VyYXRpb24gYW5kIHJvdXRpbmcg aXNzdWVzIiB3aGljaA0KPiA+PiBzZWVtcyB0byBtZWFuIGZhdWx0cyBvZiBzb21lIGtpbmQuIEkg d2FzIHRoaW5raW5nIG9mIHNjZW5hcmlvcyB3aGVyZQ0KPiA+PiBkeW5hbWljIHJlY29uZmlndXJh dGlvbiBvZiByb3V0aW5nIHdhcyBpbnRlbnRpb25hbCwgbm90IGFuIGVycm9yDQo+ID4+IGNvbmRp dGlvbiwgYnV0IHdlIG5lZWQgbWFuYWdlbWVudCB0cmFmZmljIHRvIHJ1biBkdXJpbmcgdGhlDQo+ IHJlY29uZmlndXJhdGlvbi4NCj4gPj4gSW4gb3RoZXIgd29yZHMgd2UgdXNlIHRoZSBzdGFibGUg QUNQIGFzIHRoZSB0b29sIGZvciByZWNvbmZpZ3VyaW5nDQo+ID4+IHJvdXRpbmcgZm9yIHRoZSB0 ZW5hbnQgbmV0d29ya3MuDQo+ID4NCj4gPiBPSywgbm93IEkgdW5kZXJzdGFuZCB5b3UsIHRoYW5r cyBmb3IgY2xhcmlmeWluZy4gVGhpcyBpcyBhY3R1YWxseSB0aGUNCj4gaW50ZW50aW9uIG9mIHRo ZSAzcmQgYnVsbGV0LiBBbmQgcmUtcmVhZGluZyBpdCwgSSByZWFsbHkgdGhpbmsgd2UgYXJlDQo+ IGFkZHJlc3NpbmcgdGhpcyBwb2ludC4gUm91dGluZyBjaGFuZ2VzIGFyZSBldmVuIGV4cGxpY2l0 bHkgbWVudGlvbmVkIHRoZXJlLg0KPiBDYW4geW91IHBsZWFzZSByZS1yZWFkIHRvbyBhbmQgaWYg eW91IGRpc2FncmVlLCBsZXQgdXMga25vdyBob3cgd2UgY291bGQNCj4gaW1wcm92ZSBpdD8NCj4g DQo+IFdlbGwsIHR3byBwb2ludHMgYWJvdXQgdGhlIDNyZCBidWxsZXQ6IGl0IHJlYWRzIGFsbW9z dCBhcyB0aG91Z2ggYWxsIG5ldHdvcmtzDQo+IHdpbGwgYmUgU0ROLCB3aGljaCBpcyBmYXIgZnJv bSB1bml2ZXJzYWxseSBhY2NlcHRlZCwgYW5kIGl0IHNheXMgdGhlIEFDUCB3aWxsDQo+ICJzaW1w bGlmeSIgY2hhbmdlcywgd2hpY2ggSSB0aGluayB1bmRlcnNlbGxzIHRoZSBiZW5lZml0IGNvbnNp ZGVyYWJseS4gSXQncw0KPiBhY3R1YWxseSB0cmFuc2Zvcm1hdGlvbmFsIGNvbXBhcmVkIHRvIGVp dGhlciBhbiBpbmJhbmQgYXBwcm9hY2ggb3IgYQ0KPiB0cmFkaXRpb25hbCBzZXBhcmF0ZSBjb250 cm9sIHBsYW5lLg0KDQpPSywgd2UndmUgbm93IHJlLXdyaXR0ZW4gdGhlIGVudGlyZSBzZWN0aW9u LCBhbmQgY29tYmluZWQgc2VjdGlvbnMgMiBhbmQgNi4gOi0pICAgV2lsbCBiZSBvdXQgbGF0ZXIg dG9kYXkuIA0KIA0KPiAoQlRXIEkgYXNzdW1lIHRoYXQgdGhlIEFDUCB3b3VsZCBiZSB2ZXJ5IHZh bHVhYmxlIGZvciBtYW5hZ2luZyBTRkMgdG9vLikNCg0KQWJzb2x1dGVseS4gVGhlcmUgYXJlIG1h bnkgdXNlcyBmb3IgdGhlIEFDUC4gDQogDQo+IEkgdGhpbmsgd2UgYXJlIGluIHZpb2xlbnQgYWdy ZWVtZW50IGFib3V0IHRoZSBpbnRlbnQgaGVyZS4NCg0KVGhhbmtzLiBJJ20gc3RpbGwgY29uY2Vy bmVkIGFib3V0IG1ha2luZyB0aGUgZHJhZnQgZWFzaWVyIHRvIHVuZGVyc3RhbmQsIGJ1dCB0aGUg bmV3IHZlcnNpb24gc2hvdWxkIGhvcGVmdWxseSBiZSBjbGVhcmVyLCB3aXRoIGFuICJvdmVydmll dyIgc2VjdGlvbi4gDQoNCk1pY2hhZWwNCg0KPiAgICBCcmlhbg0KPiANCj4gPiBNaWNoYWVsDQo+ ID4NCj4gPj4gSSBhZ3JlZSwgdGhpcyBjb3VsZCBiZSBpbmNsdWRlZCBpbiB0aGUgc2Vjb25kIGJ1 bGxldC4NCj4gPj4NCj4gPj4gICAgIEJyaWFuDQo= From nobody Fri Mar 6 07:11:36 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 942921A6F15 for ; Fri, 6 Mar 2015 07:11:26 -0800 (PST) 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 HUeXFVLlp9sW for ; Fri, 6 Mar 2015 07:11:25 -0800 (PST) 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 CDD2F1A0099 for ; Fri, 6 Mar 2015 07:11:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3552; q=dns/txt; s=iport; t=1425654684; x=1426864284; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ZhDzuWzCX60hhv1p2ythqrYHQr86P14uWmqOSEesfmc=; b=HdpqxgWn4P5dcXPxXBHDzVwx1PRZtW5fr+9f3SusHSuaXK8EXdLqtlGi AV0MUrYFPWPXNuTYYreuIU7PS/y29E54y9zC7Uva4lm6RnZuY9yvEUJLS JnQpdTqeCAAhMy8QMxz67hALg9IvqaqAAsL/aADFFURpJQgQNofDtgZ8Z M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DFCAB2wvlU/5FdJa1cgwZSVQUEgwa8MoI2hXACHIEdTQEBAQEBAXyEDwEBAQQjEUMOBAIBCBEEAQEDAgYdAwICAjAUAQYBAQUDAgQTCAGIJggFs0eaWAEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIYl2hD04BoJiL4EUBZAHg2OHBDmCbYJUjFsjgjKBPG+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.11,353,1422921600"; d="scan'208";a="401464819" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-3.cisco.com with ESMTP; 06 Mar 2015 15:11:23 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t26FBLMY029352 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 6 Mar 2015 15:11:22 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.229]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Fri, 6 Mar 2015 09:11:21 -0600 From: "Michael Behringer (mbehring)" To: Anima WG Thread-Topic: New Version Notification for draft-behringer-anima-autonomic-control-plane-02.txt Thread-Index: AQHQWB8MNgJZ0VLH8EypUafYk9uHT50PjhoQ Date: Fri, 6 Mar 2015 15:11:20 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22EE990E@xmb-rcd-x14.cisco.com> References: <20150306150550.8486.2288.idtracker@ietfa.amsl.com> In-Reply-To: <20150306150550.8486.2288.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.132] 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-control-plane-02.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, 06 Mar 2015 15:11:26 -0000 QU5JTUEgV0csIA0KDQpUaGlzIG5ldyB2ZXJzaW9uIHRha2VzIGludG8gYWNjb3VudHMgdGhlIGZ1 bGwgcmV2aWV3IHJlY2VpdmVkIGZyb20gQnJpYW4gKHRoYW5rcykuIEl0IGhhcyBzb21lIG1ham9y IGNoYW5nZXMsIHdlIGFkZGVkIGFuICJvdmVydmlldyIgc2VjdGlvbiwgdG8gbWFrZSB0aGUgY29u Y2VwdCBlYXNpZXIgdG8gdW5kZXJzdGFuZCwgY29tYmluZWQgcHJvYmxlbSBzdGF0ZW1lbnQgYW5k IHVzZSBjYXNlcyBpbnRvIG9uZSBzZWN0aW9uLCBhbmQgcXVpdGUgYSBsb3Qgb2YgZWRpdG9yaWFs IG5pdHMuIA0KDQpXZSByZWFsbHkgaG9wZSB0aGF0IHRoaXMgbWFrZXMgdGhlIGRyYWZ0IGVhc2ll ciB0byByZWFkIGFuZCB1bmRlcnN0YW5kLiANCg0KVGhpcyBkb2N1bWVudCB3aWxsIGJlIG9uIHRo ZSBhZ2VuZGEgZm9yIHRoZSBBTklNQSBzZXNzaW9uIGluIERhbGxhcyAtIHBsZWFzZSByZWFkIGFu ZCBwcm92aWRlIGlucHV0ISBUaGlzIGRvY3VtZW50IHBlcnRhaW5zIHRvIGEgbWlsZSBzdG9uZSBp biB0aGUgY2hhcnRlciwgYW5kIHdlJ2QgbGlrZSB0byBhc2sgZm9yIFdHIGFkb3B0aW9uLCBwcm9i YWJseSBpbiBEYWxsYXMuIA0KDQpUaGFua3MsIA0KTWljaGFlbA0KDQoNCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86 aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPiBTZW50OiAwNiBNYXJjaCAyMDE1IDE2OjA2DQo+ IFRvOiBCYWxhamkgQiBMIChibGJhbGFqaSk7IE1pY2hhZWwgQmVocmluZ2VyIChtYmVocmluZyk7 IFRvZXJsZXNzIEVja2VydA0KPiAoZWNrZXJ0KTsgU3RlaW50aG9yIEJqYXJuYXNvbiAoc2JqYXJu YXMpOyBNaWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpOw0KPiBUb2VybGVzcyBFY2tlcnQgKGVj a2VydCk7IFN0ZWludGhvciBCamFybmFzb24gKHNiamFybmFzKTsgQmFsYWppIEIgTCAoYmxiYWxh amkpDQo+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYmVocmlu Z2VyLWFuaW1hLWF1dG9ub21pYy0NCj4gY29udHJvbC1wbGFuZS0wMi50eHQNCj4gDQo+IA0KPiBB IG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYmVocmluZ2VyLWFuaW1hLWF1dG9ub21pYy1jb250 cm9sLXBsYW5lLQ0KPiAwMi50eHQNCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBi eSBNaWNoYWVsIEguIEJlaHJpbmdlciBhbmQgcG9zdGVkIHRvIHRoZQ0KPiBJRVRGIHJlcG9zaXRv cnkuDQo+IA0KPiBOYW1lOgkJZHJhZnQtYmVocmluZ2VyLWFuaW1hLWF1dG9ub21pYy1jb250cm9s LXBsYW5lDQo+IFJldmlzaW9uOgkwMg0KPiBUaXRsZToJCUFuIEF1dG9ub21pYyBDb250cm9sIFBs YW5lDQo+IERvY3VtZW50IGRhdGU6CTIwMTUtMDMtMDYNCj4gR3JvdXA6CQlJbmRpdmlkdWFsIFN1 Ym1pc3Npb24NCj4gUGFnZXM6CQkxNg0KPiBVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYmVocmluZ2VyLWFuaW1hLQ0KPiBhdXRvbm9taWMt Y29udHJvbC1wbGFuZS0wMi50eHQNCj4gU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJlaHJpbmdlci1hbmltYS0NCj4gYXV0b25vbWljLWNvbnRy b2wtcGxhbmUvDQo+IEh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1iZWhyaW5nZXItYW5pbWEtYXV0b25vbWljLQ0KPiBjb250cm9sLXBsYW5lLTAyDQo+IERp ZmY6ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1iZWhy aW5nZXItYW5pbWEtDQo+IGF1dG9ub21pYy1jb250cm9sLXBsYW5lLTAyDQo+IA0KPiBBYnN0cmFj dDoNCj4gICAgSW4gY2VydGFpbiBzY2VuYXJpb3MsIGZvciBleGFtcGxlIHdoZW4gYm9vdHN0cmFw cGluZyBhIG5ldHdvcmssIGl0IGlzDQo+ICAgIGRlc2lyYWJsZSB0byBhdXRvbWF0aWNhbGx5IGJy aW5nIHVwIGEgc2VjdXJlLCByb3V0ZWQgY29udHJvbCBwbGFuZSwNCj4gICAgd2hpY2ggaXMgaW5k ZXBlbmRlbnQgb2YgZGV2aWNlIGNvbmZpZ3VyYXRpb25zIGFuZCBnbG9iYWwgcm91dGluZw0KPiAg ICB0YWJsZS4gIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGFuIGFwcHJvYWNoIGZvciBhIGxvZ2lj YWxseSBzZXBhcmF0ZWQNCj4gICAgIkF1dG9ub21pYyBDb250cm9sIFBsYW5lIiwgd2hpY2ggY2Fu IGJlIHVzZWQgYXMgYSAidmlydHVhbCBvdXQgb2YNCj4gICAgYmFuZCBjaGFubmVsIiAtIGEgc2Vs Zi1tYW5hZ2luZyBvdmVybGF5IG5ldHdvcmssIHdoaWNoIGlzIGluZGVwZW5kZW50DQo+ICAgIG9m IGNvbmZpZ3VyYXRpb24sIGFkZHJlc3NpbmcgYW5kIHJvdXRpbmcgb24gdGhlIGRhdGEgcGxhbmUu DQo+IA0KPiANCj4gDQo+IA0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxl IG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1s aXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+ IA0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Fri Mar 6 11:47: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 E36101A6EED for ; Fri, 6 Mar 2015 11:47:36 -0800 (PST) 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 who9qYhbcWlW for ; Fri, 6 Mar 2015 11:47:35 -0800 (PST) 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 386AD1A6F3B for ; Fri, 6 Mar 2015 11:47:32 -0800 (PST) Received: by pdev10 with SMTP id v10so17031716pde.13 for ; Fri, 06 Mar 2015 11:47:31 -0800 (PST) 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=aQ6ueEb/3fHA6cB8lrGs+FcaGojzNlC8QdTRcCj9yts=; b=EkSOXoFzoV+OiC9evh4CeFK+1pF3uRU2Kzo/2Nw4qFdCy2pjZxp3pFHhQNV48JnZPs lzbMOD/nRDlbg1cxylCosYw0h3UYj51JeVmjmjNT81KaOs2c7Hf/FOglk44GZHnJn/9W qVRcp6k6uuPxzbrfPm2eDhzTnE/yXF8APjufW1WQW4qmNyTpuQSYlf18L6uoVEd7Gml0 eA0b9mIyJ0tbHJ9wRTuGEMFi46qKx5CEtMVQ1884j6Chf7mOyhLrWKzBk6I9cENKrA4N qCdP9y04QSUI5DGQomopyc8kwkuacPimPY0kfuCKTZ3jfe0/fnPs0Cy4kd72ptCwTr9a kPYQ== X-Received: by 10.70.37.65 with SMTP id w1mr28354713pdj.51.1425671251875; Fri, 06 Mar 2015 11:47:31 -0800 (PST) Received: from ?IPv6:2406:e007:5871:1:28cc:dc4c:9703:6781? ([2406:e007:5871:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id br15sm10224849pdb.76.2015.03.06.11.47.29 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Mar 2015 11:47:31 -0800 (PST) Message-ID: <54FA045C.6090604@gmail.com> Date: Sat, 07 Mar 2015 08:47:40 +1300 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.5.0 MIME-Version: 1.0 To: Anima WG References: <20150306163647.31030.58285.idtracker@ietfa.amsl.com> In-Reply-To: <20150306163647.31030.58285.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-eckert-anima-stable-connectivity-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, 06 Mar 2015 19:47:37 -0000 Hi, Thanks for this. Just one comment. I'm not sure it's very useful to mention ULA-C, since no such thing has been standardised; RFC 4193 doesn't even hint at it beyond saying "Another method, indicated by clearing the L bit, may be defined later." I think the discussion will just confuse readers. Regards Brian From nobody Fri Mar 6 16:25: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 5C43D1A8782 for ; Fri, 6 Mar 2015 16:25:37 -0800 (PST) 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 MdW9DLjW4z-F for ; Fri, 6 Mar 2015 16:25:36 -0800 (PST) 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 A100D1A1BCE for ; Fri, 6 Mar 2015 16:25:31 -0800 (PST) Received: by pablj1 with SMTP id lj1so46354408pab.10 for ; Fri, 06 Mar 2015 16:25:31 -0800 (PST) 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=WPD8mueAvYpBd87l5WEvlyXk1o4BjMHXWYb0MgSfK+A=; b=tRZshyGNpyObN9CYnogFwRYYbnNq+IwbVs3EH4WJHxREsbN0Ygqp13UP8tZWWk9Qdp lj1ih55TbrGfSop8zoJHaJZBc9qtBwNfiqET74boxt259hzGddeOWfpwvCEC/vDIjoaL qTjP09Krh/hHEY79r581uc+Wu9RbVsl4e7VeiwmHj53cv0GICyjZtLuUFVVRN85zF+fu WYT77TPPbKT+n+8otnHfLvyPgh4j6me+7XF24z1wLfSpj1aluhgGWU30yZ9XWqX8ny7I w5F6YtTE/ltRk3se16HUmpu0t4Cg++6HdZp8VPmGVY7gzI9srsPxbPbxr/j+ds7ghnSA oHrw== X-Received: by 10.70.135.106 with SMTP id pr10mr29819142pdb.144.1425687931381; Fri, 06 Mar 2015 16:25:31 -0800 (PST) Received: from ?IPv6:2406:e007:5871:1:28cc:dc4c:9703:6781? ([2406:e007:5871:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id hz8sm10692736pac.5.2015.03.06.16.25.28 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Mar 2015 16:25:30 -0800 (PST) Message-ID: <54FA4583.5040001@gmail.com> Date: Sat, 07 Mar 2015 13:25:39 +1300 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.5.0 MIME-Version: 1.0 To: Anima WG References: <20150306150550.8486.26176.idtracker@ietfa.amsl.com> In-Reply-To: <20150306150550.8486.26176.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-control-plane-02.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: Sat, 07 Mar 2015 00:25:37 -0000 Thanks for this. It is now much clearer to me. We can debate the pros and cons of the VRF approach in the WG meeting. Regards Brian From nobody Mon Mar 9 02:56: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 CA8241A020B for ; Sun, 8 Mar 2015 16:16: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 wy_T2qDtZTsC for ; Sun, 8 Mar 2015 16:16:02 -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 47B041A0204 for ; Sun, 8 Mar 2015 16:16:02 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CBFBC20098; Sun, 8 Mar 2015 19:24:56 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id F31B563784; Sun, 8 Mar 2015 19:16:00 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E154963770; Sun, 8 Mar 2015 19:16:00 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter In-Reply-To: <54FA045C.6090604@gmail.com> References: <20150306163647.31030.58285.idtracker@ietfa.amsl.com> <54FA045C.6090604@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: X-Mailman-Approved-At: Mon, 09 Mar 2015 02:56:53 -0700 Cc: Anima WG Subject: Re: [Anima] I-D Action: draft-eckert-anima-stable-connectivity-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: Sun, 08 Mar 2015 23:16:03 -0000 Brian E Carpenter wrote: > Just one comment. I'm not sure it's very useful to mention ULA-C, since > no such thing has been standardised; RFC 4193 doesn't even hint at it > beyond saying "Another method, indicated by clearing the L bit, may be > defined later." I think the discussion will just confuse readers. I take it differently: I think that this is a reason to document ULA-C. From nobody Mon Mar 9 12:28:19 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 B7D911A8AA7 for ; Mon, 9 Mar 2015 12:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 p8my9ObOlnr0 for ; Mon, 9 Mar 2015 12:28:15 -0700 (PDT) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) (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 166BE1A00FB for ; Mon, 9 Mar 2015 12:28:12 -0700 (PDT) Received: by obcvb8 with SMTP id vb8so31947091obc.10 for ; Mon, 09 Mar 2015 12:28:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=OMVJqP/wFzTQrjND5oatEIQac+7z26g4Ejjs26XgfyM=; b=B665gEBypz+0uQ2WBw+8ZIwKcQDR458bkVn1bRBgkDbdG6rjWcgEIzQ58UI36HbmN5 Z/w+zBbodXc/1c23oEXZ9HbqV244uT1sRq+r6waxyEtX5aJtmfSYfGYKgwXNztyGv1AI qQHhvMhrCtZyaJHX3H2Cq4Uk+jqcIDRbv6uR/jtBMHq90/WyoAX/OdS0mC88S/n7UfKv MlaS64IgP+7PHpaNLqRnREgfNEgYjKeINsi9nHHRz7GNTUhlYGtbvJerx0G8VkgNRt2A DdypvZ7ClJaOcmVvRVgIoN7v+vAtdBp9KJp9a8qv5Ko3H2PQz5vnU91/W/zWyvNVg6jq UbwQ== X-Gm-Message-State: ALoCoQmqIwiMcsIny5U6To/OYZCw6RdPFZd4dQt8XQUtFkICB2OcPA/aIf14DjadKBWVV+RZsaOa MIME-Version: 1.0 X-Received: by 10.202.217.9 with SMTP id q9mr21815476oig.35.1425929292425; Mon, 09 Mar 2015 12:28:12 -0700 (PDT) Received: by 10.76.150.2 with HTTP; Mon, 9 Mar 2015 12:28:12 -0700 (PDT) In-Reply-To: <14941.1425856560@sandelman.ca> References: <20150306163647.31030.58285.idtracker@ietfa.amsl.com> <54FA045C.6090604@gmail.com> <14941.1425856560@sandelman.ca> Date: Mon, 9 Mar 2015 12:28:12 -0700 Message-ID: From: James Woodyatt To: Anima WG Content-Type: multipart/alternative; boundary=001a113cd400f345d40510e008af Archived-At: Subject: Re: [Anima] I-D Action: draft-eckert-anima-stable-connectivity-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: Mon, 09 Mar 2015 19:28:17 -0000 --001a113cd400f345d40510e008af Content-Type: text/plain; charset=UTF-8 I agree with Brian, and furthermore I don't agree with the judgment in this paragraph: Centrally assigned ULA addresses (ULA-C) would be an even better > choice than currently available randomnly self-assigned (ULA-R) > addresses, because they would permit to audit who owns the address > prefix if these addresses show up in places where they are not > expected (for example in above mentioned operational issues). I can see an argument here for a registry, but not one for an assignment authority. It is not at all clear to me how a central assignment authority can operate with even less risk of duplication than the already epsilon level of risk in the random self-assignment of RFC 4193. This statement appears to take it as axiomatic, and I think it's very debatable. On Sun, Mar 8, 2015 at 4:16 PM, Michael Richardson wrote: > > Brian E Carpenter wrote: > > Just one comment. I'm not sure it's very useful to mention ULA-C, > since > > no such thing has been standardised; RFC 4193 doesn't even hint at it > > beyond saying "Another method, indicated by clearing the L bit, may > be > > defined later." I think the discussion will just confuse readers. > > I take it differently: I think that this is a reason to document ULA-C. > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > -- james woodyatt Nest Labs, Communications Engineering --001a113cd400f345d40510e008af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree with Brian, and furthermore I don't agree with= the judgment in this paragraph:

Centrally as= signed ULA addresses (ULA-C) would be an even better
choice than curr= ently available randomnly self-assigned (ULA-R)
addresses, because th= ey would permit to audit who owns the address
prefix if these address= es show up in places where they are not
expected (for example in abov= e mentioned operational issues).

I ca= n see an argument here for a registry, but not one for an assignment author= ity. It is not at all clear to me how a central assignment authority can op= erate with even less risk of duplication than the already epsilon level of = risk in the random self-assignment of RFC 4193. This statement appears to t= ake it as axiomatic, and I think it's very debatable.

On Sun, Mar 8, 2015 at = 4:16 PM, Michael Richardson <mcr@sandelman.ca> wrote:

Brian E Carpenter <brian.= e.carpenter@gmail.com> wrote:
=C2=A0 =C2=A0 > Just one comment. I'm not sure it's very useful = to mention ULA-C, since
=C2=A0 =C2=A0 > no such thing has been standardised; RFC 4193 doesn'= t even hint at it
=C2=A0 =C2=A0 > beyond saying "Another method, indicated by clearin= g the L bit, may be
=C2=A0 =C2=A0 > defined later." I think the discussion will just co= nfuse readers.

I take it differently: I think that this is a reason to document ULA= -C.



_______________________________________________
Anima mailing list
Anima@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/anima



--
=
james woodyatt <jhw@nestlabs.com>Nest Labs, Communications Engineering
--001a113cd400f345d40510e008af-- From nobody Mon Mar 9 13:06: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 049631A9070 for ; Mon, 9 Mar 2015 13:06:55 -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 ecVlX_Tv1yzQ for ; Mon, 9 Mar 2015 13:06:53 -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 AC9671AC3C6 for ; Mon, 9 Mar 2015 13:06:47 -0700 (PDT) Received: by pdno5 with SMTP id o5so23173086pdn.1 for ; Mon, 09 Mar 2015 13:06:47 -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=mbul0F48sH5VuTnmXb9RPZWbkriR9WVgvLpsYSToWP0=; b=00djB25o5hu6HC/nrDEByw+esxg6d2XC9lEYnr/mW/6vMkrGVYNN+av26iqy9YeRCg oQlyCqzF6xOLUXo2b/ljCxvaRRsem7iLClZxCMFTpco/bl2563v+KPwF3IJ2Bi8q8ZCF Fw+cBgWasb0K/K7/syq+3VyXEnTtkeWpng/c7xdlmIRE78w46TX6CBYu4I/ifhSyEibn 7S4il2jTM51P/dpg560leH94IsvzwnWcL0AC5Deufdq/y6iLX+upsxfGjbBfbAF9C/vr AkJ+OLTrc3mYa1FVDgD6W+kpjX51Qst2f7JzJZhw+ToJ/wd28c67C2WSUmSAkjybWnCt QqmQ== X-Received: by 10.70.33.3 with SMTP id n3mr23469352pdi.132.1425931607280; Mon, 09 Mar 2015 13:06:47 -0700 (PDT) Received: from [10.1.9.163] ([103.23.18.15]) by mx.google.com with ESMTPSA id ul8sm8653575pab.36.2015.03.09.13.06.44 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Mar 2015 13:06:46 -0700 (PDT) Message-ID: <54FDFD52.4070005@gmail.com> Date: Tue, 10 Mar 2015 09:06:42 +1300 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.5.0 MIME-Version: 1.0 To: James Woodyatt , Anima WG References: <20150306163647.31030.58285.idtracker@ietfa.amsl.com> <54FA045C.6090604@gmail.com> <14941.1425856560@sandelman.ca> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] ULA registry [ I-D Action: draft-eckert-anima-stable-connectivity-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: Mon, 09 Mar 2015 20:06:56 -0000 On 10/03/2015 08:28, James Woodyatt wrote: > I agree with Brian, and furthermore I don't agree with the judgment in this > paragraph: > > Centrally assigned ULA addresses (ULA-C) would be an even better >> choice than currently available randomnly self-assigned (ULA-R) >> addresses, because they would permit to audit who owns the address >> prefix if these addresses show up in places where they are not >> expected (for example in above mentioned operational issues). > > > I can see an argument here for a registry, but not one for an assignment > authority. It is not at all clear to me how a central assignment authority > can operate with even less risk of duplication than the already epsilon > level of risk in the random self-assignment of RFC 4193. This statement > appears to take it as axiomatic, and I think it's very debatable. It is. In fact, IMHO the best approach if you want a registry is the one which already has running code (but would need to be operated under IANA authority to be reasonably reliable): https://www.sixxs.net/tools/grh/ula/ In any case this isn't an Anima problem and it is already proving a distraction here ;-) Brian > > On Sun, Mar 8, 2015 at 4:16 PM, Michael Richardson wrote: > >> >> Brian E Carpenter wrote: >> > Just one comment. I'm not sure it's very useful to mention ULA-C, >> since >> > no such thing has been standardised; RFC 4193 doesn't even hint at it >> > beyond saying "Another method, indicated by clearing the L bit, may >> be >> > defined later." I think the discussion will just confuse readers. >> >> I take it differently: I think that this is a reason to document ULA-C. >> >> >> >> _______________________________________________ >> 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 Mar 9 20:24: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 988491AD23D for ; Mon, 9 Mar 2015 20:24:25 -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_44=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 SmKgLxZczy8u for ; Mon, 9 Mar 2015 20:24:24 -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 D207A1AD1DB for ; Mon, 9 Mar 2015 20:24:22 -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 BQB34813; Tue, 10 Mar 2015 03:24:21 +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; Tue, 10 Mar 2015 03:24:20 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.106]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Tue, 10 Mar 2015 11:24:14 +0800 From: Sheng Jiang To: "anima@ietf.org" Thread-Topic: Primary agenda for ANIMA sessions in IETF 92 Thread-Index: AdBa4ay69+UOkualQCi0cRX6EwriGA== Date: Tue, 10 Mar 2015 03:24:13 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923B05BD1B@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] Primary agenda for ANIMA sessions in 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: Tue, 10 Mar 2015 03:24:25 -0000 SGksIGFsbCwNCg0KVGhlIEFOSU1BIFdHIGNoYWlycyBoYXZlIHVwbG9hZGVkIGEgcHJpbWFyeSBh Z2VuZGEgZm9yIEFOSU1BIHNlc3Npb24gaW4gSUVURiA5MiwgYXMgdGhlIGJlbG93IGxpbmsgYW5k IGF0dGFjaG1lbnQuIEFzIHN0YXRlZCBiZWZvcmUsIHRoZSBUdWVzZGF5IDItaG91ciBzZXNzaW9u IGlzIGRlZGljYXRlZCBmb3IgdXJnZW50IFdHIG1pbGVzdG9uZXM7IHRoZSBGcmlkYXkgMS41LWhv dXIgc2Vzc2lvbiBpcyBtYWlubHkgZm9yIG90aGVyIHdvcmsgaXRlbXMgcmVsZXZhbnQgdG8gYXV0 b25vbWljIG5ldHdvcmsgYnV0IG5vdCBpbiB1cmdlbnQgV0cgbWlsZXN0b25lcy4NCg0KaHR0cDov L3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Mi9hZ2VuZGEvYWdlbmRhLTkyLWFuaW1hDQoNClRo ZSBwcmltYXJ5IGFnZW5kYSBpcyBzdGlsbCBhIHN1YmplY3QgdG8gY2hhbmdlLiBTbywgeW91IG1h eSBnaXZlIHlvdXIgc3VnZ2VzdGlvbnMuIFRoZSBjaGFpcnMgbWF5IGFkanVzdCBhY2NvcmRpbmds eSBpZiBwb3NzaWJsZS4gV2UgYXJlIGV4cGVjdGluZyB0byBmaW5hbGl6ZSB0aGUgYWdlbmRhIGF0 IHRoZSBlbmQgb2YgdGhpcyB3ZWVrLg0KDQpCZXN0IHJlZ2FyZHMsDQoNClNoZW5nICsgVG9lcmxl c3MNCg0KQU5JTUEgV0cgQWdlbmRhIGZvciBJRVRGLTkyIChEYWxsYXMpDQogICAgICBBdXRvbm9t aWMgTmV0d29ya2luZyBJbnRlZ3JhdGVkIE1vZGVsIGFuZCBBcHByb2FjaA0KICAgICAgQ2hhaXJz OiBUb2VybGVzcyBFY2tlcnQgJiBTaGVuZyBKaWFuZyANCg0KVGhlIFR1ZXNkYXkgMi1ob3VyIHNl c3Npb24gaXMgZGVkaWNhdGVkIGZvciB1cmdlbnQgV0cgbWlsZXN0b25lczsgDQp0aGUgRnJpZGF5 IDEuNS1ob3VyIHNlc3Npb24gaXMgbWFpbmx5IGZvciBvdGhlciB3b3JrIGl0ZW1zIA0KcmVsZXZh bnQgdG8gYXV0b25vbWljIG5ldHdvcmsgYnV0IG5vdCBpbiB1cmdlbnQgV0cgbWlsZXN0b25lcy4N Cg0KDQpUdWVzZGF5IChNYXJjaCAyNCwgMjAxNSkgMi1ob3VyIHNlc3Npb246DQogICAxNTIwLTE3 MjAgIEFmdGVybm9vbiBTZXNzaW9uIElJLCBPYWsNCiAgIFdHIERhc2ggNSBtaW4NCiAgIERpc2Nv dmVyeSBhbmQgbmVnb3RpYXRpb24gZnVuY3Rpb24gLSA0NSBtaW4NCiAgICAgIEdlbmVyaWMgRGlz Y292ZXJ5IGFuZCBOZWdvdGlhdGlvbiBQcm90b2NvbCAtIDIwIG1pbiANCiAgICAgICAgIChCcmlh biBDYXJwZW50ZXIsIENvbmZpcm1lZCkNCiAgICAgIEF1dG9ub21pYyBEaXN0cmlidXRlZCBOb2Rl IENvbnNlbnN1cyBQcm90b2NvbCAtIDEwIG1pbiANCiAgICAgICAgIChNYXJrdXMgU3RlbmJlcmcs IENvbmZpcm1lZCkgDQogICAgICBDb21iaW5lIGRpc2N1c3Npb24gZm9yIEdETlAmRE5DUCAtIDE1 IG1pbg0KICAgQXV0byBib290c3RyYXBwaW5nIC0gNDUgbWluIA0KICAgICAgQm9vdHN0cmFwcGlu Zy1rZXlpbmZyYSAtIDE1IG1pbiANCiAgICAgICAgIChNYXggUHJpdGlraW4sIENvbmZpcm1lZCkN CiAgICAgIFplcm8gdG91Y2ggLSAxMCBtaW4gDQogICAgICAgICAoQ29uZmlybWF0aW9uIG5lZWRl ZCkNCiAgICAgIFN1cnZleSBvZiBTZWN1cml0eSBCb290c3RyYXBwaW5nIC0gMTAgbWluDQogICAg ICAgICAoRGFucGluZyBIZSwgQ29uZmlybWVkKQ0KICAgICAgQ29tYmluZSBkaXNjdXNzaW9uIC0g MTAgbWluDQogICBBdXRvbm9taWMgQ29udHJvbCBQbGFuZSAmIERpc2N1c3Npb24gLSAyNSBtaW4g DQogICAgICAoTWljaGFlbCBCZWhyaW5nZXIsIENvbmZpcm1lZCkNCg0KDQpGcmlkYXkgKE1hcmNo IDI3LCAyMDE1KSAxLjUtaG91ciBzZXNzaW9uDQogICAxMTUwLTEzMjAgIEFmdGVybm9vbiBTZXNz aW9uIEksIFBhcmlzaWFuDQogICBSZWZlcmVuY2UgbW9kZWwgLSAyMCBtaW4gDQogICAgICAoTWlj aGFlbCBCZWhyaW5nZXIsIENvbmZpcm1lZCkgDQogICBPYnNlcnZhdGlvbnMgb24gYm9vdHN0cmFw cGluZyBhbmQgc3luY2hyb25pemF0aW9uIC0gMTUgbWluIA0KICAgICAgKFJlbmUgU3RydWlrLCBD b25maXJtKQ0KICAgQ29vcmRpbmF0aW5nIG11bHRpcGxlIChjb25mbGljdGluZykgYXV0b25vbWlj IGZ1bmN0aW9ucyAtIDE1IG1pbiANCiAgICAgIChMYXVyZW50IENpYXZhZ2xpYSwgQ29uZmlybWVk KQ0KICAgU2VsZi1NYW5hZ2VkIE5ldHdvcmtzIHdpdGggRmF1bHQgTWFuYWdlbWVudCBIaWVyYXJj aHkgLSAxNSBtaW4gDQogICAgICAoVG95IE1laG1ldCwgQ29uZmlybWVkKSANCiAgIFByZWRpY3Rp dmUgcmlzayBhd2FyZW5lc3MgZm9yIHByb2FjdGl2ZSBtYW5hZ2VtZW50IC0gMTUgbWluIA0KICAg ICAgKExhdXJlbnQgQ2lhdmFnbGlhLCBDb25maXJtZWQpDQo= From nobody Mon Mar 9 20:40: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 55FA91AD356 for ; Mon, 9 Mar 2015 20:40: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 ujnyPY5lbrfy for ; Mon, 9 Mar 2015 20:40:54 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::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 9BA661AD34D for ; Mon, 9 Mar 2015 20:40:54 -0700 (PDT) Received: by pdbfp1 with SMTP id fp1so62633638pdb.7 for ; Mon, 09 Mar 2015 20:40: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=szf2GaE7C+15KT9wPIJ0rYpPSfTvfvjeaygAoXgRk64=; b=azR4W1V3cG3uYbL9xIb4EXxP9Ccx+ZJz9w9/Oe7r+imIus5TZjzWpX+Fw/a27uRo2h i4vLMLTr3h4gvrkZS5cuU6D1T2Rt1PYsKpbMDqk2Z/m9a76v0TGMM2/bYSMJqPX4K22f E4C4kLZG7Q8VH6inn5iT/hyqs0veyzVMXmR87vUMfkxjm7SYlzXFKMdtDq/a0y4wsKOP WxOc8O/5B1JyOij8W/r4PTLd1Do/eZAby/iixz3DXLawh1Gt04nMC0rOYFwR052DMhK3 SO+8nwW+uZs9NWWfSo0A8FDTmCJot7HYXHO/Ss7I0kyLYjbAnuGKXspwCqvW6usF4J3/ LMhQ== X-Received: by 10.66.66.230 with SMTP id i6mr60295849pat.108.1425958853286; Mon, 09 Mar 2015 20:40:53 -0700 (PDT) Received: from [10.1.9.163] ([103.23.18.15]) by mx.google.com with ESMTPSA id ey1sm17547569pdb.30.2015.03.09.20.40.49 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Mar 2015 20:40:52 -0700 (PDT) Message-ID: <54FE67C3.9010804@gmail.com> Date: Tue, 10 Mar 2015 16:40:51 +1300 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.5.0 MIME-Version: 1.0 To: John Strassner References: <5D36713D8A4E7348A7E10DF7437A4B923B059AD6@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923B059AD6@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "Liubing \(Leo\)" , Anima WG , strazpdj@gmail.com Subject: Re: [Anima] Some comments for draft-carpenter-anima-gdn-protocol 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, 10 Mar 2015 03:40:56 -0000 Hi John and everybody, Replying to some comments received privately, on the list with permission: On 09/03/2015 22:55, Sheng Jiang wrote: > Hi, authors of draft-carpenter-anima-gdn-protocol > > The below are some comments from my colleague, Dr. John Strassner. Although I personally think your protocol designs have the ability to meet his requirements for knowledge exchanging among autonomic nodes, it is better you could discuss directly and maybe include some modification/clarification in the future version. I also encourage you to discuss this in ANIMA mail list openly. > > Best regards, > > Sheng > >> -----Original Message----- >> From: John Strassner >> Sent: Friday, March 06, 2015 6:43 AM >> To: Sheng Jiang; John Strassner >> >> Dear Sheng, >> >> I read the charter and am starting on the drafts. >> >>>> autonomics require the ability to share and >>>> exchange knowledge in an interoperable fashion. I fail to see how this is >>>> even discussed in ANIMA. >>> >>> BTW, the ability to share and exchange knowledge in an interoperable fashion >>> looks like GNDP (Generic Discovery and Negotiation Protocol) in ANIMA. This >>> protocol is designed to support information discovery and bi-direction >>> negotiation. >> >> It appears that GDNP covers some, but not all, of what I am talking about. Indeed, it isn't claiming to cover everything. The idea is that draft-behringer-anima-reference-model will evolve to show how things fit together, which will help us to identify holes. >> However, the following statement from the GDNP draft is misleading, if not >> just plain wrong: >> >> "In order to fulfil autonomy, devices that embody autonomic service >> agents need to be able to discover each other, to synchronize state >> with each other, and to negotiate parameters and resources directly >> with each other." >> >> First, autonomic networks are not necessarily autonomous. Autonomy, in its >> most generic form, is the ability to have the power for an entity to govern >> itself. If every network element governs itself without regard to other, higher >> level principles, you don't even have a network. :-) Sure. That is the role for what we call "intent" which is defined in draft-irtf-nmrg-autonomic-network-definitions but is not yet in Anima scope. >> Second, the three concepts mentioned in the above excerpt (discoverability, >> synchronization of state, and parameter negotiation) are necessary but >> clearly not sufficient to have autonomic operation. I was talking about the >> ability to exchange knowledge (e.g., all or part of an information model) >> between entities. It doesn't appear that this is covered in ANIMA yet, though I >> haven't read all of the materials. My personal view is that this is going to be resolved topic by topic. In GDNP-speak that means that it will be resolved by individual Objective definitions, and GDNP will just act as a neutral carrier. (You can quite fairly argue that this means we are ducking the problem for now.) Another way to say this is that each type of autonomous service agent will solve this problem for its own target parameters. Now, again IMHO, this is why we state in GDNP that the format of the value of an objective "...might be inherited from an existing management or configuration protocol, the objective option acting as a carrier for that format. The data structure might be defined in a formal language, but that is a matter for the specifications of individual objectives. There are many candidates, according to the context, such as ABNF, RBNF, XML Schema, possibly YANG, etc. The GDNP protocol itself is agnostic on these questions." My expectation is that some objectives will need a formal information model and that others won't, and that there's no reason we couldn't inherit existing IMs when they are relevant. But that whole question is also out of charter scope for now. As you know better than most people, John, defining an IM can become a very laborious business and for now we want to get started on simple cases that don't need it. >> If you cannot exchange knowledge, you will >> never be autonomic in the computer science sense. You will find very similar words in draft-irtf-nmrg-an-gap-analysis. Regards Brian >> regards, >> John >> >> Dr. John Strassner, Ph.D. >> CTO, Software Laboratory, CRD >> >> >> Futurewei Technologies >> US R&D Center >> 2330 Central Expressway >> Building A, office A2-2143 >> Santa Clara, California 95050 >> Office: +1.408.330.4923 >> Email: john.sc.strassner@huawei.com >> >> >> Best regards, >> >> Sheng From nobody Wed Mar 11 03:42: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 0B39F1ACD3C for ; Wed, 11 Mar 2015 03:42: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 769WlrP52d4m for ; Wed, 11 Mar 2015 03:42:41 -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 B78751ACDCD for ; Wed, 11 Mar 2015 03:42:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7353; q=dns/txt; s=iport; t=1426070563; x=1427280163; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=LBbq+RSuqyv3E4EmwezhGHa3JiIIVIpxammH739k7GY=; b=RFD1aY6bICjbPrulLHqLT5yDarqmEeiiDbugxNcfuMnEuL+SDnF7Vnml CHXHOkWY/KKrgCIbJPXvukkvOQ7hvj9fsW8jpWqNG4a0cj+hryl8eb41e D2jUkrqTzysxSs/K22MXh759TcYsIR/ZDwEtt41dteCcOcHVsWAA9V9T1 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DVBwAYGwBV/5RdJa1SBwODA1JaBMEKgi0KhXACgS9NAQEBAQEBfIQPAQEBAwEBAQE3LQcLDAICAgEIEQQBAQEKFAkHFgsGCxQJCAIEAQ0FCIgTAwkIDcF7DYUoAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwQEihR/gkSBSAYKAgEBHSEQBwYLgwaBFgWQG4YGgg2CZIV8hk2CUYNDI4NubwGBAyQcfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,381,1422921600"; d="scan'208";a="403030950" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-2.cisco.com with ESMTP; 11 Mar 2015 10:42:42 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t2BAgekw008260 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Mar 2015 10:42:40 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.142]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Wed, 11 Mar 2015 05:42:40 -0500 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , John Strassner Thread-Topic: [Anima] Some comments for draft-carpenter-anima-gdn-protocol Thread-Index: AQHQWuQNTPthNQ4MbUG6geddsooIWp0W7nng Date: Wed, 11 Mar 2015 10:42:40 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22EF05CD@xmb-rcd-x14.cisco.com> References: <5D36713D8A4E7348A7E10DF7437A4B923B059AD6@nkgeml512-mbx.china.huawei.com> <54FE67C3.9010804@gmail.com> In-Reply-To: <54FE67C3.9010804@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.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Anima WG , "Liubing \(Leo\)" , "strazpdj@gmail.com" Subject: Re: [Anima] Some comments for draft-carpenter-anima-gdn-protocol 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, 11 Mar 2015 10:42:47 -0000 John,=20 Adding to Brian/Sheng my view, there are two important points to note:=20 1) What you see now is just the start. In this first phase we're not actual= ly standardising any autonomic service agents (as we call them), but we're = preparing an infrastructure for such agents. Meaning, such agents can count= on all the "mechanics" to talk to other agents: Addressing, routing, secur= ity, simple discovery, negotiation, etc. We call this the autonomic network= ing infrastructure, and our goal is to make this infrastructure "self-manag= ing" itself, specifically, it should self-configure.=20 This infrastructure is not complete, as you correctly point out. But all of= the functions you mention (e.g., knowledge exchange) first of all require = a solid communications infrastructure.=20 In the WG charter you see the elements of the infrastructure, and a couple = of use cases for autonomic service agents. In this first phase the intentio= n is to validate the autonomic networking infrastructure with those use cas= es. See also the UCAN BoF notes, where more use cases were discussed. Again= , we're looking at simple use cases to start with, and work bottom-up.=20 2) We are not trying to define fully autonomic nodes, but autonomic functio= ns. In other words, we expect nodes to be partially managed in the traditio= nal way, and some functions to be autonomic. In the future there may be cas= es of fully autonomic nodes.=20 As we take on new use cases, we define their requirements, and address the = delta in the autonomic networking infrastructure, bottom up. With the refer= ence model we need to make sure that we're not going down a track that will= make future use cases impossible or hard to support. This is of course the= main challenge. Your input would be very valuable in this process.=20 What are your thoughts?=20 Michael > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E > Carpenter > Sent: 10 March 2015 04:41 > To: John Strassner > Cc: Liubing (Leo); Anima WG; strazpdj@gmail.com > Subject: Re: [Anima] Some comments for draft-carpenter-anima-gdn- > protocol >=20 > Hi John and everybody, >=20 > Replying to some comments received privately, on the list with permission= : > On 09/03/2015 22:55, Sheng Jiang wrote: > > Hi, authors of draft-carpenter-anima-gdn-protocol > > > > The below are some comments from my colleague, Dr. John Strassner. > Although I personally think your protocol designs have the ability to mee= t > his requirements for knowledge exchanging among autonomic nodes, it is > better you could discuss directly and maybe include some > modification/clarification in the future version. I also encourage you to > discuss this in ANIMA mail list openly. > > > > Best regards, > > > > Sheng > > > >> -----Original Message----- > >> From: John Strassner > >> Sent: Friday, March 06, 2015 6:43 AM > >> To: Sheng Jiang; John Strassner > >> > >> Dear Sheng, > >> > >> I read the charter and am starting on the drafts. > >> > >>>> autonomics require the ability to share and exchange knowledge in > >>>> an interoperable fashion. I fail to see how this is even discussed > >>>> in ANIMA. > >>> > >>> BTW, the ability to share and exchange knowledge in an interoperable > >>> fashion looks like GNDP (Generic Discovery and Negotiation Protocol) > >>> in ANIMA. This protocol is designed to support information discovery > >>> and bi-direction negotiation. > >> > >> It appears that GDNP covers some, but not all, of what I am talking ab= out. >=20 > Indeed, it isn't claiming to cover everything. The idea is that draft- > behringer-anima-reference-model will evolve to show how things fit > together, which will help us to identify holes. >=20 > >> However, the following statement from the GDNP draft is misleading, > >> if not just plain wrong: > >> > >> "In order to fulfil autonomy, devices that embody autonomic service > >> agents need to be able to discover each other, to synchronize state > >> with each other, and to negotiate parameters and resources directly > >> with each other." > >> > >> First, autonomic networks are not necessarily autonomous. Autonomy, > >> in its most generic form, is the ability to have the power for an > >> entity to govern itself. If every network element governs itself > >> without regard to other, higher level principles, you don't even have > >> a network. :-) >=20 > Sure. That is the role for what we call "intent" which is defined in draf= t-irtf- > nmrg-autonomic-network-definitions but is not yet in Anima scope. >=20 > >> Second, the three concepts mentioned in the above excerpt > >> (discoverability, synchronization of state, and parameter > >> negotiation) are necessary but clearly not sufficient to have > >> autonomic operation. I was talking about the ability to exchange > >> knowledge (e.g., all or part of an information model) between > >> entities. It doesn't appear that this is covered in ANIMA yet, though = I > haven't read all of the materials. >=20 > My personal view is that this is going to be resolved topic by topic. > In GDNP-speak that means that it will be resolved by individual Objective > definitions, and GDNP will just act as a neutral carrier. (You can quite = fairly > argue that this means we are ducking the problem for now.) Another way to > say this is that each type of autonomous service agent will solve this > problem for its own target parameters. >=20 > Now, again IMHO, this is why we state in GDNP that the format of the valu= e > of an objective "...might be inherited from an existing management or > configuration protocol, the objective option acting as a carrier for that > format. The data structure might be defined in a formal language, but th= at > is a matter for the specifications of individual objectives. There are m= any > candidates, according to the context, such as ABNF, RBNF, XML Schema, > possibly YANG, etc. The GDNP protocol itself is agnostic on these > questions." >=20 > My expectation is that some objectives will need a formal information > model and that others won't, and that there's no reason we couldn't inher= it > existing IMs when they are relevant. But that whole question is also out = of > charter scope for now. As you know better than most people, John, definin= g > an IM can become a very laborious business and for now we want to get > started on simple cases that don't need it. >=20 > >> If you cannot exchange knowledge, you will never be autonomic in the > >> computer science sense. >=20 > You will find very similar words in draft-irtf-nmrg-an-gap-analysis. >=20 > >=20 > Regards > Brian >=20 > >> regards, > >> John > >> > >> Dr. John Strassner, Ph.D. > >> CTO, Software Laboratory, CRD > >> > >> > >> Futurewei Technologies > >> US R&D Center > >> 2330 Central Expressway > >> Building A, office A2-2143 > >> Santa Clara, California 95050 > >> Office: +1.408.330.4923 > >> Email: john.sc.strassner@huawei.com > >> > >> > >> Best regards, > >> > >> Sheng >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Wed Mar 11 07:00:10 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 9F5831ACD0D for ; Wed, 11 Mar 2015 07:00:08 -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, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 MM38QUL5Zw2t for ; Wed, 11 Mar 2015 07:00:05 -0700 (PDT) Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.50]) (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 C22941ACD13 for ; Wed, 11 Mar 2015 07:00:03 -0700 (PDT) Received: by qgfh3 with SMTP id h3so10002307qgf.13 for ; Wed, 11 Mar 2015 07:00:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=zxn3AJkMgZbJvlBPhkzrZVrpb0HfKoATGRZLqFjKgKs=; b=N7vq6AhV0qfnPC7T6s1UtO+kWqzFIi2fPMArJnmymajRD72k9DTc+lsfDPwkMtyjvz E6wi3OiGiAWvRbkDD8oYoHd9ZBdv5ZtVAEvLHWE5/3uoum1H/3g4FHVOOopGSQ7jer9G q+qxXOwKhFXCbFmftAaiUwN8YLg1nvFtp1y48PwR4Ox39arBt6/bOlCofj1rvCkNzxBy lC8n9CvAguP1+CNEdHy9EGFxE9zG3T2A6fvVs+hHYT7LIfrl2vZWE/Tl5tSdR6/xZX9E qMvsGcdhpdeBnUg6mMWeLW8AZqm+z5oUi+FFfY4zBftIK3Ih8TK0oHjWEqQcsu5P+m/t juzw== X-Gm-Message-State: ALoCoQmNfwjIhDZ3y6NUXwrlumBHsDUcLO4R4laJq+lPzYXPpdMyo2+q8M1IbU9z4GHJGBKFU2/w X-Received: by 10.55.31.71 with SMTP id f68mr70305451qkf.7.1426082402940; Wed, 11 Mar 2015 07:00:02 -0700 (PDT) Received: from [192.168.1.72] ([179.223.97.99]) by mx.google.com with ESMTPSA id 131sm2573372qhh.48.2015.03.11.07.00.00 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Mar 2015 07:00:01 -0700 (PDT) Message-ID: <55004A59.1070607@braga.eti.br> Date: Wed, 11 Mar 2015 10:59:53 -0300 From: Juliao Braga User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: anima@ietf.org References: <5D36713D8A4E7348A7E10DF7437A4B923B05BD1B@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923B05BD1B@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Anima] Primary agenda for ANIMA sessions in 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, 11 Mar 2015 14:00:08 -0000 We will have facilities for remote participation? Tks, Julião On 10/03/2015 00:24, Sheng Jiang wrote: > Hi, all, > > The ANIMA WG chairs have uploaded a primary agenda for ANIMA session in IETF 92, as the below link and attachment. As stated before, the Tuesday 2-hour session is dedicated for urgent WG milestones; the Friday 1.5-hour session is mainly for other work items relevant to autonomic network but not in urgent WG milestones. > > http://www.ietf.org/proceedings/92/agenda/agenda-92-anima > > The primary agenda is still a subject to change. So, you may give your suggestions. The chairs may adjust accordingly if possible. We are expecting to finalize the agenda at the end of this week. > > Best regards, > > Sheng + Toerless > > ANIMA WG Agenda for IETF-92 (Dallas) > Autonomic Networking Integrated Model and Approach > Chairs: Toerless Eckert & Sheng Jiang > > The Tuesday 2-hour session is dedicated for urgent WG milestones; > the Friday 1.5-hour session is mainly for other work items > relevant to autonomic network but not in urgent WG milestones. > > > Tuesday (March 24, 2015) 2-hour session: > 1520-1720 Afternoon Session II, Oak > WG Dash 5 min > Discovery and negotiation function - 45 min > Generic Discovery and Negotiation Protocol - 20 min > (Brian Carpenter, Confirmed) > Autonomic Distributed Node Consensus Protocol - 10 min > (Markus Stenberg, Confirmed) > Combine discussion for GDNP&DNCP - 15 min > Auto bootstrapping - 45 min > Bootstrapping-keyinfra - 15 min > (Max Pritikin, Confirmed) > Zero touch - 10 min > (Confirmation needed) > Survey of Security Bootstrapping - 10 min > (Danping He, Confirmed) > Combine discussion - 10 min > Autonomic Control Plane & Discussion - 25 min > (Michael Behringer, Confirmed) > > > Friday (March 27, 2015) 1.5-hour session > 1150-1320 Afternoon Session I, Parisian > Reference model - 20 min > (Michael Behringer, Confirmed) > Observations on bootstrapping and synchronization - 15 min > (Rene Struik, Confirm) > Coordinating multiple (conflicting) autonomic functions - 15 min > (Laurent Ciavaglia, Confirmed) > Self-Managed Networks with Fault Management Hierarchy - 15 min > (Toy Mehmet, Confirmed) > Predictive risk awareness for proactive management - 15 min > (Laurent Ciavaglia, Confirmed) > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Wed Mar 11 17:34: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 C41411A88B0 for ; Wed, 11 Mar 2015 17:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 BZJk_sYzww1f for ; Wed, 11 Mar 2015 17:34:23 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::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 69D311A884F for ; Wed, 11 Mar 2015 17:34:23 -0700 (PDT) Received: by wiwl15 with SMTP id l15so43476712wiw.4 for ; Wed, 11 Mar 2015 17:34:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JwKDbVO93x8xGaVuRwC30sZxgub9u2vnwuVm8dZBMLc=; b=GUDKwlOwO0tHNEAQuoEiSa+zZ9SX6pcJq0zD7LRlAfgb6+256WhpFLh/SI6fsP9I1x EdhwJ7PbToIwhFz/wOrl35dndD2Yh56UP4tvqMbxdeGK+0o56CTE1+sCw5v4wXNmg+/e hNnDnt6PvvomUgCuVqEkNYCWQjRWifSf00532R4En58nFRoZawkfb0g5AZGe54/3VbSa JJ/5Mlzq1NPANkkW2jgdTLFvuTdKG7vgY59k0+/ts2sbvdyl3I7D7JzM666VNC623b3c QYxQ4fxYw6DDZggLgVldr+kbCb5PNXEy8BJn2v22vvcE2xYgSN2fT+qNhoG5T6HrxJVC 8lsw== MIME-Version: 1.0 X-Received: by 10.194.87.100 with SMTP id w4mr79892077wjz.65.1426120462056; Wed, 11 Mar 2015 17:34:22 -0700 (PDT) Received: by 10.27.85.139 with HTTP; Wed, 11 Mar 2015 17:34:21 -0700 (PDT) In-Reply-To: <54FE67C3.9010804@gmail.com> References: <5D36713D8A4E7348A7E10DF7437A4B923B059AD6@nkgeml512-mbx.china.huawei.com> <54FE67C3.9010804@gmail.com> Date: Wed, 11 Mar 2015 17:34:21 -0700 Message-ID: From: John Strassner To: Brian E Carpenter , John Strassner Content-Type: multipart/alternative; boundary=047d7bf10a168c452d05110c8ba0 Archived-At: Cc: John Strassner , "Liubing \(Leo\)" , Anima WG Subject: Re: [Anima] Some comments for draft-carpenter-anima-gdn-protocol 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, 12 Mar 2015 00:34:28 -0000 --047d7bf10a168c452d05110c8ba0 Content-Type: text/plain; charset=UTF-8 Hi Brian, thanks for your quick reply. I'm out of the country, so sorry for the delay. Please see inline, look for ... ...elided... >>>> autonomics require the ability to share and >>>> exchange knowledge in an interoperable fashion. I fail to see how this is >>>> even discussed in ANIMA. This is probably my error, sorry. I've done a lot of research in autonomics, and even built a couple of things. :-) What I meant in the snipped above is the ability to pass enough information to other participating nodes so that the nodes can understand the current context, make context-relevant decisions, and then take appropriate actions. For example, if I was using ontologies to specify semantics, I would likely use something like CL (Common Logic). As another example, autonomic systems **learn** from the environment. Hence, their repositories grow, information is validated and invalidated, etc. Hopefully that makes more sense... >>> BTW, the ability to share and exchange knowledge in an interoperable fashion >>> looks like GNDP (Generic Discovery and Negotiation Protocol) in ANIMA. This >>> protocol is designed to support information discovery and bi-direction >>> negotiation. >> >> It appears that GDNP covers some, but not all, of what I am talking about. Indeed, it isn't claiming to cover everything. The idea is that draft-behringer-anima-reference-model will evolve to show how things fit together, which will help us to identify holes. I promise to read this next. :-) My quick comment is that in systems I have built, it is important to pass parts of the model among cooperating autonomic nodes. I don't detect this ability in GDNP. Another important requirement was for "more powerful" processing nodes to help "less powerful" processing nodes. This was typically implemented by advertising capabilities as well as requests for help. I think that GDNP could evolve to serve these and similar needs. >> However, the following statement from the GDNP draft is misleading, if not >> just plain wrong: >> >> "In order to fulfil autonomy, devices that embody autonomic service >> agents need to be able to discover each other, to synchronize state >> with each other, and to negotiate parameters and resources directly >> with each other." >> >> First, autonomic networks are not necessarily autonomous. Autonomy, in its >> most generic form, is the ability to have the power for an entity to govern >> itself. If every network element governs itself without regard to other, higher >> level principles, you don't even have a network. :-) Sure. That is the role for what we call "intent" which is defined in draft-irtf-nmrg-autonomic-network-definitions but is not yet in Anima scope. Another item for my reading list. Looking at page 4, it **seems** that you are defining an autonomic system as a system driven by policy. I like that :-) However, this is a difficult goal. I think that it is unlikely that a **single** level of intent can ever be built. Rather, much like the policy continuum that I defined, I think that there is a continuum of intents, where each intent is expressed using a policy that may use different concepts and terminology. We do that today, when a business person decrees that this Customer gets Gold Service, and a network admin translates that to CLI. Thoughts? >> Second, the three concepts mentioned in the above excerpt (discoverability, >> synchronization of state, and parameter negotiation) are necessary but >> clearly not sufficient to have autonomic operation. I was talking about the >> ability to exchange knowledge (e.g., all or part of an information model) >> between entities. It doesn't appear that this is covered in ANIMA yet, though I >> haven't read all of the materials. My personal view is that this is going to be resolved topic by topic. In GDNP-speak that means that it will be resolved by individual Objective definitions, and GDNP will just act as a neutral carrier. (You can quite fairly argue that this means we are ducking the problem for now.) Another way to say this is that each type of autonomous service agent will solve this problem for its own target parameters. Actually, this isn't a bad approach. My main issue is that knowledge exchange is far broader than discovery and parameter-specific data. Now, again IMHO, this is why we state in GDNP that the format of the value of an objective "...might be inherited from an existing management or configuration protocol, the objective option acting as a carrier for that format. The data structure might be defined in a formal language, but that is a matter for the specifications of individual objectives. There are many candidates, according to the context, such as ABNF, RBNF, XML Schema, possibly YANG, etc. The GDNP protocol itself is agnostic on these questions." My expectation is that some objectives will need a formal information model and that others won't, and that there's no reason we couldn't inherit existing IMs when they are relevant. But that whole question is also out of charter scope for now. As you know better than most people, John, defining an IM can become a very laborious business and for now we want to get started on simple cases that don't need it. Yes, I seem to have continually skewered myself on information models. :-) While I very much agree with your approach, I would note that you should either say IM **fragments** or limit this to one IM. >> If you cannot exchange knowledge, you will >> never be autonomic in the computer science sense. You will find very similar words in draft-irtf-nmrg-an-gap-analysis. Yikers, another draft. Is there a list of all drafts that may be eventually considered? < snip> Regards Brian On Mon, Mar 9, 2015 at 8:40 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Hi John and everybody, > > Replying to some comments received privately, on the list with permission: > On 09/03/2015 22:55, Sheng Jiang wrote: > > Hi, authors of draft-carpenter-anima-gdn-protocol > > > > The below are some comments from my colleague, Dr. John Strassner. > Although I personally think your protocol designs have the ability to meet > his requirements for knowledge exchanging among autonomic nodes, it is > better you could discuss directly and maybe include some > modification/clarification in the future version. I also encourage you to > discuss this in ANIMA mail list openly. > > > > Best regards, > > > > Sheng > > > >> -----Original Message----- > >> From: John Strassner > >> Sent: Friday, March 06, 2015 6:43 AM > >> To: Sheng Jiang; John Strassner > >> > >> Dear Sheng, > >> > >> I read the charter and am starting on the drafts. > >> > >>>> autonomics require the ability to share and > >>>> exchange knowledge in an interoperable fashion. I fail to see how > this is > >>>> even discussed in ANIMA. > >>> > >>> BTW, the ability to share and exchange knowledge in an interoperable > fashion > >>> looks like GNDP (Generic Discovery and Negotiation Protocol) in ANIMA. > This > >>> protocol is designed to support information discovery and bi-direction > >>> negotiation. > >> > >> It appears that GDNP covers some, but not all, of what I am talking > about. > > Indeed, it isn't claiming to cover everything. The idea is that > draft-behringer-anima-reference-model will evolve to show how things > fit together, which will help us to identify holes. > > >> However, the following statement from the GDNP draft is misleading, if > not > >> just plain wrong: > >> > >> "In order to fulfil autonomy, devices that embody autonomic service > >> agents need to be able to discover each other, to synchronize state > >> with each other, and to negotiate parameters and resources directly > >> with each other." > >> > >> First, autonomic networks are not necessarily autonomous. Autonomy, in > its > >> most generic form, is the ability to have the power for an entity to > govern > >> itself. If every network element governs itself without regard to > other, higher > >> level principles, you don't even have a network. :-) > > Sure. That is the role for what we call "intent" which is defined > in draft-irtf-nmrg-autonomic-network-definitions but is not yet > in Anima scope. > > >> Second, the three concepts mentioned in the above excerpt > (discoverability, > >> synchronization of state, and parameter negotiation) are necessary but > >> clearly not sufficient to have autonomic operation. I was talking about > the > >> ability to exchange knowledge (e.g., all or part of an information > model) > >> between entities. It doesn't appear that this is covered in ANIMA yet, > though I > >> haven't read all of the materials. > > My personal view is that this is going to be resolved topic by topic. > In GDNP-speak that means that it will be resolved by individual Objective > definitions, and GDNP will just act as a neutral carrier. (You can quite > fairly argue that this means we are ducking the problem for now.) > Another way to say this is that each type of autonomous service agent will > solve this problem for its own target parameters. > > Now, again IMHO, this is why we state in GDNP that the format of the > value of an objective "...might be inherited from an > existing management or configuration protocol, the objective option > acting as a carrier for that format. The data structure might be > defined in a formal language, but that is a matter for the > specifications of individual objectives. There are many candidates, > according to the context, such as ABNF, RBNF, XML Schema, possibly > YANG, etc. The GDNP protocol itself is agnostic on these questions." > > My expectation is that some objectives will need a formal information > model and that others won't, and that there's no reason we couldn't > inherit existing IMs when they are relevant. But that whole question > is also out of charter scope for now. As you know better than most > people, John, defining an IM can become a very laborious business and > for now we want to get started on simple cases that don't need it. > > >> If you cannot exchange knowledge, you will > >> never be autonomic in the computer science sense. > > You will find very similar words in draft-irtf-nmrg-an-gap-analysis. > > > > Regards > Brian > > >> regards, > >> John > >> > >> Dr. John Strassner, Ph.D. > >> CTO, Software Laboratory, CRD > >> > >> > >> Futurewei Technologies > >> US R&D Center > >> 2330 Central Expressway > >> Building A, office A2-2143 > >> Santa Clara, California 95050 > >> Office: +1.408.330.4923 > >> Email: john.sc.strassner@huawei.com > >> > >> > >> Best regards, > >> > >> Sheng > -- regards, John --047d7bf10a168c452d05110c8ba0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Brian,

thanks for your qu= ick reply. I'm out of the country, so sorry for the delay. Please see i= nline, look for <jcs>..</jcs>.

...elid= ed...

>>>> autonomics require the ability to shar= e and
>>>> exchange knowledge in an interoperable fashion. I= fail to see how this is
>>>> even discussed in ANIMA.
=

<jcs>
This is probably my error, sorry.=
I've done a lot of research in autonomics, and even built a = couple of things. :-)
What I meant in the snipped above is the ab= ility to pass enough information to other participating nodes so that the n= odes can understand the current context, make context-relevant decisions, a= nd then take appropriate actions.
For example, if I was using ont= ologies to specify semantics, I would likely use something like CL (Common = Logic).
As another example, autonomic systems **learn** from the = environment. Hence, their repositories grow, information is validated and i= nvalidated, etc.
Hopefully that makes more sense...
<= ;/jcs>

>>> BTW, the ability to share and exchange= knowledge in an interoperable fashion
>>> looks like GNDP (Gen= eric Discovery and Negotiation Protocol) in ANIMA. This
>>> pro= tocol is designed to support information discovery and bi-direction
>= >> negotiation.
>>
>> It appears that GDNP covers = some, but not all, of what I am talking about.

Indeed, it isn't= claiming to cover everything. The idea is that
draft-behringer-anima-r= eference-model will evolve to show how things
fit together, which will = help us to identify holes.

<jcs>
I= promise to read this next. :-)
My quick comment is that in syste= ms I have built, it is important to pass parts of the model among cooperati= ng autonomic nodes. I don't detect this ability in GDNP.

=
Another important requirement was for "more powerful" = processing nodes to help "less powerful" processing nodes. This w= as typically implemented by advertising capabilities as well as requests fo= r help. I think that GDNP could evolve to serve these and similar needs.</jcs>

>> However, the following statement from = the GDNP draft is misleading, if not
>> just plain wrong:
>&= gt;
>> "In order to fulfil autonomy, devices that embody aut= onomic service
>> agents need to be able to discover each other, t= o synchronize state
>> with each other, and to negotiate parameter= s and resources directly
>> with each other."
>> >> First, autonomic networks are not necessarily autonomous. Autonom= y, in its
>> most generic form, is the ability to have the power f= or an entity to govern
>> itself. If every network element governs= itself without regard to other, higher
>> level principles, you d= on't even have a network. :-)

Sure. That is the role for what w= e call "intent" which is defined
in draft-irtf-nmrg-autonomic= -network-definitions but is not yet
in Anima scope.

<jcs>
Another item for my reading list.
Loo= king at page 4, it **seems** that you are defining an autonomic system as a= system driven by policy. I like that :-)
However, this is a diff= icult goal. I think that it is unlikely that a **single** level of intent c= an ever be built. Rather, much like the policy continuum that I defined, I = think that there is a continuum of intents, where each intent is expressed = using a policy that may use different concepts and terminology. We do that = today, when a business person decrees that this Customer gets Gold Service,= and a network admin translates that to CLI.
Thoughts?
</jc= s>

>> Second, the three concepts mentioned in the above exc= erpt (discoverability,
>> synchronization of state, and parameter = negotiation) are necessary but
>> clearly not sufficient to have a= utonomic operation. I was talking about the
>> ability to exchange= knowledge (e.g., all or part of an information model)
>> between = entities. It doesn't appear that this is covered in ANIMA yet, though I=
>> haven't read all of the materials.

My personal vie= w is that this is going to be resolved topic by topic.
In GDNP-speak th= at means that it will be resolved by individual Objective
definitions, = and GDNP will just act as a neutral carrier. (You can quite
fairly argu= e that this means we are ducking the problem for now.)
Another way to s= ay this is that each type of autonomous service agent will
solve this p= roblem for its own target parameters.

<jcs><= /div>
Actually, this isn't a bad=C2=A0approach. My main issue is th= at knowledge exchange is far broader than discovery and parameter-specific = data.
</jcs>

=C2=A0Now, again IMHO, this is why we s= tate in GDNP that the format of the
value of an objective "...migh= t be inherited from an
existing management or configuration protocol, t= he objective option
acting as a carrier for that format.=C2=A0 The data= structure might be
defined in a formal language, but that is a matter = for the
specifications of individual objectives.=C2=A0 There are many c= andidates,
according to the context, such as ABNF, RBNF, XML Schema, po= ssibly
YANG, etc.=C2=A0 The GDNP protocol itself is agnostic on these q= uestions."

My expectation is that some objectives will need a = formal information
model and that others won't, and that there'= s no reason we couldn't
inherit existing IMs when they are relevant= . But that whole question
is also out of charter scope for now. As you = know better than most
people, John, defining an IM can become a very la= borious business and
for now we want to get started on simple cases tha= t don't need it.

<jcs>
Yes, I = seem to have continually skewered myself on information models. :-)
While I very much agree with your approach, I would note that you should= either say IM **fragments** or limit this to one IM.
</jcs>= ;

>> If you cannot exchange knowledge, you will
>> ne= ver be autonomic in the computer science sense.

You will find very = similar words in draft-irtf-nmrg-an-gap-analysis.
<jcs>
Yikers, another draft. Is there a list of all drafts that may be eve= ntually considered?
</jcs>

< snip>

Reg= ards
=C2=A0 =C2=A0 Brian

On Mon, Mar 9, 2015 at 8:40 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
Hi John and everybody,

Replying to some comments received privately, on the list with permission:<= br> On 09/03/2015 22:55, Sheng Jiang wrote:
> Hi, authors of draft-carpenter-anima-gdn-protocol
>
> The below are some comments from my colleague, Dr. John Strassner. Alt= hough I personally think your protocol designs have the ability to meet his= requirements for knowledge exchanging among autonomic nodes, it is better = you could discuss directly and maybe include some modification/clarificatio= n in the future version. I also encourage you to discuss this in ANIMA mail= list openly.
>
> Best regards,
>
> Sheng
>
>> -----Original Message-----
>> From: John Strassner
>> Sent: Friday, March 06, 2015 6:43 AM
>> To: Sheng Jiang; John Strassner
>>
>> Dear Sheng,
>>
>> I read the charter and am starting on the drafts.
>>
>>>> autonomics require the ability to share and
>>>> exchange knowledge in an interoperable fashion. I fail to = see how this is
>>>> even discussed in ANIMA.
>>>
>>> BTW, the ability to share and exchange knowledge in an interop= erable fashion
>>> looks like GNDP (Generic Discovery and Negotiation Protocol) i= n ANIMA. This
>>> protocol is designed to support information discovery and bi-d= irection
>>> negotiation.
>>
>> It appears that GDNP covers some, but not all, of what I am talkin= g about.

Indeed, it isn't claiming to cover everything. The idea is that
draft-behringer-anima-reference-model will evolve to show how things
fit together, which will help us to identify holes.

>> However, the following statement from the GDNP draft is misleading= , if not
>> just plain wrong:
>>
>> "In order to fulfil autonomy, devices that embody autonomic s= ervice
>> agents need to be able to discover each other, to synchronize stat= e
>> with each other, and to negotiate parameters and resources directl= y
>> with each other."
>>
>> First, autonomic networks are not necessarily autonomous. Autonomy= , in its
>> most generic form, is the ability to have the power for an entity = to govern
>> itself. If every network element governs itself without regard to = other, higher
>> level principles, you don't even have a network. :-)

Sure. That is the role for what we call "intent" which is defined=
in draft-irtf-nmrg-autonomic-network-definitions but is not yet
in Anima scope.

>> Second, the three concepts mentioned in the above excerpt (discove= rability,
>> synchronization of state, and parameter negotiation) are necessary= but
>> clearly not sufficient to have autonomic operation. I was talking = about the
>> ability to exchange knowledge (e.g., all or part of an information= model)
>> between entities. It doesn't appear that this is covered in AN= IMA yet, though I
>> haven't read all of the materials.

My personal view is that this is going to be resolved topic by topic.
In GDNP-speak that means that it will be resolved by individual Objective definitions, and GDNP will just act as a neutral carrier. (You can quite fairly argue that this means we are ducking the problem for now.)
Another way to say this is that each type of autonomous service agent will<= br> solve this problem for its own target parameters.

Now, again IMHO, this is why we state in GDNP that the format of the
value of an objective "...might be inherited from an
existing management or configuration protocol, the objective option
acting as a carrier for that format.=C2=A0 The data structure might be
defined in a formal language, but that is a matter for the
specifications of individual objectives.=C2=A0 There are many candidates, according to the context, such as ABNF, RBNF, XML Schema, possibly
YANG, etc.=C2=A0 The GDNP protocol itself is agnostic on these questions.&q= uot;

My expectation is that some objectives will need a formal information
model and that others won't, and that there's no reason we couldn&#= 39;t
inherit existing IMs when they are relevant. But that whole question
is also out of charter scope for now. As you know better than most
people, John, defining an IM can become a very laborious business and
for now we want to get started on simple cases that don't need it.

>> If you cannot exchange knowledge, you will
>> never be autonomic in the computer science sense.

You will find very similar words in draft-irtf-nmrg-an-gap-analysis.

<snip>

Regards
=C2=A0 =C2=A0 Brian

>> regards,
>> John
>>
>> Dr. John Strassner, Ph.D.
>> CTO, Software Laboratory, CRD
>>
>>
>> Futurewei Technologies
>> US R&D Center
>> 2330 Central Expressway
>> Building A, office A2-2143
>> Santa Clara, California=C2=A0 =C2=A095050
>>=C2=A0 Office:=C2=A0 +1.408.330.4923
>>=C2=A0 Email:=C2=A0 =C2=A0john.sc.strassner@huawei.com
>>
>>
>> Best regards,
>>
>> Sheng



--
regards,
John
--047d7bf10a168c452d05110c8ba0-- From nobody Wed Mar 11 18:22: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 897A91A89A5 for ; Wed, 11 Mar 2015 18:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 NZt0Y6WgjrxU for ; Wed, 11 Mar 2015 18:22:34 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c: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 837021A899B for ; Wed, 11 Mar 2015 18:22:33 -0700 (PDT) Received: by wesw55 with SMTP id w55so13063868wes.3 for ; Wed, 11 Mar 2015 18:22:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HazN+XjJ3A2GFagnNShhDYrG7iulyj0BSYKcNb9/1yc=; b=dVY5YVOqVUo2XoqCTV7/Got1PN9cO/xfNR8xa5jkoTRSYVcW+TlIfL8TTYauIlwzxq ZnyNWFJCAXUJk/XaO3eUFRZhmdJPoRhyV2M0NyqEfEztUxsoRCFqeszde4Xbi4nSjy88 Q2KlVvcC4dbvUImZG4/CGF4KXIUSpNntpCcImYA3KhKdFMdi6V6tyeNtsnVFfdDpZuw2 bWOM60OJhT47BZPQGs2JFIIa2HT9rC6XMyVkV9FtNbMW+cL4r/iWrNY72ZibHdAhzX/Q a4Dn7WVQuDOT0Ktd9+ALlm3ceDXHckZONogoT2ur4NBkLsZZ83oPV8dxYqovBfeauaYS 5smA== MIME-Version: 1.0 X-Received: by 10.180.126.69 with SMTP id mw5mr129399952wib.12.1426123352203; Wed, 11 Mar 2015 18:22:32 -0700 (PDT) Received: by 10.27.85.139 with HTTP; Wed, 11 Mar 2015 18:22:32 -0700 (PDT) In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22EF05CD@xmb-rcd-x14.cisco.com> References: <5D36713D8A4E7348A7E10DF7437A4B923B059AD6@nkgeml512-mbx.china.huawei.com> <54FE67C3.9010804@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22EF05CD@xmb-rcd-x14.cisco.com> Date: Wed, 11 Mar 2015 18:22:32 -0700 Message-ID: From: John Strassner To: "Michael Behringer (mbehring)" , John Strassner Content-Type: multipart/alternative; boundary=e89a8f839f1bd0691105110d37bb Archived-At: Cc: Anima WG , John Strassner , "Liubing \(Leo\)" Subject: Re: [Anima] Some comments for draft-carpenter-anima-gdn-protocol 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, 12 Mar 2015 01:22:38 -0000 --e89a8f839f1bd0691105110d37bb Content-Type: text/plain; charset=UTF-8 Hallo Michael, it's been a long time. :-) I understand, and agree, with your first point. Regarding the second point, I understand your point about fully autonomic nodes. In addition, I think the WG should be commended for worrying about legacy elements and processes from the outset. First question: could I characterize your approach as having three types of nodes: fully autonomic, autonomically-aware, and autonomically-unaware? An autonomically-aware node is one that fully autonomic nodes can communicate with, and which understands (perhaps after translation) what functions are required of it and what functions it can offer. An autonomically-unaware node is a dumb rock (e.g., a hub). Then, I could say that an autonomic function is either be supported directly by a fully autonomic node, or built from a set of nodes (some of which are not capable of performing autonomic functions). Second question: performing an autonomic function is a set of behaviors. What's important is the end result, not the individual behaviors. So, as long as each individual behavior can be rigorously defined (e.g., using a software contract, where the behavior satisfies a set of pre- and post-conditions as well as a set of invariants), then (in theory) they should be able to be composited together. Thoughts? best regards, John On Wed, Mar 11, 2015 at 3:42 AM, Michael Behringer (mbehring) < mbehring@cisco.com> wrote: > John, > > Adding to Brian/Sheng my view, there are two important points to note: > > 1) What you see now is just the start. In this first phase we're not > actually standardising any autonomic service agents (as we call them), but > we're preparing an infrastructure for such agents. Meaning, such agents can > count on all the "mechanics" to talk to other agents: Addressing, routing, > security, simple discovery, negotiation, etc. We call this the autonomic > networking infrastructure, and our goal is to make this infrastructure > "self-managing" itself, specifically, it should self-configure. > > This infrastructure is not complete, as you correctly point out. But all > of the functions you mention (e.g., knowledge exchange) first of all > require a solid communications infrastructure. > > In the WG charter you see the elements of the infrastructure, and a couple > of use cases for autonomic service agents. In this first phase the > intention is to validate the autonomic networking infrastructure with those > use cases. See also the UCAN BoF notes, where more use cases were > discussed. Again, we're looking at simple use cases to start with, and work > bottom-up. > > 2) We are not trying to define fully autonomic nodes, but autonomic > functions. In other words, we expect nodes to be partially managed in the > traditional way, and some functions to be autonomic. In the future there > may be cases of fully autonomic nodes. > > As we take on new use cases, we define their requirements, and address the > delta in the autonomic networking infrastructure, bottom up. With the > reference model we need to make sure that we're not going down a track that > will make future use cases impossible or hard to support. This is of course > the main challenge. Your input would be very valuable in this process. > > What are your thoughts? > > Michael > > > > -----Original Message----- > > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E > > Carpenter > > Sent: 10 March 2015 04:41 > > To: John Strassner > > Cc: Liubing (Leo); Anima WG; strazpdj@gmail.com > > Subject: Re: [Anima] Some comments for draft-carpenter-anima-gdn- > > protocol > > > > Hi John and everybody, > > > > Replying to some comments received privately, on the list with > permission: > > On 09/03/2015 22:55, Sheng Jiang wrote: > > > Hi, authors of draft-carpenter-anima-gdn-protocol > > > > > > The below are some comments from my colleague, Dr. John Strassner. > > Although I personally think your protocol designs have the ability to > meet > > his requirements for knowledge exchanging among autonomic nodes, it is > > better you could discuss directly and maybe include some > > modification/clarification in the future version. I also encourage you to > > discuss this in ANIMA mail list openly. > > > > > > Best regards, > > > > > > Sheng > > > > > >> -----Original Message----- > > >> From: John Strassner > > >> Sent: Friday, March 06, 2015 6:43 AM > > >> To: Sheng Jiang; John Strassner > > >> > > >> Dear Sheng, > > >> > > >> I read the charter and am starting on the drafts. > > >> > > >>>> autonomics require the ability to share and exchange knowledge in > > >>>> an interoperable fashion. I fail to see how this is even discussed > > >>>> in ANIMA. > > >>> > > >>> BTW, the ability to share and exchange knowledge in an interoperable > > >>> fashion looks like GNDP (Generic Discovery and Negotiation Protocol) > > >>> in ANIMA. This protocol is designed to support information discovery > > >>> and bi-direction negotiation. > > >> > > >> It appears that GDNP covers some, but not all, of what I am talking > about. > > > > Indeed, it isn't claiming to cover everything. The idea is that draft- > > behringer-anima-reference-model will evolve to show how things fit > > together, which will help us to identify holes. > > > > >> However, the following statement from the GDNP draft is misleading, > > >> if not just plain wrong: > > >> > > >> "In order to fulfil autonomy, devices that embody autonomic service > > >> agents need to be able to discover each other, to synchronize state > > >> with each other, and to negotiate parameters and resources directly > > >> with each other." > > >> > > >> First, autonomic networks are not necessarily autonomous. Autonomy, > > >> in its most generic form, is the ability to have the power for an > > >> entity to govern itself. If every network element governs itself > > >> without regard to other, higher level principles, you don't even have > > >> a network. :-) > > > > Sure. That is the role for what we call "intent" which is defined in > draft-irtf- > > nmrg-autonomic-network-definitions but is not yet in Anima scope. > > > > >> Second, the three concepts mentioned in the above excerpt > > >> (discoverability, synchronization of state, and parameter > > >> negotiation) are necessary but clearly not sufficient to have > > >> autonomic operation. I was talking about the ability to exchange > > >> knowledge (e.g., all or part of an information model) between > > >> entities. It doesn't appear that this is covered in ANIMA yet, though > I > > haven't read all of the materials. > > > > My personal view is that this is going to be resolved topic by topic. > > In GDNP-speak that means that it will be resolved by individual Objective > > definitions, and GDNP will just act as a neutral carrier. (You can quite > fairly > > argue that this means we are ducking the problem for now.) Another way to > > say this is that each type of autonomous service agent will solve this > > problem for its own target parameters. > > > > Now, again IMHO, this is why we state in GDNP that the format of the > value > > of an objective "...might be inherited from an existing management or > > configuration protocol, the objective option acting as a carrier for that > > format. The data structure might be defined in a formal language, but > that > > is a matter for the specifications of individual objectives. There are > many > > candidates, according to the context, such as ABNF, RBNF, XML Schema, > > possibly YANG, etc. The GDNP protocol itself is agnostic on these > > questions." > > > > My expectation is that some objectives will need a formal information > > model and that others won't, and that there's no reason we couldn't > inherit > > existing IMs when they are relevant. But that whole question is also out > of > > charter scope for now. As you know better than most people, John, > defining > > an IM can become a very laborious business and for now we want to get > > started on simple cases that don't need it. > > > > >> If you cannot exchange knowledge, you will never be autonomic in the > > >> computer science sense. > > > > You will find very similar words in draft-irtf-nmrg-an-gap-analysis. > > > > > > > > Regards > > Brian > > > > >> regards, > > >> John > > >> > > >> Dr. John Strassner, Ph.D. > > >> CTO, Software Laboratory, CRD > > >> > > >> > > >> Futurewei Technologies > > >> US R&D Center > > >> 2330 Central Expressway > > >> Building A, office A2-2143 > > >> Santa Clara, California 95050 > > >> Office: +1.408.330.4923 > > >> Email: john.sc.strassner@huawei.com > > >> > > >> > > >> Best regards, > > >> > > >> Sheng > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > -- regards, John --e89a8f839f1bd0691105110d37bb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hallo Michael,
it's been a long time. := -)

I understand, and agree, with your first point= .

Regarding the second point, I understand your po= int about fully autonomic nodes. In addition, I think the WG should be comm= ended for worrying about legacy elements and processes from the outset.

First question: could I characterize your approach as= having three types of nodes: fully autonomic, autonomically-aware, and aut= onomically-unaware?=C2=A0An autonomically-aware node is one that fully auto= nomic nodes can communicate with, and which understands (perhaps after tran= slation) what functions are required of it and what functions it can offer.= An autonomically-unaware node is a dumb rock (e.g., a hub).

=
Then, I could say that an autonomic function is either be=C2=A0s= upported directly by a fully autonomic node, or built from a set of=C2=A0no= des (some of which are not=C2=A0capable of performing autonomic functions).=

Second question: performing an autonomic function= is a set of behaviors. What's important is the end result, not the ind= ividual behaviors. So, as long as each individual behavior can be rigorousl= y defined (e.g., using a software contract, where the behavior satisfies a = set of pre- and post-conditions as well as a set of invariants), then (in t= heory) they should be able to be composited together.

<= div>Thoughts?


best regards,
John



On Wed, Mar 11, 2015 at 3:42 AM, Michae= l Behringer (mbehring) <mbehring@cisco.com> wrote:
John,

Adding to Brian/Sheng my view, there are two important points to note:

1) What you see now is just the start. In this first phase we're not ac= tually standardising any autonomic service agents (as we call them), but we= 're preparing an infrastructure for such agents. Meaning, such agents c= an count on all the "mechanics" to talk to other agents: Addressi= ng, routing, security, simple discovery, negotiation, etc. We call this the= autonomic networking infrastructure, and our goal is to make this infrastr= ucture "self-managing" itself, specifically, it should self-confi= gure.

This infrastructure is not complete, as you correctly point out. But all of= the functions you mention (e.g., knowledge exchange) first of all require = a solid communications infrastructure.

In the WG charter you see the elements of the infrastructure, and a couple = of use cases for autonomic service agents. In this first phase the intentio= n is to validate the autonomic networking infrastructure with those use cas= es. See also the UCAN BoF notes, where more use cases were discussed. Again= , we're looking at simple use cases to start with, and work bottom-up.<= br>
2) We are not trying to define fully autonomic nodes, but autonomic functio= ns. In other words, we expect nodes to be partially managed in the traditio= nal way, and some functions to be autonomic. In the future there may be cas= es of fully autonomic nodes.

As we take on new use cases, we define their requirements, and address the = delta in the autonomic networking infrastructure, bottom up. With the refer= ence model we need to make sure that we're not going down a track that = will make future use cases impossible or hard to support. This is of course= the main challenge. Your input would be very valuable in this process.

What are your thoughts?

Michael


> -----Original Message-----
> From: Anima [mailto:anima-bo= unces@ietf.org] On Behalf Of Brian E
> Carpenter
> Sent: 10 March 2015 04:41
> To: John Strassner
> Cc: Liubing (Leo); Anima WG; str= azpdj@gmail.com
> Subject: Re: [Anima] Some comments for draft-carpenter-anima-gdn-
> protocol
>
> Hi John and everybody,
>
> Replying to some comments received privately, on the list with permiss= ion:
> On 09/03/2015 22:55, Sheng Jiang wrote:
> > Hi, authors of draft-carpenter-anima-gdn-protocol
> >
> > The below are some comments from my colleague, Dr. John Strassner= .
> Although I personally think your protocol designs have the ability to = meet
> his requirements for knowledge exchanging among autonomic nodes, it is=
> better you could discuss directly and maybe include some
> modification/clarification in the future version. I also encourage you= to
> discuss this in ANIMA mail list openly.
> >
> > Best regards,
> >
> > Sheng
> >
> >> -----Original Message-----
> >> From: John Strassner
> >> Sent: Friday, March 06, 2015 6:43 AM
> >> To: Sheng Jiang; John Strassner
> >>
> >> Dear Sheng,
> >>
> >> I read the charter and am starting on the drafts.
> >>
> >>>> autonomics require the ability to share and exchange = knowledge in
> >>>> an interoperable fashion. I fail to see how this is e= ven discussed
> >>>> in ANIMA.
> >>>
> >>> BTW, the ability to share and exchange knowledge in an in= teroperable
> >>> fashion looks like GNDP (Generic Discovery and Negotiatio= n Protocol)
> >>> in ANIMA. This protocol is designed to support informatio= n discovery
> >>> and bi-direction negotiation.
> >>
> >> It appears that GDNP covers some, but not all, of what I am t= alking about.
>
> Indeed, it isn't claiming to cover everything. The idea is that dr= aft-
> behringer-anima-reference-model will evolve to show how things fit
> together, which will help us to identify holes.
>
> >> However, the following statement from the GDNP draft is misle= ading,
> >> if not just plain wrong:
> >>
> >> "In order to fulfil autonomy, devices that embody autono= mic service
> >> agents need to be able to discover each other, to synchronize= state
> >> with each other, and to negotiate parameters and resources di= rectly
> >> with each other."
> >>
> >> First, autonomic networks are not necessarily autonomous. Aut= onomy,
> >> in its most generic form, is the ability to have the power fo= r an
> >> entity to govern itself. If every network element governs its= elf
> >> without regard to other, higher level principles, you don'= ;t even have
> >> a network. :-)
>
> Sure. That is the role for what we call "intent" which is de= fined in draft-irtf-
> nmrg-autonomic-network-definitions but is not yet in Anima scope.
>
> >> Second, the three concepts mentioned in the above excerpt
> >> (discoverability, synchronization of state, and parameter
> >> negotiation) are necessary but clearly not sufficient to have=
> >> autonomic operation. I was talking about the ability to excha= nge
> >> knowledge (e.g., all or part of an information model) between=
> >> entities. It doesn't appear that this is covered in ANIMA= yet, though I
> haven't read all of the materials.
>
> My personal view is that this is going to be resolved topic by topic.<= br> > In GDNP-speak that means that it will be resolved by individual Object= ive
> definitions, and GDNP will just act as a neutral carrier. (You can qui= te fairly
> argue that this means we are ducking the problem for now.) Another way= to
> say this is that each type of autonomous service agent will solve this=
> problem for its own target parameters.
>
> Now, again IMHO, this is why we state in GDNP that the format of the v= alue
> of an objective "...might be inherited from an existing managemen= t or
> configuration protocol, the objective option acting as a carrier for t= hat
> format.=C2=A0 The data structure might be defined in a formal language= , but that
> is a matter for the specifications of individual objectives.=C2=A0 The= re are many
> candidates, according to the context, such as ABNF, RBNF, XML Schema,<= br> > possibly YANG, etc.=C2=A0 The GDNP protocol itself is agnostic on thes= e
> questions."
>
> My expectation is that some objectives will need a formal information<= br> > model and that others won't, and that there's no reason we cou= ldn't inherit
> existing IMs when they are relevant. But that whole question is also o= ut of
> charter scope for now. As you know better than most people, John, defi= ning
> an IM can become a very laborious business and for now we want to get<= br> > started on simple cases that don't need it.
>
> >> If you cannot exchange knowledge, you will never be autonomic= in the
> >> computer science sense.
>
> You will find very similar words in draft-irtf-nmrg-an-gap-analysis. >
> <snip>
>
> Regards
>=C2=A0 =C2=A0 =C2=A0Brian
>
> >> regards,
> >> John
> >>
> >> Dr. John Strassner, Ph.D.
> >> CTO, Software Laboratory, CRD
> >>
> >>
> >> Futurewei Technologies
> >> US R&D Center
> >> 2330 Central Expressway
> >> Building A, office A2-2143
> >> Santa Clara, California=C2=A0 =C2=A095050
> >>=C2=A0 Office:=C2=A0 +1.408.330.4923
> >>=C2=A0 Email:=C2=A0 =C2=A0john.sc.strassner@huawei.com
> >>
> >>
> >> Best regards,
> >>
> >> Sheng
>
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima



--
regards,
John
--e89a8f839f1bd0691105110d37bb-- From nobody Wed Mar 11 18:38: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 DCFCA1A884C for ; Wed, 11 Mar 2015 18:38: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 WT2god5_lEbQ for ; Wed, 11 Mar 2015 18:38:25 -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 79ED91A8944 for ; Wed, 11 Mar 2015 18:38:25 -0700 (PDT) Received: by paceu11 with SMTP id eu11so16130038pac.1 for ; Wed, 11 Mar 2015 18:38:25 -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=kdLkDquPlUDrfBWjGGgo7DYWpPC6PbiKkN75e8m7WoU=; b=lVBCU3GMkXXoiE+EkUg6w7ZvpF+Il3vmI2ZDWCaF0dHOHwdwVzPRNtJth2KLdLwi8J O3IpCVhDKGfFlanJze7TqBUOqzKg+JWejxXMg5AR+uqSOfhdBrbc7A9GbekGgoDfm9U6 K7EjTYjVP/bXGN+itBul5eG9ogxi3TnLdnmiScv3aRrJ/quVr9402yc70dzCKMDZ9d0N fB9U0yCDENqNGVJUJ5RzMTDwtxO7Ax4XARi0E6zE6Wg+8nnUObDJGHNb9IiURxz2Wnie jcl0gO7v0nm+i6/hcDZYZgSaZFdwEXASrIbcgRkPGv2tcVolkvokZc1ILWF/wKPxAApO MfFg== X-Received: by 10.70.129.108 with SMTP id nv12mr64262406pdb.71.1426124305117; Wed, 11 Mar 2015 18:38:25 -0700 (PDT) Received: from ?IPv6:2406:e007:5cba:1:28cc:dc4c:9703:6781? ([2406:e007:5cba:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id rf12sm8147367pdb.0.2015.03.11.18.38.21 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Mar 2015 18:38:24 -0700 (PDT) Message-ID: <5500EE15.8060009@gmail.com> Date: Thu, 12 Mar 2015 14:38:29 +1300 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.5.0 MIME-Version: 1.0 To: John Strassner References: <5D36713D8A4E7348A7E10DF7437A4B923B059AD6@nkgeml512-mbx.china.huawei.com> <54FE67C3.9010804@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: John Strassner , "Liubing \(Leo\)" , Anima WG Subject: [Anima] Reading list [Some comments for draft-carpenter-anima-gdn-protocol] 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, 12 Mar 2015 01:38:27 -0000 On 12/03/2015 13:34, John Strassner wrote: ... > You will find very similar words in draft-irtf-nmrg-an-gap-analysis. > > Yikers, another draft. Is there a list of all drafts that may be eventually > considered? > The official list of related drafts for the WG is at http://datatracker.ietf.org/wg/anima/documents/ Then there were two drafts developed in the Network Management Research Group, which are in the final stages of review to become RFCs: http://tools.ietf.org/html/draft-irtf-nmrg-an-gap-analysis http://tools.ietf.org/html/draft-irtf-nmrg-autonomic-network-definitions I think that's it for *directly* relevant drafts, but there are at least two others relevant to security bootstrapping: draft-ietf-netconf-zerotouch draft-he-6lo-analysis-iot-sbootstrapping and we had a bunch of possible use cases at the UCAN BOF https://tools.ietf.org/wg/anima/trac/wiki/UCAN Brian From nobody Wed Mar 11 19:42:25 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 3E88A1A8A05 for ; Wed, 11 Mar 2015 19:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 ZCvGUbAuT1nP for ; Wed, 11 Mar 2015 19:42:15 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c: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 25F291A89FD for ; Wed, 11 Mar 2015 19:42:15 -0700 (PDT) Received: by wevl61 with SMTP id l61so13321091wev.6 for ; Wed, 11 Mar 2015 19:42:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Qlc1Z2Y5C3epSOTYAWFbpI28X/kVio4szVF7gafMuGw=; b=D66CgUBV6DmlgWvQ+sftiE3EEhwkFYc+NULr0KHFzuSv9EIpSBf5bNLUjTnQk7WLIi OExqAjo/JqChDlzJwTgg9wSnYKOU0MQamZhcDEb3bem73n18D+K+jSVe0Bhk5/1xw18J 7hePjmn9Q0VMRhyCP0nUfacD/QZpRiL02RDeDUlHcJmk9vX1KbrPYb2bFrhipWqB+iMo r5cc2N5i08iGBnK+OIIaagll0jUGUtjsHj+IdCb/GbqeUMcqCaW6ehH3rd0RL1eLoIsE 3eiJTqS/Qf3CyuZEmSkNQNZjXWf35+7DTTxYutILRl0rtLWCli5QDxtFurnbHHqa2onh tacQ== MIME-Version: 1.0 X-Received: by 10.194.59.112 with SMTP id y16mr85245867wjq.36.1426128133780; Wed, 11 Mar 2015 19:42:13 -0700 (PDT) Received: by 10.27.85.139 with HTTP; Wed, 11 Mar 2015 19:42:13 -0700 (PDT) In-Reply-To: <5500EE15.8060009@gmail.com> References: <5D36713D8A4E7348A7E10DF7437A4B923B059AD6@nkgeml512-mbx.china.huawei.com> <54FE67C3.9010804@gmail.com> <5500EE15.8060009@gmail.com> Date: Wed, 11 Mar 2015 19:42:13 -0700 Message-ID: From: John Strassner To: Brian E Carpenter Content-Type: multipart/alternative; boundary=047d7ba97cc4d179b405110e5424 Archived-At: Cc: John Strassner , "Liubing \(Leo\)" , Anima WG Subject: Re: [Anima] Reading list [Some comments for draft-carpenter-anima-gdn-protocol] 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, 12 Mar 2015 02:42:21 -0000 --047d7ba97cc4d179b405110e5424 Content-Type: text/plain; charset=UTF-8 Thanks Brian! On Wed, Mar 11, 2015 at 6:38 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 12/03/2015 13:34, John Strassner wrote: > ... > > You will find very similar words in draft-irtf-nmrg-an-gap-analysis. > > > > Yikers, another draft. Is there a list of all drafts that may be > eventually > > considered? > > > > The official list of related drafts for the WG is at > http://datatracker.ietf.org/wg/anima/documents/ > > Then there were two drafts developed in the Network Management Research > Group, which are in the final stages of review to become RFCs: > > http://tools.ietf.org/html/draft-irtf-nmrg-an-gap-analysis > http://tools.ietf.org/html/draft-irtf-nmrg-autonomic-network-definitions > > I think that's it for *directly* relevant drafts, but there are > at least two others relevant to security bootstrapping: > > draft-ietf-netconf-zerotouch > draft-he-6lo-analysis-iot-sbootstrapping > > and we had a bunch of possible use cases at the UCAN BOF > https://tools.ietf.org/wg/anima/trac/wiki/UCAN > > Brian > > -- regards, John --047d7ba97cc4d179b405110e5424 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Brian!

On Wed, Mar 11, 2015 at 6:38 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
On 12/03/2015 13:34, John Strassner wrote:
...
> You will find very similar words in draft-irtf-nmrg-an-gap-analysis. > <jcs>
> Yikers, another draft. Is there a list of all drafts that may be event= ually
> considered?
> </jcs>

The official list of related drafts for the WG is at
http://datatracker.ietf.org/wg/anima/documents/

Then there were two drafts developed in the Network Management Research
Group, which are in the final stages of review to become RFCs:

http://tools.ietf.org/html/draft-irtf-nmrg-an-gap-analysis
http://tools.ietf.org/html/draft-irtf-nmrg-auto= nomic-network-definitions

I think that's it for *directly* relevant drafts, but there are
at least two others relevant to security bootstrapping:

draft-ietf-netconf-zerotouch
draft-he-6lo-analysis-iot-sbootstrapping

and we had a bunch of possible use cases at the UCAN BOF
https://tools.ietf.org/wg/anima/trac/wiki/UCAN

=C2=A0 =C2=A0 Brian




--
regards,
John
--047d7ba97cc4d179b405110e5424-- From nobody Wed Mar 11 20:09: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 6F1861A89D3 for ; Wed, 11 Mar 2015 20:09:43 -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_44=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 7Pg6isaU25gX for ; Wed, 11 Mar 2015 20:09: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 4926C1A89FF for ; Wed, 11 Mar 2015 20:09:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQD53864; Thu, 12 Mar 2015 03:09:38 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 12 Mar 2015 03:09:37 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.106]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Thu, 12 Mar 2015 11:09:34 +0800 From: Sheng Jiang To: Juliao Braga , "anima@ietf.org" Thread-Topic: [Anima] Primary agenda for ANIMA sessions in IETF 92 Thread-Index: AdBa4ay69+UOkualQCi0cRX6EwriGAA3uruAACwUZ8A= Date: Thu, 12 Mar 2015 03:09:32 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923B05DFE8@nkgeml512-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B923B05BD1B@nkgeml512-mbx.china.huawei.com> <55004A59.1070607@braga.eti.br> In-Reply-To: <55004A59.1070607@braga.eti.br> 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] Primary agenda for ANIMA sessions in 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: Thu, 12 Mar 2015 03:09:43 -0000 QXMgcmVndWxhciwgd2UgaGF2ZSBNZWV0ZWNobyBhbmQgSmFiYmVyIChKYWJiZXIgc2NyaWJlIGlz IG5lZWRlZCwgcGxlYXNlIHZvbHVudGVlcikuIFJlbW90ZSBwcmVzZW50YXRpb24gbWF5IG5lZWQg YWRkaXRpb25hbCBhcnJhbmdlbWVudCAoc28gZmFyLCBJIGRvbid0IGtub3cgYW55IGluIGFuaW1h IHNlc3Npb25zKS4gSUVURiBwcm92aWRlcyByZWFsIHRpbWUgYXVkaW8gc3RyZWFtIGZvciBhbGwg bWVldGluZyByb29tcy4gWW91IGNhbiBhY2Nlc3MgZnJvbSB0aGUgdG9vbHMtc3R5bGUgYWdlbmRh IHBhZ2UuDQoNCkphYmJlciBSb29tOiBhbmltYUBqYWJiZXIuaWV0Zi5vcmcgDQpNZWV0ZWNobzog aHR0cDovL3d3dy5tZWV0ZWNoby5jb20vaWV0ZjkyL2FuaW1hDQoNCmh0dHA6Ly90b29scy5pZXRm Lm9yZy9hZ2VuZGEvOTIvDQoNCkJlc3QgcmVnYXJkcywNCg0KU2hlbmcNCg0KPi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogQW5pbWEgW21haWx0bzphbmltYS1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgSnVsaWFvIEJyYWdhDQo+U2VudDogV2VkbmVzZGF5LCBNYXJjaCAx MSwgMjAxNSAxMDowMCBQTQ0KPlRvOiBhbmltYUBpZXRmLm9yZw0KPlN1YmplY3Q6IFJlOiBbQW5p bWFdIFByaW1hcnkgYWdlbmRhIGZvciBBTklNQSBzZXNzaW9ucyBpbiBJRVRGIDkyDQo+DQo+V2Ug d2lsbCBoYXZlIGZhY2lsaXRpZXMgZm9yIHJlbW90ZSBwYXJ0aWNpcGF0aW9uPw0KPg0KPlRrcywN Cj4NCj5KdWxpw6NvDQo+DQo+T24gMTAvMDMvMjAxNSAwMDoyNCwgU2hlbmcgSmlhbmcgd3JvdGU6 DQo+PiBIaSwgYWxsLA0KPj4NCj4+IFRoZSBBTklNQSBXRyBjaGFpcnMgaGF2ZSB1cGxvYWRlZCBh IHByaW1hcnkgYWdlbmRhIGZvciBBTklNQSBzZXNzaW9uDQo+aW4gSUVURiA5MiwgYXMgdGhlIGJl bG93IGxpbmsgYW5kIGF0dGFjaG1lbnQuIEFzIHN0YXRlZCBiZWZvcmUsIHRoZSBUdWVzZGF5DQo+ Mi1ob3VyIHNlc3Npb24gaXMgZGVkaWNhdGVkIGZvciB1cmdlbnQgV0cgbWlsZXN0b25lczsgdGhl IEZyaWRheSAxLjUtaG91cg0KPnNlc3Npb24gaXMgbWFpbmx5IGZvciBvdGhlciB3b3JrIGl0ZW1z IHJlbGV2YW50IHRvIGF1dG9ub21pYyBuZXR3b3JrIGJ1dCBub3QNCj5pbiB1cmdlbnQgV0cgbWls ZXN0b25lcy4NCj4+DQo+PiBodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzkyL2FnZW5k YS9hZ2VuZGEtOTItYW5pbWENCj4+DQo+PiBUaGUgcHJpbWFyeSBhZ2VuZGEgaXMgc3RpbGwgYSBz dWJqZWN0IHRvIGNoYW5nZS4gU28sIHlvdSBtYXkgZ2l2ZSB5b3VyDQo+c3VnZ2VzdGlvbnMuIFRo ZSBjaGFpcnMgbWF5IGFkanVzdCBhY2NvcmRpbmdseSBpZiBwb3NzaWJsZS4gV2UgYXJlIGV4cGVj dGluZw0KPnRvIGZpbmFsaXplIHRoZSBhZ2VuZGEgYXQgdGhlIGVuZCBvZiB0aGlzIHdlZWsuDQo+ Pg0KPj4gQmVzdCByZWdhcmRzLA0KPj4NCj4+IFNoZW5nICsgVG9lcmxlc3MNCj4+DQo+PiBBTklN QSBXRyBBZ2VuZGEgZm9yIElFVEYtOTIgKERhbGxhcykNCj4+ICAgICAgICBBdXRvbm9taWMgTmV0 d29ya2luZyBJbnRlZ3JhdGVkIE1vZGVsIGFuZCBBcHByb2FjaA0KPj4gICAgICAgIENoYWlyczog VG9lcmxlc3MgRWNrZXJ0ICYgU2hlbmcgSmlhbmcNCj4+DQo+PiBUaGUgVHVlc2RheSAyLWhvdXIg c2Vzc2lvbiBpcyBkZWRpY2F0ZWQgZm9yIHVyZ2VudCBXRyBtaWxlc3RvbmVzOw0KPj4gdGhlIEZy aWRheSAxLjUtaG91ciBzZXNzaW9uIGlzIG1haW5seSBmb3Igb3RoZXIgd29yayBpdGVtcw0KPj4g cmVsZXZhbnQgdG8gYXV0b25vbWljIG5ldHdvcmsgYnV0IG5vdCBpbiB1cmdlbnQgV0cgbWlsZXN0 b25lcy4NCj4+DQo+Pg0KPj4gVHVlc2RheSAoTWFyY2ggMjQsIDIwMTUpIDItaG91ciBzZXNzaW9u Og0KPj4gICAgIDE1MjAtMTcyMCAgQWZ0ZXJub29uIFNlc3Npb24gSUksIE9haw0KPj4gICAgIFdH IERhc2ggNSBtaW4NCj4+ICAgICBEaXNjb3ZlcnkgYW5kIG5lZ290aWF0aW9uIGZ1bmN0aW9uIC0g NDUgbWluDQo+PiAgICAgICAgR2VuZXJpYyBEaXNjb3ZlcnkgYW5kIE5lZ290aWF0aW9uIFByb3Rv Y29sIC0gMjAgbWluDQo+PiAgICAgICAgICAgKEJyaWFuIENhcnBlbnRlciwgQ29uZmlybWVkKQ0K Pj4gICAgICAgIEF1dG9ub21pYyBEaXN0cmlidXRlZCBOb2RlIENvbnNlbnN1cyBQcm90b2NvbCAt IDEwIG1pbg0KPj4gICAgICAgICAgIChNYXJrdXMgU3RlbmJlcmcsIENvbmZpcm1lZCkNCj4+ICAg ICAgICBDb21iaW5lIGRpc2N1c3Npb24gZm9yIEdETlAmRE5DUCAtIDE1IG1pbg0KPj4gICAgIEF1 dG8gYm9vdHN0cmFwcGluZyAtIDQ1IG1pbg0KPj4gICAgICAgIEJvb3RzdHJhcHBpbmcta2V5aW5m cmEgLSAxNSBtaW4NCj4+ICAgICAgICAgICAoTWF4IFByaXRpa2luLCBDb25maXJtZWQpDQo+PiAg ICAgICAgWmVybyB0b3VjaCAtIDEwIG1pbg0KPj4gICAgICAgICAgIChDb25maXJtYXRpb24gbmVl ZGVkKQ0KPj4gICAgICAgIFN1cnZleSBvZiBTZWN1cml0eSBCb290c3RyYXBwaW5nIC0gMTAgbWlu DQo+PiAgICAgICAgICAgKERhbnBpbmcgSGUsIENvbmZpcm1lZCkNCj4+ICAgICAgICBDb21iaW5l IGRpc2N1c3Npb24gLSAxMCBtaW4NCj4+ICAgICBBdXRvbm9taWMgQ29udHJvbCBQbGFuZSAmIERp c2N1c3Npb24gLSAyNSBtaW4NCj4+ICAgICAgICAoTWljaGFlbCBCZWhyaW5nZXIsIENvbmZpcm1l ZCkNCj4+DQo+Pg0KPj4gRnJpZGF5IChNYXJjaCAyNywgMjAxNSkgMS41LWhvdXIgc2Vzc2lvbg0K Pj4gICAgIDExNTAtMTMyMCAgQWZ0ZXJub29uIFNlc3Npb24gSSwgUGFyaXNpYW4NCj4+ICAgICBS ZWZlcmVuY2UgbW9kZWwgLSAyMCBtaW4NCj4+ICAgICAgICAoTWljaGFlbCBCZWhyaW5nZXIsIENv bmZpcm1lZCkNCj4+ICAgICBPYnNlcnZhdGlvbnMgb24gYm9vdHN0cmFwcGluZyBhbmQgc3luY2hy b25pemF0aW9uIC0gMTUgbWluDQo+PiAgICAgICAgKFJlbmUgU3RydWlrLCBDb25maXJtKQ0KPj4g ICAgIENvb3JkaW5hdGluZyBtdWx0aXBsZSAoY29uZmxpY3RpbmcpIGF1dG9ub21pYyBmdW5jdGlv bnMgLSAxNSBtaW4NCj4+ICAgICAgICAoTGF1cmVudCBDaWF2YWdsaWEsIENvbmZpcm1lZCkNCj4+ ICAgICBTZWxmLU1hbmFnZWQgTmV0d29ya3Mgd2l0aCBGYXVsdCBNYW5hZ2VtZW50IEhpZXJhcmNo eSAtIDE1IG1pbg0KPj4gICAgICAgIChUb3kgTWVobWV0LCBDb25maXJtZWQpDQo+PiAgICAgUHJl ZGljdGl2ZSByaXNrIGF3YXJlbmVzcyBmb3IgcHJvYWN0aXZlIG1hbmFnZW1lbnQgLSAxNSBtaW4N Cj4+ICAgICAgICAoTGF1cmVudCBDaWF2YWdsaWEsIENvbmZpcm1lZCkNCj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBBbmltYSBtYWlsaW5nIGxp c3QNCj4+IEFuaW1hQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2FuaW1hDQo+Pg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+QW5pbWEgbWFpbGluZyBsaXN0DQo+QW5pbWFAaWV0Zi5vcmcNCj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hDQo= From nobody Thu Mar 12 01:17:14 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 B66711A8972 for ; Thu, 12 Mar 2015 01:17:12 -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 3nzm1bwyS4Oc for ; Thu, 12 Mar 2015 01:17:07 -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 080211A88CE for ; Thu, 12 Mar 2015 01:17:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=53024; q=dns/txt; s=iport; t=1426148228; x=1427357828; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zNN+aqfeS0YY7YZ1EzXZpk3/BInfb8b3nrb2rNi9QGU=; b=cYrsOcZlMuy7sa+uT3Mh5PL6m6TZ2xGeaGmK/Zl1Y8Ae5BPTeXIPMzNI ZCxu4kWQnmfh+Mwg24o3pcnN1zAWXs09lsZj731vndz+ojiK3332e40IH q3ipFJgqLdGWIUkLk7DIuTOPhZri8YgVPoxxTiH+dhj5W9y6wj0Ydzozw w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C2BgB3SgFV/5RdJa1RBwOCQ0NSWgSDB718gi0BCYVwAhyBFkwBAQEBAQF9hA8BAQEDAQEBARcJCjoHCwwCAgIBCA4DBAEBAQoWAQYDAgICFAsGCxQJCAIEDgUIiBMDCQgNrzCVSA2FLwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEBIoUf4JEgUsGCgIBAR0WCwwEBgEGC4JXL4EWBZAkhgmCDoJkhXyGUIJSg0Ujg25vAYEDJBx/AQEB X-IronPort-AV: E=Sophos;i="5.11,387,1422921600"; d="scan'208,217";a="131297031" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-2.cisco.com with ESMTP; 12 Mar 2015 08:17:07 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t2C8H59C011902 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Mar 2015 08:17:05 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.142]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Thu, 12 Mar 2015 03:17:05 -0500 From: "Michael Behringer (mbehring)" To: John Strassner Thread-Topic: [Anima] Some comments for draft-carpenter-anima-gdn-protocol Thread-Index: AQHQWuQNTPthNQ4MbUG6geddsooIWp0W7nnggAF1lwCAABhAwA== Date: Thu, 12 Mar 2015 08:17:04 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22EF15FA@xmb-rcd-x14.cisco.com> References: <5D36713D8A4E7348A7E10DF7437A4B923B059AD6@nkgeml512-mbx.china.huawei.com> <54FE67C3.9010804@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22EF05CD@xmb-rcd-x14.cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.132] Content-Type: multipart/alternative; boundary="_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22EF15FAxmbrcdx14ciscoc_" MIME-Version: 1.0 Archived-At: Cc: Anima WG , John Strassner , "Liubing \(Leo\)" Subject: Re: [Anima] Some comments for draft-carpenter-anima-gdn-protocol 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, 12 Mar 2015 08:17:13 -0000 --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22EF15FAxmbrcdx14ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW5saW5l4oCmLg0KDQpGcm9tOiBKb2huIFN0cmFzc25lciBbbWFpbHRvOnN0cmF6cGRqQGdtYWls LmNvbV0NClNlbnQ6IDEyIE1hcmNoIDIwMTUgMDI6MjMNClRvOiBNaWNoYWVsIEJlaHJpbmdlciAo bWJlaHJpbmcpOyBKb2huIFN0cmFzc25lcg0KQ2M6IEJyaWFuIEUgQ2FycGVudGVyOyBKb2huIFN0 cmFzc25lcjsgTGl1YmluZyAoTGVvKTsgQW5pbWEgV0cNClN1YmplY3Q6IFJlOiBbQW5pbWFdIFNv bWUgY29tbWVudHMgZm9yIGRyYWZ0LWNhcnBlbnRlci1hbmltYS1nZG4tcHJvdG9jb2wNCg0KSGFs bG8gTWljaGFlbCwNCml0J3MgYmVlbiBhIGxvbmcgdGltZS4gOi0pDQoNCk1COiBJbmRlZWQg4oCT IHRoZSB3b3JsZCBpcyBzbWFsbCEg4pi6DQoNCkkgdW5kZXJzdGFuZCwgYW5kIGFncmVlLCB3aXRo IHlvdXIgZmlyc3QgcG9pbnQuDQoNClJlZ2FyZGluZyB0aGUgc2Vjb25kIHBvaW50LCBJIHVuZGVy c3RhbmQgeW91ciBwb2ludCBhYm91dCBmdWxseSBhdXRvbm9taWMgbm9kZXMuIEluIGFkZGl0aW9u LCBJIHRoaW5rIHRoZSBXRyBzaG91bGQgYmUgY29tbWVuZGVkIGZvciB3b3JyeWluZyBhYm91dCBs ZWdhY3kgZWxlbWVudHMgYW5kIHByb2Nlc3NlcyBmcm9tIHRoZSBvdXRzZXQuDQoNCkZpcnN0IHF1 ZXN0aW9uOiBjb3VsZCBJIGNoYXJhY3Rlcml6ZSB5b3VyIGFwcHJvYWNoIGFzIGhhdmluZyB0aHJl ZSB0eXBlcyBvZiBub2RlczogZnVsbHkgYXV0b25vbWljLCBhdXRvbm9taWNhbGx5LWF3YXJlLCBh bmQgYXV0b25vbWljYWxseS11bmF3YXJlPyBBbiBhdXRvbm9taWNhbGx5LWF3YXJlIG5vZGUgaXMg b25lIHRoYXQgZnVsbHkgYXV0b25vbWljIG5vZGVzIGNhbiBjb21tdW5pY2F0ZSB3aXRoLCBhbmQg d2hpY2ggdW5kZXJzdGFuZHMgKHBlcmhhcHMgYWZ0ZXIgdHJhbnNsYXRpb24pIHdoYXQgZnVuY3Rp b25zIGFyZSByZXF1aXJlZCBvZiBpdCBhbmQgd2hhdCBmdW5jdGlvbnMgaXQgY2FuIG9mZmVyLiBB biBhdXRvbm9taWNhbGx5LXVuYXdhcmUgbm9kZSBpcyBhIGR1bWIgcm9jayAoZS5nLiwgYSBodWIp Lg0KDQpNQjogWWVzLCB3ZeKAmXJlIGVzc2VudGlhbGx5IHRoaW5raW5nIGFsb25nIHRoZSBzYW1l IGxpbmVzLCBidXQgcGhyYXNlIGl0IGRpZmZlcmVudGx5LiBXZSBhZ3JlZSBvbiDigJxmdWxseSBh dXRvbm9taWPigJ0sIHRoYXTigJlzIHRoZSBlYXN5IG9uZS4NCk5vdywgeW91ciDigJxhdXRvbm9t aWNhbGx5LWF3YXJl4oCdIGRlZmluaXRpb24gdHJhbnNsYXRlcyBpbiBvdXIgd29ybGQgdG8g4oCc c3VwcG9ydHMgdGhlIEF1dG9ub21pYyBOZXR3b3JraW5nIEluZnJhc3RydWN0dXJl4oCdLCB3aGlj aCBpcyBleGFjdGx5IHdoYXQgd2XigJlyZSBkZWZpbmluZyByaWdodCBub3cgaW4gQU5JTUEuIEkg dGhpbmsgdGhpcyBkZWZpbml0aW9uIGhhcyB0d28gc3ViLWZsYXZvdXJzOg0KDQphKSAgICAgIHRo ZSBub2RlIHN1cHBvcnRzIHRoZSBBTiBJbmZyYXN0cnVjdHVyZSAgYW5kIG9uZSBvciBzZXZlcmFs IGF1dG9ub21pYyBzZXJ2aWNlIGFnZW50cyAoYnV0IGlzIG5vdCBmdWxseSBhdXRvbm9taWMpDQoN CmIpICAgICAgdGhlIG5vZGUgc3VwcG9ydHMgdGhlIEFOIEluZnJhc3RydWN0dXJlLCBidXQgbWF5 IG5vdCBiZSBhd2FyZSBvZiBhdXRvbm9taWMgc2VydmljZSBhZ2VudHMgdGhhdCBydW4gb24gb3Ro ZXIgbm9kZXMuDQpQb2ludCBhKSBpcyBhIHN1YnNldCBvZiBiKS4gRXhhbXBsZTogdG9wb2xvZ3kg aXMgQS0tLS1CLS0tLUMuIEFsbCBub2RlcyBzdXBwb3J0IHRoZSBBTiBpbmZyYXN0cnVjdHVyZS4g QSBhbmQgQyBzaG91bGQgYmUgYWJsZSB0byBuZWdvdGlhdGUgcGFyYW1ldGVycyBmb3IgYW4gYXV0 b25vbWljIHNlcnZpY2UgYWdlbnRzLCBldmVuIGlmIEIgZG9lc27igJl0IGltcGxlbWVudCB0aGF0 IGZ1bmN0aW9uLg0KSSB0aGluayBpdOKAmXMgcHJldHR5IG9idmlvdXMuIEkganVzdCB3YW50IHRv IHBvaW50IG91dCB0aGF0IGluIG91ciB0aGlua2luZyB0aGVyZSBpcyBpbmZyYXN0cnVjdHVyZSBh bmQgYXV0b25vbWljIHNlcnZpY2UgYWdlbnRzLiBBbiDigJxhdXRvbm9taWNhbGx5IGF3YXJl4oCd IG5vZGUgTVVTVCBoYXZlIHRoZSBBTiBpbmZyYXN0cnVjdHVyZSwgYW5kIE1BWSBoYXZlIGF1dG9u b21pYyBzZXJ2aWNlIGFnZW50cy4NCg0KQlRXLCBhbiDigJxhdXRvbm9taWNhbGx5IHVuYXdhcmXi gJ0gbm9kZSBpcyBub3QganVzdCBhIGR1bWIgcm9jayBsaWtlIGEgaHViLiBBbHNvIHRyYWRpdGlv bmFsIGRldmljZXMgKGUuZy4gcm91dGVycykgd2hpY2ggZG8gbm90IHN1cHBvcnQgdGhlIEFOIGlu ZnJhc3RydWN0dXJlIGZhbGwgaW50byB0aGF0IGNhdGVnb3J5Lg0KDQpUaGVuLCBJIGNvdWxkIHNh eSB0aGF0IGFuIGF1dG9ub21pYyBmdW5jdGlvbiBpcyBlaXRoZXIgYmUgc3VwcG9ydGVkIGRpcmVj dGx5IGJ5IGEgZnVsbHkgYXV0b25vbWljIG5vZGUsIG9yIGJ1aWx0IGZyb20gYSBzZXQgb2Ygbm9k ZXMgKHNvbWUgb2Ygd2hpY2ggYXJlIG5vdCBjYXBhYmxlIG9mIHBlcmZvcm1pbmcgYXV0b25vbWlj IGZ1bmN0aW9ucykuDQoNCk1COiBJIHRoaW5rIHdoZW4geW91IHNheSDigJxhdXRvbm9taWMgZnVu Y3Rpb27igJ0geW91IG1lYW4gYSBmdW5jdGlvbiBhY3Jvc3MgdmFyaW91cyBub2RlcywgcmlnaHQ/ IEluIG91ciB3b3JkaW5nLCBhIG5vZGUgcnVucyBhbiBhdXRvbm9taWMgc2VydmljZSBhZ2VudC4g QSBncm91cCBvZiBzdWNoIG5vZGVzIGltcGxlbWVudCBhbiBhdXRvbm9taWMgZnVuY3Rpb24uDQoN ClNlY29uZCBxdWVzdGlvbjogcGVyZm9ybWluZyBhbiBhdXRvbm9taWMgZnVuY3Rpb24gaXMgYSBz ZXQgb2YgYmVoYXZpb3JzLiBXaGF0J3MgaW1wb3J0YW50IGlzIHRoZSBlbmQgcmVzdWx0LCBub3Qg dGhlIGluZGl2aWR1YWwgYmVoYXZpb3JzLiBTbywgYXMgbG9uZyBhcyBlYWNoIGluZGl2aWR1YWwg YmVoYXZpb3IgY2FuIGJlIHJpZ29yb3VzbHkgZGVmaW5lZCAoZS5nLiwgdXNpbmcgYSBzb2Z0d2Fy ZSBjb250cmFjdCwgd2hlcmUgdGhlIGJlaGF2aW9yIHNhdGlzZmllcyBhIHNldCBvZiBwcmUtIGFu ZCBwb3N0LWNvbmRpdGlvbnMgYXMgd2VsbCBhcyBhIHNldCBvZiBpbnZhcmlhbnRzKSwgdGhlbiAo aW4gdGhlb3J5KSB0aGV5IHNob3VsZCBiZSBhYmxlIHRvIGJlIGNvbXBvc2l0ZWQgdG9nZXRoZXIu DQoNCldoYXTigJlzIHRoZSBxdWVzdGlvbj8gOy0pICAgWWVzLCBJIGFncmVlLiBUaGUgQXV0b25v bWljIENvbnRyb2wgUGxhbmUgaXMgYW4gZXhhbXBsZSBvZiB0aGlzLiBFYWNoIG5vZGVzIGNhcnJp ZXMgb3V0IGEgZmV3IGxvY2FsIGFjdGlvbnMgKGF1dGhlbnRpY2F0aW5nIG5laWdoYm9ycywgYnVp bGRpbmcgdHVubmVscyB0byB0aGVtLCBldGMpLCBhbmQgdGhlIG5ldCByZXN1bHQgaXMgYSBzZWxm LW1hbmFnaW5nIG92ZXJsYXkgbmV0d29yayB3aXRoIHNvbWUgbmljZSBwcm9wZXJ0aWVzLg0KDQpU aGFua3MgZm9yIHlvdXIgaW5wdXQgYW5kIHZhbGlkYXRpb24gb2Ygb3VyIHdvcmshDQpNaWNoYWVs DQoNCg0KVGhvdWdodHM/DQoNCg0KYmVzdCByZWdhcmRzLA0KSm9obg0KDQoNCg0KT24gV2VkLCBN YXIgMTEsIDIwMTUgYXQgMzo0MiBBTSwgTWljaGFlbCBCZWhyaW5nZXIgKG1iZWhyaW5nKSA8bWJl aHJpbmdAY2lzY28uY29tPG1haWx0bzptYmVocmluZ0BjaXNjby5jb20+PiB3cm90ZToNCkpvaG4s DQoNCkFkZGluZyB0byBCcmlhbi9TaGVuZyBteSB2aWV3LCB0aGVyZSBhcmUgdHdvIGltcG9ydGFu dCBwb2ludHMgdG8gbm90ZToNCg0KMSkgV2hhdCB5b3Ugc2VlIG5vdyBpcyBqdXN0IHRoZSBzdGFy dC4gSW4gdGhpcyBmaXJzdCBwaGFzZSB3ZSdyZSBub3QgYWN0dWFsbHkgc3RhbmRhcmRpc2luZyBh bnkgYXV0b25vbWljIHNlcnZpY2UgYWdlbnRzIChhcyB3ZSBjYWxsIHRoZW0pLCBidXQgd2UncmUg cHJlcGFyaW5nIGFuIGluZnJhc3RydWN0dXJlIGZvciBzdWNoIGFnZW50cy4gTWVhbmluZywgc3Vj aCBhZ2VudHMgY2FuIGNvdW50IG9uIGFsbCB0aGUgIm1lY2hhbmljcyIgdG8gdGFsayB0byBvdGhl ciBhZ2VudHM6IEFkZHJlc3NpbmcsIHJvdXRpbmcsIHNlY3VyaXR5LCBzaW1wbGUgZGlzY292ZXJ5 LCBuZWdvdGlhdGlvbiwgZXRjLiBXZSBjYWxsIHRoaXMgdGhlIGF1dG9ub21pYyBuZXR3b3JraW5n IGluZnJhc3RydWN0dXJlLCBhbmQgb3VyIGdvYWwgaXMgdG8gbWFrZSB0aGlzIGluZnJhc3RydWN0 dXJlICJzZWxmLW1hbmFnaW5nIiBpdHNlbGYsIHNwZWNpZmljYWxseSwgaXQgc2hvdWxkIHNlbGYt Y29uZmlndXJlLg0KDQpUaGlzIGluZnJhc3RydWN0dXJlIGlzIG5vdCBjb21wbGV0ZSwgYXMgeW91 IGNvcnJlY3RseSBwb2ludCBvdXQuIEJ1dCBhbGwgb2YgdGhlIGZ1bmN0aW9ucyB5b3UgbWVudGlv biAoZS5nLiwga25vd2xlZGdlIGV4Y2hhbmdlKSBmaXJzdCBvZiBhbGwgcmVxdWlyZSBhIHNvbGlk IGNvbW11bmljYXRpb25zIGluZnJhc3RydWN0dXJlLg0KDQpJbiB0aGUgV0cgY2hhcnRlciB5b3Ug c2VlIHRoZSBlbGVtZW50cyBvZiB0aGUgaW5mcmFzdHJ1Y3R1cmUsIGFuZCBhIGNvdXBsZSBvZiB1 c2UgY2FzZXMgZm9yIGF1dG9ub21pYyBzZXJ2aWNlIGFnZW50cy4gSW4gdGhpcyBmaXJzdCBwaGFz ZSB0aGUgaW50ZW50aW9uIGlzIHRvIHZhbGlkYXRlIHRoZSBhdXRvbm9taWMgbmV0d29ya2luZyBp bmZyYXN0cnVjdHVyZSB3aXRoIHRob3NlIHVzZSBjYXNlcy4gU2VlIGFsc28gdGhlIFVDQU4gQm9G IG5vdGVzLCB3aGVyZSBtb3JlIHVzZSBjYXNlcyB3ZXJlIGRpc2N1c3NlZC4gQWdhaW4sIHdlJ3Jl IGxvb2tpbmcgYXQgc2ltcGxlIHVzZSBjYXNlcyB0byBzdGFydCB3aXRoLCBhbmQgd29yayBib3R0 b20tdXAuDQoNCjIpIFdlIGFyZSBub3QgdHJ5aW5nIHRvIGRlZmluZSBmdWxseSBhdXRvbm9taWMg bm9kZXMsIGJ1dCBhdXRvbm9taWMgZnVuY3Rpb25zLiBJbiBvdGhlciB3b3Jkcywgd2UgZXhwZWN0 IG5vZGVzIHRvIGJlIHBhcnRpYWxseSBtYW5hZ2VkIGluIHRoZSB0cmFkaXRpb25hbCB3YXksIGFu ZCBzb21lIGZ1bmN0aW9ucyB0byBiZSBhdXRvbm9taWMuIEluIHRoZSBmdXR1cmUgdGhlcmUgbWF5 IGJlIGNhc2VzIG9mIGZ1bGx5IGF1dG9ub21pYyBub2Rlcy4NCg0KQXMgd2UgdGFrZSBvbiBuZXcg dXNlIGNhc2VzLCB3ZSBkZWZpbmUgdGhlaXIgcmVxdWlyZW1lbnRzLCBhbmQgYWRkcmVzcyB0aGUg ZGVsdGEgaW4gdGhlIGF1dG9ub21pYyBuZXR3b3JraW5nIGluZnJhc3RydWN0dXJlLCBib3R0b20g dXAuIFdpdGggdGhlIHJlZmVyZW5jZSBtb2RlbCB3ZSBuZWVkIHRvIG1ha2Ugc3VyZSB0aGF0IHdl J3JlIG5vdCBnb2luZyBkb3duIGEgdHJhY2sgdGhhdCB3aWxsIG1ha2UgZnV0dXJlIHVzZSBjYXNl cyBpbXBvc3NpYmxlIG9yIGhhcmQgdG8gc3VwcG9ydC4gVGhpcyBpcyBvZiBjb3Vyc2UgdGhlIG1h aW4gY2hhbGxlbmdlLiBZb3VyIGlucHV0IHdvdWxkIGJlIHZlcnkgdmFsdWFibGUgaW4gdGhpcyBw cm9jZXNzLg0KDQpXaGF0IGFyZSB5b3VyIHRob3VnaHRzPw0KDQpNaWNoYWVsDQoNCg0KPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBbmltYSBbbWFpbHRvOmFuaW1hLWJvdW5j ZXNAaWV0Zi5vcmc8bWFpbHRvOmFuaW1hLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2Yg QnJpYW4gRQ0KPiBDYXJwZW50ZXINCj4gU2VudDogMTAgTWFyY2ggMjAxNSAwNDo0MQ0KPiBUbzog Sm9obiBTdHJhc3NuZXINCj4gQ2M6IExpdWJpbmcgKExlbyk7IEFuaW1hIFdHOyBzdHJhenBkakBn bWFpbC5jb208bWFpbHRvOnN0cmF6cGRqQGdtYWlsLmNvbT4NCj4gU3ViamVjdDogUmU6IFtBbmlt YV0gU29tZSBjb21tZW50cyBmb3IgZHJhZnQtY2FycGVudGVyLWFuaW1hLWdkbi0NCj4gcHJvdG9j b2wNCj4NCj4gSGkgSm9obiBhbmQgZXZlcnlib2R5LA0KPg0KPiBSZXBseWluZyB0byBzb21lIGNv bW1lbnRzIHJlY2VpdmVkIHByaXZhdGVseSwgb24gdGhlIGxpc3Qgd2l0aCBwZXJtaXNzaW9uOg0K PiBPbiAwOS8wMy8yMDE1IDIyOjU1LCBTaGVuZyBKaWFuZyB3cm90ZToNCj4gPiBIaSwgYXV0aG9y cyBvZiBkcmFmdC1jYXJwZW50ZXItYW5pbWEtZ2RuLXByb3RvY29sDQo+ID4NCj4gPiBUaGUgYmVs b3cgYXJlIHNvbWUgY29tbWVudHMgZnJvbSBteSBjb2xsZWFndWUsIERyLiBKb2huIFN0cmFzc25l ci4NCj4gQWx0aG91Z2ggSSBwZXJzb25hbGx5IHRoaW5rIHlvdXIgcHJvdG9jb2wgZGVzaWducyBo YXZlIHRoZSBhYmlsaXR5IHRvIG1lZXQNCj4gaGlzIHJlcXVpcmVtZW50cyBmb3Iga25vd2xlZGdl IGV4Y2hhbmdpbmcgYW1vbmcgYXV0b25vbWljIG5vZGVzLCBpdCBpcw0KPiBiZXR0ZXIgeW91IGNv dWxkIGRpc2N1c3MgZGlyZWN0bHkgYW5kIG1heWJlIGluY2x1ZGUgc29tZQ0KPiBtb2RpZmljYXRp b24vY2xhcmlmaWNhdGlvbiBpbiB0aGUgZnV0dXJlIHZlcnNpb24uIEkgYWxzbyBlbmNvdXJhZ2Ug eW91IHRvDQo+IGRpc2N1c3MgdGhpcyBpbiBBTklNQSBtYWlsIGxpc3Qgb3Blbmx5Lg0KPiA+DQo+ ID4gQmVzdCByZWdhcmRzLA0KPiA+DQo+ID4gU2hlbmcNCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBKb2huIFN0cmFzc25lcg0KPiA+PiBTZW50OiBGcmlk YXksIE1hcmNoIDA2LCAyMDE1IDY6NDMgQU0NCj4gPj4gVG86IFNoZW5nIEppYW5nOyBKb2huIFN0 cmFzc25lcg0KPiA+Pg0KPiA+PiBEZWFyIFNoZW5nLA0KPiA+Pg0KPiA+PiBJIHJlYWQgdGhlIGNo YXJ0ZXIgYW5kIGFtIHN0YXJ0aW5nIG9uIHRoZSBkcmFmdHMuDQo+ID4+DQo+ID4+Pj4gYXV0b25v bWljcyByZXF1aXJlIHRoZSBhYmlsaXR5IHRvIHNoYXJlIGFuZCBleGNoYW5nZSBrbm93bGVkZ2Ug aW4NCj4gPj4+PiBhbiBpbnRlcm9wZXJhYmxlIGZhc2hpb24uIEkgZmFpbCB0byBzZWUgaG93IHRo aXMgaXMgZXZlbiBkaXNjdXNzZWQNCj4gPj4+PiBpbiBBTklNQS4NCj4gPj4+DQo+ID4+PiBCVFcs IHRoZSBhYmlsaXR5IHRvIHNoYXJlIGFuZCBleGNoYW5nZSBrbm93bGVkZ2UgaW4gYW4gaW50ZXJv cGVyYWJsZQ0KPiA+Pj4gZmFzaGlvbiBsb29rcyBsaWtlIEdORFAgKEdlbmVyaWMgRGlzY292ZXJ5 IGFuZCBOZWdvdGlhdGlvbiBQcm90b2NvbCkNCj4gPj4+IGluIEFOSU1BLiBUaGlzIHByb3RvY29s IGlzIGRlc2lnbmVkIHRvIHN1cHBvcnQgaW5mb3JtYXRpb24gZGlzY292ZXJ5DQo+ID4+PiBhbmQg YmktZGlyZWN0aW9uIG5lZ290aWF0aW9uLg0KPiA+Pg0KPiA+PiBJdCBhcHBlYXJzIHRoYXQgR0RO UCBjb3ZlcnMgc29tZSwgYnV0IG5vdCBhbGwsIG9mIHdoYXQgSSBhbSB0YWxraW5nIGFib3V0Lg0K Pg0KPiBJbmRlZWQsIGl0IGlzbid0IGNsYWltaW5nIHRvIGNvdmVyIGV2ZXJ5dGhpbmcuIFRoZSBp ZGVhIGlzIHRoYXQgZHJhZnQtDQo+IGJlaHJpbmdlci1hbmltYS1yZWZlcmVuY2UtbW9kZWwgd2ls bCBldm9sdmUgdG8gc2hvdyBob3cgdGhpbmdzIGZpdA0KPiB0b2dldGhlciwgd2hpY2ggd2lsbCBo ZWxwIHVzIHRvIGlkZW50aWZ5IGhvbGVzLg0KPg0KPiA+PiBIb3dldmVyLCB0aGUgZm9sbG93aW5n IHN0YXRlbWVudCBmcm9tIHRoZSBHRE5QIGRyYWZ0IGlzIG1pc2xlYWRpbmcsDQo+ID4+IGlmIG5v dCBqdXN0IHBsYWluIHdyb25nOg0KPiA+Pg0KPiA+PiAiSW4gb3JkZXIgdG8gZnVsZmlsIGF1dG9u b215LCBkZXZpY2VzIHRoYXQgZW1ib2R5IGF1dG9ub21pYyBzZXJ2aWNlDQo+ID4+IGFnZW50cyBu ZWVkIHRvIGJlIGFibGUgdG8gZGlzY292ZXIgZWFjaCBvdGhlciwgdG8gc3luY2hyb25pemUgc3Rh dGUNCj4gPj4gd2l0aCBlYWNoIG90aGVyLCBhbmQgdG8gbmVnb3RpYXRlIHBhcmFtZXRlcnMgYW5k IHJlc291cmNlcyBkaXJlY3RseQ0KPiA+PiB3aXRoIGVhY2ggb3RoZXIuIg0KPiA+Pg0KPiA+PiBG aXJzdCwgYXV0b25vbWljIG5ldHdvcmtzIGFyZSBub3QgbmVjZXNzYXJpbHkgYXV0b25vbW91cy4g QXV0b25vbXksDQo+ID4+IGluIGl0cyBtb3N0IGdlbmVyaWMgZm9ybSwgaXMgdGhlIGFiaWxpdHkg dG8gaGF2ZSB0aGUgcG93ZXIgZm9yIGFuDQo+ID4+IGVudGl0eSB0byBnb3Zlcm4gaXRzZWxmLiBJ ZiBldmVyeSBuZXR3b3JrIGVsZW1lbnQgZ292ZXJucyBpdHNlbGYNCj4gPj4gd2l0aG91dCByZWdh cmQgdG8gb3RoZXIsIGhpZ2hlciBsZXZlbCBwcmluY2lwbGVzLCB5b3UgZG9uJ3QgZXZlbiBoYXZl DQo+ID4+IGEgbmV0d29yay4gOi0pDQo+DQo+IFN1cmUuIFRoYXQgaXMgdGhlIHJvbGUgZm9yIHdo YXQgd2UgY2FsbCAiaW50ZW50IiB3aGljaCBpcyBkZWZpbmVkIGluIGRyYWZ0LWlydGYtDQo+IG5t cmctYXV0b25vbWljLW5ldHdvcmstZGVmaW5pdGlvbnMgYnV0IGlzIG5vdCB5ZXQgaW4gQW5pbWEg c2NvcGUuDQo+DQo+ID4+IFNlY29uZCwgdGhlIHRocmVlIGNvbmNlcHRzIG1lbnRpb25lZCBpbiB0 aGUgYWJvdmUgZXhjZXJwdA0KPiA+PiAoZGlzY292ZXJhYmlsaXR5LCBzeW5jaHJvbml6YXRpb24g b2Ygc3RhdGUsIGFuZCBwYXJhbWV0ZXINCj4gPj4gbmVnb3RpYXRpb24pIGFyZSBuZWNlc3Nhcnkg YnV0IGNsZWFybHkgbm90IHN1ZmZpY2llbnQgdG8gaGF2ZQ0KPiA+PiBhdXRvbm9taWMgb3BlcmF0 aW9uLiBJIHdhcyB0YWxraW5nIGFib3V0IHRoZSBhYmlsaXR5IHRvIGV4Y2hhbmdlDQo+ID4+IGtu b3dsZWRnZSAoZS5nLiwgYWxsIG9yIHBhcnQgb2YgYW4gaW5mb3JtYXRpb24gbW9kZWwpIGJldHdl ZW4NCj4gPj4gZW50aXRpZXMuIEl0IGRvZXNuJ3QgYXBwZWFyIHRoYXQgdGhpcyBpcyBjb3ZlcmVk IGluIEFOSU1BIHlldCwgdGhvdWdoIEkNCj4gaGF2ZW4ndCByZWFkIGFsbCBvZiB0aGUgbWF0ZXJp YWxzLg0KPg0KPiBNeSBwZXJzb25hbCB2aWV3IGlzIHRoYXQgdGhpcyBpcyBnb2luZyB0byBiZSBy ZXNvbHZlZCB0b3BpYyBieSB0b3BpYy4NCj4gSW4gR0ROUC1zcGVhayB0aGF0IG1lYW5zIHRoYXQg aXQgd2lsbCBiZSByZXNvbHZlZCBieSBpbmRpdmlkdWFsIE9iamVjdGl2ZQ0KPiBkZWZpbml0aW9u cywgYW5kIEdETlAgd2lsbCBqdXN0IGFjdCBhcyBhIG5ldXRyYWwgY2Fycmllci4gKFlvdSBjYW4g cXVpdGUgZmFpcmx5DQo+IGFyZ3VlIHRoYXQgdGhpcyBtZWFucyB3ZSBhcmUgZHVja2luZyB0aGUg cHJvYmxlbSBmb3Igbm93LikgQW5vdGhlciB3YXkgdG8NCj4gc2F5IHRoaXMgaXMgdGhhdCBlYWNo IHR5cGUgb2YgYXV0b25vbW91cyBzZXJ2aWNlIGFnZW50IHdpbGwgc29sdmUgdGhpcw0KPiBwcm9i bGVtIGZvciBpdHMgb3duIHRhcmdldCBwYXJhbWV0ZXJzLg0KPg0KPiBOb3csIGFnYWluIElNSE8s IHRoaXMgaXMgd2h5IHdlIHN0YXRlIGluIEdETlAgdGhhdCB0aGUgZm9ybWF0IG9mIHRoZSB2YWx1 ZQ0KPiBvZiBhbiBvYmplY3RpdmUgIi4uLm1pZ2h0IGJlIGluaGVyaXRlZCBmcm9tIGFuIGV4aXN0 aW5nIG1hbmFnZW1lbnQgb3INCj4gY29uZmlndXJhdGlvbiBwcm90b2NvbCwgdGhlIG9iamVjdGl2 ZSBvcHRpb24gYWN0aW5nIGFzIGEgY2FycmllciBmb3IgdGhhdA0KPiBmb3JtYXQuICBUaGUgZGF0 YSBzdHJ1Y3R1cmUgbWlnaHQgYmUgZGVmaW5lZCBpbiBhIGZvcm1hbCBsYW5ndWFnZSwgYnV0IHRo YXQNCj4gaXMgYSBtYXR0ZXIgZm9yIHRoZSBzcGVjaWZpY2F0aW9ucyBvZiBpbmRpdmlkdWFsIG9i amVjdGl2ZXMuICBUaGVyZSBhcmUgbWFueQ0KPiBjYW5kaWRhdGVzLCBhY2NvcmRpbmcgdG8gdGhl IGNvbnRleHQsIHN1Y2ggYXMgQUJORiwgUkJORiwgWE1MIFNjaGVtYSwNCj4gcG9zc2libHkgWUFO RywgZXRjLiAgVGhlIEdETlAgcHJvdG9jb2wgaXRzZWxmIGlzIGFnbm9zdGljIG9uIHRoZXNlDQo+ IHF1ZXN0aW9ucy4iDQo+DQo+IE15IGV4cGVjdGF0aW9uIGlzIHRoYXQgc29tZSBvYmplY3RpdmVz IHdpbGwgbmVlZCBhIGZvcm1hbCBpbmZvcm1hdGlvbg0KPiBtb2RlbCBhbmQgdGhhdCBvdGhlcnMg d29uJ3QsIGFuZCB0aGF0IHRoZXJlJ3Mgbm8gcmVhc29uIHdlIGNvdWxkbid0IGluaGVyaXQNCj4g ZXhpc3RpbmcgSU1zIHdoZW4gdGhleSBhcmUgcmVsZXZhbnQuIEJ1dCB0aGF0IHdob2xlIHF1ZXN0 aW9uIGlzIGFsc28gb3V0IG9mDQo+IGNoYXJ0ZXIgc2NvcGUgZm9yIG5vdy4gQXMgeW91IGtub3cg YmV0dGVyIHRoYW4gbW9zdCBwZW9wbGUsIEpvaG4sIGRlZmluaW5nDQo+IGFuIElNIGNhbiBiZWNv bWUgYSB2ZXJ5IGxhYm9yaW91cyBidXNpbmVzcyBhbmQgZm9yIG5vdyB3ZSB3YW50IHRvIGdldA0K PiBzdGFydGVkIG9uIHNpbXBsZSBjYXNlcyB0aGF0IGRvbid0IG5lZWQgaXQuDQo+DQo+ID4+IElm IHlvdSBjYW5ub3QgZXhjaGFuZ2Uga25vd2xlZGdlLCB5b3Ugd2lsbCBuZXZlciBiZSBhdXRvbm9t aWMgaW4gdGhlDQo+ID4+IGNvbXB1dGVyIHNjaWVuY2Ugc2Vuc2UuDQo+DQo+IFlvdSB3aWxsIGZp bmQgdmVyeSBzaW1pbGFyIHdvcmRzIGluIGRyYWZ0LWlydGYtbm1yZy1hbi1nYXAtYW5hbHlzaXMu DQo+DQo+IDxzbmlwPg0KPg0KPiBSZWdhcmRzDQo+ICAgICBCcmlhbg0KPg0KPiA+PiByZWdhcmRz LA0KPiA+PiBKb2huDQo+ID4+DQo+ID4+IERyLiBKb2huIFN0cmFzc25lciwgUGguRC4NCj4gPj4g Q1RPLCBTb2Z0d2FyZSBMYWJvcmF0b3J5LCBDUkQNCj4gPj4NCj4gPj4NCj4gPj4gRnV0dXJld2Vp IFRlY2hub2xvZ2llcw0KPiA+PiBVUyBSJkQgQ2VudGVyDQo+ID4+IDIzMzAgQ2VudHJhbCBFeHBy ZXNzd2F5DQo+ID4+IEJ1aWxkaW5nIEEsIG9mZmljZSBBMi0yMTQzDQo+ID4+IFNhbnRhIENsYXJh LCBDYWxpZm9ybmlhICAgOTUwNTANCj4gPj4gIE9mZmljZTogICsxLjQwOC4zMzAuNDkyMw0KPiA+ PiAgRW1haWw6ICAgam9obi5zYy5zdHJhc3NuZXJAaHVhd2VpLmNvbTxtYWlsdG86am9obi5zYy5z dHJhc3NuZXJAaHVhd2VpLmNvbT4NCj4gPj4NCj4gPj4NCj4gPj4gQmVzdCByZWdhcmRzLA0KPiA+ Pg0KPiA+PiBTaGVuZw0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBBbmltYSBtYWlsaW5nIGxpc3QNCj4gQW5pbWFAaWV0Zi5vcmc8bWFpbHRv OkFuaW1hQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2FuaW1hDQoNCg0KDQotLQ0KcmVnYXJkcywNCkpvaG4NCg== --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22EF15FAxmbrcdx14ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQ YXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1h cmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0 Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBw dCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTI1NzA1 MzQ3MTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTcx OTgwMDgwNiAxMzQ4MDc1NzUgMTM0ODA3NTc3IDEzNDgwNzU3OSAxMzQ4MDc1NjcgMTM0ODA3NTc3 IDEzNDgwNzU3OSAxMzQ4MDc1NjcgMTM0ODA3NTc3IDEzNDgwNzU3OTt9DQpAbGlzdCBsMDpsZXZl bDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRl eHQ6IiUxXCkiOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsMg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9t YW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJ e21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpA bGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdo dDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZl bDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWlu ZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTI4MDA2NzE1ODsNCgltc28t bGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTA4OTY2NTE4OCAxMzQ4 MDc1NzUgMTM0ODA3NTc3IDEzNDgwNzU3OSAxMzQ4MDc1NjcgMTM0ODA3NTc3IDEzNDgwNzU3OSAx MzQ4MDc1NjcgMTM0ODA3NTc3IDEzNDgwNzU3OTt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRleHQ6IiUxXCkiOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpA bGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdo dDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZl bDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWlu ZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 O30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7 fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250 IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW5saW5l4oCmLjxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFm NDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxmb250IHNpemU9IjIiIGZhY2U9IlRhaG9tYSI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2ZvbnQtd2VpZ2h0OmJvbGQiPkZyb206PC9zcGFuPjwv Zm9udD48L2I+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iVGFob21hIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KIEpvaG4gU3RyYXNzbmVyIFttYWlsdG86c3RyYXpwZGpA Z21haWwuY29tXSA8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U2VudDo8 L3NwYW4+PC9iPiAxMiBNYXJjaCAyMDE1IDAyOjIzPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQt d2VpZ2h0OmJvbGQiPlRvOjwvc3Bhbj48L2I+IE1pY2hhZWwgQmVocmluZ2VyIChtYmVocmluZyk7 IEpvaG4gU3RyYXNzbmVyPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNj Ojwvc3Bhbj48L2I+IEJyaWFuIEUgQ2FycGVudGVyOyBKb2huIFN0cmFzc25lcjsgTGl1YmluZyAo TGVvKTsgQW5pbWEgV0c8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3Vi amVjdDo8L3NwYW4+PC9iPiBSZTogW0FuaW1hXSBTb21lIGNvbW1lbnRzIGZvciBkcmFmdC1jYXJw ZW50ZXItYW5pbWEtZ2RuLXByb3RvY29sPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij5IYWxsbyBNaWNoYWVsLDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5pdCdz IGJlZW4gYSBsb25nIHRpbWUuIDotKQ0KPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGNvbG9yPSIj MWY0OTdkIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0i Q2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1COiBJ bmRlZWQg4oCTIHRoZSB3b3JsZCBpcyBzbWFsbCENCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0i MiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IldpbmdkaW5ncyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPko8L3NwYW4+PC9m b250Pjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMx ZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+SSB1bmRlcnN0YW5kLCBhbmQgYWdy ZWUsIHdpdGggeW91ciBmaXJzdCBwb2ludC48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQiPlJlZ2FyZGluZyB0aGUgc2Vjb25kIHBvaW50LCBJIHVuZGVyc3Rh bmQgeW91ciBwb2ludCBhYm91dCBmdWxseSBhdXRvbm9taWMgbm9kZXMuIEluIGFkZGl0aW9uLCBJ IHRoaW5rIHRoZSBXRyBzaG91bGQgYmUgY29tbWVuZGVkIGZvciB3b3JyeWluZyBhYm91dCBsZWdh Y3kgZWxlbWVudHMgYW5kDQogcHJvY2Vzc2VzIGZyb20gdGhlIG91dHNldC48bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZv bnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkZpcnN0IHF1ZXN0aW9uOiBjb3Vs ZCBJIGNoYXJhY3Rlcml6ZSB5b3VyIGFwcHJvYWNoIGFzIGhhdmluZyB0aHJlZSB0eXBlcyBvZiBu b2RlczogZnVsbHkgYXV0b25vbWljLCBhdXRvbm9taWNhbGx5LWF3YXJlLCBhbmQgYXV0b25vbWlj YWxseS11bmF3YXJlPyZuYnNwO0FuIGF1dG9ub21pY2FsbHktYXdhcmUNCiBub2RlIGlzIG9uZSB0 aGF0IGZ1bGx5IGF1dG9ub21pYyBub2RlcyBjYW4gY29tbXVuaWNhdGUgd2l0aCwgYW5kIHdoaWNo IHVuZGVyc3RhbmRzIChwZXJoYXBzIGFmdGVyIHRyYW5zbGF0aW9uKSB3aGF0IGZ1bmN0aW9ucyBh cmUgcmVxdWlyZWQgb2YgaXQgYW5kIHdoYXQgZnVuY3Rpb25zIGl0IGNhbiBvZmZlci4gQW4gYXV0 b25vbWljYWxseS11bmF3YXJlIG5vZGUgaXMgYSBkdW1iIHJvY2sgKGUuZy4sIGEgaHViKS48bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGZvbnQgc2l6ZT0iMyIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNp emU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TUI6IFllcywgd2XigJlyZSBlc3NlbnRpYWxseSB0aGlu a2luZyBhbG9uZyB0aGUgc2FtZSBsaW5lcywgYnV0IHBocmFzZSBpdCBkaWZmZXJlbnRseS4gV2Ug YWdyZWUgb24g4oCcZnVsbHkgYXV0b25vbWlj4oCdLA0KIHRoYXTigJlzIHRoZSBlYXN5IG9uZS4g PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250 IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Tm93LCB5b3VyIOKAnGF1dG9ub21pY2FsbHktYXdh cmXigJ0gZGVmaW5pdGlvbiB0cmFuc2xhdGVzIGluIG91ciB3b3JsZCB0byDigJxzdXBwb3J0cyB0 aGUgQXV0b25vbWljIE5ldHdvcmtpbmcgSW5mcmFzdHJ1Y3R1cmXigJ0sDQogd2hpY2ggaXMgZXhh Y3RseSB3aGF0IHdl4oCZcmUgZGVmaW5pbmcgcmlnaHQgbm93IGluIEFOSU1BLiBJIHRoaW5rIHRo aXMgZGVmaW5pdGlvbiBoYXMgdHdvIHN1Yi1mbGF2b3VyczoNCjxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50 Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxm b250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+YSk8Zm9udCBzaXplPSIxIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9mb250Pjwvc3Bhbj48L3NwYW4+PC9mb250PjwhW2VuZGlm XT48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPnRoZSBub2RlIHN1cHBvcnRzIHRoZSBB TiBJbmZyYXN0cnVjdHVyZSAmbmJzcDthbmQgb25lIG9yIHNldmVyYWwgYXV0b25vbWljIHNlcnZp Y2UgYWdlbnRzIChidXQNCiBpcyBub3QgZnVsbHkgYXV0b25vbWljKTxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5k ZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNd Pjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Okln bm9yZSI+Yik8Zm9udCBzaXplPSIxIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxl PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9mb250Pjwvc3Bhbj48L3NwYW4+PC9mb250PjwhW2Vu ZGlmXT48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPnRoZSBub2RlIHN1cHBvcnRzIHRo ZSBBTiBJbmZyYXN0cnVjdHVyZSwgYnV0IG1heSBub3QgYmUgYXdhcmUgb2YgYXV0b25vbWljIHNl cnZpY2UgYWdlbnRzDQogdGhhdCBydW4gb24gb3RoZXIgbm9kZXMuIDxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0i IzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlBvaW50IGEpIGlzIGEgc3Vic2V0IG9mIGIpLiBFeGFtcGxlOiB0b3BvbG9neSBp cyBBLS0tLUItLS0tQy4gQWxsIG5vZGVzIHN1cHBvcnQgdGhlIEFOIGluZnJhc3RydWN0dXJlLiBB IGFuZCBDDQogc2hvdWxkIGJlIGFibGUgdG8gbmVnb3RpYXRlIHBhcmFtZXRlcnMgZm9yIGFuIGF1 dG9ub21pYyBzZXJ2aWNlIGFnZW50cywgZXZlbiBpZiBCIGRvZXNu4oCZdCBpbXBsZW1lbnQgdGhh dCBmdW5jdGlvbi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgdGhpbmsgaXTigJlzIHBy ZXR0eSBvYnZpb3VzLiBJIGp1c3Qgd2FudCB0byBwb2ludCBvdXQgdGhhdCBpbiBvdXIgdGhpbmtp bmcgdGhlcmUgaXMgaW5mcmFzdHJ1Y3R1cmUgYW5kIGF1dG9ub21pYw0KIHNlcnZpY2UgYWdlbnRz LiBBbiDigJxhdXRvbm9taWNhbGx5IGF3YXJl4oCdIG5vZGUgTVVTVCBoYXZlIHRoZSBBTiBpbmZy YXN0cnVjdHVyZSwgYW5kIE1BWSBoYXZlIGF1dG9ub21pYyBzZXJ2aWNlIGFnZW50cy4NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXpl PSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFj ZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJU VywgYW4g4oCcYXV0b25vbWljYWxseSB1bmF3YXJl4oCdIG5vZGUgaXMgbm90IGp1c3QgYSBkdW1i IHJvY2sgbGlrZSBhIGh1Yi4gQWxzbyB0cmFkaXRpb25hbCBkZXZpY2VzIChlLmcuIHJvdXRlcnMp DQogd2hpY2ggZG8gbm90IHN1cHBvcnQgdGhlIEFOIGluZnJhc3RydWN0dXJlIGZhbGwgaW50byB0 aGF0IGNhdGVnb3J5LiA8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+VGhlbiwgSSBjb3VsZCBzYXkgdGhhdCBhbiBhdXRvbm9taWMgZnVuY3Rpb24g aXMgZWl0aGVyIGJlJm5ic3A7c3VwcG9ydGVkIGRpcmVjdGx5IGJ5IGEgZnVsbHkgYXV0b25vbWlj IG5vZGUsIG9yIGJ1aWx0IGZyb20gYSBzZXQgb2YmbmJzcDtub2RlcyAoc29tZSBvZiB3aGljaCBh cmUgbm90Jm5ic3A7Y2FwYWJsZSBvZg0KIHBlcmZvcm1pbmcgYXV0b25vbWljIGZ1bmN0aW9ucyku PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9u dCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1COiBJIHRoaW5rIHdoZW4geW91IHNheSDigJxh dXRvbm9taWMgZnVuY3Rpb27igJ0geW91IG1lYW4gYSBmdW5jdGlvbiBhY3Jvc3MgdmFyaW91cyBu b2RlcywgcmlnaHQ/IEluIG91ciB3b3JkaW5nLA0KIGEgbm9kZSBydW5zIGFuIGF1dG9ub21pYyBz ZXJ2aWNlIGFnZW50LiBBIGdyb3VwIG9mIHN1Y2ggbm9kZXMgaW1wbGVtZW50IGFuIGF1dG9ub21p YyBmdW5jdGlvbi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0Ij5TZWNvbmQgcXVlc3Rpb246IHBlcmZvcm1pbmcgYW4gYXV0b25vbWljIGZ1bmN0 aW9uIGlzIGEgc2V0IG9mIGJlaGF2aW9ycy4gV2hhdCdzIGltcG9ydGFudCBpcyB0aGUgZW5kIHJl c3VsdCwgbm90IHRoZSBpbmRpdmlkdWFsIGJlaGF2aW9ycy4gU28sIGFzIGxvbmcgYXMgZWFjaCBp bmRpdmlkdWFsDQogYmVoYXZpb3IgY2FuIGJlIHJpZ29yb3VzbHkgZGVmaW5lZCAoZS5nLiwgdXNp bmcgYSBzb2Z0d2FyZSBjb250cmFjdCwgd2hlcmUgdGhlIGJlaGF2aW9yIHNhdGlzZmllcyBhIHNl dCBvZiBwcmUtIGFuZCBwb3N0LWNvbmRpdGlvbnMgYXMgd2VsbCBhcyBhIHNldCBvZiBpbnZhcmlh bnRzKSwgdGhlbiAoaW4gdGhlb3J5KSB0aGV5IHNob3VsZCBiZSBhYmxlIHRvIGJlIGNvbXBvc2l0 ZWQgdG9nZXRoZXIuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGNvbG9yPSIjMWY0OTdkIiBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldoYXTigJlzIHRoZSBxdWVz dGlvbj8gOy0pJm5ic3A7Jm5ic3A7IFllcywgSSBhZ3JlZS4gVGhlIEF1dG9ub21pYyBDb250cm9s IFBsYW5lIGlzIGFuIGV4YW1wbGUgb2YgdGhpcy4gRWFjaCBub2RlcyBjYXJyaWVzDQogb3V0IGEg ZmV3IGxvY2FsIGFjdGlvbnMgKGF1dGhlbnRpY2F0aW5nIG5laWdoYm9ycywgYnVpbGRpbmcgdHVu bmVscyB0byB0aGVtLCBldGMpLCBhbmQgdGhlIG5ldCByZXN1bHQgaXMgYSBzZWxmLW1hbmFnaW5n IG92ZXJsYXkgbmV0d29yayB3aXRoIHNvbWUgbmljZSBwcm9wZXJ0aWVzLg0KPG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNv bG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxp YnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIGZv ciB5b3VyIGlucHV0IGFuZCB2YWxpZGF0aW9uIG9mIG91ciB3b3JrITxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0i IzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPk1pY2hhZWw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmki PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0i MiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+VGhvdWdodHM/ PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+YmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u dD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIz IiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5K b2huPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPk9uIFdl ZCwgTWFyIDExLCAyMDE1IGF0IDM6NDIgQU0sIE1pY2hhZWwgQmVocmluZ2VyIChtYmVocmluZykg Jmx0OzxhIGhyZWY9Im1haWx0bzptYmVocmluZ0BjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5t YmVocmluZ0BjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Sm9obiw8YnI+DQo8YnI+DQpB ZGRpbmcgdG8gQnJpYW4vU2hlbmcgbXkgdmlldywgdGhlcmUgYXJlIHR3byBpbXBvcnRhbnQgcG9p bnRzIHRvIG5vdGU6PGJyPg0KPGJyPg0KMSkgV2hhdCB5b3Ugc2VlIG5vdyBpcyBqdXN0IHRoZSBz dGFydC4gSW4gdGhpcyBmaXJzdCBwaGFzZSB3ZSdyZSBub3QgYWN0dWFsbHkgc3RhbmRhcmRpc2lu ZyBhbnkgYXV0b25vbWljIHNlcnZpY2UgYWdlbnRzIChhcyB3ZSBjYWxsIHRoZW0pLCBidXQgd2Un cmUgcHJlcGFyaW5nIGFuIGluZnJhc3RydWN0dXJlIGZvciBzdWNoIGFnZW50cy4gTWVhbmluZywg c3VjaCBhZ2VudHMgY2FuIGNvdW50IG9uIGFsbCB0aGUgJnF1b3Q7bWVjaGFuaWNzJnF1b3Q7IHRv IHRhbGsNCiB0byBvdGhlciBhZ2VudHM6IEFkZHJlc3NpbmcsIHJvdXRpbmcsIHNlY3VyaXR5LCBz aW1wbGUgZGlzY292ZXJ5LCBuZWdvdGlhdGlvbiwgZXRjLiBXZSBjYWxsIHRoaXMgdGhlIGF1dG9u b21pYyBuZXR3b3JraW5nIGluZnJhc3RydWN0dXJlLCBhbmQgb3VyIGdvYWwgaXMgdG8gbWFrZSB0 aGlzIGluZnJhc3RydWN0dXJlICZxdW90O3NlbGYtbWFuYWdpbmcmcXVvdDsgaXRzZWxmLCBzcGVj aWZpY2FsbHksIGl0IHNob3VsZCBzZWxmLWNvbmZpZ3VyZS48YnI+DQo8YnI+DQpUaGlzIGluZnJh c3RydWN0dXJlIGlzIG5vdCBjb21wbGV0ZSwgYXMgeW91IGNvcnJlY3RseSBwb2ludCBvdXQuIEJ1 dCBhbGwgb2YgdGhlIGZ1bmN0aW9ucyB5b3UgbWVudGlvbiAoZS5nLiwga25vd2xlZGdlIGV4Y2hh bmdlKSBmaXJzdCBvZiBhbGwgcmVxdWlyZSBhIHNvbGlkIGNvbW11bmljYXRpb25zIGluZnJhc3Ry dWN0dXJlLjxicj4NCjxicj4NCkluIHRoZSBXRyBjaGFydGVyIHlvdSBzZWUgdGhlIGVsZW1lbnRz IG9mIHRoZSBpbmZyYXN0cnVjdHVyZSwgYW5kIGEgY291cGxlIG9mIHVzZSBjYXNlcyBmb3IgYXV0 b25vbWljIHNlcnZpY2UgYWdlbnRzLiBJbiB0aGlzIGZpcnN0IHBoYXNlIHRoZSBpbnRlbnRpb24g aXMgdG8gdmFsaWRhdGUgdGhlIGF1dG9ub21pYyBuZXR3b3JraW5nIGluZnJhc3RydWN0dXJlIHdp dGggdGhvc2UgdXNlIGNhc2VzLiBTZWUgYWxzbyB0aGUgVUNBTiBCb0Ygbm90ZXMsDQogd2hlcmUg bW9yZSB1c2UgY2FzZXMgd2VyZSBkaXNjdXNzZWQuIEFnYWluLCB3ZSdyZSBsb29raW5nIGF0IHNp bXBsZSB1c2UgY2FzZXMgdG8gc3RhcnQgd2l0aCwgYW5kIHdvcmsgYm90dG9tLXVwLjxicj4NCjxi cj4NCjIpIFdlIGFyZSBub3QgdHJ5aW5nIHRvIGRlZmluZSBmdWxseSBhdXRvbm9taWMgbm9kZXMs IGJ1dCBhdXRvbm9taWMgZnVuY3Rpb25zLiBJbiBvdGhlciB3b3Jkcywgd2UgZXhwZWN0IG5vZGVz IHRvIGJlIHBhcnRpYWxseSBtYW5hZ2VkIGluIHRoZSB0cmFkaXRpb25hbCB3YXksIGFuZCBzb21l IGZ1bmN0aW9ucyB0byBiZSBhdXRvbm9taWMuIEluIHRoZSBmdXR1cmUgdGhlcmUgbWF5IGJlIGNh c2VzIG9mIGZ1bGx5IGF1dG9ub21pYyBub2Rlcy48YnI+DQo8YnI+DQpBcyB3ZSB0YWtlIG9uIG5l dyB1c2UgY2FzZXMsIHdlIGRlZmluZSB0aGVpciByZXF1aXJlbWVudHMsIGFuZCBhZGRyZXNzIHRo ZSBkZWx0YSBpbiB0aGUgYXV0b25vbWljIG5ldHdvcmtpbmcgaW5mcmFzdHJ1Y3R1cmUsIGJvdHRv bSB1cC4gV2l0aCB0aGUgcmVmZXJlbmNlIG1vZGVsIHdlIG5lZWQgdG8gbWFrZSBzdXJlIHRoYXQg d2UncmUgbm90IGdvaW5nIGRvd24gYSB0cmFjayB0aGF0IHdpbGwgbWFrZSBmdXR1cmUgdXNlIGNh c2VzIGltcG9zc2libGUNCiBvciBoYXJkIHRvIHN1cHBvcnQuIFRoaXMgaXMgb2YgY291cnNlIHRo ZSBtYWluIGNoYWxsZW5nZS4gWW91ciBpbnB1dCB3b3VsZCBiZSB2ZXJ5IHZhbHVhYmxlIGluIHRo aXMgcHJvY2Vzcy48YnI+DQo8YnI+DQpXaGF0IGFyZSB5b3VyIHRob3VnaHRzPzxicj4NCjxicj4N Ck1pY2hhZWw8YnI+DQo8YnI+DQo8YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t PGJyPg0KJmd0OyBGcm9tOiBBbmltYSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzphbmltYS1ib3Vu Y2VzQGlldGYub3JnIj5hbmltYS1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIEJy aWFuIEU8YnI+DQomZ3Q7IENhcnBlbnRlcjxicj4NCiZndDsgU2VudDogMTAgTWFyY2ggMjAxNSAw NDo0MTxicj4NCiZndDsgVG86IEpvaG4gU3RyYXNzbmVyPGJyPg0KJmd0OyBDYzogTGl1YmluZyAo TGVvKTsgQW5pbWEgV0c7IDxhIGhyZWY9Im1haWx0bzpzdHJhenBkakBnbWFpbC5jb20iPnN0cmF6 cGRqQGdtYWlsLmNvbTwvYT48YnI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBbQW5pbWFdIFNvbWUgY29t bWVudHMgZm9yIGRyYWZ0LWNhcnBlbnRlci1hbmltYS1nZG4tPGJyPg0KJmd0OyBwcm90b2NvbDxi cj4NCiZndDs8YnI+DQomZ3Q7IEhpIEpvaG4gYW5kIGV2ZXJ5Ym9keSw8YnI+DQomZ3Q7PGJyPg0K Jmd0OyBSZXBseWluZyB0byBzb21lIGNvbW1lbnRzIHJlY2VpdmVkIHByaXZhdGVseSwgb24gdGhl IGxpc3Qgd2l0aCBwZXJtaXNzaW9uOjxicj4NCiZndDsgT24gMDkvMDMvMjAxNSAyMjo1NSwgU2hl bmcgSmlhbmcgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7IEhpLCBhdXRob3JzIG9mIGRyYWZ0LWNhcnBl bnRlci1hbmltYS1nZG4tcHJvdG9jb2w8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgVGhl IGJlbG93IGFyZSBzb21lIGNvbW1lbnRzIGZyb20gbXkgY29sbGVhZ3VlLCBEci4gSm9obiBTdHJh c3NuZXIuPGJyPg0KJmd0OyBBbHRob3VnaCBJIHBlcnNvbmFsbHkgdGhpbmsgeW91ciBwcm90b2Nv bCBkZXNpZ25zIGhhdmUgdGhlIGFiaWxpdHkgdG8gbWVldDxicj4NCiZndDsgaGlzIHJlcXVpcmVt ZW50cyBmb3Iga25vd2xlZGdlIGV4Y2hhbmdpbmcgYW1vbmcgYXV0b25vbWljIG5vZGVzLCBpdCBp czxicj4NCiZndDsgYmV0dGVyIHlvdSBjb3VsZCBkaXNjdXNzIGRpcmVjdGx5IGFuZCBtYXliZSBp bmNsdWRlIHNvbWU8YnI+DQomZ3Q7IG1vZGlmaWNhdGlvbi9jbGFyaWZpY2F0aW9uIGluIHRoZSBm dXR1cmUgdmVyc2lvbi4gSSBhbHNvIGVuY291cmFnZSB5b3UgdG88YnI+DQomZ3Q7IGRpc2N1c3Mg dGhpcyBpbiBBTklNQSBtYWlsIGxpc3Qgb3Blbmx5Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyBCZXN0IHJlZ2FyZHMsPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFNoZW5nPGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LTxicj4NCiZndDsgJmd0OyZndDsgRnJvbTogSm9obiBTdHJhc3NuZXI8YnI+DQomZ3Q7ICZndDsm Z3Q7IFNlbnQ6IEZyaWRheSwgTWFyY2ggMDYsIDIwMTUgNjo0MyBBTTxicj4NCiZndDsgJmd0OyZn dDsgVG86IFNoZW5nIEppYW5nOyBKb2huIFN0cmFzc25lcjxicj4NCiZndDsgJmd0OyZndDs8YnI+ DQomZ3Q7ICZndDsmZ3Q7IERlYXIgU2hlbmcsPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsg Jmd0OyZndDsgSSByZWFkIHRoZSBjaGFydGVyIGFuZCBhbSBzdGFydGluZyBvbiB0aGUgZHJhZnRz Ljxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgYXV0b25vbWlj cyByZXF1aXJlIHRoZSBhYmlsaXR5IHRvIHNoYXJlIGFuZCBleGNoYW5nZSBrbm93bGVkZ2UgaW48 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgYW4gaW50ZXJvcGVyYWJsZSBmYXNoaW9uLiBJIGZh aWwgdG8gc2VlIGhvdyB0aGlzIGlzIGV2ZW4gZGlzY3Vzc2VkPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7IGluIEFOSU1BLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsgQlRXLCB0aGUgYWJpbGl0eSB0byBzaGFyZSBhbmQgZXhjaGFuZ2Uga25vd2xlZGdlIGlu IGFuIGludGVyb3BlcmFibGU8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBmYXNoaW9uIGxvb2tzIGxp a2UgR05EUCAoR2VuZXJpYyBEaXNjb3ZlcnkgYW5kIE5lZ290aWF0aW9uIFByb3RvY29sKTxicj4N CiZndDsgJmd0OyZndDsmZ3Q7IGluIEFOSU1BLiBUaGlzIHByb3RvY29sIGlzIGRlc2lnbmVkIHRv IHN1cHBvcnQgaW5mb3JtYXRpb24gZGlzY292ZXJ5PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgYW5k IGJpLWRpcmVjdGlvbiBuZWdvdGlhdGlvbi48YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAm Z3Q7Jmd0OyBJdCBhcHBlYXJzIHRoYXQgR0ROUCBjb3ZlcnMgc29tZSwgYnV0IG5vdCBhbGwsIG9m IHdoYXQgSSBhbSB0YWxraW5nIGFib3V0Ljxicj4NCiZndDs8YnI+DQomZ3Q7IEluZGVlZCwgaXQg aXNuJ3QgY2xhaW1pbmcgdG8gY292ZXIgZXZlcnl0aGluZy4gVGhlIGlkZWEgaXMgdGhhdCBkcmFm dC08YnI+DQomZ3Q7IGJlaHJpbmdlci1hbmltYS1yZWZlcmVuY2UtbW9kZWwgd2lsbCBldm9sdmUg dG8gc2hvdyBob3cgdGhpbmdzIGZpdDxicj4NCiZndDsgdG9nZXRoZXIsIHdoaWNoIHdpbGwgaGVs cCB1cyB0byBpZGVudGlmeSBob2xlcy48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBIb3dl dmVyLCB0aGUgZm9sbG93aW5nIHN0YXRlbWVudCBmcm9tIHRoZSBHRE5QIGRyYWZ0IGlzIG1pc2xl YWRpbmcsPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBpZiBub3QganVzdCBwbGFpbiB3cm9uZzo8YnI+DQom Z3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmcXVvdDtJbiBvcmRlciB0byBmdWxmaWwg YXV0b25vbXksIGRldmljZXMgdGhhdCBlbWJvZHkgYXV0b25vbWljIHNlcnZpY2U8YnI+DQomZ3Q7 ICZndDsmZ3Q7IGFnZW50cyBuZWVkIHRvIGJlIGFibGUgdG8gZGlzY292ZXIgZWFjaCBvdGhlciwg dG8gc3luY2hyb25pemUgc3RhdGU8YnI+DQomZ3Q7ICZndDsmZ3Q7IHdpdGggZWFjaCBvdGhlciwg YW5kIHRvIG5lZ290aWF0ZSBwYXJhbWV0ZXJzIGFuZCByZXNvdXJjZXMgZGlyZWN0bHk8YnI+DQom Z3Q7ICZndDsmZ3Q7IHdpdGggZWFjaCBvdGhlci4mcXVvdDs8YnI+DQomZ3Q7ICZndDsmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7Jmd0OyBGaXJzdCwgYXV0b25vbWljIG5ldHdvcmtzIGFyZSBub3QgbmVjZXNz YXJpbHkgYXV0b25vbW91cy4gQXV0b25vbXksPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBpbiBpdHMgbW9z dCBnZW5lcmljIGZvcm0sIGlzIHRoZSBhYmlsaXR5IHRvIGhhdmUgdGhlIHBvd2VyIGZvciBhbjxi cj4NCiZndDsgJmd0OyZndDsgZW50aXR5IHRvIGdvdmVybiBpdHNlbGYuIElmIGV2ZXJ5IG5ldHdv cmsgZWxlbWVudCBnb3Zlcm5zIGl0c2VsZjxicj4NCiZndDsgJmd0OyZndDsgd2l0aG91dCByZWdh cmQgdG8gb3RoZXIsIGhpZ2hlciBsZXZlbCBwcmluY2lwbGVzLCB5b3UgZG9uJ3QgZXZlbiBoYXZl PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBhIG5ldHdvcmsuIDotKTxicj4NCiZndDs8YnI+DQomZ3Q7IFN1 cmUuIFRoYXQgaXMgdGhlIHJvbGUgZm9yIHdoYXQgd2UgY2FsbCAmcXVvdDtpbnRlbnQmcXVvdDsg d2hpY2ggaXMgZGVmaW5lZCBpbiBkcmFmdC1pcnRmLTxicj4NCiZndDsgbm1yZy1hdXRvbm9taWMt bmV0d29yay1kZWZpbml0aW9ucyBidXQgaXMgbm90IHlldCBpbiBBbmltYSBzY29wZS48YnI+DQom Z3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBTZWNvbmQsIHRoZSB0aHJlZSBjb25jZXB0cyBtZW50aW9u ZWQgaW4gdGhlIGFib3ZlIGV4Y2VycHQ8YnI+DQomZ3Q7ICZndDsmZ3Q7IChkaXNjb3ZlcmFiaWxp dHksIHN5bmNocm9uaXphdGlvbiBvZiBzdGF0ZSwgYW5kIHBhcmFtZXRlcjxicj4NCiZndDsgJmd0 OyZndDsgbmVnb3RpYXRpb24pIGFyZSBuZWNlc3NhcnkgYnV0IGNsZWFybHkgbm90IHN1ZmZpY2ll bnQgdG8gaGF2ZTxicj4NCiZndDsgJmd0OyZndDsgYXV0b25vbWljIG9wZXJhdGlvbi4gSSB3YXMg dGFsa2luZyBhYm91dCB0aGUgYWJpbGl0eSB0byBleGNoYW5nZTxicj4NCiZndDsgJmd0OyZndDsg a25vd2xlZGdlIChlLmcuLCBhbGwgb3IgcGFydCBvZiBhbiBpbmZvcm1hdGlvbiBtb2RlbCkgYmV0 d2Vlbjxicj4NCiZndDsgJmd0OyZndDsgZW50aXRpZXMuIEl0IGRvZXNuJ3QgYXBwZWFyIHRoYXQg dGhpcyBpcyBjb3ZlcmVkIGluIEFOSU1BIHlldCwgdGhvdWdoIEk8YnI+DQomZ3Q7IGhhdmVuJ3Qg cmVhZCBhbGwgb2YgdGhlIG1hdGVyaWFscy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBNeSBwZXJzb25h bCB2aWV3IGlzIHRoYXQgdGhpcyBpcyBnb2luZyB0byBiZSByZXNvbHZlZCB0b3BpYyBieSB0b3Bp Yy48YnI+DQomZ3Q7IEluIEdETlAtc3BlYWsgdGhhdCBtZWFucyB0aGF0IGl0IHdpbGwgYmUgcmVz b2x2ZWQgYnkgaW5kaXZpZHVhbCBPYmplY3RpdmU8YnI+DQomZ3Q7IGRlZmluaXRpb25zLCBhbmQg R0ROUCB3aWxsIGp1c3QgYWN0IGFzIGEgbmV1dHJhbCBjYXJyaWVyLiAoWW91IGNhbiBxdWl0ZSBm YWlybHk8YnI+DQomZ3Q7IGFyZ3VlIHRoYXQgdGhpcyBtZWFucyB3ZSBhcmUgZHVja2luZyB0aGUg cHJvYmxlbSBmb3Igbm93LikgQW5vdGhlciB3YXkgdG88YnI+DQomZ3Q7IHNheSB0aGlzIGlzIHRo YXQgZWFjaCB0eXBlIG9mIGF1dG9ub21vdXMgc2VydmljZSBhZ2VudCB3aWxsIHNvbHZlIHRoaXM8 YnI+DQomZ3Q7IHByb2JsZW0gZm9yIGl0cyBvd24gdGFyZ2V0IHBhcmFtZXRlcnMuPGJyPg0KJmd0 Ozxicj4NCiZndDsgTm93LCBhZ2FpbiBJTUhPLCB0aGlzIGlzIHdoeSB3ZSBzdGF0ZSBpbiBHRE5Q IHRoYXQgdGhlIGZvcm1hdCBvZiB0aGUgdmFsdWU8YnI+DQomZ3Q7IG9mIGFuIG9iamVjdGl2ZSAm cXVvdDsuLi5taWdodCBiZSBpbmhlcml0ZWQgZnJvbSBhbiBleGlzdGluZyBtYW5hZ2VtZW50IG9y PGJyPg0KJmd0OyBjb25maWd1cmF0aW9uIHByb3RvY29sLCB0aGUgb2JqZWN0aXZlIG9wdGlvbiBh Y3RpbmcgYXMgYSBjYXJyaWVyIGZvciB0aGF0PGJyPg0KJmd0OyBmb3JtYXQuJm5ic3A7IFRoZSBk YXRhIHN0cnVjdHVyZSBtaWdodCBiZSBkZWZpbmVkIGluIGEgZm9ybWFsIGxhbmd1YWdlLCBidXQg dGhhdDxicj4NCiZndDsgaXMgYSBtYXR0ZXIgZm9yIHRoZSBzcGVjaWZpY2F0aW9ucyBvZiBpbmRp dmlkdWFsIG9iamVjdGl2ZXMuJm5ic3A7IFRoZXJlIGFyZSBtYW55PGJyPg0KJmd0OyBjYW5kaWRh dGVzLCBhY2NvcmRpbmcgdG8gdGhlIGNvbnRleHQsIHN1Y2ggYXMgQUJORiwgUkJORiwgWE1MIFNj aGVtYSw8YnI+DQomZ3Q7IHBvc3NpYmx5IFlBTkcsIGV0Yy4mbmJzcDsgVGhlIEdETlAgcHJvdG9j b2wgaXRzZWxmIGlzIGFnbm9zdGljIG9uIHRoZXNlPGJyPg0KJmd0OyBxdWVzdGlvbnMuJnF1b3Q7 PGJyPg0KJmd0Ozxicj4NCiZndDsgTXkgZXhwZWN0YXRpb24gaXMgdGhhdCBzb21lIG9iamVjdGl2 ZXMgd2lsbCBuZWVkIGEgZm9ybWFsIGluZm9ybWF0aW9uPGJyPg0KJmd0OyBtb2RlbCBhbmQgdGhh dCBvdGhlcnMgd29uJ3QsIGFuZCB0aGF0IHRoZXJlJ3Mgbm8gcmVhc29uIHdlIGNvdWxkbid0IGlu aGVyaXQ8YnI+DQomZ3Q7IGV4aXN0aW5nIElNcyB3aGVuIHRoZXkgYXJlIHJlbGV2YW50LiBCdXQg dGhhdCB3aG9sZSBxdWVzdGlvbiBpcyBhbHNvIG91dCBvZjxicj4NCiZndDsgY2hhcnRlciBzY29w ZSBmb3Igbm93LiBBcyB5b3Uga25vdyBiZXR0ZXIgdGhhbiBtb3N0IHBlb3BsZSwgSm9obiwgZGVm aW5pbmc8YnI+DQomZ3Q7IGFuIElNIGNhbiBiZWNvbWUgYSB2ZXJ5IGxhYm9yaW91cyBidXNpbmVz cyBhbmQgZm9yIG5vdyB3ZSB3YW50IHRvIGdldDxicj4NCiZndDsgc3RhcnRlZCBvbiBzaW1wbGUg Y2FzZXMgdGhhdCBkb24ndCBuZWVkIGl0Ljxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IElm IHlvdSBjYW5ub3QgZXhjaGFuZ2Uga25vd2xlZGdlLCB5b3Ugd2lsbCBuZXZlciBiZSBhdXRvbm9t aWMgaW4gdGhlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBjb21wdXRlciBzY2llbmNlIHNlbnNlLjxicj4N CiZndDs8YnI+DQomZ3Q7IFlvdSB3aWxsIGZpbmQgdmVyeSBzaW1pbGFyIHdvcmRzIGluIGRyYWZ0 LWlydGYtbm1yZy1hbi1nYXAtYW5hbHlzaXMuPGJyPg0KJmd0Ozxicj4NCiZndDsgJmx0O3NuaXAm Z3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgUmVnYXJkczxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwO0JyaWFuPGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyZndDsgcmVnYXJkcyw8YnI+DQomZ3Q7 ICZndDsmZ3Q7IEpvaG48YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBEci4g Sm9obiBTdHJhc3NuZXIsIFBoLkQuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBDVE8sIFNvZnR3YXJlIExh Ym9yYXRvcnksIENSRDxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7Jmd0OyBGdXR1cmV3ZWkgVGVjaG5vbG9naWVzPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBV UyBSJmFtcDtEIENlbnRlcjxicj4NCiZndDsgJmd0OyZndDsgMjMzMCBDZW50cmFsIEV4cHJlc3N3 YXk8YnI+DQomZ3Q7ICZndDsmZ3Q7IEJ1aWxkaW5nIEEsIG9mZmljZSBBMi0yMTQzPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyBTYW50YSBDbGFyYSwgQ2FsaWZvcm5pYSZuYnNwOyAmbmJzcDs5NTA1MDxicj4N CiZndDsgJmd0OyZndDsmbmJzcDsgT2ZmaWNlOiZuYnNwOyAmIzQzOzEuNDA4LjMzMC40OTIzPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZuYnNwOyBFbWFpbDombmJzcDsgJm5ic3A7PGEgaHJlZj0ibWFpbHRv OmpvaG4uc2Muc3RyYXNzbmVyQGh1YXdlaS5jb20iPmpvaG4uc2Muc3RyYXNzbmVyQGh1YXdlaS5j b208L2E+PGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZn dDsmZ3Q7IEJlc3QgcmVnYXJkcyw8YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0 OyBTaGVuZzxicj4NCiZndDs8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBBbmltYSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7 IDxhIGhyZWY9Im1haWx0bzpBbmltYUBpZXRmLm9yZyI+QW5pbWFAaWV0Zi5vcmc8L2E+PGJyPg0K Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1h IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9h bmltYTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8YnI+DQotLSA8 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij5yZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Kb2huPG86 cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF22EF15FAxmbrcdx14ciscoc_-- From nobody Thu Mar 12 04:22: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 C228E1A9232 for ; Thu, 12 Mar 2015 04:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 A6zTLpOLkHVe for ; Thu, 12 Mar 2015 04:22:05 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::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 12B871A9168 for ; Thu, 12 Mar 2015 04:22:05 -0700 (PDT) Received: by wghl2 with SMTP id l2so15590084wgh.8 for ; Thu, 12 Mar 2015 04:22:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1oQFhO9A1Y2FUKxRJNR8G51NWN+4s8TP7kwVGy/0gTo=; b=hR28ikBo0FUtwWyJRoLvoo2ipac7CevebRFc60+IdEWU6xFxLrRpeDXrW61x2aGBQ0 oRDPf4owKS5orytOEfAtF5dHeEvTTCGBYNpyI8RR0x9hjIwAw+pnvNm8EqY4iUhkona1 UCgacot6EJWGHCRJpPSoxEPNuwovDqf0dbMB18Wz6YRIfgGZBeCdRga4cAR7X9JG77bI PAB6HwDHTDB2ihMT+gLTvZ45w9s31iMcNguWuD93Ilbh/vVe+f6mfNo4tUZNUGxW1Kuw z3zGc/fczncfw9S5ASTnwlidCLtzDF2JYJIuWgX6LyfbXeMBM465sZU9bYfG1IWFD+t8 UlzQ== MIME-Version: 1.0 X-Received: by 10.180.104.200 with SMTP id gg8mr54856616wib.8.1426159323774; Thu, 12 Mar 2015 04:22:03 -0700 (PDT) Received: by 10.27.85.139 with HTTP; Thu, 12 Mar 2015 04:22:03 -0700 (PDT) In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22EF15FA@xmb-rcd-x14.cisco.com> References: <5D36713D8A4E7348A7E10DF7437A4B923B059AD6@nkgeml512-mbx.china.huawei.com> <54FE67C3.9010804@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22EF05CD@xmb-rcd-x14.cisco.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22EF15FA@xmb-rcd-x14.cisco.com> Date: Thu, 12 Mar 2015 04:22:03 -0700 Message-ID: From: John Strassner To: "Michael Behringer (mbehring)" Content-Type: multipart/alternative; boundary=f46d04430404e309460511159732 Archived-At: Cc: Anima WG , John Strassner , "Liubing \(Leo\)" Subject: Re: [Anima] Some comments for draft-carpenter-anima-gdn-protocol 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, 12 Mar 2015 11:22:12 -0000 --f46d04430404e309460511159732 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hallo Michael, inline as well...look for .. Hallo Michael, it's been a long time. :-) MB: Indeed =E2=80=93 the world is small! J I understand, and agree, with your first point. Regarding the second point, I understand your point about fully autonomic nodes. In addition, I think the WG should be commended for worrying about legacy elements and processes from the outset. First question: could I characterize your approach as having three types of nodes: fully autonomic, autonomically-aware, and autonomically-unaware? An autonomically-aware node is one that fully autonomic nodes can communicate with, and which understands (perhaps after translation) what functions are required of it and what functions it can offer. An autonomically-unaware node is a dumb rock (e.g., a hub). MB: Yes, we=E2=80=99re essentially thinking along the same lines, but phras= e it differently. We agree on =E2=80=9Cfully autonomic=E2=80=9D, that=E2=80=99s = the easy one. Now, your =E2=80=9Cautonomically-aware=E2=80=9D definition translates in ou= r world to =E2=80=9Csupports the Autonomic Networking Infrastructure=E2=80=9D, which i= s exactly what we=E2=80=99re defining right now in ANIMA. I think this definition has two sub-flavours: a) the node supports the AN Infrastructure and one or several autonomic service agents (but is not fully autonomic) b) the node supports the AN Infrastructure, but may not be aware of autonomic service agents that run on other nodes. I'm with you so far... Point a) is a subset of b). Example: topology is A----B----C. All nodes support the AN infrastructure. A and C should be able to negotiate parameters for an autonomic service agents, even if B doesn=E2=80=99t imple= ment that function. By subset, do you subclass? If "C" is a fully autonomic node, then I'm happy and understand. If not, then I'm confused. I think it=E2=80=99s pretty obvious. I just want to point out that in our t= hinking there is infrastructure and autonomic service agents. An =E2=80=9Cautonomic= ally aware=E2=80=9D node MUST have the AN infrastructure, and MAY have autonomic= service agents. This makes perfect sense. Agents are obvious - enough so that I forgot to mention them :-) However, since you bring them up, are you assuming full FIPA compliant agents, or something else? Not having decided yet is fine too. BTW, an =E2=80=9Cautonomically unaware=E2=80=9D node is not just a dumb roc= k like a hub. Also traditional devices (e.g. routers) which do not support the AN infrastructure fall into that category. Agreed. I was giving the traditional router the benefit of the doubt :-) but for this purpose, yes, it is a dumb rock. Then, I could say that an autonomic function is either be supported directly by a fully autonomic node, or built from a set of nodes (some of which are not capable of performing autonomic functions). MB: I think when you say =E2=80=9Cautonomic function=E2=80=9D you mean a fu= nction across various nodes, right? In our wording, a node runs an autonomic service agent. A group of such nodes implement an autonomic function. Yes, agreed Second question: performing an autonomic function is a set of behaviors. What's important is the end result, not the individual behaviors. So, as long as each individual behavior can be rigorously defined (e.g., using a software contract, where the behavior satisfies a set of pre- and post-conditions as well as a set of invariants), then (in theory) they should be able to be composited together. What=E2=80=99s the question? ;-) Yes, I agree. The Autonomic Control Plan= e is an example of this. Each nodes carries out a few local actions (authenticating neighbors, building tunnels to them, etc), and the net result is a self-managing overlay network with some nice properties. Oops, sorry. My caffeine/blood ratio must have been too low. :-) My question was how the behaviors are composited. When I built similar functionality, I used software contracts to manage the functions performed by the agents. At the time, I didn't see many other examples of this, so I was curious if ANIMA had thought about how to standardize the agent behavior? With software contracts, this becomes easier, as the function is characterized by the contract. Make sense? Thanks for your input and validation of our work! Michael I now understand a lot more, thanks to you, Brian, and Sheng for your answers and patience. I think the work is promising, and would like to participate. Thoughts? best regards, John mfg, John On Thu, Mar 12, 2015 at 1:17 AM, Michael Behringer (mbehring) < mbehring@cisco.com> wrote: > Inline=E2=80=A6. > > > > *From:* John Strassner [mailto:strazpdj@gmail.com] > *Sent:* 12 March 2015 02:23 > *To:* Michael Behringer (mbehring); John Strassner > *Cc:* Brian E Carpenter; John Strassner; Liubing (Leo); Anima WG > *Subject:* Re: [Anima] Some comments for > draft-carpenter-anima-gdn-protocol > > > > Hallo Michael, > > it's been a long time. :-) > > > > MB: Indeed =E2=80=93 the world is small! J > > > > I understand, and agree, with your first point. > > > > Regarding the second point, I understand your point about fully autonomic > nodes. In addition, I think the WG should be commended for worrying about > legacy elements and processes from the outset. > > > > First question: could I characterize your approach as having three types > of nodes: fully autonomic, autonomically-aware, and > autonomically-unaware? An autonomically-aware node is one that fully > autonomic nodes can communicate with, and which understands (perhaps afte= r > translation) what functions are required of it and what functions it can > offer. An autonomically-unaware node is a dumb rock (e.g., a hub). > > > > MB: Yes, we=E2=80=99re essentially thinking along the same lines, but phr= ase it > differently. We agree on =E2=80=9Cfully autonomic=E2=80=9D, that=E2=80=99= s the easy one. > > Now, your =E2=80=9Cautonomically-aware=E2=80=9D definition translates in = our world to > =E2=80=9Csupports the Autonomic Networking Infrastructure=E2=80=9D, which= is exactly what > we=E2=80=99re defining right now in ANIMA. I think this definition has tw= o > sub-flavours: > > a) the node supports the AN Infrastructure and one or several > autonomic service agents (but is not fully autonomic) > > b) the node supports the AN Infrastructure, but may not be aware of > autonomic service agents that run on other nodes. > > Point a) is a subset of b). Example: topology is A----B----C. All nodes > support the AN infrastructure. A and C should be able to negotiate > parameters for an autonomic service agents, even if B doesn=E2=80=99t imp= lement > that function. > > I think it=E2=80=99s pretty obvious. I just want to point out that in our= thinking > there is infrastructure and autonomic service agents. An =E2=80=9Cautonom= ically > aware=E2=80=9D node MUST have the AN infrastructure, and MAY have autonom= ic service > agents. > > > > BTW, an =E2=80=9Cautonomically unaware=E2=80=9D node is not just a dumb r= ock like a hub. > Also traditional devices (e.g. routers) which do not support the AN > infrastructure fall into that category. > > > > Then, I could say that an autonomic function is either be supported > directly by a fully autonomic node, or built from a set of nodes (some of > which are not capable of performing autonomic functions). > > > > MB: I think when you say =E2=80=9Cautonomic function=E2=80=9D you mean a = function across > various nodes, right? In our wording, a node runs an autonomic service > agent. A group of such nodes implement an autonomic function. > > > > Second question: performing an autonomic function is a set of behaviors. > What's important is the end result, not the individual behaviors. So, as > long as each individual behavior can be rigorously defined (e.g., using a > software contract, where the behavior satisfies a set of pre- and > post-conditions as well as a set of invariants), then (in theory) they > should be able to be composited together. > > > > What=E2=80=99s the question? ;-) Yes, I agree. The Autonomic Control Pl= ane is an > example of this. Each nodes carries out a few local actions (authenticati= ng > neighbors, building tunnels to them, etc), and the net result is a > self-managing overlay network with some nice properties. > > > > Thanks for your input and validation of our work! > > Michael > > > > > > Thoughts? > > > > > > best regards, > > John > > > > > > > > On Wed, Mar 11, 2015 at 3:42 AM, Michael Behringer (mbehring) < > mbehring@cisco.com> wrote: > > John, > > Adding to Brian/Sheng my view, there are two important points to note: > > 1) What you see now is just the start. In this first phase we're not > actually standardising any autonomic service agents (as we call them), bu= t > we're preparing an infrastructure for such agents. Meaning, such agents c= an > count on all the "mechanics" to talk to other agents: Addressing, routing= , > security, simple discovery, negotiation, etc. We call this the autonomic > networking infrastructure, and our goal is to make this infrastructure > "self-managing" itself, specifically, it should self-configure. > > This infrastructure is not complete, as you correctly point out. But all > of the functions you mention (e.g., knowledge exchange) first of all > require a solid communications infrastructure. > > In the WG charter you see the elements of the infrastructure, and a coupl= e > of use cases for autonomic service agents. In this first phase the > intention is to validate the autonomic networking infrastructure with tho= se > use cases. See also the UCAN BoF notes, where more use cases were > discussed. Again, we're looking at simple use cases to start with, and wo= rk > bottom-up. > > 2) We are not trying to define fully autonomic nodes, but autonomic > functions. In other words, we expect nodes to be partially managed in the > traditional way, and some functions to be autonomic. In the future there > may be cases of fully autonomic nodes. > > As we take on new use cases, we define their requirements, and address th= e > delta in the autonomic networking infrastructure, bottom up. With the > reference model we need to make sure that we're not going down a track th= at > will make future use cases impossible or hard to support. This is of cour= se > the main challenge. Your input would be very valuable in this process. > > What are your thoughts? > > Michael > > > > -----Original Message----- > > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E > > Carpenter > > Sent: 10 March 2015 04:41 > > To: John Strassner > > Cc: Liubing (Leo); Anima WG; strazpdj@gmail.com > > Subject: Re: [Anima] Some comments for draft-carpenter-anima-gdn- > > protocol > > > > Hi John and everybody, > > > > Replying to some comments received privately, on the list with > permission: > > On 09/03/2015 22:55, Sheng Jiang wrote: > > > Hi, authors of draft-carpenter-anima-gdn-protocol > > > > > > The below are some comments from my colleague, Dr. John Strassner. > > Although I personally think your protocol designs have the ability to > meet > > his requirements for knowledge exchanging among autonomic nodes, it is > > better you could discuss directly and maybe include some > > modification/clarification in the future version. I also encourage you = to > > discuss this in ANIMA mail list openly. > > > > > > Best regards, > > > > > > Sheng > > > > > >> -----Original Message----- > > >> From: John Strassner > > >> Sent: Friday, March 06, 2015 6:43 AM > > >> To: Sheng Jiang; John Strassner > > >> > > >> Dear Sheng, > > >> > > >> I read the charter and am starting on the drafts. > > >> > > >>>> autonomics require the ability to share and exchange knowledge in > > >>>> an interoperable fashion. I fail to see how this is even discussed > > >>>> in ANIMA. > > >>> > > >>> BTW, the ability to share and exchange knowledge in an interoperabl= e > > >>> fashion looks like GNDP (Generic Discovery and Negotiation Protocol= ) > > >>> in ANIMA. This protocol is designed to support information discover= y > > >>> and bi-direction negotiation. > > >> > > >> It appears that GDNP covers some, but not all, of what I am talking > about. > > > > Indeed, it isn't claiming to cover everything. The idea is that draft- > > behringer-anima-reference-model will evolve to show how things fit > > together, which will help us to identify holes. > > > > >> However, the following statement from the GDNP draft is misleading, > > >> if not just plain wrong: > > >> > > >> "In order to fulfil autonomy, devices that embody autonomic service > > >> agents need to be able to discover each other, to synchronize state > > >> with each other, and to negotiate parameters and resources directly > > >> with each other." > > >> > > >> First, autonomic networks are not necessarily autonomous. Autonomy, > > >> in its most generic form, is the ability to have the power for an > > >> entity to govern itself. If every network element governs itself > > >> without regard to other, higher level principles, you don't even hav= e > > >> a network. :-) > > > > Sure. That is the role for what we call "intent" which is defined in > draft-irtf- > > nmrg-autonomic-network-definitions but is not yet in Anima scope. > > > > >> Second, the three concepts mentioned in the above excerpt > > >> (discoverability, synchronization of state, and parameter > > >> negotiation) are necessary but clearly not sufficient to have > > >> autonomic operation. I was talking about the ability to exchange > > >> knowledge (e.g., all or part of an information model) between > > >> entities. It doesn't appear that this is covered in ANIMA yet, thoug= h > I > > haven't read all of the materials. > > > > My personal view is that this is going to be resolved topic by topic. > > In GDNP-speak that means that it will be resolved by individual Objecti= ve > > definitions, and GDNP will just act as a neutral carrier. (You can quit= e > fairly > > argue that this means we are ducking the problem for now.) Another way = to > > say this is that each type of autonomous service agent will solve this > > problem for its own target parameters. > > > > Now, again IMHO, this is why we state in GDNP that the format of the > value > > of an objective "...might be inherited from an existing management or > > configuration protocol, the objective option acting as a carrier for th= at > > format. The data structure might be defined in a formal language, but > that > > is a matter for the specifications of individual objectives. There are > many > > candidates, according to the context, such as ABNF, RBNF, XML Schema, > > possibly YANG, etc. The GDNP protocol itself is agnostic on these > > questions." > > > > My expectation is that some objectives will need a formal information > > model and that others won't, and that there's no reason we couldn't > inherit > > existing IMs when they are relevant. But that whole question is also ou= t > of > > charter scope for now. As you know better than most people, John, > defining > > an IM can become a very laborious business and for now we want to get > > started on simple cases that don't need it. > > > > >> If you cannot exchange knowledge, you will never be autonomic in the > > >> computer science sense. > > > > You will find very similar words in draft-irtf-nmrg-an-gap-analysis. > > > > > > > > Regards > > Brian > > > > >> regards, > > >> John > > >> > > >> Dr. John Strassner, Ph.D. > > >> CTO, Software Laboratory, CRD > > >> > > >> > > >> Futurewei Technologies > > >> US R&D Center > > >> 2330 Central Expressway > > >> Building A, office A2-2143 > > >> Santa Clara, California 95050 > > >> Office: +1.408.330.4923 > > >> Email: john.sc.strassner@huawei.com > > >> > > >> > > >> Best regards, > > >> > > >> Sheng > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > > > > -- > > regards, > > John > --=20 regards, John --f46d04430404e309460511159732 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hallo Michael,

inline as well...look for <= jcs>..</jcs>

Hallo M= ichael,

it's b= een a long time. :-)

=C2=A0

MB: Indeed =E2=80=93 the world is small! <= /span>J

=C2=A0<= /font>

I understand, and agree, with you= r first point.

=C2=A0

= Re= garding the second point, I understand your point about fully autonomic nod= es. In addition, I think the WG should be commended for worrying about lega= cy elements and processes from the outset.

<= /div>

= =C2=A0

=

First question: could I characterize your approac= h as having three types of nodes: fully autonomic, autonomically-aware, and= autonomically-unaware?=C2=A0An autonomically-aware node is one that fully = autonomic nodes can communicate with, and which understands (perhaps after = translation) what functions are required of it and what functions it can of= fer. An autonomically-unaware node is a dumb rock (e.g., a hub).


MB: Ye= s, we=E2=80=99re essentially thinking along the same lines, but phrase it d= ifferently. We agree on =E2=80=9Cfully autonomic=E2=80=9D, that=E2=80=99s = the easy one.

Now, you= r =E2=80=9Cautonomically-aware=E2=80=9D definition translates in our world = to =E2=80=9Csupports the Autonomic Networking Infrastructure=E2=80=9D, whi= ch is exactly what we=E2=80=99re defining right now in ANIMA. I think this = definition has two sub-flavours:

= a)= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the = node supports the AN Infrastructure =C2=A0and one or several autonomic serv= ice agents (but is not fully autonomic)

<= u>b)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = <jcs>

I'= ;m with you so far...

</jcs>

=

Point a) is a subset = of b). Example: topology is A----B----C. All nodes support the AN infrastru= cture. A and C should be able to negotiate parameters for an autonomic serv= ice agents, even if B doesn=E2=80=99t implement that function.

=C2=A0

= <jcs>

By su= bset, do you subclass?

If "C&q= uot; is a fully autonomic node, then I'm happy and understand. If not, = then I'm confused.

</jcs&g= t;


I think it=E2=80=99s pretty ob= vious. I just want to point out that in our thinking there is infrastructur= e and autonomic service agents. An =E2=80=9Cautonomically aware=E2=80=9D no= de MUST have the AN infrastructure, and MAY have autonomic service agents. =


<jcs>

This makes perfec= t sense.

Agents are obvious - enough = so that I forgot to mention them :-)

= However, since you bring them up, are you assuming full FIPA compliant agen= ts, or something else? Not having decided yet is fine too.

</jcs>


BTW, an =E2=80=9Ca= utonomically unaware=E2=80=9D node is not just a dumb rock like a hub. Also= traditional devices (e.g. routers) which do not support the AN infrastruct= ure fall into that category.


<jcs>=

Agreed. I was giving the traditional router the be= nefit of the doubt :-) but for this purpose, yes, it is a dumb rock.

</jcs>


Then= , I could say that an autonomic function is either be=C2=A0supported direct= ly by a fully autonomic node, or built from a set of=C2=A0nodes (some of wh= ich are not=C2=A0capable of performing autonomic functions).<= /p>

= =C2=A0

MB: I think when you sa= y =E2=80=9Cautonomic function=E2=80=9D you mean a function across various n= odes, right? In our wording, a node runs an autonomic service agent. A grou= p of such nodes implement an autonomic function.


<jcs>= ;

Yes, agreed

</jcs>


=

Second question: perfo= rming an autonomic function is a set of behaviors. What's important is = the end result, not the individual behaviors. So, as long as each individua= l behavior can be rigorously defined (e.g., using a software contract, wher= e the behavior satisfies a set of pre- and post-conditions as well as a set= of invariants), then (in theory) they should be able to be composited toge= ther.


What=E2=80=99= s the question? ;-)=C2=A0=C2=A0 Yes, I agree. The Autonomic Control Plane i= s an example of this. Each nodes carries out a few local actions (authentic= ating neighbors, building tunnels to them, etc), and the net result is a se= lf-managing overlay network with some nice properties.


<jcs>

Oops, sorry. My caffeine= /blood ratio must have been too low. :-)

My question was how the behaviors are composited. When I built similar = functionality, I used software contracts to manage the functions performed = by the agents. At the time, I didn't see many other examples of this, s= o I was curious if ANIMA had thought about how to standardize the agent beh= avior? With software contracts, this becomes easier, as the function is cha= racterized by the contract. Make sense?

</jcs>


Thanks for your input and validation = of our work!

Michael

=C2=A0

<= /div>

<jcs>

I now understand a lot more, thanks to you, Brian, and Sheng for your a= nswers and patience. I think the work is promising, and would like to parti= cipate.

</jcs>


Thoughts?

= =C2=A0

=C2= =A0

best regards,

John<= /font>

=

mfg,
John


On Thu, Mar 12, 2015 at 1:17 AM, Michael Behringer (mbehri= ng) <mbehring@cisco.com> wrote:

Inline=E2=80=A6.

=C2=A0

From: John Strassner [mailto:strazpdj@gmail.com]
Sent: 12 March 2015 02:23 To: Michael Behringer (mbehr= ing); John Strassner
Cc: Brian E Carpenter; John = Strassner; Liubing (Leo); Anima WG
Subject: Re: [Anima] Some co= mments for draft-carpenter-anima-gdn-protocol

=C2=A0

Hallo Michael,

it's been a long time. :-)

=C2=A0

MB: Indeed =E2=80=93 the world is small! J

=C2=A0

I understand, and agree, with your first point.=

=C2=A0

Regarding the second point, I understand your point ab= out fully autonomic nodes. In addition, I think the WG should be commended = for worrying about legacy elements and processes from the outset.

=C2=A0

First question: could I characterize your approach as = having three types of nodes: fully autonomic, autonomically-aware, and auto= nomically-unaware?=C2=A0An autonomically-aware node is one that fully autonomic nodes can communicate with, and which und= erstands (perhaps after translation) what functions are required of it and = what functions it can offer. An autonomically-unaware node is a dumb rock (= e.g., a hub).

=C2=A0

MB: Yes, we=E2=80=99re essentially thinking along the = same lines, but phrase it differently. We agree on =E2=80=9Cfully autonomic= =E2=80=9D, that=E2=80=99s the easy one.

Now, your =E2=80=9Cautonomically-aware=E2=80=9D defini= tion translates in our world to =E2=80=9Csupports the Autonomic Networking = Infrastructure=E2=80=9D, which is exactly what we=E2=80=99re defining right now in ANIMA. I think t= his definition has two sub-flavours:

a)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the node supports the AN Infrastruc= ture =C2=A0and one or several autonomic service agents (but is not fully autonomic)

b)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the node supports the AN Infrastruc= ture, but may not be aware of autonomic service agents that run on other nodes.

Point a) is a subset of b). Example: topology is A----= B----C. All nodes support the AN infrastructure. A and C should be able to negotiate parameters for an autonomic service agents, ev= en if B doesn=E2=80=99t implement that function.

I think it=E2=80=99s pretty obvious. I just want to po= int out that in our thinking there is infrastructure and autonomic service agents. An =E2=80=9Cautonomically aware=E2=80=9D node MUST have th= e AN infrastructure, and MAY have autonomic service agents.

=C2=A0

BTW, an =E2=80=9Cautonomically unaware=E2=80=9D node i= s not just a dumb rock like a hub. Also traditional devices (e.g. routers) which do not support the AN infrastructure fall into that category.

=C2=A0

Then, I could say that an autonomic function is either= be=C2=A0supported directly by a fully autonomic node, or built from a set = of=C2=A0nodes (some of which are not=C2=A0capable of performing autonomic functions).

=C2=A0

MB: I think when you say =E2=80=9Cautonomic function= =E2=80=9D you mean a function across various nodes, right? In our wording, a node runs an autonomic service agent. A group of such nodes implement an= autonomic function.

=C2=A0

Second question: performing an autonomic function is a= set of behaviors. What's important is the end result, not the individu= al behaviors. So, as long as each individual behavior can be rigorously defined (e.g., using a software contract, where= the behavior satisfies a set of pre- and post-conditions as well as a set = of invariants), then (in theory) they should be able to be composited toget= her.

=C2=A0

What=E2=80=99s the question? ;-)=C2=A0=C2=A0 Yes, I ag= ree. The Autonomic Control Plane is an example of this. Each nodes carries out a few local actions (authenticating neighbors, building tunnels to the= m, etc), and the net result is a self-managing overlay network with some ni= ce properties.

=C2=A0

Thanks for your input and validation of our work!

Michael

=C2=A0

=C2=A0

Thoughts?

=C2=A0

=C2=A0

best regards,

John

=C2=A0

=C2=A0

=C2=A0

On Wed, Mar 11, 2015 at 3:42 AM, Michael Behringer (mb= ehring) <mbehrin= g@cisco.com> wrote:

John,

Adding to Brian/Sheng my view, there are two important points to note:

1) What you see now is just the start. In this first phase we're not ac= tually standardising any autonomic service agents (as we call them), but we= 're preparing an infrastructure for such agents. Meaning, such agents c= an count on all the "mechanics" to talk to other agents: Addressing, routing, security, simple discovery, negotiat= ion, etc. We call this the autonomic networking infrastructure, and our goa= l is to make this infrastructure "self-managing" itself, specific= ally, it should self-configure.

This infrastructure is not complete, as you correctly point out. But all of= the functions you mention (e.g., knowledge exchange) first of all require = a solid communications infrastructure.

In the WG charter you see the elements of the infrastructure, and a couple = of use cases for autonomic service agents. In this first phase the intentio= n is to validate the autonomic networking infrastructure with those use cas= es. See also the UCAN BoF notes, where more use cases were discussed. Again, we're looking at simple us= e cases to start with, and work bottom-up.

2) We are not trying to define fully autonomic nodes, but autonomic functio= ns. In other words, we expect nodes to be partially managed in the traditio= nal way, and some functions to be autonomic. In the future there may be cas= es of fully autonomic nodes.

As we take on new use cases, we define their requirements, and address the = delta in the autonomic networking infrastructure, bottom up. With the refer= ence model we need to make sure that we're not going down a track that = will make future use cases impossible or hard to support. This is of course the main challenge. Your input would= be very valuable in this process.

What are your thoughts?

Michael


> -----Original Message-----
> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E
> Carpenter
> Sent: 10 March 2015 04:41
> To: John Strassner
> Cc: Liubing (Leo); Anima WG; strazpdj@gmail.com
> Subject: Re: [Anima] Some comments for draft-carpenter-anima-gdn-
> protocol
>
> Hi John and everybody,
>
> Replying to some comments received privately, on the list with permiss= ion:
> On 09/03/2015 22:55, Sheng Jiang wrote:
> > Hi, authors of draft-carpenter-anima-gdn-protocol
> >
> > The below are some comments from my colleague, Dr. John Strassner= .
> Although I personally think your protocol designs have the ability to = meet
> his requirements for knowledge exchanging among autonomic nodes, it is=
> better you could discuss directly and maybe include some
> modification/clarification in the future version. I also encourage you= to
> discuss this in ANIMA mail list openly.
> >
> > Best regards,
> >
> > Sheng
> >
> >> -----Original Message-----
> >> From: John Strassner
> >> Sent: Friday, March 06, 2015 6:43 AM
> >> To: Sheng Jiang; John Strassner
> >>
> >> Dear Sheng,
> >>
> >> I read the charter and am starting on the drafts.
> >>
> >>>> autonomics require the ability to share and exchange = knowledge in
> >>>> an interoperable fashion. I fail to see how this is e= ven discussed
> >>>> in ANIMA.
> >>>
> >>> BTW, the ability to share and exchange knowledge in an in= teroperable
> >>> fashion looks like GNDP (Generic Discovery and Negotiatio= n Protocol)
> >>> in ANIMA. This protocol is designed to support informatio= n discovery
> >>> and bi-direction negotiation.
> >>
> >> It appears that GDNP covers some, but not all, of what I am t= alking about.
>
> Indeed, it isn't claiming to cover everything. The idea is that dr= aft-
> behringer-anima-reference-model will evolve to show how things fit
> together, which will help us to identify holes.
>
> >> However, the following statement from the GDNP draft is misle= ading,
> >> if not just plain wrong:
> >>
> >> "In order to fulfil autonomy, devices that embody autono= mic service
> >> agents need to be able to discover each other, to synchronize= state
> >> with each other, and to negotiate parameters and resources di= rectly
> >> with each other."
> >>
> >> First, autonomic networks are not necessarily autonomous. Aut= onomy,
> >> in its most generic form, is the ability to have the power fo= r an
> >> entity to govern itself. If every network element governs its= elf
> >> without regard to other, higher level principles, you don'= ;t even have
> >> a network. :-)
>
> Sure. That is the role for what we call "intent" which is de= fined in draft-irtf-
> nmrg-autonomic-network-definitions but is not yet in Anima scope.
>
> >> Second, the three concepts mentioned in the above excerpt
> >> (discoverability, synchronization of state, and parameter
> >> negotiation) are necessary but clearly not sufficient to have=
> >> autonomic operation. I was talking about the ability to excha= nge
> >> knowledge (e.g., all or part of an information model) between=
> >> entities. It doesn't appear that this is covered in ANIMA= yet, though I
> haven't read all of the materials.
>
> My personal view is that this is going to be resolved topic by topic.<= br> > In GDNP-speak that means that it will be resolved by individual Object= ive
> definitions, and GDNP will just act as a neutral carrier. (You can qui= te fairly
> argue that this means we are ducking the problem for now.) Another way= to
> say this is that each type of autonomous service agent will solve this=
> problem for its own target parameters.
>
> Now, again IMHO, this is why we state in GDNP that the format of the v= alue
> of an objective "...might be inherited from an existing managemen= t or
> configuration protocol, the objective option acting as a carrier for t= hat
> format.=C2=A0 The data structure might be defined in a formal language= , but that
> is a matter for the specifications of individual objectives.=C2=A0 The= re are many
> candidates, according to the context, such as ABNF, RBNF, XML Schema,<= br> > possibly YANG, etc.=C2=A0 The GDNP protocol itself is agnostic on thes= e
> questions."
>
> My expectation is that some objectives will need a formal information<= br> > model and that others won't, and that there's no reason we cou= ldn't inherit
> existing IMs when they are relevant. But that whole question is also o= ut of
> charter scope for now. As you know better than most people, John, defi= ning
> an IM can become a very laborious business and for now we want to get<= br> > started on simple cases that don't need it.
>
> >> If you cannot exchange knowledge, you will never be autonomic= in the
> >> computer science sense.
>
> You will find very similar words in draft-irtf-nmrg-an-gap-analysis. >
> <snip>
>
> Regards
>=C2=A0 =C2=A0 =C2=A0Brian
>
> >> regards,
> >> John
> >>
> >> Dr. John Strassner, Ph.D.
> >> CTO, Software Laboratory, CRD
> >>
> >>
> >> Futurewei Technologies
> >> US R&D Center
> >> 2330 Central Expressway
> >> Building A, office A2-2143
> >> Santa Clara, California=C2=A0 =C2=A095050
> >>=C2=A0 Office:=C2=A0 +1.408.330.4923
> >>=C2=A0 Email:=C2=A0 =C2=A0john.sc.strassner@huawei.com
> >>
> >>
> >> Best regards,
> >>
> >> Sheng
>
> _______________________________________________
> Anima mailing list
> Anima@ietf.org=
> https://www.ietf.org/mailman/listinfo/anima




--

regards,

John




--
regards,
John
--f46d04430404e309460511159732-- From nobody Thu Mar 12 05:18:21 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 AC2871A0013 for ; Thu, 12 Mar 2015 05:18:20 -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 dE5KQZ95ZO54 for ; Thu, 12 Mar 2015 05:18:19 -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 BD1C61A0058 for ; Thu, 12 Mar 2015 05:18:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5292; q=dns/txt; s=iport; t=1426162699; x=1427372299; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=aEh7DPQgRUAzNU6fZ/ewWDvThS7PjHO11n8KNoQz9Rg=; b=iz5jkb544I/9DtZmmJqnzQgi6c5SM8y8Pl2MPEoSdjz4oqxJtKNYqQwW Wol8FHhNYGKsYpkEpeoO48ei003JjMyahTJG0g9q7kKsUoG09PIWwjuAg j1ScvrqJw9x9fNR8guoOKqr2y8H7bBcasFS52Xl68sKIHE3BCwaSS4x3E U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CrBgBvgwFV/5JdJa1bgwaBMIMHvg6IJwIcgRNMAQEBAQEBfYQQAQEEIxEzEhACAQgODAIGIAICAjAVEAIEDg2IJ7ALmwsBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGJdoRAMQeCaC+BFgWQJIp7jx6DRSODboFzJBx/AQEB X-IronPort-AV: E=Sophos;i="5.11,388,1422921600"; d="scan'208";a="131349778" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-7.cisco.com with ESMTP; 12 Mar 2015 12:18:18 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t2CCIHfg019063 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Mar 2015 12:18:17 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.142]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Thu, 12 Mar 2015 07:18:17 -0500 From: "Michael Behringer (mbehring)" To: John Strassner Thread-Topic: [Anima] Some comments for draft-carpenter-anima-gdn-protocol Thread-Index: AQHQWuQNTPthNQ4MbUG6geddsooIWp0W7nnggAF1lwCAABhAwIAAj0CA//+4MzA= Date: Thu, 12 Mar 2015 12:18:16 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22EF2620@xmb-rcd-x14.cisco.com> References: <5D36713D8A4E7348A7E10DF7437A4B923B059AD6@nkgeml512-mbx.china.huawei.com> <54FE67C3.9010804@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22EF05CD@xmb-rcd-x14.cisco.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22EF15FA@xmb-rcd-x14.cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.13] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Anima WG , John Strassner , "Liubing \(Leo\)" Subject: Re: [Anima] Some comments for draft-carpenter-anima-gdn-protocol 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, 12 Mar 2015 12:18:20 -0000 Wy4uLl0NClBvaW50IGEpIGlzIGEgc3Vic2V0IG9mIGIpLiBFeGFtcGxlOiB0b3BvbG9neSBpcyBB LS0tLUItLS0tQy4gQWxsIG5vZGVzIHN1cHBvcnQgdGhlIEFOIGluZnJhc3RydWN0dXJlLiBBIGFu ZCBDIHNob3VsZCBiZSBhYmxlIHRvIG5lZ290aWF0ZSBwYXJhbWV0ZXJzIGZvciBhbiBhdXRvbm9t aWMgc2VydmljZSBhZ2VudHMsIGV2ZW4gaWYgQiBkb2VzbuKAmXQgaW1wbGVtZW50IHRoYXQgZnVu Y3Rpb24uDQrCoA0KPGpjcz4NCkJ5IHN1YnNldCwgZG8geW91IHN1YmNsYXNzPw0KSWYgIkMiIGlz IGEgZnVsbHkgYXV0b25vbWljIG5vZGUsIHRoZW4gSSdtIGhhcHB5IGFuZCB1bmRlcnN0YW5kLiBJ ZiBub3QsIHRoZW4gSSdtIGNvbmZ1c2VkLg0KPC9qY3M+DQoNCk1COiBJJ20gbm90IHJlYWxseSBj b25zaWRlcmluZyBmdWxseSBhdXRvbm9taWMgbm9kZXMgZm9yIG5vdy4gV2Ugd29uJ3QgaGl0IHRo YXQgdGFyZ2V0IGZvciBhIGxvbmcgdGltZSwgc28gSSBhbHdheXMgYXNzdW1lIHBhcnRpYWxseSBh dXRvbm9taWMsIGllLCBjZXJ0YWluIGZ1bmN0aW9ucyBhcmUgYXV0b25vbWljLCBvdGhlcnMgbm90 LiBCdXQgSSB0aGluayAoISkgaXQncyBqdXN0IGEgcXVlc3Rpb24gb2Ygd29yZGluZywgYW5kIHdl J3JlIGFjdHVhbGx5IGluIHN5bmMuIFNheSwgZm9yIHRoZSBzYWtlIG9mIHRoZSBkaXNjdXNzaW9u IHRoYXQgQSBhbmQgQyBpbXBsZW1lbnQgYW4gYXV0b25vbWljIHJvdXRpbmcgZnVuY3Rpb24sIHdo aWNoIGlzIG5vdCBjb25maWd1cmVkIHRyYWRpdGlvbmFsbHkgYW55IG1vcmUuIEFsbCBwYXJhbWV0 ZXJzIGFyZSBuZWdvdGlhdGVkLCBhbmQgcG9saWN5IGlzIHNldCB0aHJvdWdoIGludGVudCBub3Qg Y29uZmlndXJhdGlvbi4gU28gdGhpcyBpcyBhIGZ1bGx5IGF1dG9ub21pYyBmdW5jdGlvbi4gVGhl IGZhY3QgdGhhdCBzYXkgUW9TIGlzIHN0aWxsIGNvbmZpZ3VyZWQgbWFudWFsbHkgdG8gbWUgaXMg bm90IHJlYWxseSByZWxldmFudCBoZXJlLiBUaG91Z2h0cz8gDQoNCi0tDQpJIHRoaW5rIGl04oCZ cyBwcmV0dHkgb2J2aW91cy4gSSBqdXN0IHdhbnQgdG8gcG9pbnQgb3V0IHRoYXQgaW4gb3VyIHRo aW5raW5nIHRoZXJlIGlzIGluZnJhc3RydWN0dXJlIGFuZCBhdXRvbm9taWMgc2VydmljZSBhZ2Vu dHMuIEFuIOKAnGF1dG9ub21pY2FsbHkgYXdhcmXigJ0gbm9kZSBNVVNUIGhhdmUgdGhlIEFOIGlu ZnJhc3RydWN0dXJlLCBhbmQgTUFZIGhhdmUgYXV0b25vbWljIHNlcnZpY2UgYWdlbnRzLiANCg0K PGpjcz4NClRoaXMgbWFrZXMgcGVyZmVjdCBzZW5zZS4NCkFnZW50cyBhcmUgb2J2aW91cyAtIGVu b3VnaCBzbyB0aGF0IEkgZm9yZ290IHRvIG1lbnRpb24gdGhlbSA6LSkNCkhvd2V2ZXIsIHNpbmNl IHlvdSBicmluZyB0aGVtIHVwLCBhcmUgeW91IGFzc3VtaW5nIGZ1bGwgRklQQSBjb21wbGlhbnQg YWdlbnRzLCBvciBzb21ldGhpbmcgZWxzZT8gTm90IGhhdmluZyBkZWNpZGVkIHlldCBpcyBmaW5l IHRvby4NCjwvamNzPg0KDQpNQjogTm90IGRlY2lkZWQgeWV0LiANCg0KLS0NCkJUVywgYW4g4oCc YXV0b25vbWljYWxseSB1bmF3YXJl4oCdIG5vZGUgaXMgbm90IGp1c3QgYSBkdW1iIHJvY2sgbGlr ZSBhIGh1Yi4gQWxzbyB0cmFkaXRpb25hbCBkZXZpY2VzIChlLmcuIHJvdXRlcnMpIHdoaWNoIGRv IG5vdCBzdXBwb3J0IHRoZSBBTiBpbmZyYXN0cnVjdHVyZSBmYWxsIGludG8gdGhhdCBjYXRlZ29y eS4gDQoNCjxqY3M+DQpBZ3JlZWQuIEkgd2FzIGdpdmluZyB0aGUgdHJhZGl0aW9uYWwgcm91dGVy IHRoZSBiZW5lZml0IG9mIHRoZSBkb3VidCA6LSkgYnV0IGZvciB0aGlzIHB1cnBvc2UsIHllcywg aXQgaXMgYSBkdW1iIHJvY2suDQo8L2pjcz4NCg0KVGhlbiwgSSBjb3VsZCBzYXkgdGhhdCBhbiBh dXRvbm9taWMgZnVuY3Rpb24gaXMgZWl0aGVyIGJlwqBzdXBwb3J0ZWQgZGlyZWN0bHkgYnkgYSBm dWxseSBhdXRvbm9taWMgbm9kZSwgb3IgYnVpbHQgZnJvbSBhIHNldCBvZsKgbm9kZXMgKHNvbWUg b2Ygd2hpY2ggYXJlIG5vdMKgY2FwYWJsZSBvZiBwZXJmb3JtaW5nIGF1dG9ub21pYyBmdW5jdGlv bnMpLg0KwqANCk1COiBJIHRoaW5rIHdoZW4geW91IHNheSDigJxhdXRvbm9taWMgZnVuY3Rpb27i gJ0geW91IG1lYW4gYSBmdW5jdGlvbiBhY3Jvc3MgdmFyaW91cyBub2RlcywgcmlnaHQ/IEluIG91 ciB3b3JkaW5nLCBhIG5vZGUgcnVucyBhbiBhdXRvbm9taWMgc2VydmljZSBhZ2VudC4gQSBncm91 cCBvZiBzdWNoIG5vZGVzIGltcGxlbWVudCBhbiBhdXRvbm9taWMgZnVuY3Rpb24uIA0KDQo8amNz Pg0KWWVzLCBhZ3JlZWQNCjwvamNzPg0KDQpTZWNvbmQgcXVlc3Rpb246IHBlcmZvcm1pbmcgYW4g YXV0b25vbWljIGZ1bmN0aW9uIGlzIGEgc2V0IG9mIGJlaGF2aW9ycy4gV2hhdCdzIGltcG9ydGFu dCBpcyB0aGUgZW5kIHJlc3VsdCwgbm90IHRoZSBpbmRpdmlkdWFsIGJlaGF2aW9ycy4gU28sIGFz IGxvbmcgYXMgZWFjaCBpbmRpdmlkdWFsIGJlaGF2aW9yIGNhbiBiZSByaWdvcm91c2x5IGRlZmlu ZWQgKGUuZy4sIHVzaW5nIGEgc29mdHdhcmUgY29udHJhY3QsIHdoZXJlIHRoZSBiZWhhdmlvciBz YXRpc2ZpZXMgYSBzZXQgb2YgcHJlLSBhbmQgcG9zdC1jb25kaXRpb25zIGFzIHdlbGwgYXMgYSBz ZXQgb2YgaW52YXJpYW50cyksIHRoZW4gKGluIHRoZW9yeSkgdGhleSBzaG91bGQgYmUgYWJsZSB0 byBiZSBjb21wb3NpdGVkIHRvZ2V0aGVyLg0KDQpXaGF04oCZcyB0aGUgcXVlc3Rpb24/IDstKcKg wqAgWWVzLCBJIGFncmVlLiBUaGUgQXV0b25vbWljIENvbnRyb2wgUGxhbmUgaXMgYW4gZXhhbXBs ZSBvZiB0aGlzLiBFYWNoIG5vZGVzIGNhcnJpZXMgb3V0IGEgZmV3IGxvY2FsIGFjdGlvbnMgKGF1 dGhlbnRpY2F0aW5nIG5laWdoYm9ycywgYnVpbGRpbmcgdHVubmVscyB0byB0aGVtLCBldGMpLCBh bmQgdGhlIG5ldCByZXN1bHQgaXMgYSBzZWxmLW1hbmFnaW5nIG92ZXJsYXkgbmV0d29yayB3aXRo IHNvbWUgbmljZSBwcm9wZXJ0aWVzLiANCg0KPGpjcz4NCk9vcHMsIHNvcnJ5LiBNeSBjYWZmZWlu ZS9ibG9vZCByYXRpbyBtdXN0IGhhdmUgYmVlbiB0b28gbG93LiA6LSkNCk15IHF1ZXN0aW9uIHdh cyBob3cgdGhlIGJlaGF2aW9ycyBhcmUgY29tcG9zaXRlZC4gV2hlbiBJIGJ1aWx0IHNpbWlsYXIg ZnVuY3Rpb25hbGl0eSwgSSB1c2VkIHNvZnR3YXJlIGNvbnRyYWN0cyB0byBtYW5hZ2UgdGhlIGZ1 bmN0aW9ucyBwZXJmb3JtZWQgYnkgdGhlIGFnZW50cy4gQXQgdGhlIHRpbWUsIEkgZGlkbid0IHNl ZSBtYW55IG90aGVyIGV4YW1wbGVzIG9mIHRoaXMsIHNvIEkgd2FzIGN1cmlvdXMgaWYgQU5JTUEg aGFkIHRob3VnaHQgYWJvdXQgaG93IHRvIHN0YW5kYXJkaXplIHRoZSBhZ2VudCBiZWhhdmlvcj8g V2l0aCBzb2Z0d2FyZSBjb250cmFjdHMsIHRoaXMgYmVjb21lcyBlYXNpZXIsIGFzIHRoZSBmdW5j dGlvbiBpcyBjaGFyYWN0ZXJpemVkIGJ5IHRoZSBjb250cmFjdC4gTWFrZSBzZW5zZT8NCjwvamNz Pg0KDQpNQjogV2UgYXJlbid0IHJlYWxseSB0aGF0IGZhciB5ZXQgaW4gQU5JTUEsIGJ1dCBzaG91 bGQgY2xlYXJseSBleHBsb3JlIHRoaXMgd2F5LiANCg0KVGhhbmtzIGZvciB5b3VyIGlucHV0IGFu ZCB2YWxpZGF0aW9uIG9mIG91ciB3b3JrIQ0KTWljaGFlbA0KwqANCjxqY3M+DQpJIG5vdyB1bmRl cnN0YW5kIGEgbG90IG1vcmUsIHRoYW5rcyB0byB5b3UsIEJyaWFuLCBhbmQgU2hlbmcgZm9yIHlv dXIgYW5zd2VycyBhbmQgcGF0aWVuY2UuIEkgdGhpbmsgdGhlIHdvcmsgaXMgcHJvbWlzaW5nLCBh bmQgd291bGQgbGlrZSB0byBwYXJ0aWNpcGF0ZS4NCjwvamNzPg0KDQpNQjogVGhhdCB3b3VsZCBi ZSBjb29sLiBXaWxsIHlvdSBiZSBpbiBEYWxsYXM/IA0KDQpNaWNoYWVsDQoNCg== From nobody Thu Mar 12 15:33: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 1C38A1A878E for ; Thu, 12 Mar 2015 15:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 lOA3v5gfsq0y for ; Thu, 12 Mar 2015 15:33:40 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::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 2B82F1A877A for ; Thu, 12 Mar 2015 15:33:40 -0700 (PDT) Received: by wiwl15 with SMTP id l15so7742465wiw.1 for ; Thu, 12 Mar 2015 15:33:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DgEeuMzLaNw8t8LSRmdq4l6ULhTOMCzh9Pj7vtASQC4=; b=j9GAxWmxwN3lCE8lkVVLkeXQu3y4b2REnl+wowcuIUAWs4YQQN+iQrmhBvl8CplET6 Qp6vlD+aWVwRxoGJYNv+nJ3RFKCfAbLew+3phwI2KuqB5hqSSh+1+/np5FNB+EPJwU8x nYockVGrvejmGjhKJOjakCBWyJTsVavLt/nrEbihDh2iByNWqpkGHRiOUjPp5O0osfDz afA7qjdilWKXmalStZiG/P5feJPEv3Gpa6Nh6nn+cIvM8P6KQZq2rWo4Y3ae1MOO3atO ZcvNgWdI/yKhFwmtDsfGlCWMVc8XfKE5iOoM4yxPrtshKPly5LE6VC3vGv2BdFyVKMNx v+dg== MIME-Version: 1.0 X-Received: by 10.194.59.112 with SMTP id y16mr93992574wjq.36.1426199618903; Thu, 12 Mar 2015 15:33:38 -0700 (PDT) Received: by 10.27.85.139 with HTTP; Thu, 12 Mar 2015 15:33:38 -0700 (PDT) In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22EF2620@xmb-rcd-x14.cisco.com> References: <5D36713D8A4E7348A7E10DF7437A4B923B059AD6@nkgeml512-mbx.china.huawei.com> <54FE67C3.9010804@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22EF05CD@xmb-rcd-x14.cisco.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22EF15FA@xmb-rcd-x14.cisco.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22EF2620@xmb-rcd-x14.cisco.com> Date: Thu, 12 Mar 2015 15:33:38 -0700 Message-ID: From: John Strassner To: "Michael Behringer (mbehring)" Content-Type: multipart/alternative; boundary=047d7ba97cc4a9e5e805111ef957 Archived-At: Cc: Anima WG , John Strassner , "Liubing \(Leo\)" Subject: Re: [Anima] Some comments for draft-carpenter-anima-gdn-protocol 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, 12 Mar 2015 22:33:43 -0000 --047d7ba97cc4a9e5e805111ef957 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hallo Michael,... replies inline, look for .. best regards, John On Thu, Mar 12, 2015 at 5:18 AM, Michael Behringer (mbehring) < mbehring@cisco.com> wrote: > [...] > Point a) is a subset of b). Example: topology is A----B----C. All nodes > support the AN infrastructure. A and C should be able to negotiate > parameters for an autonomic service agents, even if B doesn=E2=80=99t imp= lement > that function. > > > By subset, do you subclass? > If "C" is a fully autonomic node, then I'm happy and understand. If not, > then I'm confused. > > > MB: I'm not really considering fully autonomic nodes for now. We won't hi= t > that target for a long time, so I always assume partially autonomic, ie, > certain functions are autonomic, others not. But I think (!) it's just a > question of wording, and we're actually in sync. Say, for the sake of the > discussion that A and C implement an autonomic routing function, which is > not configured traditionally any more. All parameters are negotiated, and > policy is set through intent not configuration. So this is a fully > autonomic function. The fact that say QoS is still configured manually to > me is not really relevant here. Thoughts? > I completely agree. I've always felt that the purpose of autonomic functions is to augment and simplify, not to rip and replace. So in your example, the fact that part of the behavior is now easier to configure and manage is great! We don't need to solve everything at once. > > -- > I think it=E2=80=99s pretty obvious. I just want to point out that in our= thinking > there is infrastructure and autonomic service agents. An =E2=80=9Cautonom= ically > aware=E2=80=9D node MUST have the AN infrastructure, and MAY have autonom= ic service > agents. > > > This makes perfect sense. > Agents are obvious - enough so that I forgot to mention them :-) > However, since you bring them up, are you assuming full FIPA compliant > agents, or something else? Not having decided yet is fine too. > > > MB: Not decided yet. > No worries. I know FIPA well, and can help translate it. :-) That being said, I have no strong opinions about whether we should make it compliant or not. > > -- > BTW, an =E2=80=9Cautonomically unaware=E2=80=9D node is not just a dumb r= ock like a hub. > Also traditional devices (e.g. routers) which do not support the AN > infrastructure fall into that category. > > > Agreed. I was giving the traditional router the benefit of the doubt :-) > but for this purpose, yes, it is a dumb rock. > > > Then, I could say that an autonomic function is either be supported > directly by a fully autonomic node, or built from a set of nodes (some of > which are not capable of performing autonomic functions). > > MB: I think when you say =E2=80=9Cautonomic function=E2=80=9D you mean a = function across > various nodes, right? In our wording, a node runs an autonomic service > agent. A group of such nodes implement an autonomic function. > > > Yes, agreed > > > Second question: performing an autonomic function is a set of behaviors. > What's important is the end result, not the individual behaviors. So, as > long as each individual behavior can be rigorously defined (e.g., using a > software contract, where the behavior satisfies a set of pre- and > post-conditions as well as a set of invariants), then (in theory) they > should be able to be composited together. > > What=E2=80=99s the question? ;-) Yes, I agree. The Autonomic Control Pl= ane is an > example of this. Each nodes carries out a few local actions (authenticati= ng > neighbors, building tunnels to them, etc), and the net result is a > self-managing overlay network with some nice properties. > > > Oops, sorry. My caffeine/blood ratio must have been too low. :-) > My question was how the behaviors are composited. When I built similar > functionality, I used software contracts to manage the functions performe= d > by the agents. At the time, I didn't see many other examples of this, so = I > was curious if ANIMA had thought about how to standardize the agent > behavior? With software contracts, this becomes easier, as the function i= s > characterized by the contract. Make sense? > > > MB: We aren't really that far yet in ANIMA, but should clearly explore > this way. > > Thanks for your input and validation of our work! > Michael > > > I now understand a lot more, thanks to you, Brian, and Sheng for your > answers and patience. I think the work is promising, and would like to > participate. > > > MB: That would be cool. Will you be in Dallas? > Yes, I will be there for both sessions. > > Michael > > --=20 regards, John --047d7ba97cc4a9e5e805111ef957 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hallo Michael,...
replies inline, look for <jcs2>..<= ;/jcs2>

best regards,
John
=
On Thu, Mar 12, 2015 at 5:18 AM, Micha= el Behringer (mbehring) <mbehring@cisco.com> wrote:
[...]
Point a) is a subset of b). Example: topology is A----B----C. All nodes sup= port the AN infrastructure. A and C should be able to negotiate parameters = for an autonomic service agents, even if B doesn=E2=80=99t implement that f= unction.
=C2=A0
<jcs>
By subset, do you subclass?
If "C" is a fully autonomic node, then I'm happy and understa= nd. If not, then I'm confused.
</jcs>

MB: I'm not really considering fully autonomic nodes for now. We won= 9;t hit that target for a long time, so I always assume partially autonomic= , ie, certain functions are autonomic, others not. But I think (!) it's= just a question of wording, and we're actually in sync. Say, for the s= ake of the discussion that A and C implement an autonomic routing function,= which is not configured traditionally any more. All parameters are negotia= ted, and policy is set through intent not configuration. So this is a fully= autonomic function. The fact that say QoS is still configured manually to = me is not really relevant here. Thoughts?

<jcs>
I completely agree. I've always felt that the = purpose of autonomic functions is to augment and simplify, not to rip and r= eplace. So in your example, the fact that part of the behavior is now easie= r to configure and manage is great! We don't need to solve everything a= t once.
</jcs>=C2=A0

--
I think it=E2=80=99s pretty obvious. I just want to point out that in our t= hinking there is infrastructure and autonomic service agents. An =E2=80=9Ca= utonomically aware=E2=80=9D node MUST have the AN infrastructure, and MAY h= ave autonomic service agents.

<jcs>
This makes perfect sense.
Agents are obvious - enough so that I forgot to mention them :-)
However, since you bring them up, are you assuming full FIPA compliant agen= ts, or something else? Not having decided yet is fine too.
</jcs>

MB: Not decided yet.
<jcs>
No worries.= I know FIPA well, and can help translate it. :-) That being said, I have n= o strong opinions about whether we should make it compliant or not.
</jcs>=C2=A0

--
BTW, an =E2=80=9Cautonomically unaware=E2=80=9D node is not just a dumb roc= k like a hub. Also traditional devices (e.g. routers) which do not support = the AN infrastructure fall into that category.

<jcs>
Agreed. I was giving the traditional router the benefit of the doubt :-) bu= t for this purpose, yes, it is a dumb rock.
</jcs>

Then, I could say that an autonomic function is either be=C2=A0supported di= rectly by a fully autonomic node, or built from a set of=C2=A0nodes (some o= f which are not=C2=A0capable of performing autonomic functions).
=C2=A0
MB: I think when you say =E2=80=9Cautonomic function=E2=80=9D you mean a fu= nction across various nodes, right? In our wording, a node runs an autonomi= c service agent. A group of such nodes implement an autonomic function.

<jcs>
Yes, agreed
</jcs>

Second question: performing an autonomic function is a set of behaviors. Wh= at's important is the end result, not the individual behaviors. So, as = long as each individual behavior can be rigorously defined (e.g., using a s= oftware contract, where the behavior satisfies a set of pre- and post-condi= tions as well as a set of invariants), then (in theory) they should be able= to be composited together.

What=E2=80=99s the question? ;-)=C2=A0=C2=A0 Yes, I agree. The Autonomic Co= ntrol Plane is an example of this. Each nodes carries out a few local actio= ns (authenticating neighbors, building tunnels to them, etc), and the net r= esult is a self-managing overlay network with some nice properties.

<jcs>
Oops, sorry. My caffeine/blood ratio must have been too low. :-)
My question was how the behaviors are composited. When I built similar func= tionality, I used software contracts to manage the functions performed by t= he agents. At the time, I didn't see many other examples of this, so I = was curious if ANIMA had thought about how to standardize the agent behavio= r? With software contracts, this becomes easier, as the function is charact= erized by the contract. Make sense?
</jcs>

MB: We aren't really that far yet in ANIMA, but should clearly explore = this way.

Thanks for your input and validation of our work!
Michael
=C2=A0
<jcs>
I now understand a lot more, thanks to you, Brian, and Sheng for your answe= rs and patience. I think the work is promising, and would like to participa= te.
</jcs>

MB: That would be cool. Will you be in Dallas?
<jcs= >
Yes, I will be there for both sessions.
</jcs&g= t;=C2=A0

Michael




--
regards,
John
--047d7ba97cc4a9e5e805111ef957-- From nobody Fri Mar 13 02:26: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 21B8E1A06E9 for ; Fri, 13 Mar 2015 02:26: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 ZA8DcpIlz6LI for ; Fri, 13 Mar 2015 02:26:53 -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 B545E1A1B7C for ; Fri, 13 Mar 2015 02:26:52 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQE90972; Fri, 13 Mar 2015 09:26:51 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 13 Mar 2015 09:26:48 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.106]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Fri, 13 Mar 2015 17:26:43 +0800 From: Sheng Jiang To: "anima@ietf.org" Thread-Topic: Final agenda and chair's slides - ANIMA WG Thread-Index: AdBdb8slahat6IZiRSaKdmhPGEpfrQ== Date: Fri, 13 Mar 2015 09:26:42 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923B05EA3B@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: Subject: [Anima] Final agenda and chair's slides - ANIMA WG 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, 13 Mar 2015 09:26:54 -0000 SGksIGFsbCwNCg0KVGhlIGNoYWlycyBoYXZlIGZpbmFsaXplZCB0aGUgYWdlbmRhIGZvciBvdXIg QU5JTUEgV0cgc2Vzc2lvbnMuIFBsZWFzZSBzZWUgYmVsb3cgbGluay4NCg0KaHR0cDovL3Rvb2xz LmlldGYub3JnL3dnL2FuaW1hL2FnZW5kYQ0KDQpXZSBhbHNvIHVwbG9hZCBvdXIgY2hhaXIncyBz bGlkZXMsIHdoaWNoIGNhbiBiZSBmb3VuZCBpbiB0aGUgSUVURiBtYXRlcmlhbCBwYWdlLg0KDQpo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvOTIvbWF0ZXJpYWxzLmh0bWwNCg0K U2VlIHlvdSBhbGwgaW4gRGFsbGFzIQ0KDQpCZXN0IHJlZ2FyZHMsDQoNClNoZW5nICsgVG9lcmxl c3MNCg== From nobody Mon Mar 16 18:38:36 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 C32B51ACDCE for ; Mon, 16 Mar 2015 18:38:28 -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 uSkCn-glNSde for ; Mon, 16 Mar 2015 18:38:25 -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 5098B1A90AB for ; Mon, 16 Mar 2015 18:38:25 -0700 (PDT) Received: by pacwe9 with SMTP id we9so81614592pac.1 for ; Mon, 16 Mar 2015 18:38:25 -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=lXop3Znz1WOaP8+IdNxDTVpuS8T30V0MJ6JdIvkDiRg=; b=QwKJf8oeiA7gA6paLGYtSNdeq8NcO8mqWq1s27p94O+U1yser0YCJAlR2jdMMYIXUv 75uMk6jmXEX+kRXBA36VDNQvhEVzdDS429boOmUWkE1qgTHdWR9dh2uPZsrcGcZrVJac Bv2bydoAleFOOAwrl5zOsQXpfZOLRysdXdRBU30eUfYanbl7LS0IEkrWfeApn5nVoEcp a/J8afqLMvuGYHsz+xKt9DGZtMIp1lTp87mAkTSZzXMWRmSPxejazxdRa8KuJnYJK40U GKmW6tKd6ZmemADHsrl4pc6n3mnZnFXy0eqBxHicpwqxv8UYpahTwZ7g/XQlX7v7sa9g VfaQ== X-Received: by 10.70.31.66 with SMTP id y2mr81709509pdh.118.1426556304988; Mon, 16 Mar 2015 18:38:24 -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 m1sm16138908pdo.65.2015.03.16.18.38.21 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Mar 2015 18:38:23 -0700 (PDT) Message-ID: <5507858E.4010006@gmail.com> Date: Tue, 17 Mar 2015 14:38:22 +1300 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.5.0 MIME-Version: 1.0 To: Sheng Jiang , Ted Lemon References: <54F50116.9000501@gmail.com> <46E8AE45-3B6A-4CA0-92EA-F5E463C1D47C@fugue.com> <54F5205C.9020302@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B923B054B46@nkgeml512-mbx.china.huawei.com> <295A41C5-166E-4AF4-A04D-83A575CEA277@fugue.com> <5D36713D8A4E7348A7E10DF7437A4B923B05522F@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923B05522F@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Anima WG Subject: Re: [Anima] DNA 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, 17 Mar 2015 01:38:29 -0000 Getting back to this: It seems to me that while we have no plans to write an Autonomic Node Requirements draft any time soon, the expectation that nodes should run DNA belongs for now in draft-behringer-anima-reference-model-00 Regards Brian On 04/03/2015 13:38, Sheng Jiang wrote: >> On Mar 2, 2015, at 10:23 PM, Sheng Jiang wrote: >>> Where can we make them mandatory? Yes, they are reasonable functions >> for autonomic nodes. But we do not have an integrated requirements for >> autonomic nodes, neither for autonomic network architecture. The only >> opinion I can think out is to redesign the mechanisms and try to embed them >> into ANIMA Protocols, for which I don't think is right thing to do. >> >> Why not make the ones that are dependable mandatory? Do you think that >> layer 2 stuff shouldn't be mentioned in Anima documents? > > Of course, there is no any restriction that layer 2 stuff shouldn't be mentioned in Anima documents. My point was there is not a suitable document in our current plan deliverables to contain this mandatory. We do not have a document for requirements of ANIMA devices, neither for ANIMA architecture. Reference model may be a document to mention it, but it is an informational document, which cannot make any mandatory requirements. > > Of course, we can have a new document for this and for other requirements of ANIMA devices. And we could make it milestone later with approval from the responsible Area Director or by re-chartering. But I don't think we have know enough to make a full requirements yet. > > Best regards, > > Sheng > >> DNA makes >> stacks' behavior a lot better in general, although occasionally it can result in >> unnecessary brief outages when a cable is unplugged and plugged back in to >> the same network, but for Anima devices isn't this kind of a non-problem? >> >> _______________________________________________ >> 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 Sun Mar 22 14:50: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 0D9361A1EE8 for ; Sun, 22 Mar 2015 14:50:27 -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 Lalp26b3br2L for ; Sun, 22 Mar 2015 14:50:24 -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 D19AA1A1EEC for ; Sun, 22 Mar 2015 14:50:22 -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 BQO81205; Sun, 22 Mar 2015 21:50:21 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 22 Mar 2015 21:50:21 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.168]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Mon, 23 Mar 2015 05:50:16 +0800 From: Sheng Jiang To: "anima@ietf.org" Thread-Topic: minutes taker and jabber scriber needed Thread-Index: AQHQZOoufwQ8Lm8x9E2imMloeYpJrg== Date: Sun, 22 Mar 2015 21:50:16 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B925F4A3E47@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.146.169] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "anima-chairs@tools.ietf.org" Subject: [Anima] minutes taker and jabber scriber needed 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, 22 Mar 2015 21:50:27 -0000 Hi, all, We need a minute taker and a jabber scribe for our sessions. Please volunt= eer by emailing/contacting chairs. One may volunteer for only one out of tw= o our sessions. Many thanks and best regards, Sheng + Toerless= From nobody Mon Mar 23 09:05: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 D6C961AC3D3 for ; Mon, 23 Mar 2015 09:05: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 Az5loBpxb8Y2 for ; Mon, 23 Mar 2015 09:05:48 -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 0035A1AC3C8 for ; Mon, 23 Mar 2015 09:05:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2610; q=dns/txt; s=iport; t=1427126748; x=1428336348; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=3DDFU7o6ip74+RjddLRBd9Pq+QPb3P0St1tefdnxtIo=; b=L2C1sScHdfm1x+Aue9glZ7l1ahu3CwZ4tjKbaSKcaxpl25XDIu3kYIOR 0xRwp24EGJhxzXBeT0zQjOumzvqys5sWkp99+R2NHoTo1kmTm6aq3o50g dtUhOiGHh8u6D353FeNTod1tcrlFhDoQICJWsZ3jeKh5hT4DaLOZF4zIi 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AJBQAPORBV/4gNJK1cgwaBLMxFAoEpTAEBAQEBAX2EFAEBAQQdHT8MBAsRBAEBAQkeBw8FDSUJDhOIGwMRwnkNhT4BAQEBAQEBAQEBAQEBAQEBAQEBAQEXiyGCRoIvBwaDEYEWBYsSjV+BSwGBG4wcTIJgg0ciggIcgXAeMQGCQgEBAQ X-IronPort-AV: E=Sophos;i="5.11,452,1422921600"; d="scan'208";a="134620151" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-5.cisco.com with ESMTP; 23 Mar 2015 16:05:47 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t2NG5kYx003965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Mar 2015 16:05:47 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 t2NG5kZV008540; Mon, 23 Mar 2015 09:05:46 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t2NG5iuq008536; Mon, 23 Mar 2015 09:05:44 -0700 Date: Mon, 23 Mar 2015 09:05:44 -0700 From: Toerless Eckert To: Sheng Jiang Message-ID: <20150323160544.GB6810@cisco.com> References: <5D36713D8A4E7348A7E10DF7437A4B923B0455C9@nkgeml512-mbx.china.huawei.com> <02817548-0AD9-4AE4-B5B1-F97B53C5154E@iki.fi> <54E24207.5000803@gmail.com> <082248A1-BB56-43B4-972D-4F9CA1980FCF@iki.fi> <54E39160.5070607@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B923B053D5D@nkgeml512-mbx.china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923B053D5D@nkgeml512-mbx.china.huawei.com> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Markus Stenberg , "anima@ietf.org" , "anima-chairs@tools.ietf.org" Subject: Re: [Anima] DNCP + X != GDNP [ Call for agenda ANIMA @ IETF92] 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, 23 Mar 2015 16:05:53 -0000 Did you decide to have a pre-meeting ? If so and you did not have it yet, le me know, i would be happy to join as well. Cheers Toerless On Mon, Mar 02, 2015 at 08:18:57AM +0000, Sheng Jiang wrote: > Hi, Brian and Markus, > > I will arrange your presentation next to each other and have a combined mic discussion afterwards. We should have around time together. I also encourage you and the other coauthors of these two documents to have a pre-meeting discussion in Dallas. I would like to join you, too. > > Best regards, > > Sheng > > >-----Original Message----- > >From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > >Sent: Wednesday, February 18, 2015 3:07 AM > >To: Markus Stenberg > >Cc: Sheng Jiang; anima@ietf.org; anima-chairs@tools.ietf.org > >Subject: Re: DNCP + X != GDNP [ Call for agenda ANIMA @ IETF92] > > > >On 17/02/2015 19:30, Markus Stenberg wrote: > >> On 16.2.2015, at 21.16, Brian E Carpenter > >wrote: > >>> As for the number of pages of text, I think that mainly depends where > >>> you choose to write down the details, including background information, > >>> requirements, theory of operation and alternatives. We chose to put all > >>> of it into one document for GDNP. > >> > >> Yes, GDNP spec is heavy on theory/requirements (and comparisons to some > >degree). > >> > >> However, given the document, it is completely unclear to me how it would > >work in practise (and given the latitude allowed to the individual objectives, > >perhaps intentionally so). The TODO list is a (partial) indicator of that. > > > >There will be a new version soon where the TO DO list is quite a bit shorter, > >and hopefully there will be time in Dallas for a protocol walk-through, but > >you are correct, we are intentionally being generic in this draft. > > > >> I do not mind the theory/requirements parts (they are skippable if not > >interested in them after all), but the lack of concrete > >detail I find somewhat distracting. > >> > >> Perhaps it is just a difference of opinion on what should be the leading part > >of an effort ;) > > > >I know exactly what you mean. Remember that there is some prototype code, > >though. > >The next version does (IMNSHO) tie down a lot more details, to the point > >where > >I feel I could at least write a pseudo-code version of the whole thing. And my > >co-author is on the hook to update the prototype code when time permits. > > > > Brian > > > >> Cheers, > >> > >> -Markus > >> > >> -- --- Toerless Eckert, eckert@cisco.com From nobody Mon Mar 23 12:11: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 CB8851AD2EE for ; Mon, 23 Mar 2015 12:11: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 YdoEcGMivxsK for ; Mon, 23 Mar 2015 12:11:36 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E50EE1AD244 for ; Mon, 23 Mar 2015 12:11:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2253; q=dns/txt; s=iport; t=1427137896; x=1428347496; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=C8CQyIDTCEFH2n1JI5eL7wVmbEA1Bl/+aQfUSdhwk1k=; b=NDoREcDOpmXmwNO7XKILhvZ0sTRmGavgqZVpXbLz2DaM4lfhvu20spOi rdWCOBd9ITZNyIRvuqzcq0+OZuF3dFidI0DF3y0wjF8/SwhMmraK/lniX skBimED3LrUGXQ37O6FDv/AuPWNx3ilo/ETQwSCKY1kuEa5NjOee+NQnj I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ANBQC+ZBBV/xPFo0hcgwZSWsZICoV1AoEuTAEBAQEBAX2EFAEBAQMBAQEBNzQLBQsLDgoJDBkPBQ0GNhMbiAADCQgNwnMNhT4BAQEBAQEBAQEBAQEBAQEBAQEBAQETBIshgkaCLwcKgw2BFgWLEo1fgUsBjgOGJyKEDh4xAYJCAQEB X-IronPort-AV: E=Sophos;i="5.11,453,1422921600"; d="scan'208";a="398585375" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by aer-iport-2.cisco.com with ESMTP; 23 Mar 2015 19:11:33 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by bgl-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t2NJBTfl010262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Mar 2015 19:11:31 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 t2NJBN30021118; Mon, 23 Mar 2015 12:11:23 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t2NJBNUf021117; Mon, 23 Mar 2015 12:11:23 -0700 Date: Mon, 23 Mar 2015 12:11:23 -0700 From: Toerless Eckert To: James Woodyatt Message-ID: <20150323191123.GA19342@cisco.com> References: <20150306163647.31030.58285.idtracker@ietfa.amsl.com> <54FA045C.6090604@gmail.com> <14941.1425856560@sandelman.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Anima WG Subject: Re: [Anima] I-D Action: draft-eckert-anima-stable-connectivity-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: Mon, 23 Mar 2015 19:11:38 -0000 Inline, On Mon, Mar 09, 2015 at 12:28:12PM -0700, James Woodyatt wrote: > I can see an argument here for a registry, but not one for an assignment > authority. Yes, i was also wondering if there was a more lightweight solution than assignment. > It is not at all clear to me how a central assignment authority > can operate with even less risk of duplication than the already epsilon > level of risk in the random self-assignment of RFC 4193. What are existing cases of duplication through assignment ? Also: can you define how "self registration" should work ? Eg: Thinking about this i couldn't get up with a better scheme than taking money, or else you have trolls depleting the space. And once you take money, could you really give less "guarantees" than you have to give in the "assignment" case ? Self registrastion portal at ulac.internetsociety.org, $20 to create an account, $20 for every registered prefix, can only look up a prefix (not search, not list prefixes) when you have an account ? Still looks a lot like assignment... > This statement > appears to take it as axiomatic, and I think it's very debatable. Any suggestions for better text welcome. Thanks! Toerless > On Sun, Mar 8, 2015 at 4:16 PM, Michael Richardson wrote: > > > > > Brian E Carpenter wrote: > > > Just one comment. I'm not sure it's very useful to mention ULA-C, > > since > > > no such thing has been standardised; RFC 4193 doesn't even hint at it > > > beyond saying "Another method, indicated by clearing the L bit, may > > be > > > defined later." I think the discussion will just confuse readers. > > > > I take it differently: I think that this is a reason to document ULA-C. > > > > > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > > > > > -- > james woodyatt > Nest Labs, Communications Engineering > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- Toerless Eckert, eckert@cisco.com From nobody Mon Mar 23 12:40: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 CBA581B29E2 for ; Mon, 23 Mar 2015 12:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_44=0.6, 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 dg05TZDAHIP2 for ; Mon, 23 Mar 2015 12:39:57 -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 C045D1B29D4 for ; Mon, 23 Mar 2015 12:39:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4131; q=dns/txt; s=iport; t=1427139597; x=1428349197; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=yfVdxALYfGFpLEEoR5SugspT6bWYRyZcKCM6Yyi5hAo=; b=lUbX2WD704RqkcabGUqS0y1e9Hmb+MohILGza3ETd7i3/QJjnHFfvJkV UQ+RnsiuA1X9SpP2BSlf57sIkFHuWoY8UA0uBI1a0ALPm16vkVLogic5M d3NwMSSSk93mG4PSB/STOp23P33nV7G2Mv7cmsDPaC8Ay8CZxKpUlijJO g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ANBQD8ahBV/5ldJa1cgwZSWsZJCoV1AoEuTAEBAQEBAX2EFAEBAQQBAQEVGgE7CwwECxEEAQEBCR4HDwUTHwkOEwmIJg3IPwEBAQEBAQEBAQEBAQEBAQEBAQEBAReLIYJdghgHBoMRgRYFixKJLIV+AYEbOoJ2jBiDRyKEDh4xAYJCAQEB X-IronPort-AV: E=Sophos;i="5.11,453,1422921600"; d="scan'208";a="405976613" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 23 Mar 2015 19:39:56 +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 t2NJdtJE014419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Mar 2015 19:39:55 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 t2NJdsr1023108; Mon, 23 Mar 2015 12:39:54 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t2NJdr7o023107; Mon, 23 Mar 2015 12:39:53 -0700 Date: Mon, 23 Mar 2015 12:39:53 -0700 From: Toerless Eckert To: Sheng Jiang Message-ID: <20150323193953.GB19342@cisco.com> References: <5D36713D8A4E7348A7E10DF7437A4B923B05BD1B@nkgeml512-mbx.china.huawei.com> <55004A59.1070607@braga.eti.br> <5D36713D8A4E7348A7E10DF7437A4B923B05DFE8@nkgeml512-mbx.china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923B05DFE8@nkgeml512-mbx.china.huawei.com> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Juliao Braga , "anima@ietf.org" Subject: Re: [Anima] remote participation (Primary agenda for ANIMA sessions in 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: Mon, 23 Mar 2015 19:39:59 -0000 I think the oficial URL is this: http://www.ietf.org/meeting/92/remote-participation.html Cheers Toerless On Thu, Mar 12, 2015 at 03:09:32AM +0000, Sheng Jiang wrote: > As regular, we have Meetecho and Jabber (Jabber scribe is needed, please volunteer). Remote presentation may need additional arrangement (so far, I don't know any in anima sessions). IETF provides real time audio stream for all meeting rooms. You can access from the tools-style agenda page. > > Jabber Room: anima@jabber.ietf.org > Meetecho: http://www.meetecho.com/ietf92/anima > > http://tools.ietf.org/agenda/92/ > > Best regards, > > Sheng > > >-----Original Message----- > >From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Juliao Braga > >Sent: Wednesday, March 11, 2015 10:00 PM > >To: anima@ietf.org > >Subject: Re: [Anima] Primary agenda for ANIMA sessions in IETF 92 > > > >We will have facilities for remote participation? > > > >Tks, > > > >Julião > > > >On 10/03/2015 00:24, Sheng Jiang wrote: > >> Hi, all, > >> > >> The ANIMA WG chairs have uploaded a primary agenda for ANIMA session > >in IETF 92, as the below link and attachment. As stated before, the Tuesday > >2-hour session is dedicated for urgent WG milestones; the Friday 1.5-hour > >session is mainly for other work items relevant to autonomic network but not > >in urgent WG milestones. > >> > >> http://www.ietf.org/proceedings/92/agenda/agenda-92-anima > >> > >> The primary agenda is still a subject to change. So, you may give your > >suggestions. The chairs may adjust accordingly if possible. We are expecting > >to finalize the agenda at the end of this week. > >> > >> Best regards, > >> > >> Sheng + Toerless > >> > >> ANIMA WG Agenda for IETF-92 (Dallas) > >> Autonomic Networking Integrated Model and Approach > >> Chairs: Toerless Eckert & Sheng Jiang > >> > >> The Tuesday 2-hour session is dedicated for urgent WG milestones; > >> the Friday 1.5-hour session is mainly for other work items > >> relevant to autonomic network but not in urgent WG milestones. > >> > >> > >> Tuesday (March 24, 2015) 2-hour session: > >> 1520-1720 Afternoon Session II, Oak > >> WG Dash 5 min > >> Discovery and negotiation function - 45 min > >> Generic Discovery and Negotiation Protocol - 20 min > >> (Brian Carpenter, Confirmed) > >> Autonomic Distributed Node Consensus Protocol - 10 min > >> (Markus Stenberg, Confirmed) > >> Combine discussion for GDNP&DNCP - 15 min > >> Auto bootstrapping - 45 min > >> Bootstrapping-keyinfra - 15 min > >> (Max Pritikin, Confirmed) > >> Zero touch - 10 min > >> (Confirmation needed) > >> Survey of Security Bootstrapping - 10 min > >> (Danping He, Confirmed) > >> Combine discussion - 10 min > >> Autonomic Control Plane & Discussion - 25 min > >> (Michael Behringer, Confirmed) > >> > >> > >> Friday (March 27, 2015) 1.5-hour session > >> 1150-1320 Afternoon Session I, Parisian > >> Reference model - 20 min > >> (Michael Behringer, Confirmed) > >> Observations on bootstrapping and synchronization - 15 min > >> (Rene Struik, Confirm) > >> Coordinating multiple (conflicting) autonomic functions - 15 min > >> (Laurent Ciavaglia, Confirmed) > >> Self-Managed Networks with Fault Management Hierarchy - 15 min > >> (Toy Mehmet, Confirmed) > >> Predictive risk awareness for proactive management - 15 min > >> (Laurent Ciavaglia, Confirmed) > >> _______________________________________________ > >> 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 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- Toerless Eckert, eckert@cisco.com From nobody Mon Mar 23 13:01:25 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 010AE1A044F for ; Mon, 23 Mar 2015 13:01: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 gURgcAkGg_JN for ; Mon, 23 Mar 2015 13:01:22 -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 509191A0282 for ; Mon, 23 Mar 2015 13:01:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1783; q=dns/txt; s=iport; t=1427140883; x=1428350483; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=GeneYQJLeTAjemd6zmANZuQN9KUJ7crNElyLApaX8C4=; b=ljCi3YIBpsQwPNAWn6ujU6lFA2Xa0sKzloRT/D/Q4zV/53TnHaHxpqEj yRBEbn5KP7nKVXSnqVOY4DVmv31MPqa14Ox9UFnsZ3u2+AfJMyjXlHZpZ K3TGVsW9RJB2i4jQH9TgYqJS+TFpNH5QvbJRRdFVd7FfLuTw82kxjvgEN M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AMBQCUcBBV/4UNJK1cgwZSWsZJCoV1AoEuTAEBAQEBAX2EFQEBBAEBATc0CxALGAklDwUNBjYTiBsDEQ3CcQ2FPgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEiyGCRoIvB4MXgRYFixKNX4FLAY4DhiciggIcFIFcHjEBgkIBAQE X-IronPort-AV: E=Sophos;i="5.11,453,1422921600"; d="scan'208";a="134634789" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-1.cisco.com with ESMTP; 23 Mar 2015 20:01:22 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t2NK1LF3000600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Mar 2015 20:01: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 t2NK1KSW024513; Mon, 23 Mar 2015 13:01:20 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t2NK1Ktp024511; Mon, 23 Mar 2015 13:01:20 -0700 Date: Mon, 23 Mar 2015 13:01:20 -0700 From: Toerless Eckert To: Brian E Carpenter Message-ID: <20150323200120.GC19342@cisco.com> References: <20150306163647.31030.58285.idtracker@ietfa.amsl.com> <54FA045C.6090604@gmail.com> <14941.1425856560@sandelman.ca> <54FDFD52.4070005@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54FDFD52.4070005@gmail.com> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: James Woodyatt , Anima WG Subject: Re: [Anima] ULA registry [ I-D Action: draft-eckert-anima-stable-connectivity-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: Mon, 23 Mar 2015 20:01:24 -0000 On Tue, Mar 10, 2015 at 09:06:42AM +1300, Brian E Carpenter wrote: > It is. In fact, IMHO the best approach if you want a registry is the one > which already has running code (but would need to be operated under IANA > authority to be reasonably reliable): > https://www.sixxs.net/tools/grh/ula/ > In any case this isn't an Anima problem and it is already proving a distraction > here ;-) Nice. I just worry about this being abused when it becomes more successful to the extend that somebody needs to earn money from it to harden it. And as i said, taking in money also reduces the attack vectors. Cheers Toerles > > Brian > > > > > On Sun, Mar 8, 2015 at 4:16 PM, Michael Richardson wrote: > > > >> > >> Brian E Carpenter wrote: > >> > Just one comment. I'm not sure it's very useful to mention ULA-C, > >> since > >> > no such thing has been standardised; RFC 4193 doesn't even hint at it > >> > beyond saying "Another method, indicated by clearing the L bit, may > >> be > >> > defined later." I think the discussion will just confuse readers. > >> > >> I take it differently: I think that this is a reason to document ULA-C. > >> > >> > >> > >> _______________________________________________ > >> 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 > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- Toerless Eckert, eckert@cisco.com From nobody Mon Mar 23 16:36: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 E18331A3BA2 for ; Mon, 23 Mar 2015 16:36:37 -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 wVewdrYXKYZX for ; Mon, 23 Mar 2015 16:36:36 -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 14ED21A3BA1 for ; Mon, 23 Mar 2015 16:36:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQP94244; Mon, 23 Mar 2015 23:36:34 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 23 Mar 2015 23:36:33 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.168]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Tue, 24 Mar 2015 07:36:29 +0800 From: Sheng Jiang To: "anima@ietf.org" Thread-Topic: Slides for Tuesday session Thread-Index: AdBlwi9s4rLHQGn6SdyuwryxG81KmA== Date: Mon, 23 Mar 2015 23:36:28 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B925F4A666E@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.146.205] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "anima-chairs@tools.ietf.org" Subject: [Anima] Slides for Tuesday session 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, 23 Mar 2015 23:36:38 -0000 Hi, all, We have uploaded all slides for our Tuesday session. Please read them (and = the drafts) before the ANIMA meeting, so that we could have good discussion= s there. Best regards, Sheng + Toerless= From nobody Mon Mar 23 16:41: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 B10E01A6F01 for ; Mon, 23 Mar 2015 16:41:31 -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 n0qBp7OvztpC for ; Mon, 23 Mar 2015 16:41:30 -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 D64441A6EF9 for ; Mon, 23 Mar 2015 16:41:29 -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 BUB04699; Mon, 23 Mar 2015 23:41:28 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 23 Mar 2015 23:41:27 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.168]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Tue, 24 Mar 2015 07:41:21 +0800 From: Sheng Jiang To: "anima@ietf.org" Thread-Topic: URL//RE: Slides for Tuesday session Thread-Index: AQHQZcLdQcgE4WIYpU6a3/0d+osNeg== Date: Mon, 23 Mar 2015 23:41:20 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B925F4A667D@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.146.205] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "anima-chairs@tools.ietf.org" Subject: [Anima] URL//RE: Slides for Tuesday session 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, 23 Mar 2015 23:41:31 -0000 A pointer for the proceeding web page. https://www.ietf.org/proceedings/92/anima.html Sheng ________________________________________ From: Sheng Jiang Sent: 24 March 2015 7:36 To: anima@ietf.org Cc: anima-chairs@tools.ietf.org Subject: Slides for Tuesday session Hi, all, We have uploaded all slides for our Tuesday session. Please read them (and = the drafts) before the ANIMA meeting, so that we could have good discussion= s there. Best regards, Sheng + Toerless= From nobody Tue Mar 24 07:39: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 DF3381A87A0 for ; Tue, 24 Mar 2015 07:39: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 Ch4c3THbSu06 for ; Tue, 24 Mar 2015 07:38:52 -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 D7E041A87C8 for ; Tue, 24 Mar 2015 07:38:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=561; q=dns/txt; s=iport; t=1427207892; x=1428417492; h=date:from:to:subject:message-id:references:mime-version: in-reply-to; bh=V4Mw7aTNPFI+ayqml2SbAwAmGjruOV7jxtuIFZa21uU=; b=dblalOp5bATtl+0FdYXBi3wseWKTD5w5pUqMKa3JLhGIRbfs641Lsq4Q JkTQj8Ls1W7Lx3XKjIWBErWwu8kGmdo9Tl3oHIUz1gF3hjLXqT8TRGmTI HcqBumVMS1kDG5oNGQKPNoN+p3+gOKfCsgl6ksxQ1Czypc62Jxb1XSqMr k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AKBQBhdhFV/5JdJa1cgwZSWsZGCocvTAEBAQEBAX2EFQEBBAEBATc0GwsYCSUPBRM2ARKILw3IdgEBAQEGAQEBAQEBGASLIYgUgRYBBIsTjysBQlmDMIJZjQgihA4eMYJDAQEB X-IronPort-AV: E=Sophos;i="5.11,458,1422921600"; d="scan'208";a="406247001" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-3.cisco.com with ESMTP; 24 Mar 2015 14:37:58 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t2OEbvma010562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2015 14:37:57 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 t2OEbuHZ005479; Tue, 24 Mar 2015 07:37:57 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t2OEbuT8005478; Tue, 24 Mar 2015 07:37:56 -0700 Date: Tue, 24 Mar 2015 07:37:56 -0700 From: Toerless Eckert To: "anima@ietf.org" , "anima-chairs@tools.ietf.org" Message-ID: <20150324143756.GD19342@cisco.com> References: <5D36713D8A4E7348A7E10DF7437A4B925F4A666E@nkgeml512-mbx.china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B925F4A666E@nkgeml512-mbx.china.huawei.com> User-Agent: Mutt/1.4.2.2i Archived-At: Subject: Re: [Anima] Slides for Tuesday session 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, 24 Mar 2015 14:39:01 -0000 Also fixed up agenda with slide pointers, timing, presenter name fixes. https://www.ietf.org/proceedings/92/agenda/agenda-92-anima On Mon, Mar 23, 2015 at 11:36:28PM +0000, Sheng Jiang wrote: > Hi, all, > > We have uploaded all slides for our Tuesday session. Please read them (and the drafts) before the ANIMA meeting, so that we could have good discussions there. > > Best regards, > > Sheng + Toerless > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Tue Mar 24 07:48: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 E97F51A8753 for ; Tue, 24 Mar 2015 07:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.025 X-Spam-Level: X-Spam-Status: No, score=-13.025 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FAKE_REPLY_C=1.486, 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 vA8py72vPQvO for ; Tue, 24 Mar 2015 07:48:04 -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 9534A1A8741 for ; Tue, 24 Mar 2015 07:48:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=399; q=dns/txt; s=iport; t=1427208484; x=1428418084; h=date:from:to:subject:message-id:mime-version; bh=Kr4HX2JpjFNMIDbZXeU1aw8zR+TVyGHQ1oV6upCT2TQ=; b=Tm8RkoChIQGzhcIZUgM8TgCHAh2V/cU9NfqCg007GpU4sO4uqw1sUSdS GI1NVJMtvhCah6M/oNR8QMqnEnc9M7EjI5LfvdwUtrHcu6vVpbFqmk1j0 nLnuJ2vkSeppmVtAmG/hzzyujg42mEqA+jucMVGwIgSAqId5TEjpZY6AO o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AHBQDPdxFV/4kNJK1cgwZSWsZQhy9MAQEBAQEBfYRVWiE0BUkBG4gmDch1AQoBAQEeiyGCXoU2gRYFixOPKwFCk2oihA4eMQGCQgEBAQ X-IronPort-AV: E=Sophos;i="5.11,458,1422921600"; d="scan'208";a="406207695" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-7.cisco.com with ESMTP; 24 Mar 2015 14:48:04 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t2OEm3De003638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2015 14:48:03 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 t2OElvCC006175; Tue, 24 Mar 2015 07:47:57 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t2OElvjS006173; Tue, 24 Mar 2015 07:47:57 -0700 Date: Tue, 24 Mar 2015 07:47:57 -0700 From: Toerless Eckert To: "anima@ietf.org" , "anima-chairs@tools.ietf.org" Message-ID: <20150324144757.GA5964@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Archived-At: Subject: Re: [Anima] Meetecho 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, 24 Mar 2015 14:48:07 -0000 On tuesdays Anima meeting, we will participate in the Meetecho experiment whereby remote participants can also use meetecho to ask questions via audio. If you intend to participate remotely, drop us a note just to make sure we can check with you in case something doesn't work as expected. URL was updated: http://www.ietf.org/meeting/92/remote-participation.html Cheers Toerless From nobody Tue Mar 24 11:44: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 3EE6A1A89F5 for ; Tue, 24 Mar 2015 11:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_21=0.6, 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 TtVHdLLXQY30 for ; Tue, 24 Mar 2015 11:44:30 -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 965C31A87C5 for ; Tue, 24 Mar 2015 11:44:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1962; q=dns/txt; s=iport; t=1427222670; x=1428432270; h=date:from:to:cc:subject:message-id:mime-version; bh=wcjYbwPre+Jq/EGBzLnEqB+qcqPYmPiKtTusbTTwh3A=; b=icZCPsVENaOS8I+mBzPT/ppFTCUQ9FkISrWP30JiEr6o3ktIVN+9Apff SaPnrdIoMIbggk/q+4koDM3CcCU2h7JVz3lRaPu9gD6sjVxroprFaeCUf yUXhEEPde++BdSJTyX+Jr7wRjOLYhM/nccvyftCSLJrcM6RpkbyGK1FxO c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AdBQCUrxFV/4oNJK1CGoMGUloBxkmHNkwBAQEBAQF9hFU/PDQFiQsNN8h0AQEBHo81EQFtgwGBFgWLE4U9g2+FfwGBGzqPEINHIoQOHjIBgQmBOAEBAQ X-IronPort-AV: E=Sophos;i="5.11,459,1422921600"; d="scan'208,223";a="135015386" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-6.cisco.com with ESMTP; 24 Mar 2015 18:44:29 +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 t2OIiTiE027772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2015 18:44:29 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 t2OIiSGu022013; Tue, 24 Mar 2015 11:44:29 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t2OIiSSF022012; Tue, 24 Mar 2015 11:44:28 -0700 Date: Tue, 24 Mar 2015 11:44:28 -0700 From: "Toerless Eckert (eckert)" To: anima@ietf.org Message-ID: <20150324184428.GC5964@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Alexa Morris Subject: [Anima] [anima] more meetecho details. 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, 24 Mar 2015 18:44:32 -0000 >From Alexa, (thanks a lot, Alexa) If you are attending either of the two ANIMA working group sessions this week at IETF 92 as a remote attendee, we want to let you know that we are running an experiment that will give you the ability to bypass the jabber relay when commenting or asking questions, and instead comment directly into the room. There will be two separate queues ? a virtual and an actual (in-room) queue. Remote attendees will log into the Meetecho platform and will have a virtual queue that they can enter if they have a question or comment. In-room participants will continue to use normal mic lines (queues). The working group chair (or a delegate) will move back and forth between the two queues, giving people turns. When someone in the virtual queue has a turn, Meetecho will inject their audio the room so that they can speak directly to/with everyone in the actual meeting room. The remote queue will be displayed on a 2nd screen in the meeting room so that everyone can see if a remote attendee is waiting for their turn to speak. For the Tuesday 1520-1720 session, join at: http://www.meetecho.com/ietf92/anima For the Friday 150-1320 session, join at: http://www.meetecho.com/ietf92/anima_II Once you are in the Meetecho room you will see several icons next to your name, which will be displayed at the top left. If you wish to enter the queue, click on the raised hand and you will be entered into the queue. If you wish to see the virtual queue on the screen, click on the icon in the upper right side that is circled in the attached image. When you get to the front of the mic line and it?s your turn, the chair (or delegate) will give you the ability to speak and your audio will be injected into the room. You can see an example of the virtual queue in second image attached to this email. More information about these experiments can be found at: http://ietf92.conf.meetecho.com/index.php/UMPIRE_Project From nobody Tue Mar 24 14:56: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 83C071A1B84 for ; Tue, 24 Mar 2015 14:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 vRPgNDioWZXP for ; Tue, 24 Mar 2015 14:56:53 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 A390C1A1AB9 for ; Tue, 24 Mar 2015 14:56:52 -0700 (PDT) Received: from [192.168.10.146] ([31.133.152.120]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LgI0W-1ZF6IA2GAO-00ngEN for ; Tue, 24 Mar 2015 22:56:51 +0100 Message-ID: <5511DDA0.6040308@gmx.net> Date: Tue, 24 Mar 2015 22:56:48 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "anima@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="k4xelhS99Ct5qcOS3ba1E4hhWBMLHH1UR" X-Provags-ID: V03:K0:YucpVvIcwZrZnln2UQUvdJnzLcXIlYGeoxt0YIYkXct7am3/sfM 29+fqVY+Y/V8LmCjDVEvfQ9MnpNmsxccFlAhDF1912zLPLlagIMd0BfVS4u0fzXEoYI0UQy MpIvVf3eHzHok/JEw241aNNO3WzB51MYI2KrkKa4li5BSF20TZOHnnBE5wh67DVYt+0VFkQ Ob65mFMMIHvlFkaDR+LRw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [Anima] OMA Lightweight M2M 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, 24 Mar 2015 21:56:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --k4xelhS99Ct5qcOS3ba1E4hhWBMLHH1UR Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, during the meeting I was asking how the ZeroTouch / ANIMA bootstrapping document relates to the OMA Lightweight M2M specification. 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. Ciao Hannes --k4xelhS99Ct5qcOS3ba1E4hhWBMLHH1UR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVEd2gAAoJEGhJURNOOiAtVOYH/jSgrjfNj3htXqTGdDVr47Xu csdZD0/Z86UIthXRhxByIrG9VDPHkWPOxDOAo5ewwhjSc9q3htSxJGuOpmHghgcj UsfcbTXWc1ZF/bVkThHBFdudN5lYDA6cMACB2vVylyVDrrLl1Q0/YSdQO5Y1E0x+ ZcCemWl0j0+7iiGR+Hkl/Ec52o9pDyrNzZLvRuyJ7t98haWgPLLFdqxNex7i0YW+ p0RXn8ON/G6+hudXRm6T7aC7OYCDd2SjFd8eM0/IRw8sRWpFT8bjXltN1FR3YJ6x xQsO2RePllTF84tvhG1ojsK4SVxCQp0bJ5YoIXd4qoKV9fcyU+CajpeKHwkqDKM= =CupX -----END PGP SIGNATURE----- --k4xelhS99Ct5qcOS3ba1E4hhWBMLHH1UR-- From nobody Tue Mar 24 15: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 232161A1B2D for ; Tue, 24 Mar 2015 15:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 i-ZFig9KP-t5 for ; Tue, 24 Mar 2015 15:08:33 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C5421A1B28 for ; Tue, 24 Mar 2015 15:08:33 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id AEC5CA1; Tue, 24 Mar 2015 23:08:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1427234911; bh=pNYS1PP7dl+LTQcPQQ88Bpnr9hFmNtwqRBDyThTaaOM=; h=Date:From:To:Subject:From; b=Pw2Cf/aNxLLOEjpJoc3yyemi3UCRNA5IUPQ5nNtXgO7tqu2/I+2qW38mGQOTF0hCI cqtpBFaJEQ+HfsKS0DfPqI/yhHNqHu1M7DNHqEsJbyLndbTQ3UpSxAsfgqpaTOq/zl jj6/jKXsc4dTTHOVb3lxN7/UALaExKxOYGa1x0DM= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A0DAE9F for ; Tue, 24 Mar 2015 23:08:31 +0100 (CET) Date: Tue, 24 Mar 2015 23:08:31 +0100 (CET) From: Mikael Abrahamsson To: anima@ietf.org Message-ID: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Subject: [Anima] interface towards vendors 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, 24 Mar 2015 22:08:35 -0000 Hi, With my operator hat on, I just want to say that I do not want a lot of different ways of interacting with vendors to get credentials or anything else from the vendor regarding the devices we have purchased from them. I do not want separate protocols or mechanisms, and preferrably not different credetials either. So whatever happens with the protocols speaking to IoT devices, admission control to Autonomic Networks, and to Netconf-call-home, we need to make sure the "backend systems" are the same. I think this was implied in the presentation about draft-he-6lo-analysis-iot-sbootstrapping, but I just want to say that I am of this opinion as well. Can we do achieve this? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Mar 24 15:12:10 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 71C151A1A9D for ; Tue, 24 Mar 2015 15:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 I8Jew2fSEAJU for ; Tue, 24 Mar 2015 15:12:04 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 7C0201A1B28 for ; Tue, 24 Mar 2015 15:12:03 -0700 (PDT) Received: from [192.168.10.146] ([31.133.152.120]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Lngv5-1Z8nba0ZTD-00hvHv for ; Tue, 24 Mar 2015 23:12:01 +0100 Message-ID: <5511E12E.9050002@gmx.net> Date: Tue, 24 Mar 2015 23:11:58 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "anima@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="arCwuSjjJ4sbfBWtv9NaXaeGtbt5nCrpL" X-Provags-ID: V03:K0:QZVqSVmVDZ4EoBcwo244t9Eik0nrvb56cAQ6iBYL085+5tXN61f keNKilaQvgxXqUJLCRfsEai93AeVPQQq+jkY0zjuzEmsChbBryJzg+MEK4zn0GUBBu3Lmce McilAUrAi9aT3iPzGQ7ZCiz3JNotx/YtUfJ8Vo1MIh/1l5EWH+1D4emq6y3ww0Iln2zwdw9 ZQTseD0+2ITa8jbBI6qpQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [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, 24 Mar 2015 22:12:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --arCwuSjjJ4sbfBWtv9NaXaeGtbt5nCrpL Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable There was no time during the meeting today to ask too many questions (because of lack of time). That's unfortunately and so I have to fall back to the mailing list. I wanted to get some better understand what the ownership concept is about and what the implications are for the protocol design. The term came up in various presentations today and it appears to be important. Many parties are involved in the manufacturing process of products today and the value chain is certainly complex. Hence, who the owner of what is and at what point might be difficult to determine. Does it really matter who the owner actually is? Ciao Hannes --arCwuSjjJ4sbfBWtv9NaXaeGtbt5nCrpL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVEeEuAAoJEGhJURNOOiAtYdgIAILzmIgKNcc6R218MGbTyr3/ H8zB8nqPADGMWibvxuDX/1e+LA3+aR5/i/ugWX6G08YUqVnjcydaA76QKJw+Yosb /YPDBWhps2z8URti8xUrht2B0YqetI6NVp6wSwVpyU6Q1UM/0OrqiFDN/gHeJ03q m2u3Y1BPscnfWn0MKshvkGQ9Bi1ybE1zlFuvPEqg9yJJ+o3bx6BZCGVf6H/hMVp+ 0FjKmLuP43R0m7Lt/sbkEUx2jvIexvnAyw2ijqiRCQgklb7VDFYRcTIsEHsIZQmB 4H+IWnPHFqaN4DmiC0jvfUMkdJnoz7u/r+J0MSOs+oTWL11ikoa4cc2YcBIAy30= =X4K1 -----END PGP SIGNATURE----- --arCwuSjjJ4sbfBWtv9NaXaeGtbt5nCrpL-- From nobody Tue Mar 24 15:21:22 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 1C2DA1A8F3B for ; Tue, 24 Mar 2015 15:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 pIXj113yMcuz for ; Tue, 24 Mar 2015 15:21:20 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::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 305DD1AC44D for ; Tue, 24 Mar 2015 15:21:20 -0700 (PDT) Received: by wibbg6 with SMTP id bg6so1180927wib.0 for ; Tue, 24 Mar 2015 15:21:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=ZmlbviUU/x2BxQuuudNWRH9VTVmx/tl0eSRc0E/TatE=; b=NI/iMkmw5l4Pi8L6XAmd+JF8dCnjKx17fnIJLT4Eu35yMZsKR33gF2cZ8egPUJ2pzE ag4hzb0l9Q6DSKEGT3OU6Hl6GsAQ2deu6FmgJC7+9J/3NZ8lFZTn6z1GVNkGYUXv4uKO xZ4hNoE/Y+wL/eIlMhxxmZA57ZnaGgmW2kK94qFujQlawEhwr9/VtirYci46+5FHw53Y L+vhubxRgadanIW3dTFgHlmy2V2PHBY8UWOGhjtLN12rhIE14NHuvjXSj17lqR5VRQ7P l5MRxlF+isitoh9ZRxmey2MfM9UEf00OGJ/AtJwJQ1IXnsaUwHRU3qU1riwTM3hFIQF8 cT8g== X-Received: by 10.180.78.136 with SMTP id b8mr33019813wix.6.1427235678972; Tue, 24 Mar 2015 15:21:18 -0700 (PDT) Received: from ?IPv6:2001:67c:370:160:e5eb:94bd:1fdb:398a? ([2001:67c:370:160:e5eb:94bd:1fdb:398a]) by mx.google.com with ESMTPSA id 14sm810075wjv.29.2015.03.24.15.21.17 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Mar 2015 15:21:18 -0700 (PDT) Message-ID: <5511E359.10600@gmail.com> Date: Tue, 24 Mar 2015 18:21:13 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Hannes Tschofenig , "anima@ietf.org" References: <5511E12E.9050002@gmx.net> In-Reply-To: <5511E12E.9050002@gmx.net> Content-Type: multipart/alternative; boundary="------------030803070400090307070406" 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: Tue, 24 Mar 2015 22:21:22 -0000 This is a multi-part message in MIME format. --------------030803070400090307070406 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Hannes: I think supply chain issues, and transgression from one supply chain step to the next, are important in life-cycle considerations. This includes how to move from one logical "owner" to the next and potentially "cutting the ties" with the former. These aspects certainly require more work. A very simple example of supply chain would be relabelling a device as a "white goods" device (e.g., by selling a branded good at a superstore, such as Walmart, under the Walmart brand, whereas in reality it outsourced all production (except perhaps putting the sticker on top). Best regards, Rene On 3/24/2015 6:11 PM, Hannes Tschofenig wrote: > There was no time during the meeting today to ask too many questions > (because of lack of time). That's unfortunately and so I have to fall > back to the mailing list. > > I wanted to get some better understand what the ownership concept is > about and what the implications are for the protocol design. The term > came up in various presentations today and it appears to be important. > > Many parties are involved in the manufacturing process of products today > and the value chain is certainly complex. Hence, who the owner of what > is and at what point might be difficult to determine. > > Does it really matter who the owner actually is? > > Ciao > Hannes > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------030803070400090307070406 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
Hi Hannes:

I think supply chain issues, and transgression from one supply chain step to the next, are important in life-cycle considerations. This includes how to move from one logical "owner" to the next and potentially "cutting the ties" with the former. These aspects certainly require more work.

A very simple example of supply chain would be relabelling a device as a "white goods" device (e.g., by selling a branded good at a superstore, such as Walmart, under the Walmart brand, whereas in reality it outsourced all production (except perhaps putting the sticker on top).

Best regards, Rene

On 3/24/2015 6:11 PM, Hannes Tschofenig wrote:
There was no time during the meeting today to ask too many questions
(because of lack of time). That's unfortunately and so I have to fall
back to the mailing list.

I wanted to get some better understand what the ownership concept is
about and what the implications are for the protocol design. The term
came up in various presentations today and it appears to be important.

Many parties are involved in the manufacturing process of products today
and the value chain is certainly complex. Hence, who the owner of what
is and at what point might be difficult to determine.

Does it really matter who the owner actually is?

Ciao
Hannes




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



-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------030803070400090307070406-- From nobody Wed Mar 25 08:49: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 DAF1E1B2A86 for ; Wed, 25 Mar 2015 08:49:23 -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 Ouob6D9w8TCH for ; Wed, 25 Mar 2015 08:49:21 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010: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 83F7F1A8869 for ; Wed, 25 Mar 2015 08:49:21 -0700 (PDT) Received: by labto5 with SMTP id to5so23511595lab.0 for ; Wed, 25 Mar 2015 08:49:20 -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=9siQQhXqTHeYwk+DiZjGCti1WOboUp2H+GXJEtHTe7k=; b=I7UllIqP9CikmcRvAO/bMn2ZeCbPr4X8sOA5v4/CFP/yrww9Rcy4qHMdlhZiNRKNd0 8dDkOh5QM92+D30lwdAXE6GmMHdsglf2hLngM49QWNFTbk4tYVcJuUx8a+HzhUFK48Ph Zx4bi/Teb/u0Mdonk8q4f+cnFTkmpRKtN1YKQSudQiSm6HKfSNvxVuRql5jSvI2pFQLJ TrAR5fu/QnI27f0KtnG8qU96aYpA63rAj/o5u06z9L6/R28b8rKP/Mx0GTCX4xncH68k WAvzlhCUPgRs8qm7JzLQnHZPSPOsRmsqXrdK/VtUKpH640HjdjcFjDNpY4IhP3Fvu/NI Sv4A== MIME-Version: 1.0 X-Received: by 10.152.197.34 with SMTP id ir2mr9142244lac.36.1427298560065; Wed, 25 Mar 2015 08:49:20 -0700 (PDT) Sender: jeferson.nobre@gmail.com Received: by 10.112.160.129 with HTTP; Wed, 25 Mar 2015 08:49:20 -0700 (PDT) In-Reply-To: References: Date: Wed, 25 Mar 2015 10:49:20 -0500 X-Google-Sender-Auth: OKniDZtGMX0fC8tWF95Lo_A_CkY Message-ID: From: =?UTF-8?Q?J=C3=A9ferson_Campos_Nobre?= To: Mikael Abrahamsson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "anima@ietf.org" Subject: Re: [Anima] interface towards vendors 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, 25 Mar 2015 15:49:24 -0000 +1 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 Tue, Mar 24, 2015 at 5:08 PM, Mikael Abrahamsson wrot= e: > > Hi, > > With my operator hat on, I just want to say that I do not want a lot of > different ways of interacting with vendors to get credentials or anything > else from the vendor regarding the devices we have purchased from them. I= do > not want separate protocols or mechanisms, and preferrably not different > credetials either. > > So whatever happens with the protocols speaking to IoT devices, admission > control to Autonomic Networks, and to Netconf-call-home, we need to make > sure the "backend systems" are the same. I think this was implied in the > presentation about draft-he-6lo-analysis-iot-sbootstrapping, but I just w= ant > to say that I am of this opinion as well. > > Can we do achieve this? > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Wed Mar 25 09:12: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 050D31ACE44 for ; Wed, 25 Mar 2015 09:12: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 SSPO-sYuIrgG for ; Wed, 25 Mar 2015 09:12:25 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::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 596B41B2AD3 for ; Wed, 25 Mar 2015 09:11:39 -0700 (PDT) Received: by wixw10 with SMTP id w10so45622005wix.0 for ; Wed, 25 Mar 2015 09:11: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=8RDqLckiOYmqOOqoSnEIuNnMe+uIhLu+80EJDbjJ9q0=; b=HBzBXTpIpLVgEFjbT6AGQ4jTmszKGie4KWT0qFUDddlqmwingGR02R0pHIHZvcfGbG VyHXkleNnZisZz9BFZkfa0ZHnxB5qsCS5bB9b5fU4QdVyrNEzIEias3E0Y6l+Eff/WQ4 aj7WL7qobRGjmu0vvf9MTMI1s8K5il6iTaIEwGuoiCohhjZs7PZJM7vKQdzb3Oa5Rmdd 9zmmS85iabSh3b76Njl2IyXaCfU1o9EXtGrRFj6h20s2ASONPGhxMlv0oscLkfAsMx54 Ui6wxt7JQMzIodHrfQ14z69UDtIEDsagsc2mlkOwSD0zssaX3SrFa/oP5VUvBANX0epO ACng== X-Received: by 10.180.74.112 with SMTP id s16mr38927234wiv.73.1427299898012; Wed, 25 Mar 2015 09:11:38 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:28cc:dc4c:9703:6781? ([2001:67c:370:176:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id k1sm4353452wjn.9.2015.03.25.09.11.36 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Mar 2015 09:11:37 -0700 (PDT) Message-ID: <5512DE41.6030209@gmail.com> Date: Thu, 26 Mar 2015 05:11:45 +1300 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.5.0 MIME-Version: 1.0 To: Rene Struik References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> In-Reply-To: <5511E359.10600@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Hannes Tschofenig , "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, 25 Mar 2015 16:12:30 -0000 I think it is unanswerable, or at least the answer is YMMV. You may remember that one of my comments on draft-pritikin was basically: I hate the MASA. I was glad to see the connection to the MASA was clearly indicated as optional in the slides yesterday. The point is that we have no control over this - different classes of device and different vendors will have different ideas about this. I firmly believe that any design we do in the IETF has to be very flexible on this point. Regards Brian On 25/03/2015 11:21, Rene Struik wrote: > Hi Hannes: > > I think supply chain issues, and transgression from one supply chain step to the next, are important in life-cycle > considerations. This includes how to move from one logical "owner" to the next and potentially "cutting the ties" with the > former. These aspects certainly require more work. > > A very simple example of supply chain would be relabelling a device as a "white goods" device (e.g., by selling a branded good > at a superstore, such as Walmart, under the Walmart brand, whereas in reality it outsourced all production (except perhaps > putting the sticker on top). > > Best regards, Rene > > On 3/24/2015 6:11 PM, Hannes Tschofenig wrote: >> There was no time during the meeting today to ask too many questions >> (because of lack of time). That's unfortunately and so I have to fall >> back to the mailing list. >> >> I wanted to get some better understand what the ownership concept is >> about and what the implications are for the protocol design. The term >> came up in various presentations today and it appears to be important. >> >> Many parties are involved in the manufacturing process of products today >> and the value chain is certainly complex. Hence, who the owner of what >> is and at what point might be difficult to determine. >> >> Does it really matter who the owner actually is? >> >> Ciao >> Hannes >> >> >> >> _______________________________________________ >> 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 Wed Mar 25 09:25: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 77E401A894E for ; Wed, 25 Mar 2015 09:24:58 -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 qvRE7_NqKFgq for ; Wed, 25 Mar 2015 09:24:57 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::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 D0F661A894A for ; Wed, 25 Mar 2015 09:24:56 -0700 (PDT) Received: by wibg7 with SMTP id g7so115940808wib.1 for ; Wed, 25 Mar 2015 09:24: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=rUxpouXDfmvTiCX5IBPpIfKJnPoDENlbBFI1hBBR8KE=; b=e9VhTHREgNB1cAnxcP7BoNvFqvZ7H1P6O/cmZsFKXPFxaZXftO8vv+JfUCkIdlhSY9 /ZexRAcBvOp5nuIpJixpY3Lltl8qeie8BRRmf0CPeU+Rg05KOWKo1X4w2XuX5nuPgHr0 +zngcIWw0hTXRgIAVjN05BgWB2K6V+NMjeaj/OB89WarF51b/Xl3lbni8RG7nOs5S8JW UFP4pvYJi98HP0FBLm3vECi6/pDwW5dqdEjBUxqLx8UR4CN8/e3o4WPfZ9/dvVRablA4 4bAgu2ol43Mgfg7/7sBOUknu0C4nGobvZIk5gXVAIQ6eIBGxyRicBmcWyBWqXpFz7Ko+ adYA== X-Received: by 10.180.7.134 with SMTP id j6mr40038027wia.11.1427300694402; Wed, 25 Mar 2015 09:24:54 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:28cc:dc4c:9703:6781? ([2001:67c:370:176:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id m9sm21320778wiz.24.2015.03.25.09.24.53 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Mar 2015 09:24:53 -0700 (PDT) Message-ID: <5512E15D.4050508@gmail.com> Date: Thu, 26 Mar 2015 05:25:01 +1300 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.5.0 MIME-Version: 1.0 To: Mikael Abrahamsson , anima@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] interface towards vendors 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, 25 Mar 2015 16:24:58 -0000 On 25/03/2015 11:08, Mikael Abrahamsson wrote: > > Hi, > > With my operator hat on, I just want to say that I do not want a lot of different ways of interacting with vendors to get > credentials or anything else from the vendor regarding the devices we have purchased from them. I do not want separate protocols > or mechanisms, and preferrably not different credetials either. > > So whatever happens with the protocols speaking to IoT devices, admission control to Autonomic Networks, and to > Netconf-call-home, we need to make sure the "backend systems" are the same. I think this was implied in the presentation about > draft-he-6lo-analysis-iot-sbootstrapping, but I just want to say that I am of this opinion as well. > > Can we do achieve this? Shout at Thread, first, to tell them not to work in secret. More generally, I am very worried about this. We cannot force the industry to adopt a single solution. If someone can define a common registrar model, which I guess is what you mean by a common back end, that would be fine. I am a bit pessimistic. To the extent that we can factor this out of the anima protocols as such, we should do so. In my walkthrough I had Discover("trust relay"). I suspect that the response to that will have to include a list of supported methods. The alternative would be for a node that supports, for example, draft-pritikin would say Discover("draft-pritikin-relay") and so on for the other methods. Brian From nobody Wed Mar 25 10:07: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 A3E621A1A75 for ; Wed, 25 Mar 2015 10:07:14 -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 EMJ-jp0lWSQL for ; Wed, 25 Mar 2015 10:07:10 -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 E18001A883D for ; Wed, 25 Mar 2015 10:07:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2798; q=dns/txt; s=iport; t=1427303229; x=1428512829; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=f1fFPb61Ify9fR8FfE8YaEd8jjewNRWocEasMgzgNAw=; b=jC6X8Liz59ZhPvdKRZTIuczweRuquR7IubKtopQDSm+HJRuMxnWSbv7U tQMHxxzvmI0EzStZrlJ6fMBTcOfsQlKcZLXCHIpiR3T7fL2EiA3AwhwNk 652GTGBDZvvaFaNhlybt0TbdpFqjfOnF/vI+tWakl28HHx0HS02n87vyL E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DLDQAS6hJV/5FdJa1cgwZSWsNCgUUKhXUCgVg5EwEBAQEBAQF8QQKDUgEBBAEBATc0CxALGAklDwUTNhMZiBYNyUkBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIoif4R2B4MXgRYFixOPKwGLY4hJIoQOHjGCQwEBAQ X-IronPort-AV: E=Sophos;i="5.11,465,1422921600"; d="scan'208";a="135297996" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-3.cisco.com with ESMTP; 25 Mar 2015 17:07:07 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t2PH6l6m001620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Mar 2015 17:07:07 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 t2PH6kfb011390; Wed, 25 Mar 2015 10:06:46 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t2PH6kEm011389; Wed, 25 Mar 2015 10:06:46 -0700 Date: Wed, 25 Mar 2015 10:06:46 -0700 From: Toerless Eckert To: Brian E Carpenter Message-ID: <20150325170646.GB31979@cisco.com> References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> <5512DE41.6030209@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5512DE41.6030209@gmail.com> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Hannes Tschofenig , Rene Struik , "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, 25 Mar 2015 17:07:14 -0000 Should i be able to find a more detailed reasonining from you about MASA in the mailing list archive ? if not, would you mind to elaborate here ? Cheers Toerless On Thu, Mar 26, 2015 at 05:11:45AM +1300, Brian E Carpenter wrote: > I think it is unanswerable, or at least the answer is YMMV. You may remember that > one of my comments on draft-pritikin was basically: I hate the MASA. I was glad > to see the connection to the MASA was clearly indicated as optional in the slides > yesterday. The point is that we have no control over this - different classes > of device and different vendors will have different ideas about this. I firmly > believe that any design we do in the IETF has to be very flexible on > this point. > > Regards > Brian > > On 25/03/2015 11:21, Rene Struik wrote: > > Hi Hannes: > > > > I think supply chain issues, and transgression from one supply chain step to the next, are important in life-cycle > > considerations. This includes how to move from one logical "owner" to the next and potentially "cutting the ties" with the > > former. These aspects certainly require more work. > > > > A very simple example of supply chain would be relabelling a device as a "white goods" device (e.g., by selling a branded good > > at a superstore, such as Walmart, under the Walmart brand, whereas in reality it outsourced all production (except perhaps > > putting the sticker on top). > > > > Best regards, Rene > > > > On 3/24/2015 6:11 PM, Hannes Tschofenig wrote: > >> There was no time during the meeting today to ask too many questions > >> (because of lack of time). That's unfortunately and so I have to fall > >> back to the mailing list. > >> > >> I wanted to get some better understand what the ownership concept is > >> about and what the implications are for the protocol design. The term > >> came up in various presentations today and it appears to be important. > >> > >> Many parties are involved in the manufacturing process of products today > >> and the value chain is certainly complex. Hence, who the owner of what > >> is and at what point might be difficult to determine. > >> > >> Does it really matter who the owner actually is? > >> > >> Ciao > >> Hannes > >> > >> > >> > >> _______________________________________________ > >> 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 > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- Toerless Eckert, eckert@cisco.com From nobody Wed Mar 25 11: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 B2F151AC3AC for ; Wed, 25 Mar 2015 11:02: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 4b4hyEZWAUu6 for ; Wed, 25 Mar 2015 11:02:28 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::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 037ED1A9308 for ; Wed, 25 Mar 2015 11:02:28 -0700 (PDT) Received: by wgra20 with SMTP id a20so36706585wgr.3 for ; Wed, 25 Mar 2015 11:02:26 -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=4uAQ60O/YauzV7ShmXc4f0nHCh22qYBKdGJRhXj7Ku8=; b=VsrnM/9YyuXlgzzpNnrBcD33Ljz43yqSu3wVPjPNHrO4229jtPOp9VIb1rC8sbUJY+ 92zNBlvCRny0Q473bxgb2ToeJKPAskbQrGJgK/C0GhEAceFOM6JfW+0hA/FXJIrvExtq i4y7wAY8xZl5cnCUEZE1E0tD0AdCCNe35X4fkqwwinFhP9GYREdRK2AdcH1IJw0rk4uo cw3wyHd/v/nca0pWue6fglaPLwCd9B+Yy5V/qJSJw9mGRXeIchDK2lwkkmCvtz5GIAYD 9vU1q7o0L2dlKORWmacHni1HpHvqKqgx0JoU3lrZ40sAhXbItM4AnGYHb7fQdFKfQovl LKYA== X-Received: by 10.180.24.162 with SMTP id v2mr39065879wif.80.1427306546782; Wed, 25 Mar 2015 11:02:26 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:28cc:dc4c:9703:6781? ([2001:67c:370:176:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id jy7sm21681509wid.22.2015.03.25.11.02.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Mar 2015 11:02:26 -0700 (PDT) Message-ID: <5512F839.6080502@gmail.com> Date: Thu, 26 Mar 2015 07:02:33 +1300 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.5.0 MIME-Version: 1.0 To: Toerless Eckert References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> <5512DE41.6030209@gmail.com> <20150325170646.GB31979@cisco.com> In-Reply-To: <20150325170646.GB31979@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Hannes Tschofenig , Rene Struik , "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, 25 Mar 2015 18:02:30 -0000 On 26/03/2015 06:06, Toerless Eckert wrote: > Should i be able to find a more detailed reasonining from you about MASA > in the mailing list archive ? if not, would you mind to elaborate here ? I expect it is somewhere in my comments on draft-pritikin, but basically I think we MUST have a mode that has no external dependencies whatever. A nuclear plant operator might agree with me, or anyone who wants a secure network with an air gap round it. As long as the MASA is optional, it's fine. Brian > > Cheers > Toerless > > On Thu, Mar 26, 2015 at 05:11:45AM +1300, Brian E Carpenter wrote: >> I think it is unanswerable, or at least the answer is YMMV. You may remember that >> one of my comments on draft-pritikin was basically: I hate the MASA. I was glad >> to see the connection to the MASA was clearly indicated as optional in the slides >> yesterday. The point is that we have no control over this - different classes >> of device and different vendors will have different ideas about this. I firmly >> believe that any design we do in the IETF has to be very flexible on >> this point. >> >> Regards >> Brian >> >> On 25/03/2015 11:21, Rene Struik wrote: >>> Hi Hannes: >>> >>> I think supply chain issues, and transgression from one supply chain step to the next, are important in life-cycle >>> considerations. This includes how to move from one logical "owner" to the next and potentially "cutting the ties" with the >>> former. These aspects certainly require more work. >>> >>> A very simple example of supply chain would be relabelling a device as a "white goods" device (e.g., by selling a branded good >>> at a superstore, such as Walmart, under the Walmart brand, whereas in reality it outsourced all production (except perhaps >>> putting the sticker on top). >>> >>> Best regards, Rene >>> >>> On 3/24/2015 6:11 PM, Hannes Tschofenig wrote: >>>> There was no time during the meeting today to ask too many questions >>>> (because of lack of time). That's unfortunately and so I have to fall >>>> back to the mailing list. >>>> >>>> I wanted to get some better understand what the ownership concept is >>>> about and what the implications are for the protocol design. The term >>>> came up in various presentations today and it appears to be important. >>>> >>>> Many parties are involved in the manufacturing process of products today >>>> and the value chain is certainly complex. Hence, who the owner of what >>>> is and at what point might be difficult to determine. >>>> >>>> Does it really matter who the owner actually is? >>>> >>>> Ciao >>>> Hannes >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > From nobody Wed Mar 25 11:45: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 A20301B2B0A for ; Wed, 25 Mar 2015 11:45:55 -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 mXtq3wzk5smP for ; Wed, 25 Mar 2015 11:45:54 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 342641B2AFB for ; Wed, 25 Mar 2015 11:45:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3330; q=dns/txt; s=iport; t=1427309154; x=1428518754; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=/BkM3u4NFmCRRp9J99YIB9hQKh2QW1x5fto8rdz4hOw=; b=kh16HE+RoWwz9NdqPVxr7V5fy/qs0eNKeFPE9pGLoWw7QkriT86kQUHV WAnY1z/IsSJ17cp18friD9jqKnNBBkcc6MydG3Zh511n7wEY/mWgNcUZd niNToXpopBePfYYFcBV4LjwzqPvv57QyKJN+M97SjZTBORoKZuk+wQUCz c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DHDQCOARNV/4ENJK1cgwbJYYJSAoFZTAEBAQEBAX1BAoNSAQEEOjQLEAsYCSUPBUksiBbJdAEBAQEBAQEBAQEBAQEBAQEBAQEBAReKIn+EdgeDF4EWBYsTjysBgRuKSIUCg0cihA4egnQBAQE X-IronPort-AV: E=Sophos;i="5.11,466,1422921600"; d="scan'208";a="406618065" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-5.cisco.com with ESMTP; 25 Mar 2015 18:45:53 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t2PIjqT1006675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Mar 2015 18:45:53 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 t2PIjqDd017670; Wed, 25 Mar 2015 11:45:52 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t2PIjqwT017669; Wed, 25 Mar 2015 11:45:52 -0700 Date: Wed, 25 Mar 2015 11:45:52 -0700 From: Toerless Eckert To: Brian E Carpenter Message-ID: <20150325184552.GC31979@cisco.com> References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> <5512DE41.6030209@gmail.com> <20150325170646.GB31979@cisco.com> <5512F839.6080502@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5512F839.6080502@gmail.com> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Hannes Tschofenig , Rene Struik , "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, 25 Mar 2015 18:45:55 -0000 Thanks, Brian. If i understand it correctly, in the netconf zerotouch approach, the router to control the meltdown process in the reactor would still need to receive a file from the outside of the reactor airgap (axctually something like a .tar of 4? files). And in result it would have some bootstrap config, but not a nuclear pant operator certificate. True/False ? How would that match your requirements - any better/different to you than MASA ? Cheers Toerless On Thu, Mar 26, 2015 at 07:02:33AM +1300, Brian E Carpenter wrote: > On 26/03/2015 06:06, Toerless Eckert wrote: > > Should i be able to find a more detailed reasonining from you about MASA > > in the mailing list archive ? if not, would you mind to elaborate here ? > > I expect it is somewhere in my comments on draft-pritikin, but basically > I think we MUST have a mode that has no external dependencies whatever. > A nuclear plant operator might agree with me, or anyone who wants a secure > network with an air gap round it. > > As long as the MASA is optional, it's fine. > > Brian > > > > > Cheers > > Toerless > > > > On Thu, Mar 26, 2015 at 05:11:45AM +1300, Brian E Carpenter wrote: > >> I think it is unanswerable, or at least the answer is YMMV. You may remember that > >> one of my comments on draft-pritikin was basically: I hate the MASA. I was glad > >> to see the connection to the MASA was clearly indicated as optional in the slides > >> yesterday. The point is that we have no control over this - different classes > >> of device and different vendors will have different ideas about this. I firmly > >> believe that any design we do in the IETF has to be very flexible on > >> this point. > >> > >> Regards > >> Brian > >> > >> On 25/03/2015 11:21, Rene Struik wrote: > >>> Hi Hannes: > >>> > >>> I think supply chain issues, and transgression from one supply chain step to the next, are important in life-cycle > >>> considerations. This includes how to move from one logical "owner" to the next and potentially "cutting the ties" with the > >>> former. These aspects certainly require more work. > >>> > >>> A very simple example of supply chain would be relabelling a device as a "white goods" device (e.g., by selling a branded good > >>> at a superstore, such as Walmart, under the Walmart brand, whereas in reality it outsourced all production (except perhaps > >>> putting the sticker on top). > >>> > >>> Best regards, Rene > >>> > >>> On 3/24/2015 6:11 PM, Hannes Tschofenig wrote: > >>>> There was no time during the meeting today to ask too many questions > >>>> (because of lack of time). That's unfortunately and so I have to fall > >>>> back to the mailing list. > >>>> > >>>> I wanted to get some better understand what the ownership concept is > >>>> about and what the implications are for the protocol design. The term > >>>> came up in various presentations today and it appears to be important. > >>>> > >>>> Many parties are involved in the manufacturing process of products today > >>>> and the value chain is certainly complex. Hence, who the owner of what > >>>> is and at what point might be difficult to determine. > >>>> > >>>> Does it really matter who the owner actually is? > >>>> > >>>> Ciao > >>>> Hannes From nobody Wed Mar 25 12:00: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 A76541B2B87 for ; Wed, 25 Mar 2015 12:00:18 -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 sgRYa30rFSML for ; Wed, 25 Mar 2015 12:00:16 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::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 D8EFC1B2B6A for ; Wed, 25 Mar 2015 12:00:14 -0700 (PDT) Received: by wibgn9 with SMTP id gn9so53073707wib.1 for ; Wed, 25 Mar 2015 12:00: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:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=n86A2GVMDcjIqJ2zcBP3tRBV9Cik4C76yx1T9mDWft8=; b=0Ap2KvI2Ctv2TkZHSH+k65On9LPE8UkeLCNkFo72aoALdLJTMyr2VeOT4ZdhlTEXPd Gz/lHwutq2itkZr5+c4dwleAJ/jHZ10uiOnLTNih+yXcF63jVjLBmT1xS8Bh+kczIpbC So/im80exjfkui1A9SX/2xDmHE/aXaH6ZTzupGpUMaUdDW1RSobSTLLVUgWDYRWsDdjD PoRRiVSnrjzrMqBQzPgyPVFHam15UJueyJbzmNncwovn67pIAD6Oqmw6aAIyyJsbRaHD LW9VdlsOJ1Nm12PTOB6oUjmtmFQb7vu1D/nztkL4pMLEsxrRfYFy/HYpKffZBK6ET2M0 6PAw== X-Received: by 10.194.57.206 with SMTP id k14mr21201103wjq.1.1427310013621; Wed, 25 Mar 2015 12:00:13 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:28cc:dc4c:9703:6781? ([2001:67c:370:176:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id e2sm4933376wjy.46.2015.03.25.12.00.12 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Mar 2015 12:00:13 -0700 (PDT) Message-ID: <551305C4.9030001@gmail.com> Date: Thu, 26 Mar 2015 08:00:20 +1300 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.5.0 MIME-Version: 1.0 To: Toerless Eckert References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> <5512DE41.6030209@gmail.com> <20150325170646.GB31979@cisco.com> <5512F839.6080502@gmail.com> <20150325184552.GC31979@cisco.com> In-Reply-To: <20150325184552.GC31979@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Hannes Tschofenig , Rene Struik , "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, 25 Mar 2015 19:00:18 -0000 Indeed, I think any kind of call-home is unacceptable in certain high security environments. Would you expect, say, the door lock control system of the White House or the Bundestag to call an external server for a firmware update? Another aspect is disaster recovery. If you have to reboot your network at a time when all Internet access is down (think hurricane or earthquake), you don't want to *require* an external service. "We can't open the elevator doors because the Internet is down." I really think our bootstrap scenarios have to allow for this. Brian On 26/03/2015 07:45, Toerless Eckert wrote: > Thanks, Brian. > > If i understand it correctly, in the netconf zerotouch approach, > the router to control the meltdown process in the reactor would still > need to receive a file from the outside of the reactor airgap (axctually > something like a .tar of 4? files). And in result it would have some > bootstrap config, but not a nuclear pant operator certificate. > > True/False ? > > How would that match your requirements - any better/different to > you than MASA ? > > Cheers > Toerless > > On Thu, Mar 26, 2015 at 07:02:33AM +1300, Brian E Carpenter wrote: >> On 26/03/2015 06:06, Toerless Eckert wrote: >>> Should i be able to find a more detailed reasonining from you about MASA >>> in the mailing list archive ? if not, would you mind to elaborate here ? >> >> I expect it is somewhere in my comments on draft-pritikin, but basically >> I think we MUST have a mode that has no external dependencies whatever. >> A nuclear plant operator might agree with me, or anyone who wants a secure >> network with an air gap round it. >> >> As long as the MASA is optional, it's fine. >> >> Brian >> >>> >>> Cheers >>> Toerless >>> >>> On Thu, Mar 26, 2015 at 05:11:45AM +1300, Brian E Carpenter wrote: >>>> I think it is unanswerable, or at least the answer is YMMV. You may remember that >>>> one of my comments on draft-pritikin was basically: I hate the MASA. I was glad >>>> to see the connection to the MASA was clearly indicated as optional in the slides >>>> yesterday. The point is that we have no control over this - different classes >>>> of device and different vendors will have different ideas about this. I firmly >>>> believe that any design we do in the IETF has to be very flexible on >>>> this point. >>>> >>>> Regards >>>> Brian >>>> >>>> On 25/03/2015 11:21, Rene Struik wrote: >>>>> Hi Hannes: >>>>> >>>>> I think supply chain issues, and transgression from one supply chain step to the next, are important in life-cycle >>>>> considerations. This includes how to move from one logical "owner" to the next and potentially "cutting the ties" with the >>>>> former. These aspects certainly require more work. >>>>> >>>>> A very simple example of supply chain would be relabelling a device as a "white goods" device (e.g., by selling a branded good >>>>> at a superstore, such as Walmart, under the Walmart brand, whereas in reality it outsourced all production (except perhaps >>>>> putting the sticker on top). >>>>> >>>>> Best regards, Rene >>>>> >>>>> On 3/24/2015 6:11 PM, Hannes Tschofenig wrote: >>>>>> There was no time during the meeting today to ask too many questions >>>>>> (because of lack of time). That's unfortunately and so I have to fall >>>>>> back to the mailing list. >>>>>> >>>>>> I wanted to get some better understand what the ownership concept is >>>>>> about and what the implications are for the protocol design. The term >>>>>> came up in various presentations today and it appears to be important. >>>>>> >>>>>> Many parties are involved in the manufacturing process of products today >>>>>> and the value chain is certainly complex. Hence, who the owner of what >>>>>> is and at what point might be difficult to determine. >>>>>> >>>>>> Does it really matter who the owner actually is? >>>>>> >>>>>> Ciao >>>>>> Hannes > From nobody Wed Mar 25 12:27: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 96D4A1A8A3A for ; Wed, 25 Mar 2015 12:26:56 -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 4YuAvzz2P1A3 for ; Wed, 25 Mar 2015 12:26: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 829F21A8A4A for ; Wed, 25 Mar 2015 12:26:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUD19857; Wed, 25 Mar 2015 19:26:46 +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; Wed, 25 Mar 2015 19:26:45 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.209]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Thu, 26 Mar 2015 03:26:40 +0800 From: Sheng Jiang To: Brian E Carpenter , Toerless Eckert Thread-Topic: [Anima] Ownership Concept Thread-Index: AQHQZn+Wg9fZJUO6M0OTD8vJ8KxwwZ0rrpGAgAErGoCAAA9fAIAAD5aAgACbctg= Date: Wed, 25 Mar 2015 19:26:40 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B925F4C1B6D@NKGEML512-MBS.china.huawei.com> References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> <5512DE41.6030209@gmail.com> <20150325170646.GB31979@cisco.com>,<5512F839.6080502@gmail.com> In-Reply-To: <5512F839.6080502@gmail.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.158.27] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Hannes Tschofenig , Rene Struik , "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, 25 Mar 2015 19:26:56 -0000 >By Brian >I think we MUST have a mode that has no external dependencies whatever. >As long as the MASA is optional, it's fine. It is exactly the same comment that I have made a couple of time. It is up = to the owner of the network or the network operator how they may validate t= he bootstrapped devices. It may be MASA, may be some other ways, or even si= mply nothing (yes, it is insecure). But the owner of the network has the ri= ght to choose. Any mandated mechanism would harm the independency of the ne= twork operator. Best regards, Sheng > Cheers > Toerless > > On Thu, Mar 26, 2015 at 05:11:45AM +1300, Brian E Carpenter wrote: >> I think it is unanswerable, or at least the answer is YMMV. You may reme= mber that >> one of my comments on draft-pritikin was basically: I hate the MASA. I w= as glad >> to see the connection to the MASA was clearly indicated as optional in t= he slides >> yesterday. The point is that we have no control over this - different cl= asses >> of device and different vendors will have different ideas about this. I = firmly >> believe that any design we do in the IETF has to be very flexible on >> this point. >> >> Regards >> Brian >> >> On 25/03/2015 11:21, Rene Struik wrote: >>> Hi Hannes: >>> >>> I think supply chain issues, and transgression from one supply chain st= ep to the next, are important in life-cycle >>> considerations. This includes how to move from one logical "owner" to t= he next and potentially "cutting the ties" with the >>> former. These aspects certainly require more work. >>> >>> A very simple example of supply chain would be relabelling a device as = a "white goods" device (e.g., by selling a branded good >>> at a superstore, such as Walmart, under the Walmart brand, whereas in r= eality it outsourced all production (except perhaps >>> putting the sticker on top). >>> >>> Best regards, Rene >>> >>> On 3/24/2015 6:11 PM, Hannes Tschofenig wrote: >>>> There was no time during the meeting today to ask too many questions >>>> (because of lack of time). That's unfortunately and so I have to fall >>>> back to the mailing list. >>>> >>>> I wanted to get some better understand what the ownership concept is >>>> about and what the implications are for the protocol design. The term >>>> came up in various presentations today and it appears to be important. >>>> >>>> Many parties are involved in the manufacturing process of products tod= ay >>>> and the value chain is certainly complex. Hence, who the owner of what >>>> is and at what point might be difficult to determine. >>>> >>>> Does it really matter who the owner actually is? >>>> >>>> Ciao >>>> Hannes >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> _______________________________________________ >> 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 Wed Mar 25 13:08: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 565871B2A23 for ; Wed, 25 Mar 2015 13:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_84=0.6, 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 70xlAv46ul9Z for ; Wed, 25 Mar 2015 13:08:01 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8232B1A8AE8 for ; Wed, 25 Mar 2015 13:08:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5731; q=dns/txt; s=iport; t=1427314081; x=1428523681; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=DyG0nFrFTrx1h1J8whwPKzWD6IM6UFgkgGIKY50psSE=; b=cdaKcNQld6t3z0tk8AD/9XqO2d0sDY0RpnJMwncULcW4zk2C3I4T4tsO k3+Lc0/uSq63Pf8V7trD2vHGVx6xa+pDxyKn/apztA+XB/eAFM5lPEjA5 Cmdlp+wF5JZ19DzMd6+JiPUK3U7gBPNleRfXLuCJyzphpH3hMb6J4vN9Q Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DHDQBPFBNV/4cNJK1cgwaBLMsKAoFaTAEBAQEBAX1BAoNSAQEEOjQLEAsYCSUPBUkTGYgWyg4BAQEBAQEBAQEBAQEBAQEBAQEBAQEXiiJ/hHYHgxeBFgWLE48rAYEbikiBVIMug0cihA4eMYJDAQEB X-IronPort-AV: E=Sophos;i="5.11,466,1422921600"; d="scan'208";a="406639111" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-5.cisco.com with ESMTP; 25 Mar 2015 20:08:00 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t2PK80Mn028288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Mar 2015 20:08:00 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 t2PK7x1i022998; Wed, 25 Mar 2015 13:07:59 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t2PK7wv3022996; Wed, 25 Mar 2015 13:07:58 -0700 Date: Wed, 25 Mar 2015 13:07:58 -0700 From: Toerless Eckert To: Brian E Carpenter Message-ID: <20150325200758.GD31979@cisco.com> References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> <5512DE41.6030209@gmail.com> <20150325170646.GB31979@cisco.com> <5512F839.6080502@gmail.com> <20150325184552.GC31979@cisco.com> <551305C4.9030001@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <551305C4.9030001@gmail.com> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Hannes Tschofenig , Rene Struik , "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, 25 Mar 2015 20:08:03 -0000 Thanks Brian, There is a difference between call-home and bring-in-key. Aka: You have in the powerplant a server that runs Registrar, CA and config-server for new devices in the powerplant, no outside network connectivity required. With both zerotouch and pritikin(masa included) approaches i could make this work by requiring that somebody brings into the powerplant a USB stick with the right authorization material. And given how this is very little data, it would also be very easy to vet that this is not a virus or the like. If i see it correctly, the zerotouch draft does not even have the option to forego the backend processes that result in such a USB stick with files. Although i think it would equally be possible to do that as it would be possible in draft-pritikin to make MASA optional. I just think that devices that do permit to be enrolled/configured without MASA or the zerotouch backend equivalent will be intrinsically less secure. It does make sense though to permit them to exist, especially for high security envionments where te vendor and customer may have a much better lock on the ongoing physical presence of the device and what networks it gets connected to. Cheers Toerless P.S.: I think all devices other than those owned by DoD and DoE can be expected to have connectivity to a backend server in Fort Meade including White House and Bundestag ;-) On Thu, Mar 26, 2015 at 08:00:20AM +1300, Brian E Carpenter wrote: > Indeed, I think any kind of call-home is unacceptable in > certain high security environments. Would you expect, say, > the door lock control system of the White House or the > Bundestag to call an external server for a firmware update? > > Another aspect is disaster recovery. If you have to reboot > your network at a time when all Internet access is down > (think hurricane or earthquake), you don't want to *require* > an external service. > > "We can't open the elevator doors because the Internet is down." > > I really think our bootstrap scenarios have to allow for this. > > Brian > > On 26/03/2015 07:45, Toerless Eckert wrote: > > Thanks, Brian. > > > > If i understand it correctly, in the netconf zerotouch approach, > > the router to control the meltdown process in the reactor would still > > need to receive a file from the outside of the reactor airgap (axctually > > something like a .tar of 4? files). And in result it would have some > > bootstrap config, but not a nuclear pant operator certificate. > > > > True/False ? > > > > How would that match your requirements - any better/different to > > you than MASA ? > > > > Cheers > > Toerless > > > > On Thu, Mar 26, 2015 at 07:02:33AM +1300, Brian E Carpenter wrote: > >> On 26/03/2015 06:06, Toerless Eckert wrote: > >>> Should i be able to find a more detailed reasonining from you about MASA > >>> in the mailing list archive ? if not, would you mind to elaborate here ? > >> > >> I expect it is somewhere in my comments on draft-pritikin, but basically > >> I think we MUST have a mode that has no external dependencies whatever. > >> A nuclear plant operator might agree with me, or anyone who wants a secure > >> network with an air gap round it. > >> > >> As long as the MASA is optional, it's fine. > >> > >> Brian > >> > >>> > >>> Cheers > >>> Toerless > >>> > >>> On Thu, Mar 26, 2015 at 05:11:45AM +1300, Brian E Carpenter wrote: > >>>> I think it is unanswerable, or at least the answer is YMMV. You may remember that > >>>> one of my comments on draft-pritikin was basically: I hate the MASA. I was glad > >>>> to see the connection to the MASA was clearly indicated as optional in the slides > >>>> yesterday. The point is that we have no control over this - different classes > >>>> of device and different vendors will have different ideas about this. I firmly > >>>> believe that any design we do in the IETF has to be very flexible on > >>>> this point. > >>>> > >>>> Regards > >>>> Brian > >>>> > >>>> On 25/03/2015 11:21, Rene Struik wrote: > >>>>> Hi Hannes: > >>>>> > >>>>> I think supply chain issues, and transgression from one supply chain step to the next, are important in life-cycle > >>>>> considerations. This includes how to move from one logical "owner" to the next and potentially "cutting the ties" with the > >>>>> former. These aspects certainly require more work. > >>>>> > >>>>> A very simple example of supply chain would be relabelling a device as a "white goods" device (e.g., by selling a branded good > >>>>> at a superstore, such as Walmart, under the Walmart brand, whereas in reality it outsourced all production (except perhaps > >>>>> putting the sticker on top). > >>>>> > >>>>> Best regards, Rene > >>>>> > >>>>> On 3/24/2015 6:11 PM, Hannes Tschofenig wrote: > >>>>>> There was no time during the meeting today to ask too many questions > >>>>>> (because of lack of time). That's unfortunately and so I have to fall > >>>>>> back to the mailing list. > >>>>>> > >>>>>> I wanted to get some better understand what the ownership concept is > >>>>>> about and what the implications are for the protocol design. The term > >>>>>> came up in various presentations today and it appears to be important. > >>>>>> > >>>>>> Many parties are involved in the manufacturing process of products today > >>>>>> and the value chain is certainly complex. Hence, who the owner of what > >>>>>> is and at what point might be difficult to determine. > >>>>>> > >>>>>> Does it really matter who the owner actually is? > >>>>>> > >>>>>> Ciao > >>>>>> Hannes > > -- --- Toerless Eckert, eckert@cisco.com From nobody Wed Mar 25 13:14: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 E31431B2AF8 for ; Wed, 25 Mar 2015 13:14:52 -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 BF79yJNYOSud for ; Wed, 25 Mar 2015 13:14:50 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-01.alcatel-lucent.com [135.245.210.20]) (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 9944F1A92EF for ; Wed, 25 Mar 2015 13:14:49 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 5ACE57FDAE7B for ; Wed, 25 Mar 2015 20:14:41 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id t2PKEgIA019808 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 25 Mar 2015 16:14:42 -0400 Received: from [135.244.23.228] (135.5.27.18) by US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 25 Mar 2015 16:14:42 -0400 Message-ID: <5513172F.3040000@alcatel-lucent.com> Date: Wed, 25 Mar 2015 21:14:39 +0100 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.5.0 MIME-Version: 1.0 To: References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> <5512DE41.6030209@gmail.com> <20150325170646.GB31979@cisco.com>, <5512F839.6080502@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B925F4C1B6D@NKGEML512-MBS.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B925F4C1B6D@NKGEML512-MBS.china.huawei.com> Content-Type: multipart/alternative; boundary="------------040804010105030300000509" X-Originating-IP: [135.5.27.18] 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, 25 Mar 2015 20:14:53 -0000 --------------040804010105030300000509 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Dear all, We must remember the initial requirements: ability to _securely_ and _automatically_ enroll a device (or a function, piece of software (e.g. VNFs)). The automation part is motivated by operational costs. The security level might be dependent on the end-user. You may want to be isolated/independent from an external/remote system, but you still want security, then it will cost you more (e.g. "trusted" humans installing (manually) the device or software). This could work for certain cases or up to a certain level, but if you imagine not only physical devices but also digital/software functions, this will become rapidly prohibitive/unpractical. So, the point is that yes you can have the flexibility but don't forget the cost. Finally, in the context of ANIMA, if we are not allowed to think/design stuff that increase the level of automation/autonomicity of the technologies, then why are we having a working group on it? I mean it is ok to have the option to disable automation, etc. and it should be integrated in the design of our stuff, however in the majority of the cases (i.e. not nuclear plant) we want more automation and lower operational costs. The reliability, trust and confidence in/of the technology is orthogonal. Best regards, Laurent. On 25/03/2015 20:26, Sheng Jiang wrote: >> By Brian >> I think we MUST have a mode that has no external dependencies whatever. >> As long as the MASA is optional, it's fine. > It is exactly the same comment that I have made a couple of time. It is up to the owner of the network or the network operator how they may validate the bootstrapped devices. It may be MASA, may be some other ways, or even simply nothing (yes, it is insecure). But the owner of the network has the right to choose. Any mandated mechanism would harm the independency of the network operator. > > Best regards, > > Sheng > >> Cheers >> Toerless >> >> On Thu, Mar 26, 2015 at 05:11:45AM +1300, Brian E Carpenter wrote: >>> I think it is unanswerable, or at least the answer is YMMV. You may remember that >>> one of my comments on draft-pritikin was basically: I hate the MASA. I was glad >>> to see the connection to the MASA was clearly indicated as optional in the slides >>> yesterday. The point is that we have no control over this - different classes >>> of device and different vendors will have different ideas about this. I firmly >>> believe that any design we do in the IETF has to be very flexible on >>> this point. >>> >>> Regards >>> Brian >>> >>> On 25/03/2015 11:21, Rene Struik wrote: >>>> Hi Hannes: >>>> >>>> I think supply chain issues, and transgression from one supply chain step to the next, are important in life-cycle >>>> considerations. This includes how to move from one logical "owner" to the next and potentially "cutting the ties" with the >>>> former. These aspects certainly require more work. >>>> >>>> A very simple example of supply chain would be relabelling a device as a "white goods" device (e.g., by selling a branded good >>>> at a superstore, such as Walmart, under the Walmart brand, whereas in reality it outsourced all production (except perhaps >>>> putting the sticker on top). >>>> >>>> Best regards, Rene >>>> >>>> On 3/24/2015 6:11 PM, Hannes Tschofenig wrote: >>>>> There was no time during the meeting today to ask too many questions >>>>> (because of lack of time). That's unfortunately and so I have to fall >>>>> back to the mailing list. >>>>> >>>>> I wanted to get some better understand what the ownership concept is >>>>> about and what the implications are for the protocol design. The term >>>>> came up in various presentations today and it appears to be important. >>>>> >>>>> Many parties are involved in the manufacturing process of products today >>>>> and the value chain is certainly complex. Hence, who the owner of what >>>>> is and at what point might be difficult to determine. >>>>> >>>>> Does it really matter who the owner actually is? >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> _______________________________________________ >>> 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 > _______________________________________________ > 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 --------------040804010105030300000509 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit Dear all,

We must remember the initial requirements: ability to securely and automatically enroll a device (or a function, piece of software (e.g. VNFs)).

The automation part is motivated by operational costs.
The security level might be dependent on the end-user.

You may want to be isolated/independent from an external/remote system, but you still want security, then it will cost you more (e.g. "trusted" humans installing (manually) the device or software).
This could work for certain cases or up to a certain level, but if you imagine not only physical devices but also digital/software functions, this will become rapidly prohibitive/unpractical.

So, the point is that yes you can have the flexibility but don't forget the cost.

Finally, in the context of ANIMA, if we are not allowed to think/design stuff that increase the level of automation/autonomicity of the technologies, then why are we having a working group on it?
I mean it is ok to have the option to disable automation, etc. and it should be integrated in the design of our stuff, however in the majority of the cases (i.e. not nuclear plant) we want more automation and lower operational costs.
The reliability, trust and confidence in/of the technology is orthogonal.

Best regards, Laurent.


On 25/03/2015 20:26, Sheng Jiang wrote:
By Brian
I think we MUST have a mode that has no external dependencies whatever.
As long as the MASA is optional, it's fine.

It is exactly the same comment that I have made a couple of time. It is up to the owner of the network or the network operator how they may validate the bootstrapped devices. It may be MASA, may be some other ways, or even simply nothing (yes, it is insecure). But the owner of the network has the right to choose. Any mandated mechanism would harm the independency of the network operator.

Best regards,

Sheng


Cheers
    Toerless

On Thu, Mar 26, 2015 at 05:11:45AM +1300, Brian E Carpenter wrote:

I think it is unanswerable, or at least the answer is YMMV. You may remember that
one of my comments on draft-pritikin was basically: I hate the MASA. I was glad
to see the connection to the MASA was clearly indicated as optional in the slides
yesterday. The point is that we have no control over this - different classes
of device and different vendors will have different ideas about this. I firmly
believe that any design we do in the IETF has to be very flexible on
this point.

Regards
   Brian

On 25/03/2015 11:21, Rene Struik wrote:

Hi Hannes:

I think supply chain issues, and transgression from one supply chain step to the next, are important in life-cycle
considerations. This includes how to move from one logical "owner" to the next and potentially "cutting the ties" with the
former. These aspects certainly require more work.

A very simple example of supply chain would be relabelling a device as a "white goods" device (e.g., by selling a branded good
at a superstore, such as Walmart, under the Walmart brand, whereas in reality it outsourced all production (except perhaps
putting the sticker on top).

Best regards, Rene

On 3/24/2015 6:11 PM, Hannes Tschofenig wrote:

There was no time during the meeting today to ask too many questions
(because of lack of time). That's unfortunately and so I have to fall
back to the mailing list.

I wanted to get some better understand what the ownership concept is
about and what the implications are for the protocol design. The term
came up in various presentations today and it appears to be important.

Many parties are involved in the manufacturing process of products today
and the value chain is certainly complex. Hence, who the owner of what
is and at what point might be difficult to determine.

Does it really matter who the owner actually is?

Ciao
Hannes



_______________________________________________
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


_______________________________________________
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
_______________________________________________
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

      

    

  


--------------040804010105030300000509--


From nobody Wed Mar 25 13:55: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 3A3181B2BD1 for ; Wed, 25 Mar 2015 13:55:16 -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 8MXwo05ljibt for ; Wed, 25 Mar 2015 13:55:14 -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 4EF471B2B9F for ; Wed, 25 Mar 2015 13:55:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9558; q=dns/txt; s=iport; t=1427316909; x=1428526509; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=sQuxp3UvCj1a9PsWGIO/fZ461Io9oAwvBDCgwcSqd9k=; b=IEvvscGvnrHiFseICSf2yrAe3NM8F+Z0X6dTYZSGahF5z4GeFdouzXpb w+aoFiLlKjL2zM4wyaw/YEXXXlruy0nSe55S3/HjdeH6pD4mUkghcCe5p 3UzCt7d86vKXVEtCYm2DjJ7u9YulV0mi4p7vz38u+FFCVb3BaLzn2Bvga 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BVBQDYHxNV/4YNJK1ZA4MGUloExQMBCYV1AoFbOxEBAQEBAQEBfIQVAQEEAQEBawMIEAIBCA4xByEGCxQRAgQOBRkCiAADEQ3EOQ2FRQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEiiJ/gkaBTREBQBAHEYMGgRYFjSqBF4IOhhKCD4FMi2OCIIYmIoICHIFQb4ELOX8BAQE
X-IronPort-AV: E=Sophos;i="5.11,466,1422921600";  d="scan'208,217";a="135301088"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-8.cisco.com with ESMTP; 25 Mar 2015 20:55:08 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t2PKt8If019675 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Mar 2015 20:55:08 GMT
Received: from xmb-rcd-x03.cisco.com ([169.254.7.184]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.03.0195.001; Wed, 25 Mar 2015 15:55:08 -0500
From: "Max Pritikin (pritikin)" 
To: Rene Struik 
Thread-Topic: [Anima] Ownership Concept
Thread-Index: AQHQZn+Wm4eAxWuLS02QOiRijuPZe50siH6AgAF6E4A=
Date: Wed, 25 Mar 2015 20:55:07 +0000
Message-ID: <1D2369B2-4AEA-4479-8177-59BEB7DA0B6E@cisco.com>
References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com>
In-Reply-To: <5511E359.10600@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.24.233.138]
Content-Type: multipart/alternative; boundary="_000_1D2369B24AEA4479817759BEB7DA0B6Eciscocom_"
MIME-Version: 1.0
Archived-At: 
Cc: Hannes Tschofenig , "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, 25 Mar 2015 20:55:16 -0000

--_000_1D2369B24AEA4479817759BEB7DA0B6Eciscocom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable


An excellent question Hannes.

During bootstrapping the concern is that a device is bootstrapped into the =
=93wrong=94 domain, e.g. into the domain of an attacker that does not own t=
he device. This can be seen as a DoS attack, in that the newly detected dev=
ice was expected to join the target domain and it did not. In order to supp=
ort the points that Rene brings up I don=92t think this is an attack agains=
t the device though =97 it is originally =93just=94 a DoS attack against th=
e domain.

It leads to a persistent attack against the domain though. If the attacker =
inserts malware onto the device and then injects it back into the domain th=
at originally expected the device it has now injected malware into the targ=
et domain. This is, in my mind, the more important threat to mitigate.

Possible mitigations include:

a) Fully tracking ownership. This mitigates the attack but requires the Ven=
dor to fully secure the life-cycle including all the transitions detailed b=
y Rene. All security depends on good decisions by the Vendor. [this should =
look similar to the draft-ietf-netconf-zerotouch-02 approach].

b) Trusted Hardware Modules such that malware can not be installed on devic=
es or that such devices can be detected by the target domain. This requires=
 very specific and detailed hardware such as the TPM provided by Trusted Co=
mputing Group and is, I think, out of scope for IETF solutions.

c) Providing the domain a method of detecting and blocking the insertion. F=
or example if the Vendor and its partners provided a log service that indis=
criminately produced =93authorization tokens=94 for devices and domains to =
join each other then the Domain could check the log service to detect poten=
tial attackers thus mitigating the problem. All decisions are made on the D=
omain. [this should look similar to the draft-pritikin-anima-bootstrapping-=
keyinfra-01 approach].

I think this does effect the protocol design.

- max


On Mar 24, 2015, at 4:21 PM, Rene Struik > wrote:

Hi Hannes:

I think supply chain issues, and transgression from one supply chain step t=
o the next, are important in life-cycle considerations. This includes how t=
o move from one logical "owner" to the next and potentially "cutting the ti=
es" with the former. These aspects certainly require more work.

A very simple example of supply chain would be relabelling a device as a "w=
hite goods" device (e.g., by selling a branded good at a superstore, such a=
s Walmart, under the Walmart brand, whereas in reality it outsourced all pr=
oduction (except perhaps putting the sticker on top).

Best regards, Rene

On 3/24/2015 6:11 PM, Hannes Tschofenig wrote:

There was no time during the meeting today to ask too many questions
(because of lack of time). That's unfortunately and so I have to fall
back to the mailing list.

I wanted to get some better understand what the ownership concept is
about and what the implications are for the protocol design. The term
came up in various presentations today and it appears to be important.

Many parties are involved in the manufacturing process of products today
and the value chain is certainly complex. Hence, who the owner of what
is and at what point might be difficult to determine.

Does it really matter who the owner actually is?

Ciao
Hannes





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




--
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

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


--_000_1D2369B24AEA4479817759BEB7DA0B6Eciscocom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <953624BEC1B07949B79CED8E81051EAA@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable











An excellent question Hannes. 






During bootstrapping the concern is that a device is bootstrapped into=
 the =93wrong=94 domain, e.g. into the domain of an attacker that does not =
own the device. This can be seen as a DoS attack, in that the newly detecte=
d device was expected to join the target
 domain and it did not. In order to support the points that Rene brings up =
I don=92t think this is an attack against the device though =97 it is origi=
nally =93just=94 a DoS attack against the domain. 







It leads to a persistent attack against the domain though. If the atta=
cker inserts malware onto the device and then injects it back into the doma=
in that originally expected the device it has now injected malware into the=
 target domain. This is, in my mind,
 the more important threat to mitigate.







Possible mitigations include:







a) Fully tracking ownership. This mitigates the attack but requires th=
e Vendor to fully secure the life-cycle including all the transitions detai=
led by Rene. All security depends on good decisions by the Vendor. [this sh=
ould look similar to the draft-ietf-netconf-zerotouch-02
 approach].







b) Trusted Hardware Modules such that malware can not be installed on =
devices or that such devices can be detected by the target domain. This req=
uires very specific and detailed hardware such as the TPM provided by Trust=
ed Computing Group and is, I think,
 out of scope for IETF solutions. 







c) Providing the domain a method of detecting and blocking the inserti=
on. For example if the Vendor and its partners provided a log service that =
indiscriminately produced =93authorization tokens=94 for devices and domain=
s to join each other then the Domain
 could check the log service to detect potential attackers thus mitigating =
the problem. All decisions are made on the Domain. [this should look simila=
r to the draft-pritikin-anima-bootstrapping-keyinfra-01 approach]. 






I think this does effect the protocol design.







- max












On Mar 24, 2015, at 4:21 PM, Rene Struik <rstruik.ext@gmail.com> wrote:








Hi Hannes:



I think supply chain issues, and transgression from one supply chain step t=
o the next, are important in life-cycle considerations. This includes how t=
o move from one logical "owner" to the next and potentially "=
;cutting the ties" with the former. These aspects
 certainly require more work.



A very simple example of supply chain would be relabelling a device as a &q=
uot;white goods" device (e.g., by selling a branded good at a supersto=
re, such as Walmart, under the Walmart brand, whereas in reality it outsour=
ced all production (except perhaps putting
 the sticker on top).



Best regards, Rene



On 3/24/2015 6:11 PM, Hannes Tschofenig wrote:






There was no time during the meeting today to ask too many q=
uestions
(because of lack of time). That's unfortunately and so I have to fall
back to the mailing list.

I wanted to get some better understand what the ownership concept is
about and what the implications are for the protocol design. The term
came up in various presentations today and it appears to be important.

Many parties are involved in the manufacturing process of products today
and the value chain is certainly complex. Hence, who the owner of what
is and at what point might be difficult to determine.

Does it really matter who the owner actually is?

Ciao
Hannes






 


_______________________________________________
Anima mailing list
Anima@=
ietf.org
https://www.ietf.org/mailman/listinfo/anima









--=20
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363



_______________________________________________

Anima mailing list

Anima@ietf.org

https://www.ietf.org/mailman/listinfo/anima














--_000_1D2369B24AEA4479817759BEB7DA0B6Eciscocom_--


From nobody Wed Mar 25 14:00:19 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 1C1E61B2C02 for ; Wed, 25 Mar 2015 14:00:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.911
X-Spam-Level: 
X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_84=0.6, 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 s2lz_404kRee for ; Wed, 25 Mar 2015 14:00:16 -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 E513D1A0058 for ; Wed, 25 Mar 2015 14:00:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7047; q=dns/txt; s=iport; t=1427317216; x=1428526816; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=WNwdn4hQjyDt00b9FbtnRZdwMj6Inivxnqg9FR/daYI=; b=PBZOLfSsmRZGCqLgebsnXVjexvS6H2nJ2puEtTTsW+L3E9ObyvP7orP1 yWybiIYc01Nd6z3hmisDDlygGI+FVIThHZkvIt375BOVggRdXOZaEVUOM LlmboFXMvnJ8yI3Kt2Ef6fahtnmodJf09QyLIfD2cRQnsMAN3krxgwJVT w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ARBQC5IBNV/4wNJK1cgwZSTgwExQcKhXUCgVtMAQEBAQEBfYQUAQEBAwEBAQFrCwULAgEIGC4nCyUCBA4FGYgOCA3KDAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEiiJ/hEMzB4MXgRYFkFCGE4NcgRuKSIFUgy6DRyKDbm+BBCQcfwEBAQ
X-IronPort-AV: E=Sophos;i="5.11,467,1422921600"; d="scan'208";a="406618003"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-7.cisco.com with ESMTP; 25 Mar 2015 21:00:15 +0000
Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t2PL0EZN027981 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Mar 2015 21:00:14 GMT
Received: from xmb-rcd-x03.cisco.com ([169.254.7.184]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Wed, 25 Mar 2015 16:00:14 -0500
From: "Max Pritikin (pritikin)" 
To: "Toerless Eckert (eckert)" 
Thread-Topic: [Anima] Ownership Concept
Thread-Index: AQHQZn+Wm4eAxWuLS02QOiRijuPZe50siH6AgAErG4CAAA9fAIAAD5aAgAAMGgCAAAQLAIAAEuYAgAAOZIA=
Date: Wed, 25 Mar 2015 21:00:13 +0000
Message-ID: <3C8F19F4-54E7-48E5-AD62-A2300E946C4E@cisco.com>
References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> <5512DE41.6030209@gmail.com> <20150325170646.GB31979@cisco.com> <5512F839.6080502@gmail.com> <20150325184552.GC31979@cisco.com> <551305C4.9030001@gmail.com> <20150325200758.GD31979@cisco.com>
In-Reply-To: <20150325200758.GD31979@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.24.233.138]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <343F3D33A0671A418D9CD6C3A85C7195@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: Hannes Tschofenig , "anima@ietf.org" , Rene Struik 
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, 25 Mar 2015 21:00:18 -0000

On Mar 25, 2015, at 2:07 PM, Toerless Eckert  wrote:

> Thanks Brian,
>=20
> There is a difference between call-home and bring-in-key. Aka:
> You have in the powerplant a server that runs Registrar, CA and
> config-server for new devices in the powerplant, no outside
> network connectivity required.
>=20
> With both zerotouch and pritikin(masa included) approaches i could
> make this work by requiring that somebody brings into the powerplant
> a USB stick with the right authorization material. And given how
> this is very little data, it would also be very easy to vet that this
> is not a virus or the like.
>=20
> If i see it correctly, the zerotouch draft does not even have the option
> to forego the backend processes that result in such a USB stick with
> files. Although i think it would equally be possible to do that as
> it would be possible in draft-pritikin to make MASA optional.

See the first paragraph of the security considerations:

   In order to support a variety of use cases, devices can be claimed by
   a registrar without proving possession of the device in question.

This allows the use case of powerplants, oil rigs, etc.

I don=92t understand how one can expect the backend to be totally =93option=
al=94 since the device doesn=92t know if it should be optional or not. The =
best I think we can do is make the backend =93no decision=94 and =93air gap=
 compliant=94. But if the device itself is willing to make the back end opt=
ional thats like saying that the end device has a trivial downgrade attack.=
=20

I wonder if the netconf draft (ownership validation) isn=92t better for off=
line situations than what the masa has described. A mix of hte two might wo=
rk well then,=20

- max

>=20
> I just think that devices that do permit to be enrolled/configured
> without MASA or the zerotouch backend equivalent will be intrinsically
> less secure. It does make sense though to permit them to exist, especiall=
y
> for high security envionments where te vendor and customer may have
> a much better lock on the ongoing physical presence of the device and
> what networks it gets connected to.
>=20
> Cheers
>    Toerless
>=20
> P.S.: I think all devices other than those owned by DoD and DoE can
> be expected to have connectivity to a backend server in Fort Meade
> including White House and Bundestag ;-)
>=20
> On Thu, Mar 26, 2015 at 08:00:20AM +1300, Brian E Carpenter wrote:
>> Indeed, I think any kind of call-home is unacceptable in
>> certain high security environments. Would you expect, say,
>> the door lock control system of the White House or the
>> Bundestag to call an external server for a firmware update?
>>=20
>> Another aspect is disaster recovery. If you have to reboot
>> your network at a time when all Internet access is down
>> (think hurricane or earthquake), you don't want to *require*
>> an external service.
>>=20
>> "We can't open the elevator doors because the Internet is down."
>>=20
>> I really think our bootstrap scenarios have to allow for this.
>>=20
>>    Brian
>>=20
>> On 26/03/2015 07:45, Toerless Eckert wrote:
>>> Thanks, Brian.
>>>=20
>>> If i understand it correctly, in the netconf zerotouch approach,
>>> the router to control the meltdown process in the reactor would still=20
>>> need to receive a file from the outside of the reactor airgap (axctuall=
y
>>> something like a .tar of 4? files). And in result it would have some
>>> bootstrap config, but not a nuclear pant operator certificate.=20
>>>=20
>>> True/False ?
>>>=20
>>> How would that match your requirements - any better/different to
>>> you than MASA ?
>>>=20
>>> Cheers
>>>    Toerless
>>>=20
>>> On Thu, Mar 26, 2015 at 07:02:33AM +1300, Brian E Carpenter wrote:
>>>> On 26/03/2015 06:06, Toerless Eckert wrote:
>>>>> Should i be able to find a more detailed reasonining from you about M=
ASA=20
>>>>> in the mailing list archive ?  if not, would you mind to elaborate he=
re ?
>>>>=20
>>>> I expect it is somewhere in my comments on draft-pritikin, but basical=
ly
>>>> I think we MUST have a mode that has no external dependencies whatever=
.
>>>> A nuclear plant operator might agree with me, or anyone who wants a se=
cure
>>>> network with an air gap round it.
>>>>=20
>>>> As long as the MASA is optional, it's fine.
>>>>=20
>>>>    Brian
>>>>=20
>>>>>=20
>>>>> Cheers
>>>>>    Toerless
>>>>>=20
>>>>> On Thu, Mar 26, 2015 at 05:11:45AM +1300, Brian E Carpenter wrote:
>>>>>> I think it is unanswerable, or at least the answer is YMMV. You may =
remember that
>>>>>> one of my comments on draft-pritikin was basically: I hate the MASA.=
 I was glad
>>>>>> to see the connection to the MASA was clearly indicated as optional =
in the slides
>>>>>> yesterday. The point is that we have no control over this - differen=
t classes
>>>>>> of device and different vendors will have different ideas about this=
. I firmly
>>>>>> believe that any design we do in the IETF has to be very flexible on
>>>>>> this point.
>>>>>>=20
>>>>>> Regards
>>>>>>   Brian
>>>>>>=20
>>>>>> On 25/03/2015 11:21, Rene Struik wrote:
>>>>>>> Hi Hannes:
>>>>>>>=20
>>>>>>> I think supply chain issues, and transgression from one supply chai=
n step to the next, are important in life-cycle
>>>>>>> considerations. This includes how to move from one logical "owner" =
to the next and potentially "cutting the ties" with the
>>>>>>> former. These aspects certainly require more work.
>>>>>>>=20
>>>>>>> A very simple example of supply chain would be relabelling a device=
 as a "white goods" device (e.g., by selling a branded good
>>>>>>> at a superstore, such as Walmart, under the Walmart brand, whereas =
in reality it outsourced all production (except perhaps
>>>>>>> putting the sticker on top).
>>>>>>>=20
>>>>>>> Best regards, Rene
>>>>>>>=20
>>>>>>> On 3/24/2015 6:11 PM, Hannes Tschofenig wrote:
>>>>>>>> There was no time during the meeting today to ask too many questio=
ns
>>>>>>>> (because of lack of time). That's unfortunately and so I have to f=
all
>>>>>>>> back to the mailing list.
>>>>>>>>=20
>>>>>>>> I wanted to get some better understand what the ownership concept =
is
>>>>>>>> about and what the implications are for the protocol design. The t=
erm
>>>>>>>> came up in various presentations today and it appears to be import=
ant.
>>>>>>>>=20
>>>>>>>> Many parties are involved in the manufacturing process of products=
 today
>>>>>>>> and the value chain is certainly complex. Hence, who the owner of =
what
>>>>>>>> is and at what point might be difficult to determine.
>>>>>>>>=20
>>>>>>>> Does it really matter who the owner actually is?
>>>>>>>>=20
>>>>>>>> Ciao
>>>>>>>> Hannes
>>>=20
>=20
> --=20
> ---
> Toerless Eckert, eckert@cisco.com
>=20
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima


From nobody Wed Mar 25 14:05: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 CF88B1A8AC1 for ; Wed, 25 Mar 2015 14:05:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level: 
X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_84=0.6, 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 PeXNfRyswhM5 for ; Wed, 25 Mar 2015 14:05:11 -0700 (PDT)
Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::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 160DF1A8AAF for ; Wed, 25 Mar 2015 14:05:11 -0700 (PDT)
Received: by wibbg6 with SMTP id bg6so40486743wib.0 for ; Wed, 25 Mar 2015 14:05:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=fMYKag/Zy0xpamozmI0jSHBJ6NDMl+r7SvY/B5BthI0=; b=uQps1Cm39MRJU1eiVnNwI+QQb0DMx9bFkUG8uT2AO4Po63ydV6O30ZJLLu0w9hvpQP m9R675SOllhelD7ePPoRK1chIkphjJcO7AdIgQx1TT7pqtzb0+pIVv4BThvXS5T/AFOv M5As7m0SBeDZ3iywwv+QoEQ8Nfp+nXfkGvSgiYXirlqvrIWV4VdFDJdRZzwq0+bPhJRW YdJz3+eDczHscLdw3AWcncAn6mRVgtJgwbbYeYYWYGqCdMxYz+f+85p467P7V9XGKMGc Lels5mspEl4yqrVUDivnIzESC8/IUVSE5nZ5urGZxaQwVXarLkOTCpqEUEQ2xQUmsBO6 Ii0g==
X-Received: by 10.180.80.164 with SMTP id s4mr33340453wix.78.1427317509627; Wed, 25 Mar 2015 14:05:09 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:160:2182:4ce6:a93b:890d? ([2001:67c:370:160:2182:4ce6:a93b:890d]) by mx.google.com with ESMTPSA id pm6sm9843976wic.20.2015.03.25.14.05.07 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Mar 2015 14:05:08 -0700 (PDT)
Message-ID: <551322FF.9050704@gmail.com>
Date: Wed, 25 Mar 2015 17:05:03 -0400
From: Rene Struik 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Toerless Eckert ,  Brian E Carpenter 
References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> <5512DE41.6030209@gmail.com> <20150325170646.GB31979@cisco.com> <5512F839.6080502@gmail.com> <20150325184552.GC31979@cisco.com> <551305C4.9030001@gmail.com> <20150325200758.GD31979@cisco.com>
In-Reply-To: <20150325200758.GD31979@cisco.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: Hannes Tschofenig , "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, 25 Mar 2015 21:05:16 -0000

Dear Toerless:

I think it would help to describe the underlying security model, from a 
device and network lifecycle perspective. Essential elements here are 
description of security policy enforcement, and potential transitions 
here over time. This also allows filling in detail as to what degree 
statements, such as the one below, are technically correct.

Rene

I just think that devices that do permit to be enrolled/configured
without MASA or the zerotouch backend equivalent will be intrinsically
less secure.



On 3/25/2015 4:07 PM, Toerless Eckert wrote:
> Thanks Brian,
>
> There is a difference between call-home and bring-in-key. Aka:
> You have in the powerplant a server that runs Registrar, CA and
> config-server for new devices in the powerplant, no outside
> network connectivity required.
>
> With both zerotouch and pritikin(masa included) approaches i could
> make this work by requiring that somebody brings into the powerplant
> a USB stick with the right authorization material. And given how
> this is very little data, it would also be very easy to vet that this
> is not a virus or the like.
>
> If i see it correctly, the zerotouch draft does not even have the option
> to forego the backend processes that result in such a USB stick with
> files. Although i think it would equally be possible to do that as
> it would be possible in draft-pritikin to make MASA optional.
>
> I just think that devices that do permit to be enrolled/configured
> without MASA or the zerotouch backend equivalent will be intrinsically
> less secure. It does make sense though to permit them to exist, especially
> for high security envionments where te vendor and customer may have
> a much better lock on the ongoing physical presence of the device and
> what networks it gets connected to.
>
> Cheers
>      Toerless
>
> P.S.: I think all devices other than those owned by DoD and DoE can
> be expected to have connectivity to a backend server in Fort Meade
> including White House and Bundestag ;-)
>
> On Thu, Mar 26, 2015 at 08:00:20AM +1300, Brian E Carpenter wrote:
>> Indeed, I think any kind of call-home is unacceptable in
>> certain high security environments. Would you expect, say,
>> the door lock control system of the White House or the
>> Bundestag to call an external server for a firmware update?
>>
>> Another aspect is disaster recovery. If you have to reboot
>> your network at a time when all Internet access is down
>> (think hurricane or earthquake), you don't want to *require*
>> an external service.
>>
>> "We can't open the elevator doors because the Internet is down."
>>
>> I really think our bootstrap scenarios have to allow for this.
>>
>>      Brian
>>
>> On 26/03/2015 07:45, Toerless Eckert wrote:
>>> Thanks, Brian.
>>>
>>> If i understand it correctly, in the netconf zerotouch approach,
>>> the router to control the meltdown process in the reactor would still
>>> need to receive a file from the outside of the reactor airgap (axctually
>>> something like a .tar of 4? files). And in result it would have some
>>> bootstrap config, but not a nuclear pant operator certificate.
>>>
>>> True/False ?
>>>
>>> How would that match your requirements - any better/different to
>>> you than MASA ?
>>>
>>> Cheers
>>>      Toerless
>>>
>>> On Thu, Mar 26, 2015 at 07:02:33AM +1300, Brian E Carpenter wrote:
>>>> On 26/03/2015 06:06, Toerless Eckert wrote:
>>>>> Should i be able to find a more detailed reasonining from you about MASA
>>>>> in the mailing list archive ?  if not, would you mind to elaborate here ?
>>>> I expect it is somewhere in my comments on draft-pritikin, but basically
>>>> I think we MUST have a mode that has no external dependencies whatever.
>>>> A nuclear plant operator might agree with me, or anyone who wants a secure
>>>> network with an air gap round it.
>>>>
>>>> As long as the MASA is optional, it's fine.
>>>>
>>>>      Brian
>>>>
>>>>> Cheers
>>>>>      Toerless
>>>>>
>>>>> On Thu, Mar 26, 2015 at 05:11:45AM +1300, Brian E Carpenter wrote:
>>>>>> I think it is unanswerable, or at least the answer is YMMV. You may remember that
>>>>>> one of my comments on draft-pritikin was basically: I hate the MASA. I was glad
>>>>>> to see the connection to the MASA was clearly indicated as optional in the slides
>>>>>> yesterday. The point is that we have no control over this - different classes
>>>>>> of device and different vendors will have different ideas about this. I firmly
>>>>>> believe that any design we do in the IETF has to be very flexible on
>>>>>> this point.
>>>>>>
>>>>>> Regards
>>>>>>     Brian
>>>>>>
>>>>>> On 25/03/2015 11:21, Rene Struik wrote:
>>>>>>> Hi Hannes:
>>>>>>>
>>>>>>> I think supply chain issues, and transgression from one supply chain step to the next, are important in life-cycle
>>>>>>> considerations. This includes how to move from one logical "owner" to the next and potentially "cutting the ties" with the
>>>>>>> former. These aspects certainly require more work.
>>>>>>>
>>>>>>> A very simple example of supply chain would be relabelling a device as a "white goods" device (e.g., by selling a branded good
>>>>>>> at a superstore, such as Walmart, under the Walmart brand, whereas in reality it outsourced all production (except perhaps
>>>>>>> putting the sticker on top).
>>>>>>>
>>>>>>> Best regards, Rene
>>>>>>>
>>>>>>> On 3/24/2015 6:11 PM, Hannes Tschofenig wrote:
>>>>>>>> There was no time during the meeting today to ask too many questions
>>>>>>>> (because of lack of time). That's unfortunately and so I have to fall
>>>>>>>> back to the mailing list.
>>>>>>>>
>>>>>>>> I wanted to get some better understand what the ownership concept is
>>>>>>>> about and what the implications are for the protocol design. The term
>>>>>>>> came up in various presentations today and it appears to be important.
>>>>>>>>
>>>>>>>> Many parties are involved in the manufacturing process of products today
>>>>>>>> and the value chain is certainly complex. Hence, who the owner of what
>>>>>>>> is and at what point might be difficult to determine.
>>>>>>>>
>>>>>>>> Does it really matter who the owner actually is?
>>>>>>>>
>>>>>>>> Ciao
>>>>>>>> Hannes


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


From nobody Wed Mar 25 15:00: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 A3C8C1A87C3 for ; Wed, 25 Mar 2015 15:00: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 2cShbP0oKYaW for ; Wed, 25 Mar 2015 15:00: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 92B491B2A52 for ; Wed, 25 Mar 2015 15:00:25 -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 BQS09317; Wed, 25 Mar 2015 22:00:24 +0000 (GMT)
Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 25 Mar 2015 22:00:22 +0000
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.209]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Thu, 26 Mar 2015 06:00:15 +0800
From: Sheng Jiang 
To: "Max Pritikin (pritikin)" , "Toerless Eckert (eckert)" 
Thread-Topic: [Anima] Ownership Concept
Thread-Index: AQHQZn+Wg9fZJUO6M0OTD8vJ8KxwwZ0rrpGAgAErGoCAAA9fAIAAD5aAgAAMGgCAAAQLAIAAEuYAgAAOmYCAAJX1vQ==
Date: Wed, 25 Mar 2015 22:00:15 +0000
Message-ID: <5D36713D8A4E7348A7E10DF7437A4B925F4C2C8D@NKGEML512-MBS.china.huawei.com>
References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> <5512DE41.6030209@gmail.com> <20150325170646.GB31979@cisco.com> <5512F839.6080502@gmail.com> <20150325184552.GC31979@cisco.com> <551305C4.9030001@gmail.com> <20150325200758.GD31979@cisco.com>, <3C8F19F4-54E7-48E5-AD62-A2300E946C4E@cisco.com>
In-Reply-To: <3C8F19F4-54E7-48E5-AD62-A2300E946C4E@cisco.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.147.148]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Cc: Hannes Tschofenig , Rene Struik , "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, 25 Mar 2015 22:00:28 -0000

Max>I don=92t understand how one can expect the backend to be=20
>totally =93optional=94 since the device doesn=92t know if it should be=20
>optional or not.

One possible deployment scenario: the owner of the network has obtained the=
 certs of devices out-of-band before the device bootstraps. The certs are s=
tored at the registrater locally. Then, we the new devices is plugged in, t=
he registrater can validate it by it self - no need to contact MASA.

Sheng

>
> I just think that devices that do permit to be enrolled/configured
> without MASA or the zerotouch backend equivalent will be intrinsically
> less secure. It does make sense though to permit them to exist, especiall=
y
> for high security envionments where te vendor and customer may have
> a much better lock on the ongoing physical presence of the device and
> what networks it gets connected to.
>
> Cheers
>    Toerless
>
> P.S.: I think all devices other than those owned by DoD and DoE can
> be expected to have connectivity to a backend server in Fort Meade
> including White House and Bundestag ;-)
>
> On Thu, Mar 26, 2015 at 08:00:20AM +1300, Brian E Carpenter wrote:
>> Indeed, I think any kind of call-home is unacceptable in
>> certain high security environments. Would you expect, say,
>> the door lock control system of the White House or the
>> Bundestag to call an external server for a firmware update?
>>
>> Another aspect is disaster recovery. If you have to reboot
>> your network at a time when all Internet access is down
>> (think hurricane or earthquake), you don't want to *require*
>> an external service.
>>
>> "We can't open the elevator doors because the Internet is down."
>>
>> I really think our bootstrap scenarios have to allow for this.
>>
>>    Brian
>>
>> On 26/03/2015 07:45, Toerless Eckert wrote:
>>> Thanks, Brian.
>>>
>>> If i understand it correctly, in the netconf zerotouch approach,
>>> the router to control the meltdown process in the reactor would still
>>> need to receive a file from the outside of the reactor airgap (axctuall=
y
>>> something like a .tar of 4? files). And in result it would have some
>>> bootstrap config, but not a nuclear pant operator certificate.
>>>
>>> True/False ?
>>>
>>> How would that match your requirements - any better/different to
>>> you than MASA ?
>>>
>>> Cheers
>>>    Toerless
>>>
>>> On Thu, Mar 26, 2015 at 07:02:33AM +1300, Brian E Carpenter wrote:
>>>> On 26/03/2015 06:06, Toerless Eckert wrote:
>>>>> Should i be able to find a more detailed reasonining from you about M=
ASA
>>>>> in the mailing list archive ?  if not, would you mind to elaborate he=
re ?
>>>>
>>>> I expect it is somewhere in my comments on draft-pritikin, but basical=
ly
>>>> I think we MUST have a mode that has no external dependencies whatever=
.
>>>> A nuclear plant operator might agree with me, or anyone who wants a se=
cure
>>>> network with an air gap round it.
>>>>
>>>> As long as the MASA is optional, it's fine.
>>>>
>>>>    Brian
>>>>
>>>>>
>>>>> Cheers
>>>>>    Toerless
>>>>>
>>>>> On Thu, Mar 26, 2015 at 05:11:45AM +1300, Brian E Carpenter wrote:
>>>>>> I think it is unanswerable, or at least the answer is YMMV. You may =
remember that
>>>>>> one of my comments on draft-pritikin was basically: I hate the MASA.=
 I was glad
>>>>>> to see the connection to the MASA was clearly indicated as optional =
in the slides
>>>>>> yesterday. The point is that we have no control over this - differen=
t classes
>>>>>> of device and different vendors will have different ideas about this=
. I firmly
>>>>>> believe that any design we do in the IETF has to be very flexible on
>>>>>> this point.
>>>>>>
>>>>>> Regards
>>>>>>   Brian
>>>>>>
>>>>>> On 25/03/2015 11:21, Rene Struik wrote:
>>>>>>> Hi Hannes:
>>>>>>>
>>>>>>> I think supply chain issues, and transgression from one supply chai=
n step to the next, are important in life-cycle
>>>>>>> considerations. This includes how to move from one logical "owner" =
to the next and potentially "cutting the ties" with the
>>>>>>> former. These aspects certainly require more work.
>>>>>>>
>>>>>>> A very simple example of supply chain would be relabelling a device=
 as a "white goods" device (e.g., by selling a branded good
>>>>>>> at a superstore, such as Walmart, under the Walmart brand, whereas =
in reality it outsourced all production (except perhaps
>>>>>>> putting the sticker on top).
>>>>>>>
>>>>>>> Best regards, Rene
>>>>>>>
>>>>>>> On 3/24/2015 6:11 PM, Hannes Tschofenig wrote:
>>>>>>>> There was no time during the meeting today to ask too many questio=
ns
>>>>>>>> (because of lack of time). That's unfortunately and so I have to f=
all
>>>>>>>> back to the mailing list.
>>>>>>>>
>>>>>>>> I wanted to get some better understand what the ownership concept =
is
>>>>>>>> about and what the implications are for the protocol design. The t=
erm
>>>>>>>> came up in various presentations today and it appears to be import=
ant.
>>>>>>>>
>>>>>>>> Many parties are involved in the manufacturing process of products=
 today
>>>>>>>> and the value chain is certainly complex. Hence, who the owner of =
what
>>>>>>>> is and at what point might be difficult to determine.
>>>>>>>>
>>>>>>>> Does it really matter who the owner actually is?
>>>>>>>>
>>>>>>>> Ciao
>>>>>>>> Hannes
>>>
>
> --
> ---
> Toerless Eckert, eckert@cisco.com
>
> _______________________________________________
> 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 Wed Mar 25 16:09: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 24E7D1A8A92 for ; Wed, 25 Mar 2015 16:08:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.911
X-Spam-Level: 
X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_31=0.6, 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 aIxMmq4RWBvP for ; Wed, 25 Mar 2015 16:08:56 -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 B4B3E1A1AB3 for ; Wed, 25 Mar 2015 16:08:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7460; q=dns/txt; s=iport; t=1427324936; x=1428534536; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=v1LAJKysuwMsEJnQ4o72hxz0+sTS3D2WLgTNP0hfN0w=; b=m4H/zf5ZsDeE4W2DfAkHWjaERkCkTlTgLoVvXFxe4mcf34KnS+uC6DVZ Bx+4XuuhefGpbF7CrJEKkpmmCQ6DMqWnms3qDjhf87eK4odme7UuCtFcB sko1BA+IE539bY22gKC765We8hXGmZt6YEOiMJPInB9o4bIxnFFf6nbty E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AQBQC2PhNV/5FdJa1cgwZSWgTFCAqFdQKBW0wBAQEBAQF9hBQBAQEDAQEBAWsLBQsCAQgYLicLJQIEDgUZiA4IDcohAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSKIn+EQzMHgxeBFgWQUIlvgRuKSIFUgy6DRyKCAhyBUG+BBCQcfwEBAQ
X-IronPort-AV: E=Sophos;i="5.11,467,1422921600"; d="scan'208";a="403576887"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-1.cisco.com with ESMTP; 25 Mar 2015 23:08:55 +0000
Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t2PN8tgm032339 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Mar 2015 23:08:55 GMT
Received: from xmb-rcd-x03.cisco.com ([169.254.7.184]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Wed, 25 Mar 2015 18:08:55 -0500
From: "Max Pritikin (pritikin)" 
To: Sheng Jiang 
Thread-Topic: [Anima] Ownership Concept
Thread-Index: AQHQZn+Wm4eAxWuLS02QOiRijuPZe50siH6AgAErG4CAAA9fAIAAD5aAgAAMGgCAAAQLAIAAEuYAgAAOZICAABD7gIAAEvkA
Date: Wed, 25 Mar 2015 23:08:55 +0000
Message-ID: 
References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> <5512DE41.6030209@gmail.com> <20150325170646.GB31979@cisco.com> <5512F839.6080502@gmail.com> <20150325184552.GC31979@cisco.com> <551305C4.9030001@gmail.com> <20150325200758.GD31979@cisco.com>, <3C8F19F4-54E7-48E5-AD62-A2300E946C4E@cisco.com> <5D36713D8A4E7348A7E10DF7437A4B925F4C2C8D@NKGEML512-MBS.china.huawei.com>
In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B925F4C2C8D@NKGEML512-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.233.138]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <8AEC88F35053384DA8BC08DDD0BB16B4@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "Toerless Eckert \(eckert\)" , Hannes Tschofenig , Rene Struik , "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, 25 Mar 2015 23:08:59 -0000

I think Rene=92s point about the underlying security model is a good one. I=
t explains why I disagree with your note below. Refer to my email earlier i=
n this thread where I lay out the attack which must be mitigated: the devic=
e joins Mallory=92s domain and has malware installed on it. =20

On Mar 25, 2015, at 4:00 PM, Sheng Jiang  wrote:

> Max>I don=92t understand how one can expect the backend to be=20
>> totally =93optional=94 since the device doesn=92t know if it should be=20
>> optional or not.
>=20
> One possible deployment scenario: the owner of the network has obtained t=
he certs of devices out-of-band before the device bootstraps. The certs are=
 stored at the registrater locally. Then, we the new devices is plugged in,=
 the registrater can validate it by it self - no need to contact MASA.

In which case Mallory can trivially do this and now has full access to the =
device. Mallory installs malware on the device and, using the malware, join=
s the target network.=20

What I laid out in the prior thread were three possible mitigations. None o=
f them are ideal. Of the choices I=92ve contended that the MASA approach is=
 the least onerous since it minimizes the central cloud service to a simple=
 logging entity.=20

Where the MASA concept is weakest is when an air-gap is anticipated. In suc=
h cases the MASA concept allows for =93nonce-less=94 authorizations that ar=
e long lived. To minimize that one can optionally do full ownership trackin=
g but only if all MASA responders agree to do so =97 which reduces our abil=
ity to deal with =93vendor went out of business but there are 3rd party MAS=
A services=94 use cases.=20

I=92m uncomfortable mitigating this problem by mandating full ownership tra=
cking, as in the netconf proposal, because that is a really hard problem to=
 solve even while I see the value of it.

- max

>=20
> Sheng
>=20
>>=20
>> I just think that devices that do permit to be enrolled/configured
>> without MASA or the zerotouch backend equivalent will be intrinsically
>> less secure. It does make sense though to permit them to exist, especial=
ly
>> for high security envionments where te vendor and customer may have
>> a much better lock on the ongoing physical presence of the device and
>> what networks it gets connected to.
>>=20
>> Cheers
>>   Toerless
>>=20
>> P.S.: I think all devices other than those owned by DoD and DoE can
>> be expected to have connectivity to a backend server in Fort Meade
>> including White House and Bundestag ;-)
>>=20
>> On Thu, Mar 26, 2015 at 08:00:20AM +1300, Brian E Carpenter wrote:
>>> Indeed, I think any kind of call-home is unacceptable in
>>> certain high security environments. Would you expect, say,
>>> the door lock control system of the White House or the
>>> Bundestag to call an external server for a firmware update?
>>>=20
>>> Another aspect is disaster recovery. If you have to reboot
>>> your network at a time when all Internet access is down
>>> (think hurricane or earthquake), you don't want to *require*
>>> an external service.
>>>=20
>>> "We can't open the elevator doors because the Internet is down."
>>>=20
>>> I really think our bootstrap scenarios have to allow for this.
>>>=20
>>>   Brian
>>>=20
>>> On 26/03/2015 07:45, Toerless Eckert wrote:
>>>> Thanks, Brian.
>>>>=20
>>>> If i understand it correctly, in the netconf zerotouch approach,
>>>> the router to control the meltdown process in the reactor would still
>>>> need to receive a file from the outside of the reactor airgap (axctual=
ly
>>>> something like a .tar of 4? files). And in result it would have some
>>>> bootstrap config, but not a nuclear pant operator certificate.
>>>>=20
>>>> True/False ?
>>>>=20
>>>> How would that match your requirements - any better/different to
>>>> you than MASA ?
>>>>=20
>>>> Cheers
>>>>   Toerless
>>>>=20
>>>> On Thu, Mar 26, 2015 at 07:02:33AM +1300, Brian E Carpenter wrote:
>>>>> On 26/03/2015 06:06, Toerless Eckert wrote:
>>>>>> Should i be able to find a more detailed reasonining from you about =
MASA
>>>>>> in the mailing list archive ?  if not, would you mind to elaborate h=
ere ?
>>>>>=20
>>>>> I expect it is somewhere in my comments on draft-pritikin, but basica=
lly
>>>>> I think we MUST have a mode that has no external dependencies whateve=
r.
>>>>> A nuclear plant operator might agree with me, or anyone who wants a s=
ecure
>>>>> network with an air gap round it.
>>>>>=20
>>>>> As long as the MASA is optional, it's fine.
>>>>>=20
>>>>>   Brian
>>>>>=20
>>>>>>=20
>>>>>> Cheers
>>>>>>   Toerless
>>>>>>=20
>>>>>> On Thu, Mar 26, 2015 at 05:11:45AM +1300, Brian E Carpenter wrote:
>>>>>>> I think it is unanswerable, or at least the answer is YMMV. You may=
 remember that
>>>>>>> one of my comments on draft-pritikin was basically: I hate the MASA=
. I was glad
>>>>>>> to see the connection to the MASA was clearly indicated as optional=
 in the slides
>>>>>>> yesterday. The point is that we have no control over this - differe=
nt classes
>>>>>>> of device and different vendors will have different ideas about thi=
s. I firmly
>>>>>>> believe that any design we do in the IETF has to be very flexible o=
n
>>>>>>> this point.
>>>>>>>=20
>>>>>>> Regards
>>>>>>>  Brian
>>>>>>>=20
>>>>>>> On 25/03/2015 11:21, Rene Struik wrote:
>>>>>>>> Hi Hannes:
>>>>>>>>=20
>>>>>>>> I think supply chain issues, and transgression from one supply cha=
in step to the next, are important in life-cycle
>>>>>>>> considerations. This includes how to move from one logical "owner"=
 to the next and potentially "cutting the ties" with the
>>>>>>>> former. These aspects certainly require more work.
>>>>>>>>=20
>>>>>>>> A very simple example of supply chain would be relabelling a devic=
e as a "white goods" device (e.g., by selling a branded good
>>>>>>>> at a superstore, such as Walmart, under the Walmart brand, whereas=
 in reality it outsourced all production (except perhaps
>>>>>>>> putting the sticker on top).
>>>>>>>>=20
>>>>>>>> Best regards, Rene
>>>>>>>>=20
>>>>>>>> On 3/24/2015 6:11 PM, Hannes Tschofenig wrote:
>>>>>>>>> There was no time during the meeting today to ask too many questi=
ons
>>>>>>>>> (because of lack of time). That's unfortunately and so I have to =
fall
>>>>>>>>> back to the mailing list.
>>>>>>>>>=20
>>>>>>>>> I wanted to get some better understand what the ownership concept=
 is
>>>>>>>>> about and what the implications are for the protocol design. The =
term
>>>>>>>>> came up in various presentations today and it appears to be impor=
tant.
>>>>>>>>>=20
>>>>>>>>> Many parties are involved in the manufacturing process of product=
s today
>>>>>>>>> and the value chain is certainly complex. Hence, who the owner of=
 what
>>>>>>>>> is and at what point might be difficult to determine.
>>>>>>>>>=20
>>>>>>>>> Does it really matter who the owner actually is?
>>>>>>>>>=20
>>>>>>>>> Ciao
>>>>>>>>> Hannes
>>>>=20
>>=20
>> --
>> ---
>> Toerless Eckert, eckert@cisco.com
>>=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 Wed Mar 25 16:35:12 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 1C8331B29E8 for ; Wed, 25 Mar 2015 16:35:10 -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_31=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 OcvaDEvTrwjn for ; Wed, 25 Mar 2015 16:35:07 -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 D26581A8898 for ; Wed, 25 Mar 2015 16:35:06 -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 BUD31168; Wed, 25 Mar 2015 23:35:05 +0000 (GMT)
Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 25 Mar 2015 23:35:04 +0000
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.209]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Thu, 26 Mar 2015 07:34:26 +0800
From: Sheng Jiang 
To: "Max Pritikin (pritikin)" 
Thread-Topic: [Anima] Ownership Concept
Thread-Index: AQHQZn+Wg9fZJUO6M0OTD8vJ8KxwwZ0rrpGAgAErGoCAAA9fAIAAD5aAgAAMGgCAAAQLAIAAEuYAgAAOmYCAAJX1vf//jgCAgACJPdA=
Date: Wed, 25 Mar 2015 23:34:25 +0000
Message-ID: <5D36713D8A4E7348A7E10DF7437A4B925F4C3D1A@NKGEML512-MBS.china.huawei.com>
References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> <5512DE41.6030209@gmail.com> <20150325170646.GB31979@cisco.com> <5512F839.6080502@gmail.com> <20150325184552.GC31979@cisco.com> <551305C4.9030001@gmail.com> <20150325200758.GD31979@cisco.com>, <3C8F19F4-54E7-48E5-AD62-A2300E946C4E@cisco.com> <5D36713D8A4E7348A7E10DF7437A4B925F4C2C8D@NKGEML512-MBS.china.huawei.com>, 
In-Reply-To: 
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.157.92]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Cc: "Toerless Eckert \(eckert\)" , Hannes Tschofenig , Rene Struik , "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, 25 Mar 2015 23:35:10 -0000

Hi, Max,

I agree you have desribe a valid attack model there. However, I don't think=
 check with MASA online would solve the prolem. Onless the MASA performs ha=
rdware signature validation, to make sure the hardware has not been modifie=
d since it leaves the manufacture, which I don't think is in the current ve=
rsion of bootstrap. However, even so, hardware signature validation may als=
o be able to be processed on the registrater within the network. So, MASA w=
ould still be optional.

Sheng

________________________________________
From: Max Pritikin (pritikin) [pritikin@cisco.com]
Sent: 26 March 2015 7:08
To: Sheng Jiang
Cc: Toerless Eckert (eckert); Hannes Tschofenig; anima@ietf.org; Rene Strui=
k
Subject: Re: [Anima] Ownership Concept

I think Rene=92s point about the underlying security model is a good one. I=
t explains why I disagree with your note below. Refer to my email earlier i=
n this thread where I lay out the attack which must be mitigated: the devic=
e joins Mallory=92s domain and has malware installed on it.

On Mar 25, 2015, at 4:00 PM, Sheng Jiang  wrote:

> Max>I don=92t understand how one can expect the backend to be
>> totally =93optional=94 since the device doesn=92t know if it should be
>> optional or not.
>
> One possible deployment scenario: the owner of the network has obtained t=
he certs of devices out-of-band before the device bootstraps. The certs are=
 stored at the registrater locally. Then, we the new devices is plugged in,=
 the registrater can validate it by it self - no need to contact MASA.

In which case Mallory can trivially do this and now has full access to the =
device. Mallory installs malware on the device and, using the malware, join=
s the target network.

What I laid out in the prior thread were three possible mitigations. None o=
f them are ideal. Of the choices I=92ve contended that the MASA approach is=
 the least onerous since it minimizes the central cloud service to a simple=
 logging entity.

Where the MASA concept is weakest is when an air-gap is anticipated. In suc=
h cases the MASA concept allows for =93nonce-less=94 authorizations that ar=
e long lived. To minimize that one can optionally do full ownership trackin=
g but only if all MASA responders agree to do so =97 which reduces our abil=
ity to deal with =93vendor went out of business but there are 3rd party MAS=
A services=94 use cases.

I=92m uncomfortable mitigating this problem by mandating full ownership tra=
cking, as in the netconf proposal, because that is a really hard problem to=
 solve even while I see the value of it.

- max

>
> Sheng
>
>>
>> I just think that devices that do permit to be enrolled/configured
>> without MASA or the zerotouch backend equivalent will be intrinsically
>> less secure. It does make sense though to permit them to exist, especial=
ly
>> for high security envionments where te vendor and customer may have
>> a much better lock on the ongoing physical presence of the device and
>> what networks it gets connected to.
>>
>> Cheers
>>   Toerless
>>
>> P.S.: I think all devices other than those owned by DoD and DoE can
>> be expected to have connectivity to a backend server in Fort Meade
>> including White House and Bundestag ;-)
>>
>> On Thu, Mar 26, 2015 at 08:00:20AM +1300, Brian E Carpenter wrote:
>>> Indeed, I think any kind of call-home is unacceptable in
>>> certain high security environments. Would you expect, say,
>>> the door lock control system of the White House or the
>>> Bundestag to call an external server for a firmware update?
>>>
>>> Another aspect is disaster recovery. If you have to reboot
>>> your network at a time when all Internet access is down
>>> (think hurricane or earthquake), you don't want to *require*
>>> an external service.
>>>
>>> "We can't open the elevator doors because the Internet is down."
>>>
>>> I really think our bootstrap scenarios have to allow for this.
>>>
>>>   Brian
>>>
>>> On 26/03/2015 07:45, Toerless Eckert wrote:
>>>> Thanks, Brian.
>>>>
>>>> If i understand it correctly, in the netconf zerotouch approach,
>>>> the router to control the meltdown process in the reactor would still
>>>> need to receive a file from the outside of the reactor airgap (axctual=
ly
>>>> something like a .tar of 4? files). And in result it would have some
>>>> bootstrap config, but not a nuclear pant operator certificate.
>>>>
>>>> True/False ?
>>>>
>>>> How would that match your requirements - any better/different to
>>>> you than MASA ?
>>>>
>>>> Cheers
>>>>   Toerless
>>>>
>>>> On Thu, Mar 26, 2015 at 07:02:33AM +1300, Brian E Carpenter wrote:
>>>>> On 26/03/2015 06:06, Toerless Eckert wrote:
>>>>>> Should i be able to find a more detailed reasonining from you about =
MASA
>>>>>> in the mailing list archive ?  if not, would you mind to elaborate h=
ere ?
>>>>>
>>>>> I expect it is somewhere in my comments on draft-pritikin, but basica=
lly
>>>>> I think we MUST have a mode that has no external dependencies whateve=
r.
>>>>> A nuclear plant operator might agree with me, or anyone who wants a s=
ecure
>>>>> network with an air gap round it.
>>>>>
>>>>> As long as the MASA is optional, it's fine.
>>>>>
>>>>>   Brian
>>>>>
>>>>>>
>>>>>> Cheers
>>>>>>   Toerless
>>>>>>
>>>>>> On Thu, Mar 26, 2015 at 05:11:45AM +1300, Brian E Carpenter wrote:
>>>>>>> I think it is unanswerable, or at least the answer is YMMV. You may=
 remember that
>>>>>>> one of my comments on draft-pritikin was basically: I hate the MASA=
. I was glad
>>>>>>> to see the connection to the MASA was clearly indicated as optional=
 in the slides
>>>>>>> yesterday. The point is that we have no control over this - differe=
nt classes
>>>>>>> of device and different vendors will have different ideas about thi=
s. I firmly
>>>>>>> believe that any design we do in the IETF has to be very flexible o=
n
>>>>>>> this point.
>>>>>>>
>>>>>>> Regards
>>>>>>>  Brian
>>>>>>>
>>>>>>> On 25/03/2015 11:21, Rene Struik wrote:
>>>>>>>> Hi Hannes:
>>>>>>>>
>>>>>>>> I think supply chain issues, and transgression from one supply cha=
in step to the next, are important in life-cycle
>>>>>>>> considerations. This includes how to move from one logical "owner"=
 to the next and potentially "cutting the ties" with the
>>>>>>>> former. These aspects certainly require more work.
>>>>>>>>
>>>>>>>> A very simple example of supply chain would be relabelling a devic=
e as a "white goods" device (e.g., by selling a branded good
>>>>>>>> at a superstore, such as Walmart, under the Walmart brand, whereas=
 in reality it outsourced all production (except perhaps
>>>>>>>> putting the sticker on top).
>>>>>>>>
>>>>>>>> Best regards, Rene
>>>>>>>>
>>>>>>>> On 3/24/2015 6:11 PM, Hannes Tschofenig wrote:
>>>>>>>>> There was no time during the meeting today to ask too many questi=
ons
>>>>>>>>> (because of lack of time). That's unfortunately and so I have to =
fall
>>>>>>>>> back to the mailing list.
>>>>>>>>>
>>>>>>>>> I wanted to get some better understand what the ownership concept=
 is
>>>>>>>>> about and what the implications are for the protocol design. The =
term
>>>>>>>>> came up in various presentations today and it appears to be impor=
tant.
>>>>>>>>>
>>>>>>>>> Many parties are involved in the manufacturing process of product=
s today
>>>>>>>>> and the value chain is certainly complex. Hence, who the owner of=
 what
>>>>>>>>> is and at what point might be difficult to determine.
>>>>>>>>>
>>>>>>>>> Does it really matter who the owner actually is?
>>>>>>>>>
>>>>>>>>> Ciao
>>>>>>>>> Hannes
>>>>
>>
>> --
>> ---
>> Toerless Eckert, eckert@cisco.com
>>
>> _______________________________________________
>> 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 Wed Mar 25 16:49: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 B9C511B2AA0 for ; Wed, 25 Mar 2015 16:49:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.911
X-Spam-Level: 
X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_31=0.6, 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 dcqF9u931fba for ; Wed, 25 Mar 2015 16:49: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 AB4121B2A82 for ; Wed, 25 Mar 2015 16:49:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9908; q=dns/txt; s=iport; t=1427327371; x=1428536971; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=gCvcOqOtNsdowAvJLYZ1DjDZl/7ggpHjYj7CDc4zeNg=; b=a7KWYsu7SACys8ZMiXSUFr60gaJzwiYqMs8afFCyBkLwnQEcWW8xJdgE yze198PEGQw1qeVfInVuct+QX/zFJ9OPQquBpVO3u3yJZSrgPKGrIeTuU I0Wm0EUVTJ0eiOOT+NScEC74HUmQ/Nlm9qmtCuglDR4NTDVr1RpS70XLj U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ARBQAISRNV/5FdJa1cgwNSWgTFCAqFdQKBW0wBAQEBAQF9hBQBAQEDAQEBAWsLBQsCAQgRBAEBAS4nCx0IAgQOBRmIDggNyh4BAQEBAQEBAQEBAQEBAQEBAQEBAQETBIoif4RDMweDF4EWBZBQiW+BG4pIgVSDLoNHIoICHIFQb4EEJBx/AQEB
X-IronPort-AV: E=Sophos;i="5.11,468,1422921600"; d="scan'208";a="135394498"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-1.cisco.com with ESMTP; 25 Mar 2015 23:49:30 +0000
Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t2PNnUYj028179 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Mar 2015 23:49:30 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; Wed, 25 Mar 2015 18:49:30 -0500
From: "Max Pritikin (pritikin)" 
To: Sheng Jiang 
Thread-Topic: [Anima] Ownership Concept
Thread-Index: AQHQZn+Wm4eAxWuLS02QOiRijuPZe50siH6AgAErG4CAAA9fAIAAD5aAgAAMGgCAAAQLAIAAEuYAgAAOZICAABD7gIAAEvkAgAAHVoCAAAQAAA==
Date: Wed, 25 Mar 2015 23:49:29 +0000
Message-ID: <7502156E-DF71-492F-874F-A0053A5EFAC2@cisco.com>
References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> <5512DE41.6030209@gmail.com> <20150325170646.GB31979@cisco.com> <5512F839.6080502@gmail.com> <20150325184552.GC31979@cisco.com> <551305C4.9030001@gmail.com> <20150325200758.GD31979@cisco.com>, <3C8F19F4-54E7-48E5-AD62-A2300E946C4E@cisco.com> <5D36713D8A4E7348A7E10DF7437A4B925F4C2C8D@NKGEML512-MBS.china.huawei.com>,  <5D36713D8A4E7348A7E10DF7437A4B925F4C3D1A@NKGEML512-MBS.china.huawei.com>
In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B925F4C3D1A@NKGEML512-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.233.138]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <8B48D9C9503DB142B6806915D84DFBD9@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "Toerless Eckert \(eckert\)" , Hannes Tschofenig , Rene Struik , "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, 25 Mar 2015 23:49:34 -0000

On Mar 25, 2015, at 5:34 PM, Sheng Jiang  wrote:

> Hi, Max,
>=20
> I agree you have desribe a valid attack model there.

I suspect we=92d agree it is incomplete =97 only focusing on a single impor=
tant threat at the moment. As we proceed we=92ll have to build this out.=20

> However, I don't think check with MASA online would solve the prolem. Onl=
ess the MASA performs hardware signature validation, to make sure the hardw=
are has not been modified since it leaves the manufacture, which I don't th=
ink is in the current version of bootstrap.

The threat being mitigated is a network based attack where Mallory inserts =
itself between the new device and the valid domain. I think =93hardware mod=
ification" assumes Mallory has physical access to the device and I agree th=
at the Trusted Platform Module type mitigation is the path to take for that=
. That is being worked on by other efforts so I think we=92d be ok declarin=
g that out-of-scope in our threat modeling even while I agree we=92ll event=
ually address it. Perhaps the right approach is to admit into the onboardin=
g protocol some alignment with the Network Endpoint Assessment (NEA) work (=
e.g. RFC5209).

> However, even so, hardware signature validation may also be able to be pr=
ocessed on the registrater within the network. So, MASA would still be opti=
onal.

How would we deal with this in standards language? I suppose it would go so=
mething like:
"If the device does not support NEA [RFC7209] integration then it MUST veri=
fy the [MASA "authorization token" or NCONF =93ownership validation=94] oth=
erwise it MAY imprint on an unknown and unvalidated domain=94? Also the reg=
istar/domain would have to know the capabilities/requirements of the device=
 during onboarding so it knows if it needs to contact the cloud.

I think you=92re arguing that all three mitigation techniques, or at least =
two of them, are required? Is that true?

- max



> Sheng
>=20
> ________________________________________
> From: Max Pritikin (pritikin) [pritikin@cisco.com]
> Sent: 26 March 2015 7:08
> To: Sheng Jiang
> Cc: Toerless Eckert (eckert); Hannes Tschofenig; anima@ietf.org; Rene Str=
uik
> Subject: Re: [Anima] Ownership Concept
>=20
> I think Rene=92s point about the underlying security model is a good one.=
 It explains why I disagree with your note below. Refer to my email earlier=
 in this thread where I lay out the attack which must be mitigated: the dev=
ice joins Mallory=92s domain and has malware installed on it.
>=20
> On Mar 25, 2015, at 4:00 PM, Sheng Jiang  wrote:
>=20
>> Max>I don=92t understand how one can expect the backend to be
>>> totally =93optional=94 since the device doesn=92t know if it should be
>>> optional or not.
>>=20
>> One possible deployment scenario: the owner of the network has obtained =
the certs of devices out-of-band before the device bootstraps. The certs ar=
e stored at the registrater locally. Then, we the new devices is plugged in=
, the registrater can validate it by it self - no need to contact MASA.
>=20
> In which case Mallory can trivially do this and now has full access to th=
e device. Mallory installs malware on the device and, using the malware, jo=
ins the target network.
>=20
> What I laid out in the prior thread were three possible mitigations. None=
 of them are ideal. Of the choices I=92ve contended that the MASA approach =
is the least onerous since it minimizes the central cloud service to a simp=
le logging entity.
>=20
> Where the MASA concept is weakest is when an air-gap is anticipated. In s=
uch cases the MASA concept allows for =93nonce-less=94 authorizations that =
are long lived. To minimize that one can optionally do full ownership track=
ing but only if all MASA responders agree to do so =97 which reduces our ab=
ility to deal with =93vendor went out of business but there are 3rd party M=
ASA services=94 use cases.
>=20
> I=92m uncomfortable mitigating this problem by mandating full ownership t=
racking, as in the netconf proposal, because that is a really hard problem =
to solve even while I see the value of it.
>=20
> - max
>=20
>>=20
>> Sheng
>>=20
>>>=20
>>> I just think that devices that do permit to be enrolled/configured
>>> without MASA or the zerotouch backend equivalent will be intrinsically
>>> less secure. It does make sense though to permit them to exist, especia=
lly
>>> for high security envionments where te vendor and customer may have
>>> a much better lock on the ongoing physical presence of the device and
>>> what networks it gets connected to.
>>>=20
>>> Cheers
>>>  Toerless
>>>=20
>>> P.S.: I think all devices other than those owned by DoD and DoE can
>>> be expected to have connectivity to a backend server in Fort Meade
>>> including White House and Bundestag ;-)
>>>=20
>>> On Thu, Mar 26, 2015 at 08:00:20AM +1300, Brian E Carpenter wrote:
>>>> Indeed, I think any kind of call-home is unacceptable in
>>>> certain high security environments. Would you expect, say,
>>>> the door lock control system of the White House or the
>>>> Bundestag to call an external server for a firmware update?
>>>>=20
>>>> Another aspect is disaster recovery. If you have to reboot
>>>> your network at a time when all Internet access is down
>>>> (think hurricane or earthquake), you don't want to *require*
>>>> an external service.
>>>>=20
>>>> "We can't open the elevator doors because the Internet is down."
>>>>=20
>>>> I really think our bootstrap scenarios have to allow for this.
>>>>=20
>>>>  Brian
>>>>=20
>>>> On 26/03/2015 07:45, Toerless Eckert wrote:
>>>>> Thanks, Brian.
>>>>>=20
>>>>> If i understand it correctly, in the netconf zerotouch approach,
>>>>> the router to control the meltdown process in the reactor would still
>>>>> need to receive a file from the outside of the reactor airgap (axctua=
lly
>>>>> something like a .tar of 4? files). And in result it would have some
>>>>> bootstrap config, but not a nuclear pant operator certificate.
>>>>>=20
>>>>> True/False ?
>>>>>=20
>>>>> How would that match your requirements - any better/different to
>>>>> you than MASA ?
>>>>>=20
>>>>> Cheers
>>>>>  Toerless
>>>>>=20
>>>>> On Thu, Mar 26, 2015 at 07:02:33AM +1300, Brian E Carpenter wrote:
>>>>>> On 26/03/2015 06:06, Toerless Eckert wrote:
>>>>>>> Should i be able to find a more detailed reasonining from you about=
 MASA
>>>>>>> in the mailing list archive ?  if not, would you mind to elaborate =
here ?
>>>>>>=20
>>>>>> I expect it is somewhere in my comments on draft-pritikin, but basic=
ally
>>>>>> I think we MUST have a mode that has no external dependencies whatev=
er.
>>>>>> A nuclear plant operator might agree with me, or anyone who wants a =
secure
>>>>>> network with an air gap round it.
>>>>>>=20
>>>>>> As long as the MASA is optional, it's fine.
>>>>>>=20
>>>>>>  Brian
>>>>>>=20
>>>>>>>=20
>>>>>>> Cheers
>>>>>>>  Toerless
>>>>>>>=20
>>>>>>> On Thu, Mar 26, 2015 at 05:11:45AM +1300, Brian E Carpenter wrote:
>>>>>>>> I think it is unanswerable, or at least the answer is YMMV. You ma=
y remember that
>>>>>>>> one of my comments on draft-pritikin was basically: I hate the MAS=
A. I was glad
>>>>>>>> to see the connection to the MASA was clearly indicated as optiona=
l in the slides
>>>>>>>> yesterday. The point is that we have no control over this - differ=
ent classes
>>>>>>>> of device and different vendors will have different ideas about th=
is. I firmly
>>>>>>>> believe that any design we do in the IETF has to be very flexible =
on
>>>>>>>> this point.
>>>>>>>>=20
>>>>>>>> Regards
>>>>>>>> Brian
>>>>>>>>=20
>>>>>>>> On 25/03/2015 11:21, Rene Struik wrote:
>>>>>>>>> Hi Hannes:
>>>>>>>>>=20
>>>>>>>>> I think supply chain issues, and transgression from one supply ch=
ain step to the next, are important in life-cycle
>>>>>>>>> considerations. This includes how to move from one logical "owner=
" to the next and potentially "cutting the ties" with the
>>>>>>>>> former. These aspects certainly require more work.
>>>>>>>>>=20
>>>>>>>>> A very simple example of supply chain would be relabelling a devi=
ce as a "white goods" device (e.g., by selling a branded good
>>>>>>>>> at a superstore, such as Walmart, under the Walmart brand, wherea=
s in reality it outsourced all production (except perhaps
>>>>>>>>> putting the sticker on top).
>>>>>>>>>=20
>>>>>>>>> Best regards, Rene
>>>>>>>>>=20
>>>>>>>>> On 3/24/2015 6:11 PM, Hannes Tschofenig wrote:
>>>>>>>>>> There was no time during the meeting today to ask too many quest=
ions
>>>>>>>>>> (because of lack of time). That's unfortunately and so I have to=
 fall
>>>>>>>>>> back to the mailing list.
>>>>>>>>>>=20
>>>>>>>>>> I wanted to get some better understand what the ownership concep=
t is
>>>>>>>>>> about and what the implications are for the protocol design. The=
 term
>>>>>>>>>> came up in various presentations today and it appears to be impo=
rtant.
>>>>>>>>>>=20
>>>>>>>>>> Many parties are involved in the manufacturing process of produc=
ts today
>>>>>>>>>> and the value chain is certainly complex. Hence, who the owner o=
f what
>>>>>>>>>> is and at what point might be difficult to determine.
>>>>>>>>>>=20
>>>>>>>>>> Does it really matter who the owner actually is?
>>>>>>>>>>=20
>>>>>>>>>> Ciao
>>>>>>>>>> Hannes
>>>>>=20
>>>=20
>>> --
>>> ---
>>> Toerless Eckert, eckert@cisco.com
>>>=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 Wed Mar 25 16:55: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 613921A8892 for ; Wed, 25 Mar 2015 16:55:07 -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 HcXs9BXJWwcn for ; Wed, 25 Mar 2015 16:55:06 -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 D88331A0030 for ; Wed, 25 Mar 2015 16:55:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2279; q=dns/txt; s=iport; t=1427327706; x=1428537306; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=YIo3PnNCEYbGz7XdjtX9e9RDNREz3M5Jg/dZVm7hW6A=; b=ayDcfgjiK8qAL6ZJi5ix6KIZiyCUyJb+WEYJTQ5WjMGBHDk9Z3iP4OQI M5m5faz6fQeehTHz+oUyMop60iBfRFoT4hB+HEUbk5c5gZ3tXh0isCE0G iapdRKtHbaJNsNV6Ug3GQ6UfXKxOQT6o/d8f5VLfAfgoxXAo9uIHdSk51 E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AQBQCBSRNV/4YNJK1cgwNSWgTFCAqFdQKBW0wBAQEBAQF9hBQBAQEDAQEBAWsLBQsCAQgYLiEGCyUCBA4FG4gAAwkIDcRMDYVFAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLIYJHgXwzB4MXgRYFkFCIIoFNjgOGKSKDbm8BgUN/AQEB
X-IronPort-AV: E=Sophos;i="5.11,468,1422921600"; d="scan'208";a="406660401"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-7.cisco.com with ESMTP; 25 Mar 2015 23:55:05 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t2PNt5RH018420 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Mar 2015 23:55:05 GMT
Received: from xmb-rcd-x03.cisco.com ([169.254.7.184]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.03.0195.001; Wed, 25 Mar 2015 18:55:04 -0500
From: "Max Pritikin (pritikin)" 
To: Brian E Carpenter 
Thread-Topic: [Anima] interface towards vendors
Thread-Index: AQHQZn8XByVZKZPnh0+WInbbFaB6mJ0tt0+AgAB9iIA=
Date: Wed, 25 Mar 2015 23:55:03 +0000
Message-ID: <16CEC515-094C-4192-BE96-A96368F72CC3@cisco.com>
References:  <5512E15D.4050508@gmail.com>
In-Reply-To: <5512E15D.4050508@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.24.233.138]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <28D239F08EC84C42AA873692B6C315FD@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "anima@ietf.org" , Mikael Abrahamsson 
Subject: Re: [Anima] interface towards vendors
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, 25 Mar 2015 23:55:07 -0000

On Mar 25, 2015, at 10:25 AM, Brian E Carpenter  wrote:

> On 25/03/2015 11:08, Mikael Abrahamsson wrote:
>>=20
>> Hi,
>>=20
>> With my operator hat on, I just want to say that I do not want a lot of =
different ways of interacting with vendors to get
>> credentials or anything else from the vendor regarding the devices we ha=
ve purchased from them. I do not want separate protocols
>> or mechanisms, and preferrably not different credetials either.
>>=20
>> So whatever happens with the protocols speaking to IoT devices, admissio=
n control to Autonomic Networks, and to
>> Netconf-call-home, we need to make sure the "backend systems" are the sa=
me. I think this was implied in the presentation about
>> draft-he-6lo-analysis-iot-sbootstrapping, but I just want to say that I =
am of this opinion as well.
>>=20
>> Can we do achieve this?
>=20
> Shout at Thread, first, to tell them not to work in secret.
>=20
> More generally, I am very worried about this. We cannot force
> the industry to adopt a single solution. If someone can define
> a common registrar model, which I guess is what you mean by
> a common back end, that would be fine. I am a bit pessimistic.
>=20
> To the extent that we can factor this out of the anima protocols as
> such, we should do so. In my walkthrough I had Discover("trust relay").
> I suspect that the response to that will have to include a list of
> supported methods. The alternative would be for a node that supports,
> for example, draft-pritikin would say Discover("draft-pritikin-relay")
> and so on for the other methods.

Or it discovers one relay and then reports (somehow, somehow securely) whic=
h methods it accepts for onboarding?

Something like, the device indicates which of these options are supported:
	a) prove you own me (required: vendors to track this plus vendor cloud ser=
vice)
	b) i=92ll prove i=92m not corrupted (required: NEA hardware)
	c) prove this event is logged (required: vendor neutral cloud service)
And the =93trust relay=94 reacts accordingly?

- max

>=20
>    Brian
>=20
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima


From nobody Wed Mar 25 19:56: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 4A9891A6FEC for ; Wed, 25 Mar 2015 19:55:59 -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_31=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 lDuvWE72fhzw for ; Wed, 25 Mar 2015 19:55:56 -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 A22101A6F5D for ; Wed, 25 Mar 2015 19:55: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 BUD40825; Thu, 26 Mar 2015 02:55:53 +0000 (GMT)
Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 26 Mar 2015 02:55:52 +0000
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.209]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Thu, 26 Mar 2015 10:55:48 +0800
From: Sheng Jiang 
To: "Max Pritikin (pritikin)" 
Thread-Topic: [Anima] Ownership Concept
Thread-Index: AQHQZn+Wg9fZJUO6M0OTD8vJ8KxwwZ0rrpGAgAErGoCAAA9fAIAAD5aAgAAMGgCAAAQLAIAAEuYAgAAOmYCAAJX1vf//jgCAgACJPdD//4IZgIAAtj1T
Date: Thu, 26 Mar 2015 02:55:48 +0000
Message-ID: <5D36713D8A4E7348A7E10DF7437A4B925F4C3DBA@NKGEML512-MBS.china.huawei.com>
References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> <5512DE41.6030209@gmail.com> <20150325170646.GB31979@cisco.com> <5512F839.6080502@gmail.com> <20150325184552.GC31979@cisco.com> <551305C4.9030001@gmail.com> <20150325200758.GD31979@cisco.com>, <3C8F19F4-54E7-48E5-AD62-A2300E946C4E@cisco.com> <5D36713D8A4E7348A7E10DF7437A4B925F4C2C8D@NKGEML512-MBS.china.huawei.com>,  <5D36713D8A4E7348A7E10DF7437A4B925F4C3D1A@NKGEML512-MBS.china.huawei.com>, <7502156E-DF71-492F-874F-A0053A5EFAC2@cisco.com>
In-Reply-To: <7502156E-DF71-492F-874F-A0053A5EFAC2@cisco.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.147.135]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Cc: "Toerless Eckert \(eckert\)" , Hannes Tschofenig , Rene Struik , "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, 26 Mar 2015 02:55:59 -0000

Max>I think you=92re arguing that all three mitigation techniques,=20
>or at least two of them, are required? Is that true?

No. I did not argue on any certain mitigation techniques. My argument is th=
e necessity of online checking with MASA. I don't think there is technical =
requirements that you could not do on the registrater locally, although it =
may require some pre-configuration or out-of-band setup.

Evenmore, the owner of the network should have the right to trust devices w=
ith Trust-on-first-use (TOFU) policy.

Sheng

> Sheng
>
> ________________________________________
> From: Max Pritikin (pritikin) [pritikin@cisco.com]
> Sent: 26 March 2015 7:08
> To: Sheng Jiang
> Cc: Toerless Eckert (eckert); Hannes Tschofenig; anima@ietf.org; Rene Str=
uik
> Subject: Re: [Anima] Ownership Concept
>
> I think Rene=92s point about the underlying security model is a good one.=
 It explains why I disagree with your note below. Refer to my email earlier=
 in this thread where I lay out the attack which must be mitigated: the dev=
ice joins Mallory=92s domain and has malware installed on it.
>
> On Mar 25, 2015, at 4:00 PM, Sheng Jiang  wrote:
>
>> Max>I don=92t understand how one can expect the backend to be
>>> totally =93optional=94 since the device doesn=92t know if it should be
>>> optional or not.
>>
>> One possible deployment scenario: the owner of the network has obtained =
the certs of devices out-of-band before the device bootstraps. The certs ar=
e stored at the registrater locally. Then, we the new devices is plugged in=
, the registrater can validate it by it self - no need to contact MASA.
>
> In which case Mallory can trivially do this and now has full access to th=
e device. Mallory installs malware on the device and, using the malware, jo=
ins the target network.
>
> What I laid out in the prior thread were three possible mitigations. None=
 of them are ideal. Of the choices I=92ve contended that the MASA approach =
is the least onerous since it minimizes the central cloud service to a simp=
le logging entity.
>
> Where the MASA concept is weakest is when an air-gap is anticipated. In s=
uch cases the MASA concept allows for =93nonce-less=94 authorizations that =
are long lived. To minimize that one can optionally do full ownership track=
ing but only if all MASA responders agree to do so =97 which reduces our ab=
ility to deal with =93vendor went out of business but there are 3rd party M=
ASA services=94 use cases.
>
> I=92m uncomfortable mitigating this problem by mandating full ownership t=
racking, as in the netconf proposal, because that is a really hard problem =
to solve even while I see the value of it.
>
> - max
>
>>
>> Sheng
>>
>>>
>>> I just think that devices that do permit to be enrolled/configured
>>> without MASA or the zerotouch backend equivalent will be intrinsically
>>> less secure. It does make sense though to permit them to exist, especia=
lly
>>> for high security envionments where te vendor and customer may have
>>> a much better lock on the ongoing physical presence of the device and
>>> what networks it gets connected to.
>>>
>>> Cheers
>>>  Toerless
>>>
>>> P.S.: I think all devices other than those owned by DoD and DoE can
>>> be expected to have connectivity to a backend server in Fort Meade
>>> including White House and Bundestag ;-)
>>>
>>> On Thu, Mar 26, 2015 at 08:00:20AM +1300, Brian E Carpenter wrote:
>>>> Indeed, I think any kind of call-home is unacceptable in
>>>> certain high security environments. Would you expect, say,
>>>> the door lock control system of the White House or the
>>>> Bundestag to call an external server for a firmware update?
>>>>
>>>> Another aspect is disaster recovery. If you have to reboot
>>>> your network at a time when all Internet access is down
>>>> (think hurricane or earthquake), you don't want to *require*
>>>> an external service.
>>>>
>>>> "We can't open the elevator doors because the Internet is down."
>>>>
>>>> I really think our bootstrap scenarios have to allow for this.
>>>>
>>>>  Brian
>>>>
>>>> On 26/03/2015 07:45, Toerless Eckert wrote:
>>>>> Thanks, Brian.
>>>>>
>>>>> If i understand it correctly, in the netconf zerotouch approach,
>>>>> the router to control the meltdown process in the reactor would still
>>>>> need to receive a file from the outside of the reactor airgap (axctua=
lly
>>>>> something like a .tar of 4? files). And in result it would have some
>>>>> bootstrap config, but not a nuclear pant operator certificate.
>>>>>
>>>>> True/False ?
>>>>>
>>>>> How would that match your requirements - any better/different to
>>>>> you than MASA ?
>>>>>
>>>>> Cheers
>>>>>  Toerless
>>>>>
>>>>> On Thu, Mar 26, 2015 at 07:02:33AM +1300, Brian E Carpenter wrote:
>>>>>> On 26/03/2015 06:06, Toerless Eckert wrote:
>>>>>>> Should i be able to find a more detailed reasonining from you about=
 MASA
>>>>>>> in the mailing list archive ?  if not, would you mind to elaborate =
here ?
>>>>>>
>>>>>> I expect it is somewhere in my comments on draft-pritikin, but basic=
ally
>>>>>> I think we MUST have a mode that has no external dependencies whatev=
er.
>>>>>> A nuclear plant operator might agree with me, or anyone who wants a =
secure
>>>>>> network with an air gap round it.
>>>>>>
>>>>>> As long as the MASA is optional, it's fine.
>>>>>>
>>>>>>  Brian
>>>>>>
>>>>>>>
>>>>>>> Cheers
>>>>>>>  Toerless
>>>>>>>
>>>>>>> On Thu, Mar 26, 2015 at 05:11:45AM +1300, Brian E Carpenter wrote:
>>>>>>>> I think it is unanswerable, or at least the answer is YMMV. You ma=
y remember that
>>>>>>>> one of my comments on draft-pritikin was basically: I hate the MAS=
A. I was glad
>>>>>>>> to see the connection to the MASA was clearly indicated as optiona=
l in the slides
>>>>>>>> yesterday. The point is that we have no control over this - differ=
ent classes
>>>>>>>> of device and different vendors will have different ideas about th=
is. I firmly
>>>>>>>> believe that any design we do in the IETF has to be very flexible =
on
>>>>>>>> this point.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Brian
>>>>>>>>
>>>>>>>> On 25/03/2015 11:21, Rene Struik wrote:
>>>>>>>>> Hi Hannes:
>>>>>>>>>
>>>>>>>>> I think supply chain issues, and transgression from one supply ch=
ain step to the next, are important in life-cycle
>>>>>>>>> considerations. This includes how to move from one logical "owner=
" to the next and potentially "cutting the ties" with the
>>>>>>>>> former. These aspects certainly require more work.
>>>>>>>>>
>>>>>>>>> A very simple example of supply chain would be relabelling a devi=
ce as a "white goods" device (e.g., by selling a branded good
>>>>>>>>> at a superstore, such as Walmart, under the Walmart brand, wherea=
s in reality it outsourced all production (except perhaps
>>>>>>>>> putting the sticker on top).
>>>>>>>>>
>>>>>>>>> Best regards, Rene
>>>>>>>>>
>>>>>>>>> On 3/24/2015 6:11 PM, Hannes Tschofenig wrote:
>>>>>>>>>> There was no time during the meeting today to ask too many quest=
ions
>>>>>>>>>> (because of lack of time). That's unfortunately and so I have to=
 fall
>>>>>>>>>> back to the mailing list.
>>>>>>>>>>
>>>>>>>>>> I wanted to get some better understand what the ownership concep=
t is
>>>>>>>>>> about and what the implications are for the protocol design. The=
 term
>>>>>>>>>> came up in various presentations today and it appears to be impo=
rtant.
>>>>>>>>>>
>>>>>>>>>> Many parties are involved in the manufacturing process of produc=
ts today
>>>>>>>>>> and the value chain is certainly complex. Hence, who the owner o=
f what
>>>>>>>>>> is and at what point might be difficult to determine.
>>>>>>>>>>
>>>>>>>>>> Does it really matter who the owner actually is?
>>>>>>>>>>
>>>>>>>>>> Ciao
>>>>>>>>>> Hannes
>>>>>
>>>
>>> --
>>> ---
>>> Toerless Eckert, eckert@cisco.com
>>>
>>> _______________________________________________
>>> 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 Wed Mar 25 22:16: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 44A1B1ACD3E for ; Wed, 25 Mar 2015 22:16:55 -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 3pSwUzV5HiFM for ; Wed, 25 Mar 2015 22:16:53 -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 C9BE21ACD3B for ; Wed, 25 Mar 2015 22:16:52 -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 BUD49591; Thu, 26 Mar 2015 05:16:51 +0000 (GMT)
Received: from SZXEML431-HUB.china.huawei.com (10.82.67.208) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 26 Mar 2015 05:16:21 +0000
Received: from szxeml557-mbs.china.huawei.com ([169.254.6.131]) by szxeml431-hub.china.huawei.com ([10.82.67.208]) with mapi id 14.03.0158.001; Thu, 26 Mar 2015 13:16:13 +0800
From: "Hedanping (Ana)" 
To: "Max Pritikin (pritikin)" , Brian E Carpenter 
Thread-Topic: [Anima] interface towards vendors
Thread-Index: AQHQZn8X5HeH1nBtQEWdii7d37+EF50s3WGAgAB9vYCAANi0oA==
Date: Thu, 26 Mar 2015 05:16:13 +0000
Message-ID: <77FA386512F0D748BC7C02C36EB1106D956D21@szxeml557-mbs.china.huawei.com>
References:  <5512E15D.4050508@gmail.com> <16CEC515-094C-4192-BE96-A96368F72CC3@cisco.com>
In-Reply-To: <16CEC515-094C-4192-BE96-A96368F72CC3@cisco.com>
Accept-Language: en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.155.88]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Cc: "anima@ietf.org" , Mikael Abrahamsson 
Subject: Re: [Anima] interface towards vendors
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, 26 Mar 2015 05:16:55 -0000

Hi Max,
  > -----Original Message-----
  > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Max Pritikin
  > (pritikin)
  > Sent: Thursday, March 26, 2015 7:55 AM
  > To: Brian E Carpenter
  > Cc: anima@ietf.org; Mikael Abrahamsson
  > Subject: Re: [Anima] interface towards vendors
  >=20
 =20
  > Something like, the device indicates which of these options are support=
ed:
  > 	a) prove you own me (required: vendors to track this plus vendor cloud
  > service)

It is ownership issue, and I believe it belongs to higher level security ra=
ther than devices securely joins the network.

  > 	b) i'll prove i'm not corrupted (required: NEA hardware)

How about firmware signature by vendor?
  > 	c) prove this event is logged (required: vendor neutral cloud service)=
 And
  > the "trust relay" reacts accordingly?

Why should the device care about this information?

Besides, why is the domain concept needed if any one of the above mentioned=
 options are supported?

Regards,
Ana
  >=20
  > - max
  >=20
  > >
  > >    Brian
  > >
  > > _______________________________________________
  > > 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 Wed Mar 25 22:48: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 7CC5C1B2A57 for ; Wed, 25 Mar 2015 22:48: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 71KJyaHaQ1t1 for ; Wed, 25 Mar 2015 22:48:53 -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 5CC531ACDA4 for ; Wed, 25 Mar 2015 22:48:52 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUD51596; Thu, 26 Mar 2015 05:48:50 +0000 (GMT)
Received: from SZXEML433-HUB.china.huawei.com (10.82.67.210) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 26 Mar 2015 05:48:49 +0000
Received: from szxeml557-mbs.china.huawei.com ([169.254.6.131]) by szxeml433-hub.china.huawei.com ([10.82.67.210]) with mapi id 14.03.0158.001; Thu, 26 Mar 2015 13:48:42 +0800
From: "Hedanping (Ana)" 
To: Brian E Carpenter , Rene Struik 
Thread-Topic: [Anima] Ownership Concept
Thread-Index: AQHQZn+XTQng45mwMk+HZqqnogMqdJ0rrpGAgAErGoCAAWoPYA==
Date: Thu, 26 Mar 2015 05:48:41 +0000
Message-ID: <77FA386512F0D748BC7C02C36EB1106D956D45@szxeml557-mbs.china.huawei.com>
References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> <5512DE41.6030209@gmail.com>
In-Reply-To: <5512DE41.6030209@gmail.com>
Accept-Language: en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.155.88]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Cc: Hannes Tschofenig , "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, 26 Mar 2015 05:48:54 -0000

I agree that ownership is important in life-cycle consideration, but I beli=
eve it belongs to higher security level that impacts the interaction or man=
ipulation between NEs or between NEs and owner.

  > -----Original Message-----
  > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E
  > Carpenter
  > Sent: Thursday, March 26, 2015 12:12 AM
  > To: Rene Struik
  > Cc: Hannes Tschofenig; anima@ietf.org
  > Subject: Re: [Anima] Ownership Concept
  >=20
  > I think it is unanswerable, or at least the answer is YMMV. You may
  > remember that one of my comments on draft-pritikin was basically: I hat=
e
  > the MASA. I was glad to see the connection to the MASA was clearly
  > indicated as optional in the slides yesterday. The point is that we hav=
e no
  > control over this - different classes of device and different vendors w=
ill have
  > different ideas about this. I firmly believe that any design we do in t=
he IETF
  > has to be very flexible on this point.
  >=20
  > Regards
  >    Brian
  >=20
  > On 25/03/2015 11:21, Rene Struik wrote:
  > > Hi Hannes:
  > >
  > > I think supply chain issues, and transgression from one supply chain
  > > step to the next, are important in life-cycle considerations. This
  > > includes how to move from one logical "owner" to the next and potenti=
ally
  > "cutting the ties" with the former. These aspects certainly require mor=
e
  > work.
  > >
  > > A very simple example of supply chain would be relabelling a device a=
s
  > > a "white goods" device (e.g., by selling a branded good at a
  > > superstore, such as Walmart, under the Walmart brand, whereas in real=
ity
  > it outsourced all production (except perhaps putting the sticker on top=
).
  > >
  > > Best regards, Rene
  > >
  > > On 3/24/2015 6:11 PM, Hannes Tschofenig wrote:
  > >> There was no time during the meeting today to ask too many questions
  > >> (because of lack of time). That's unfortunately and so I have to fal=
l
  > >> back to the mailing list.
  > >>
  > >> I wanted to get some better understand what the ownership concept is
  > >> about and what the implications are for the protocol design. The ter=
m
  > >> came up in various presentations today and it appears to be importan=
t.
  > >>
  > >> Many parties are involved in the manufacturing process of products
  > >> today and the value chain is certainly complex. Hence, who the owner
  > >> of what is and at what point might be difficult to determine.
  > >>
  > >> Does it really matter who the owner actually is?
  > >>
  > >> Ciao
  > >> Hannes
  > >>
  > >>
  > >>
  > >> _______________________________________________
  > >> 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
  > >
  >=20
  > _______________________________________________
  > Anima mailing list
  > Anima@ietf.org
  > https://www.ietf.org/mailman/listinfo/anima


From nobody Thu Mar 26 05:15: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 A143E1B2CCA for ; Thu, 26 Mar 2015 05:15: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 4r3bHXJ_ZGYO for ; Thu, 26 Mar 2015 05:15:25 -0700 (PDT)
Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::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 B0D4F1B2CB6 for ; Thu, 26 Mar 2015 05:15:24 -0700 (PDT)
Received: by wibg7 with SMTP id g7so15086259wib.1 for ; Thu, 26 Mar 2015 05:15:23 -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=p5bKoh0gIrcoNNPb4LNRhh81ykKomFpJr1Lpdmd/SgU=; b=aQQkPHNnJhFQrqVn+CzpBt/i8MBdOWhz54dGsL2Tibu2BHY9WSZLs1yp5Q5KVpzsjZ xNMLqQE4zDxhNVNK3wukEkLqhGX2k2NPEHy6yhlmowDl/WkXsbgsz1aktEvTd+1fzhsK H7yqnNe51JPHUvGLmU9yMCAoihAAJ/RldZZQNXY4BZgoXkYCnvds/r5e1qd8y6Ew6Ee3 jHppRuSGZ4zRhw/yFgmdFtDRkpGIBfDpyTpQ7IyyrJAHybXTBCkmFw4SwPCGYpAfjX2i a1nS7w1vJ2f/bVRkbjNMWkeBE0N4GkvyoMiDIVodvwI6vLBiwuby2hCL/nPXn9oD2ZQ9 XtdQ==
X-Received: by 10.180.109.169 with SMTP id ht9mr10170290wib.86.1427372123523;  Thu, 26 Mar 2015 05:15:23 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:136:28cc:dc4c:9703:6781? ([2001:67c:370:136:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id q10sm8117857wjr.41.2015.03.26.05.15.21 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Mar 2015 05:15:22 -0700 (PDT)
Message-ID: <5513F864.1090308@gmail.com>
Date: Fri, 27 Mar 2015 01:15:32 +1300
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.5.0
MIME-Version: 1.0
To: "Hedanping (Ana)" ,  "Max Pritikin (pritikin)" 
References:  <5512E15D.4050508@gmail.com> <16CEC515-094C-4192-BE96-A96368F72CC3@cisco.com> <77FA386512F0D748BC7C02C36EB1106D956D21@szxeml557-mbs.china.huawei.com>
In-Reply-To: <77FA386512F0D748BC7C02C36EB1106D956D21@szxeml557-mbs.china.huawei.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "anima@ietf.org" , Mikael Abrahamsson 
Subject: Re: [Anima] interface towards vendors
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, 26 Mar 2015 12:15:26 -0000

Hi Ana,
On 26/03/2015 18:16, Hedanping (Ana) wrote:
> Hi Max,
>   > -----Original Message-----
>   > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Max Pritikin
>   > (pritikin)
>   > Sent: Thursday, March 26, 2015 7:55 AM
>   > To: Brian E Carpenter
>   > Cc: anima@ietf.org; Mikael Abrahamsson
>   > Subject: Re: [Anima] interface towards vendors
>   > 
>   
>   > Something like, the device indicates which of these options are supported:
>   > 	a) prove you own me (required: vendors to track this plus vendor cloud
>   > service)
> 
> It is ownership issue, and I believe it belongs to higher level security rather than devices securely joins the network.
> 
>   > 	b) i'll prove i'm not corrupted (required: NEA hardware)
> 
> How about firmware signature by vendor?
>   > 	c) prove this event is logged (required: vendor neutral cloud service) And
>   > the "trust relay" reacts accordingly?
> 
> Why should the device care about this information?
> 
> Besides, why is the domain concept needed if any one of the above mentioned options are supported?

The set of devices permitted to perform autonomic configuration in
a network must be limited to devices within the network, and also they
must be able to verify that peer autonomic nodes are also in the same
network. The Device ID and Domain ID both need to be cryptographically
authenticated for this. That's why we need registration *within*
the domain. Actually that is much more important for Anima that
ownership.

    Brian

> 
> Regards,
> Ana
>   > 
>   > - max
>   > 
>   > >
>   > >    Brian
>   > >
>   > > _______________________________________________
>   > > 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 Mar 26 07:55: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 720221AD071 for ; Thu, 26 Mar 2015 07:55: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 jkcHMNz_NLPn for ; Thu, 26 Mar 2015 07:55:36 -0700 (PDT)
Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::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 E1F261A038A for ; Thu, 26 Mar 2015 07:53:31 -0700 (PDT)
Received: by wgdm6 with SMTP id m6so67272764wgd.2 for ; Thu, 26 Mar 2015 07:53:30 -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=AyyTg6tFB/WY6FwtBTE8LZcQNomEOcYYSJkgz0TL+Ig=; b=Yag4peaqmf6h011iQJEBlDrWSla52BNk0lReCz/tErhcdz0efNfONudpKsAJ+rLYfI z0ygtNPhxHphRUqM9l+6Fh9e5Vqkmx8Lk6gKYjd0QaHZSYYABrXi1T50oDBUAxRxwnHN PItI47rtQtujOeOcKzP0JW/0C1x8gLlCBY0n7tn/3CSh6iHsGBms+rsQg8z7hBpAUh1m IU/lKP4I0R5Nc+Lo/xOXSFSMoVPDWI49/Me6Nwce0G2pu0XDoGYHkNiT3GBoNDKemajr gIW897bDPa1bvszT+/svF7+PwNRGGNNkeRciubmcQ4RxQqhtX/Zu8OW/ldLQVF7qg8MW SKfw==
X-Received: by 10.180.187.67 with SMTP id fq3mr25709623wic.59.1427381610636; Thu, 26 Mar 2015 07:53:30 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:176:28cc:dc4c:9703:6781? ([2001:67c:370:176:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id at4sm8742875wjc.16.2015.03.26.07.53.29 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Mar 2015 07:53:30 -0700 (PDT)
Message-ID: <55141D73.2010008@gmail.com>
Date: Fri, 27 Mar 2015 03:53:39 +1300
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.5.0
MIME-Version: 1.0
To: "Max Pritikin (pritikin)" 
References:  <5512E15D.4050508@gmail.com> <16CEC515-094C-4192-BE96-A96368F72CC3@cisco.com>
In-Reply-To: <16CEC515-094C-4192-BE96-A96368F72CC3@cisco.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: "anima@ietf.org" , Mikael Abrahamsson 
Subject: Re: [Anima] interface towards vendors
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, 26 Mar 2015 14:55:42 -0000

On 26/03/2015 12:55, Max Pritikin (pritikin) wrote:
>=20
>=20
> On Mar 25, 2015, at 10:25 AM, Brian E Carpenter  wrote:
>=20
>> On 25/03/2015 11:08, Mikael Abrahamsson wrote:
>>>
>>> Hi,
>>>
>>> With my operator hat on, I just want to say that I do not want a lot =
of different ways of interacting with vendors to get
>>> credentials or anything else from the vendor regarding the devices we=
 have purchased from them. I do not want separate protocols
>>> or mechanisms, and preferrably not different credetials either.
>>>
>>> So whatever happens with the protocols speaking to IoT devices, admis=
sion control to Autonomic Networks, and to
>>> Netconf-call-home, we need to make sure the "backend systems" are the=
 same. I think this was implied in the presentation about
>>> draft-he-6lo-analysis-iot-sbootstrapping, but I just want to say that=
 I am of this opinion as well.
>>>
>>> Can we do achieve this?
>>
>> Shout at Thread, first, to tell them not to work in secret.
>>
>> More generally, I am very worried about this. We cannot force
>> the industry to adopt a single solution. If someone can define
>> a common registrar model, which I guess is what you mean by
>> a common back end, that would be fine. I am a bit pessimistic.
>>
>> To the extent that we can factor this out of the anima protocols as
>> such, we should do so. In my walkthrough I had Discover("trust relay")=
=2E
>> I suspect that the response to that will have to include a list of
>> supported methods. The alternative would be for a node that supports,
>> for example, draft-pritikin would say Discover("draft-pritikin-relay")=

>> and so on for the other methods.
>=20
> Or it discovers one relay and then reports (somehow, somehow securely) =
which methods it accepts for onboarding?

I don't see how that can be done securely, since at that moment nobody
can trust the new device at all.

For the rest I agree with Max.

   Brian

>=20
> Something like, the device indicates which of these options are support=
ed:
> 	a) prove you own me (required: vendors to track this plus vendor cloud=
 service)
> 	b) i=E2=80=99ll prove i=E2=80=99m not corrupted (required: NEA hardwar=
e)
> 	c) prove this event is logged (required: vendor neutral cloud service)=

> And the =E2=80=9Ctrust relay=E2=80=9D reacts accordingly?
>=20
> - max
>=20
>>
>>    Brian
>>
>> _______________________________________________
>> Anima mailing list
>> Anima@ietf.org
>> https://www.ietf.org/mailman/listinfo/anima
>=20
>=20


From nobody Thu Mar 26 08:12: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 27E011A01FA for ; Thu, 26 Mar 2015 08:12: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 14PnUZ8Wp8Kz for ; Thu, 26 Mar 2015 08:12: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 5ECD51A7030 for ; Thu, 26 Mar 2015 08:11:51 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUE12260; Thu, 26 Mar 2015 15:11:49 +0000 (GMT)
Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 26 Mar 2015 15:11:48 +0000
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.209]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Thu, 26 Mar 2015 23:11:38 +0800
From: Sheng Jiang 
To: "Hedanping (Ana)" , Brian E Carpenter , Rene Struik 
Thread-Topic: Security Levels//RE: [Anima] Ownership Concept
Thread-Index: AQHQZ9cnWJhsSGt0zEiY8ONq6gPYdQ==
Date: Thu, 26 Mar 2015 15:11:37 +0000
Message-ID: <5D36713D8A4E7348A7E10DF7437A4B925F4C4FC9@NKGEML512-MBS.china.huawei.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.146.112]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Cc: Hannes Tschofenig , "anima@ietf.org" 
Subject: [Anima] Security Levels//RE:  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, 26 Mar 2015 15:12:28 -0000

Hi, Ana,

You have mentioned security levels, which I think it is worth a separated t=
hreat to discuss it.

For my understanding, in Autonomic Network, we want to minimize the human o=
perating, which includes the operating on security level. Therefore, we wou=
ld like to design a system with as less as possible security levels.

By having domains, we may be able to get the simplest - one security level =
- full trust/security.

I also understand, in IoT scenarios, you probably need at least one more se=
curity level - exchanging information without trust relationship. This may =
be categoried into unsecure communication. So, this may still ok for the on=
e security level design: secure+unsecure.

Cheers,

Sheng
________________________________________
From: Anima [anima-bounces@ietf.org] on behalf of Hedanping (Ana) [ana.heda=
nping@huawei.com]
Sent: 26 March 2015 13:48
To: Brian E Carpenter; Rene Struik
Cc: Hannes Tschofenig; anima@ietf.org
Subject: Re: [Anima] Ownership Concept

I agree that ownership is important in life-cycle consideration, but I beli=
eve it belongs to higher security level that impacts the interaction or man=
ipulation between NEs or between NEs and owner.

  > -----Original Message-----
  > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E
  > Carpenter
  > Sent: Thursday, March 26, 2015 12:12 AM
  > To: Rene Struik
  > Cc: Hannes Tschofenig; anima@ietf.org
  > Subject: Re: [Anima] Ownership Concept
  >
  > I think it is unanswerable, or at least the answer is YMMV. You may
  > remember that one of my comments on draft-pritikin was basically: I hat=
e
  > the MASA. I was glad to see the connection to the MASA was clearly
  > indicated as optional in the slides yesterday. The point is that we hav=
e no
  > control over this - different classes of device and different vendors w=
ill have
  > different ideas about this. I firmly believe that any design we do in t=
he IETF
  > has to be very flexible on this point.
  >
  > Regards
  >    Brian
  >
  > On 25/03/2015 11:21, Rene Struik wrote:
  > > Hi Hannes:
  > >
  > > I think supply chain issues, and transgression from one supply chain
  > > step to the next, are important in life-cycle considerations. This
  > > includes how to move from one logical "owner" to the next and potenti=
ally
  > "cutting the ties" with the former. These aspects certainly require mor=
e
  > work.
  > >
  > > A very simple example of supply chain would be relabelling a device a=
s
  > > a "white goods" device (e.g., by selling a branded good at a
  > > superstore, such as Walmart, under the Walmart brand, whereas in real=
ity
  > it outsourced all production (except perhaps putting the sticker on top=
).
  > >
  > > Best regards, Rene
  > >
  > > On 3/24/2015 6:11 PM, Hannes Tschofenig wrote:
  > >> There was no time during the meeting today to ask too many questions
  > >> (because of lack of time). That's unfortunately and so I have to fal=
l
  > >> back to the mailing list.
  > >>
  > >> I wanted to get some better understand what the ownership concept is
  > >> about and what the implications are for the protocol design. The ter=
m
  > >> came up in various presentations today and it appears to be importan=
t.
  > >>
  > >> Many parties are involved in the manufacturing process of products
  > >> today and the value chain is certainly complex. Hence, who the owner
  > >> of what is and at what point might be difficult to determine.
  > >>
  > >> Does it really matter who the owner actually is?
  > >>
  > >> Ciao
  > >> Hannes
  > >>
  > >>
  > >>
  > >> _______________________________________________
  > >> 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
  > >
  >
  > _______________________________________________
  > 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 Mar 26 08:27: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 7E01F1A1B21 for ; Thu, 26 Mar 2015 08:27:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 pG9kkATjOrqr for ; Thu, 26 Mar 2015 08:27:00 -0700 (PDT)
Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::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 7903B1A00ED for ; Thu, 26 Mar 2015 08:26:59 -0700 (PDT)
Received: by wibg7 with SMTP id g7so152805559wib.1 for ; Thu, 26 Mar 2015 08:26:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=GB3x4e+yCxXxm2sGpVoySGloKfR1KHbb/c1Kzx91McM=; b=eYwI1uq8gg19eEkeG+5JSaxaKYYcnt+pGScfSDPbDrjRdrcaOMyd3WpahLN+AfcOcs ky8TC2b8r+Mk8apPLa8VCDGx+osLDarKb8tcYRfTear1EZuAZdpspoaTYLTN3nC5RePH 0zk21b+Uv3Drr3rqVV7fsTvODANw+ILjD1SPcxDVu3U9+qK5zSEiv7IL29iYjixi7vpQ NkdjBTsJ6MCvKxiC3yCeykzSrXzId9pU8hi3V8HNU9+6xGxYEjFptL7Y1dTyuwCNO99F mU2QK1PrdOBK+sYbgbT5eSJkZZBVL1/te/RWzm3b6Ezp0q1jRs0T0fo3QSONmgO0eUBV 15oA==
X-Received: by 10.194.59.199 with SMTP id b7mr29700531wjr.26.1427383617281; Thu, 26 Mar 2015 08:26:57 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:160:2581:da2a:4964:7646? ([2001:67c:370:160:2581:da2a:4964:7646]) by mx.google.com with ESMTPSA id ax10sm8859962wjc.26.2015.03.26.08.26.52 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Mar 2015 08:26:56 -0700 (PDT)
Message-ID: <55142538.6010703@gmail.com>
Date: Thu, 26 Mar 2015 11:26:48 -0400
From: Rene Struik 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Sheng Jiang ,  "Hedanping (Ana)" , Brian E Carpenter 
References: <5D36713D8A4E7348A7E10DF7437A4B925F4C4FC9@NKGEML512-MBS.china.huawei.com>
In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B925F4C4FC9@NKGEML512-MBS.china.huawei.com>
Content-Type: multipart/alternative; boundary="------------040802090204030307050603"
Archived-At: 
Cc: Hannes Tschofenig , "anima@ietf.org" 
Subject: Re: [Anima] Security Levels//RE:  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, 26 Mar 2015 15:27:03 -0000

This is a multi-part message in MIME format.
--------------040802090204030307050603
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Dear colleagues:

I think some of the discussion would benefit from distinguishing 
different objectives one may have for security services. The (very old - 
2003) two paras below illustrate this, in terms of network security vs. 
application security.

Max Pritikin mentioned the risk that a device that joins the network may 
end up with malware, which may end up with the correct network it may 
later on join.

I think his example conflates network security and application security, 
since the underlying assumption seems to be that the (adversarial) 
network manager (the one injecting the malware) has both authority to 
communicate network-related parameters and to change huge chunks of 
internal state of the device that does not have to do anything with 
infrastructure security (but with device management).

So, finer detail on the underlying security model and granularities at 
play helps.

Rene
==
Security policy and trust model
The main objectives of network security are to provide for 
infrastructure security and application security. Infrastructure 
security deals with controlling admission to networks. The objective 
here is to restrict access to scarce network resources to authorized 
resources only, such as to ensure proper bandwidth allocation, 
protection of commands (such as those regulating network membership and 
exchange of status information), and, e.g., power drain savings. 
Application security deals with controlling access to actual 
information. The objective here is to restrict access to information 
shared between members of a group of network devices to precisely these 
group members, such as to prevent external parties from learning the 
contents of exchanged messages and from modifying message traffic or 
injecting their own messages in an undetected way.

Infrastructure security and application security have different 
underlying trust requirements. With infrastructure security, the network 
owner may have an interest in restricting access to his network to 
privileged devices only, based on specific criteria, such as device 
subscription to the network or charging for airtime/bandwidth, whereas 
network devices might not care who the actual network coordinator is, as 
long as access to bandwidth is satisfactory. With application security, 
devices that exchange information may have a vested interest in keeping 
their communications private, also from the network owner. Both types of 
security involve the management of groups of devices, either for 
controlling network membership (by a network coordinator) or for 
restricting access to information to specific groups (by a security 
manager).

On 3/26/2015 11:11 AM, Sheng Jiang wrote:
> Hi, Ana,
>
> You have mentioned security levels, which I think it is worth a separated threat to discuss it.
>
> For my understanding, in Autonomic Network, we want to minimize the human operating, which includes the operating on security level. Therefore, we would like to design a system with as less as possible security levels.
>
> By having domains, we may be able to get the simplest - one security level - full trust/security.
>
> I also understand, in IoT scenarios, you probably need at least one more security level - exchanging information without trust relationship. This may be categoried into unsecure communication. So, this may still ok for the one security level design: secure+unsecure.
>
> Cheers,
>
> Sheng
> ________________________________________
> From: Anima [anima-bounces@ietf.org] on behalf of Hedanping (Ana) [ana.hedanping@huawei.com]
> Sent: 26 March 2015 13:48
> To: Brian E Carpenter; Rene Struik
> Cc: Hannes Tschofenig; anima@ietf.org
> Subject: Re: [Anima] Ownership Concept
>
> I agree that ownership is important in life-cycle consideration, but I believe it belongs to higher security level that impacts the interaction or manipulation between NEs or between NEs and owner.
>
>    > -----Original Message-----
>    > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E
>    > Carpenter
>    > Sent: Thursday, March 26, 2015 12:12 AM
>    > To: Rene Struik
>    > Cc: Hannes Tschofenig; anima@ietf.org
>    > Subject: Re: [Anima] Ownership Concept
>    >
>    > I think it is unanswerable, or at least the answer is YMMV. You may
>    > remember that one of my comments on draft-pritikin was basically: I hate
>    > the MASA. I was glad to see the connection to the MASA was clearly
>    > indicated as optional in the slides yesterday. The point is that we have no
>    > control over this - different classes of device and different vendors will have
>    > different ideas about this. I firmly believe that any design we do in the IETF
>    > has to be very flexible on this point.
>    >
>    > Regards
>    >    Brian
>    >
>    > On 25/03/2015 11:21, Rene Struik wrote:
>    > > Hi Hannes:
>    > >
>    > > I think supply chain issues, and transgression from one supply chain
>    > > step to the next, are important in life-cycle considerations. This
>    > > includes how to move from one logical "owner" to the next and potentially
>    > "cutting the ties" with the former. These aspects certainly require more
>    > work.
>    > >
>    > > A very simple example of supply chain would be relabelling a device as
>    > > a "white goods" device (e.g., by selling a branded good at a
>    > > superstore, such as Walmart, under the Walmart brand, whereas in reality
>    > it outsourced all production (except perhaps putting the sticker on top).
>    > >
>    > > Best regards, Rene
>    > >
>    > > On 3/24/2015 6:11 PM, Hannes Tschofenig wrote:
>    > >> There was no time during the meeting today to ask too many questions
>    > >> (because of lack of time). That's unfortunately and so I have to fall
>    > >> back to the mailing list.
>    > >>
>    > >> I wanted to get some better understand what the ownership concept is
>    > >> about and what the implications are for the protocol design. The term
>    > >> came up in various presentations today and it appears to be important.
>    > >>
>    > >> Many parties are involved in the manufacturing process of products
>    > >> today and the value chain is certainly complex. Hence, who the owner
>    > >> of what is and at what point might be difficult to determine.
>    > >>
>    > >> Does it really matter who the owner actually is?
>    > >>
>    > >> Ciao
>    > >> Hannes
>    > >>
>    > >>
>    > >>
>    > >> _______________________________________________
>    > >> 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
>    > >
>    >
>    > _______________________________________________
>    > 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


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


--------------040802090204030307050603
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    

      
      Dear colleagues:

        

        I think some of the discussion would benefit from distinguishing
        different objectives one may have for security services. The
        (very old - 2003) two paras below illustrate this, in terms of
        network security vs. application security.

        

        Max Pritikin mentioned the risk that a device that joins the
        network may end up with malware, which may end up with the
        correct network it may later on join.

        

        I think his example conflates network security and application
        security, since the underlying assumption seems to be that the
        (adversarial) network manager (the one injecting the malware)
        has both authority to communicate network-related parameters and
        to change huge chunks of internal state of the device that does
        not have to do anything with infrastructure security (but with
        device management).

        

        So, finer detail on the underlying security model and
        granularities at play helps.

        

        Rene

        ==

        Security policy
        and trust model

        The main objectives of network security are to provide
        for infrastructure security and application security.
        Infrastructure security
        deals with controlling admission to networks. The objective here
        is to restrict
        access to scarce network resources to authorized resources only,
        such as to
        ensure proper bandwidth allocation, protection of commands (such
        as those
        regulating network membership and exchange of status
        information), and, e.g.,
        power drain savings. Application security deals with controlling
        access to
        actual information. The objective here is to restrict access to
        information
        shared between members of a group of network devices to
        precisely these group
        members, such as to prevent external parties from learning the
        contents of
        exchanged messages and from modifying message traffic or
        injecting their own
        messages in an undetected way. 
      
 

      Infrastructure
        security and application security have different underlying
        trust requirements.
        With infrastructure security, the network owner may have an
        interest in
        restricting access to his network to privileged devices only,
        based on specific
        criteria, such as device subscription to the network or charging
        for
        airtime/bandwidth, whereas network devices might not care who
        the actual
        network coordinator is, as long as access to bandwidth is
        satisfactory. With
        application security, devices that exchange information may have
        a vested
        interest in keeping their communications private, also from the
        network owner.
        Both types of security involve the management of groups of
        devices, either for
        controlling network membership (by a network coordinator) or for
        restricting
        access to information to specific groups (by a security
        manager). 

        

      
      
      
      
      
      
      
      
      On 3/26/2015 11:11 AM, Sheng Jiang wrote:

    

    

      
Hi, Ana,

You have mentioned security levels, which I think it is worth a separated threat to discuss it.

For my understanding, in Autonomic Network, we want to minimize the human operating, which includes the operating on security level. Therefore, we would like to design a system with as less as possible security levels.

By having domains, we may be able to get the simplest - one security level - full trust/security.

I also understand, in IoT scenarios, you probably need at least one more security level - exchanging information without trust relationship. This may be categoried into unsecure communication. So, this may still ok for the one security level design: secure+unsecure.

Cheers,

Sheng
________________________________________
From: Anima [anima-bounces@ietf.org] on behalf of Hedanping (Ana) [ana.hedanping@huawei.com]
Sent: 26 March 2015 13:48
To: Brian E Carpenter; Rene Struik
Cc: Hannes Tschofenig; anima@ietf.org
Subject: Re: [Anima] Ownership Concept

I agree that ownership is important in life-cycle consideration, but I believe it belongs to higher security level that impacts the interaction or manipulation between NEs or between NEs and owner.

  > -----Original Message-----
  > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E
  > Carpenter
  > Sent: Thursday, March 26, 2015 12:12 AM
  > To: Rene Struik
  > Cc: Hannes Tschofenig; anima@ietf.org
  > Subject: Re: [Anima] Ownership Concept
  >
  > I think it is unanswerable, or at least the answer is YMMV. You may
  > remember that one of my comments on draft-pritikin was basically: I hate
  > the MASA. I was glad to see the connection to the MASA was clearly
  > indicated as optional in the slides yesterday. The point is that we have no
  > control over this - different classes of device and different vendors will have
  > different ideas about this. I firmly believe that any design we do in the IETF
  > has to be very flexible on this point.
  >
  > Regards
  >    Brian
  >
  > On 25/03/2015 11:21, Rene Struik wrote:
  > > Hi Hannes:
  > >
  > > I think supply chain issues, and transgression from one supply chain
  > > step to the next, are important in life-cycle considerations. This
  > > includes how to move from one logical "owner" to the next and potentially
  > "cutting the ties" with the former. These aspects certainly require more
  > work.
  > >
  > > A very simple example of supply chain would be relabelling a device as
  > > a "white goods" device (e.g., by selling a branded good at a
  > > superstore, such as Walmart, under the Walmart brand, whereas in reality
  > it outsourced all production (except perhaps putting the sticker on top).
  > >
  > > Best regards, Rene
  > >
  > > On 3/24/2015 6:11 PM, Hannes Tschofenig wrote:
  > >> There was no time during the meeting today to ask too many questions
  > >> (because of lack of time). That's unfortunately and so I have to fall
  > >> back to the mailing list.
  > >>
  > >> I wanted to get some better understand what the ownership concept is
  > >> about and what the implications are for the protocol design. The term
  > >> came up in various presentations today and it appears to be important.
  > >>
  > >> Many parties are involved in the manufacturing process of products
  > >> today and the value chain is certainly complex. Hence, who the owner
  > >> of what is and at what point might be difficult to determine.
  > >>
  > >> Does it really matter who the owner actually is?
  > >>
  > >> Ciao
  > >> Hannes
  > >>
  > >>
  > >>
  > >> _______________________________________________
  > >> 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
  > >
  >
  > _______________________________________________
  > 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

    

    

    

    
-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

  


--------------040802090204030307050603--


From nobody Thu Mar 26 08:35: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 871311A8032 for ; Thu, 26 Mar 2015 08:35:57 -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 p-iVJy5jQzKV for ; Thu, 26 Mar 2015 08:35:54 -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 8E00A1A1BA3 for ; Thu, 26 Mar 2015 08:35:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3189; q=dns/txt; s=iport; t=1427384155; x=1428593755; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vx+Z6sA5/MkTccPT+JJZNB3PTjqURYplzk73SbgMLQc=; b=WNQOx49LzHIzRSwQhNkwaVXkP3McECqgLKFdcl+qLjzs+FjG7osjMMh0 87RX1QzArEsQpDTiUmTI5HDCn0+t53w9bpWzx+Nfs2Rolcc5g3yVazclB JgYmeDsHid1CiXY1MVlb+t8GaOmon/C/VXV1LkatcUV9TNKWWbYk3Xymt 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ANBQAEJxRV/4cNJK1cgwZSWgTFIAqFdQKBWEwBAQEBAQF9hBQBAQEDAQEBAWsLBQsCAQgYLiEGCyUCBA4FG4gAAwkIDcVeDYUpAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLKIJHgX4zB4MXgRYFkFCIIoFNjgSGKSKDbm8BgUN/AQEB
X-IronPort-AV: E=Sophos;i="5.11,472,1422921600"; d="scan'208";a="403776468"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-1.cisco.com with ESMTP; 26 Mar 2015 15:35:55 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t2QFZrlc029054 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Mar 2015 15:35:53 GMT
Received: from xmb-rcd-x03.cisco.com ([169.254.7.184]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.03.0195.001; Thu, 26 Mar 2015 10:35:53 -0500
From: "Max Pritikin (pritikin)" 
To: Brian E Carpenter 
Thread-Topic: [Anima] interface towards vendors
Thread-Index: AQHQZn8XByVZKZPnh0+WInbbFaB6mJ0tt0+AgAB9iICAAPtGgIAAC5IA
Date: Thu, 26 Mar 2015 15:35:53 +0000
Message-ID: 
References:  <5512E15D.4050508@gmail.com> <16CEC515-094C-4192-BE96-A96368F72CC3@cisco.com> <55141D73.2010008@gmail.com>
In-Reply-To: <55141D73.2010008@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.24.233.138]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "anima@ietf.org" , Mikael Abrahamsson 
Subject: Re: [Anima] interface towards vendors
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, 26 Mar 2015 15:35:57 -0000

On Mar 26, 2015, at 8:53 AM, Brian E Carpenter  wrote:

> On 26/03/2015 12:55, Max Pritikin (pritikin) wrote:
>>=20
>>=20
>> On Mar 25, 2015, at 10:25 AM, Brian E Carpenter  wrote:
>>=20
>>> On 25/03/2015 11:08, Mikael Abrahamsson wrote:
>>>>=20
>>>> Hi,
>>>>=20
>>>> With my operator hat on, I just want to say that I do not want a lot o=
f different ways of interacting with vendors to get
>>>> credentials or anything else from the vendor regarding the devices we =
have purchased from them. I do not want separate protocols
>>>> or mechanisms, and preferrably not different credetials either.
>>>>=20
>>>> So whatever happens with the protocols speaking to IoT devices, admiss=
ion control to Autonomic Networks, and to
>>>> Netconf-call-home, we need to make sure the "backend systems" are the =
same. I think this was implied in the presentation about
>>>> draft-he-6lo-analysis-iot-sbootstrapping, but I just want to say that =
I am of this opinion as well.
>>>>=20
>>>> Can we do achieve this?
>>>=20
>>> Shout at Thread, first, to tell them not to work in secret.
>>>=20
>>> More generally, I am very worried about this. We cannot force
>>> the industry to adopt a single solution. If someone can define
>>> a common registrar model, which I guess is what you mean by
>>> a common back end, that would be fine. I am a bit pessimistic.
>>>=20
>>> To the extent that we can factor this out of the anima protocols as
>>> such, we should do so. In my walkthrough I had Discover("trust relay").
>>> I suspect that the response to that will have to include a list of
>>> supported methods. The alternative would be for a node that supports,
>>> for example, draft-pritikin would say Discover("draft-pritikin-relay")
>>> and so on for the other methods.
>>=20
>> Or it discovers one relay and then reports (somehow, somehow securely) w=
hich methods it accepts for onboarding?
>=20
> I don't see how that can be done securely, since at that moment nobody
> can trust the new device at all.

Yes, =93(somehow, somehow securely)=94 was meant to imply I=92m not sure ho=
w to do secure negotiation either.=20

Although we can leverage the IDevID to authenticate the client, and know th=
at the negotiation proposal originated at the client, we can=92t know if ma=
lware is driving this negotiation unless we have one of the mitigation tech=
niques already in place.=20

> For the rest I agree with Max.

I think we=92re on the same page,=20

- max



>=20
>   Brian
>=20
>>=20
>> Something like, the device indicates which of these options are supporte=
d:
>> 	a) prove you own me (required: vendors to track this plus vendor cloud =
service)
>> 	b) i=92ll prove i=92m not corrupted (required: NEA hardware)
>> 	c) prove this event is logged (required: vendor neutral cloud service)
>> And the =93trust relay=94 reacts accordingly?
>>=20
>> - max
>>=20
>>>=20
>>>   Brian
>>>=20
>>> _______________________________________________
>>> Anima mailing list
>>> Anima@ietf.org
>>> https://www.ietf.org/mailman/listinfo/anima
>>=20
>>=20
>=20


From nobody Thu Mar 26 08:50:24 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 C878F1B29A9 for ; Thu, 26 Mar 2015 08:50: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 JL1272CP3CsF for ; Thu, 26 Mar 2015 08:50:14 -0700 (PDT)
Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::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 41C331B2CE6 for ; Thu, 26 Mar 2015 08:49:50 -0700 (PDT)
Received: by wgdm6 with SMTP id m6so69222506wgd.2 for ; Thu, 26 Mar 2015 08:49:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ApMJ/jyqT3TI1RUQuWEIv4OJMjZpmsvlWgBPJ9y6cNU=; b=r6Y2qjDTZA7LMB5y8JpzXFY11YIiZrcWp+EHBkxiSbY4vlB4HdHLOa63AuHC21kbyl VVGE7uZuX/E4IJu24cL4mItp8CSFGgA7DJ438GxiCCygG4NffoWn7vWMM0x5+Czt92aP gRNm9KtawpwpkkRaJyzblvx5TNG+u/laYge4/P+icYxsGHoHIu9QCA8NdZvt/ds0Eg0D pEN4cLzJxnF2uGMJw+x9W4Vi6Nhqk8GTnWGLPNSpzHJv8Ict13GYuM7BEdjCiKP4Np2z WoW3Pv28gymUcjoQUAyrELvEfLLTTfCZDGh81GA9smLg4ykiJvhrxOoZFCheHYwcBv5V ag7w==
X-Received: by 10.180.74.47 with SMTP id q15mr47955719wiv.90.1427384989012; Thu, 26 Mar 2015 08:49:49 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:160:2581:da2a:4964:7646? ([2001:67c:370:160:2581:da2a:4964:7646]) by mx.google.com with ESMTPSA id ey10sm21073224wib.2.2015.03.26.08.49.46 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Mar 2015 08:49:48 -0700 (PDT)
Message-ID: <55142A96.6040209@gmail.com>
Date: Thu, 26 Mar 2015 11:49:42 -0400
From: Rene Struik 
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)" ,  Brian E Carpenter 
References:  <5512E15D.4050508@gmail.com> <16CEC515-094C-4192-BE96-A96368F72CC3@cisco.com> <55141D73.2010008@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "anima@ietf.org" , Mikael Abrahamsson 
Subject: Re: [Anima] interface towards vendors
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, 26 Mar 2015 15:50:16 -0000

Max:

Below, you mentioned the risk that a device that joins the network may 
end up with malware, which may end up with the correct network it may 
later on join.

I think your example conflates network security and application 
security, since the underlying assumption seems to be that the 
(adversarial) network manager (the one injecting the malware) has both 
authority to communicate network-related parameters and to change huge 
chunks of internal state of the device that does not have to do anything 
with infrastructure security (but with device management).

For detail on security models, please see my earlier email (Thu March 
26, 2015, 11.26am EDT).

Rene

On 3/26/2015 11:35 AM, Max Pritikin (pritikin) wrote:
> On Mar 26, 2015, at 8:53 AM, Brian E Carpenter  wrote:
>
>> On 26/03/2015 12:55, Max Pritikin (pritikin) wrote:
>>>
>>> On Mar 25, 2015, at 10:25 AM, Brian E Carpenter  wrote:
>>>
>>>> On 25/03/2015 11:08, Mikael Abrahamsson wrote:
>>>>> Hi,
>>>>>
>>>>> With my operator hat on, I just want to say that I do not want a lot of different ways of interacting with vendors to get
>>>>> credentials or anything else from the vendor regarding the devices we have purchased from them. I do not want separate protocols
>>>>> or mechanisms, and preferrably not different credetials either.
>>>>>
>>>>> So whatever happens with the protocols speaking to IoT devices, admission control to Autonomic Networks, and to
>>>>> Netconf-call-home, we need to make sure the "backend systems" are the same. I think this was implied in the presentation about
>>>>> draft-he-6lo-analysis-iot-sbootstrapping, but I just want to say that I am of this opinion as well.
>>>>>
>>>>> Can we do achieve this?
>>>> Shout at Thread, first, to tell them not to work in secret.
>>>>
>>>> More generally, I am very worried about this. We cannot force
>>>> the industry to adopt a single solution. If someone can define
>>>> a common registrar model, which I guess is what you mean by
>>>> a common back end, that would be fine. I am a bit pessimistic.
>>>>
>>>> To the extent that we can factor this out of the anima protocols as
>>>> such, we should do so. In my walkthrough I had Discover("trust relay").
>>>> I suspect that the response to that will have to include a list of
>>>> supported methods. The alternative would be for a node that supports,
>>>> for example, draft-pritikin would say Discover("draft-pritikin-relay")
>>>> and so on for the other methods.
>>> Or it discovers one relay and then reports (somehow, somehow securely) which methods it accepts for onboarding?
>> I don't see how that can be done securely, since at that moment nobody
>> can trust the new device at all.
> Yes, “(somehow, somehow securely)” was meant to imply I’m not sure how to do secure negotiation either.
>
> Although we can leverage the IDevID to authenticate the client, and know that the negotiation proposal originated at the client, we can’t know if malware is driving this negotiation unless we have one of the mitigation techniques already in place.
>
>> For the rest I agree with Max.
> I think we’re on the same page,
>
> - max
>
>
>
>>    Brian
>>
>>> Something like, the device indicates which of these options are supported:
>>> 	a) prove you own me (required: vendors to track this plus vendor cloud service)
>>> 	b) i’ll prove i’m not corrupted (required: NEA hardware)
>>> 	c) prove this event is logged (required: vendor neutral cloud service)
>>> And the “trust relay” reacts accordingly?
>>>
>>> - max
>>>
>>>>    Brian
>>>>
>>>> _______________________________________________
>>>> 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


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


From nobody Thu Mar 26 08:55: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 78B2A1A024E for ; Thu, 26 Mar 2015 08:55:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.911
X-Spam-Level: 
X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_31=0.6, 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 ptpYOJX8dFuE for ; Thu, 26 Mar 2015 08:55:51 -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 791641A870E for ; Thu, 26 Mar 2015 08:55:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10508; q=dns/txt; s=iport; t=1427385351; x=1428594951; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=5RuX0GkGFYdNdx/j0Zm8bJeIrgKnMSfEP4cXVjkryfs=; b=Rzzcic236bTdtjm3r+T3juBo4b4IcdCREhuFcIeAwgMoEmXtKjRmd0u6 MSPBekfgAHOryJO2SuwbWKfGYjudjErPbiEV1RCNlLnNqbEI2Ivfy01DR uvgrbLrwCLRHWUWF2cEEOsyuBR0Csuj0wDWt0DvXqkRJR5RRxpILq7oIi 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AOBQA5KxRV/4YNJK1cgwZSWgTFIAqFdQKBWUwBAQEBAQF9hBQBAQEDAQEBAWsLBQsCAQgRBAEBAS4nCx0IAgQOBRkCiAwIDcsjAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSKKX+ERTMHgxeBFgWQUIlvgRuKSYFUgy6DRyKCAhyBUG+BBCQcfwEBAQ
X-IronPort-AV: E=Sophos;i="5.11,473,1422921600"; d="scan'208";a="135668919"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-7.cisco.com with ESMTP; 26 Mar 2015 15:55:50 +0000
Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t2QFto7d005280 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Mar 2015 15:55:50 GMT
Received: from xmb-rcd-x03.cisco.com ([169.254.7.184]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Thu, 26 Mar 2015 10:55:50 -0500
From: "Max Pritikin (pritikin)" 
To: Sheng Jiang 
Thread-Topic: [Anima] Ownership Concept
Thread-Index: AQHQZn+Wm4eAxWuLS02QOiRijuPZe50siH6AgAErG4CAAA9fAIAAD5aAgAAMGgCAAAQLAIAAEuYAgAAOZICAABD7gIAAEvkAgAAHVoCAAAQAAIAANEQAgADZtoA=
Date: Thu, 26 Mar 2015 15:55:49 +0000
Message-ID: <450CE948-8AD8-419B-B026-9549FE4CCF9F@cisco.com>
References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> <5512DE41.6030209@gmail.com> <20150325170646.GB31979@cisco.com> <5512F839.6080502@gmail.com> <20150325184552.GC31979@cisco.com> <551305C4.9030001@gmail.com> <20150325200758.GD31979@cisco.com>, <3C8F19F4-54E7-48E5-AD62-A2300E946C4E@cisco.com> <5D36713D8A4E7348A7E10DF7437A4B925F4C2C8D@NKGEML512-MBS.china.huawei.com>,  <5D36713D8A4E7348A7E10DF7437A4B925F4C3D1A@NKGEML512-MBS.china.huawei.com>, <7502156E-DF71-492F-874F-A0053A5EFAC2@cisco.com> <5D36713D8A4E7348A7E10DF7437A4B925F4C3DBA@NKGEML512-MBS.china.huawei.com>
In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B925F4C3DBA@NKGEML512-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.233.138]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <9F95216FBE86CE4CB678F6BB0CB3218F@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "Toerless Eckert \(eckert\)" , Hannes Tschofenig , Rene Struik , "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, 26 Mar 2015 15:55:54 -0000

On Mar 25, 2015, at 8:55 PM, Sheng Jiang  wrote:

> Max>I think you=92re arguing that all three mitigation techniques,=20
>> or at least two of them, are required? Is that true?
>=20
> No. I did not argue on any certain mitigation techniques. My argument is =
the necessity of online checking with MASA.

I take this to mean you accept the threat model discussion and that the mit=
igations I supplied address the threats =97 but that you really don=92t lik=
e having a cloud service in the loop at all.

> I don't think there is technical requirements that you could not do on th=
e registrater locally,

The requirement is that the solution ensure against, or detect, malware bei=
ng installed by a Mallory registrar. At the time that this occurs the commu=
nication is between the device and the Mallory registrar so I don=92t under=
stand how the domain Registrar could prevent this w/o adding specific funct=
ionality on the device. For example...

> although it may require some pre-configuration or out-of-band setup.

=85 here you imply a pre-configuration or out-of-band feature on the new de=
vice. If so, I agree with you that pre-configuration of the new device via =
an out-of-band channel like a console port does mitigate the threat describ=
ed, to some extent. I thought a basic requirement is for zero-touch (no pre=
-configuration). Additionally =93out-of-band=94 channels are becoming rarer=
 as devices move to more and more wireless or at least single/simple ports =
without user interfaces. I didn=92t consider this a particularly useful mit=
igation but agree it could be included for completeness in the discussion.

> Evenmore, the owner of the network should have the right to trust devices=
 with Trust-on-first-use (TOFU) policy.

The only way I know to secure this is, according to the threat model and mi=
tigations agreed on above, is to use TPM like hardware behind an NEA mechan=
ism. The network *of course* has the right to demand and to purchase such e=
quipment. Lets assume for a moment that not all devices have this hardware =
though. What mitigation mechanism do you suggest to ensure against, or dete=
ct, malware being installed by a Mallory domain that is not either a MASA c=
loud service (logging used for detection) or an Ownership Validation cloud =
service (fully tracking ownership in the sales channel)?=20

- max

> Sheng
>=20
>> Sheng
>>=20
>> ________________________________________
>> From: Max Pritikin (pritikin) [pritikin@cisco.com]
>> Sent: 26 March 2015 7:08
>> To: Sheng Jiang
>> Cc: Toerless Eckert (eckert); Hannes Tschofenig; anima@ietf.org; Rene St=
ruik
>> Subject: Re: [Anima] Ownership Concept
>>=20
>> I think Rene=92s point about the underlying security model is a good one=
. It explains why I disagree with your note below. Refer to my email earlie=
r in this thread where I lay out the attack which must be mitigated: the de=
vice joins Mallory=92s domain and has malware installed on it.
>>=20
>> On Mar 25, 2015, at 4:00 PM, Sheng Jiang  wrote:
>>=20
>>> Max>I don=92t understand how one can expect the backend to be
>>>> totally =93optional=94 since the device doesn=92t know if it should be
>>>> optional or not.
>>>=20
>>> One possible deployment scenario: the owner of the network has obtained=
 the certs of devices out-of-band before the device bootstraps. The certs a=
re stored at the registrater locally. Then, we the new devices is plugged i=
n, the registrater can validate it by it self - no need to contact MASA.
>>=20
>> In which case Mallory can trivially do this and now has full access to t=
he device. Mallory installs malware on the device and, using the malware, j=
oins the target network.
>>=20
>> What I laid out in the prior thread were three possible mitigations. Non=
e of them are ideal. Of the choices I=92ve contended that the MASA approach=
 is the least onerous since it minimizes the central cloud service to a sim=
ple logging entity.
>>=20
>> Where the MASA concept is weakest is when an air-gap is anticipated. In =
such cases the MASA concept allows for =93nonce-less=94 authorizations that=
 are long lived. To minimize that one can optionally do full ownership trac=
king but only if all MASA responders agree to do so =97 which reduces our a=
bility to deal with =93vendor went out of business but there are 3rd party =
MASA services=94 use cases.
>>=20
>> I=92m uncomfortable mitigating this problem by mandating full ownership =
tracking, as in the netconf proposal, because that is a really hard problem=
 to solve even while I see the value of it.
>>=20
>> - max
>>=20
>>>=20
>>> Sheng
>>>=20
>>>>=20
>>>> I just think that devices that do permit to be enrolled/configured
>>>> without MASA or the zerotouch backend equivalent will be intrinsically
>>>> less secure. It does make sense though to permit them to exist, especi=
ally
>>>> for high security envionments where te vendor and customer may have
>>>> a much better lock on the ongoing physical presence of the device and
>>>> what networks it gets connected to.
>>>>=20
>>>> Cheers
>>>> Toerless
>>>>=20
>>>> P.S.: I think all devices other than those owned by DoD and DoE can
>>>> be expected to have connectivity to a backend server in Fort Meade
>>>> including White House and Bundestag ;-)
>>>>=20
>>>> On Thu, Mar 26, 2015 at 08:00:20AM +1300, Brian E Carpenter wrote:
>>>>> Indeed, I think any kind of call-home is unacceptable in
>>>>> certain high security environments. Would you expect, say,
>>>>> the door lock control system of the White House or the
>>>>> Bundestag to call an external server for a firmware update?
>>>>>=20
>>>>> Another aspect is disaster recovery. If you have to reboot
>>>>> your network at a time when all Internet access is down
>>>>> (think hurricane or earthquake), you don't want to *require*
>>>>> an external service.
>>>>>=20
>>>>> "We can't open the elevator doors because the Internet is down."
>>>>>=20
>>>>> I really think our bootstrap scenarios have to allow for this.
>>>>>=20
>>>>> Brian
>>>>>=20
>>>>> On 26/03/2015 07:45, Toerless Eckert wrote:
>>>>>> Thanks, Brian.
>>>>>>=20
>>>>>> If i understand it correctly, in the netconf zerotouch approach,
>>>>>> the router to control the meltdown process in the reactor would stil=
l
>>>>>> need to receive a file from the outside of the reactor airgap (axctu=
ally
>>>>>> something like a .tar of 4? files). And in result it would have some
>>>>>> bootstrap config, but not a nuclear pant operator certificate.
>>>>>>=20
>>>>>> True/False ?
>>>>>>=20
>>>>>> How would that match your requirements - any better/different to
>>>>>> you than MASA ?
>>>>>>=20
>>>>>> Cheers
>>>>>> Toerless
>>>>>>=20
>>>>>> On Thu, Mar 26, 2015 at 07:02:33AM +1300, Brian E Carpenter wrote:
>>>>>>> On 26/03/2015 06:06, Toerless Eckert wrote:
>>>>>>>> Should i be able to find a more detailed reasonining from you abou=
t MASA
>>>>>>>> in the mailing list archive ?  if not, would you mind to elaborate=
 here ?
>>>>>>>=20
>>>>>>> I expect it is somewhere in my comments on draft-pritikin, but basi=
cally
>>>>>>> I think we MUST have a mode that has no external dependencies whate=
ver.
>>>>>>> A nuclear plant operator might agree with me, or anyone who wants a=
 secure
>>>>>>> network with an air gap round it.
>>>>>>>=20
>>>>>>> As long as the MASA is optional, it's fine.
>>>>>>>=20
>>>>>>> Brian
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> Cheers
>>>>>>>> Toerless
>>>>>>>>=20
>>>>>>>> On Thu, Mar 26, 2015 at 05:11:45AM +1300, Brian E Carpenter wrote:
>>>>>>>>> I think it is unanswerable, or at least the answer is YMMV. You m=
ay remember that
>>>>>>>>> one of my comments on draft-pritikin was basically: I hate the MA=
SA. I was glad
>>>>>>>>> to see the connection to the MASA was clearly indicated as option=
al in the slides
>>>>>>>>> yesterday. The point is that we have no control over this - diffe=
rent classes
>>>>>>>>> of device and different vendors will have different ideas about t=
his. I firmly
>>>>>>>>> believe that any design we do in the IETF has to be very flexible=
 on
>>>>>>>>> this point.
>>>>>>>>>=20
>>>>>>>>> Regards
>>>>>>>>> Brian
>>>>>>>>>=20
>>>>>>>>> On 25/03/2015 11:21, Rene Struik wrote:
>>>>>>>>>> Hi Hannes:
>>>>>>>>>>=20
>>>>>>>>>> I think supply chain issues, and transgression from one supply c=
hain step to the next, are important in life-cycle
>>>>>>>>>> considerations. This includes how to move from one logical "owne=
r" to the next and potentially "cutting the ties" with the
>>>>>>>>>> former. These aspects certainly require more work.
>>>>>>>>>>=20
>>>>>>>>>> A very simple example of supply chain would be relabelling a dev=
ice as a "white goods" device (e.g., by selling a branded good
>>>>>>>>>> at a superstore, such as Walmart, under the Walmart brand, where=
as in reality it outsourced all production (except perhaps
>>>>>>>>>> putting the sticker on top).
>>>>>>>>>>=20
>>>>>>>>>> Best regards, Rene
>>>>>>>>>>=20
>>>>>>>>>> On 3/24/2015 6:11 PM, Hannes Tschofenig wrote:
>>>>>>>>>>> There was no time during the meeting today to ask too many ques=
tions
>>>>>>>>>>> (because of lack of time). That's unfortunately and so I have t=
o fall
>>>>>>>>>>> back to the mailing list.
>>>>>>>>>>>=20
>>>>>>>>>>> I wanted to get some better understand what the ownership conce=
pt is
>>>>>>>>>>> about and what the implications are for the protocol design. Th=
e term
>>>>>>>>>>> came up in various presentations today and it appears to be imp=
ortant.
>>>>>>>>>>>=20
>>>>>>>>>>> Many parties are involved in the manufacturing process of produ=
cts today
>>>>>>>>>>> and the value chain is certainly complex. Hence, who the owner =
of what
>>>>>>>>>>> is and at what point might be difficult to determine.
>>>>>>>>>>>=20
>>>>>>>>>>> Does it really matter who the owner actually is?
>>>>>>>>>>>=20
>>>>>>>>>>> Ciao
>>>>>>>>>>> Hannes
>>>>>>=20
>>>>=20
>>>> --
>>>> ---
>>>> Toerless Eckert, eckert@cisco.com
>>>>=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 Mar 26 08:56: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 57C111AD0C0 for ; Thu, 26 Mar 2015 08:56:31 -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 RhUiFzqONlHH for ; Thu, 26 Mar 2015 08:56:30 -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 525001ACE7E for ; Thu, 26 Mar 2015 08:56:30 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id F091AE1A6 for ; Thu, 26 Mar 2015 12:06:26 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id EE40663B76; Thu, 26 Mar 2015 11:56:28 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D4CD263731 for ; Thu, 26 Mar 2015 11:56:28 -0400 (EDT)
From: Michael Richardson 
To: "anima\@ietf.org" 
In-Reply-To: <1D2369B2-4AEA-4479-8177-59BEB7DA0B6E@cisco.com>
References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> <1D2369B2-4AEA-4479-8177-59BEB7DA0B6E@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: Thu, 26 Mar 2015 15:56:31 -0000

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable


Max Pritikin (pritikin)  wrote:
    > b) Trusted Hardware Modules such that malware can not be installed on
    > devices or that such devices can be detected by the target domain.
    > This requires very specific and detailed hardware such as the TPM
    > provided by Trusted Computing Group and is, I think, out of scope for
    > IETF solutions.

This is neither here nor there.
Even without this trojan, it might be that I can still MITM the operator.

Getting the device to join my malicious network, instead of your network, m=
ay
be more than enough.  I can now control your actuators.  That might mean I'=
ve
won, period.=20

Maybe, I will provide a different device that appears to join your network,
and after some on your part, troubleshooting, convince you that it's the
right device, because after all, when you operate this "fake" device, the
real valves actually do operate...=20

    > I think this does effect the protocol design.


=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)

iQEVAwUBVRQsKoCLcPvd0N1lAQLsvgf/ZMbKwznuo+y+M1zreot9264Z2ET3Wzkh
Kl7eaBsvG2tausGbgH4u8FwqAqS2W1gotsbg9Mm25uoWfl37QaLF4UXk9eJWsrM9
5k38y4OkObo0SMRtH2dihKPqEwmNphcsxjMQD2/TfSXgJyjDTbUXDqx/JT3+ATdY
+YcsnPVJVjZzKzp4bhhCHQZY4eUDsUXRoF4wWQpvPb2xN9tbiV8N0Wk/7Gcw4eSz
+6SlfvDZncIoih2/SwVvqqvOeW/BtVxejlB8P9bdmBUduhbfO+bEgV0ZnVovWidQ
Z4TdYXNcmv75Pgd62lWBaljo2C67H5Ys/YEB+K0CWlgNf3jeegTupA==
=ntCd
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Thu Mar 26 08:57: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 5C4E01A7D80 for ; Thu, 26 Mar 2015 08:57:29 -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 TqCuIxwxvyI0 for ; Thu, 26 Mar 2015 08:57:28 -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 5EF971A0363 for ; Thu, 26 Mar 2015 08:57:28 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A6669E1A6; Thu, 26 Mar 2015 12:07:25 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id A574E63B76; Thu, 26 Mar 2015 11:57:27 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 8CBC363731; Thu, 26 Mar 2015 11:57:27 -0400 (EDT)
From: Michael Richardson 
To: "anima\@ietf.org" 
In-Reply-To: <77FA386512F0D748BC7C02C36EB1106D956D45@szxeml557-mbs.china.huawei.com>
References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> <5512DE41.6030209@gmail.com> <77FA386512F0D748BC7C02C36EB1106D956D45@szxeml557-mbs.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: 
Cc: "Hedanping \(Ana\)" 
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, 26 Mar 2015 15:57:29 -0000

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable


Hedanping (Ana)  wrote:
    > I agree that ownership is important in life-cycle consideration, but I
    > believe it belongs to higher security level that impacts the
    > interaction or manipulation between NEs or between NEs and owner.

I strongly disagree.
Ownership is fundamental.  No other interaction makes sense until you
establish ownership.


=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)

iQEVAwUBVRQsZICLcPvd0N1lAQLR4wf/X6YacxCOCRmfJGFuxsKGijULHXKfkiNg
W9iFTdOFKwz5l4JGWExppV6qOmTubKYRDo/syp1ay7dSu1TLXD/+GQch4c8Qxvuk
FJ+W5yeMePTMRivjgpAkOoMvE7IUKl1AOCJlnv6xa/Wa8chL/+5NEvWy61rYeD9/
GW6vaOUvyv+7oY4/2Fx2jpMpR/lzBe03lCNInRJwzOQSgm8jjQFFNSj/rNV7DJXl
DkdK+UUYvEbIOzAbnNYrRY4pq766Uu1vbRwFITsWzM/FrD46tz779U2NkSz0wy+q
rgjOdG2dXBiPycWGZVvKg8tj32OgY81tHtiU1mc7a2xqnEXGi7HaOw==
=Qv8Q
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Thu Mar 26 08:59: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 7E5611A876A for ; Thu, 26 Mar 2015 08:59: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 u8qK9lxNeD1U for ; Thu, 26 Mar 2015 08:59:31 -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 0D3A21A024E for ; Thu, 26 Mar 2015 08:59: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 BQS96020; Thu, 26 Mar 2015 15:59:29 +0000 (GMT)
Received: from SZXEML432-HUB.china.huawei.com (10.82.67.209) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 26 Mar 2015 15:59:28 +0000
Received: from szxeml557-mbs.china.huawei.com ([169.254.6.131]) by szxeml432-hub.china.huawei.com ([10.82.67.209]) with mapi id 14.03.0158.001; Thu, 26 Mar 2015 23:59:11 +0800
From: "Hedanping (Ana)" 
To: Brian E Carpenter , "Max Pritikin (pritikin)" 
Thread-Topic: [Anima] interface towards vendors
Thread-Index: AQHQZn8X5HeH1nBtQEWdii7d37+EF50s3WGAgAB9vYCAANi0oP//9i8AgACzD1A=
Date: Thu, 26 Mar 2015 15:59:10 +0000
Message-ID: <77FA386512F0D748BC7C02C36EB1106D956F43@szxeml557-mbs.china.huawei.com>
References:  <5512E15D.4050508@gmail.com> <16CEC515-094C-4192-BE96-A96368F72CC3@cisco.com> <77FA386512F0D748BC7C02C36EB1106D956D21@szxeml557-mbs.china.huawei.com> <5513F864.1090308@gmail.com>
In-Reply-To: <5513F864.1090308@gmail.com>
Accept-Language: en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.152.219]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Cc: "anima@ietf.org" , Mikael Abrahamsson 
Subject: Re: [Anima] interface towards vendors
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, 26 Mar 2015 15:59:33 -0000

Hi Brian,

  > -----Original Message-----
  > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E
  > Carpenter
  > Sent: Thursday, March 26, 2015 8:16 PM
  > To: Hedanping (Ana); Max Pritikin (pritikin)
  > Cc: anima@ietf.org; Mikael Abrahamsson
  > Subject: Re: [Anima] interface towards vendors
  >=20
  > Hi Ana,
  > On 26/03/2015 18:16, Hedanping (Ana) wrote:
  > > Hi Max,
  > >   > -----Original Message-----
  > >   > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Max
  > Pritikin
  > >   > (pritikin)
  > >   > Sent: Thursday, March 26, 2015 7:55 AM
  > >   > To: Brian E Carpenter
  > >   > Cc: anima@ietf.org; Mikael Abrahamsson
  > >   > Subject: Re: [Anima] interface towards vendors
  > >   >
  > >
  > >   > Something like, the device indicates which of these options are
  > supported:
  > >   > 	a) prove you own me (required: vendors to track this plus vendor
  > cloud
  > >   > service)
  > >
  > > It is ownership issue, and I believe it belongs to higher level secur=
ity rather
  > than devices securely joins the network.
  > >
  > >   > 	b) i'll prove i'm not corrupted (required: NEA hardware)
  > >
  > > How about firmware signature by vendor?
  > >   > 	c) prove this event is logged (required: vendor neutral cloud se=
rvice)
  > And
  > >   > the "trust relay" reacts accordingly?
  > >
  > > Why should the device care about this information?
  > >
  > > Besides, why is the domain concept needed if any one of the above
  > mentioned options are supported?
  >=20
  > The set of devices permitted to perform autonomic configuration in a
  > network must be limited to devices within the network, and also they mu=
st
  > be able to verify that peer autonomic nodes are also in the same networ=
k.
  > The Device ID and Domain ID both need to be cryptographically
  > authenticated for this. That's why we need registration *within* the do=
main.
  > Actually that is much more important for Anima that ownership.
  >=20
Domain ID sounds like network ID to me. Do we really need the centralized m=
anner to let registrar assign the domain ID to a joining device?
But I do agree that in some scenarios, it would be better if the registrati=
on can be realized locally. The solution should not limit users' option: Th=
e registrar can either download device lists/credential material from vendo=
r or be configured locally.=20

Ana

=20
  >     Brian
  >=20
  > >
  > > Regards,
  > > Ana
  > >   >
  > >   > - max
  > >   >
  > >   > >
  > >   > >    Brian
  > >   > >
  > >   > > _______________________________________________
  > >   > > 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
  > >
  >=20
  > _______________________________________________
  > Anima mailing list
  > Anima@ietf.org
  > https://www.ietf.org/mailman/listinfo/anima


From nobody Thu Mar 26 09:02: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 282261A87A0 for ; Thu, 26 Mar 2015 09:02:36 -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 uU9z3HDUM8BT for ; Thu, 26 Mar 2015 09:02:30 -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 7A9B81A872A for ; Thu, 26 Mar 2015 09:02:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5046; q=dns/txt; s=iport; t=1427385750; x=1428595350; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=6CAuJk5FiGKOoE6wSpZaSQhpDBbjfQO8qBcGtUj5PvM=; b=Qub7ICR8yhhUZnQE96IfclTbFU9J7r6asND0w6OFlkAcs+VLTCOp2yPV /Cb8PnAN7pyXSRGQsZOJD5BFNlhGOAiG9JlfJ/ucI7VKRamVmOcQqND9p eTHfB5a0HhDwOwQtXx4QLsLjkUZV6UMxcrvx/de2E+eDBCPKN6KrGF2kC k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AOBQAULRRV/5FdJa1ZA4MGUloExSAKhXUCgVlMAQEBAQEBfYQUAQEBAwEBAQFrCwULAgEIDgouIQYLJQIEDgUbiAADCQgNxWYNhSkBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIsogkeBTxEBHSMQBxGDBoEWBY0rgyWIIoFNgRuDMIk5gmKDRyKDbm8BgQo5fwEBAQ
X-IronPort-AV: E=Sophos;i="5.11,473,1422921600"; d="scan'208";a="406900493"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-3.cisco.com with ESMTP; 26 Mar 2015 16:02:27 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t2QG2RfN032630 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Mar 2015 16:02:27 GMT
Received: from xmb-rcd-x03.cisco.com ([169.254.7.184]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Thu, 26 Mar 2015 11:02:27 -0500
From: "Max Pritikin (pritikin)" 
To: Rene Struik 
Thread-Topic: [Anima] interface towards vendors
Thread-Index: AQHQZn8XByVZKZPnh0+WInbbFaB6mJ0tt0+AgAB9iICAAPtGgIAAC5IAgAAEFwCAAANVAA==
Date: Thu, 26 Mar 2015 16:02:26 +0000
Message-ID: <985C1266-1E66-4568-B9A5-1C20C5991B4F@cisco.com>
References:  <5512E15D.4050508@gmail.com> <16CEC515-094C-4192-BE96-A96368F72CC3@cisco.com> <55141D73.2010008@gmail.com>  <55142A96.6040209@gmail.com>
In-Reply-To: <55142A96.6040209@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.24.233.138]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "anima@ietf.org" , Mikael Abrahamsson 
Subject: Re: [Anima] interface towards vendors
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, 26 Mar 2015 16:02:36 -0000

On Mar 26, 2015, at 9:49 AM, Rene Struik  wrote:

> Max:
>=20
> Below, you mentioned the risk that a device that joins the network may en=
d up with malware, which may end up with the correct network it may later o=
n join.
>=20
> I think your example conflates network security and application security,=
 since the underlying assumption seems to be that the (adversarial) network=
 manager (the one injecting the malware) has both authority to communicate =
network-related parameters and to change huge chunks of internal state of t=
he device that does not have to do anything with infrastructure security (b=
ut with device management).

For the purpose of a threat model I go further and assume the attacker can =
load arbitrary code onto the device. We=92re talking about taking local =93=
ownership=94 of the device meaning full control to do whatever the device a=
llows in the way of configuration and updates and new images and etc. This =
includes the ability to install vulnerable images and inject malware throug=
h known (perhaps older) security vulnerabilities.=20

The hardware TPM for secure boot and attestation as described in NEA does m=
itigate this but I figure we=92re looking for an approximation of that secu=
rity without mandating that hardware.=20

- max

> For detail on security models, please see my earlier email (Thu March 26,=
 2015, 11.26am EDT).
>=20
> Rene
>=20
> On 3/26/2015 11:35 AM, Max Pritikin (pritikin) wrote:
>> On Mar 26, 2015, at 8:53 AM, Brian E Carpenter  wrote:
>>=20
>>> On 26/03/2015 12:55, Max Pritikin (pritikin) wrote:
>>>>=20
>>>> On Mar 25, 2015, at 10:25 AM, Brian E Carpenter  wrote:
>>>>=20
>>>>> On 25/03/2015 11:08, Mikael Abrahamsson wrote:
>>>>>> Hi,
>>>>>>=20
>>>>>> With my operator hat on, I just want to say that I do not want a lot=
 of different ways of interacting with vendors to get
>>>>>> credentials or anything else from the vendor regarding the devices w=
e have purchased from them. I do not want separate protocols
>>>>>> or mechanisms, and preferrably not different credetials either.
>>>>>>=20
>>>>>> So whatever happens with the protocols speaking to IoT devices, admi=
ssion control to Autonomic Networks, and to
>>>>>> Netconf-call-home, we need to make sure the "backend systems" are th=
e same. I think this was implied in the presentation about
>>>>>> draft-he-6lo-analysis-iot-sbootstrapping, but I just want to say tha=
t I am of this opinion as well.
>>>>>>=20
>>>>>> Can we do achieve this?
>>>>> Shout at Thread, first, to tell them not to work in secret.
>>>>>=20
>>>>> More generally, I am very worried about this. We cannot force
>>>>> the industry to adopt a single solution. If someone can define
>>>>> a common registrar model, which I guess is what you mean by
>>>>> a common back end, that would be fine. I am a bit pessimistic.
>>>>>=20
>>>>> To the extent that we can factor this out of the anima protocols as
>>>>> such, we should do so. In my walkthrough I had Discover("trust relay"=
).
>>>>> I suspect that the response to that will have to include a list of
>>>>> supported methods. The alternative would be for a node that supports,
>>>>> for example, draft-pritikin would say Discover("draft-pritikin-relay"=
)
>>>>> and so on for the other methods.
>>>> Or it discovers one relay and then reports (somehow, somehow securely)=
 which methods it accepts for onboarding?
>>> I don't see how that can be done securely, since at that moment nobody
>>> can trust the new device at all.
>> Yes, =93(somehow, somehow securely)=94 was meant to imply I=92m not sure=
 how to do secure negotiation either.
>>=20
>> Although we can leverage the IDevID to authenticate the client, and know=
 that the negotiation proposal originated at the client, we can=92t know if=
 malware is driving this negotiation unless we have one of the mitigation t=
echniques already in place.
>>=20
>>> For the rest I agree with Max.
>> I think we=92re on the same page,
>>=20
>> - max
>>=20
>>=20
>>=20
>>>   Brian
>>>=20
>>>> Something like, the device indicates which of these options are suppor=
ted:
>>>> 	a) prove you own me (required: vendors to track this plus vendor clou=
d service)
>>>> 	b) i=92ll prove i=92m not corrupted (required: NEA hardware)
>>>> 	c) prove this event is logged (required: vendor neutral cloud service=
)
>>>> And the =93trust relay=94 reacts accordingly?
>>>>=20
>>>> - max
>>>>=20
>>>>>   Brian
>>>>>=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
>=20
>=20
> --=20
> email: rstruik.ext@gmail.com | Skype: rstruik
> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
>=20


From nobody Thu Mar 26 09:06: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 00C4C1A87D7 for ; Thu, 26 Mar 2015 09:06:11 -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 0_T6h_F8LvSr for ; Thu, 26 Mar 2015 09:06:07 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 232491AD357 for ; Thu, 26 Mar 2015 09:06:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1935; q=dns/txt; s=iport; t=1427385967; x=1428595567; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=p4ja/EOzSJOF9F8RxHJUFFz13DFEZBhXqZ0lIu9IYXI=; b=cTZ4bRb6l7BaFmC64ZoDe3fjG1Z8kd9rUQ+6h591tGes7A2ORUvejSEW g4MjyTHa0UW/QXmWNvokC0EjwYZ/DvE5AXvdF+7U9muuQcgmDSB+nn7CX bdr/2HLR5AeW5EWVuZnL5W2gwrhzDp+xtwEZeytCsEM4krWFJXpiq171S U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BVBQCqaeJU/4YNJK1bgwZSWgTCMgqFcQKBGEMBAQEBAQF8hAwBAQEDAQEBAWsLBQsCAQgYLicLJQIEDgUbBIgGCA3OKAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEiwyEOjMHgxaBFAEEjziJN4EYjjeDPiKDbm+BRH8BAQE
X-IronPort-AV: E=Sophos;i="5.11,473,1422921600"; d="scan'208";a="406639044"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-8.cisco.com with ESMTP; 26 Mar 2015 16:06:04 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t2QG64c0014277 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Mar 2015 16:06:04 GMT
Received: from xmb-rcd-x03.cisco.com ([169.254.7.184]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Thu, 26 Mar 2015 11:06:04 -0500
From: "Max Pritikin (pritikin)" 
To: Michael Richardson 
Thread-Topic: [Anima] Ownership Concept
Thread-Index: AQHQZn+Wm4eAxWuLS02QOiRijuPZe50siH6AgAF6E4CAAT8YAIAAAnSA
Date: Thu, 26 Mar 2015 16:06:03 +0000
Message-ID: 
References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> <1D2369B2-4AEA-4479-8177-59BEB7DA0B6E@cisco.com> <7694.1427385388@sandelman.ca>
In-Reply-To: <7694.1427385388@sandelman.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.24.233.138]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: 
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, 26 Mar 2015 16:06:11 -0000

On Mar 26, 2015, at 9:56 AM, Michael Richardson  wro=
te:

>=20
> Max Pritikin (pritikin)  wrote:
>> b) Trusted Hardware Modules such that malware can not be installed on
>> devices or that such devices can be detected by the target domain.
>> This requires very specific and detailed hardware such as the TPM
>> provided by Trusted Computing Group and is, I think, out of scope for
>> IETF solutions.
>=20
> This is neither here nor there.
> Even without this trojan, it might be that I can still MITM the operator.

Agreed. There are plausible attacks against a TPM where the MiTM could =93c=
ontrol your actuators=94 effectively using the TPM as a remote hardware sec=
urity module.

Since I=92d be happy to declare this mitigation out of scope (it requires h=
ardware and I don=92t think IETF is in a position to mandate hardware!) I=
=92m certainly not going to argue against possible weaknesses. Like any sec=
urity space the TPM/NEA technology is progressing. It will get better but w=
e shouldn=92t assume it is ubiquitous nor infallible.

- max

> Getting the device to join my malicious network, instead of your network,=
 may
> be more than enough.  I can now control your actuators.  That might mean =
I've
> won, period.=20
>=20
> Maybe, I will provide a different device that appears to join your networ=
k,
> and after some on your part, troubleshooting, convince you that it's the
> right device, because after all, when you operate this "fake" device, the
> real valves actually do operate...=20
>=20
>> I think this does effect the protocol design.
>=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 Thu Mar 26 09:06: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 9CAF41A00F9 for ; Thu, 26 Mar 2015 09:06: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 bU9se36zhmvf for ; Thu, 26 Mar 2015 09:06:40 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8C871A87D7 for ; Thu, 26 Mar 2015 09:06:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=812; q=dns/txt; s=iport; t=1427385999; x=1428595599; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=mai61l94kV+AoHWObMzrVGJYm4EulLBCi7nfBJ9HB1A=; b=NQ5z/+BD6NQsbE6sijmoerNNOJSbd2Rf8HSquZE5LIFQ/O2wxSYDzfUj EqUPLpyQ2FeZ+dvUWEgPIIga3u9gdZz50Z7cxNDppOoBkSO50Q/bOIYdi EQYUhzHInU5CCPvyGpJwk4zH0QDG+X30ygR6prCDVwYg4qCKAuBz1PYHx s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ANBQD/LRRV/4UNJK1cgwZSWgTFIAqFdQKBWUwBAQEBAQF9hBQBAQEDAQEBATc0CxACAQgYHhAnCyUCBA4FGYgOCA3LEwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEiyiERTMHgxeBFgEEkFCJb5QtIoICHIFQb4FEfwEBAQ
X-IronPort-AV: E=Sophos;i="5.11,473,1422921600"; d="scan'208";a="406970701"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-4.cisco.com with ESMTP; 26 Mar 2015 16:06:39 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t2QG6dlo022833 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Mar 2015 16:06:39 GMT
Received: from xmb-rcd-x03.cisco.com ([169.254.7.184]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Thu, 26 Mar 2015 11:06:38 -0500
From: "Max Pritikin (pritikin)" 
To: Michael Richardson 
Thread-Topic: [Anima] Ownership Concept
Thread-Index: AQHQZn+Wm4eAxWuLS02QOiRijuPZe50siH6AgAErG4CAAORAgIAAqhaAgAACVoA=
Date: Thu, 26 Mar 2015 16:06:38 +0000
Message-ID: <39B5A883-8A4C-4B56-B0A7-4DE5D31A5F5A@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>
In-Reply-To: <7912.1427385447@sandelman.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.24.233.138]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <9B6C576EF966CB4C819900F4CA828CE1@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "Hedanping \(Ana\)" , "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, 26 Mar 2015 16:06:43 -0000

On Mar 26, 2015, at 9:57 AM, Michael Richardson  wro=
te:

>=20
> Hedanping (Ana)  wrote:
>> I agree that ownership is important in life-cycle consideration, but I
>> believe it belongs to higher security level that impacts the
>> interaction or manipulation between NEs or between NEs and owner.
>=20
> I strongly disagree.
> Ownership is fundamental.  No other interaction makes sense until you
> establish ownership.

+1

Well and strongly said.=20

- max

>=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 Thu Mar 26 09:35: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 49F1B1A9046 for ; Thu, 26 Mar 2015 09:35:55 -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 mPBjoryHl2if for ; Thu, 26 Mar 2015 09:35:54 -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 AD5DF1A8851 for ; Thu, 26 Mar 2015 09:35:53 -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 BUE19627; Thu, 26 Mar 2015 16:35:52 +0000 (GMT)
Received: from SZXEML428-HUB.china.huawei.com (10.82.67.183) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 26 Mar 2015 16:35:51 +0000
Received: from szxeml557-mbs.china.huawei.com ([169.254.6.131]) by szxeml428-hub.china.huawei.com ([10.82.67.183]) with mapi id 14.03.0158.001; Fri, 27 Mar 2015 00:35:46 +0800
From: "Hedanping (Ana)" 
To: Michael Richardson , "anima@ietf.org" 
Thread-Topic: [Anima] Ownership Concept
Thread-Index: AQHQZn+XTQng45mwMk+HZqqnogMqdJ0rrpGAgAErGoCAAWoPYIAAJEeAgACJpQA=
Date: Thu, 26 Mar 2015 16:35:45 +0000
Message-ID: <77FA386512F0D748BC7C02C36EB1106D95700F@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>
In-Reply-To: <7912.1427385447@sandelman.ca>
Accept-Language: en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.158.218]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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, 26 Mar 2015 16:35:55 -0000

Hi Michael,
  > -----Original Message-----
  > From: mcr@sandelman.ca [mailto:mcr@sandelman.ca] On Behalf Of Michael
  > Richardson
  > Sent: Thursday, March 26, 2015 11:57 PM
  > To: anima@ietf.org
  > Cc: Hedanping (Ana)
  > Subject: Re: [Anima] Ownership Concept
  >=20
  >=20
  > Hedanping (Ana)  wrote:
  >     > I agree that ownership is important in life-cycle consideration, =
but I
  >     > believe it belongs to higher security level that impacts the
  >     > interaction or manipulation between NEs or between NEs and owner.
  >=20
  > I strongly disagree.
  > Ownership is fundamental.  No other interaction makes sense until you
  > establish ownership.
  >=20
I don't think there is any problem that devices belong to different owners =
can join the same network securely and make necessary networking configurat=
ion.
Normally devices don't need to know each other's ownership until they reall=
y need interaction... What I mean is that ownership doesn't affect secure n=
etworking.
It doesn't mean that ownership is not fundamental for application level sec=
urity. From my point of view, it is very important, especially in iot cases=
.

Regards,
Ana=20
  >=20
  > --
  > Michael Richardson , Sandelman Software Works
  > -=3D IPv6 IoT consulting =3D-
  >=20
  >=20


From nobody Thu Mar 26 10:10: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 3A9DF1A88E0 for ; Thu, 26 Mar 2015 10:10:40 -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 pk-9g0e6B6ZB for ; Thu, 26 Mar 2015 10:10:30 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13A631A885A for ; Thu, 26 Mar 2015 10:10:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2460; q=dns/txt; s=iport; t=1427389824; x=1428599424; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Odo7UHVSfPQMiZutRkvQOUZPYK23hkDDUB4rVEMtVjM=; b=GX1UvlBTB9+EPJs6L4G3pDZxDuhoe5A3XbRGsTsKZgis3NG2uXmaoUU9 6lAd8zViyzH7c2125XG4+s8SCTfE+rk4/S9nQkL5kxc4OsNJhb4U0uqb1 7vYc8RRnIfGEf+9byUxe94Far2KQtFBojBVs7daxLAWgLrcSincmYEGX7 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AOBQDkPBRV/4gNJK1SCoMGUloExSEKhXUCgVtMAQEBAQEBfYQUAQEBAwEBAQFrCwUHBAIBCBEEAQEBJwcnCxQJCAIEDgUZiA4IDctNAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLKIQcKTMHBoMRgRYFkFCJb5QtIoNub4EEJBx/AQEB
X-IronPort-AV: E=Sophos;i="5.11,473,1422921600"; d="scan'208";a="403806290"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-9.cisco.com with ESMTP; 26 Mar 2015 17:10:24 +0000
Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t2QHANj4008001 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Mar 2015 17:10:23 GMT
Received: from xmb-rcd-x03.cisco.com ([169.254.7.184]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Thu, 26 Mar 2015 12:10:23 -0500
From: "Max Pritikin (pritikin)" 
To: "Hedanping (Ana)" 
Thread-Topic: [Anima] Ownership Concept
Thread-Index: AQHQZn+Wm4eAxWuLS02QOiRijuPZe50siH6AgAErG4CAAORAgIAAqhaAgAAKs4CAAAlUAA==
Date: Thu, 26 Mar 2015 17:10:21 +0000
Message-ID: <1F85BE1D-44A3-420A-8852-A4BA0DE213AC@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>
In-Reply-To: <77FA386512F0D748BC7C02C36EB1106D95700F@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.233.138]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <3DEC59225B8929429463D3A328BB2A28@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: Thu, 26 Mar 2015 17:10:40 -0000

On Mar 26, 2015, at 10:35 AM, Hedanping (Ana)  wr=
ote:

> Hi Michael,
>> -----Original Message-----
>> From: mcr@sandelman.ca [mailto:mcr@sandelman.ca] On Behalf Of Michael
>> Richardson
>> Sent: Thursday, March 26, 2015 11:57 PM
>> To: anima@ietf.org
>> Cc: Hedanping (Ana)
>> Subject: Re: [Anima] Ownership Concept
>>=20
>>=20
>> Hedanping (Ana)  wrote:
>>> I agree that ownership is important in life-cycle consideration, but I
>>> believe it belongs to higher security level that impacts the
>>> interaction or manipulation between NEs or between NEs and owner.
>>=20
>> I strongly disagree.
>> Ownership is fundamental.  No other interaction makes sense until you
>> establish ownership.
>>=20
> I don't think there is any problem that devices belong to different owner=
s can join the same network securely and make necessary networking configur=
ation.

Hmm. What do we mean by =93ownership=94?=20

I=92d work backward form the slang term =93pwn=94, as in: Mallory has pwned=
 that device!
At one level the =93owner=94 of a device is whomever has complete control o=
ver it.=20

We care very strongly who this is. (Namely that is isn=92t Mallory).=20

I don=92t think its possible to track and identify the correct owner via sa=
les channel security, which is my primary concern about the =93ownership va=
lidation=94 approach taken in the netconf draft. The MASA approach cares st=
rongly about providing logs about entities that have =93owned=94 the device=
 without requiring that any central source actually know who those entities=
 are. Meaning that I think it is sufficient to know that somebody =93pwned=
=94 it but I don=92t think it is necessary to know the authenticated name o=
f the pwner.=20

- max

> Normally devices don't need to know each other's ownership until they rea=
lly need interaction... What I mean is that ownership doesn't affect secure=
 networking.
> It doesn't mean that ownership is not fundamental for application level s=
ecurity. From my point of view, it is very important, especially in iot cas=
es.
>=20
> Regards,
> Ana=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 Mar 26 11:59: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 374461A8792 for ; Thu, 26 Mar 2015 11:59:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.911
X-Spam-Level: 
X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 yrD7v8VN205B for ; Thu, 26 Mar 2015 11:59:30 -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 555A31A901D for ; Thu, 26 Mar 2015 11:59:30 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id EE61620421 for ; Thu, 26 Mar 2015 15:09:27 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 58BA063B76; Thu, 26 Mar 2015 14:59:29 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 393E563731 for ; Thu, 26 Mar 2015 14:59:29 -0400 (EDT)
From: Michael Richardson 
To: "anima\@ietf.org" 
In-Reply-To: <3C8F19F4-54E7-48E5-AD62-A2300E946C4E@cisco.com>
References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> <5512DE41.6030209@gmail.com> <20150325170646.GB31979@cisco.com> <5512F839.6080502@gmail.com> <20150325184552.GC31979@cisco.com> <551305C4.9030001@gmail.com> <20150325200758.GD31979@cisco.com> <3C8F19F4-54E7-48E5-AD62-A2300E946C4E@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: Thu, 26 Mar 2015 18:59:32 -0000

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Max Pritikin (pritikin)  wrote:
    > I don=E2=80=99t understand how one can expect the backend to be total=
ly
    > =E2=80=9Coptional=E2=80=9D since the device doesn=E2=80=99t know if i=
t should be optional or
    > not. The best I think we can do is make the backend =E2=80=9Cno decis=
ion=E2=80=9D and
    > =E2=80=9Cair gap compliant=E2=80=9D. But if the device itself is will=
ing to make the
    > back end optional thats like saying that the end device has a trivial
    > downgrade attack.

I have read this thread.
Unfortunately, I missed the discussion at the session, as I had to present =
in
6lo at that time.

I don't see a conflict between MASA and no-MASA.  Both are valid, legitimate
security models, and business models.

In the certificate based ownership mechanism (I hesitate to call it a
protocol), that I envision, the MASA function defends against certain kinds
of attacks, and enables other kinds of attacks.

A MASA may be operated by either a vendor or their supply chain delegate.
As such, it is subject to various attacks: National Security letters,
takeovers (friendly and hostile), etc.  The existence of the MASA provides
a way to detect, or prevent, transfers from one owner to another.  Some
device claim mechanisms may include knowledge of a pre-shared (symmetric)
key (such as might come from a QRcode on the packaging).  That key, if
disclosed in the supply chain, can enable logical device theft.

A MASA could also in some cases be operated by a sophisticated end user.
How the trust relationship to do so is setup depends upon some details that
need to be worked out, but not here.

Solutions without a MASA have the advantage that MASA do not need to be
available.  This isn't just about network "availability", but also about
business continuity.  A device that sits in a warehouse for 20 years should
not have to depend the company that made it still existing at the same
address. (I saw a closet full of Nortel Meridian spare parts last week...)

Solutions without a MASA enable the end owner to decide how/when to
resell/transfer the device to another owner. This is a transaction that the
MASA can prevent.  (Reselling things is business as usual for some, and the=
ft
to other vendors)  The solution I describe at:
  https://mailarchive.ietf.org/arch/msg/6tisch-security/2kObJLkLlhuI-HU9s5y=
qfRm0n00

has a potential flaw: a previous owner, and any supplier in the supply chain
could assert their ownership certificate again, and steal the device "back"
From=20the end user.  This happens if either you do not replace the 802.1AR
certificates with locally significant certificates.  (If you merely augment
the 1AR with a LDevID, then the originally UDevID may be still useable)
This may be a "feature" --- it means that you can call up the guy who sold
you the device, and get their help to "reset your password".

In the scenario that I describe above, using 1AR certificates with an
extension like I describe at
          http://datatracker.ietf.org/doc/draft-richardson-6tisch-idevid-ce=
rt/

one can operate this online or offline. The certificate could be shipped
with the device when you buy it.  It could also be generated online from a
MASA-type device based upon a one-time token that you provide to the MASA
device (along with the public key you want to have bound).
It could be that the work in ACME applies as well here.

I suggest that a virtual interim meeting would be appropriate soon.

=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)

iQEVAwUBVRRXDoCLcPvd0N1lAQI1iwf/XguqqLW9iRAb99tfUtrlI/vB9zyFS2Yg
rBBygNNlCd3vaKvQ1wapvW/J1ek+KwpVTBbOKYI9DvkHGCjXJbo4krB7gA1DD31t
bCX1nPtNLn6jW+aWmtMynG3gu/uUiUZVqks/MxrpintlwElWYhvNo2k+IBIuiwCz
Zfv2zJVi+JcsRpBqNRNXl0fvcrJoKeqsRx1CxGGfS5hrIpM2qATalZsc+lrkMMJL
bgSxwc8xxLdsaGfjtP9ncsSxHDTVYTiNWAIjMeeHNhhUpBmiZ2N8NfK8Ua9f95hd
CJT6CXGBat1gFm2J8xyG+OB9DPaqpuioAlTuDyOa9g3dcG2DF8D1pQ==
=Q4bl
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Thu Mar 26 12:18: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 F17EC1A019B for ; Thu, 26 Mar 2015 12:18:19 -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 BgfuzXixBlKN for ; Thu, 26 Mar 2015 12:18:18 -0700 (PDT)
Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::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 32D4D1B2CE6 for ; Thu, 26 Mar 2015 12:18:13 -0700 (PDT)
Received: by wiaa2 with SMTP id a2so1586367wia.0 for ; Thu, 26 Mar 2015 12:18: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:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=yJShaICbKFcWZQ9jvV5jOe4AjcTGyfYkoh11NeBhLxo=; b=De6J4j5Y0QMp1VdnxqYy36uiY21rvDd2ResGlT/1Ferm4+NPCWBobWpcK+zfdw1Vk0 6rMVKvTOYXsCk2vlC4eV+IAXf7yzyAFiB4XE4Fon3edun68DM34R+oEfGxDue62Co4s+ bxRpnjBuaB3OXZjrIUI/49H1KpbbJctqlHRBzo6PLxOHyfsTBzcVtfYxGsDBHPoYeISB 3+cdWqMalXvNSHzZ2FGRomIXr9JQhAqRLT6kFVqWPTFFH/ABlT+wZz3IILJDkzD/e2v8 OAnC396kcfy8JWBjuKz3uJsZ17yN9fgMiPvnGVlRt1ylsUerNHd8IzmjxooMcih+cjWh k3SA==
X-Received: by 10.180.208.46 with SMTP id mb14mr11095141wic.31.1427397492023;  Thu, 26 Mar 2015 12:18:12 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:176:28cc:dc4c:9703:6781? ([2001:67c:370:176:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id q10sm9647235wjr.41.2015.03.26.12.18.10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Mar 2015 12:18:11 -0700 (PDT)
Message-ID: <55145B7D.9020207@gmail.com>
Date: Fri, 27 Mar 2015 08:18:21 +1300
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.5.0
MIME-Version: 1.0
To: "Hedanping (Ana)" ,  "Max Pritikin (pritikin)" 
References:  <5512E15D.4050508@gmail.com> <16CEC515-094C-4192-BE96-A96368F72CC3@cisco.com> <77FA386512F0D748BC7C02C36EB1106D956D21@szxeml557-mbs.china.huawei.com> <5513F864.1090308@gmail.com> <77FA386512F0D748BC7C02C36EB1106D956F43@szxeml557-mbs.china.huawei.com>
In-Reply-To: <77FA386512F0D748BC7C02C36EB1106D956F43@szxeml557-mbs.china.huawei.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "anima@ietf.org" , Mikael Abrahamsson 
Subject: Re: [Anima] interface towards vendors
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, 26 Mar 2015 19:18:20 -0000

On 27/03/2015 04:59, Hedanping (Ana) wrote:
> Hi Brian,
> 
>   > -----Original Message-----
>   > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E
>   > Carpenter
>   > Sent: Thursday, March 26, 2015 8:16 PM
>   > To: Hedanping (Ana); Max Pritikin (pritikin)
>   > Cc: anima@ietf.org; Mikael Abrahamsson
>   > Subject: Re: [Anima] interface towards vendors
>   > 
>   > Hi Ana,
>   > On 26/03/2015 18:16, Hedanping (Ana) wrote:
>   > > Hi Max,
>   > >   > -----Original Message-----
>   > >   > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Max
>   > Pritikin
>   > >   > (pritikin)
>   > >   > Sent: Thursday, March 26, 2015 7:55 AM
>   > >   > To: Brian E Carpenter
>   > >   > Cc: anima@ietf.org; Mikael Abrahamsson
>   > >   > Subject: Re: [Anima] interface towards vendors
>   > >   >
>   > >
>   > >   > Something like, the device indicates which of these options are
>   > supported:
>   > >   > 	a) prove you own me (required: vendors to track this plus vendor
>   > cloud
>   > >   > service)
>   > >
>   > > It is ownership issue, and I believe it belongs to higher level security rather
>   > than devices securely joins the network.
>   > >
>   > >   > 	b) i'll prove i'm not corrupted (required: NEA hardware)
>   > >
>   > > How about firmware signature by vendor?
>   > >   > 	c) prove this event is logged (required: vendor neutral cloud service)
>   > And
>   > >   > the "trust relay" reacts accordingly?
>   > >
>   > > Why should the device care about this information?
>   > >
>   > > Besides, why is the domain concept needed if any one of the above
>   > mentioned options are supported?
>   > 
>   > The set of devices permitted to perform autonomic configuration in a
>   > network must be limited to devices within the network, and also they must
>   > be able to verify that peer autonomic nodes are also in the same network.
>   > The Device ID and Domain ID both need to be cryptographically
>   > authenticated for this. That's why we need registration *within* the domain.
>   > Actually that is much more important for Anima that ownership.
>   > 
> Domain ID sounds like network ID to me. 

More or less, except that we can have a precise definition of "Domain"
but "network" can mean almost any scope.

> Do we really need the centralized manner to let registrar assign the domain ID to a joining device?

Yes, because a node needs to make assertions like "I am {Node ID} in {Domain ID}"
and sign it with a private key who public key is in a cert from the CA in {Domain ID}.

   Brian

> But I do agree that in some scenarios, it would be better if the registration can be realized locally. The solution should not limit users' option: The registrar can either download device lists/credential material from vendor or be configured locally. 
> 
> Ana
> 
>  
>   >     Brian
>   > 
>   > >
>   > > Regards,
>   > > Ana
>   > >   >
>   > >   > - max
>   > >   >
>   > >   > >
>   > >   > >    Brian
>   > >   > >
>   > >   > > _______________________________________________
>   > >   > > 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
>   > >
>   > 
>   > _______________________________________________
>   > Anima mailing list
>   > Anima@ietf.org
>   > https://www.ietf.org/mailman/listinfo/anima
> .
> 


From nobody Thu Mar 26 14:09: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 1A3C91B2F28 for ; Thu, 26 Mar 2015 14:09:30 -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 NoFOEVtFLQuf for ; Thu, 26 Mar 2015 14:09:21 -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 F004D1B2F34 for ; Thu, 26 Mar 2015 14:09:20 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 9D889200A3; Thu, 26 Mar 2015 17:19:18 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id C9B3463B76; Thu, 26 Mar 2015 17:09:19 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id AA81E63731; Thu, 26 Mar 2015 17:09:19 -0400 (EDT)
From: Michael Richardson 
To: "Hedanping \(Ana\)" 
In-Reply-To: <77FA386512F0D748BC7C02C36EB1106D95700F@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>
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: Thu, 26 Mar 2015 21:09:30 -0000

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable


Hedanping (Ana)  wrote:
    >> I strongly disagree.
    >> Ownership is fundamental.  No other interaction makes sense until you
    >> establish ownership.

    > I don't think there is any problem that devices belong to different
    > owners can join the same network securely and make necessary networki=
ng
    > configuration.

That's a very surprising thing that you say.
And I want to understand what it is that you mean.
Are you saying for instance that two operators at some common place could
pull their configuration down from an available public wifi (netconf-style)
or 3G network.=20=20=20

But, I don't see how an operator of a network can tolerate having a device =
owned
by another operator inside the core of their network.
I wonder if the word "owner" is being mis-understood.

An operator receives some crates of equipment from a variety of vendors.
They take it out of the boxes, and plug things together (or in the case of
wireless equipment, they "unplug", I guess).  Today, the equipment gets its'
initial configuration either by having a serial console plugged in, or more
commonly now, the equipment iether runs a dhcp client or a dhcp server
(possibly on a custome wifi ESSID), and someone connects to it with a laptop
and HTTPS. (Clicks through the certigficate is not valid warning...)

But, this takes trained personnel.  If the equipment is connected together
via some long wire (a cross-country dark fiber), then shipping people to bo=
th
ends is expensive and annoying.



    > Normally devices don't need to know each other's ownership until they
    > really need interaction... What I mean is that ownership doesn't affe=
ct
    > secure networking.

I am looking for example/reason why two devices would be plugged together, =
if
not so that they would interact.
=20=20=20=20


=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)

iQEVAwUBVRR1eoCLcPvd0N1lAQI7RggAwxLV5r7BesysADrEw89k5jxhTe1iJd09
VrW0mkYbsaKj1li42i7FezhmYEUj/Y/xEwws2FBxZ0l44ZbCj1q5JdfWMX+TToI1
h4x3DhY3F0/jjkoV5iHfA9wKX9PPjmmIdKKnnMBcRF8WOZoEEpFrWmGBGsmAa1en
jzJRhw+vuybRhKpe0/idNmNVnySnsdqgyLPgW895ie+GIbRESiPBJt1SKNr+y5xF
o3BuFnIQrL/GZyv6OHfc7OOMoY7CXUMmwUTsjDhi8Rq4lGQY8Q+K9VoasNlocy7Q
cv0weX9KDXvYhCkHThm0dMe2Tpk1ZdABaqcOCxraCy2fG5EmeKSb8Q==
=C4gg
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Thu Mar 26 14:19: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 BD04E1B2F30 for ; Thu, 26 Mar 2015 14:19:28 -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 xSXy5M5Kbpn3 for ; Thu, 26 Mar 2015 14:19:27 -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 470C71B2F1F for ; Thu, 26 Mar 2015 14:19:27 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5E32F200A3 for ; Thu, 26 Mar 2015 17:29:25 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 8CF4563B76; Thu, 26 Mar 2015 17:19:26 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 7367763731 for ; Thu, 26 Mar 2015 17:19:26 -0400 (EDT)
From: Michael Richardson 
To: "anima\@ietf.org" 
In-Reply-To: <1F85BE1D-44A3-420A-8852-A4BA0DE213AC@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>
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, 26 Mar 2015 21:19:28 -0000

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Max Pritikin (pritikin)  wrote:
    > I don=E2=80=99t think its possible to track and identify the correct =
owner via
    > sales channel security, which is my primary concern about the
    > =E2=80=9Cownership validation=E2=80=9D approach taken in the netconf =
draft. The MASA
    > approach cares strongly about providing logs about entities that have
    > =E2=80=9Cowned=E2=80=9D the device without requiring that any central=
 source actually
    > know who those entities are. Meaning that I think it is sufficient to
    > know that somebody =E2=80=9Cpwned=E2=80=9D it but I don=E2=80=99t thi=
nk it is necessary to know
    > the authenticated name of the pwner.

Which document are you talking about?
Can you comment on whether the MASA would be selected by the device, by the
vendor, or by the operator?  Is there a competitive market for providing the
MASA service?

I had previously assumed that the MASA would be operated by some entity in
the supply chain of the device.  Probably the vendor, but as has been
discussed, it could also be delegated to VARs, and even into parts of the
customer (I imagine some piece of .mil might run one for all of the US
military.  I was looking for the name of that entity, found:
http://en.wikipedia.org/wiki/Military_acquisition and gave up)

But, if there are more than one place to find this log, how do I know that
I've looked in all the right places?


=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)

iQEVAwUBVRR32oCLcPvd0N1lAQI27AgAs1zo6AGW00zhbmtO5o6hKY08ThOhkvkP
LXgibO3Q+N/ig9n/XcSZCGBDvnoVy4Ufd2oHVEYc3TyLz90gMb0O3NF0ijeorqsL
uMCXdDXNEL48uQg8Mw8631u8nvRgxcXDNm51iIrxEHceGND2S8Ec9sHAT5j0VuVh
ljWelCg2UzLIRIcVDd0mQq8mJNQLqqpvO1PHdiDBmyLyXOujKcWx/JPgZzW19a32
B8OqhJzpT8YLnPHk9FV/7yztG3V9c5qD3s1atHtIoXufhixDEw9Sb+tpkHi8dI/A
0Wajcnw+40BqXo57KpZNcoZf8qR0GFaNvwLslJ1GDIGPTdPXncFE5A==
=+l8D
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Thu Mar 26 15:23: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 7DC171A0366 for ; Thu, 26 Mar 2015 15:23:46 -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 AGs1Uuf5dx0A for ; Thu, 26 Mar 2015 15:23:45 -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 9CDE51A016C for ; Thu, 26 Mar 2015 15:23:44 -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 BUE38100; Thu, 26 Mar 2015 22:23:43 +0000 (GMT)
Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 26 Mar 2015 22:23:42 +0000
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.209]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Fri, 27 Mar 2015 06:23:37 +0800
From: Sheng Jiang 
To: Michael Richardson , "anima@ietf.org" 
Thread-Topic: time choosing of virtual interim meeting//RE: [Anima] Ownership Concept
Thread-Index: AQHQaBEAAY0GFvcYUU2VrRaYjn4Xcw==
Date: Thu, 26 Mar 2015 22:23:37 +0000
Message-ID: <5D36713D8A4E7348A7E10DF7437A4B925F4C730B@NKGEML512-MBS.china.huawei.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.148.145]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Cc: "anima-chairs@tools.ietf.org" 
Subject: [Anima] time choosing of virtual interim meeting//RE: 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, 26 Mar 2015 22:23:46 -0000

Michael> I suggest that a virtual interim meeting would be appropriate soon=
.=0A=
=0A=
This is certainly possible. The chairs are considering it.=0A=
=0A=
However, the IETF rules request at least two week notice for virtual interi=
m meeting. So it cannot happen very soon. Meanwhile, the dynamic discussion=
 in the mail list may make great progress.=0A=
=0A=
One important preparation towards a virtual interim meeting is to choose a =
good time that would be suitable for most of participators globally. If the=
re are conflicts, we need to share the pain of time different by switching =
various times among meetings.=0A=
=0A=
So, let's assume we will have a virtual interim meeting that is dedicated f=
or bootstrap relevant discussion in two or three week time. Could everyone =
who is interested to participate replies to chairs your time zone with your=
 name, like the below example? The chairs would try our best to choose a ti=
me that suits most of people who notify the chairs the willingness of parti=
cipate.=0A=
=0A=
CST (China Standard Time), UTC/GMT+8 Hours, Sheng Jiang=0A=
=0A=
Best regards,=0A=
=0A=
Sheng=0A=


From nobody Thu Mar 26 16:09:21 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 BA4671A1A82 for ; Thu, 26 Mar 2015 16:09:20 -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 j3mt15brt0MJ for ; Thu, 26 Mar 2015 16:09:17 -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 8B88A1A1A7D for ; Thu, 26 Mar 2015 16:09:16 -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 BUE40082; Thu, 26 Mar 2015 23:09:15 +0000 (GMT)
Received: from SZXEML431-HUB.china.huawei.com (10.82.67.208) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 26 Mar 2015 23:09:14 +0000
Received: from szxeml557-mbs.china.huawei.com ([169.254.6.131]) by szxeml431-hub.china.huawei.com ([10.82.67.208]) with mapi id 14.03.0158.001; Fri, 27 Mar 2015 07:09:05 +0800
From: "Hedanping (Ana)" 
To: "anima@ietf.org" 
Thread-Topic: owner categories
Thread-Index: AdBoDoQhFjsXvFi1TCWi/GRAiBAkjv//gTQAgAAGcAD//3IJUA==
Date: Thu, 26 Mar 2015 23:09:06 +0000
Message-ID: <77FA386512F0D748BC7C02C36EB1106D9573C4@szxeml557-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: zh-CN
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.147.22]
Content-Type: multipart/mixed; boundary="_004_77FA386512F0D748BC7C02C36EB1106D9573C4szxeml557mbschina_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: [Anima] owner categories
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, 26 Mar 2015 23:09:20 -0000

--_004_77FA386512F0D748BC7C02C36EB1106D9573C4szxeml557mbschina_
Content-Type: multipart/alternative;
	boundary="_000_77FA386512F0D748BC7C02C36EB1106D9573C4szxeml557mbschina_"

--_000_77FA386512F0D748BC7C02C36EB1106D9573C4szxeml557mbschina_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I forward what has been discussed in 6lo.
I like this categorizing approach. I think in anima we need to clarify whic=
h owners do we care about during security bootstrapping

Regards,
Ana

From: 6tisch [mailto:6tisch-bounces@ietf.org] On Behalf Of Robert Moskowitz
Sent: Friday, March 27, 2015 6:37 AM
To: Rene Struik; Samita Chakrabarti; 6lo@ietf.org; 6tisch@ietf.org
Subject: Re: [6tisch] [6lo] Tonight's 6lo informal security discussion

When we were doing IEEE 802.1AE, we said this very tightly:

MAC (layer 2) security addresses the risks and liablities of the network ow=
ner.
IP (layer 3) security addresses the risks and liablities of the system owne=
r.
Transport/Session (layers 4/5) security addresses the risks and liablities =
of the application owner.
Data security addresses the risks and liablities of the data owner.

We WILL be doing more than one of the above.
On 03/26/2015 05:14 PM, Rene Struik wrote:
Dear colleagues:

I posted some material on difference in potential security objectives for i=
nfrastructure security and for application security to the Anima mailing li=
st this morning (11.26am EDT) and that may be of interest to our 6l0 discus=
sion tonight as well, esp. since Samita's email suggested focus on network =
access.

Weblink to this email:
http://www.ietf.org/mail-archive/web/anima/current/msg00864.html

Excerpt{
Security policy and trust model
The main objectives of network security are to provide for infrastructure s=
ecurity and application security. Infrastructure security deals with contro=
lling admission to networks. The objective here is to restrict access to sc=
arce network resources to authorized resources only, such as to ensure prop=
er bandwidth allocation, protection of commands (such as those regulating n=
etwork membership and exchange of status information), and, e.g., power dra=
in savings. Application security deals with controlling access to actual in=
formation. The objective here is to restrict access to information shared b=
etween members of a group of network devices to precisely these group membe=
rs, such as to prevent external parties from learning the contents of excha=
nged messages and from modifying message traffic or injecting their own mes=
sages in an undetected way.

Infrastructure security and application security have different underlying =
trust requirements. With infrastructure security, the network owner may hav=
e an interest in restricting access to his network to privileged devices on=
ly, based on specific criteria, such as device subscription to the network =
or charging for airtime/bandwidth, whereas network devices might not care w=
ho the actual network coordinator is, as long as access to bandwidth is sat=
isfactory. With application security, devices that exchange information may=
 have a vested interest in keeping their communications private, also from =
the network owner. Both types of security involve the management of groups =
of devices, either for controlling network membership (by a network coordin=
ator) or for restricting access to information to specific groups (by a sec=
urity manager).
}

Best regards, Rene

On 3/26/2015 5:53 PM, Samita Chakrabarti wrote:
Many folks were asking about the scope and content of the discussion.

Here are some thoughts and suggestions:


Scope:  Network level Access security and authentication
                                For 6lo Networks (multi-constrained L2 tech=
nologies)

Possible discussion items:

1.            L3 Solutions desirable for network access [ since we deal wit=
h multi-L2 Technologies]
2.            Dynamic Key/id distribution ? [ useful for L2-L3-APP layer SA=
?]
3.            Router Advertisement authentication?
4.            Join/Leave network
5.            Mobility across 6lowpan/6lo subnets or networks?
6.            Analysis of security work done in 6Tisch and how can we separ=
ate the Tsch-independent part for common usage on 6lo?


Time: 7p-8p Room: Pavillion (Terrace level)


See you there!

-Gabriel, Samita and James





_______________________________________________

6lo mailing list

6lo@ietf.org

https://www.ietf.org/mailman/listinfo/6lo




--

email: rstruik.ext@gmail.com | Skype: rstruik

cell: +1 (647) 867-5658 | US: +1 (415) 690-7363




_______________________________________________

6tisch mailing list

6tisch@ietf.org

https://www.ietf.org/mailman/listinfo/6tisch


--_000_77FA386512F0D748BC7C02C36EB1106D9573C4szxeml557mbschina_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











I forward what has been discussed in 6lo.


I like this categorizing approach. I think in anima we need to cl=
arify which owners do we care about during security bootstrapping


 


Regards,


Ana


 








From:=
 6tisch [mailto:6tis=
ch-bounces@ietf.org]
On Behalf Of Robert Moskowitz

Sent: Friday, March 27, 2015 6:37 AM

To: Rene Struik; Samita Chakrabarti; 6lo@ietf.org; 6tisch@ietf.org
Subject: Re: [6tisch] [6lo] Tonight's 6lo informal security discussi=
on






 


=
When we were doing IEEE 802.1AE, we said this very tightly:



MAC (layer 2) security addresses the risks and liablities of the network ow=
ner.

IP (layer 3) security addresses the risks and liablities of the system owne=
r.

Transport/Session (layers 4/5) security addresses the risks and liablities =
of the application owner.

Data security addresses the risks and liablities of the data owner.



We WILL be doing more than one of the above.




On 03/26/2015 05:14 PM, Rene St=
ruik wrote:








Dear colleagues:



I posted some material on difference in potential security objectives for i=
nfrastructure security and for application security to the Anima mailing li=
st this morning (11.26am EDT) and that may be of interest to our 6l0 discus=
sion tonight as well, esp. since
 Samita's email suggested focus on network access.



Weblink to this email:

http://www.ietf.org/mail-archive/web/anima/current/msg00864.html


Excerpt{ 

Security policy and trust model

The main objectives of network security are to provide for infrastructure s=
ecurity and application security. Infrastructure security deals with contro=
lling admission to networks. The objective here is to restrict access to sc=
arce network resources to authorized
 resources only, such as to ensure proper bandwidth allocation, protection =
of commands (such as those regulating network membership and exchange of st=
atus information), and, e.g., power drain savings. Application security dea=
ls with controlling access to actual
 information. The objective here is to restrict access to information share=
d between members of a group of network devices to precisely these group me=
mbers, such as to prevent external parties from learning the contents of ex=
changed messages and from modifying
 message traffic or injecting their own messages in an undetected way.




 =



Infrastructure security an=
d application security have different underlying trust requirements. With i=
nfrastructure security, the network owner may have an interest
 in restricting access to his network to privileged devices only, based on =
specific criteria, such as device subscription to the network or charging f=
or airtime/bandwidth, whereas network devices might not care who the actual=
 network coordinator is, as long
 as access to bandwidth is satisfactory. With application security, devices=
 that exchange information may have a vested interest in keeping their comm=
unications private, also from the network owner. Both types of security inv=
olve the management of groups of
 devices, either for controlling network membership (by a network coordinat=
or) or for restricting access to information to specific groups (by a secur=
ity manager).

} =




Best regards, Rene



On 3/26/2015 5:53 PM, Samita Chakrabarti wrote:






Many folks were asking about th=
e scope and content of the discussion.


 


Here are some thoughts and sugg=
estions:


 


 


Scope:  Network level Acce=
ss security and authentication


     &=
nbsp;           &nbs=
p;            &=
nbsp; For 6lo Networks (multi-constrained L2 technologies)


 


Possible discussion items:=



 


1.     =
;       L3 Solutions desirable for network ac=
cess [ since we deal with multi-L2 Technologies]


2.     =
;       Dynamic Key/id distribution ? [ usefu=
l for L2-L3-APP layer SA?]


3.     =
;       Router Advertisement authentication?<=
o:p>


4.     =
;       Join/Leave network<=
/p>

5.     =
;       Mobility across 6lowpan/6lo subnets o=
r networks?


6.     =
;       Analysis of security work done in 6Ti=
sch and how can we separate the Tsch-independent part for common usage on 6=
lo?


 


 


Time: 7p-8p Room: Pavillion (Te=
rrace level)


 


 


See you there!


 


-Gabriel, Samita and James=



 











_______________________________________________


6lo mailing list


6lo@ietf.org<=
o:p>


https://www.ietf.org/mailman/listinfo/6lo













-- 


email: r=
struik.ext@gmail.com | Skype: rstruik


cell: +1 (647) 867-5658 | US: +1 (415) 69=
0-7363











_______________________________________________


6tisch mailing list


6tisch@ietf.or=
g


https://www.ietf.org/mailman/listinfo/6tisch<=
/pre>



 








--_000_77FA386512F0D748BC7C02C36EB1106D9573C4szxeml557mbschina_--

--_004_77FA386512F0D748BC7C02C36EB1106D9573C4szxeml557mbschina_
Content-Type: text/plain; name="ATT00001.txt"
Content-Description: ATT00001.txt
Content-Disposition: attachment; filename="ATT00001.txt"; size=133;
	creation-date="Thu, 26 Mar 2015 22:37:34 GMT";
	modification-date="Thu, 26 Mar 2015 22:37:34 GMT"
Content-ID: <367017F746D1A046B652D43976435A29@huawei.com>
Content-Transfer-Encoding: base64

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCjZ0aXNjaCBt
YWlsaW5nIGxpc3QNCjZ0aXNjaEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby82dGlzY2gNCg==

--_004_77FA386512F0D748BC7C02C36EB1106D9573C4szxeml557mbschina_--


From nobody Thu Mar 26 16:45: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 507731A6F3A for ; Thu, 26 Mar 2015 16:45:44 -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 jajpmwjZBEvI for ; Thu, 26 Mar 2015 16:45:42 -0700 (PDT)
Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::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 48E171A6F2A for ; Thu, 26 Mar 2015 16:45:42 -0700 (PDT)
Received: by obcjt1 with SMTP id jt1so58983734obc.2 for ; Thu, 26 Mar 2015 16:45:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=9GOggz1UPCmpECP04mEPrLRvWnJ5KLssj1rv+6wzp94=; b=UGdHGPx2e+OB1hZ20OURucprUlvAhlzV7ntdcNpJyYtz1dh6T9gi9Y0mimLKeW6yrr pdPyic40fsRIQyeh0MQmEvjsD9w/ekLiH6E+339gMNbMhcGrRWSWvhKKiTDlNJ9P5wKI EjfmqLXW+PZNJtg34ydTKx0QUglp64uPUqJ/sw45JwSOnQdpddxMuGbgBhpPeMWHn5ni e6jE0pBGrFmn+Esdlpz8XazXa8LPTvFTy2nqHe33ir+3tBc68NfmO2DQUpye1w5U6lzk 51PD6YpRu8ZhWPe2JvGjxXRnJ69divbBMARfu87EolQxbWB3u1LPK2+eVO942rMA0sPc 0Cdw==
MIME-Version: 1.0
X-Received: by 10.202.60.66 with SMTP id j63mr13319243oia.83.1427413541816; Thu, 26 Mar 2015 16:45:41 -0700 (PDT)
Sender: robert.cragie@gmail.com
Received: by 10.202.2.9 with HTTP; Thu, 26 Mar 2015 16:45:41 -0700 (PDT)
In-Reply-To: <1F85BE1D-44A3-420A-8852-A4BA0DE213AC@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>
Date: Thu, 26 Mar 2015 23:45:41 +0000
X-Google-Sender-Auth: iJGf8t79e6gt9NYUgxyAvpqEvOg
Message-ID: 
From: Robert Cragie 
To: "Max Pritikin (pritikin)" 
Content-Type: multipart/alternative; boundary=001a113cca3e1b8e6b0512399dce
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: Thu, 26 Mar 2015 23:45:44 -0000

--001a113cca3e1b8e6b0512399dce
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

This conversation is going around in circles as this was Hannes' original
question.

In my attempt to analyse the discussion, there are a number of points I
notice.

Firstly, the concept of MASA seems to be no more than an online whitelist
(using LDAP or something). 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 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.

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. A MASA makes no difference here, it's simply about validating
the trust chain of the domain certificate, surely? So I don't see issues
with pre-loading NE IDs/certs on the Registrar providing the domain
certificate chain is validated by the NE.

Robert



On 26 March 2015 at 17:10, Max Pritikin (pritikin) 
wrote:

>
> On Mar 26, 2015, at 10:35 AM, Hedanping (Ana) 
> wrote:
>
> > Hi Michael,
> >> -----Original Message-----
> >> From: mcr@sandelman.ca [mailto:mcr@sandelman.ca] On Behalf Of Michael
> >> Richardson
> >> Sent: Thursday, March 26, 2015 11:57 PM
> >> To: anima@ietf.org
> >> Cc: Hedanping (Ana)
> >> Subject: Re: [Anima] Ownership Concept
> >>
> >>
> >> Hedanping (Ana)  wrote:
> >>> I agree that ownership is important in life-cycle consideration, but =
I
> >>> believe it belongs to higher security level that impacts the
> >>> interaction or manipulation between NEs or between NEs and owner.
> >>
> >> I strongly disagree.
> >> Ownership is fundamental.  No other interaction makes sense until you
> >> establish ownership.
> >>
> > I don't think there is any problem that devices belong to different
> owners can join the same network securely and make necessary networking
> configuration.
>
> Hmm. What do we mean by =E2=80=9Cownership=E2=80=9D?
>
> I=E2=80=99d work backward form the slang term =E2=80=9Cpwn=E2=80=9D, as i=
n: Mallory has pwned that
> device!
> At one level the =E2=80=9Cowner=E2=80=9D of a device is whomever has comp=
lete control over
> it.
>
> We care very strongly who this is. (Namely that is isn=E2=80=99t Mallory)=
.
>
> I don=E2=80=99t think its possible to track and identify the correct owne=
r via
> sales channel security, which is my primary concern about the =E2=80=9Cow=
nership
> validation=E2=80=9D approach taken in the netconf draft. The MASA approac=
h cares
> strongly about providing logs about entities that have =E2=80=9Cowned=E2=
=80=9D the device
> without requiring that any central source actually know who those entitie=
s
> are. Meaning that I think it is sufficient to know that somebody =E2=80=
=9Cpwned=E2=80=9D it
> but I don=E2=80=99t think it is necessary to know the authenticated name =
of the
> pwner.
>
> - max
>
> > Normally devices don't need to know each other's ownership until they
> really need interaction... What I mean is that ownership doesn't affect
> secure networking.
> > It doesn't mean that ownership is not fundamental for application level
> security. From my point of view, it is very important, especially in iot
> cases.
> >
> > Regards,
> > Ana
> >>
> >> --
> >> Michael Richardson , Sandelman Software Works
> >> -=3D IPv6 IoT consulting =3D-
> >>
> >>
> >
> > _______________________________________________
> > 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
>

--001a113cca3e1b8e6b0512399dce
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


This conversation is going around in circles as this was H=
annes' original question.

In my attempt to analyse t=
he discussion, there are a number of points I notice.

<=
div>Firstly, the concept of MASA seems to be no more than an online whiteli=
st (using LDAP or something). There are certainly cases where I can see thi=
s being used but conceptually it is not much different to a whitelist on th=
e registrar. 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 real=
ly 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 publ=
ic keys relevant to the certificate chain.

Regardi=
ng the honeypot (Mallory) attack - the NE is going to find out it's a h=
oneypot as the honeypot will not be able to issue valid domain certificates=
. A MASA makes no difference here, it's simply about validating the tru=
st chain of the domain certificate, surely? So I don't see issues with =
pre-loading NE IDs/certs on the Registrar providing the domain certificate =
chain is validated by the NE.

Robert


On 26 March 2015 at 17:10, Max Pritikin (pritikin) <pritikin@c=
isco.com> wrote:


On Mar 26, 2015, at 10:35 AM, Hedanping (Ana) <ana.hedanping@huawei.com> wrote:



> Hi Michael,

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

>> From: mcr@sandelman.ca [ma=
ilto:mcr@sandelman.ca] On Behalf Of=
 Michael

>> Richardson

>> Sent: Thursday, March 26, 2015 11:57 PM

>> To: anima@ietf.org

>> Cc: Hedanping (Ana)

>> Subject: Re: [Anima] Ownership Concept

>>

>>

>> Hedanping (Ana) <an=
a.hedanping@huawei.com> wrote:

>>> I agree that ownership is important in life-cycle consideratio=
n, but I

>>> believe it belongs to higher security level that impacts the
>>> interaction or manipulation between NEs or between NEs and own=
er.

>>

>> I strongly disagree.

>> Ownership is fundamental.=C2=A0 No other interaction makes sense u=
ntil you

>> establish ownership.

>>

> I don't think there is any problem that devices belong to differen=
t owners can join the same network securely and make necessary networking c=
onfiguration.



Hmm. What do we mean by =E2=80=9Cownership=E2=80=9D?



I=E2=80=99d work backward form the slang term =E2=80=9Cpwn=E2=80=9D, as in:=
 Mallory has pwned that device!

At one level the =E2=80=9Cowner=E2=80=9D of a device is whomever has comple=
te control over it.



We care very strongly who this is. (Namely that is isn=E2=80=99t Mallory).<=
br>


I don=E2=80=99t think its possible to track and identify the correct owner =
via sales channel security, which is my primary concern about the =E2=80=9C=
ownership validation=E2=80=9D approach taken in the netconf draft. The MASA=
 approach cares strongly about providing logs about entities that have =E2=
=80=9Cowned=E2=80=9D the device without requiring that any central source a=
ctually know who those entities are. Meaning that I think it is sufficient =
to know that somebody =E2=80=9Cpwned=E2=80=9D it but I don=E2=80=99t think =
it is necessary to know the authenticated name of the pwner.



- max




> Normally devices don't need to know each other's ownership unt=
il they really need interaction... What I mean is that ownership doesn'=
t affect secure networking.

> It doesn't mean that ownership is not fundamental for application =
level security. From my point of view, it is very important, especially in =
iot cases.

>

> Regards,

> Ana

>>

>> --

>> Michael Richardson <=
mcr+IETF@sandelman.ca>, Sandelman Software Works

>> -=3D IPv6 IoT consulting =3D-

>>

>>

>

> _______________________________________________

> Anima mailing list

> Anima@ietf.org

> https://www.ietf.org/mailman/listinfo/anima



_______________________________________________

Anima mailing list

Anima@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/anima





--001a113cca3e1b8e6b0512399dce--


From nobody Thu Mar 26 18:14: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 BB76D1A039F for ; Thu, 26 Mar 2015 18:14:16 -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 rvEPdoHnhbkv for ; Thu, 26 Mar 2015 18:14:15 -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 860341A1A62 for ; Thu, 26 Mar 2015 18:14:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2611; q=dns/txt; s=iport; t=1427418855; x=1428628455; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Z0MzwYhBmxN+axuG/9G7DePZHZPKRm1N6Tm7M2BWW+E=; b=Mq/TPo1oPi7M/oAY2zDND+TZjpJElq/LMyOY6oCYrp4z+qPqtLdPKawb EyMpyBRQ+zMg7Y39fiL7Pchbwd+M3mP4EoEG/lHmdzz5EfPEl0poqlZwk hZYl44sefR2TBtTSKz/+vqVp+4QCvivEXxM/9xHeL4q1JpyDoIevC8/e+ U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AYBQCHrRRV/40NJK1SCoMGUlrFKgqFdQKBRUwBAQEBAQF9hBQBAQEDAQEBAWsLBQsCAQgYLicLJQIEDgWIJwgNzA0BAQEBAQEBAQEBAQEBAQEBAQEBAQEXiyiEHCkzB4MXgRYFkFCDb4YAi2SISSKDbm+BBCSBGwEBAQ
X-IronPort-AV: E=Sophos;i="5.11,476,1422921600"; d="scan'208";a="135829598"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-7.cisco.com with ESMTP; 27 Mar 2015 01:14:14 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t2R1ECE3005480 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Mar 2015 01:14:12 GMT
Received: from xmb-rcd-x03.cisco.com ([169.254.7.184]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Thu, 26 Mar 2015 20:14:12 -0500
From: "Max Pritikin (pritikin)" 
To: Michael Richardson 
Thread-Topic: [Anima] Ownership Concept
Thread-Index: AQHQZn+Wm4eAxWuLS02QOiRijuPZe50siH6AgAErG4CAAORAgIAAqhaAgAAKs4CAAAlUAIAARe8A///txpI=
Date: Fri, 27 Mar 2015 01:14:11 +0000
Message-ID: <5AD9C83C-2BA8-40AA-9801-01AF8C3550B1@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>, <9929.1427404766@sandelman.ca>
In-Reply-To: <9929.1427404766@sandelman.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="Windows-1252"
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, 27 Mar 2015 01:14:16 -0000

Inline,

> On Mar 26, 2015, at 3:19 PM, Michael Richardson  w=
rote:
>=20
>=20
> Max Pritikin (pritikin)  wrote:
>> I don=92t think its possible to track and identify the correct owner via
>> sales channel security, which is my primary concern about the
>> =93ownership validation=94 approach taken in the netconf draft. The MASA
>> approach cares strongly about providing logs about entities that have
>> =93owned=94 the device without requiring that any central source actuall=
y
>> know who those entities are. Meaning that I think it is sufficient to
>> know that somebody =93pwned=94 it but I don=92t think it is necessary to=
 know
>> the authenticated name of the pwner.
>=20
> Which document are you talking about?

The two bootstrapping docs being discussed: Pritikin-anima-bootstrapping-ke=
yinfrastructures (MASA concepts) and the netconf alternative (owner validat=
ion).=20

> Can you comment on whether the MASA would be selected by the device, by t=
he
> vendor, or by the operator?  Is there a competitive market for providing =
the
> MASA service?

The drafts assume vendor provides the cloud service for their devices. Beca=
use the MASA concept doesn't require sales channel integration it could be =
provided by a third party more easily.=20

I think there would be a market for 3rd party MASA servers that provide the=
 service for multiple manufacturers. I have not explored that as a business=
 case though.=20

> I had previously assumed that the MASA would be operated by some entity i=
n
> the supply chain of the device.  Probably the vendor, but as has been
> discussed, it could also be delegated to VARs, and even into parts of the
> customer (I imagine some piece of .mil might run one for all of the US
> military.  I was looking for the name of that entity, found:
> http://en.wikipedia.org/wiki/Military_acquisition and gave up)
>=20
> But, if there are more than one place to find this log, how do I know tha=
t
> I've looked in all the right places?

If consensus were to support more than just the vendor we'd have to signal =
the NE behavior (eg MASA servers it trusts) in a secure manor. Off the cuff=
 this could be embedded in the IDevID certificate similar to an AIA etc.=20

- max=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 Thu Mar 26 18:21: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 050941A88FC for ; Thu, 26 Mar 2015 18:21:30 -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 1M1G2jKs-y2C for ; Thu, 26 Mar 2015 18:21:24 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D24C1A88D9 for ; Thu, 26 Mar 2015 18:21:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12737; q=dns/txt; s=iport; t=1427419284; x=1428628884; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ZXifnjRw5nYWffpGPwX67YTaUxvpR7T1HEOOw3DPTMg=; b=gzyWcl2c0ZEy6lAbV3LzMw2cKeCDo9npp14a4DWGm9s9F8oZB1/FCLVr hgn73OwKJ86vlJX+H4u+EYexi/vgnpYl0eNC8lPlbOY/Eml198xL6PPH0 cgNF0dW8Eq7npCgXFV2PNvYybncfFFWeoWNVNlz7AJBEptkb2v9BCP81+ g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BWBQCqaeJU/5ldJa1RCoMGUlrCNgEJhXECgRhDAQEBAQEBfIQMAQEBAwEBAQFrCwUHBAIBCBEEAQEBJwcnCxQJCAIEDgUZiAwIDc4oAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLDIQRWAQHBoMQgRQFjziHPoF5gSiRZSKDbm+BBCSBGwEBAQ
X-IronPort-AV: E=Sophos;i="5.11,476,1422921600";  d="scan'208,217";a="406780670"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 27 Mar 2015 01:21:23 +0000
Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t2R1LN69026361 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Mar 2015 01:21:23 GMT
Received: from xmb-rcd-x03.cisco.com ([169.254.7.184]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Thu, 26 Mar 2015 20:21:23 -0500
From: "Max Pritikin (pritikin)" 
To: "" 
Thread-Topic: [Anima] Ownership Concept
Thread-Index: AQHQZn+Wm4eAxWuLS02QOiRijuPZe50siH6AgAErG4CAAORAgIAAqhaAgAAKs4CAAAlUAIAAbsyA///G6uQ=
Date: Fri, 27 Mar 2015 01:21:22 +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>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_DD32C1D9F5044D119C5D88C9354D6B56ciscocom_"
MIME-Version: 1.0
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
List-Id: Autonomic Networking Integrated Model and Approach 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Mar 2015 01:21:30 -0000

--_000_DD32C1D9F5044D119C5D88C9354D6B56ciscocom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Inlines,

On Mar 26, 2015, at 5:45 PM, Robert Cragie > wrote:

This conversation is going around in circles as this was Hannes' original q=
uestion.

In my attempt to analyse the discussion, there are a number of points I not=
ice.

Firstly, the concept of MASA seems to be no more than an online whitelist (=
using LDAP or something).

More appropriate is to think of the MASA as a 3rd entity logging events. It=
 is not itself a whitelist -- recall it can be implemented without making a=
ny decisions about who owns what. All whitelist belong in the Domain Regist=
rar, in my opinion.


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.

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 doma=
in public key, whether the MASA or the Registrar is authorised to issue dom=
ain certificates on behalf of the Domain CA and any other public keys relev=
ant to the certificate chain.

The MASA does not sign certs. All it ever does is assure, via the authoriza=
tion token, the NE that if it joins the domain this will be logged. That wa=
y Mallory can be detected by the real domain.

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 certifica=
tes.

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

A MASA makes no difference here, it's simply about validating the trust cha=
in of the domain certificate, surely?

Nope. See above.

- max

So I don't see issues with pre-loading NE IDs/certs on the Registrar provid=
ing the domain certificate chain is validated by the NE.

Robert



On 26 March 2015 at 17:10, Max Pritikin (pritikin) > wrote:

On Mar 26, 2015, at 10:35 AM, Hedanping (Ana) > wrote:

> Hi Michael,
>> -----Original Message-----
>> From: mcr@sandelman.ca [mailto:mcr@sandelman.ca=
] On Behalf Of Michael
>> Richardson
>> Sent: Thursday, March 26, 2015 11:57 PM
>> To: anima@ietf.org
>> Cc: Hedanping (Ana)
>> Subject: Re: [Anima] Ownership Concept
>>
>>
>> Hedanping (Ana) > wrote:
>>> I agree that ownership is important in life-cycle consideration, but I
>>> believe it belongs to higher security level that impacts the
>>> interaction or manipulation between NEs or between NEs and owner.
>>
>> I strongly disagree.
>> Ownership is fundamental.  No other interaction makes sense until you
>> establish ownership.
>>
> I don't think there is any problem that devices belong to different owner=
s can join the same network securely and make necessary networking configur=
ation.

Hmm. What do we mean by =93ownership=94?

I=92d work backward form the slang term =93pwn=94, as in: Mallory has pwned=
 that device!
At one level the =93owner=94 of a device is whomever has complete control o=
ver it.

We care very strongly who this is. (Namely that is isn=92t Mallory).

I don=92t think its possible to track and identify the correct owner via sa=
les channel security, which is my primary concern about the =93ownership va=
lidation=94 approach taken in the netconf draft. The MASA approach cares st=
rongly about providing logs about entities that have =93owned=94 the device=
 without requiring that any central source actually know who those entities=
 are. Meaning that I think it is sufficient to know that somebody =93pwned=
=94 it but I don=92t think it is necessary to know the authenticated name o=
f the pwner.

- max

> Normally devices don't need to know each other's ownership until they rea=
lly need interaction... What I mean is that ownership doesn't affect secure=
 networking.
> It doesn't mean that ownership is not fundamental for application level s=
ecurity. From my point of view, it is very important, especially in iot cas=
es.
>
> Regards,
> Ana
>>
>> --
>> Michael Richardson >, Sandelman Software Works
>> -=3D IPv6 IoT consulting =3D-
>>
>>
>
> _______________________________________________
> 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


--_000_DD32C1D9F5044D119C5D88C9354D6B56ciscocom_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable







Inlines,




On Mar 26, 2015, at 5:45 PM, Robert Cragie <robert.cragie@gridmerge.com> wrote:










This conversation is going around in circles as this was H=
annes' original question.






In my attempt to analyse the discussion, there are a number of points =
I notice.







Firstly, the concept of MASA seems to be no more than an online whitel=
ist (using LDAP or something).














More appropriate is to think of the MASA as a 3rd entity logging event=
s. It is not itself a whitelist -- recall it can be implemented without mak=
ing any decisions about who owns what. All whitelist belong in the Domain R=
egistrar, in my opinion. 















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














The registrar is owned and operated by the domain owner. The cloud ser=
vice is not. I argue MASA substantially simplifies the threat model. <=
/div>









The only other operation it seems to do is to sign the domain certific=
ate. But the registrar could also do this - so I guess this is really combi=
ning 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 cha=
in.













The MASA does not sign certs. All it ever does is assure, via the auth=
orization token, the NE that if it joins the domain this will be logged. Th=
at way Mallory can be detected by the real domain. 













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 cert=
ificates.














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










A MASA makes no difference here, it's simply about validating the trus=
t chain of the domain certificate, surely?














Nope. See above. 







- max 










So I don't see issues with pre-loading NE IDs/certs on the Registrar p=
roviding the domain certificate chain is validated by the NE.







Robert

















On 26 March 2015 at 17:10, Max Pritikin (pritiki=
n) 
<pritikin@cisco.=
com> wrote:





On Mar 26, 2015, at 10:35 AM, Hedanping (Ana) <ana.hedanping@huawei.com> wrote:



> Hi Michael,

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

>> From: mcr@sandelman.ca [ma=
ilto:mcr@sandelman.ca] On Behalf Of=
 Michael

>> Richardson

>> Sent: Thursday, March 26, 2015 11:57 PM

>> To: anima@ietf.org

>> Cc: Hedanping (Ana)

>> Subject: Re: [Anima] Ownership Concept

>>

>>

>> Hedanping (Ana) <an=
a.hedanping@huawei.com> wrote:

>>> I agree that ownership is important in life-cycle consideratio=
n, but I

>>> believe it belongs to higher security level that impacts the
>>> interaction or manipulation between NEs or between NEs and own=
er.

>>

>> I strongly disagree.

>> Ownership is fundamental.  No other interaction makes sense u=
ntil you

>> establish ownership.

>>

> I don't think there is any problem that devices belong to different ow=
ners can join the same network securely and make necessary networking confi=
guration.



Hmm. What do we mean by =93ownership=94?



I=92d work backward form the slang term =93pwn=94, as in: Mallory has pwned=
 that device!

At one level the =93owner=94 of a device is whomever has complete control o=
ver it.



We care very strongly who this is. (Namely that is isn=92t Mallory).



I don=92t think its possible to track and identify the correct owner via sa=
les channel security, which is my primary concern about the =93ownership va=
lidation=94 approach taken in the netconf draft. The MASA approach cares st=
rongly about providing logs about entities
 that have =93owned=94 the device without requiring that any central source=
 actually know who those entities are. Meaning that I think it is sufficien=
t to know that somebody =93pwned=94 it but I don=92t think it is necessary =
to know the authenticated name of the pwner.



- max







> Normally devices don't need to know each other's ownership until they =
really need interaction... What I mean is that ownership doesn't affect sec=
ure networking.

> It doesn't mean that ownership is not fundamental for application leve=
l security. From my point of view, it is very important, especially in iot =
cases.

>

> Regards,

> Ana

>>

>> --

>> Michael Richardson <=
mcr+IETF@sandelman.ca>, Sandelman Software Works

>> -=3D IPv6 IoT consulting =3D-

>>

>>

>

> _______________________________________________

> Anima mailing list

> Anima@ietf.org

> https://www.ietf.org/mailman/listinfo/anima



_______________________________________________

Anima mailing list

Anima@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/anima




















--_000_DD32C1D9F5044D119C5D88C9354D6B56ciscocom_--


From nobody Fri Mar 27 06:01: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 A584F1ACDBC for ; Fri, 27 Mar 2015 06:01:47 -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 9l9VYSqqLa3g for ; Fri, 27 Mar 2015 06:01:46 -0700 (PDT)
Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::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 633981ACDB6 for ; Fri, 27 Mar 2015 06:01:46 -0700 (PDT)
Received: by obvd1 with SMTP id d1so6420616obv.0 for ; Fri, 27 Mar 2015 06:01:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=FXKo+kmQvUqxR3OpadaiJtj7ZfeBtDKxCJ3aCFeGseo=; b=o+3/vG8cuog7UlmQnemptvKejVmX7XULyrHXc7ItkmUyemarPnhNMIdxZWizsojPTn 6ELg2i+wiyu4Ckk36oAXHk6VpqjjL+qb3SjmYyB2N/jQNh9fqM7ocYjErWkpZounpUj3 m1J8gI1hqCBxvJnUqYGSf8lC6J3c+f+ST0c9z3eIoVGlXdRh16eKwsV3kAAa8rNaNF61 YBXrRgfKFAty3liyUjZ8JNuT0tZxsRFe0HF6m05XFHORm2WReDw146/0bdlXVDH59tcj MJbdsARwW+ko4SMr0FzucQhTOh8F1m8LARsBS6Hrw3AXhh7ADq6pgUn8f8XVR3nrMuMr Drrw==
X-Received: by 10.60.120.36 with SMTP id kz4mr16248643oeb.47.1427461305961; Fri, 27 Mar 2015 06:01:45 -0700 (PDT)
Received: from [192.168.0.81] (rrcs-50-84-137-11.sw.biz.rr.com. [50.84.137.11]) by mx.google.com with ESMTPSA id du10sm963068obb.29.2015.03.27.06.01.45 for  (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Mar 2015 06:01:45 -0700 (PDT)
Message-ID: <551554B5.1010106@gmail.com>
Date: Fri, 27 Mar 2015 09:01:41 -0400
From: Rene Struik 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: "anima@ietf.org" 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [Anima] overarching comment on draft-pritikin-anima-bootstrapping-keyinfra-01
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, 27 Mar 2015 13:01:47 -0000

Dear colleagues:

I think this draft would benefit from a trust model (which is currently 
mentioned only as a TBD) and a more flashed-out security section (e.g., 
including detailed analysis of roles, authorization, etc., but also DoS 
attacks). Moreover, it would help to see some more detail on deployment 
models and a privacy section. I am happy to provide a careful review, 
after seeing this "meaty" material added.

Best regards, Rene

-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


From nobody Fri Mar 27 06:16: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 6A4A01ACDE3 for ; Fri, 27 Mar 2015 06:16:31 -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 MnhSIYyUcNwN for ; Fri, 27 Mar 2015 06:16:30 -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 29EB51ACDDB for ; Fri, 27 Mar 2015 06:16:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=880; q=dns/txt; s=iport; t=1427462191; x=1428671791; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=R33Nh7Jdbtw3JxdFSot0jFNmWZLPnFyx3vJ3e8oYyzc=; b=C1LEZ2EG0CyPZ3WScxNM4Nlm+mU5U20bgtb4yE8MVnT78D//syZPrFta m2apVVC3hQzko7hC5HK5sRPpJtLcdkFtCW0h45ZGEKrOYpgTdoH2/Wbl5 IiYQvwgvlN0uNDQCKRPXJy3RmyPu4b4bLreQ/5uJpT4hllFZLNj8SnIlW A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ANBQAzVxVV/4oNJK1ZA4MGUlrFMwqFdQKBQEwBAQEBAQF9hBQBAQEDAQEBATc0CwULAgEIDgoeECEGCyUCBA4FiBsDCQgNxjkNhUMBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIsogkeBTxEBHSMQBxGDBoEWBY0ygyWII4FNjgaGKyKCMoE8b4ELgTgBAQE
X-IronPort-AV: E=Sophos;i="5.11,478,1422921600"; d="scan'208";a="407161215"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-3.cisco.com with ESMTP; 27 Mar 2015 13:16:30 +0000
Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t2RDGTAK027804 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Mar 2015 13:16:29 GMT
Received: from xmb-rcd-x03.cisco.com ([169.254.7.184]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Fri, 27 Mar 2015 08:16:29 -0500
From: "Max Pritikin (pritikin)" 
To: Rene Struik 
Thread-Topic: [Anima] overarching comment on draft-pritikin-anima-bootstrapping-keyinfra-01
Thread-Index: AQHQaI5D8bRZ19ZpP0+BXT93GUes9Z0wT1st
Date: Fri, 27 Mar 2015 13:16:28 +0000
Message-ID: <2D1FECCC-34F5-4B17-8586-956D8BF223FD@cisco.com>
References: <551554B5.1010106@gmail.com>
In-Reply-To: <551554B5.1010106@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "anima@ietf.org" 
Subject: Re: [Anima] overarching comment on draft-pritikin-anima-bootstrapping-keyinfra-01
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, 27 Mar 2015 13:16:31 -0000

Thanks Rene,  these are good suggestions for any draft!

- max

> On Mar 27, 2015, at 7:02 AM, Rene Struik  wrote:
>=20
> Dear colleagues:
>=20
> I think this draft would benefit from a trust model (which is currently m=
entioned only as a TBD) and a more flashed-out security section (e.g., incl=
uding detailed analysis of roles, authorization, etc., but also DoS attacks=
). Moreover, it would help to see some more detail on deployment models and=
 a privacy section. I am happy to provide a careful review, after seeing th=
is "meaty" material added.
>=20
> Best regards, Rene
>=20
> --=20
> email: rstruik.ext@gmail.com | Skype: rstruik
> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
>=20
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima


From nobody Fri Mar 27 07:00: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 807D41ACE61 for ; Fri, 27 Mar 2015 07:00:52 -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 AClagRTAQasV for ; Fri, 27 Mar 2015 07:00:49 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0762.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::762]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 937D81ACE8C for ; Fri, 27 Mar 2015 07:00:41 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.125.19; Fri, 27 Mar 2015 14:00:20 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.86]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.86]) with mapi id 15.01.0125.002; Fri, 27 Mar 2015 14:00:20 +0000
From: Kent Watsen 
To: "Max Pritikin (pritikin)" , Michael Richardson 
Thread-Topic: [Anima] Ownership Concept
Thread-Index: AQHQZn+WmG3Pkztd4UiFW+kyT70z+Z0sNK2AgAErGoCAAORAgIAAqhaAgAAKtICAAAmrgIAARZcAgABBl4CAAII7AA==
Date: Fri, 27 Mar 2015 14:00:20 +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> <9929.1427404766@sandelman.ca> <5AD9C83C-2BA8-40AA-9801-01AF8C3550B1@cisco.com>
In-Reply-To: <5AD9C83C-2BA8-40AA-9801-01AF8C3550B1@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.14]
authentication-results: cisco.com; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(46102003)(106116001)(77156002)(83506001)(36756003)(87936001)(93886004)(2656002)(86362001)(76176999)(50986999)(54356999)(66066001)(2900100001)(102836002)(92566002)(62966003)(2950100001)(99286002)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; 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:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; 
x-forefront-prvs: 0528942FD8
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2697F3C52B18A24C867F9ADE2B09EB77@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2015 14:00:20.4113 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457
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, 27 Mar 2015 14:00:52 -0000

>The drafts assume vendor provides the cloud service for their devices.
>Because the MASA concept doesn't require sales channel integration it
>could be provided by a third party more easily.

The Netconf ZeroTouch approach could also support 3rd-parties - a vendor
delegates a signing key to the 3rd-party and let them define their own
vetting policy.  The issue, of course, is that this key could be used to
sign data for anybody's equipment and lead to a simple attack.


Regarding use-cases for bootstrapping, there might be four that matter:

  1. Operator's CPE device plugging into operator's network

  2. Device plugging into a 3rd-party network (franchise chains)
  3. Device plugging into campus/enterprise network
  4. Device plugging into a home network
  

Some characterizations:

  - 1 and 4 are needed because we need something easy for grandma
  - 1, 2 and 3 are high-touch sales events, where validating ownership is
possible
  - 4 may allow for degraded or no security
  - all should allow for a normal boot when no bootstrapping is possible


Switching gears, last night I had an idea that might apply here.  That
both the device and the network could enforce a minimum security level.
For instance, a device could be manufactured with an requirement that any
network it's plugged into provides at least a gold-level security and/or
bootstrapping process.  Likewise, a  network could be configured with a
requirement that any device plugged into it implements at least
bronze-level security and/or bootstrapping process.   I'm still searching
for how this might work, but it seems intuitive and roughly approximates
the concerns...



Thanks,
Kent



From nobody Fri Mar 27 07:29: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 B44781A1A0B for ; Fri, 27 Mar 2015 07:29:03 -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 scN7-RlpD9Eg for ; Fri, 27 Mar 2015 07:29:01 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0764.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::764]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 898921A897E for ; Fri, 27 Mar 2015 07:29:01 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.125.19; Fri, 27 Mar 2015 14:28:44 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.86]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.86]) with mapi id 15.01.0125.002; Fri, 27 Mar 2015 14:28:44 +0000
From: Kent Watsen 
To: Kent Watsen , "Max Pritikin (pritikin)" , Michael Richardson 
Thread-Topic: [Anima] Ownership Concept
Thread-Index: AQHQZn+WmG3Pkztd4UiFW+kyT70z+Z0sNK2AgAErGoCAAORAgIAAqhaAgAAKtICAAAmrgIAARZcAgABBl4CAAII7AIAAB/AA
Date: Fri, 27 Mar 2015 14:28:44 +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> <9929.1427404766@sandelman.ca> <5AD9C83C-2BA8-40AA-9801-01AF8C3550B1@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
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.14]
authentication-results: juniper.net; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459;
x-microsoft-antispam-prvs: 
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(51704005)(46102003)(76176999)(50986999)(122556002)(62966003)(86362001)(54356999)(36756003)(102836002)(106116001)(66066001)(2900100001)(99286002)(93886004)(2656002)(77156002)(92566002)(87936001)(2950100001)(83506001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; 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:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; 
x-forefront-prvs: 0528942FD8
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4C590C092F3354489F2C498782FAFE5D@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2015 14:28:44.1335 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459
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, 27 Mar 2015 14:29:03 -0000

>Regarding use-cases for bootstrapping, there might be four that matter:
>
>  1. Operator's CPE device plugging into operator's network
>  2. Device plugging into a 3rd-party network (franchise chains)
>  3. Device plugging into campus/enterprise network
>  4. Device plugging into a home network
>  


On second thought, #4 may not matter, at least not from a security
perspective.  This as it seems improbable that a consumer would go through
the trouble of staging bootstrapping infrastructure in a way that would
ensure security.  The whole idea with #4 is to dumb it down, heaping
complexity on top is the opposite of what's desired.

FWIW, 1-3 are high-touch in another way too, in that the rightful owner is
willing to go through a staging process, so long as a negates the need for
the installer to have to be a skilled technician.

Thanks,
Kent


From nobody Fri Mar 27 08:32: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 15A4C1AD1D5 for ; Fri, 27 Mar 2015 08:32:06 -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 xQfqoG75kWRX for ; Fri, 27 Mar 2015 08:32:04 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DDFE1AD0CD for ; Fri, 27 Mar 2015 08:31:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3370; q=dns/txt; s=iport; t=1427470300; x=1428679900; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=9o3UyQHAtzHFSOI3Utdl7DfxZulv7CELX3nBoKAp3+0=; b=OCOXmg4EwEKTZcAn5IZrBd8QEi/SN3v1lle+p5bVO+vbexak7Oue3Dny XQ6GzMNtBvlmWgT5rzmCTzsJzyd0JUGlY3kZNqwp642RcEaeSnVfrRI9K /lPo2jl+EbEEMN8wlVeQE3XjlU8mq8fEyYwejWnITegSxkQsrl7zAxWFj I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BRBQCqaeJU/5BdJa1bgwaBLMgxAoEYQwEBAQEBAXyEDAEBAQMBOj8FCwIBCA4KHhAyJQIEDgWIJQjONQEBAQEBAQEBAQEBAQEBAQEBAQEBGIsMhDozB4MWgRQFjziJN5MNIoNub4EEJIEbAQEB
X-IronPort-AV: E=Sophos;i="5.11,479,1422921600"; d="scan'208";a="406930606"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-8.cisco.com with ESMTP; 27 Mar 2015 15:31:39 +0000
Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t2RFVcmj025536 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Mar 2015 15:31:39 GMT
Received: from xmb-rcd-x03.cisco.com ([169.254.7.184]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Fri, 27 Mar 2015 10:31:38 -0500
From: "Max Pritikin (pritikin)" 
To: Kent Watsen 
Thread-Topic: [Anima] Ownership Concept
Thread-Index: AQHQZn+Wm4eAxWuLS02QOiRijuPZe50siH6AgAErG4CAAORAgIAAqhaAgAAKs4CAAAlUAIAARe8A///txpKAASngAP//xbH5
Date: Fri, 27 Mar 2015 15:31:38 +0000
Message-ID: <632B7B5D-D299-4F1B-B110-8F3524AA20B1@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> <9929.1427404766@sandelman.ca> <5AD9C83C-2BA8-40AA-9801-01AF8C3550B1@cisco.com>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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, 27 Mar 2015 15:32:06 -0000

Inline,

> On Mar 27, 2015, at 8:00 AM, Kent Watsen  wrote:
>=20
>=20
>=20
>> The drafts assume vendor provides the cloud service for their devices.
>> Because the MASA concept doesn't require sales channel integration it
>> could be provided by a third party more easily.
>=20
> The Netconf ZeroTouch approach could also support 3rd-parties - a vendor
> delegates a signing key to the 3rd-party and let them define their own
> vetting policy.  The issue, of course, is that this key could be used to
> sign data for anybody's equipment and lead to a simple attack.

I think the difference is that netconf netconf zerotouch requires the cloud=
 to know who owns which device. This means integration into the sales chann=
el. MASA doesn't require that - so it would be easier for a third party to =
provide the ongoing service.=20

> Regarding use-cases for bootstrapping, there might be four that matter:
>=20
>  1. Operator's CPE device plugging into operator's network
>=20
>  2. Device plugging into a 3rd-party network (franchise chains)
>  3. Device plugging into campus/enterprise network
>  4. Device plugging into a home network
>  
>=20
> Some characterizations:
>=20
>  - 1 and 4 are needed because we need something easy for grandma
>  - 1, 2 and 3 are high-touch sales events, where validating ownership is
> possible
>  - 4 may allow for degraded or no security

I see this supported by having the MASA be a dumb logger and by the registr=
ar not checking the logs. This allows one network to "not care" about secur=
ity without forcing everybody else to be insecure. (Or forcing venders to s=
hip multiple "secure" vs "insecure" versions of their product.=20

>  - all should allow for a normal boot when no bootstrapping is possible

By normal I take you to mean locally configured. I think in the long run th=
is won't exist: because all devices will ship without local console ports -=
 they'll all use wireless which needs a security model. But I understand we=
 are not there yet.=20

> Switching gears, last night I had an idea that might apply here.  That
> both the device and the network could enforce a minimum security level.
> For instance, a device could be manufactured with an requirement that any
> network it's plugged into provides at least a gold-level security and/or
> bootstrapping process.  Likewise, a  network could be configured with a
> requirement that any device plugged into it implements at least
> bronze-level security and/or bootstrapping process.   I'm still searching
> for how this might work, but it seems intuitive and roughly approximates
> the concerns...

As noted previously -- I think the device needs a fixed behavior and the do=
main needs to make the decision about the local security level. I had thoug=
ht the vendor/cloud behavior could be fixed and always the same (no decisio=
ns, MASA approach) but to support air gaps I provide two levels of security=
 on the MASA authorization token: nonced and nonceless responses. The chara=
cteristics of the protocol would be improved if nonceless responses were of=
 the netconf zero touch ownership validation variety.=20

Hmm. That would be an interesting blending of the two approaches.=20


- max

>=20
>=20
>=20
> Thanks,
> Kent
>=20
>=20


From nobody Fri Mar 27 17:15: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 01CE71A03A0 for ; Fri, 27 Mar 2015 17:15: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 7y1vhPb8ey_3 for ; Fri, 27 Mar 2015 17:15: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 E81A71A0399 for ; Fri, 27 Mar 2015 17:15:50 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUF44835; Sat, 28 Mar 2015 00:15:49 +0000 (GMT)
Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 28 Mar 2015 00:15:48 +0000
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.209]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Sat, 28 Mar 2015 08:15:43 +0800
From: Sheng Jiang 
To: "anima@ietf.org" 
Thread-Topic: ANIMA Proceeding in IETF 92
Thread-Index: AQHQaOxTIRLLqFsSPkirH9DcIdYH9w==
Date: Sat, 28 Mar 2015 00:15:42 +0000
Message-ID: <5D36713D8A4E7348A7E10DF7437A4B925F4CAD5C@NKGEML512-MBS.china.huawei.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.150.191]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Cc: "anima-chairs@tools.ietf.org" 
Subject: [Anima] ANIMA Proceeding in 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: Sat, 28 Mar 2015 00:15:54 -0000

Hi, all,

All the materials of ANIMA meetings in IETF 92 can be accessed online:

https://www.ietf.org/proceedings/92/anima.html

https://datatracker.ietf.org/meeting/92/materials.html#anima

The chairs are working on the WG official minutes, which will be uploaded l=
ater of next week.

Best regards,

Sheng + Toerless=


From nobody Sat Mar 28 16:52: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 27A701A00C2 for ; Sat, 28 Mar 2015 16:52:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.423
X-Spam-Level: *
X-Spam-Status: No, score=1.423 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 yWJQs99kBq63 for ; Sat, 28 Mar 2015 16:52:25 -0700 (PDT)
Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::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 7749F1A00BE for ; Sat, 28 Mar 2015 16:52:25 -0700 (PDT)
Received: by obcjt1 with SMTP id jt1so96100581obc.2 for ; Sat, 28 Mar 2015 16:52:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=vFwn8/Q1fP63YlJyVBcMFtmKYSVT7Ca6Vbux7Ao69fk=; b=iXP/vuh3YWjBfjEeUEslLrhttEaZiuw8kpw/Sj/WjQXx1MFQqKBVZyWnutX3wnc9Pj edOzyeXrkvW4Bq+Y1Iqcf6uselb5pw6eBV3sYZflIMcYLKFo/QtSJiwa/qfjbSKHCbVL fhzCV1O4/60dgDWlpyaVggFKO4Mma8ApHR+D71n7XBBWXyjY1CJsGwNm1R10N3CSd7j4 AXyx1WUK0NNKVFqDvvFaKkUxwkDepcc/qtheYbmIXb9KqfqZGI6g14HNqzVMDxgHQhRC AoKrP54SeLwhlrQgxCmqij8Tv5rkh6bs4Y5+5vJ8uMSXKFkVv3S3KH1ou7LQtVWf2ViF 5Rmg==
MIME-Version: 1.0
X-Received: by 10.182.72.169 with SMTP id e9mr21577226obv.23.1427586744963; Sat, 28 Mar 2015 16:52:24 -0700 (PDT)
Sender: robert.cragie@gmail.com
Received: by 10.202.2.9 with HTTP; Sat, 28 Mar 2015 16:52:24 -0700 (PDT)
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>  
Date: Sat, 28 Mar 2015 23:52:24 +0000
X-Google-Sender-Auth: xIcDrGIhjaGwi6y-rCpl1nCuFNA
Message-ID: 
From: Robert Cragie 
To: "Max Pritikin (pritikin)" 
Content-Type: multipart/alternative; boundary=001a11c2eeead1d75e051261f0d4
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: Sat, 28 Mar 2015 23:52:28 -0000

--001a11c2eeead1d75e051261f0d4
Content-Type: text/plain; charset=UTF-8

Perhaps I was a bit premature in sending the original e-mail and have taken
the time to read definitions and design goals draft and the reference model
draft (on which I will post comments shortly)

Not having participated fully in the anima inner sanctum, I don't find the
description of the MASA at all clear (it's just a "tbd"
in draft-behringer-anima-reference-model). However, I have read between the
lines somewhat and I think I have a clearer picture.

Comments inline.

Robert

On 27 March 2015 at 01:21, Max Pritikin (pritikin) 
wrote:

>  Inlines,
>
> On Mar 26, 2015, at 5:45 PM, Robert Cragie 
> wrote:
>
>   This conversation is going around in circles as this was Hannes'
> original question.
>
>  In my attempt to analyse the discussion, there are a number of points I
> notice.
>
>  Firstly, the concept of MASA seems to be no more than an online
> whitelist (using LDAP or something).
>
>
>  More appropriate is to think of the MASA as a 3rd entity logging events.
> It is not itself a whitelist -- recall it can be implemented without making
> any decisions about who owns what. All whitelist belong in the Domain
> Registrar, in my opinion.
>

The "automated orchestrator" hints at that behaviour ("or in real time
for each new device"). I can't see that just logging will achieve that
much, unless the aim is to alert someone (unclear - user, vendor?) that an
anomalous event has occurred.

>
>
>   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
whitelisting, and the difference in the domain authority and the 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). I see the Factory CA signs the
IDevID - that seems to be what is shown in Figure 1 and I can see it would
be the Registrar (on behalf of the domain CA) signing any domain
certificate (or it may just pass it on?). However, the MASA is shown in the
same dotted line as the Factory CA - which I would assume means "the
Vendor". So what is the difference between the Factory CA and the MASA? If
the MASA is separate, what is the trust relationship between Factory CA and
MASA? Chain to the same common CA? I guess the question I am asking is how
can the new element trust the MASA unless it has been pre-programmed with
its public key as part of its factory-configured material - is that the
intent?


. All it ever does is assure, via the authorization token, the NE that if
> it joins the domain this will be logged. That way Mallory can be detected
> by the real domain.
>


So please explain the authorisation token in more detail and what leads to
its generation. This is a bit more than just logging.

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. For this to
work, the NE would have to send details of the registrar it has received,
presumably relayed by the registrar itself (OCSP)? 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. 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.


>
>
>   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 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?

>
>   A MASA makes no difference here, it's simply about validating the trust
> chain of the domain certificate, surely?
>
>
>  Nope. See above.
>

There are different models here which need to be elucidated. A whole
load more information needs to go into the document.

--001a11c2eeead1d75e051261f0d4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Perhaps I was a bit premature in sending the original e-ma=
il and have taken the time to read definitions and design goals draft and t=
he reference model draft (on which I will post comments shortly)

Not having participated fully in the anima inner sanctum, I don=
9;t find the description of the MASA at all clear (it's just a "tb=
d" in=C2=A0draft-behringer-anima-reference-model). However, I have rea=
d between the lines somewhat and I think I have a clearer picture.

Comments inline.

Robert

On 27 March 2015 at 01:=
21, Max Pritikin (pritikin) <pritikin@cisco.com> wrote:
=








Inlines,




On Mar 26, 2015, at 5:45 PM, Robert Cragie <robert.cragie@gridmerge.com> wr=
ote:










This conversation is going around in circles as this was H=
annes' original question.






In my attempt to analyse the discussion, there are a number of points =
I notice.







Firstly, the concept of MASA seems to be no more than an online whitel=
ist (using LDAP or something).














More appropriate is to think of the MASA as a 3rd entity loggin=
g events. It is not itself a whitelist -- recall it can be implemented with=
out making any decisions about who owns what. All whitelist belong in the D=
omain Registrar, in my opinion.=C2=A0

<RCC>The "automated orchestrator" hints at that beha=
viour ("or in real time for each new device"). I can't see th=
at just logging will achieve that much, unless the aim is to alert someone =
(unclear - user, vendor?) that an anomalous event has occurred.</RCC>=
=C2=A0















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














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

<RCC>I see now tha=
t the purpose of the MASA service is not online whitelisting, and the diffe=
rence in the domain authority and the MASA.</RCC>










The only other operation it seems to do is to sign the domain certific=
ate. But the registrar could also do this - so I guess this is really combi=
ning 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 cha=
in.













The MASA does not sign certs

<=
/div>
<RCC>So why is it called a "signing authority" th=
en? Confusing. I can see it may sign authorisation tokes (see later). I see=
 the Factory CA signs the IDevID - that seems to be what is shown in Figure=
 1 and I can see it would be the Registrar (on behalf of the domain CA) sig=
ning any domain certificate (or it may just pass it on?). However, the MASA=
 is shown in the same dotted line as the Factory CA - which I would assume =
means "the Vendor". So what is the difference between the Factory=
 CA and the MASA? If the MASA is separate, what is the trust relationship b=
etween Factory CA and MASA? Chain to the same common CA? I guess the questi=
on I am asking is how can the new element trust the MASA unless it has been=
 pre-programmed with its public key as part of its factory-configured mater=
ial - is that the intent?</RCC>


. All it ever does is assure, via the=
 authorization token, the NE that if it joins the domain this will be logge=
d. That way Mallory can be detected by the real domain.

<RCC>
So please explain the author=
isation token in more detail and what leads to its generation. This is a bi=
t more than just logging.

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. For this to work, the NE would have to send deta=
ils of the registrar it has received, presumably relayed by the registrar i=
tself (OCSP)? 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. If a honeypot tried =
to use a honeypot MASA, it wouldn't have the private key to sign the au=
thorisation 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 thre=
at model.
</RCC>
=C2=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 certificat=
e so I don't believe this is correct.=C2=A0

<RCC>It could if it were pre-provisioned with the Re=
gistrar's public key and Domain CA public key. As you point out, in Sec=
tion 2, "As a service offering the MASA can incorporate many of the bo=
otstrapping elements (such as the Registrar and the Domain CA) into the ove=
rall service." So surely in this case, there is no separation of CAs?&=
lt;/RCC>=C2=A0










A MASA makes no difference here, it's simply about validating the =
trust chain of the domain certificate, surely?














Nope. See above.=C2=A0

<=
div><RCC>There are different models here which need to be elucidated.=
 A whole load more information needs to go into the document.</RCC>



--001a11c2eeead1d75e051261f0d4--


From nobody Mon Mar 30 10:03:22 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 523561A890B for ; Mon, 30 Mar 2015 10:03:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.11
X-Spam-Level: 
X-Spam-Status: No, score=-13.11 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 k7ePhwEqU1Xh for ; Mon, 30 Mar 2015 10:03:19 -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 15D621A87EB for ; Mon, 30 Mar 2015 10:03:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21484; q=dns/txt; s=iport; t=1427734999; x=1428944599; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kf4NBgVIsSe+WxpAz73e07sz8sniafWfvUvcxdRl0Ak=; b=cSvzzi8swclx+FiL6w8m8ge6pqMW910GcjKnd4D7ccPE5LnkO2xT66mG umxebSgMd1mk/L/gkhQvT1CiOZR3yQc9iIJVREE1NvnvtYOg70dCUU2jx yUfnUN+WnYSekK5R7pOoF8p7EtSc1amRbfL0McdElJevro9EYpjeEdSlu s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ArBQD1gBlV/5pdJa1SCoMGgS4EyywCgTlMAQEBAQEBfYQVAQEEcgcQAgEIPwcyFBECBA4FiC/LMwEBAQEBAQEBAQEBAQEBAQEBAQEBAReLKYQcJTcHAoMVgRYFjk6CDoYXgV2CAIEcEYMhglqNDSKDbm+BBCQcfwEBAQ
X-IronPort-AV: E=Sophos;i="5.11,494,1422921600";  d="scan'208,217";a="136680270"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-7.cisco.com with ESMTP; 30 Mar 2015 17:03:18 +0000
Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t2UH3Iol018629 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Mar 2015 17:03:18 GMT
Received: from xmb-rcd-x03.cisco.com ([169.254.7.184]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Mon, 30 Mar 2015 12:03:17 -0500
From: "Max Pritikin (pritikin)" 
To: "robert.cragie@gridmerge.com" 
Thread-Topic: [Anima] Ownership Concept
Thread-Index: AQHQZn+Wm4eAxWuLS02QOiRijuPZe50siH6AgAErG4CAAORAgIAAqhaAgAAKs4CAAAlUAIAAbsyA///G6uSAA1+gAIACsoiA
Date: Mon, 30 Mar 2015 17:03:17 +0000
Message-ID: <247ADDB2-807D-4AB5-A814-58381A929EB5@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>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.24.217.243]
Content-Type: multipart/alternative; boundary="_000_247ADDB2807D4AB5A81458381A929EB5ciscocom_"
MIME-Version: 1.0
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
List-Id: Autonomic Networking Integrated Model and Approach 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Mar 2015 17:03:22 -0000

--_000_247ADDB2807D4AB5A81458381A929EB5ciscocom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable


On Mar 28, 2015, at 5:52 PM, Robert Cragie > wrote:

Perhaps I was a bit premature in sending the original e-mail and have taken=
 the time to read definitions and design goals draft and the reference mode=
l draft (on which I will post comments shortly)

Not having participated fully in the anima inner sanctum, I don't find the =
description of the MASA at all clear (it's just a "tbd" in draft-behringer-=
anima-reference-model). However, I have read between the lines somewhat and=
 I think I have a clearer picture.

Thanks for the feedback.


Comments inline.

responses inline,


Robert

On 27 March 2015 at 01:21, Max Pritikin (pritikin) > wrote:
Inlines,

On Mar 26, 2015, at 5:45 PM, Robert Cragie > wrote:

This conversation is going around in circles as this was Hannes' original q=
uestion.

In my attempt to analyse the discussion, there are a number of points I not=
ice.

Firstly, the concept of MASA seems to be no more than an online whitelist (=
using LDAP or something).

More appropriate is to think of the MASA as a 3rd entity logging events. It=
 is not itself a whitelist -- recall it can be implemented without making a=
ny decisions about who owns what. All whitelist belong in the Domain Regist=
rar, in my opinion.

The "automated orchestrator" hints at that behaviour ("or in real time=
 for each new device"). I can't see that just logging will achieve that muc=
h, unless the aim is to alert someone (unclear - user, vendor?) that an ano=
malous event has occurred.

The Registrar is =93alerted=94 in that when it decides if a device is to jo=
in the domain it checks the logs. If there is an anomalous event the Regist=
rar makes appropriate decisions based on domain policy. This allows the dom=
ain to scale up or down the security as it requires.



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 whitelist=
ing, and the difference in the domain authority and the 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 doma=
in public key, whether the MASA or the Registrar is authorised to issue dom=
ain certificates on behalf of the Domain CA and any other public keys relev=
ant to the certificate chain.

The MASA does not sign certs

So why is it called a "signing authority" then? Confusing. I can see i=
t may sign authorisation tokes (see later).

Understood. It signs the =93proof of logging=94 things we called =93authori=
zation tokens=94. Please feel free to suggest terms that resonate.

I see the Factory CA signs the IDevID - that seems to be what is shown in F=
igure 1 and I can see it would be the Registrar (on behalf of the domain CA=
) signing any domain certificate (or it may just pass it on?). However, the=
 MASA is shown in the same dotted line as the Factory CA - which I would as=
sume means "the Vendor". So what is the difference between the Factory CA a=
nd the MASA? If the MASA is separate, what is the trust relationship betwee=
n Factory CA and MASA? Chain to the same common CA?

Specifically the vendor trusts the MASA trust anchor and installs it on the=
 devices. The simplest approach is to re-use the IDevID trust anchor but fo=
r 3rd party MASA=92s one could install a set of MASA trust anchors. Ultimat=
ely trust anchors are just public keys with policy about how/what they are =
trusted for.

I guess the question I am asking is how can the new element trust the MASA =
unless it has been pre-programmed with its public key as part of its factor=
y-configured material - is that the intent?

yes.

. All it ever does is assure, via the authorization token, the NE that if i=
t joins the domain this will be logged. That way Mallory can be detected by=
 the real domain.


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.

s4.3.2: Registrar only allows the device to join the domain if the devices =
history (e.g. the log information) doesn=92t show it has joined Mallory=92s=
 domain. Or, if the registar doesn=92t care, maybe it just doesn=92t check.

s4.3.3: Registrar MUST claim the device, obtaining an authorization token a=
nd ensuring a log entry is generated, in order to get the device to trust i=
t.

As far as I can see (and please correct me if I am wrong), the Mallory/hone=
ypot 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 acc=
ept 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.

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

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 the log informati=
on 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.

Then the MASA service sends a signed authorisation token back, attesting th=
e 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 sign=
ed authorization token which ensures that the event has been logged.

If a honeypot tried to use a honeypot MASA, it wouldn't have the private ke=
y to sign the authorisation token so that would fail to. If the honeypot cl=
aims the MASA is unreachable - another failure. So I agree, a good way to s=
implify 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 certifica=
tes.

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 key an=
d Domain CA public key. As you point out, in Section 2, "As a service offer=
ing the MASA can incorporate many of the bootstrapping elements (such as th=
e Registrar and the Domain CA) into the overall 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 i=
f the target domain isn=92t known when the device leaves the vendor.


A MASA makes no difference here, it's simply about validating the trust cha=
in of the domain certificate, surely?

Nope. See above.

There are different models here which need to be elucidated. A whole l=
oad more information needs to go into the document.

Thanks for the feedback,

- max

--_000_247ADDB2807D4AB5A81458381A929EB5ciscocom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <91BEF52D076A374D8D0E1AB5E90AFDEA@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable











On Mar 28, 2015, at 5:52 PM, Robert Cragie <robert.cragie@gridmerge.com> wrote:






Perhaps I was a bit premature in sending the original e-ma=
il and have taken the time to read definitions and design goals draft and t=
he reference model draft (on which I will post comments shortly)






Not having participated fully in the anima inner sanctum, I don't find=
 the description of the MASA at all clear (it's just a "tbd" in&n=
bsp;draft-behringer-anima-reference-model). However, I have read between th=
e lines somewhat and I think I have a clearer picture.











Thanks for the feedback.













Comments inline.











responses inline,













Robert





On 27 March 2015 at 01:21, Max Pritikin (pritiki=
n) 
<pritikin@cisco.=
com> wrote:






Inlines,





On Mar 26, 2015, at 5:45 PM, Robert Cragie <robert.cragie@gridmerge.com> wr=
ote:










This conversation is going around in circles as this was H=
annes' original question.






In my attempt to analyse the discussion, there are a number of points =
I notice.







Firstly, the concept of MASA seems to be no more than an online whitel=
ist (using LDAP or something).















More appropriate is to think of the MASA as a 3rd entity logging event=
s. It is not itself a whitelist -- recall it can be implemented without mak=
ing any decisions about who owns what. All whitelist belong in the Domain R=
egistrar, in my opinion. 











<RCC>The "automated orchestrator" hints at that behavi=
our ("or in real time for each new device"). I can't see that jus=
t logging will achieve that much, unless the aim is to alert someone (uncle=
ar - user, vendor?) that an anomalous event has occurred.</RCC> =


















The Registrar is =93alerted=94 in that when it decides if a device is =
to join the domain it checks the logs. If there is an anomalous event the R=
egistrar makes appropriate decisions based on domain policy. This allows th=
e domain to scale up or down the security
 as it requires.































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















The registrar is owned and operated by the domain owner. The cloud ser=
vice is not. I argue MASA substantially simplifies the threat model. <=
/div>










<RCC>I see now that the purpose of the MASA service is not onlin=
e 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 certific=
ate. But the registrar could also do this - so I guess this is really combi=
ning 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 cha=
in.














The MASA does not sign certs











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

















Understood. It signs the =93proof of logging=94 things we called =93au=
thorization tokens=94. Please feel free to suggest terms that resonate.&nbs=
p;














I see the Factory CA signs the IDevID - that seems to be what is shown=
 in Figure 1 and I can see it would be the Registrar (on behalf of the doma=
in CA) signing any domain certificate (or it may just pass it on?). However=
, the MASA is shown in the same
 dotted line as the Factory CA - which I would assume means "the Vendo=
r". So what is the difference between the Factory CA and the MASA? If =
the MASA is separate, what is the trust relationship between Factory CA and=
 MASA? Chain to the same common CA?

















Specifically the vendor trusts the MASA trust anchor and installs it o=
n the devices. The simplest approach is to re-use the IDevID trust anchor b=
ut for 3rd party MASA=92s one could install a set of MASA trust anchors. Ul=
timately trust anchors are just public
 keys with policy about how/what they are trusted for. 














I guess the question I am asking is how can the new element trust the =
MASA unless it has been pre-programmed with its public key as part of its f=
actory-configured material - is that the intent?</RCC>

















yes.
















. All it ever does is assure, via the authorization token=
, the NE that if it joins the domain this will be logged. That way Mallory =
can be detected by the real domain.









<RCC>


So please explain the authorisation token in more detail and what lead=
s 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 al=
so a log of every time the NE joins a domain. 







s4.3.2: Registrar only allows the device to join the domain if the dev=
ices history (e.g. the log information) doesn=92t show it has joined Mallor=
y=92s domain. Or, if the registar doesn=92t care, maybe it just doesn=92t c=
heck. 







s4.3.3: Registrar MUST claim the device, obtaining an authorization to=
ken and ensuring a log entry is generated, in order to get the device to tr=
ust it. 














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 tok=
en=94 are sent to the Domain from the MASA. The Domain then decides =93stil=
l accept device?=94 based on the log information. This is the Registrar che=
cking for Mallory. If the log information shows
 an 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 i=
t has received, presumably relayed by the registrar itself (OCSP)?


















Ummm=85 didn=92t follow you completely. I suggest keeping the log info=
rmation 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.&=
nbsp;














Then the MASA service sends a signed authorisation token back, attesti=
ng the validity of the Registrar. A honeypot would not be able to provide v=
alid 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.&n=
bsp;














If a honeypot tried to use a honeypot MASA, it wouldn't have the priva=
te key to sign the authorisation token so that would fail to. If the honeyp=
ot claims the MASA is unreachable - another failure. So I agree, a good way=
 to simplify the threat model.


</RCC>






 














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 cert=
ificates.















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











<RCC>It could if it were pre-provisioned with the Registrar's pu=
blic 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 elem=
ents (such as the Registrar and the Domain
 CA) into the overall service." So surely in this case, there is no se=
paration of CAs?</RCC> 

















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.&n=
bsp;

























A MASA makes no difference here, it's simply about validating the trus=
t chain of the domain certificate, surely?















Nope. See above. 











<RCC>There are different models here which need to be elucidated=
. A whole load more information needs to go into the document.</RCC><=
/div>
















Thanks for the feedback,







- max






--_000_247ADDB2807D4AB5A81458381A929EB5ciscocom_--


From nobody Tue Mar 31 00:58: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 50B101A90EB for ; Tue, 31 Mar 2015 00:58:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ef5BpTh8dmlB for ; Tue, 31 Mar 2015 00:58:53 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 725F91A1A2D for ; Tue, 31 Mar 2015 00:58:53 -0700 (PDT)
Received: from [192.168.131.145] ([80.92.114.249]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MLelb-1YcZp43Qyh-000rQT; Tue, 31 Mar 2015 09:58:50 +0200
Message-ID: <551A53B8.7020005@gmx.net>
Date: Tue, 31 Mar 2015 09:58:48 +0200
From: Hannes Tschofenig 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Michael Richardson 
References: <5511DDA0.6040308@gmx.net> <14422.1427751694@sandelman.ca>
In-Reply-To: <14422.1427751694@sandelman.ca>
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="saAgAJtdUk2GCGOo1thBgRuLNjTHCriDn"
X-Provags-ID: V03:K0:w3Qyot9L8Plc5E5d0sOdsAgb5eHnFuzYwBeYvvp0HYRzej3/H5z C91pTErD1YF5n4tmiXIH3+SwFoO0tgfUXOB4usroL2SkyXUEDedwWbD3ZVu2qkdeVsZSzf2 FTkhriio6sK+HHKfeqcgDwIU7QNxzPyC0QtohM4X9dzvQ+y5FkDNcHxF5OjtWibcg0zPr9s dYkFO8UlwjB4w7YsgXp+A==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: 
Cc: "anima@ietf.org" 
Subject: Re: [Anima] OMA Lightweight M2M
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, 31 Mar 2015 07:58:55 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--saAgAJtdUk2GCGOo1thBgRuLNjTHCriDn
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

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.

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 p=
ost a
>     > link to the list:
>     > http://openmobilealliance.org/about-oma/work-program/m2m-enablers=
/
>=20
>     > I would be interested to see whether there is overlap between Zer=
oTouch
>     > / ANIMA bootstrapping and the OMA work.
>=20
> After some poking around, I get to:
>       http://openmobilealliance.org/about-oma/work-program/device-manag=
ement/
>=20
> which has about 20 documents to read.
> When I picked to first one, I got to:
>      http://technical.openmobilealliance.org/Technical/technical-inform=
ation/release-program/current-releases/dm-v1-1-2
>=20
> 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
>=20
> which I see is 25 pages of PDF.
>=20
> I wonder if there is a shorter reading list.
>=20
> I think, in this case of this document, "SyncML", it's not applicable b=
ecause
> it says:
>=20
>    "e.g. by inserting a SIM, the prerequisites for this process are in =
place"
>=20
> 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 no=
t
> feeling the love with this organization.
>=20


--saAgAJtdUk2GCGOo1thBgRuLNjTHCriDn
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJVGlO4AAoJEGhJURNOOiAtQ4AH/1YjclILnzX2HgUoORi00GVo
X+BIkPS7IJq1WhAMedRM9kXc/ZcDO3aTRRwDIrOagGha12RIXVsQOEbbz1VGnCY6
os2vo4NKWGjxEhyp7NqNiSaJjK29flneUgIUif0UCfRlpZK9BiNiRMMYcP6c0kcQ
faLVlF36EQKyIfuQJIYwmpa8b8N28TJGpwTZRfJQCFI9Kl4uHZ45CV39P3LGVI3L
PBEp6WDyb4oKAcmYiOdTVdTPzZ6fuWCZGky6KQ6miOerl+8X4ZYryoGQxwqx9oFY
ub5f8K3g2agacIq4W3cDDgFDs6RcRfK4yFonmzw1e1FLxkWgzTcAzJuEUu8Qk98=
=j8sq
-----END PGP SIGNATURE-----

--saAgAJtdUk2GCGOo1thBgRuLNjTHCriDn--


From nobody Tue Mar 31 18: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 AD7EF1A07BE for ; Mon, 30 Mar 2015 14:41:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.511
X-Spam-Level: 
X-Spam-Status: No, score=-0.511 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 5sMZB5e35JTH for ; Mon, 30 Mar 2015 14:41:35 -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 24EF01A0406 for ; Mon, 30 Mar 2015 14:41:34 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id F3C6D2009E; Mon, 30 Mar 2015 17:51:46 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 1CD7A63B76; Mon, 30 Mar 2015 17:41:34 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 091FE63784; Mon, 30 Mar 2015 17:41:34 -0400 (EDT)
From: Michael Richardson 
To: Hannes Tschofenig 
In-Reply-To: <5511DDA0.6040308@gmx.net>
References: <5511DDA0.6040308@gmx.net>
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: 
X-Mailman-Approved-At: Tue, 31 Mar 2015 18:11:52 -0700
Cc: "anima@ietf.org" 
Subject: Re: [Anima] OMA Lightweight M2M
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, 30 Mar 2015 21:41:36 -0000

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.

-- 
]               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    [