NFD

Are there any other key types that are needed?

And is the proper sig-type:

sig-type ecdsa-sha256

John DeHart wrote:

Are there any other key types that are needed?

Up to now, in ndn-cxx, there are two types of sig type : sha256 with RSA and sha256 with ECDSA. You may ask Yingdi. He knows this part better.

The spec of validator configuration is correct, but there is an implementation bug in security::conf::Checker, we need to fix http://redmine.named-data.net/issues/3645 first.

The spec of validator configuration is correct, but there is an implementation bug in security::conf::Checker, we need to fix #3645 first.

#3645 is closed. After deployment, how to proceed with this? How to write the configuration?

Junxiao Shi wrote:

The spec of validator configuration is correct, but there is an implementation bug in security::conf::Checker, we need to fix #3645 first.

#3645 is closed. After deployment, how to proceed with this? How to write the configuration?

Now that 0.5.0 is deployed in the Testbed are we ready to turn on ECDSA rules?

I think just add checker in each rule and it should work.
The checker in the "NRD Prefix Registration Command Rule" :

   checker
   {
     type customized
     sig-type ecdsa-sha256
     key-locator
     {
       type name
       regex ^[^<KEY>]*<KEY><>*<ksk-.*><ID-CERT>$
     }
   }

The checker in the "NDN Testbed Hierarchy Rule"

   checker
   {
     type hierarchical
     sig-type ecdsa-sha256
   }

Then add a new trust anchor in the end.

 trust-anchor
 {
   type file
   file-name keys/ndn-testbed-root.ecdsa.ndncert.base64
 }

Follow-up to note-10:

Can you add the example into nfd.conf.sample file, and also modify IntegrationTests auto prefix propagation scenario to test with a mix of RSA and ECDSA keys?

I will, but it may take some time. I have never got into detail of NFD. I may first need to know what's going on now and then do the change.

Zhiyi Zhang wrote:

I think just add checker in each rule and it should work.
The checker in the "NRD Prefix Registration Command Rule" :

   checker
   {
     type customized
     sig-type ecdsa-sha256
     key-locator
     {
       type name
       regex ^[^<KEY>]*<KEY><>*<ksk-.*><ID-CERT>$
     }
   }

The checker in the "NDN Testbed Hierarchy Rule"

   checker
   {
     type hierarchical
     sig-type ecdsa-sha256
   }

Then add a new trust anchor in the end.

 trust-anchor
 {
   type file
   file-name keys/ndn-testbed-root.ecdsa.ndncert.base64
 }

Has an ecdsa root key been generated by anyone for this trust anchor?

We can use RSA root key only, and update config file to support the ECDSA key validation. Sure we can have a ECDSA root key and it can work.

Reply to note-17:

What's the relevant log lines, on both end host and router?
What's seen in tcpdump?
I suspect there's a time synchronization problem or certificate retrieval delay.

Reply to note-18:
On my localhost test:
The log from NFD:

