Re: [Lurk] lurk@Hackathon102

[Daniel Migault <[e-mail]>]

Thanks for the feed backs Ori,

On Thu, Jun 7, 2018 at 5:15 AM, Ori Finkelman <[e-mail]> wrote:

> Hi Daniel and Sanjay,
>
> Some of the goals we may aim to achieve in the IETF102 Hackathon (some are
> already under development)
> + A CLurk OpenSSL implementation (ongoing work)
>

I agree c implementation is very important. At the current stage the client
side is more important than the server side as we need it for an
integration with openssl for example.

+ Nginx integration (ongoing work)
>    - benchmark for session establishment, CPU and latency
> + Possibly a second cache server reference integration. ATS and Varnish
> are good candidates
> + A second LURK server implementation, preferably using a more performant
> language than Python, possible Go or Java.
>

Just to mention there is a Java implementation of a Key Server [1]. It
implements a previous version of LURK, so it might be a good starting
point.
Note that to improve the performance of pylurk, we may also consider moving
from construct 2.8 to construct  2.9 which adds a compilation feature [2].
Note that defining structures with kaita [3] who enable sharing those with
Go, Java, C++, Python implementations.... so that may also be considered.
Consideration of SGX would also be important I believe.



> + Management model and API for the LURK key server, Daniel proposed YANG,
> is there a re need for an I-D for that ?
>
I agree that would be usefull to have a common configuration interface
among the various implementations

+ HA model
>   - What should be the HA model ?
>   - Load balancer ?
>   - Configuring the LURK client with multiple LURK server addresses ?
>
> That would be interesting. Probably reflexion should be described in an
informational document. I would envision HA working a bit like DNS, where
LURK Client being provided multiple addresses ( or fqdn) , can select the
LURK Server either using round robin, given the capabilities of the LURK
Server or the ping measurement.


[1] https://github.com/mami-project/KeyServer
[2] https://construct.readthedocs.io/en/latest/compilation.html
[3] http://kaitai.io/



> Thanks,
> Ori
>
> On Wed, May 23, 2018 at 8:28 PM, Daniel Migault <
> [e-mail]> wrote:
>
>> Thanks Sanjay for raising this point.
>>
>> Since we now have at least a second implementation of lurk, it would be
>> good to proceed to interoperability test.
>>
>> Other things that come to my mind are:
>> * Editing vector tests for future implementations.
>> * Designing some performance measurements
>>
>> As far as pylurk is concerned there are multiple points we could focused
>> on:
>> * lurk client - sevrer communication:
>> ** UDP multithreading
>> ** UDP/DTLS
>> ** TCP
>> ** TCP/TLS
>> ** HTTPS
>> * updating construct to construct 2.9
>> * ....
>>
>> I am happy to take any comments / feed backs and add items as they come
>> to my mind.
>>
>> Yours,
>> Daniel
>>
>>
>>
>> On Tue, May 22, 2018 at 11:24 PM, <sanjay.mishra=40verizon.com@d
>> marc.ietf.org> wrote:
>>
>>> To add to Daniel’s update, there are plans to bring an early
>>> implementation at the Hackathon in Montreal (IETF102). Please feel free to
>>> reach out to Daniel, Dmitry or me for any implementation related questions.
>>>
>>>
>>>
>>> -Sanjay
>>>
>>>
>>>
>>> *From:* Lurk [mailto:[e-mail]] *On Behalf Of *Daniel
>>> Migault
>>> *Sent:* Friday, May 18, 2018 11:12 AM
>>> *To:* LURK BoF <[e-mail]>
>>> *Subject:* [E] [Lurk] pylurk
>>>
>>>
>>>
>>> Hi,
>>>
>>>
>>>
>>> We are happy to let you know that we have been able to publish our
>>> implementation of pylurk on github [1] as well as on pypi [2].
>>>
>>>
>>>
>>> This is an early implementation of draft-mglt-lurk-lurk [3] and
>>> draft-mglt-lurk-tls12 [4]. We expect to update the drafts to reflects our
>>> findings while implementing soon.
>>>
>>>
>>>
>>> If you encounter any issue or have any question, feel free to raise you
>>> concern and of course any comment / feed back is appreciated!
>>>
>>>
>>>
>>> Yours,
>>>
>>> Daniel
>>>
>>>
>>>
>>> [1] https://github.com/mglt/pylurk
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_mglt_pylurk&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=uDsnQIk-WRzcF3eSc7AqZKkP8rKw6ND7l2U5KtRdwa4&s=i1ej8GdJ7wGzzOQdya7-frDePvxHdsWal_wFv8FPvrk&e=>
>>>
>>> [2] https://pypi.org/project/pylurk/
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__pypi.org_project_pylurk_&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=uDsnQIk-WRzcF3eSc7AqZKkP8rKw6ND7l2U5KtRdwa4&s=9pcQpr-0ORpWkMClnhrqfYjkdMuawxmuwbv1XPVbIOQ&e=>
>>>
>>> [3] https://datatracker.ietf.org/doc/draft-mglt-lurk-lurk/
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dmglt-2Dlurk-2Dlurk_&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=uDsnQIk-WRzcF3eSc7AqZKkP8rKw6ND7l2U5KtRdwa4&s=EDP277NhIg5iAp5pA0fge8nKosSirLFL9yhXSiCOooQ&e=>
>>>
>>> [4] https://github.com/mglt/draft-mglt-lurk-tls12/blob/master/dr
>>> aft-mglt-lurk-tls12.mkd
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_mglt_draft-2Dmglt-2Dlurk-2Dtls12_blob_master_draft-2Dmglt-2Dlurk-2Dtls12.mkd&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=uDsnQIk-WRzcF3eSc7AqZKkP8rKw6ND7l2U5KtRdwa4&s=VB1TauZ4XA0SW09Out7EdlgKP64sTiG9oP9OQHmfRfg&e=>
>>>
>>>
>>>
>>> _______________________________________________
>>> Lurk mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/lurk
>>>
>>>
>>
>> _______________________________________________
>> Lurk mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lurk
>>
>>
>
>
> --
>
> *Ori Finkelman*Qwilt | Work: [phone] | Mobile: [phone] |
> [e-mail]
>
> _______________________________________________
> Lurk mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lurk
>
>