[Nfd-dev] Question about doing remote prefix registration using Android app
Haitao Zhang
zhtaoxiang at gmail.com
Thu Aug 10 13:02:54 PDT 2017
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, and register
prefix "/localhop" on udp://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/
<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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20170810/47331afa/attachment-0001.html>
More information about the Nfd-dev
mailing list