[Nfd-dev] Try NDNCERT (based on Interest-Data exchange) and get an NDN certificate today
Zhiyi Zhang
zhiyi at cs.ucla.edu
Wed Nov 13 15:59:18 PST 2019
Hi Junxiao,
I don't know whether I can update the deployment because the server is now
running over Spurs.
Let me ask Alex about this. I need to make sure the new deployment will not
affect anything that are running now.
@Alex what do you think of Junxiao's suggestion?
Best,
Zhiyi
On Wed, Nov 13, 2019 at 2:46 AM Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:
> Hi Zhiyi
>
> Can you update the deployment with that?
>
> Hint: if you need a different ndn-cxx version than what SPURS has, you can
> do so with user-scope installation.
> 1. Set --prefix to $HOME/usr while compiling ndn-cxx
> 2. Set PKG_CONFIG_PATH to $HOME/usr/lib/pkgconfig while compiling ndncert
> 3. Set LD_LIBRARY_PATH to $HOME/usr/lib while running ndncert
>
> Yours, Junxiao
>
> On Tue, Nov 12, 2019 at 23:47 Zhiyi Zhang <zhiyi at cs.ucla.edu> wrote:
>
>> Hi Junxiao,
>>
>> After I fixed the typo, the Interest will be processed and a Data will be
>> returned. I am using the latest version on github.
>>
>> Client:
>> ➜ temp ./ndncert-client
>> 1573620336.083851 DEBUG: [ndn.UnixTransport] connect
>> path=/var/run/nfd.sock
>> 1573620336.083996 DEBUG: [ndn.Face] <I
>> /zhiyi/CA/_PROBE?ndn.MaxSuffixComponents=1&ndn.MustBeFresh=true&ndn.InterestLifetime=3991&ndn.Nonce=3638500717
>> 1573620336.084021 DEBUG: [ndn.UnixTransport] connect
>> path=/var/run/nfd.sock
>> 1573620336.084025 DEBUG: [ndn.UnixTransport] resume
>> 1573620339.050352 DEBUG: [ndn.Face] >D /zhiyi/CA/_PROBE
>> 1573620339.050365 DEBUG: [ndn.Face] satisfying
>> /zhiyi/CA/_PROBE?ndn.MaxSuffixComponents=1&ndn.MustBeFresh=true&ndn.InterestLifetime=3991&ndn.Nonce=3638500717
>> from app
>> 1573620339.050441 DEBUG: [ndn.UnixTransport] pause
>>
>> Server:
>> 1573620336.099217 DEBUG: [ndn.Face] >I
>> /zhiyi/CA/_PROBE?ndn.MaxSuffixComponents=1&ndn.MustBeFresh=true&ndn.InterestLifetime=3991&ndn.Nonce=3638500717
>> 1573620336.099251 DEBUG: [ndn.Face] matches /zhiyi/CA/_PROBE
>> 1573620336.099260 TRACE: [ndncert.ndncert.ca] ../src/ca-module.cpp:121:
>> Receive PROBE request
>> 1573620336.099307 TRACE: [ndncert.ndncert.ca] ../src/ca-module.cpp:152:
>> Handle PROBE: generate an identity /zhiyi/4944111405507993668
>> 1573620336.099995 TRACE: [ndn.security.v2.KeyChain] Prepared signature
>> info: SignatureSha256WithRsa Name=/zhiyi/KEY/%EF28%08%5Cx%1E%EA
>> 1573620339.050001 TRACE: [ndncert.ndncert.ca] ../src/ca-module.cpp:162:
>> Handle PROBE: send out the PROBE response
>> 1573620339.050050 DEBUG: [ndn.Face] <D /zhiyi/CA/_PROBE
>> 1573620339.050063 DEBUG: [ndn.Face] satisfying
>> /zhiyi/CA/_PROBE?ndn.MaxSuffixComponents=1&ndn.MustBeFresh=true&ndn.InterestLifetime=3991&ndn.Nonce=3638500717
>> from forwarder
>>
>> Best,
>> Zhiyi
>>
>> On Tue, Nov 12, 2019 at 4:42 PM Junxiao Shi <shijunxiao at email.arizona.edu>
>> wrote:
>>
>>> Hi Zhiyi
>>>
>>> NDNCERT PROBE command uses name /CA/_PROBE, not /CA/_RPROBE.
>>> The packet sample in pcap file is sending correct prefix according to
>>> protocol, but your snippet is sending wrong prefix.
>>>
>>> Yours, Junxiao
>>>
>>> On Tue, Nov 12, 2019, 18:51 Zhiyi Zhang <zhiyi at cs.ucla.edu> wrote:
>>>
>>>> Hi Junxiao,
>>>>
>>>> I tried the code but it seems that the Interest arrives at the CA, but
>>>> did not trigger the filter match (I cannot see the log from this line
>>>> https://github.com/named-data/ndn-cxx/blob/master/ndn-cxx/impl/face-impl.hpp#L209
>>>> ).
>>>> I set a breakpoint in my ndncert code in the onProbe function, but it's
>>>> never triggered.
>>>>
>>>> Here is my client code (I modified your code):
>>>>
>>>> #include <ndn-cxx/interest.hpp>
>>>> #include <ndn-cxx/face.hpp>
>>>> #include <ndn-cxx/encoding/block.hpp>
>>>> #include <ndn-cxx/util/string-helper.hpp>
>>>>
>>>> #include <iostream>
>>>> #include <string>
>>>>
>>>> std::string pkt =
>>>> "0571074208036e646e0803656475080475636c610806797566656e6708065f50524f42450220649503f51f30e5f9a3a76d6f1847bcce7208b64367a2459ac848ebfc91f47ed812000a046d1ddfd80c020f97241f7b22656d61696c223a22537573656e746572406461797265702e636f6d227d"
>>>> ;
>>>>
>>>> ndn::Face face;
>>>>
>>>> int main() {
>>>> ndn::Block block(ndn::fromHex(pkt));
>>>> ndn::Interest interest(block);
>>>> auto param = interest.getApplicationParameters();
>>>> interest.setName(ndn::Name("/zhiyi/CA/_RPROBE"));
>>>> interest.setApplicationParameters(param);
>>>> face.expressInterest(interest, nullptr, nullptr, nullptr);
>>>> face.processEvents();
>>>> }
>>>>
>>>>
>>>> On the client side, here is what I got from the NDN log:
>>>>
>>>> 1573601811.702968 DEBUG: [ndn.Face] >I /zhiyi/CA/_RPROBE
>>>> ndn.MaxSuffixComponents=1&ndn.MustBeFresh=true&ndn.InterestLifetime=3991&ndn.Nonce=3638500717
>>>>
>>>> Best,
>>>> Zhiyi
>>>>
>>>> On Tue, Nov 12, 2019 at 10:02 AM Junxiao Shi <
>>>> shijunxiao at email.arizona.edu> wrote:
>>>>
>>>>> Hi Zhiyi
>>>>>
>>>>> Have you figured out why the CA isn't responding?
>>>>> I attached packet samples so you can replay them onto your node.
>>>>>
>>>>> Yours, Junxiao
>>>>>
>>>>> On Tue, Nov 5, 2019 at 5:25 PM Junxiao Shi <
>>>>> shijunxiao at email.arizona.edu> wrote:
>>>>>
>>>>>> Hi Zhiyi
>>>>>>
>>>>>> Sorry. but to be honest, I don't know why the client will have
>>>>>>> invalid last component. (my clinet code simply runs
>>>>>>> setApplicationParameter(), no more function calls).
>>>>>>>
>>>>>>
>>>>>> I guess it's because I'm running the client from your personal repo
>>>>>> <https://github.com/Zhiyi-Zhang/ndncert>, designed to work with
>>>>>> ndn-cxx-0.6.6, which does not append ParametersDigestSha256Component.
>>>>>> However, my other program appends ParametersDigestSha256Component
>>>>>> properly, and I have verified against latest ndn-cxx that the digest is
>>>>>> correct.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Regarding the CA does not reply, I guess it may be the JSON format
>>>>>>> problem (if you generate the JSON on your own)? I recalled in last
>>>>>>> hackathon, Alex met the similar issue. They said some weird newlines are
>>>>>>> added to the JSON file generated by the BOOST library.
>>>>>>>
>>>>>>
>>>>>> According to RFC8259 section 2
>>>>>> <https://tools.ietf.org/html/rfc8259#section-2>,
>>>>>>
>>>>>> Insignificant whitespace is allowed before or after any of the
>>>>>> six structural characters.
>>>>>>
>>>>>> Therefore, it's not wrong to add "weird newlines", as they will be
>>>>>> ignored by a decoder.
>>>>>>
>>>>>> ApplicationParameters element (including T,L,V) is:
>>>>>>
>>>>>> 0000 24 1f 7b 22 65 6d 61 69 6c 22 3a 22 53 75 73 65
>>>>>> $.{"email":"Suse
>>>>>> 0010 6e 74 65 72 40 64 61 79 72 65 70 2e 63 6f 6d 22
>>>>>> nter at dayrep.com"
>>>>>> 0020 7d }
>>>>>>
>>>>>> The JSON payload is handwritten. It is not generated by BOOST library.
>>>>>>
>>>>>> Interpreting the TLV-VALUE using RFC8259
>>>>>> <https://tools.ietf.org/html/rfc8259>, we can see that it represents
>>>>>> a JSON object that contains a key "email".
>>>>>>
>>>>>> As specified in NDNCERT protocol:
>>>>>>
>>>>>> JSON format: The format depends on the probe of the configuration
>>>>>> file. As an example, if we have "probe":"email:full-name", then the JSON
>>>>>> file carried in the PROBE Interest will contains two attributes: email and
>>>>>> full-name.
>>>>>>
>>>>>>
>>>>>> As seen in /ndn/edu/ucla/yufeng/CA/_PROBE/INFO packet (frame 5 in packet
>>>>>> sample
>>>>>> <https://www.lists.cs.ucla.edu/pipermail/nfd-dev/2019-November/003861.html>),
>>>>>> the CA expects PROBE parameters to have "email" key.
>>>>>> Therefore, I believe my Interest satisfies the schema shown on the
>>>>>> protocol page.
>>>>>>
>>>>>> Yours, Junxiao
>>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20191113/e2d54aa3/attachment.html>
More information about the Nfd-dev
mailing list