[Nfd-dev] Try NDNCERT (based on Interest-Data exchange) and get an NDN certificate today
Zhiyi Zhang
zhiyi at cs.ucla.edu
Tue Nov 12 20:47:19 PST 2019
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/20191112/d8d84d11/attachment.html>
More information about the Nfd-dev
mailing list