Re: [Anima-bootstrap] anima-bootstrap: Bootstrap proxy discovery options

"Max Pritikin (pritikin)" <pritikin@cisco.com> Sat, 05 December 2015 00:26 UTC

Return-Path: <pritikin@cisco.com>
X-Original-To: anima-bootstrap@ietfa.amsl.com
Delivered-To: anima-bootstrap@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 859841B3427 for <anima-bootstrap@ietfa.amsl.com>; Fri, 4 Dec 2015 16:26:04 -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_64=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 xoGMeb3e9jbi for <anima-bootstrap@ietfa.amsl.com>; Fri, 4 Dec 2015 16:26:02 -0800 (PST)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E9CF1B3423 for <anima-bootstrap@ietf.org>; Fri, 4 Dec 2015 16:26:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6228; q=dns/txt; s=iport; t=1449275162; x=1450484762; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=WVLrPZQhp3ldvK1Rn0zQqOpylnE3ecpRivFaxd56E7c=; b=jLDMkBR9vi+bODgAISCgWWWj1+aUcggVOIoAF2gSFPizsCAXGghA6iUz +FrMWACMZtyeK+1mMoIKUGjtc+JqYsYUri6tR3ljZ1EN3R/La05ZbnILa CqEEfwj1izcRTa8ZEAph+Cu/Ai3tE3z7I8ncAQTQg7BDH7K0dLXtpQPyG w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AAAgD3LWJW/5pdJa1egzpTbga9PwENgW4XCoVtAhyBCzgUAQEBAQEBAYEKhDQBAQEDAQEBASAEDToLBQsCAQgYAgImAgICHwYLFRACBA4FiBoDCggNr1mMBw2EWQEBAQEBAQEBAQEBAQEBAQEBAQEBARQEgQGHYoJuglOCBhiDBi+BFQWWYQGLRIF3lRSHWAEfAQFCghEdgVZyAYQkAgQaBxyBBwEBAQ
X-IronPort-AV: E=Sophos;i="5.20,382,1444694400"; d="scan'208";a="215008194"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Dec 2015 00:26:01 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id tB50Q1XS026503 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 5 Dec 2015 00:26:01 GMT
Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 4 Dec 2015 18:26:00 -0600
Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1104.000; Fri, 4 Dec 2015 18:25:54 -0600
From: "Max Pritikin (pritikin)" <pritikin@cisco.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Thread-Topic: [Anima-bootstrap] anima-bootstrap: Bootstrap proxy discovery options
Thread-Index: AQHRLjUzUXhNiuqCZk29llWSg8eoaJ66oGCAgAFDVQCAAAYSAIAABWOA
Date: Sat, 05 Dec 2015 00:25:54 +0000
Message-ID: <FD53CF07-302A-4FEC-8119-B2FF98A1916E@cisco.com>
References: <20151204014333.GZ29056@cisco.com> <56611639.9060508@gmail.com> <29E5EEC1-9995-4137-B8BE-7E2103810CD9@cisco.com> <56622A8C.2020106@gmail.com>
In-Reply-To: <56622A8C.2020106@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.99.106.4]
Content-Type: text/plain; charset="utf-8"
Content-ID: <FE5B954FAE346B4DBD3A11D3D3BF0230@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/anima-bootstrap/TPmt_WBO0kRS-gZr8ZkcOSYUzvo>
Cc: "Toerless Eckert (eckert)" <eckert@cisco.com>, "anima-bootstrap@ietf.org" <anima-bootstrap@ietf.org>
Subject: Re: [Anima-bootstrap] anima-bootstrap: Bootstrap proxy discovery options
X-BeenThere: anima-bootstrap@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mailing list for the bootstrap design team of the ANIMA WG <anima-bootstrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima-bootstrap/>
List-Post: <mailto:anima-bootstrap@ietf.org>
List-Help: <mailto:anima-bootstrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 05 Dec 2015 00:26:04 -0000

