[Nfd-dev] Try NDNCERT (based on Interest-Data exchange) and get an NDN certificate today
Junxiao Shi
shijunxiao at email.arizona.edu
Wed Nov 13 02:46:54 PST 2019
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/e3e8bcd3/attachment-0001.html>
More information about the Nfd-dev
mailing list