1478288791.079004 INFO: [UnixStreamTransport] [id=0,local=unix:///private/var/run/nfd.sock,remote=fd://33] Creating transport
1478288791.079022 INFO: [FaceTable] Added face id=266 remote=fd://33 local=unix:///private/var/run/nfd.sock
1478288791.127800 INFO: [Transport] [id=266,local=unix:///private/var/run/nfd.sock,remote=fd://33] setState UP -> FAILED
1478288791.127837 INFO: [Transport] [id=266,local=unix:///private/var/run/nfd.sock,remote=fd://33] setState FAILED -> CLOSED
1478288791.145549 INFO: [FaceTable] Removed face id=266 remote=fd://33 local=unix:///private/var/run/nfd.sock

The result after running nfdc register for the first time:

Failed in unregistering name: failed in validating parameters (code: 400)

For the second try:
From NFD:

1478288793.624334 INFO: [UnixStreamTransport] [id=0,local=unix:///private/var/run/nfd.sock,remote=fd://33] Creating transport
1478288793.624363 INFO: [FaceTable] Added face id=267 remote=fd://33 local=unix:///private/var/run/nfd.sock
1478288793.663790 INFO: [RibManager] Removing route /ndn nexthop=264 origin=255
1478288793.664282 INFO: [Transport] [id=267,local=unix:///private/var/run/nfd.sock,remote=fd://33] setState UP -> FAILED
1478288793.664319 INFO: [Transport] [id=267,local=unix:///private/var/run/nfd.sock,remote=fd://33] setState FAILED -> CLOSED
1478288793.694358 INFO: [FaceTable] Removed face id=267 remote=fd://33 local=unix:///private/var/run/nfd.sock

Result of nfdc register:

Successful in unregistering name: ControlParameters(Name: /ndn, FaceId: 264, Origin: 255, )

note-19 does not answer ALL questions in note-18. Complete answers in exactly same scenario (i.e. remote prefix registration) are needed.

Don't know how to go further, maybe someone who is familiar with NFD can solve the problem.
There is no error for my most recent try and I don't know why.
This is the most recent tcpdump log:

15:09:37.729876 IP wifi-131-179-33-163.host.ucla.edu.63922 > ndn-remap-p05.it.ucla.edu.6363: 
    Flags [S], seq 3920632055, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 236349370 ecr 0,sackOK,eol], length 0
15:09:37.734723 IP ndn-remap-p05.it.ucla.edu.6363 > wifi-131-179-33-163.host.ucla.edu.63922: 
    Flags [S.], seq 131968288, ack 3920632056, win 28960, options [mss 1380,sackOK,TS val 434287326 ecr 236349370,nop,wscale 7], length 0
15:09:37.734753 IP wifi-131-179-33-163.host.ucla.edu.63922 > ndn-remap-p05.it.ucla.edu.6363: 
    Flags [.], ack 1, win 4104, options [nop,nop,TS val 236349374 ecr 434287326], length 0
15:09:37.734860 IP wifi-131-179-33-163.host.ucla.edu.63922 > ndn-remap-p05.it.ucla.edu.6363: 
    Flags [P.], seq 1:269, ack 1, win 4104, options [nop,nop,TS val 236349374 ecr 434287326], length 268
15:09:37.738731 IP ndn-remap-p05.it.ucla.edu.6363 > wifi-131-179-33-163.host.ucla.edu.63922: 
    Flags [.], ack 269, win 235, options [nop,nop,TS val 434287327 ecr 236349374], length 0
15:09:37.756521 IP ndn-remap-p05.it.ucla.edu.6363 > wifi-131-179-33-163.host.ucla.edu.63922: 
    Flags [P.], seq 1:646, ack 269, win 235, options [nop,nop,TS val 434287332 ecr 236349374], length 645
15:09:37.756563 IP wifi-131-179-33-163.host.ucla.edu.63922 > ndn-remap-p05.it.ucla.edu.6363: 
    Flags [.], ack 646, win 4083, options [nop,nop,TS val 236349395 ecr 434287332], length 0

note-19 and note-21 did not answer ALL questions in note-18. Complete answers in exactly same scenario (i.e. remote prefix registration) are needed. tcpdump trace should be attached as .pcap file, rather than pasted as text output.

How can I get the log lines of the router? I mean where can find, for example I tested on the REMAP, how can I find the log information of REMAP's NFD.

How can I get the log lines of the router?

You'll need to work with the operator of this router. If you don't know who's the operator, ask operators mailing list.

1. You can determine which NFD log sources need more detailed logs in order to help you diagnose the problem. I suggest Forwarder=DEBUG as a start.
2. Ask the operator to set the log levels, then send a signal to let NFD reload configuration; also, start a tcpdump session to capture NDN traffic.
3. You can run the test on a laptop connected to the router. Don't forget to raise log levels and tcpdump locally.
4. Ask the operator to restore the log levels, and send you the NFD logs and tcpdump trace.

OK, it takes a little bit time. I will coordinate with REMAP's operator Zhehao to figure it out. I will do the update in time once we figure it out.

Here are my comments, based on experimentation during the retreat:

I have kind of succeeded to run (remote/automatic) prefix registration using ECDSA keys, but I'm getting unpredictable NFD crashes and failures:

Also, registration doesn't succeed from the first time for all types of keys:

(ECDSA)

✘  17:07 ~/Downloads/1 [ master | ✚ 1 ] $ ndnsec-set-default /ndn/edu/ucla/%40GUEST/aa%40cs.ucla.edu

✘  17:07 ~/Downloads/1 [ master | ✚ 1 ] $ ./reg 128.97.98.7
FAILURE: authorization rejected
✔  17:08 ~/Downloads/1 [ master | ✚ 1 ] $ ./reg 128.97.98.7
FAILURE: failed in validating parameters
✔  17:08 ~/Downloads/1 [ master | ✚ 1 ] $ ./reg 128.97.98.7
SUCCESS waiting

(RSA)

✔  17:10 ~/Downloads/1 [ master | ✚ 1 ] $ ndnsec-set-default /ndn/edu/ucla/remap/%40GUEST/aa%40cs.ucla.edu
✔  17:10 ~/Downloads/1 [ master | ✚ 1 ] $ ./reg 128.97.98.7
FAILURE: failed in validating parameters
✔  17:10 ~/Downloads/1 [ master | ✚ 1 ] $ ./reg 128.97.98.7
SUCCESS waiting

The question is here:
From ndn-cxx/src/mgmt/nfd/control-command.cpp

void
ControlCommand::FieldValidator::validate(const ControlParameters& parameters) const
{
  const std::vector<bool>& presentFields = parameters.getPresentFields();

  for (size_t i = 0; i < CONTROL_PARAMETER_UBOUND; ++i) {
    bool isPresent = presentFields[i];
    if (m_required[i]) {
      if (!isPresent) {
        BOOST_THROW_EXCEPTION(ArgumentError(CONTROL_PARAMETER_FIELD[i] + " is required but "
                                            "missing"));
      }
    }
    else if (isPresent && !m_optional[i]) {
      BOOST_THROW_EXCEPTION(ArgumentError(CONTROL_PARAMETER_FIELD[i] + " is forbidden but "
                                          "present"));
    }
  }
}

There is a throw happened here so that the response is failed in validating parameters. For RibRegisterCommand, the parameter list is:

m_requestValidator
    .required(CONTROL_PARAMETER_NAME)
    .optional(CONTROL_PARAMETER_FACE_ID)
    .optional(CONTROL_PARAMETER_ORIGIN)
    .optional(CONTROL_PARAMETER_COST)
    .optional(CONTROL_PARAMETER_FLAGS)
    .optional(CONTROL_PARAMETER_EXPIRATION_PERIOD);

So the question is in NAME? Anyone may know the reason?

Reply to note-27:

I don't know what you are asking, but this code can validate the response ControlParameters from rib/register command according to RibMgmt spec, and throws if Name field is missing or a field not in the optional list appears.

The error message is failed in validating parameters, which can only happen in ControlCommand::FieldValidator::validate function.
Here is my test:

1. I use /ndn/edu/ucla/zhiyi as the intermediate CA and create a ECDSA certificate for /ndn/edu/ucla/zhiyi/ecdsa-node

2. I added the new config file which support ECDSA to my localhost part in nfd.conf

3. I added std::cout in the ControlCommand::FieldValidator::validate function and reinstall the ndn-cxx library and then reinstall the NFD.
   The function is now like:

   void
   ControlCommand::FieldValidator::validate(const ControlParameters& parameters) const
   {
     const std::vector<bool>& presentFields = parameters.getPresentFields();
   
     for (size_t i = 0; i < CONTROL_PARAMETER_UBOUND; ++i) {
       bool isPresent = presentFields[i];
       if (m_required[i]) {
        if (!isPresent) {
           std::cout << CONTROL_PARAMETER_FIELD[i] << " is required but missing" << std::endl;
           BOOST_THROW_EXCEPTION(ArgumentError(CONTROL_PARAMETER_FIELD[i] + " is required but missing"));
         }
       }
       else if (isPresent && !m_optional[i]) {
         std::cout << CONTROL_PARAMETER_FIELD[i] << " is forbidden but present" << std::endl;
         BOOST_THROW_EXCEPTION(ArgumentError(CONTROL_PARAMETER_FIELD[i] + " is forbidden but present"));
      }
     }
   }
   

4. I add the ECDSA certificate to repo and also add prefix to repo-ng.conf. Then I run repo-ng

5. I set /ndn/edu/ucla/zhiyi/ecdsa-node as default identity and run nfdc register /ndn udp://spurs.cs.ucla.edu. Here is the outputs. client part:

    ~ nfdc register /ndn udp://spurs.cs.ucla.edu
    Failed in name registration: failed in validating parameters (code: 400)
    ~ nfdc register /ndn udp://spurs.cs.ucla.edu
    Successful in name registration: ControlParameters(Name: /ndn, FaceId: 264, Origin: 255, Cost: 0, Flags: 0x1, )
   

   nfd part:

   1482628587.603428 INFO: [UnixStreamTransport] [id=0,local=unix:///private/var/run/nfd.sock,remote=fd://33] Creating transport
   1482628587.603447 INFO: [FaceTable] Added face id=267 remote=fd://33 local=unix:///private/var/run/nfd.sock
   1482628587.720483 INFO: [Transport] [id=267,local=unix:///private/var/run/nfd.sock,remote=fd://33] setState UP -> FAILED
   1482628587.720522 INFO: [Transport] [id=267,local=unix:///private/var/run/nfd.sock,remote=fd://33] setState FAILED -> CLOSED
   1482628587.737156 INFO: [FaceTable] Removed face id=267 remote=fd://33 local=unix:///private/var/run/nfd.sock
   1482628603.310834 INFO: [UnixStreamTransport] [id=0,local=unix:///private/var/run/nfd.sock,remote=fd://33] Creating transport
   1482628603.310858 INFO: [FaceTable] Added face id=268 remote=fd://33 local=unix:///private/var/run/nfd.sock
   Name is required but missing
   1482628605.807625 INFO: [Transport] [id=268,local=unix:///private/var/run/nfd.sock,remote=fd://33] setState UP -> FAILED
   1482628605.807752 INFO: [Transport] [id=268,local=unix:///private/var/run/nfd.sock,remote=fd://33] setState FAILED -> CLOSED
   1482628605.827329 INFO: [FaceTable] Removed face id=268 remote=fd://33 local=unix:///private/var/run/nfd.sock
   1482628626.390622 INFO: [UnixStreamTransport] [id=0,local=unix:///private/var/run/nfd.sock,remote=fd://33] Creating transport
   1482628626.390641 INFO: [FaceTable] Added face id=269 remote=fd://33 local=unix:///private/var/run/nfd.sock
   1482628626.473108 INFO: [RibManager] Adding route /ndn nexthop=264 origin=255 cost=0
   1482628626.473636 INFO: [Transport] [id=269,local=unix:///private/var/run/nfd.sock,remote=fd://33] setState UP -> FAILED
   1482628626.473662 INFO: [Transport] [id=269,local=unix:///private/var/run/nfd.sock,remote=fd://33] setState FAILED -> CLOSED
   1482628626.504099 INFO: [FaceTable] Removed face id=269 remote=fd://33 local=unix:///private/var/run/nfd.sock
   1482628626.581862 INFO: [AutoPrefixPropagator] no signing identity available for: /ndn
   

Result:
Notice the output of NFD. For the first nfdc command, there is a Name is required but missing. For the second command, everything is OK. Now we know the error is because that for the first time, the command has no name or wrong name? Anyone knows what's going on here?

It can only indicates the ControlParameters. The error string "failed in validating parameters" is only in the request validation part. The problem may exist in the command generation in end host side. I will check it.