[Nfd-dev] Question about doing remote prefix registration using Android app
Lan Wang (lanwang)
lanwang at memphis.edu
Thu Aug 10 13:27:36 PDT 2017
Junxiao mentioned yesterday that sometimes it takes some time to retrieve the certificate for the validation. And he mentioned setting a higher retransmission count for the remote registration request if I remember correctly.
But it’s also possible the naming of your data and keys may not fit the hierarchical model. This is just a guess. I don’t remember the specific definition of the hierarchical model.
checker
{
type hierarchical ; the certificate name of the signing key and
; the data name must follow the hierarchical model
sig-type ecdsa-sha256 ; data must have a ecdsa-sha256 signature
}
Lan
On Aug 10, 2017, at 3:02 PM, Haitao Zhang <zhtaoxiang at gmail.com<mailto:zhtaoxiang at gmail.com>> wrote:
Hi Dev team,
My NDNFit Android app needs to do remote prefix registration on the testbed, so Interests can be forwarded to the Android device, then the NDNFit Android app.
To do it, I did the following steps. But it failed, could you help to take a look if I did something wrong?
(0) John configured NDNFit trust anchor /org/openmhealth/KEY/ksk-1490231565751/ID-CERT/%FD%00%00%01Z%F8%B9%1Et to be a new trust anchor on the testbed. The configuration has been verified to be correct (details at the end of the email).
(1) I configured NDN-Android to connect to spurs.ucla.edu<http://spurs.ucla.edu/>, and register prefix "/localhop" on udp://spurs.cs.ucla.edu<http://spurs.cs.ucla.edu/> (UCLA node). Notice that, by default, NDN-Android doesn't register "/localhop"
(2) Create an interest /localhop/nfd/rib/register/<control parameter including the prefix I want to register>, sign it using
/org/openmhealth/KEY/uLsLn5csbB/ksk-1502352233531/ID-CERT/%FD%00%00%01%5D%CB+%E5S
which is further signed by
NDNFit trust anchor /org/openmhealth/KEY/ksk-1490231565751/ID-CERT/%FD%00%00%01Z%F8%B9%1Et
(Those two certs are publicly available, you can connect to any NDN testbed node, then do ndnpeek to fetch those two certs)
Java code:
Name remotePrefixRegisterPrefix = new Name("/localhop/nfd/rib/register");
ControlParameters params = new ControlParameters();
params.setName(new Name(prefix));
remotePrefixRegisterPrefix.append(params.wireEncode());
Interest remotePrefixRegisterInterest = new Interest(remotePrefixRegisterPrefix);
keyChain.sign(remotePrefixRegisterInterest, keyChain.getDefaultCertificateName());
I set the default certificate to be /org/openmhealth/KEY/uLsLn5csbB/ksk-1502352233531/ID-CERT/%FD%00%00%01%5D%CB+%E5S
(3) Send it out. As I registered "/localhop" on UCLA node, the interest should go to UCLA node.
(4) I got an data packet containing a message "authorization rejected".
Best,
-Haitao
To make NDNFit another trust anchor on testbed, nfd.conf file is modified (the red part is added)
localhop_security
{
; This section defines the trust model for NFD RIB Management. It consists of rules and
; trust-anchors, which are briefly defined in this file. For more information refer to
; manpage of ndn-validator.conf:
;
; man ndn-validator.conf
;
; A trust-anchor is a pre-trusted certificate. This can be any certificate that is the
; root of certification chain (e.g., NDN testbed root certificate) or an existing
; default system certificate `default.ndncert`.
;
; A rule defines conditions a valid packet MUST have. A packet must satisfy one of the
; rules defined here. A rule can be broken into two parts: matching & checking. A packet
; will be matched against rules from the first to the last until a matched rule is
; encountered. The matched rule will be used to check the packet. If a packet does not
; match any rule, it will be treated as invalid. The matching part of a rule consists
; of `for` and `filter` sections. They collectively define which packets can be checked
; with this rule. `for` defines packet type (data or interest) and `filter` defines
; conditions on other properties of a packet. Right now, you can only define conditions
; on packet name, and you can only specify ONLY ONE filter for packet name. The
; checking part of a rule consists of `checker`, which defines the conditions that a
; VALID packet MUST have. See comments in checker section for more details.
rule
{
id "NRD Prefix Registration Command Rule"
for interest ; rule for Interests (to validate CommandInterests)
filter
{
type name ; condition on interest name (w/o signature)
regex ^[<localhop><localhost>]<nfd><rib>[<register><unregister>]<>$ ; prefix before
; timestamp
}
checker
{
type customized
sig-type rsa-sha256 ; interest must have a rsa-sha256 signature
key-locator
{
type name ; key locator must be the certificate name of the
; signing key
regex ^[^<KEY>]*<KEY><>*<ksk-.*><ID-CERT>$
}
}
checker
{
type customized
sig-type ecdsa-sha256 ; interest must have a ecdsa-sha256 signature
key-locator
{
type name ; key locator must be the certificate name of the
; signing key
regex ^[^<KEY>]*<KEY><>*<ksk-.*><ID-CERT>$
}
}
}
rule
{
id "NDN Testbed Hierarchy Rule"
for data ; rule for Data (to validate NDN certificates)
filter
{
type name ; condition on data name
regex ^[^<KEY>]*<KEY><>*<ksk-.*><ID-CERT><>$
}
checker
{
type hierarchical ; the certificate name of the signing key and
; the data name must follow the hierarchical model
sig-type rsa-sha256 ; data must have a rsa-sha256 signature
}
checker
{
type hierarchical ; the certificate name of the signing key and
; the data name must follow the hierarchical model
sig-type ecdsa-sha256 ; data must have a ecdsa-sha256 signature
}
}
trust-anchor
{
type file
file-name keys/ndn-testbed-root.ndncert.base64
}
trust-anchor
{
type file
file-name keys/openmhealth.cert
}
}
To verify that the configuration works, John requested a key from NDNFit cert management website http://128.97.98.8:5001/ (it is ported from ndncert website and works the same way as ndncert website) and did the following (quote his email here):
... I was able to register a prefix and have it propagate on the Testbed with readvertise.
I ran this script to start NFD and set my identity:
#!/bin/bash
# make sure any old nfd is stopped:
nfd-stop
sleep 5
# start a new nfd:
nfd-start >& nfd-start.log
sleep 5
# use WU as gateway router:
nfdc register / udp://wundngw.arl.wustl.edu
# configure for prefix registration at WU:
nfdc register /localhop/nfd udp4://wundngw.arl.wustl.edu
sleep 5
# test connection to WU gateway with ndnping
ndnping -c 5 /ndn/edu/wustl
# set identity to WU based name:
ndnsec-set-default /org/openmhealth/m8rP9jdjKp
Then I ran ndnpingserver like this:
ndnpingserver /org/openmhealth/m8rP9jdjKp/jdd
Then I checked WU and UCLA:
WU:
ndnops at wundngw:~$ nfdc fib list | grep mhealth
/org/openmhealth nexthops={faceid=259 (cost=22132), faceid=261 (cost=24334), faceid=277 (cost=36283)}
/org/openmhealth/m8rP9jdjKp nexthops={faceid=259 (cost=20674), faceid=261 (cost=21391), faceid=277 (cost=34642)}
ndnops at wundngw:~$
UCLA:
ndnops at spurs:~$ nfdc fib list | grep m8rP9jdjKp
/org/openmhealth/m8rP9jdjKp nexthops={faceid=278 (cost=19669), faceid=260 (cost=22128), faceid=259 (cost=22252), faceid=276 (cost=23762), faceid=279 (cost=28847)}
ndnops at spurs:~$ nfdc fib list | grep m8rP9jdjKp
/org/openmhealth/m8rP9jdjKp nexthops={faceid=278 (cost=19669), faceid=260 (cost=22128), faceid=259 (cost=22252), faceid=276 (cost=23762), faceid=279 (cost=28847)}
ndnops at spurs:~$
And I show up on both!
So, it appears to me to be working from a normal end host. So I think the certificate/key/trust-anchor part must
be working, right?
_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20170810/e164e6e3/attachment-0001.html>
More information about the Nfd-dev
mailing list