[Ndn-interest] NACK

Marc.Mosko at parc.com Marc.Mosko at parc.com
Thu Jul 7 09:02:11 PDT 2016


As noted below, NDN has a method to embed a SignatureInfo and SignatureValue at the end of a name.  This only protects the name, not the other fields in an interest.  Those other fields could still be corrupted or maliciously altered.  For example, someone could change MinSuffixComponents from “0” to “1” and there may be no way for the Interest originator to know this because they still get back valid Data, just not all the Data they were asking for.  Or, one could modify the Exclude field to omit certain data packets or cause the same one to keep being returned.

I do not think intermediate nodes should try to parse NDN SignedInterest.  There is no deterministic way to figure out if a name is signed apart from knowledge of the application-layer framing and application security protocol.  One could try to guess by inspecting the last four name components of the Interest to see if they look like a signature, but that is no guarantee they are a signature.

My understanding from looking at the specs is that the last 4 name components would look like this, where “__” is a length of the bytes to the right.

%08%08<posix_time>/%08%08<nonce>/%08__%16__<signature_info>/%08__%17__<signature_value>

The issue is that generic name component (%08) is an opaque octet string, so it could be anything that just happens to have %16 or %17 as the 1st byte of name component, based on the application’s use.  I grant that if the %16__ evaluates to the correct length and %17__ evaluates to the correct length, then its more likely you have a signed interest, but you are still guessing.  You could keep on trying to parse further and further down in the data structures to see if it syntactically looks like a signature info (not the signature value, it has no TLV structure), but that is a lot of work to do on every Interest and makes an easy attack vector against forwarders. 

The Naming Conventions tech report (https://named-data.net/wp-content/uploads/2014/08/ndn-tr-22-ndn-memo-naming-conventions.pdf) reserves some special values as the 1st byte of a name component, but the values %16 and %17 are not in those reserved values, so these fall squarely in the opaque octet string realm.

Marc

> On Jul 6, 2016, at 7:12 PM, Klaus Schneider <klaus at email.arizona.edu> wrote:
> 
> I'm not an expert in NDN security, but it looks like it can:
> 
> http://named-data.net/doc/ndn-cxx/current/tutorials/security-library.html#signing-interests
> 
> http://named-data.net/doc/ndn-cxx/current/tutorials/signed-interest.html
> 
> Best regards.
> 
> 
> On 06.07.2016 18:49, Tanusree Chatterjee wrote:
>> Can any special Interest be signed to check its authenticity on other side?
>> On Jul 7, 2016 5:37 AM, "Klaus Schneider" <klaus at email.arizona.edu
>> <mailto:klaus at email.arizona.edu>> wrote:
>> >
>> > I think there are at least two cases in which the verification fails:
>> 1) random errors which couldn't be corrected by a lower layer and 2)
>> purposeful manipulation of the packet by a malicious attacker.
>> >
>> > I don't know how easy these are to distinguish, but in both cases
>> it's likely that the in-network routers have to solve the problem by
>> forwarding interests on a different path.
>> >
>> > There is a trade-off in how persistently routers should retransmit
>> before notifying the consumer: In one extreme all routers on the path
>> try all of their paths before sending a NACK back (potentially
>> increasing the delay to the point where the consumer no longer needs the
>> data). In the other extreme, the NACK goes directly to the consumer and
>> then the consumer sends a retransmission to tell the routers to try a
>> different path (increasing delay and packet overhead compared to routers
>> retransmitting on their own).
>> >
>> > It is also useful to identify how fine-granular the problem is: Did
>> the data corruption affect 1) just a single packet, 2) many/most packets
>> under that FIB-prefix-face combination, or 3) all packets send over that
>> face?
>> >
>> > This information can then be used to make better decisions at the
>> forwarding layer, like moving traffic of the affected "flow"/FIB
>> prefix/face. I think the problem is quite similar to the one of congestion.
>> >
>> > Best regards,
>> > Klaus
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On 30.06.2016 14:29, Cesar Ghali wrote:
>> >>
>> >> I just want to highlight that interest NACKs that Lixia mentioned are
>> >> studied as two types of NACK messages in the paper that Gene shared
>> earlier:
>> >> http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=7288477
>> >>
>> >> Cesar
>> >>
>> >>
>> >> On Wednesday, June 29, 2016, Lixia Zhang <lixia at cs.ucla.edu
>> <mailto:lixia at cs.ucla.edu>
>> >> <mailto:lixia at cs.ucla.edu <mailto:lixia at cs.ucla.edu>>> wrote:
>> >>
>> >>     one detail that I have not seen mentioned so far: interest NACK
>> >>     versus data packet NACK.
>> >>
>> >>     It seems to me that interest NACK is relatively well understood: a
>> >>     forwarding node failed to forward a received interest hence
>> >>     generates a NACK to its previous hop.
>> >>     data NACK seems to me not understood as fully:
>> >>     a) if a consumer gets a data packet that's not what it wants, it'd
>> >>     retry the interest in some way;
>> >>     b) any other forwarding node could drop an incorrect data packet, it
>> >>     can; whether it should generate a NACK on behalf of the consumer
>> >>     seems a separable question.
>> >>
>> >>
>> >>      > On Jun 28, 2016, at 1:47 AM, Tanusree Chatterjee
>> >>     <tnsr.chatterjee at gmail.com <mailto:tnsr.chatterjee at gmail.com>>
>> wrote:
>> >>      >
>> >>      > If a data packet is modified and detected during verification,
>> >>     can forwarder send a NACK. How the data can be resend in this case?
>> >>     If consumer is not satisfied it has to send the same interest again,
>> >>     is there any other way out to get the data which may not been
>> >>     correctly received due to some modification.
>> >>      >
>> >>      > -- Regards,
>> >>      > Tanusree Chatterjee
>> >>      >
>> >>      > _______________________________________________
>> >>      > Ndn-interest mailing list
>> >>      > Ndn-interest at lists.cs.ucla.edu
>> <mailto:Ndn-interest at lists.cs.ucla.edu>
>> >>      > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>> >>
>> >>
>> >>     _______________________________________________
>> >>     Ndn-interest mailing list
>> >> Ndn-interest at lists.cs.ucla.edu <mailto:Ndn-interest at lists.cs.ucla.edu>
>> >> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> Ndn-interest mailing list
>> >> Ndn-interest at lists.cs.ucla.edu <mailto:Ndn-interest at lists.cs.ucla.edu>
>> >> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>> >>
>> > _______________________________________________
>> > Ndn-interest mailing list
>> > Ndn-interest at lists.cs.ucla.edu <mailto:Ndn-interest at lists.cs.ucla.edu>
>> > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>> 
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest





More information about the Ndn-interest mailing list