> On Dec 4, 2015, at 5:06 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
> On 05/12/2015 12:44, Max Pritikin (pritikin) wrote:
>> Brian, 
>> 
>> Are the session-id and the nonce equivalent?
> 
> Well, I made an implementation choice that when an ASA registers itself
> with GRASP it gets back a nonce, used to validate future calls, so
> that no other process can masquerade as the same ASA. And yes, I
> just re-used the existing Session ID mechanism to assign that nonce.
> However, each transaction that an ASA initiates will get its own
> Session ID.
> 
>> Why is the 30000 a parameter passed into the into the grasp.discover call? This looks like a timeout for how long to wait for a response (GRASP_DEF_TIMEOUT/2)? If so this would provide the 30s behavior but is leveraging a side-effect dubiously. Sufficient for PoC; I’m just asking to understand.
> 
> Correct. Again, it's just an implementation choice and I agree it's a bit
> of a kludge. It could be done more elegantly. (Although I must say that the
> threading support in Python is a dream to use.)

all goodness. thanks. 

> 
>> 
>> Toerless’s suggestion appears to be to include the “locator-option” within the discover message. Did you include that? Currently "locator-option” is not part of the [grasp] s3.7.2 Discover Message. Are you comfortable adding that as Toerless argues for?
> 
> It turns out that we have to do that anyway, for other reasons that Joel Halpern
> pointed out (since Session IDs are unique per node, not network-wide). That will
> be fixed in the next GRASP draft. But in any case, the recipient of a LL multicast
> can know the source address (and interface #) even if they are not in the payload.
> So this isn't a problem.
> 
> However, I do think that the "announcement" nature of this is better suited
> to the unsolicited flooding message than the Discovery message, because then
> it's natural to include data in the message.

so rather than add “locator-option” to the discovery message use unsolicited response messages. This makes sense (very similar to mDNS approach!). 

FYI - as an editorial note the paragraph explaining flooding is buried in s3.3.5 and could probably be called out more clearly in the text. Perhaps its own section or in the Response section? Similarly s3.9.1 includes the text: "and for terminating flooding as described in FLOODING” which looks like an incomplete reference as if you had already planned to pull flooding out into its own section.

- max

> 
>    Brian
> 
>> 
>> - max
>> 
>>> On Dec 3, 2015, at 9:27 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>>> 
>>> On 04/12/2015 14:43, Toerless Eckert wrote:
>>> 
>>> ...
>>>>  IMHO, i would let the proxy periodically (30 secs) just announce that its providing
>>>>  AN enrollment proxy function via link-local IPv6 multicast. 
>>> 
>>> Here's the Python code to do that with my prototype:
>>> 
>>> import grasp
>>> import time
>>> 
>>> OK, nonce = grasp.register_asa("Boot")
>>> if not OK:
>>>   #we've got a serious problem...
>>>   raise RuntimeError("Can't register as ASA")
>>> 
>>> obj = objective(0,":Boot")
>>> x = grasp.register_obj(nonce, obj)
>>> if not x == "OK":
>>>   #we've got a different problem...
>>>   raise RuntimeError(x)
>>> 
>>> while True:
>>>   grasp.discover(nonce, obj, 30000)
>>> 
>>> What this does is register the caller as an ASA called "Boot" that handles the
>>> objective called ":Boot", and then LL multicast a discovery message every
>>> 30s. That will tell the others that it's there. It's running in another window
>>> as I type. I didn't write the handler code for the receiving end yet though,
>>> so I just get output like this twice a minute:
>>> 
>>> CBOR->Python gives:  [1, 1248700, b'$\x06\xe0\x07S\x07\x00\x01(\xcc\xdcL\x97\x03g\x81', ':Boot', 0, 6, 0]
>>> 
>>>> Maybe with port-number
>>>>  and protocol (EST over IPv6 link-local ) as parameters so it's extensible.
>>> 
>>> If you want parameters, we'd need to use the (synch) flooding method
>>> instead. Maybe I'll write that code next week; it will be very similar to
>>> the discovery case. I don't think there are any real problems here.
>>> 
>>> Python+CBOR is fun. Thanks, Toerless, for pushing the CBOR idea.
>>> 
>>>  Brian
>>> 
>>> _______________________________________________
>>> Anima-bootstrap mailing list
>>> Anima-bootstrap@ietf.org
>>> https://www.ietf.org/mailman/listinfo/anima-bootstrap
>> 
>