From christian.tschudin at unibas.ch Mon Jun 1 04:45:12 2015 From: christian.tschudin at unibas.ch (christian.tschudin at unibas.ch) Date: Mon, 1 Jun 2015 13:45:12 +0200 (CEST) Subject: [Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256? In-Reply-To: References: Message-ID: On Wed, 27 May 2015, Thompson, Jeff wrote: > Hello Christian, > > Two questions: > > 1. Can you repeat your suggestion that the spec allow a truncated form > of the key digest, for example the first 8 bytes of the key digest > instead of the full 32 bytes? Hi Jeff, This is a trick that Marc Mosko used when we presented the 1+0 encoding at the January ICNRG interim meeting: Just reduce then number of KeyID-Bits (2 Bytes, in our case), if need be. The observation is that the key digest is for convenience, not security reasons: If you have many parties for which you have to maintain different symmetric keys, it is nice to quickly identify which key to use for validating the signature. But theoretically, you could just try out all symmetric keys you have for some peer. Rivest's "chaffing and winnowing" even relies on not sending any KeyID bits, on purpose. > 2. If you want this suggestion on the spec, what is the best way to > describe the computation of the key digest if we don't describe the > HMAC algorithm in the spec? First, it could be made optional. But then I think it would be good to write down how the digest is computed, as you suggest (because RFC 2104 does not cover it, right?) Adapted from previous text of yours: "The Key must not be included in the signature but optionally a full or partial KeyDigest can be put in the KeyLocator block of the SignatureInfo field. If the byte length of Key is less than or equal to the SHA256 block length (64 bytes) then the full length KeyDigest is SHA256(Key). But if the byte length of Key is greater than 64 bytes, the KeyValue is already SHA256(Key) with zeros appended, so in this case the full length KeyDigest is SHA256(SHA256(Key)). The optional KeyDigest bits consist of 2 to 32 of the most-significant (=left-most) bytes of the full length KeyDigest. For the convenience of the validator and if packet size permits, it is recommended to include the full 32 bytes." Would that be precise enough? best, c > > Thanks, > - Jeff T > > From: Junxiao Shi > Date: Wednesday, May 27, 2015 at 5:10 > To: Jeff Thompson > Cc: "ndn-interest at lists.cs.ucla.edu" > Subject: Re: [Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256? > > Dear folks > Details about HMAC algorithm, or any other crypto algorithm, SHOULD NOT appear in NDN Packet Format > spec. > Instead, the implementer should be referred to RFC. > > Those details are duplication of RFC, and they would make the spec unnecessary long. > They also increase the probability of incorrect implementations because the implementer is unsure > whether it's exactly same as what she/he has in the library, and would have to implement it again. > "don't have HMAC in their crypto library" is not a valid argument - it's easier to find an > RFC-compliant library or snippet for most languages than to implement according to the (duplicate of > RFC in) spec. > > Yours, Junxiao > > On Mon, May 18, 2015 at 4:00 PM, Thompson, Jeff wrote: > The proposed SignatureHmacWithSha256 spec (below) repeats the details of the HMAC > algorithm from RFC 2104. But should the details be removed and just refer to RFC 2104? > Arguments for keeping the details are that it provides details for the discussion of > creating the KeyDIgest and also because some applications don't have HMAC in their crypto > library and need to implement it directly. An argument against keeping the details is that > the info is in RFC 2104 so an application writer can read the RFC if needed, and that we > don't repeat the details of other algorithms like SHA-256. > > Any opinions on removing the algorithm details? > > - Jeff T > > > From Marc.Mosko at parc.com Mon Jun 1 07:24:22 2015 From: Marc.Mosko at parc.com (Marc.Mosko at parc.com) Date: Mon, 1 Jun 2015 14:24:22 +0000 Subject: [Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256? In-Reply-To: References: Message-ID: <1C839A4C-7C50-4847-8428-B8098983536C@parc.com> The proposed spec already defines KeyValue as the right-padded (for short keys) or sha256 (for long keys) of the Key. I would define the KeyDigest as the SHA256(KeyValue) and not repeat the same algorithm used to compute KeyValue. With regard to repeating the definition of HMAC, I would not do that but simply say that the ?text? input to HMAC is {Name, MetaInfo, Content, SignatureInfo} TLVs. For symmetric key systems, like HMAC, I think it is also acceptable to use an agreed upon integer identifier for the shared secret, as determined by a key exchange protocol (e.g. an ISAKMP SPI). I don?t think that symmetric key KeyDigests need to be derived from the key. That?s different than public key systems, where the the KeyDigest is used like the Subject Key Identifier (RFC 5280 4.2.1.2) and derived from the actual public key. Marc On Jun 1, 2015, at 1:45 PM, wrote: > On Wed, 27 May 2015, Thompson, Jeff wrote: > >> Hello Christian, >> Two questions: >> 1. Can you repeat your suggestion that the spec allow a truncated form of the key digest, for example the first 8 bytes of the key digest instead of the full 32 bytes? > > Hi Jeff, > > This is a trick that Marc Mosko used when we presented the 1+0 encoding at the January ICNRG interim meeting: Just reduce then number of KeyID-Bits (2 Bytes, in our case), if need be. > > The observation is that the key digest is for convenience, not security reasons: If you have many parties for which you have to maintain different symmetric keys, it is nice to quickly identify which key to use for validating the signature. But theoretically, you could just try out all symmetric keys you have for some peer. Rivest's "chaffing and winnowing" even relies on not sending any KeyID bits, on purpose. > > >> 2. If you want this suggestion on the spec, what is the best way to describe the computation of the key digest if we don't describe the HMAC algorithm in the spec? > > First, it could be made optional. But then I think it would be good to write down how the digest is computed, as you suggest (because RFC 2104 does not cover it, right?) > > Adapted from previous text of yours: > > "The Key must not be included in the signature but optionally a full or partial KeyDigest can be put in the KeyLocator block of the SignatureInfo field. If the byte length of Key is less than or equal to the SHA256 block length (64 bytes) then the full length KeyDigest is SHA256(Key). But if the byte length of Key is greater than 64 bytes, the KeyValue is already SHA256(Key) with zeros appended, so in this case the full length KeyDigest is SHA256(SHA256(Key)). The optional KeyDigest bits consist of 2 to 32 of the most-significant (=left-most) bytes of the full length KeyDigest. For the convenience of the validator and if packet size permits, it is recommended to include the full 32 bytes." > > Would that be precise enough? > > best, c > >> Thanks, >> - Jeff T >> From: Junxiao Shi >> Date: Wednesday, May 27, 2015 at 5:10 >> To: Jeff Thompson >> Cc: "ndn-interest at lists.cs.ucla.edu" >> Subject: Re: [Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256? >> Dear folks >> Details about HMAC algorithm, or any other crypto algorithm, SHOULD NOT appear in NDN Packet Format >> spec. >> Instead, the implementer should be referred to RFC. >> Those details are duplication of RFC, and they would make the spec unnecessary long. >> They also increase the probability of incorrect implementations because the implementer is unsure >> whether it's exactly same as what she/he has in the library, and would have to implement it again. >> "don't have HMAC in their crypto library" is not a valid argument - it's easier to find an >> RFC-compliant library or snippet for most languages than to implement according to the (duplicate of >> RFC in) spec. >> Yours, Junxiao >> On Mon, May 18, 2015 at 4:00 PM, Thompson, Jeff wrote: >> The proposed SignatureHmacWithSha256 spec (below) repeats the details of the HMAC >> algorithm from RFC 2104. But should the details be removed and just refer to RFC 2104? >> Arguments for keeping the details are that it provides details for the discussion of >> creating the KeyDIgest and also because some applications don't have HMAC in their crypto >> library and need to implement it directly. An argument against keeping the details is that >> the info is in RFC 2104 so an application writer can read the RFC if needed, and that we >> don't repeat the details of other algorithms like SHA-256. >> Any opinions on removing the algorithm details? >> - Jeff T >> > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest From christian.tschudin at unibas.ch Mon Jun 1 09:48:44 2015 From: christian.tschudin at unibas.ch (christian.tschudin at unibas.ch) Date: Mon, 1 Jun 2015 18:48:44 +0200 (CEST) Subject: [Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256? In-Reply-To: <1C839A4C-7C50-4847-8428-B8098983536C@parc.com> References: <1C839A4C-7C50-4847-8428-B8098983536C@parc.com> Message-ID: I understood Jeff wanting to make the spec as self-contained as possible, but I doubt that a reference to an HMAC-internal variable is helping. (It translate into "Dear NDN implementor, to implement this two-line feature you need to read the following RFC and locate that Keyval variable in your favorit shrinked-wrapped library." As a probe: the Python hashlib API page does not reference it). So better write at least that part out? Regarding how to choose the KeyId (hash, ISAKMP SPI etc): I see, so it make sense to point out the many possibilities to pick your way. At least an advantage of the currently discussed hashing approach would be to not add another document to read 8-) best, c On Mon, 1 Jun 2015, Marc.Mosko at parc.com wrote: > The proposed spec already defines KeyValue as the right-padded (for short keys) or sha256 (for long keys) of the Key. I would define the KeyDigest as the SHA256(KeyValue) and not repeat the same algorithm used to compute KeyValue. > > With regard to repeating the definition of HMAC, I would not do that but simply say that the ?text? input to HMAC is {Name, MetaInfo, Content, SignatureInfo} TLVs. > > For symmetric key systems, like HMAC, I think it is also acceptable to use an agreed upon integer identifier for the shared secret, as determined by a key exchange protocol (e.g. an ISAKMP SPI). I don?t think that symmetric key KeyDigests need to be derived from the key. That?s different than public key systems, where the the KeyDigest is used like the Subject Key Identifier (RFC 5280 4.2.1.2) and derived from the actual public key. > > Marc > > On Jun 1, 2015, at 1:45 PM, wrote: > >> On Wed, 27 May 2015, Thompson, Jeff wrote: >> >>> Hello Christian, >>> Two questions: >>> 1. Can you repeat your suggestion that the spec allow a truncated form of the key digest, for example the first 8 bytes of the key digest instead of the full 32 bytes? >> >> Hi Jeff, >> >> This is a trick that Marc Mosko used when we presented the 1+0 encoding at the January ICNRG interim meeting: Just reduce then number of KeyID-Bits (2 Bytes, in our case), if need be. >> >> The observation is that the key digest is for convenience, not security reasons: If you have many parties for which you have to maintain different symmetric keys, it is nice to quickly identify which key to use for validating the signature. But theoretically, you could just try out all symmetric keys you have for some peer. Rivest's "chaffing and winnowing" even relies on not sending any KeyID bits, on purpose. >> >> >>> 2. If you want this suggestion on the spec, what is the best way to describe the computation of the key digest if we don't describe the HMAC algorithm in the spec? >> >> First, it could be made optional. But then I think it would be good to write down how the digest is computed, as you suggest (because RFC 2104 does not cover it, right?) >> >> Adapted from previous text of yours: >> >> "The Key must not be included in the signature but optionally a full or partial KeyDigest can be put in the KeyLocator block of the SignatureInfo field. If the byte length of Key is less than or equal to the SHA256 block length (64 bytes) then the full length KeyDigest is SHA256(Key). But if the byte length of Key is greater than 64 bytes, the KeyValue is already SHA256(Key) with zeros appended, so in this case the full length KeyDigest is SHA256(SHA256(Key)). The optional KeyDigest bits consist of 2 to 32 of the most-significant (=left-most) bytes of the full length KeyDigest. For the convenience of the validator and if packet size permits, it is recommended to include the full 32 bytes." >> >> Would that be precise enough? >> >> best, c >> >>> Thanks, >>> - Jeff T >>> From: Junxiao Shi >>> Date: Wednesday, May 27, 2015 at 5:10 >>> To: Jeff Thompson >>> Cc: "ndn-interest at lists.cs.ucla.edu" >>> Subject: Re: [Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256? >>> Dear folks >>> Details about HMAC algorithm, or any other crypto algorithm, SHOULD NOT appear in NDN Packet Format >>> spec. >>> Instead, the implementer should be referred to RFC. >>> Those details are duplication of RFC, and they would make the spec unnecessary long. >>> They also increase the probability of incorrect implementations because the implementer is unsure >>> whether it's exactly same as what she/he has in the library, and would have to implement it again. >>> "don't have HMAC in their crypto library" is not a valid argument - it's easier to find an >>> RFC-compliant library or snippet for most languages than to implement according to the (duplicate of >>> RFC in) spec. >>> Yours, Junxiao >>> On Mon, May 18, 2015 at 4:00 PM, Thompson, Jeff wrote: >>> The proposed SignatureHmacWithSha256 spec (below) repeats the details of the HMAC >>> algorithm from RFC 2104. But should the details be removed and just refer to RFC 2104? >>> Arguments for keeping the details are that it provides details for the discussion of >>> creating the KeyDIgest and also because some applications don't have HMAC in their crypto >>> library and need to implement it directly. An argument against keeping the details is that >>> the info is in RFC 2104 so an application writer can read the RFC if needed, and that we >>> don't repeat the details of other algorithms like SHA-256. >>> Any opinions on removing the algorithm details? >>> - Jeff T >>> >> _______________________________________________ >> Ndn-interest mailing list >> Ndn-interest at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > > From lixia at CS.UCLA.EDU Mon Jun 1 10:26:09 2015 From: lixia at CS.UCLA.EDU (Lixia Zhang) Date: Mon, 1 Jun 2015 10:26:09 -0700 Subject: [Ndn-interest] Call for Demos and Posters: ACM ICN'15 References: <1BBB5B8548ACEF4093CE0051D9EA9A6B7A2BB790@ORSMSX105.amr.corp.intel.com> Message-ID: <92ECB224-309F-47BB-9BD8-37A3FCD36969@cs.ucla.edu> 2nd ACM Information-Centric Networking Conference (ICN?15) Sep. 30 - Oct. 2, 2015 http://conferences2.sigcomm.org/acm-icn/2015/ Call for Demos and Posters: Deadline June 26, 2015 Dear all, The 2nd ACM ICN conference will take place in San Francisco this year. We are soliciting posters and demos intended to showcase work-in-progress research. Topics of interest include ICN design, implementation and evaluation, as well as others listed here . We strongly encourage student and industry submissions. Both demos and posters should be accompanied by a 2 page extended abstract, which will be published in the conference proceedings. Further details can be found at: http://conferences.sigcomm.org/acm-icn/2015/cfd.php Best regards, Eve and Gareth (Demo and Poster Chairs) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jefft0 at remap.ucla.edu Mon Jun 1 10:42:55 2015 From: jefft0 at remap.ucla.edu (Thompson, Jeff) Date: Mon, 1 Jun 2015 17:42:55 +0000 Subject: [Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256? In-Reply-To: References: <1C839A4C-7C50-4847-8428-B8098983536C@parc.com> Message-ID: Hi Christian and Marc, I think we agree that we'll spell out how to get the key digest from the Key, but not spell out the HMAC algorithm itself (or how Key is padded to make the internally-used KeyValue). If the applications want to use an integer identifier for the Key, then the KeyLocator would need to be a Name with the integer as a name component, right? Also, if the "truncated key digest" (maybe as short as a byte) is used as an identifier, I wonder whether this should be in a Name too. This way, we don't mess with the semantics of KeyDigest which usually means the full digest. What do you think? Thanks, - Jeff T On 2015/6/1, 9:48, "christian.tschudin at unibas.ch" wrote: >I understood Jeff wanting to make the spec as self-contained as >possible, but I doubt that a reference to an HMAC-internal variable is >helping. > >(It translate into "Dear NDN implementor, to implement this two-line >feature you need to read the following RFC and locate that Keyval >variable in your favorit shrinked-wrapped library." As a probe: the >Python hashlib API page does not reference it). > >So better write at least that part out? > >Regarding how to choose the KeyId (hash, ISAKMP SPI etc): I see, so it >make sense to point out the many possibilities to pick your way. At >least an advantage of the currently discussed hashing approach would >be to not add another document to read 8-) > >best, c > > >On Mon, 1 Jun 2015, Marc.Mosko at parc.com wrote: > >> The proposed spec already defines KeyValue as the right-padded (for >>short keys) or sha256 (for long keys) of the Key. I would define the >>KeyDigest as the SHA256(KeyValue) and not repeat the same algorithm used >>to compute KeyValue. >> >> With regard to repeating the definition of HMAC, I would not do that >>but simply say that the ?text? input to HMAC is {Name, MetaInfo, >>Content, SignatureInfo} TLVs. >> >> For symmetric key systems, like HMAC, I think it is also acceptable to >>use an agreed upon integer identifier for the shared secret, as >>determined by a key exchange protocol (e.g. an ISAKMP SPI). I don?t >>think that symmetric key KeyDigests need to be derived from the key. >>That?s different than public key systems, where the the KeyDigest is >>used like the Subject Key Identifier (RFC 5280 4.2.1.2) and derived from >>the actual public key. >> >> Marc >> >> On Jun 1, 2015, at 1:45 PM, >> wrote: >> >>> On Wed, 27 May 2015, Thompson, Jeff wrote: >>> >>>> Hello Christian, >>>> Two questions: >>>> 1. Can you repeat your suggestion that the spec allow a truncated >>>>form of the key digest, for example the first 8 bytes of the key >>>>digest instead of the full 32 bytes? >>> >>> Hi Jeff, >>> >>> This is a trick that Marc Mosko used when we presented the 1+0 >>>encoding at the January ICNRG interim meeting: Just reduce then number >>>of KeyID-Bits (2 Bytes, in our case), if need be. >>> >>> The observation is that the key digest is for convenience, not >>>security reasons: If you have many parties for which you have to >>>maintain different symmetric keys, it is nice to quickly identify which >>>key to use for validating the signature. But theoretically, you could >>>just try out all symmetric keys you have for some peer. Rivest's >>>"chaffing and winnowing" even relies on not sending any KeyID bits, on >>>purpose. >>> >>> >>>> 2. If you want this suggestion on the spec, what is the best way to >>>>describe the computation of the key digest if we don't describe the >>>>HMAC algorithm in the spec? >>> >>> First, it could be made optional. But then I think it would be good to >>>write down how the digest is computed, as you suggest (because RFC 2104 >>>does not cover it, right?) >>> >>> Adapted from previous text of yours: >>> >>> "The Key must not be included in the signature but optionally a full >>>or partial KeyDigest can be put in the KeyLocator block of the >>>SignatureInfo field. If the byte length of Key is less than or equal to >>>the SHA256 block length (64 bytes) then the full length KeyDigest is >>>SHA256(Key). But if the byte length of Key is greater than 64 bytes, >>>the KeyValue is already SHA256(Key) with zeros appended, so in this >>>case the full length KeyDigest is SHA256(SHA256(Key)). The optional >>>KeyDigest bits consist of 2 to 32 of the most-significant (=left-most) >>>bytes of the full length KeyDigest. For the convenience of the >>>validator and if packet size permits, it is recommended to include the >>>full 32 bytes." >>> >>> Would that be precise enough? >>> >>> best, c >>> >>>> Thanks, >>>> - Jeff T >>>> From: Junxiao Shi >>>> Date: Wednesday, May 27, 2015 at 5:10 >>>> To: Jeff Thompson >>>> Cc: "ndn-interest at lists.cs.ucla.edu" >>>> Subject: Re: [Ndn-interest] Describe the HMAC algorithm in >>>>SignatureHmacWithSha256? >>>> Dear folks >>>> Details about HMAC algorithm, or any other crypto algorithm, SHOULD >>>>NOT appear in NDN Packet Format >>>> spec. >>>> Instead, the implementer should be referred to RFC. >>>> Those details are duplication of RFC, and they would make the spec >>>>unnecessary long. >>>> They also increase the probability of incorrect implementations >>>>because the implementer is unsure >>>> whether it's exactly same as what she/he has in the library, and >>>>would have to implement it again. >>>> "don't have HMAC in their crypto library" is not a valid argument - >>>>it's easier to find an >>>> RFC-compliant library or snippet for most languages than to implement >>>>according to the (duplicate of >>>> RFC in) spec. >>>> Yours, Junxiao >>>> On Mon, May 18, 2015 at 4:00 PM, Thompson, Jeff >>>> wrote: >>>> The proposed SignatureHmacWithSha256 spec (below) repeats the >>>>details of the HMAC >>>> algorithm from RFC 2104. But should the details be removed and >>>>just refer to RFC 2104? >>>> Arguments for keeping the details are that it provides details >>>>for the discussion of >>>> creating the KeyDIgest and also because some applications don't >>>>have HMAC in their crypto >>>> library and need to implement it directly. An argument against >>>>keeping the details is that >>>> the info is in RFC 2104 so an application writer can read the >>>>RFC if needed, and that we >>>> don't repeat the details of other algorithms like SHA-256. >>>> Any opinions on removing the algorithm details? >>>> - Jeff T >>>> >>> _______________________________________________ >>> Ndn-interest mailing list >>> Ndn-interest at lists.cs.ucla.edu >>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest >> From christian.tschudin at unibas.ch Mon Jun 1 12:10:58 2015 From: christian.tschudin at unibas.ch (christian.tschudin at unibas.ch) Date: Mon, 1 Jun 2015 21:10:58 +0200 (CEST) Subject: [Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256? In-Reply-To: References: <1C839A4C-7C50-4847-8428-B8098983536C@parc.com> Message-ID: Hi Jeff, maybe I make a too far-fetching intepretation of your suggestion, but this would be a hefty price to pay: Forcing all principles to name their keys, globally, just to avoid the introduction of "truncated key digest" in the spec? Concept-wise there is no key to locate and fetch (via NDN) here, just an optional speedup inside the validator's memory. best, christian On Mon, 1 Jun 2015, Thompson, Jeff wrote: > Hi Christian and Marc, > > I think we agree that we'll spell out how to get the key digest from the > Key, but not spell out the HMAC algorithm itself (or how Key is padded to > make the internally-used KeyValue). > > If the applications want to use an integer identifier for the Key, then > the KeyLocator would need to be a Name with the integer as a name > component, right? > > Also, if the "truncated key digest" (maybe as short as a byte) is used as > an identifier, I wonder whether this should be in a Name too. This way, > we don't mess with the semantics of KeyDigest which usually means the full > digest. What do you think? > > Thanks, > - Jeff T > > On 2015/6/1, 9:48, "christian.tschudin at unibas.ch" > wrote: > >> I understood Jeff wanting to make the spec as self-contained as >> possible, but I doubt that a reference to an HMAC-internal variable is >> helping. >> >> (It translate into "Dear NDN implementor, to implement this two-line >> feature you need to read the following RFC and locate that Keyval >> variable in your favorit shrinked-wrapped library." As a probe: the >> Python hashlib API page does not reference it). >> >> So better write at least that part out? >> >> Regarding how to choose the KeyId (hash, ISAKMP SPI etc): I see, so it >> make sense to point out the many possibilities to pick your way. At >> least an advantage of the currently discussed hashing approach would >> be to not add another document to read 8-) >> >> best, c >> >> >> On Mon, 1 Jun 2015, Marc.Mosko at parc.com wrote: >> >>> The proposed spec already defines KeyValue as the right-padded (for >>> short keys) or sha256 (for long keys) of the Key. I would define the >>> KeyDigest as the SHA256(KeyValue) and not repeat the same algorithm used >>> to compute KeyValue. >>> >>> With regard to repeating the definition of HMAC, I would not do that >>> but simply say that the ?text? input to HMAC is {Name, MetaInfo, >>> Content, SignatureInfo} TLVs. >>> >>> For symmetric key systems, like HMAC, I think it is also acceptable to >>> use an agreed upon integer identifier for the shared secret, as >>> determined by a key exchange protocol (e.g. an ISAKMP SPI). I don?t >>> think that symmetric key KeyDigests need to be derived from the key. >>> That?s different than public key systems, where the the KeyDigest is >>> used like the Subject Key Identifier (RFC 5280 4.2.1.2) and derived from >>> the actual public key. >>> >>> Marc >>> >>> On Jun 1, 2015, at 1:45 PM, >>> wrote: >>> >>>> On Wed, 27 May 2015, Thompson, Jeff wrote: >>>> >>>>> Hello Christian, >>>>> Two questions: >>>>> 1. Can you repeat your suggestion that the spec allow a truncated >>>>> form of the key digest, for example the first 8 bytes of the key >>>>> digest instead of the full 32 bytes? >>>> >>>> Hi Jeff, >>>> >>>> This is a trick that Marc Mosko used when we presented the 1+0 >>>> encoding at the January ICNRG interim meeting: Just reduce then number >>>> of KeyID-Bits (2 Bytes, in our case), if need be. >>>> >>>> The observation is that the key digest is for convenience, not >>>> security reasons: If you have many parties for which you have to >>>> maintain different symmetric keys, it is nice to quickly identify which >>>> key to use for validating the signature. But theoretically, you could >>>> just try out all symmetric keys you have for some peer. Rivest's >>>> "chaffing and winnowing" even relies on not sending any KeyID bits, on >>>> purpose. >>>> >>>> >>>>> 2. If you want this suggestion on the spec, what is the best way to >>>>> describe the computation of the key digest if we don't describe the >>>>> HMAC algorithm in the spec? >>>> >>>> First, it could be made optional. But then I think it would be good to >>>> write down how the digest is computed, as you suggest (because RFC 2104 >>>> does not cover it, right?) >>>> >>>> Adapted from previous text of yours: >>>> >>>> "The Key must not be included in the signature but optionally a full >>>> or partial KeyDigest can be put in the KeyLocator block of the >>>> SignatureInfo field. If the byte length of Key is less than or equal to >>>> the SHA256 block length (64 bytes) then the full length KeyDigest is >>>> SHA256(Key). But if the byte length of Key is greater than 64 bytes, >>>> the KeyValue is already SHA256(Key) with zeros appended, so in this >>>> case the full length KeyDigest is SHA256(SHA256(Key)). The optional >>>> KeyDigest bits consist of 2 to 32 of the most-significant (=left-most) >>>> bytes of the full length KeyDigest. For the convenience of the >>>> validator and if packet size permits, it is recommended to include the >>>> full 32 bytes." >>>> >>>> Would that be precise enough? >>>> >>>> best, c >>>> >>>>> Thanks, >>>>> - Jeff T >>>>> From: Junxiao Shi >>>>> Date: Wednesday, May 27, 2015 at 5:10 >>>>> To: Jeff Thompson >>>>> Cc: "ndn-interest at lists.cs.ucla.edu" >>>>> Subject: Re: [Ndn-interest] Describe the HMAC algorithm in >>>>> SignatureHmacWithSha256? >>>>> Dear folks >>>>> Details about HMAC algorithm, or any other crypto algorithm, SHOULD >>>>> NOT appear in NDN Packet Format >>>>> spec. >>>>> Instead, the implementer should be referred to RFC. >>>>> Those details are duplication of RFC, and they would make the spec >>>>> unnecessary long. >>>>> They also increase the probability of incorrect implementations >>>>> because the implementer is unsure >>>>> whether it's exactly same as what she/he has in the library, and >>>>> would have to implement it again. >>>>> "don't have HMAC in their crypto library" is not a valid argument - >>>>> it's easier to find an >>>>> RFC-compliant library or snippet for most languages than to implement >>>>> according to the (duplicate of >>>>> RFC in) spec. >>>>> Yours, Junxiao >>>>> On Mon, May 18, 2015 at 4:00 PM, Thompson, Jeff >>>>> wrote: >>>>> The proposed SignatureHmacWithSha256 spec (below) repeats the >>>>> details of the HMAC >>>>> algorithm from RFC 2104. But should the details be removed and >>>>> just refer to RFC 2104? >>>>> Arguments for keeping the details are that it provides details >>>>> for the discussion of >>>>> creating the KeyDIgest and also because some applications don't >>>>> have HMAC in their crypto >>>>> library and need to implement it directly. An argument against >>>>> keeping the details is that >>>>> the info is in RFC 2104 so an application writer can read the >>>>> RFC if needed, and that we >>>>> don't repeat the details of other algorithms like SHA-256. >>>>> Any opinions on removing the algorithm details? >>>>> - Jeff T >>>>> >>>> _______________________________________________ >>>> Ndn-interest mailing list >>>> Ndn-interest at lists.cs.ucla.edu >>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest >>> > > From Marc.Mosko at parc.com Mon Jun 1 14:32:17 2015 From: Marc.Mosko at parc.com (Marc.Mosko at parc.com) Date: Mon, 1 Jun 2015 21:32:17 +0000 Subject: [Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256? In-Reply-To: References: <1C839A4C-7C50-4847-8428-B8098983536C@parc.com> Message-ID: <49DE0EF2-012F-4996-80EC-FC52BCCF9BC6@parc.com> I think overloading the use of a Name to avoid overloading the use of KeyDigest is trading one thing for another. If the Name is only an SPI (32-bit integer), for example, then its not really a name either as it cannot be fetched. I agree that if KeyDigest is defined as the SHA256 of something (as it is in the ndn spec), then its not the right container for an index, and possibly not the right container for a truncated digest. To avoid mis-using a Name and mis-using a KeyDigest, then it looks like one would need to introduce a new TLV container ?KeyIndex? or something like that to accommodate negotiated key IDs in a key exchange protocol. To accomodate truncated KeyDigest, one could use a new container. However, if it is a truncated SHA256, then I think it would be obvious that it is only the ?length? bytes of the SHA256, not the full 32-bytes. I could see allowing a shorter (left truncated) SHA256 in the KeyDigest without loss of specificity. Marc On Jun 1, 2015, at 7:42 PM, Thompson, Jeff > wrote: Hi Christian and Marc, I think we agree that we'll spell out how to get the key digest from the Key, but not spell out the HMAC algorithm itself (or how Key is padded to make the internally-used KeyValue). If the applications want to use an integer identifier for the Key, then the KeyLocator would need to be a Name with the integer as a name component, right? Also, if the "truncated key digest" (maybe as short as a byte) is used as an identifier, I wonder whether this should be in a Name too. This way, we don't mess with the semantics of KeyDigest which usually means the full digest. What do you think? Thanks, - Jeff T On 2015/6/1, 9:48, "christian.tschudin at unibas.ch" > wrote: I understood Jeff wanting to make the spec as self-contained as possible, but I doubt that a reference to an HMAC-internal variable is helping. (It translate into "Dear NDN implementor, to implement this two-line feature you need to read the following RFC and locate that Keyval variable in your favorit shrinked-wrapped library." As a probe: the Python hashlib API page does not reference it). So better write at least that part out? Regarding how to choose the KeyId (hash, ISAKMP SPI etc): I see, so it make sense to point out the many possibilities to pick your way. At least an advantage of the currently discussed hashing approach would be to not add another document to read 8-) best, c On Mon, 1 Jun 2015, Marc.Mosko at parc.com wrote: The proposed spec already defines KeyValue as the right-padded (for short keys) or sha256 (for long keys) of the Key. I would define the KeyDigest as the SHA256(KeyValue) and not repeat the same algorithm used to compute KeyValue. With regard to repeating the definition of HMAC, I would not do that but simply say that the ?text? input to HMAC is {Name, MetaInfo, Content, SignatureInfo} TLVs. For symmetric key systems, like HMAC, I think it is also acceptable to use an agreed upon integer identifier for the shared secret, as determined by a key exchange protocol (e.g. an ISAKMP SPI). I don?t think that symmetric key KeyDigests need to be derived from the key. That?s different than public key systems, where the the KeyDigest is used like the Subject Key Identifier (RFC 5280 4.2.1.2) and derived from the actual public key. Marc On Jun 1, 2015, at 1:45 PM, > > wrote: On Wed, 27 May 2015, Thompson, Jeff wrote: Hello Christian, Two questions: 1. Can you repeat your suggestion that the spec allow a truncated form of the key digest, for example the first 8 bytes of the key digest instead of the full 32 bytes? Hi Jeff, This is a trick that Marc Mosko used when we presented the 1+0 encoding at the January ICNRG interim meeting: Just reduce then number of KeyID-Bits (2 Bytes, in our case), if need be. The observation is that the key digest is for convenience, not security reasons: If you have many parties for which you have to maintain different symmetric keys, it is nice to quickly identify which key to use for validating the signature. But theoretically, you could just try out all symmetric keys you have for some peer. Rivest's "chaffing and winnowing" even relies on not sending any KeyID bits, on purpose. 2. If you want this suggestion on the spec, what is the best way to describe the computation of the key digest if we don't describe the HMAC algorithm in the spec? First, it could be made optional. But then I think it would be good to write down how the digest is computed, as you suggest (because RFC 2104 does not cover it, right?) Adapted from previous text of yours: "The Key must not be included in the signature but optionally a full or partial KeyDigest can be put in the KeyLocator block of the SignatureInfo field. If the byte length of Key is less than or equal to the SHA256 block length (64 bytes) then the full length KeyDigest is SHA256(Key). But if the byte length of Key is greater than 64 bytes, the KeyValue is already SHA256(Key) with zeros appended, so in this case the full length KeyDigest is SHA256(SHA256(Key)). The optional KeyDigest bits consist of 2 to 32 of the most-significant (=left-most) bytes of the full length KeyDigest. For the convenience of the validator and if packet size permits, it is recommended to include the full 32 bytes." Would that be precise enough? best, c Thanks, - Jeff T From: Junxiao Shi > Date: Wednesday, May 27, 2015 at 5:10 To: Jeff Thompson > Cc: "ndn-interest at lists.cs.ucla.edu" > Subject: Re: [Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256? Dear folks Details about HMAC algorithm, or any other crypto algorithm, SHOULD NOT appear in NDN Packet Format spec. Instead, the implementer should be referred to RFC. Those details are duplication of RFC, and they would make the spec unnecessary long. They also increase the probability of incorrect implementations because the implementer is unsure whether it's exactly same as what she/he has in the library, and would have to implement it again. "don't have HMAC in their crypto library" is not a valid argument - it's easier to find an RFC-compliant library or snippet for most languages than to implement according to the (duplicate of RFC in) spec. Yours, Junxiao On Mon, May 18, 2015 at 4:00 PM, Thompson, Jeff > wrote: The proposed SignatureHmacWithSha256 spec (below) repeats the details of the HMAC algorithm from RFC 2104. But should the details be removed and just refer to RFC 2104? Arguments for keeping the details are that it provides details for the discussion of creating the KeyDIgest and also because some applications don't have HMAC in their crypto library and need to implement it directly. An argument against keeping the details is that the info is in RFC 2104 so an application writer can read the RFC if needed, and that we don't repeat the details of other algorithms like SHA-256. Any opinions on removing the algorithm details? - Jeff T _______________________________________________ Ndn-interest mailing list Ndn-interest at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest -------------- next part -------------- An HTML attachment was scrubbed... URL: From tailinchu at gmail.com Mon Jun 1 19:37:04 2015 From: tailinchu at gmail.com (Tai-Lin Chu) Date: Mon, 1 Jun 2015 19:37:04 -0700 Subject: [Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256? In-Reply-To: <49DE0EF2-012F-4996-80EC-FC52BCCF9BC6@parc.com> References: <1C839A4C-7C50-4847-8428-B8098983536C@parc.com> <49DE0EF2-012F-4996-80EC-FC52BCCF9BC6@parc.com> Message-ID: A name can be non-fetchable. I really think for HMAC keylocator, we just need name to identify the key, and key digest should be let empty (because sha256keydigest is not very helpful). If one needs some form of key digest, just put that in name. On Mon, Jun 1, 2015 at 2:32 PM, wrote: > I think overloading the use of a Name to avoid overloading the use of > KeyDigest is trading one thing for another. If the Name is only an SPI > (32-bit integer), for example, then its not really a name either as it > cannot be fetched. > > I agree that if KeyDigest is defined as the SHA256 of something (as it is in > the ndn spec), then its not the right container for an index, and possibly > not the right container for a truncated digest. > > To avoid mis-using a Name and mis-using a KeyDigest, then it looks like one > would need to introduce a new TLV container ?KeyIndex? or something like > that to accommodate negotiated key IDs in a key exchange protocol. > > To accomodate truncated KeyDigest, one could use a new container. However, > if it is a truncated SHA256, then I think it would be obvious that it is > only the ?length? bytes of the SHA256, not the full 32-bytes. I could see > allowing a shorter (left truncated) SHA256 in the KeyDigest without loss of > specificity. > > Marc > > On Jun 1, 2015, at 7:42 PM, Thompson, Jeff wrote: > > Hi Christian and Marc, > > I think we agree that we'll spell out how to get the key digest from the > Key, but not spell out the HMAC algorithm itself (or how Key is padded to > make the internally-used KeyValue). > > If the applications want to use an integer identifier for the Key, then > the KeyLocator would need to be a Name with the integer as a name > component, right? > > Also, if the "truncated key digest" (maybe as short as a byte) is used as > an identifier, I wonder whether this should be in a Name too. This way, > we don't mess with the semantics of KeyDigest which usually means the full > digest. What do you think? > > Thanks, > - Jeff T > > On 2015/6/1, 9:48, "christian.tschudin at unibas.ch" > wrote: > > I understood Jeff wanting to make the spec as self-contained as > possible, but I doubt that a reference to an HMAC-internal variable is > helping. > > (It translate into "Dear NDN implementor, to implement this two-line > feature you need to read the following RFC and locate that Keyval > variable in your favorit shrinked-wrapped library." As a probe: the > Python hashlib API page does not reference it). > > So better write at least that part out? > > Regarding how to choose the KeyId (hash, ISAKMP SPI etc): I see, so it > make sense to point out the many possibilities to pick your way. At > least an advantage of the currently discussed hashing approach would > be to not add another document to read 8-) > > best, c > > > On Mon, 1 Jun 2015, Marc.Mosko at parc.com wrote: > > The proposed spec already defines KeyValue as the right-padded (for > short keys) or sha256 (for long keys) of the Key. I would define the > KeyDigest as the SHA256(KeyValue) and not repeat the same algorithm used > to compute KeyValue. > > With regard to repeating the definition of HMAC, I would not do that > but simply say that the ?text? input to HMAC is {Name, MetaInfo, > Content, SignatureInfo} TLVs. > > For symmetric key systems, like HMAC, I think it is also acceptable to > use an agreed upon integer identifier for the shared secret, as > determined by a key exchange protocol (e.g. an ISAKMP SPI). I don?t > think that symmetric key KeyDigests need to be derived from the key. > That?s different than public key systems, where the the KeyDigest is > used like the Subject Key Identifier (RFC 5280 4.2.1.2) and derived from > the actual public key. > > Marc > > On Jun 1, 2015, at 1:45 PM, > wrote: > > On Wed, 27 May 2015, Thompson, Jeff wrote: > > Hello Christian, > Two questions: > 1. Can you repeat your suggestion that the spec allow a truncated > form of the key digest, for example the first 8 bytes of the key > digest instead of the full 32 bytes? > > > Hi Jeff, > > This is a trick that Marc Mosko used when we presented the 1+0 > encoding at the January ICNRG interim meeting: Just reduce then number > of KeyID-Bits (2 Bytes, in our case), if need be. > > The observation is that the key digest is for convenience, not > security reasons: If you have many parties for which you have to > maintain different symmetric keys, it is nice to quickly identify which > key to use for validating the signature. But theoretically, you could > just try out all symmetric keys you have for some peer. Rivest's > "chaffing and winnowing" even relies on not sending any KeyID bits, on > purpose. > > > 2. If you want this suggestion on the spec, what is the best way to > describe the computation of the key digest if we don't describe the > HMAC algorithm in the spec? > > > First, it could be made optional. But then I think it would be good to > write down how the digest is computed, as you suggest (because RFC 2104 > does not cover it, right?) > > Adapted from previous text of yours: > > "The Key must not be included in the signature but optionally a full > or partial KeyDigest can be put in the KeyLocator block of the > SignatureInfo field. If the byte length of Key is less than or equal to > the SHA256 block length (64 bytes) then the full length KeyDigest is > SHA256(Key). But if the byte length of Key is greater than 64 bytes, > the KeyValue is already SHA256(Key) with zeros appended, so in this > case the full length KeyDigest is SHA256(SHA256(Key)). The optional > KeyDigest bits consist of 2 to 32 of the most-significant (=left-most) > bytes of the full length KeyDigest. For the convenience of the > validator and if packet size permits, it is recommended to include the > full 32 bytes." > > Would that be precise enough? > > best, c > > Thanks, > - Jeff T > From: Junxiao Shi > Date: Wednesday, May 27, 2015 at 5:10 > To: Jeff Thompson > Cc: "ndn-interest at lists.cs.ucla.edu" > Subject: Re: [Ndn-interest] Describe the HMAC algorithm in > SignatureHmacWithSha256? > Dear folks > Details about HMAC algorithm, or any other crypto algorithm, SHOULD > NOT appear in NDN Packet Format > spec. > Instead, the implementer should be referred to RFC. > Those details are duplication of RFC, and they would make the spec > unnecessary long. > They also increase the probability of incorrect implementations > because the implementer is unsure > whether it's exactly same as what she/he has in the library, and > would have to implement it again. > "don't have HMAC in their crypto library" is not a valid argument - > it's easier to find an > RFC-compliant library or snippet for most languages than to implement > according to the (duplicate of > RFC in) spec. > Yours, Junxiao > On Mon, May 18, 2015 at 4:00 PM, Thompson, Jeff > wrote: > The proposed SignatureHmacWithSha256 spec (below) repeats the > details of the HMAC > algorithm from RFC 2104. But should the details be removed and > just refer to RFC 2104? > Arguments for keeping the details are that it provides details > for the discussion of > creating the KeyDIgest and also because some applications don't > have HMAC in their crypto > library and need to implement it directly. An argument against > keeping the details is that > the info is in RFC 2104 so an application writer can read the > RFC if needed, and that we > don't repeat the details of other algorithms like SHA-256. > Any opinions on removing the algorithm details? > - Jeff T > > _______________________________________________ > Ndn-interest mailing list > 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 > From gts at ics.uci.EDU Mon Jun 1 20:13:19 2015 From: gts at ics.uci.EDU (GTS) Date: Tue, 02 Jun 2015 05:13:19 +0200 Subject: [Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256? In-Reply-To: <1C839A4C-7C50-4847-8428-B8098983536C@parc.com> References: <1C839A4C-7C50-4847-8428-B8098983536C@parc.com> Message-ID: <556D1F4F.2020408@ics.uci.edu> FWIW, I think Marc is quite right about this issue. What should be used here is a Key ID, and not anything derived (e.g., a hash) of the actual key. Indeed, a key digest is only appropriate in public key settings. In the symmetric case (such as HMAC), using a key digest is not advisable. Cheers, Gene ====================== Gene Tsudik Chancellor's Professor of Computer Science University of California, Irvine On 6/1/15 4:24 PM, Marc.Mosko at parc.com wrote: > ... > > For symmetric key systems, like HMAC, I think it is also acceptable to use an agreed upon integer identifier for the shared secret, as determined by a key exchange protocol (e.g. an ISAKMP SPI). I don?t think that symmetric key KeyDigests need to be derived from the key. That?s different than public key systems, where the the KeyDigest is used like the Subject Key Identifier (RFC 5280 4.2.1.2) and derived from the actual public key. > > Marc > > From christian.tschudin at unibas.ch Tue Jun 2 00:38:28 2015 From: christian.tschudin at unibas.ch (christian.tschudin at unibas.ch) Date: Tue, 2 Jun 2015 09:38:28 +0200 (CEST) Subject: [Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256? In-Reply-To: <49DE0EF2-012F-4996-80EC-FC52BCCF9BC6@parc.com> References: <1C839A4C-7C50-4847-8428-B8098983536C@parc.com> <49DE0EF2-012F-4996-80EC-FC52BCCF9BC6@parc.com> Message-ID: On Mon, 1 Jun 2015, Marc.Mosko at parc.com wrote: > ... > To avoid mis-using a Name and mis-using a KeyDigest, then it looks like one > would need to introduce a new TLV container ?KeyIndex? or something like > that to accommodate negotiated key IDs in a key exchange protocol. I agree. If we move away from using a hash or other intrinsic key properties, as Gene suggests, the simplest process would be random bits instead of requiring a negotiation of key IDs and making assumptions on persistent state. Collisions would be normal (they also happen with negotiated keyIDs, over long enough time), wherefore one could call it "KeyBin" instead of "KeyIndex": the signer anounces the bin in which the signing key can be found. best, christian > > To accomodate truncated KeyDigest, one could use a new container. ?However, > if it is a truncated SHA256, then I think it would be obvious that it is > only the ?length? bytes of the SHA256, not the full 32-bytes. ?I could see > allowing a shorter (left truncated) SHA256 in the KeyDigest without loss of > specificity. > > Marc > > On Jun 1, 2015, at 7:42 PM, Thompson, Jeff wrote: > > Hi Christian and Marc, > > I think we agree that we'll spell out how to get the key digest > from the > Key, but not spell out the HMAC algorithm itself (or how Key is > padded to > make the internally-used KeyValue). > > If the applications want to use an integer identifier for the > Key, then > the KeyLocator would need to be a Name with the integer as a > name > component, right? ? > > Also, if the "truncated key digest" (maybe as short as a byte) > is used as > an identifier, I wonder whether this should be in a Name too. > ?This way, > we don't mess with the semantics of KeyDigest which usually > means the full > digest. What do you think? > > Thanks, > - Jeff T > > On 2015/6/1, 9:48, "christian.tschudin at unibas.ch" > wrote: > > I understood Jeff wanting to make the spec as > self-contained as > possible, but I doubt that a reference to an > HMAC-internal variable is > helping. > > (It translate into "Dear NDN implementor, to > implement this two-line > feature you need to read the following RFC and > locate that Keyval > variable in your favorit shrinked-wrapped library." > As a probe: the > Python hashlib API page does not reference it). > > So better write at least that part out? > > Regarding how to choose the KeyId (hash, ISAKMP SPI > etc): I see, so it > make sense to point out the many possibilities to > pick your way. At > least an advantage of the currently discussed > hashing approach would > be to not add another document to read 8-) > > best, c > > > On Mon, 1 Jun 2015, Marc.Mosko at parc.com wrote: > > The proposed spec already defines > KeyValue as the right-padded (for > short keys) or sha256 (for long keys) of > the Key. ?I would define the > KeyDigest as the SHA256(KeyValue) and > not repeat the same algorithm used > to compute KeyValue. > > With regard to repeating the definition > of HMAC, I would not do that > but simply say that the ?text? input to > HMAC is {Name, MetaInfo, > Content, SignatureInfo} TLVs. > > For symmetric key systems, like HMAC, I > think it is also acceptable to > use an agreed upon integer identifier > for the shared secret, as > determined by a key exchange protocol > (e.g. an ISAKMP SPI). ?I don?t > think that symmetric key KeyDigests need > to be derived from the key. > That?s different than public key > systems, where the the KeyDigest is > used like the Subject Key Identifier > (RFC 5280 4.2.1.2) and derived from > the actual public key. > > Marc > > On Jun 1, 2015, at 1:45 PM, > > wrote: > > On Wed, 27 May 2015, > Thompson, Jeff wrote: > > Hello Christian, > Two questions: > 1. Can you > repeat your > suggestion that > the spec allow a > truncated > form of the key > digest, for > example the > first 8 bytes of > the key > digest instead > of the full 32 > bytes? > > > Hi Jeff, > > This is a trick that Marc > Mosko used when we presented > the 1+0 > encoding at the January > ICNRG interim meeting: Just > reduce then number > of KeyID-Bits (2 Bytes, in > our case), if need be. > > The observation is that the > key digest is for > convenience, not > security reasons: If you > have many parties for which > you have to > maintain different symmetric > keys, it is nice to quickly > identify which > key to use for validating > the signature. But > theoretically, you could > just try out all symmetric > keys you have for some peer. > Rivest's > "chaffing and winnowing" > even relies on not sending > any KeyID bits, on > purpose. > > > 2. If you want > this suggestion > on the spec, > what is the best > way to > describe the > computation of > the key digest > if we don't > describe the > HMAC algorithm > in the spec? > > > First, it could be made > optional. But then I think > it would be good to > write down how the digest is > computed, as you suggest > (because RFC 2104 > does not cover it, right?) > > Adapted from previous text > of yours: > > "The Key must not be > included in the signature > but optionally a full > or partial KeyDigest can be > put in the KeyLocator block > of the > SignatureInfo field. If the > byte length of Key is less > than or equal to > the SHA256 block length (64 > bytes) then the full length > KeyDigest is > SHA256(Key). But if the byte > length of Key is greater > than 64 bytes, > the KeyValue is already > SHA256(Key) with zeros > appended, so in this > case the full length > KeyDigest is > SHA256(SHA256(Key)). The > optional > KeyDigest bits consist of 2 > to 32 of the > most-significant > (=left-most) > bytes of the full length > KeyDigest. For the > convenience of the > validator and if packet size > permits, it is recommended > to include the > full 32 bytes." > > Would that be precise > enough? > > best, c > > Thanks, > - Jeff T > From: Junxiao > Shi > > Date: Wednesday, > May 27, 2015 at > 5:10 > To: Jeff > Thompson > > Cc: > "ndn-interest at lists.cs.ucla.edu" > > Subject: Re: > [Ndn-interest] > Describe the > HMAC algorithm > in > SignatureHmacWithSha256? > Dear folks > Details about > HMAC algorithm, > or any other > crypto > algorithm, > SHOULD > NOT appear in > NDN Packet > Format > spec. > Instead, the > implementer > should be > referred to RFC. > Those details > are duplication > of RFC, and they > would make the > spec > unnecessary > long. > They also > increase the > probability of > incorrect > implementations > because the > implementer is > unsure > whether it's > exactly same as > what she/he has > in the library, > and > would have to > implement it > again. > "don't have HMAC > in their crypto > library" is not > a valid argument > - > it's easier to > find an > RFC-compliant > library or > snippet for most > languages than > to implement > according to the > (duplicate of > RFC in) spec. > Yours, Junxiao > On Mon, May 18, > 2015 at 4:00 PM, > Thompson, Jeff > > wrote: > ????The proposed > SignatureHmacWithSha256 > spec (below) > repeats the > details of the > HMAC > ????algorithm > from RFC 2104. > But should the > details be > removed and > just refer to > RFC 2104? > ????Arguments > for keeping the > details are that > it provides > details > for the > discussion of > ????creating the > KeyDIgest and > also because > some > applications > don't > have HMAC in > their crypto > ????library and > need to > implement it > directly. An > argument against > keeping the > details is that > ????the info is > in RFC 2104 so > an application > writer can read > the > RFC if needed, > and that we > ????don't repeat > the details of > other algorithms > like SHA-256. > Any opinions on > removing the > algorithm > details? > - Jeff T > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > > > > From jefft0 at remap.ucla.edu Tue Jun 2 09:03:39 2015 From: jefft0 at remap.ucla.edu (Thompson, Jeff) Date: Tue, 2 Jun 2015 16:03:39 +0000 Subject: [Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256? In-Reply-To: <556D1F4F.2020408@ics.uci.edu> References: <1C839A4C-7C50-4847-8428-B8098983536C@parc.com> <556D1F4F.2020408@ics.uci.edu> Message-ID: Hi Gene, As Tai-Lin suggests, the Name in a KeyLocator does not need to be a globally fetchable name. Indeed it is part of the NDN design that names can be non-global, and this is used often in NFD (e.g. /localhost command interests). So, could the Key ID be put in a (non-global) key Name in the KeyLocator? - Jeff T On 2015/6/1, 20:13, "GTS" wrote: >FWIW, I think Marc is quite right about this issue. What should be used >here is a Key ID, and not >anything derived (e.g., a hash) of the actual key. Indeed, a key digest >is only appropriate in >public key settings. In the symmetric case (such as HMAC), using a key >digest is not advisable. >Cheers, >Gene > > ====================== > Gene Tsudik > Chancellor's Professor of Computer Science > University of California, Irvine > > > > >On 6/1/15 4:24 PM, Marc.Mosko at parc.com wrote: >> ... >> >> For symmetric key systems, like HMAC, I think it is also acceptable to >>use an agreed upon integer identifier for the shared secret, as >>determined by a key exchange protocol (e.g. an ISAKMP SPI). I don?t >>think that symmetric key KeyDigests need to be derived from the key. >>That?s different than public key systems, where the the KeyDigest is >>used like the Subject Key Identifier (RFC 5280 4.2.1.2) and derived from >>the actual public key. >> >> Marc >> >> > >_______________________________________________ >Ndn-interest mailing list >Ndn-interest at lists.cs.ucla.edu >http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest From jefft0 at remap.ucla.edu Tue Jun 2 09:05:09 2015 From: jefft0 at remap.ucla.edu (Thompson, Jeff) Date: Tue, 2 Jun 2015 16:05:09 +0000 Subject: [Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256? In-Reply-To: <49DE0EF2-012F-4996-80EC-FC52BCCF9BC6@parc.com> References: <1C839A4C-7C50-4847-8428-B8098983536C@parc.com> <49DE0EF2-012F-4996-80EC-FC52BCCF9BC6@parc.com> Message-ID: Hi Marc, As I asked Gene, to avoid expanding the definition of KeyLocator, it is possible to use a local/relative sense of a Name for the Key ID? - Jeff T From: "Marc.Mosko at parc.com" > Date: Monday, June 1, 2015 at 14:32 To: Jeff Thompson > Cc: "christian.tschudin at unibas.ch" >, "Ndn-interest at lists.cs.ucla.edu" > Subject: Re: [Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256? I think overloading the use of a Name to avoid overloading the use of KeyDigest is trading one thing for another. If the Name is only an SPI (32-bit integer), for example, then its not really a name either as it cannot be fetched. I agree that if KeyDigest is defined as the SHA256 of something (as it is in the ndn spec), then its not the right container for an index, and possibly not the right container for a truncated digest. To avoid mis-using a Name and mis-using a KeyDigest, then it looks like one would need to introduce a new TLV container ?KeyIndex? or something like that to accommodate negotiated key IDs in a key exchange protocol. To accomodate truncated KeyDigest, one could use a new container. However, if it is a truncated SHA256, then I think it would be obvious that it is only the ?length? bytes of the SHA256, not the full 32-bytes. I could see allowing a shorter (left truncated) SHA256 in the KeyDigest without loss of specificity. Marc On Jun 1, 2015, at 7:42 PM, Thompson, Jeff > wrote: Hi Christian and Marc, I think we agree that we'll spell out how to get the key digest from the Key, but not spell out the HMAC algorithm itself (or how Key is padded to make the internally-used KeyValue). If the applications want to use an integer identifier for the Key, then the KeyLocator would need to be a Name with the integer as a name component, right? Also, if the "truncated key digest" (maybe as short as a byte) is used as an identifier, I wonder whether this should be in a Name too. This way, we don't mess with the semantics of KeyDigest which usually means the full digest. What do you think? Thanks, - Jeff T On 2015/6/1, 9:48, "christian.tschudin at unibas.ch" > wrote: I understood Jeff wanting to make the spec as self-contained as possible, but I doubt that a reference to an HMAC-internal variable is helping. (It translate into "Dear NDN implementor, to implement this two-line feature you need to read the following RFC and locate that Keyval variable in your favorit shrinked-wrapped library." As a probe: the Python hashlib API page does not reference it). So better write at least that part out? Regarding how to choose the KeyId (hash, ISAKMP SPI etc): I see, so it make sense to point out the many possibilities to pick your way. At least an advantage of the currently discussed hashing approach would be to not add another document to read 8-) best, c On Mon, 1 Jun 2015, Marc.Mosko at parc.com wrote: The proposed spec already defines KeyValue as the right-padded (for short keys) or sha256 (for long keys) of the Key. I would define the KeyDigest as the SHA256(KeyValue) and not repeat the same algorithm used to compute KeyValue. With regard to repeating the definition of HMAC, I would not do that but simply say that the ?text? input to HMAC is {Name, MetaInfo, Content, SignatureInfo} TLVs. For symmetric key systems, like HMAC, I think it is also acceptable to use an agreed upon integer identifier for the shared secret, as determined by a key exchange protocol (e.g. an ISAKMP SPI). I don?t think that symmetric key KeyDigests need to be derived from the key. That?s different than public key systems, where the the KeyDigest is used like the Subject Key Identifier (RFC 5280 4.2.1.2) and derived from the actual public key. Marc On Jun 1, 2015, at 1:45 PM, > > wrote: On Wed, 27 May 2015, Thompson, Jeff wrote: Hello Christian, Two questions: 1. Can you repeat your suggestion that the spec allow a truncated form of the key digest, for example the first 8 bytes of the key digest instead of the full 32 bytes? Hi Jeff, This is a trick that Marc Mosko used when we presented the 1+0 encoding at the January ICNRG interim meeting: Just reduce then number of KeyID-Bits (2 Bytes, in our case), if need be. The observation is that the key digest is for convenience, not security reasons: If you have many parties for which you have to maintain different symmetric keys, it is nice to quickly identify which key to use for validating the signature. But theoretically, you could just try out all symmetric keys you have for some peer. Rivest's "chaffing and winnowing" even relies on not sending any KeyID bits, on purpose. 2. If you want this suggestion on the spec, what is the best way to describe the computation of the key digest if we don't describe the HMAC algorithm in the spec? First, it could be made optional. But then I think it would be good to write down how the digest is computed, as you suggest (because RFC 2104 does not cover it, right?) Adapted from previous text of yours: "The Key must not be included in the signature but optionally a full or partial KeyDigest can be put in the KeyLocator block of the SignatureInfo field. If the byte length of Key is less than or equal to the SHA256 block length (64 bytes) then the full length KeyDigest is SHA256(Key). But if the byte length of Key is greater than 64 bytes, the KeyValue is already SHA256(Key) with zeros appended, so in this case the full length KeyDigest is SHA256(SHA256(Key)). The optional KeyDigest bits consist of 2 to 32 of the most-significant (=left-most) bytes of the full length KeyDigest. For the convenience of the validator and if packet size permits, it is recommended to include the full 32 bytes." Would that be precise enough? best, c Thanks, - Jeff T From: Junxiao Shi > Date: Wednesday, May 27, 2015 at 5:10 To: Jeff Thompson > Cc: "ndn-interest at lists.cs.ucla.edu" > Subject: Re: [Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256? Dear folks Details about HMAC algorithm, or any other crypto algorithm, SHOULD NOT appear in NDN Packet Format spec. Instead, the implementer should be referred to RFC. Those details are duplication of RFC, and they would make the spec unnecessary long. They also increase the probability of incorrect implementations because the implementer is unsure whether it's exactly same as what she/he has in the library, and would have to implement it again. "don't have HMAC in their crypto library" is not a valid argument - it's easier to find an RFC-compliant library or snippet for most languages than to implement according to the (duplicate of RFC in) spec. Yours, Junxiao On Mon, May 18, 2015 at 4:00 PM, Thompson, Jeff > wrote: The proposed SignatureHmacWithSha256 spec (below) repeats the details of the HMAC algorithm from RFC 2104. But should the details be removed and just refer to RFC 2104? Arguments for keeping the details are that it provides details for the discussion of creating the KeyDIgest and also because some applications don't have HMAC in their crypto library and need to implement it directly. An argument against keeping the details is that the info is in RFC 2104 so an application writer can read the RFC if needed, and that we don't repeat the details of other algorithms like SHA-256. Any opinions on removing the algorithm details? - Jeff T _______________________________________________ Ndn-interest mailing list Ndn-interest at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest -------------- next part -------------- An HTML attachment was scrubbed... URL: From jefft0 at remap.ucla.edu Tue Jun 2 09:08:45 2015 From: jefft0 at remap.ucla.edu (Thompson, Jeff) Date: Tue, 2 Jun 2015 16:08:45 +0000 Subject: [Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256? In-Reply-To: References: <1C839A4C-7C50-4847-8428-B8098983536C@parc.com> <49DE0EF2-012F-4996-80EC-FC52BCCF9BC6@parc.com> Message-ID: Hi Christian, If I understand, you suggest that the recipient should try to validate the signature using all available keys, and any key locator is just something which would narrow down the keys to try? More strongly, you're suggesting that we give up on the idea that a KeyLocator should uniquely identify the key needed to verify? - Jeff T On 2015/6/2, 0:38, "christian.tschudin at unibas.ch" > wrote: On Mon, 1 Jun 2015, Marc.Mosko at parc.com wrote: ... To avoid mis-using a Name and mis-using a KeyDigest, then it looks like one would need to introduce a new TLV container ?KeyIndex? or something like that to accommodate negotiated key IDs in a key exchange protocol. I agree. If we move away from using a hash or other intrinsic key properties, as Gene suggests, the simplest process would be random bits instead of requiring a negotiation of key IDs and making assumptions on persistent state. Collisions would be normal (they also happen with negotiated keyIDs, over long enough time), wherefore one could call it "KeyBin" instead of "KeyIndex": the signer anounces the bin in which the signing key can be found. best, christian To accomodate truncated KeyDigest, one could use a new container. However, if it is a truncated SHA256, then I think it would be obvious that it is only the ?length? bytes of the SHA256, not the full 32-bytes. I could see allowing a shorter (left truncated) SHA256 in the KeyDigest without loss of specificity. Marc On Jun 1, 2015, at 7:42 PM, Thompson, Jeff > wrote: Hi Christian and Marc, I think we agree that we'll spell out how to get the key digest from the Key, but not spell out the HMAC algorithm itself (or how Key is padded to make the internally-used KeyValue). If the applications want to use an integer identifier for the Key, then the KeyLocator would need to be a Name with the integer as a name component, right? Also, if the "truncated key digest" (maybe as short as a byte) is used as an identifier, I wonder whether this should be in a Name too. This way, we don't mess with the semantics of KeyDigest which usually means the full digest. What do you think? Thanks, - Jeff T On 2015/6/1, 9:48, "christian.tschudin at unibas.ch" > wrote: I understood Jeff wanting to make the spec as self-contained as possible, but I doubt that a reference to an HMAC-internal variable is helping. (It translate into "Dear NDN implementor, to implement this two-line feature you need to read the following RFC and locate that Keyval variable in your favorit shrinked-wrapped library." As a probe: the Python hashlib API page does not reference it). So better write at least that part out? Regarding how to choose the KeyId (hash, ISAKMP SPI etc): I see, so it make sense to point out the many possibilities to pick your way. At least an advantage of the currently discussed hashing approach would be to not add another document to read 8-) best, c On Mon, 1 Jun 2015, Marc.Mosko at parc.com wrote: The proposed spec already defines KeyValue as the right-padded (for short keys) or sha256 (for long keys) of the Key. I would define the KeyDigest as the SHA256(KeyValue) and not repeat the same algorithm used to compute KeyValue. With regard to repeating the definition of HMAC, I would not do that but simply say that the ?text? input to HMAC is {Name, MetaInfo, Content, SignatureInfo} TLVs. For symmetric key systems, like HMAC, I think it is also acceptable to use an agreed upon integer identifier for the shared secret, as determined by a key exchange protocol (e.g. an ISAKMP SPI). I don?t think that symmetric key KeyDigests need to be derived from the key. That?s different than public key systems, where the the KeyDigest is used like the Subject Key Identifier (RFC 5280 4.2.1.2) and derived from the actual public key. Marc On Jun 1, 2015, at 1:45 PM, > > wrote: On Wed, 27 May 2015, Thompson, Jeff wrote: Hello Christian, Two questions: 1. Can you repeat your suggestion that the spec allow a truncated form of the key digest, for example the first 8 bytes of the key digest instead of the full 32 bytes? Hi Jeff, This is a trick that Marc Mosko used when we presented the 1+0 encoding at the January ICNRG interim meeting: Just reduce then number of KeyID-Bits (2 Bytes, in our case), if need be. The observation is that the key digest is for convenience, not security reasons: If you have many parties for which you have to maintain different symmetric keys, it is nice to quickly identify which key to use for validating the signature. But theoretically, you could just try out all symmetric keys you have for some peer. Rivest's "chaffing and winnowing" even relies on not sending any KeyID bits, on purpose. 2. If you want this suggestion on the spec, what is the best way to describe the computation of the key digest if we don't describe the HMAC algorithm in the spec? First, it could be made optional. But then I think it would be good to write down how the digest is computed, as you suggest (because RFC 2104 does not cover it, right?) Adapted from previous text of yours: "The Key must not be included in the signature but optionally a full or partial KeyDigest can be put in the KeyLocator block of the SignatureInfo field. If the byte length of Key is less than or equal to the SHA256 block length (64 bytes) then the full length KeyDigest is SHA256(Key). But if the byte length of Key is greater than 64 bytes, the KeyValue is already SHA256(Key) with zeros appended, so in this case the full length KeyDigest is SHA256(SHA256(Key)). The optional KeyDigest bits consist of 2 to 32 of the most-significant (=left-most) bytes of the full length KeyDigest. For the convenience of the validator and if packet size permits, it is recommended to include the full 32 bytes." Would that be precise enough? best, c Thanks, - Jeff T From: Junxiao Shi > Date: Wednesday, May 27, 2015 at 5:10 To: Jeff Thompson > Cc: "ndn-interest at lists.cs.ucla.edu" > Subject: Re: [Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256? Dear folks Details about HMAC algorithm, or any other crypto algorithm, SHOULD NOT appear in NDN Packet Format spec. Instead, the implementer should be referred to RFC. Those details are duplication of RFC, and they would make the spec unnecessary long. They also increase the probability of incorrect implementations because the implementer is unsure whether it's exactly same as what she/he has in the library, and would have to implement it again. "don't have HMAC in their crypto library" is not a valid argument - it's easier to find an RFC-compliant library or snippet for most languages than to implement according to the (duplicate of RFC in) spec. Yours, Junxiao On Mon, May 18, 2015 at 4:00 PM, Thompson, Jeff > wrote: The proposed SignatureHmacWithSha256 spec (below) repeats the details of the HMAC algorithm from RFC 2104. But should the details be removed and just refer to RFC 2104? Arguments for keeping the details are that it provides details for the discussion of creating the KeyDIgest and also because some applications don't have HMAC in their crypto library and need to implement it directly. An argument against keeping the details is that the info is in RFC 2104 so an application writer can read the RFC if needed, and that we don't repeat the details of other algorithms like SHA-256. Any opinions on removing the algorithm details? - Jeff T _______________________________________________ Ndn-interest mailing list Ndn-interest at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest -------------- next part -------------- An HTML attachment was scrubbed... URL: From Marc.Mosko at parc.com Tue Jun 2 10:14:04 2015 From: Marc.Mosko at parc.com (Marc.Mosko at parc.com) Date: Tue, 2 Jun 2015 17:14:04 +0000 Subject: [Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256? In-Reply-To: References: <1C839A4C-7C50-4847-8428-B8098983536C@parc.com> <49DE0EF2-012F-4996-80EC-FC52BCCF9BC6@parc.com> Message-ID: <884C8B3F-51D8-4B01-8EE6-EC9337F1FE00@parc.com> My concern with using the Name in a KeyLocator is that some implementations will start sending an Interest for the name, which is the normal thing to do for a Name in a KeyLocator. If there is some way to clearly indicate in this case the name it is non-routable and that its purpose is to identify a KeyId, that would be ok. I understand that should be implicit from the SignatureType being HMAC?. >From the spec on SignatureInfo, one reads: The specific definition of the usage of Name and KeyDigest options in KeyLocator field is outside the scope of this specification. Generally, Name names the Data packet with the corresponding certificate. However, it is up to the specific trust model to define whether this name is a full name of the Data packet or a prefix that can match multiple Data packets. For example, the hierarchical trust model [1] uses the latter approach, requiring clients to fetch the latest version of the Data packet pointed by the KeyLocator (the latest version of the public key certificate) in order to ensure that the public key was not yet revoked. So that does not really allow the third option that the Name does not specify any Data packet but rather names a KeyId. Marc On Jun 2, 2015, at 6:05 PM, Thompson, Jeff > wrote: Hi Marc, As I asked Gene, to avoid expanding the definition of KeyLocator, it is possible to use a local/relative sense of a Name for the Key ID? - Jeff T From: "Marc.Mosko at parc.com" > Date: Monday, June 1, 2015 at 14:32 To: Jeff Thompson > Cc: "christian.tschudin at unibas.ch" >, "Ndn-interest at lists.cs.ucla.edu" > Subject: Re: [Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256? I think overloading the use of a Name to avoid overloading the use of KeyDigest is trading one thing for another. If the Name is only an SPI (32-bit integer), for example, then its not really a name either as it cannot be fetched. I agree that if KeyDigest is defined as the SHA256 of something (as it is in the ndn spec), then its not the right container for an index, and possibly not the right container for a truncated digest. To avoid mis-using a Name and mis-using a KeyDigest, then it looks like one would need to introduce a new TLV container ?KeyIndex? or something like that to accommodate negotiated key IDs in a key exchange protocol. To accomodate truncated KeyDigest, one could use a new container. However, if it is a truncated SHA256, then I think it would be obvious that it is only the ?length? bytes of the SHA256, not the full 32-bytes. I could see allowing a shorter (left truncated) SHA256 in the KeyDigest without loss of specificity. Marc On Jun 1, 2015, at 7:42 PM, Thompson, Jeff > wrote: Hi Christian and Marc, I think we agree that we'll spell out how to get the key digest from the Key, but not spell out the HMAC algorithm itself (or how Key is padded to make the internally-used KeyValue). If the applications want to use an integer identifier for the Key, then the KeyLocator would need to be a Name with the integer as a name component, right? Also, if the "truncated key digest" (maybe as short as a byte) is used as an identifier, I wonder whether this should be in a Name too. This way, we don't mess with the semantics of KeyDigest which usually means the full digest. What do you think? Thanks, - Jeff T On 2015/6/1, 9:48, "christian.tschudin at unibas.ch" > wrote: I understood Jeff wanting to make the spec as self-contained as possible, but I doubt that a reference to an HMAC-internal variable is helping. (It translate into "Dear NDN implementor, to implement this two-line feature you need to read the following RFC and locate that Keyval variable in your favorit shrinked-wrapped library." As a probe: the Python hashlib API page does not reference it). So better write at least that part out? Regarding how to choose the KeyId (hash, ISAKMP SPI etc): I see, so it make sense to point out the many possibilities to pick your way. At least an advantage of the currently discussed hashing approach would be to not add another document to read 8-) best, c On Mon, 1 Jun 2015, Marc.Mosko at parc.com wrote: The proposed spec already defines KeyValue as the right-padded (for short keys) or sha256 (for long keys) of the Key. I would define the KeyDigest as the SHA256(KeyValue) and not repeat the same algorithm used to compute KeyValue. With regard to repeating the definition of HMAC, I would not do that but simply say that the ?text? input to HMAC is {Name, MetaInfo, Content, SignatureInfo} TLVs. For symmetric key systems, like HMAC, I think it is also acceptable to use an agreed upon integer identifier for the shared secret, as determined by a key exchange protocol (e.g. an ISAKMP SPI). I don?t think that symmetric key KeyDigests need to be derived from the key. That?s different than public key systems, where the the KeyDigest is used like the Subject Key Identifier (RFC 5280 4.2.1.2) and derived from the actual public key. Marc On Jun 1, 2015, at 1:45 PM, > > wrote: On Wed, 27 May 2015, Thompson, Jeff wrote: Hello Christian, Two questions: 1. Can you repeat your suggestion that the spec allow a truncated form of the key digest, for example the first 8 bytes of the key digest instead of the full 32 bytes? Hi Jeff, This is a trick that Marc Mosko used when we presented the 1+0 encoding at the January ICNRG interim meeting: Just reduce then number of KeyID-Bits (2 Bytes, in our case), if need be. The observation is that the key digest is for convenience, not security reasons: If you have many parties for which you have to maintain different symmetric keys, it is nice to quickly identify which key to use for validating the signature. But theoretically, you could just try out all symmetric keys you have for some peer. Rivest's "chaffing and winnowing" even relies on not sending any KeyID bits, on purpose. 2. If you want this suggestion on the spec, what is the best way to describe the computation of the key digest if we don't describe the HMAC algorithm in the spec? First, it could be made optional. But then I think it would be good to write down how the digest is computed, as you suggest (because RFC 2104 does not cover it, right?) Adapted from previous text of yours: "The Key must not be included in the signature but optionally a full or partial KeyDigest can be put in the KeyLocator block of the SignatureInfo field. If the byte length of Key is less than or equal to the SHA256 block length (64 bytes) then the full length KeyDigest is SHA256(Key). But if the byte length of Key is greater than 64 bytes, the KeyValue is already SHA256(Key) with zeros appended, so in this case the full length KeyDigest is SHA256(SHA256(Key)). The optional KeyDigest bits consist of 2 to 32 of the most-significant (=left-most) bytes of the full length KeyDigest. For the convenience of the validator and if packet size permits, it is recommended to include the full 32 bytes." Would that be precise enough? best, c Thanks, - Jeff T From: Junxiao Shi > Date: Wednesday, May 27, 2015 at 5:10 To: Jeff Thompson > Cc: "ndn-interest at lists.cs.ucla.edu" > Subject: Re: [Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256? Dear folks Details about HMAC algorithm, or any other crypto algorithm, SHOULD NOT appear in NDN Packet Format spec. Instead, the implementer should be referred to RFC. Those details are duplication of RFC, and they would make the spec unnecessary long. They also increase the probability of incorrect implementations because the implementer is unsure whether it's exactly same as what she/he has in the library, and would have to implement it again. "don't have HMAC in their crypto library" is not a valid argument - it's easier to find an RFC-compliant library or snippet for most languages than to implement according to the (duplicate of RFC in) spec. Yours, Junxiao On Mon, May 18, 2015 at 4:00 PM, Thompson, Jeff > wrote: The proposed SignatureHmacWithSha256 spec (below) repeats the details of the HMAC algorithm from RFC 2104. But should the details be removed and just refer to RFC 2104? Arguments for keeping the details are that it provides details for the discussion of creating the KeyDIgest and also because some applications don't have HMAC in their crypto library and need to implement it directly. An argument against keeping the details is that the info is in RFC 2104 so an application writer can read the RFC if needed, and that we don't repeat the details of other algorithms like SHA-256. Any opinions on removing the algorithm details? - Jeff T _______________________________________________ Ndn-interest mailing list Ndn-interest at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest -------------- next part -------------- An HTML attachment was scrubbed... URL: From tailinchu at gmail.com Tue Jun 2 11:29:46 2015 From: tailinchu at gmail.com (Tai-Lin Chu) Date: Tue, 2 Jun 2015 11:29:46 -0700 Subject: [Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256? In-Reply-To: <884C8B3F-51D8-4B01-8EE6-EC9337F1FE00@parc.com> References: <1C839A4C-7C50-4847-8428-B8098983536C@parc.com> <49DE0EF2-012F-4996-80EC-FC52BCCF9BC6@parc.com> <884C8B3F-51D8-4B01-8EE6-EC9337F1FE00@parc.com> Message-ID: @marc The name's definition may need to be changed. But that is not in scope of this discussion. On Tue, Jun 2, 2015 at 10:14 AM, wrote: > My concern with using the Name in a KeyLocator is that some implementations > will start sending an Interest for the name, which is the normal thing to do > for a Name in a KeyLocator. If there is some way to clearly indicate in > this case the name it is non-routable and that its purpose is to identify a > KeyId, that would be ok. I understand that should be implicit from the > SignatureType being HMAC?. > > From the spec on SignatureInfo, one reads: > > The specific definition of the usage of Name and KeyDigest options in > KeyLocator field is outside the scope of this specification. Generally, Name > names the Data packet with the corresponding certificate. However, it is up > to the specific trust model to define whether this name is a full name of > the Data packet or a prefix that can match multiple Data packets. For > example, the hierarchical trust model [1] uses the latter approach, > requiring clients to fetch the latest version of the Data packet pointed by > the KeyLocator (the latest version of the public key certificate) in order > to ensure that the public key was not yet revoked. > > > So that does not really allow the third option that the Name does not > specify any Data packet but rather names a KeyId. > > Marc > > On Jun 2, 2015, at 6:05 PM, Thompson, Jeff wrote: > > Hi Marc, > > As I asked Gene, to avoid expanding the definition of KeyLocator, it is > possible to use a local/relative sense of a Name for the Key ID? > > - Jeff T > > From: "Marc.Mosko at parc.com" > Date: Monday, June 1, 2015 at 14:32 > To: Jeff Thompson > Cc: "christian.tschudin at unibas.ch" , > "Ndn-interest at lists.cs.ucla.edu" > Subject: Re: [Ndn-interest] Describe the HMAC algorithm in > SignatureHmacWithSha256? > > I think overloading the use of a Name to avoid overloading the use of > KeyDigest is trading one thing for another. If the Name is only an SPI > (32-bit integer), for example, then its not really a name either as it > cannot be fetched. > > I agree that if KeyDigest is defined as the SHA256 of something (as it is in > the ndn spec), then its not the right container for an index, and possibly > not the right container for a truncated digest. > > To avoid mis-using a Name and mis-using a KeyDigest, then it looks like one > would need to introduce a new TLV container ?KeyIndex? or something like > that to accommodate negotiated key IDs in a key exchange protocol. > > To accomodate truncated KeyDigest, one could use a new container. However, > if it is a truncated SHA256, then I think it would be obvious that it is > only the ?length? bytes of the SHA256, not the full 32-bytes. I could see > allowing a shorter (left truncated) SHA256 in the KeyDigest without loss of > specificity. > > Marc > > On Jun 1, 2015, at 7:42 PM, Thompson, Jeff wrote: > > Hi Christian and Marc, > > I think we agree that we'll spell out how to get the key digest from the > Key, but not spell out the HMAC algorithm itself (or how Key is padded to > make the internally-used KeyValue). > > If the applications want to use an integer identifier for the Key, then > the KeyLocator would need to be a Name with the integer as a name > component, right? > > Also, if the "truncated key digest" (maybe as short as a byte) is used as > an identifier, I wonder whether this should be in a Name too. This way, > we don't mess with the semantics of KeyDigest which usually means the full > digest. What do you think? > > Thanks, > - Jeff T > > On 2015/6/1, 9:48, "christian.tschudin at unibas.ch" > wrote: > > I understood Jeff wanting to make the spec as self-contained as > possible, but I doubt that a reference to an HMAC-internal variable is > helping. > > (It translate into "Dear NDN implementor, to implement this two-line > feature you need to read the following RFC and locate that Keyval > variable in your favorit shrinked-wrapped library." As a probe: the > Python hashlib API page does not reference it). > > So better write at least that part out? > > Regarding how to choose the KeyId (hash, ISAKMP SPI etc): I see, so it > make sense to point out the many possibilities to pick your way. At > least an advantage of the currently discussed hashing approach would > be to not add another document to read 8-) > > best, c > > > On Mon, 1 Jun 2015, Marc.Mosko at parc.com wrote: > > The proposed spec already defines KeyValue as the right-padded (for > short keys) or sha256 (for long keys) of the Key. I would define the > KeyDigest as the SHA256(KeyValue) and not repeat the same algorithm used > to compute KeyValue. > > With regard to repeating the definition of HMAC, I would not do that > but simply say that the ?text? input to HMAC is {Name, MetaInfo, > Content, SignatureInfo} TLVs. > > For symmetric key systems, like HMAC, I think it is also acceptable to > use an agreed upon integer identifier for the shared secret, as > determined by a key exchange protocol (e.g. an ISAKMP SPI). I don?t > think that symmetric key KeyDigests need to be derived from the key. > That?s different than public key systems, where the the KeyDigest is > used like the Subject Key Identifier (RFC 5280 4.2.1.2) and derived from > the actual public key. > > Marc > > On Jun 1, 2015, at 1:45 PM, > wrote: > > On Wed, 27 May 2015, Thompson, Jeff wrote: > > Hello Christian, > Two questions: > 1. Can you repeat your suggestion that the spec allow a truncated > form of the key digest, for example the first 8 bytes of the key > digest instead of the full 32 bytes? > > > Hi Jeff, > > This is a trick that Marc Mosko used when we presented the 1+0 > encoding at the January ICNRG interim meeting: Just reduce then number > of KeyID-Bits (2 Bytes, in our case), if need be. > > The observation is that the key digest is for convenience, not > security reasons: If you have many parties for which you have to > maintain different symmetric keys, it is nice to quickly identify which > key to use for validating the signature. But theoretically, you could > just try out all symmetric keys you have for some peer. Rivest's > "chaffing and winnowing" even relies on not sending any KeyID bits, on > purpose. > > > 2. If you want this suggestion on the spec, what is the best way to > describe the computation of the key digest if we don't describe the > HMAC algorithm in the spec? > > > First, it could be made optional. But then I think it would be good to > write down how the digest is computed, as you suggest (because RFC 2104 > does not cover it, right?) > > Adapted from previous text of yours: > > "The Key must not be included in the signature but optionally a full > or partial KeyDigest can be put in the KeyLocator block of the > SignatureInfo field. If the byte length of Key is less than or equal to > the SHA256 block length (64 bytes) then the full length KeyDigest is > SHA256(Key). But if the byte length of Key is greater than 64 bytes, > the KeyValue is already SHA256(Key) with zeros appended, so in this > case the full length KeyDigest is SHA256(SHA256(Key)). The optional > KeyDigest bits consist of 2 to 32 of the most-significant (=left-most) > bytes of the full length KeyDigest. For the convenience of the > validator and if packet size permits, it is recommended to include the > full 32 bytes." > > Would that be precise enough? > > best, c > > Thanks, > - Jeff T > From: Junxiao Shi > Date: Wednesday, May 27, 2015 at 5:10 > To: Jeff Thompson > Cc: "ndn-interest at lists.cs.ucla.edu" > Subject: Re: [Ndn-interest] Describe the HMAC algorithm in > SignatureHmacWithSha256? > Dear folks > Details about HMAC algorithm, or any other crypto algorithm, SHOULD > NOT appear in NDN Packet Format > spec. > Instead, the implementer should be referred to RFC. > Those details are duplication of RFC, and they would make the spec > unnecessary long. > They also increase the probability of incorrect implementations > because the implementer is unsure > whether it's exactly same as what she/he has in the library, and > would have to implement it again. > "don't have HMAC in their crypto library" is not a valid argument - > it's easier to find an > RFC-compliant library or snippet for most languages than to implement > according to the (duplicate of > RFC in) spec. > Yours, Junxiao > On Mon, May 18, 2015 at 4:00 PM, Thompson, Jeff > wrote: > The proposed SignatureHmacWithSha256 spec (below) repeats the > details of the HMAC > algorithm from RFC 2104. But should the details be removed and > just refer to RFC 2104? > Arguments for keeping the details are that it provides details > for the discussion of > creating the KeyDIgest and also because some applications don't > have HMAC in their crypto > library and need to implement it directly. An argument against > keeping the details is that > the info is in RFC 2104 so an application writer can read the > RFC if needed, and that we > don't repeat the details of other algorithms like SHA-256. > Any opinions on removing the algorithm details? > - Jeff T > > _______________________________________________ > Ndn-interest mailing list > 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 > From gts at ics.uci.EDU Wed Jun 3 01:09:52 2015 From: gts at ics.uci.EDU (GTS) Date: Wed, 03 Jun 2015 10:09:52 +0200 Subject: [Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256? In-Reply-To: References: <1C839A4C-7C50-4847-8428-B8098983536C@parc.com> <556D1F4F.2020408@ics.uci.edu> Message-ID: <556EB650.6070803@ics.uci.edu> Jeff, yes, I don't see why not. I think KeyID can be viewed as a sort of a locator. Cheers, Gene On 6/2/15 6:03 PM, Thompson, Jeff wrote: > Hi Gene, > > As Tai-Lin suggests, the Name in a KeyLocator does not need to be a > globally fetchable name. Indeed it is part of the NDN design that names > can be non-global, and this is used often in NFD (e.g. /localhost command > interests). > > So, could the Key ID be put in a (non-global) key Name in the KeyLocator? > > - Jeff T > > On 2015/6/1, 20:13, "GTS" wrote: > >> FWIW, I think Marc is quite right about this issue. What should be used >> here is a Key ID, and not >> anything derived (e.g., a hash) of the actual key. Indeed, a key digest >> is only appropriate in >> public key settings. In the symmetric case (such as HMAC), using a key >> digest is not advisable. >> Cheers, >> Gene >> >> ====================== >> Gene Tsudik >> Chancellor's Professor of Computer Science >> University of California, Irvine >> >> >> >> >> On 6/1/15 4:24 PM, Marc.Mosko at parc.com wrote: >>> ... >>> >>> For symmetric key systems, like HMAC, I think it is also acceptable to >>> use an agreed upon integer identifier for the shared secret, as >>> determined by a key exchange protocol (e.g. an ISAKMP SPI). I don?t >>> think that symmetric key KeyDigests need to be derived from the key. >>> That?s different than public key systems, where the the KeyDigest is >>> used like the Subject Key Identifier (RFC 5280 4.2.1.2) and derived from >>> the actual public key. >>> >>> Marc >>> >>> >> _______________________________________________ >> Ndn-interest mailing list >> Ndn-interest at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > . > From shijunxiao at email.arizona.edu Wed Jun 3 14:49:15 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Wed, 3 Jun 2015 14:49:15 -0700 Subject: [Ndn-interest] Data comes from another face? In-Reply-To: <4AC03A6244C3C34BB52A7EC60B799C4C03CC2969@m-pdc.sbu.ac.ir> References: <4AC03A6244C3C34BB52A7EC60B799C4C03CC2964@m-pdc.sbu.ac.ir> <4AC03A6244C3C34BB52A7EC60B799C4C03CC2969@m-pdc.sbu.ac.ir> Message-ID: Hi Sabet Ethernet repeater and UDP multicast group are two examples of multi-access links. Infrastructure WiFi is different: at MAC layer, all communications go through the AP (access point). We could take advantage of this property, and install an NDN stack on the AP that aggregates Interests and caches Data. Under this design, a wireless client treats the WiFi link as a point-to-point link to the AP, and the AP treats the WiFi link as both a multi-access link where packets can be broadcast to all wireless clients, and one point-to-point link to each wireless link. Yours, Junxiao On May 31, 2015 2:27 PM, "Muhammad Hosain Abdollahi Sabet" < M.AbdollahiSabet at mail.sbu.ac.ir> wrote: > Junxiao, > > So in wired nets it would be good old BUS or ethernet HUB networks, which > is rare these days unless we face lack of switching devices. And in > wireless nets, generally all of them are multiple-access link, right? > > Actually It'very good to see you here by chance. Lately I've been thinking > on intelligent(self-learning) forwarding and I was counting different > situations which it would be useful for. Just a couple of hours ago I saw > your presentation about NDN in LANs at NDNComm and I was like :| "Again, > I've got here late!", though I had felt the need for such a self-learning > mechanism in producer mobility. I don't know if still there is a room to > contribute more in this. As far as I already saw, this NFD in addition to a > pointer to the chosen output face in PIT, which is available right now, > lacks some pointer to the chosen FIB entry itself. And of course some > measures are needed to check efficiency of self-learned chosen faces after > a while and see if another flooding is needed for choosing possible better > face. > > Thanks, > Sabet. > > > -----Original Message----- > From: Junxiao Shi [mailto:shijunxiao at email.arizona.edu > ] > Sent: Sun 5/24/2015 1:48 AM > To: Muhammad Hosain Abdollahi Sabet > Cc: ndn-interest at lists.cs.ucla.edu > Subject: Re: [Ndn-interest] Data comes from another face? > > Hi Sabet > > As I understand you question is: > In a network of NDN nodes where none of the nodes is using broadcast > strategy, if a node has not forwarded an Interest out of an interface, is > it possible for this node to receive a Data on this interface? > > The answer is YES. > Think about a multi-access link with 3 hosts P Q R. > > 1. Q sends an Interest. P and R receive this Interest, > 2. P replies with a Data. Q and R receive this Data. > > In this scenario, R has not forwarded an Interest to the multi-access link, > but receives a Data from the multi-access link. > > Yours, Junxiao > > On Wed, May 20, 2015 at 11:17 AM, Muhammad Hosain Abdollahi Sabet < > M.AbdollahiSabet at mail.sbu.ac.ir> wrote: > > > Hi, > > We all know that data packets follow breadcrumbs which interest packets > > leave behind. And we expect to receive data packets from the same face > > which interests have already been forwarded to, according to > correspondent > > fib entries, right? So, when the second sentence won't happen? I mean a > > node receive a data packet matching a pit entry, from a face that the > > interest has not been forwarded to, according to the fib entry. If a node > > choose to broadcast for forwarding strategy, such a situation happens. I > > know that. But is there any other condition? > > > > Thanks, > > Sabet > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yingdi at CS.UCLA.EDU Fri Jun 5 17:58:37 2015 From: yingdi at CS.UCLA.EDU (Yingdi Yu) Date: Fri, 5 Jun 2015 17:58:37 -0700 Subject: [Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256? In-Reply-To: <884C8B3F-51D8-4B01-8EE6-EC9337F1FE00@parc.com> References: <1C839A4C-7C50-4847-8428-B8098983536C@parc.com> <49DE0EF2-012F-4996-80EC-FC52BCCF9BC6@parc.com> <884C8B3F-51D8-4B01-8EE6-EC9337F1FE00@parc.com> Message-ID: <3DB747F4-8EDE-40F6-AD6A-2024B62F02EB@cs.ucla.edu> I would prefer to explicitly state in the spec that, for HMAC signature, validating implementation should look up keys in local symmetric key storage. If we restrict the usage of KeyLocator of HMAC to local lookup, we can use Name as KeyId (in KeyLocator). I do not think KeyDigest would be very useful, but if a data producer really wants to use KeyDigest as a KeyLocator, the definition JeffT made in the first mail should be fine. Yingdi > On Jun 2, 2015, at 10:14 AM, Marc.Mosko at parc.com wrote: > > My concern with using the Name in a KeyLocator is that some implementations will start sending an Interest for the name, which is the normal thing to do for a Name in a KeyLocator. If there is some way to clearly indicate in this case the name it is non-routable and that its purpose is to identify a KeyId, that would be ok. I understand that should be implicit from the SignatureType being HMAC?. > > From the spec on SignatureInfo, one reads: > >> The specific definition of the usage of Name and KeyDigest options in KeyLocator field is outside the scope of this specification. Generally, Name names the Data packet with the corresponding certificate. However, it is up to the specific trust model to define whether this name is a full name of the Data packet or a prefix that can match multiple Data packets. For example, the hierarchical trust model [1] uses the latter approach, requiring clients to fetch the latest version of the Data packet pointed by the KeyLocator (the latest version of the public key certificate) in order to ensure that the public key was not yet revoked. > > > So that does not really allow the third option that the Name does not specify any Data packet but rather names a KeyId. > > Marc > > On Jun 2, 2015, at 6:05 PM, Thompson, Jeff > wrote: > >> Hi Marc, >> >> As I asked Gene, to avoid expanding the definition of KeyLocator, it is possible to use a local/relative sense of a Name for the Key ID? >> >> - Jeff T >> >> From: "Marc.Mosko at parc.com " > >> Date: Monday, June 1, 2015 at 14:32 >> To: Jeff Thompson > >> Cc: "christian.tschudin at unibas.ch " >, "Ndn-interest at lists.cs.ucla.edu " > >> Subject: Re: [Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256? >> >> I think overloading the use of a Name to avoid overloading the use of KeyDigest is trading one thing for another. If the Name is only an SPI (32-bit integer), for example, then its not really a name either as it cannot be fetched. >> >> I agree that if KeyDigest is defined as the SHA256 of something (as it is in the ndn spec), then its not the right container for an index, and possibly not the right container for a truncated digest. >> >> To avoid mis-using a Name and mis-using a KeyDigest, then it looks like one would need to introduce a new TLV container ?KeyIndex? or something like that to accommodate negotiated key IDs in a key exchange protocol. >> >> To accomodate truncated KeyDigest, one could use a new container. However, if it is a truncated SHA256, then I think it would be obvious that it is only the ?length? bytes of the SHA256, not the full 32-bytes. I could see allowing a shorter (left truncated) SHA256 in the KeyDigest without loss of specificity. >> >> Marc >> >> On Jun 1, 2015, at 7:42 PM, Thompson, Jeff > wrote: >> >>> Hi Christian and Marc, >>> >>> I think we agree that we'll spell out how to get the key digest from the >>> Key, but not spell out the HMAC algorithm itself (or how Key is padded to >>> make the internally-used KeyValue). >>> >>> If the applications want to use an integer identifier for the Key, then >>> the KeyLocator would need to be a Name with the integer as a name >>> component, right? >>> >>> Also, if the "truncated key digest" (maybe as short as a byte) is used as >>> an identifier, I wonder whether this should be in a Name too. This way, >>> we don't mess with the semantics of KeyDigest which usually means the full >>> digest. What do you think? >>> >>> Thanks, >>> - Jeff T >>> >>> On 2015/6/1, 9:48, "christian.tschudin at unibas.ch " >>> > wrote: >>> >>>> I understood Jeff wanting to make the spec as self-contained as >>>> possible, but I doubt that a reference to an HMAC-internal variable is >>>> helping. >>>> >>>> (It translate into "Dear NDN implementor, to implement this two-line >>>> feature you need to read the following RFC and locate that Keyval >>>> variable in your favorit shrinked-wrapped library." As a probe: the >>>> Python hashlib API page does not reference it). >>>> >>>> So better write at least that part out? >>>> >>>> Regarding how to choose the KeyId (hash, ISAKMP SPI etc): I see, so it >>>> make sense to point out the many possibilities to pick your way. At >>>> least an advantage of the currently discussed hashing approach would >>>> be to not add another document to read 8-) >>>> >>>> best, c >>>> >>>> >>>> On Mon, 1 Jun 2015, Marc.Mosko at parc.com wrote: >>>> >>>>> The proposed spec already defines KeyValue as the right-padded (for >>>>> short keys) or sha256 (for long keys) of the Key. I would define the >>>>> KeyDigest as the SHA256(KeyValue) and not repeat the same algorithm used >>>>> to compute KeyValue. >>>>> >>>>> With regard to repeating the definition of HMAC, I would not do that >>>>> but simply say that the ?text? input to HMAC is {Name, MetaInfo, >>>>> Content, SignatureInfo} TLVs. >>>>> >>>>> For symmetric key systems, like HMAC, I think it is also acceptable to >>>>> use an agreed upon integer identifier for the shared secret, as >>>>> determined by a key exchange protocol (e.g. an ISAKMP SPI). I don?t >>>>> think that symmetric key KeyDigests need to be derived from the key. >>>>> That?s different than public key systems, where the the KeyDigest is >>>>> used like the Subject Key Identifier (RFC 5280 4.2.1.2) and derived from >>>>> the actual public key. >>>>> >>>>> Marc >>>>> >>>>> On Jun 1, 2015, at 1:45 PM, > >>>>> > wrote: >>>>> >>>>>> On Wed, 27 May 2015, Thompson, Jeff wrote: >>>>>> >>>>>>> Hello Christian, >>>>>>> Two questions: >>>>>>> 1. Can you repeat your suggestion that the spec allow a truncated >>>>>>> form of the key digest, for example the first 8 bytes of the key >>>>>>> digest instead of the full 32 bytes? >>>>>> >>>>>> Hi Jeff, >>>>>> >>>>>> This is a trick that Marc Mosko used when we presented the 1+0 >>>>>> encoding at the January ICNRG interim meeting: Just reduce then number >>>>>> of KeyID-Bits (2 Bytes, in our case), if need be. >>>>>> >>>>>> The observation is that the key digest is for convenience, not >>>>>> security reasons: If you have many parties for which you have to >>>>>> maintain different symmetric keys, it is nice to quickly identify which >>>>>> key to use for validating the signature. But theoretically, you could >>>>>> just try out all symmetric keys you have for some peer. Rivest's >>>>>> "chaffing and winnowing" even relies on not sending any KeyID bits, on >>>>>> purpose. >>>>>> >>>>>> >>>>>>> 2. If you want this suggestion on the spec, what is the best way to >>>>>>> describe the computation of the key digest if we don't describe the >>>>>>> HMAC algorithm in the spec? >>>>>> >>>>>> First, it could be made optional. But then I think it would be good to >>>>>> write down how the digest is computed, as you suggest (because RFC 2104 >>>>>> does not cover it, right?) >>>>>> >>>>>> Adapted from previous text of yours: >>>>>> >>>>>> "The Key must not be included in the signature but optionally a full >>>>>> or partial KeyDigest can be put in the KeyLocator block of the >>>>>> SignatureInfo field. If the byte length of Key is less than or equal to >>>>>> the SHA256 block length (64 bytes) then the full length KeyDigest is >>>>>> SHA256(Key). But if the byte length of Key is greater than 64 bytes, >>>>>> the KeyValue is already SHA256(Key) with zeros appended, so in this >>>>>> case the full length KeyDigest is SHA256(SHA256(Key)). The optional >>>>>> KeyDigest bits consist of 2 to 32 of the most-significant (=left-most) >>>>>> bytes of the full length KeyDigest. For the convenience of the >>>>>> validator and if packet size permits, it is recommended to include the >>>>>> full 32 bytes." >>>>>> >>>>>> Would that be precise enough? >>>>>> >>>>>> best, c >>>>>> >>>>>>> Thanks, >>>>>>> - Jeff T >>>>>>> From: Junxiao Shi > >>>>>>> Date: Wednesday, May 27, 2015 at 5:10 >>>>>>> To: Jeff Thompson > >>>>>>> Cc: "ndn-interest at lists.cs.ucla.edu " > >>>>>>> Subject: Re: [Ndn-interest] Describe the HMAC algorithm in >>>>>>> SignatureHmacWithSha256? >>>>>>> Dear folks >>>>>>> Details about HMAC algorithm, or any other crypto algorithm, SHOULD >>>>>>> NOT appear in NDN Packet Format >>>>>>> spec. >>>>>>> Instead, the implementer should be referred to RFC. >>>>>>> Those details are duplication of RFC, and they would make the spec >>>>>>> unnecessary long. >>>>>>> They also increase the probability of incorrect implementations >>>>>>> because the implementer is unsure >>>>>>> whether it's exactly same as what she/he has in the library, and >>>>>>> would have to implement it again. >>>>>>> "don't have HMAC in their crypto library" is not a valid argument - >>>>>>> it's easier to find an >>>>>>> RFC-compliant library or snippet for most languages than to implement >>>>>>> according to the (duplicate of >>>>>>> RFC in) spec. >>>>>>> Yours, Junxiao >>>>>>> On Mon, May 18, 2015 at 4:00 PM, Thompson, Jeff >>>>>>> > wrote: >>>>>>> The proposed SignatureHmacWithSha256 spec (below) repeats the >>>>>>> details of the HMAC >>>>>>> algorithm from RFC 2104. But should the details be removed and >>>>>>> just refer to RFC 2104? >>>>>>> Arguments for keeping the details are that it provides details >>>>>>> for the discussion of >>>>>>> creating the KeyDIgest and also because some applications don't >>>>>>> have HMAC in their crypto >>>>>>> library and need to implement it directly. An argument against >>>>>>> keeping the details is that >>>>>>> the info is in RFC 2104 so an application writer can read the >>>>>>> RFC if needed, and that we >>>>>>> don't repeat the details of other algorithms like SHA-256. >>>>>>> Any opinions on removing the algorithm details? >>>>>>> - Jeff T >>>>>>> >>>>>> _______________________________________________ >>>>>> Ndn-interest mailing list >>>>>> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.AbdollahiSabet at mail.sbu.ac.ir Mon Jun 8 09:22:37 2015 From: M.AbdollahiSabet at mail.sbu.ac.ir (Muhammad Hosain Abdollahi Sabet) Date: Mon, 8 Jun 2015 20:52:37 +0430 Subject: [Ndn-interest] Data comes from another face? References: <4AC03A6244C3C34BB52A7EC60B799C4C03CC2964@m-pdc.sbu.ac.ir><4AC03A6244C3C34BB52A7EC60B799C4C03CC2969@m-pdc.sbu.ac.ir> Message-ID: <4AC03A6244C3C34BB52A7EC60B799C4C03CC296B@m-pdc.sbu.ac.ir> Junxiao, Thank you for responding. >?Infrastructure WiFi is different: at MAC layer, all communications go through the AP (access point). We could take advantage of this property, and install an NDN stack on the AP that aggregates Interests and caches Data. ?You mean we turn a L2 device (access point) into a wireless router? ? ?>?the AP treats the WiFi link as both a multi-access link where packets can be broadcast to all wireless clients, and one point-to-point link to each wireless link. Does that make any difference? An ap treat a link as a multiple-access or a point-to-point link. I mean in both cases, the ap does the same thing(transmit one copy of a packet). The only difference would be in L2 addressing?, right? Of course there could be difference if using omnidirectional or unidirectional antennas, which could be a big deal facing mobile nodes. But that's out of computer networking scope. Thanks, Sabet -----Original Message----- From: Junxiao Shi [mailto:shijunxiao at email.arizona.edu] Sent: Thu 6/4/2015 2:19 AM To: Muhammad Hosain Abdollahi Sabet Cc: ndn-interest at lists.cs.ucla.edu Subject: RE: [Ndn-interest] Data comes from another face? Hi Sabet Ethernet repeater and UDP multicast group are two examples of multi-access links. Infrastructure WiFi is different: at MAC layer, all communications go through the AP (access point). We could take advantage of this property, and install an NDN stack on the AP that aggregates Interests and caches Data. Under this design, a wireless client treats the WiFi link as a point-to-point link to the AP, and the AP treats the WiFi link as both a multi-access link where packets can be broadcast to all wireless clients, and one point-to-point link to each wireless link. Yours, Junxiao On May 31, 2015 2:27 PM, "Muhammad Hosain Abdollahi Sabet" < M.AbdollahiSabet at mail.sbu.ac.ir> wrote: > Junxiao, > > So in wired nets it would be good old BUS or ethernet HUB networks, which > is rare these days unless we face lack of switching devices. And in > wireless nets, generally all of them are multiple-access link, right? > > Actually It'very good to see you here by chance. Lately I've been thinking > on intelligent(self-learning) forwarding and I was counting different > situations which it would be useful for. Just a couple of hours ago I saw > your presentation about NDN in LANs at NDNComm and I was like :| "Again, > I've got here late!", though I had felt the need for such a self-learning > mechanism in producer mobility. I don't know if still there is a room to > contribute more in this. As far as I already saw, this NFD in addition to a > pointer to the chosen output face in PIT, which is available right now, > lacks some pointer to the chosen FIB entry itself. And of course some > measures are needed to check efficiency of self-learned chosen faces after > a while and see if another flooding is needed for choosing possible better > face. > > Thanks, > Sabet. > > > -----Original Message----- > From: Junxiao Shi [mailto:shijunxiao at email.arizona.edu > ] > Sent: Sun 5/24/2015 1:48 AM > To: Muhammad Hosain Abdollahi Sabet > Cc: ndn-interest at lists.cs.ucla.edu > Subject: Re: [Ndn-interest] Data comes from another face? > > Hi Sabet > > As I understand you question is: > In a network of NDN nodes where none of the nodes is using broadcast > strategy, if a node has not forwarded an Interest out of an interface, is > it possible for this node to receive a Data on this interface? > > The answer is YES. > Think about a multi-access link with 3 hosts P Q R. > > 1. Q sends an Interest. P and R receive this Interest, > 2. P replies with a Data. Q and R receive this Data. > > In this scenario, R has not forwarded an Interest to the multi-access link, > but receives a Data from the multi-access link. > > Yours, Junxiao > > On Wed, May 20, 2015 at 11:17 AM, Muhammad Hosain Abdollahi Sabet < > M.AbdollahiSabet at mail.sbu.ac.ir> wrote: > > > Hi, > > We all know that data packets follow breadcrumbs which interest packets > > leave behind. And we expect to receive data packets from the same face > > which interests have already been forwarded to, according to > correspondent > > fib entries, right? So, when the second sentence won't happen? I mean a > > node receive a data packet matching a pit entry, from a face that the > > interest has not been forwarded to, according to the fib entry. If a node > > choose to broadcast for forwarding strategy, such a situation happens. I > > know that. But is there any other condition? > > > > Thanks, > > Sabet > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Mon Jun 8 09:53:00 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Mon, 8 Jun 2015 09:53:00 -0700 Subject: [Ndn-interest] Data comes from another face? In-Reply-To: <4AC03A6244C3C34BB52A7EC60B799C4C03CC296A@m-pdc.sbu.ac.ir> References: <4AC03A6244C3C34BB52A7EC60B799C4C03CC2964@m-pdc.sbu.ac.ir> <4AC03A6244C3C34BB52A7EC60B799C4C03CC2969@m-pdc.sbu.ac.ir> <4AC03A6244C3C34BB52A7EC60B799C4C03CC296A@m-pdc.sbu.ac.ir> Message-ID: Hi Sabet Yes, in my example the WiFi access point is turned into a wireless router, which is a L3 device. In reality, most WiFi access points can be upgraded to work on L3 with cross-compiled NDN stack for OpenWRT . When the access point (or wireless router) treats a link as point-to-point, the destination address would be a unicast address. In 802.11 WiFi, the access point can send to unicast address at a faster rate than a multicast/broadcast address. See draft-vyncke-6man-mcast-not-efficient-01 section 3. Yours, Junxiao On Mon, Jun 8, 2015 at 8:45 AM, Muhammad Hosain Abdollahi Sabet < M.AbdollahiSabet at mail.sbu.ac.ir> wrote: > Junxiao, > > Thank you for responding. > > >?Infrastructure WiFi is different: at MAC layer, all communications go > through the AP (access point). > We could take advantage of this property, and install an NDN stack on the > AP that aggregates Interests and caches Data. > > ?You mean we turn a L2 device (access point) into a wireless router? > > ? > ?>?the AP treats the WiFi link as both a multi-access link where packets > can be broadcast to all wireless clients, and one point-to-point link to > each wireless link. > > Does that make any difference? An ap treat a link as a multiple-access or > a point-to-point link. I mean in both cases, the ap does the same > thing(transmit one copy of a packet). The only difference would be in L2 > addressing?, right? Of course there could be difference if using > omnidirectional or unidirectional antennas, which could be a big deal > facing mobile nodes. But that's out of computer networking scope. > > Thanks, > Sabet > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ignacio.Solis at parc.com Mon Jun 8 09:55:19 2015 From: Ignacio.Solis at parc.com (Ignacio.Solis at parc.com) Date: Mon, 8 Jun 2015 16:55:19 +0000 Subject: [Ndn-interest] Data comes from another face? In-Reply-To: <4AC03A6244C3C34BB52A7EC60B799C4C03CC296B@m-pdc.sbu.ac.ir> References: <4AC03A6244C3C34BB52A7EC60B799C4C03CC2964@m-pdc.sbu.ac.ir> <4AC03A6244C3C34BB52A7EC60B799C4C03CC2969@m-pdc.sbu.ac.ir> <4AC03A6244C3C34BB52A7EC60B799C4C03CC296B@m-pdc.sbu.ac.ir> Message-ID: Hi folks. I wanted to bring up a couple of important points to this discussion that have not been mentioned. Maybe people have already assimilated them so they think they?re obvious, but just in case: 1- A node should not accept data packets over links/interfaces/faces over which it did not forward an interest. This is a security risk. 2- NDN may have issues over multiple access links/interfaces/faces where not all nodes can hear each other (non-infrastructure WiFi). Both of these are true in the basic case. It?s possible that with extra design, protocols or developments that I?m unaware of these can be mitigated/solved. Nacho -- Nacho (Ignacio) Solis Protocol Architect Principal Scientist Palo Alto Research Center (PARC) +1(650)812-4458 Ignacio.Solis at parc.com On 6/8/15, 9:22 AM, "Muhammad Hosain Abdollahi Sabet" > wrote: Junxiao, Thank you for responding. >?Infrastructure WiFi is different: at MAC layer, all communications go through the AP (access point). We could take advantage of this property, and install an NDN stack on the AP that aggregates Interests and caches Data. ?You mean we turn a L2 device (access point) into a wireless router? ? ?>?the AP treats the WiFi link as both a multi-access link where packets can be broadcast to all wireless clients, and one point-to-point link to each wireless link. Does that make any difference? An ap treat a link as a multiple-access or a point-to-point link. I mean in both cases, the ap does the same thing(transmit one copy of a packet). The only difference would be in L2 addressing?, right? Of course there could be difference if using omnidirectional or unidirectional antennas, which could be a big deal facing mobile nodes. But that's out of computer networking scope. Thanks, Sabet -----Original Message----- From: Junxiao Shi [mailto:shijunxiao at email.arizona.edu] Sent: Thu 6/4/2015 2:19 AM To: Muhammad Hosain Abdollahi Sabet Cc: ndn-interest at lists.cs.ucla.edu Subject: RE: [Ndn-interest] Data comes from another face? Hi Sabet Ethernet repeater and UDP multicast group are two examples of multi-access links. Infrastructure WiFi is different: at MAC layer, all communications go through the AP (access point). We could take advantage of this property, and install an NDN stack on the AP that aggregates Interests and caches Data. Under this design, a wireless client treats the WiFi link as a point-to-point link to the AP, and the AP treats the WiFi link as both a multi-access link where packets can be broadcast to all wireless clients, and one point-to-point link to each wireless link. Yours, Junxiao On May 31, 2015 2:27 PM, "Muhammad Hosain Abdollahi Sabet" < M.AbdollahiSabet at mail.sbu.ac.ir> wrote: > Junxiao, > > So in wired nets it would be good old BUS or ethernet HUB networks, which > is rare these days unless we face lack of switching devices. And in > wireless nets, generally all of them are multiple-access link, right? > > Actually It'very good to see you here by chance. Lately I've been thinking > on intelligent(self-learning) forwarding and I was counting different > situations which it would be useful for. Just a couple of hours ago I saw > your presentation about NDN in LANs at NDNComm and I was like :| "Again, > I've got here late!", though I had felt the need for such a self-learning > mechanism in producer mobility. I don't know if still there is a room to > contribute more in this. As far as I already saw, this NFD in addition to a > pointer to the chosen output face in PIT, which is available right now, > lacks some pointer to the chosen FIB entry itself. And of course some > measures are needed to check efficiency of self-learned chosen faces after > a while and see if another flooding is needed for choosing possible better > face. > > Thanks, > Sabet. > > > -----Original Message----- > From: Junxiao Shi [mailto:shijunxiao at email.arizona.edu > >] > Sent: Sun 5/24/2015 1:48 AM > To: Muhammad Hosain Abdollahi Sabet > Cc: ndn-interest at lists.cs.ucla.edu > Subject: Re: [Ndn-interest] Data comes from another face? > > Hi Sabet > > As I understand you question is: > In a network of NDN nodes where none of the nodes is using broadcast > strategy, if a node has not forwarded an Interest out of an interface, is > it possible for this node to receive a Data on this interface? > > The answer is YES. > Think about a multi-access link with 3 hosts P Q R. > > 1. Q sends an Interest. P and R receive this Interest, > 2. P replies with a Data. Q and R receive this Data. > > In this scenario, R has not forwarded an Interest to the multi-access link, > but receives a Data from the multi-access link. > > Yours, Junxiao > > On Wed, May 20, 2015 at 11:17 AM, Muhammad Hosain Abdollahi Sabet < > M.AbdollahiSabet at mail.sbu.ac.ir> wrote: > > > Hi, > > We all know that data packets follow breadcrumbs which interest packets > > leave behind. And we expect to receive data packets from the same face > > which interests have already been forwarded to, according to > correspondent > > fib entries, right? So, when the second sentence won't happen? I mean a > > node receive a data packet matching a pit entry, from a face that the > > interest has not been forwarded to, according to the fib entry. If a node > > choose to broadcast for forwarding strategy, such a situation happens. I > > know that. But is there any other condition? > > > > Thanks, > > Sabet > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Mon Jun 8 10:15:00 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Mon, 8 Jun 2015 10:15:00 -0700 Subject: [Ndn-interest] Data comes from another face? In-Reply-To: References: <4AC03A6244C3C34BB52A7EC60B799C4C03CC2964@m-pdc.sbu.ac.ir> <4AC03A6244C3C34BB52A7EC60B799C4C03CC2969@m-pdc.sbu.ac.ir> <4AC03A6244C3C34BB52A7EC60B799C4C03CC296B@m-pdc.sbu.ac.ir> Message-ID: Hi Nacho Yes I'm aware of both issues. Sabet's original question is asking whether a Data packet could be received on a face where an Interest has not been forwarded to, under normal situations. The question is not about whether such Data packet should be accepted. Currently NFD forwarding would accept a Data packet as long as there is a PIT entry, without considering whether an Interest has been forwarded to the incoming face. This behavior is inherited from ccnd 0.7.2, and I know there's a security risk. I also suspect there would forwarding problems where transmissions on a multi-access link cannot reach every node. But I'm unfamiliar with those links, so I can't say exactly what problem could occur. Yours, Junxiao On Mon, Jun 8, 2015 at 9:55 AM, wrote: > Hi folks. > > I wanted to bring up a couple of important points to this discussion > that have not been mentioned. Maybe people have already assimilated them > so they think they?re obvious, but just in case: > > 1- A node should not accept data packets over links/interfaces/faces > over which it did not forward an interest. This is a security risk. > > 2- NDN may have issues over multiple access links/interfaces/faces where > not all nodes can hear each other (non-infrastructure WiFi). > > Both of these are true in the basic case. It?s possible that with extra > design, protocols or developments that I?m unaware of these can be > mitigated/solved. > > Nacho > > > -- > Nacho (Ignacio) Solis > Protocol Architect > Principal Scientist > Palo Alto Research Center (PARC) > +1(650)812-4458 > Ignacio.Solis at parc.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ignacio.Solis at parc.com Mon Jun 8 10:51:27 2015 From: Ignacio.Solis at parc.com (Ignacio.Solis at parc.com) Date: Mon, 8 Jun 2015 17:51:27 +0000 Subject: [Ndn-interest] Data comes from another face? In-Reply-To: References: <4AC03A6244C3C34BB52A7EC60B799C4C03CC2964@m-pdc.sbu.ac.ir> <4AC03A6244C3C34BB52A7EC60B799C4C03CC2969@m-pdc.sbu.ac.ir> <4AC03A6244C3C34BB52A7EC60B799C4C03CC296B@m-pdc.sbu.ac.ir> Message-ID: On 6/8/15, 10:15 AM, "Junxiao Shi" > wrote: Sabet's original question is asking whether a Data packet could be received on a face where an Interest has not been forwarded to, under normal situations. The question is not about whether such Data packet should be accepted. Currently NFD forwarding would accept a Data packet as long as there is a PIT entry, without considering whether an Interest has been forwarded to the incoming face. This behavior is inherited from ccnd 0.7.2, and I know there's a security risk. Good thing we deprecated the old ccnd :-). . I also suspect there would forwarding problems where transmissions on a multi-access link cannot reach every node. But I'm unfamiliar with those links, so I can't say exactly what problem could occur. Assume a network of: A??B??C??D where nodes can only hear neighbors. So: A can hear B but not C. B can hear both A+C. C can hear B+D, D can only hear C. A is a requester, D is a producer. A wants to get data located at D. Case 1 - Nodes don?t forward interests over the interface they received them from. A sends and interest and B gets it. B needs to forward the interest, but won?t do so over the same interface it arrived on. Protocol fails. Case 2 - Nodes forward interest over interface they received it on + nodes don?t forward objects over same interface A sends an interest and B gets it. It forwards the interest. Any node that receives the interest will forward it, flooding the network. C gets the interest, D gets the interest. D responds. C gets the reply satisfying the PIT from the interface that requested it. It assumes somebody else answered. - Protocol fails. Case 2b - Nodes that receive duplicate interests (same nonce), send control message to prune Chaos ensues as networks larger than 3 start pruning each other. A sends to B. B sends to A+C. C sends to B+D. B sees same interest from C, sends a prune message to C. C removes pit state. Case 2b.1 - If there is hold time on PIT, C won?t create a PIT entry again. Protocol fails. Case 2b.2 - If there is no hold time on the PIT entry, it may get created again as the interest is still being flooded. Network will continuously prune and flood, collapsing. - Network fails. Case 3 - Nodes forward interest over interface they received it on + nodes forward objects over same interface Same as Case 2, interest is flooded on the network? and then the data is flooded on the network. I?m sure other cases exist. These errors don?t occur if the link/interface/face has other properties. Like they can all hear each other (though there may are other issues in this scenario alone), there is an underlying protocol (like MAC level unicast), next-hops are used instead of interfaces/links/faces, etc. Again, maybe there are NDN features I?m not aware of or forgot. But either way, it?s a good discussion to have. And maybe you can clarify how NDN handles these cases. Nacho On Mon, Jun 8, 2015 at 9:55 AM, > wrote: Hi folks. I wanted to bring up a couple of important points to this discussion that have not been mentioned. Maybe people have already assimilated them so they think they?re obvious, but just in case: 1- A node should not accept data packets over links/interfaces/faces over which it did not forward an interest. This is a security risk. 2- NDN may have issues over multiple access links/interfaces/faces where not all nodes can hear each other (non-infrastructure WiFi). Both of these are true in the basic case. It?s possible that with extra design, protocols or developments that I?m unaware of these can be mitigated/solved. Nacho -- Nacho (Ignacio) Solis Protocol Architect Principal Scientist Palo Alto Research Center (PARC) +1(650)812-4458 Ignacio.Solis at parc.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.AbdollahiSabet at mail.sbu.ac.ir Mon Jun 8 11:11:07 2015 From: M.AbdollahiSabet at mail.sbu.ac.ir (Muhammad Hosain Abdollahi Sabet) Date: Mon, 8 Jun 2015 22:41:07 +0430 Subject: [Ndn-interest] Data comes from another face? References: <4AC03A6244C3C34BB52A7EC60B799C4C03CC2964@m-pdc.sbu.ac.ir> <4AC03A6244C3C34BB52A7EC60B799C4C03CC2969@m-pdc.sbu.ac.ir> <4AC03A6244C3C34BB52A7EC60B799C4C03CC296B@m-pdc.sbu.ac.ir> Message-ID: <4AC03A6244C3C34BB52A7EC60B799C4C03CC296F@m-pdc.sbu.ac.ir> Hi all, Actually I'm looking for a chances to have self-learning path feature, which implies - I guess - receiving data packets on faces which are not the same faces the interest has been forwarded to, or in better words the faces which is not in the corresponding FIB entry. I'm not quite aware of those security risks you are talking about, and I will be grateful If you could enlighten me a bit. The only point that is in my mind right now is that accepting such data packets will break fully symmetric subscriber-publisher approach. Thanks, Sabet -----Original Message----- From: Ignacio.Solis at parc.com [mailto:Ignacio.Solis at parc.com] Sent: Mon 6/8/2015 10:21 PM To: shijunxiao at email.arizona.edu Cc: Muhammad Hosain Abdollahi Sabet; ndn-interest at lists.cs.ucla.edu Subject: Re: [Ndn-interest] Data comes from another face? On 6/8/15, 10:15 AM, "Junxiao Shi" > wrote: Sabet's original question is asking whether a Data packet could be received on a face where an Interest has not been forwarded to, under normal situations. The question is not about whether such Data packet should be accepted. Currently NFD forwarding would accept a Data packet as long as there is a PIT entry, without considering whether an Interest has been forwarded to the incoming face. This behavior is inherited from ccnd 0.7.2, and I know there's a security risk. Good thing we deprecated the old ccnd :-). . I also suspect there would forwarding problems where transmissions on a multi-access link cannot reach every node. But I'm unfamiliar with those links, so I can't say exactly what problem could occur. Assume a network of: A--B--C--D where nodes can only hear neighbors. So: A can hear B but not C. B can hear both A+C. C can hear B+D, D can only hear C. A is a requester, D is a producer. A wants to get data located at D. Case 1 - Nodes don't forward interests over the interface they received them from. A sends and interest and B gets it. B needs to forward the interest, but won't do so over the same interface it arrived on. Protocol fails. Case 2 - Nodes forward interest over interface they received it on + nodes don't forward objects over same interface A sends an interest and B gets it. It forwards the interest. Any node that receives the interest will forward it, flooding the network. C gets the interest, D gets the interest. D responds. C gets the reply satisfying the PIT from the interface that requested it. It assumes somebody else answered. - Protocol fails. Case 2b - Nodes that receive duplicate interests (same nonce), send control message to prune Chaos ensues as networks larger than 3 start pruning each other. A sends to B. B sends to A+C. C sends to B+D. B sees same interest from C, sends a prune message to C. C removes pit state. Case 2b.1 - If there is hold time on PIT, C won't create a PIT entry again. Protocol fails. Case 2b.2 - If there is no hold time on the PIT entry, it may get created again as the interest is still being flooded. Network will continuously prune and flood, collapsing. - Network fails. Case 3 - Nodes forward interest over interface they received it on + nodes forward objects over same interface Same as Case 2, interest is flooded on the network. and then the data is flooded on the network. I'm sure other cases exist. These errors don't occur if the link/interface/face has other properties. Like they can all hear each other (though there may are other issues in this scenario alone), there is an underlying protocol (like MAC level unicast), next-hops are used instead of interfaces/links/faces, etc. Again, maybe there are NDN features I'm not aware of or forgot. But either way, it's a good discussion to have. And maybe you can clarify how NDN handles these cases. Nacho On Mon, Jun 8, 2015 at 9:55 AM, > wrote: Hi folks. I wanted to bring up a couple of important points to this discussion that have not been mentioned. Maybe people have already assimilated them so they think they're obvious, but just in case: 1- A node should not accept data packets over links/interfaces/faces over which it did not forward an interest. This is a security risk. 2- NDN may have issues over multiple access links/interfaces/faces where not all nodes can hear each other (non-infrastructure WiFi). Both of these are true in the basic case. It's possible that with extra design, protocols or developments that I'm unaware of these can be mitigated/solved. Nacho -- Nacho (Ignacio) Solis Protocol Architect Principal Scientist Palo Alto Research Center (PARC) +1(650)812-4458 Ignacio.Solis at parc.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ignacio.Solis at parc.com Mon Jun 8 11:45:19 2015 From: Ignacio.Solis at parc.com (Ignacio.Solis at parc.com) Date: Mon, 8 Jun 2015 18:45:19 +0000 Subject: [Ndn-interest] Data comes from another face? In-Reply-To: <4AC03A6244C3C34BB52A7EC60B799C4C03CC296F@m-pdc.sbu.ac.ir> References: <4AC03A6244C3C34BB52A7EC60B799C4C03CC2964@m-pdc.sbu.ac.ir> <4AC03A6244C3C34BB52A7EC60B799C4C03CC2969@m-pdc.sbu.ac.ir> <4AC03A6244C3C34BB52A7EC60B799C4C03CC296B@m-pdc.sbu.ac.ir> <4AC03A6244C3C34BB52A7EC60B799C4C03CC296F@m-pdc.sbu.ac.ir> Message-ID: On 6/8/15, 11:11 AM, "Muhammad Hosain Abdollahi Sabet" > wrote: Actually I'm looking for a chances to have self-learning path feature, which implies - I guess - receiving data packets on faces which are not the same faces the interest has been forwarded to, or in better words the faces which is not in the corresponding FIB entry. Can you describe what you have in mind? I?m unclear what you mean by self-learning path features with respect to the data objects. I can come up with protocols in my mind but they change the behavior of NDN/CCN drastically. I'm not quite aware of those security risks you are talking about, and I will be grateful If you could enlighten me a bit. The only point that is in my mind right now is that accepting such data packets will break fully symmetric subscriber-publisher approach. Well, in a regular Interest->Data exchange allowing "off-path? responses basically means you can have nodes that shouldn?t have authority in responding to traffic being able to generate responses. This is a waste of resources and a potential denial of service between otherwise cooperating nodes. A node off path can insert data in response to interests that will cause nodes to perform extra work (verifying hashes or signatures, triggering retransmissions, adding exclude filters, etc). You can imagine this gets trickier on multi-access networks. Nacho -----Original Message----- From: Ignacio.Solis at parc.com [mailto:Ignacio.Solis at parc.com] Sent: Mon 6/8/2015 10:21 PM To: shijunxiao at email.arizona.edu Cc: Muhammad Hosain Abdollahi Sabet; ndn-interest at lists.cs.ucla.edu Subject: Re: [Ndn-interest] Data comes from another face? On 6/8/15, 10:15 AM, "Junxiao Shi" > wrote: Sabet's original question is asking whether a Data packet could be received on a face where an Interest has not been forwarded to, under normal situations. The question is not about whether such Data packet should be accepted. Currently NFD forwarding would accept a Data packet as long as there is a PIT entry, without considering whether an Interest has been forwarded to the incoming face. This behavior is inherited from ccnd 0.7.2, and I know there's a security risk. Good thing we deprecated the old ccnd :-). . I also suspect there would forwarding problems where transmissions on a multi-access link cannot reach every node. But I'm unfamiliar with those links, so I can't say exactly what problem could occur. Assume a network of: A--B--C--D where nodes can only hear neighbors. So: A can hear B but not C. B can hear both A+C. C can hear B+D, D can only hear C. A is a requester, D is a producer. A wants to get data located at D. Case 1 - Nodes don't forward interests over the interface they received them from. A sends and interest and B gets it. B needs to forward the interest, but won't do so over the same interface it arrived on. Protocol fails. Case 2 - Nodes forward interest over interface they received it on + nodes don't forward objects over same interface A sends an interest and B gets it. It forwards the interest. Any node that receives the interest will forward it, flooding the network. C gets the interest, D gets the interest. D responds. C gets the reply satisfying the PIT from the interface that requested it. It assumes somebody else answered. - Protocol fails. Case 2b - Nodes that receive duplicate interests (same nonce), send control message to prune Chaos ensues as networks larger than 3 start pruning each other. A sends to B. B sends to A+C. C sends to B+D. B sees same interest from C, sends a prune message to C. C removes pit state. Case 2b.1 - If there is hold time on PIT, C won't create a PIT entry again. Protocol fails. Case 2b.2 - If there is no hold time on the PIT entry, it may get created again as the interest is still being flooded. Network will continuously prune and flood, collapsing. - Network fails. Case 3 - Nodes forward interest over interface they received it on + nodes forward objects over same interface Same as Case 2, interest is flooded on the network. and then the data is flooded on the network. I'm sure other cases exist. These errors don't occur if the link/interface/face has other properties. Like they can all hear each other (though there may are other issues in this scenario alone), there is an underlying protocol (like MAC level unicast), next-hops are used instead of interfaces/links/faces, etc. Again, maybe there are NDN features I'm not aware of or forgot. But either way, it's a good discussion to have. And maybe you can clarify how NDN handles these cases. Nacho On Mon, Jun 8, 2015 at 9:55 AM, > wrote: Hi folks. I wanted to bring up a couple of important points to this discussion that have not been mentioned. Maybe people have already assimilated them so they think they're obvious, but just in case: 1- A node should not accept data packets over links/interfaces/faces over which it did not forward an interest. This is a security risk. 2- NDN may have issues over multiple access links/interfaces/faces where not all nodes can hear each other (non-infrastructure WiFi). Both of these are true in the basic case. It's possible that with extra design, protocols or developments that I'm unaware of these can be mitigated/solved. Nacho -- Nacho (Ignacio) Solis Protocol Architect Principal Scientist Palo Alto Research Center (PARC) +1(650)812-4458 Ignacio.Solis at parc.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From oran at cisco.com Mon Jun 8 11:53:41 2015 From: oran at cisco.com (Dave Oran (oran)) Date: Mon, 8 Jun 2015 18:53:41 +0000 Subject: [Ndn-interest] Data comes from another face? In-Reply-To: References: <4AC03A6244C3C34BB52A7EC60B799C4C03CC2964@m-pdc.sbu.ac.ir> <4AC03A6244C3C34BB52A7EC60B799C4C03CC2969@m-pdc.sbu.ac.ir> <4AC03A6244C3C34BB52A7EC60B799C4C03CC296B@m-pdc.sbu.ac.ir> <4AC03A6244C3C34BB52A7EC60B799C4C03CC296F@m-pdc.sbu.ac.ir> Message-ID: Naive question: Are faces like L2 interfaces, or like routing adjacencies? If the former, all the kinds of weirdnesses regarding unsolicited data and non-transitivity show up. If the latter, you need an adjacency initialization and maintenance protocol (which all routing protocols running on multi-access links have), but you avoid all the messiness pointed out in this thread. My recommendation is that faces behave as adjacencies, not interfaces and that we adopt or design a good adjacency management protocol ASAP. DaveO. > On Jun 8, 2015, at 2:45 PM, Ignacio.Solis at parc.com wrote: > > On 6/8/15, 11:11 AM, "Muhammad Hosain Abdollahi Sabet" wrote: >> Actually I'm looking for a chances to have self-learning path feature, which implies - I guess - receiving data packets on faces which are not the same faces the interest has been forwarded to, or in better words the faces which is not in the corresponding FIB entry. > > Can you describe what you have in mind? I?m unclear what you mean by self-learning path features with respect to the data objects. I can come up with protocols in my mind but they change the behavior of NDN/CCN drastically. > >> I'm not quite aware of those security risks you are talking about, and I will be grateful If you could enlighten me a bit. >> The only point that is in my mind right now is that accepting such data packets will break fully symmetric subscriber-publisher approach. > > Well, in a regular Interest->Data exchange allowing "off-path? responses basically means you can have nodes that shouldn?t have authority in responding to traffic being able to generate responses. This is a waste of resources and a potential denial of service between otherwise cooperating nodes. A node off path can insert data in response to interests that will cause nodes to perform extra work (verifying hashes or signatures, triggering retransmissions, adding exclude filters, etc). > > You can imagine this gets trickier on multi-access networks. > > Nacho > > > >> -----Original Message----- >> From: Ignacio.Solis at parc.com [mailto:Ignacio.Solis at parc.com] >> Sent: Mon 6/8/2015 10:21 PM >> To: shijunxiao at email.arizona.edu >> Cc: Muhammad Hosain Abdollahi Sabet; ndn-interest at lists.cs.ucla.edu >> Subject: Re: [Ndn-interest] Data comes from another face? >> >> On 6/8/15, 10:15 AM, "Junxiao Shi" > wrote: >> >> Sabet's original question is asking whether a Data packet could be received on a face where an Interest has not been forwarded to, under normal situations. The question is not about whether such Data packet should be accepted. >> Currently NFD forwarding would accept a Data packet as long as there is a PIT entry, without considering whether an Interest has been forwarded to the incoming face. >> This behavior is inherited from ccnd 0.7.2, and I know there's a security risk. >> >> Good thing we deprecated the old ccnd :-). >> . >> >> I also suspect there would forwarding problems where transmissions on a multi-access link cannot reach every node. >> But I'm unfamiliar with those links, so I can't say exactly what problem could occur. >> >> Assume a network of: A--B--C--D where nodes can only hear neighbors. So: A can hear B but not C. B can hear both A+C. C can hear B+D, D can only hear C. A is a requester, D is a producer. A wants to get data located at D. >> >> Case 1 - Nodes don't forward interests over the interface they received them from. >> A sends and interest and B gets it. B needs to forward the interest, but won't do so over the same interface it arrived on. Protocol fails. >> >> Case 2 - Nodes forward interest over interface they received it on + nodes don't forward objects over same interface >> A sends an interest and B gets it. It forwards the interest. Any node that receives the interest will forward it, flooding the network. C gets the interest, D gets the interest. D responds. C gets the reply satisfying the PIT from the interface that requested it. It assumes somebody else answered. - Protocol fails. >> Case 2b - Nodes that receive duplicate interests (same nonce), send control message to prune >> Chaos ensues as networks larger than 3 start pruning each other. A sends to B. B sends to A+C. C sends to B+D. >> B sees same interest from C, sends a prune message to C. C removes pit state. >> Case 2b.1 - If there is hold time on PIT, C won't create a PIT entry again. Protocol fails. >> Case 2b.2 - If there is no hold time on the PIT entry, it may get created again as the interest is still being flooded. Network will continuously prune and flood, collapsing. - Network fails. >> >> Case 3 - Nodes forward interest over interface they received it on + nodes forward objects over same interface >> Same as Case 2, interest is flooded on the network. and then the data is flooded on the network. >> >> I'm sure other cases exist. >> >> These errors don't occur if the link/interface/face has other properties. Like they can all hear each other (though there may are other issues in this scenario alone), there is an underlying protocol (like MAC level unicast), next-hops are used instead of interfaces/links/faces, etc. >> >> Again, maybe there are NDN features I'm not aware of or forgot. But either way, it's a good discussion to have. And maybe you can clarify how NDN handles these cases. >> >> Nacho >> >> >> >> On Mon, Jun 8, 2015 at 9:55 AM, > wrote: >> Hi folks. >> >> I wanted to bring up a couple of important points to this discussion that have not been mentioned. Maybe people have already assimilated them so they think they're obvious, but just in case: >> >> 1- A node should not accept data packets over links/interfaces/faces over which it did not forward an interest. This is a security risk. >> >> 2- NDN may have issues over multiple access links/interfaces/faces where not all nodes can hear each other (non-infrastructure WiFi). >> >> Both of these are true in the basic case. It's possible that with extra design, protocols or developments that I'm unaware of these can be mitigated/solved. >> >> Nacho >> >> >> -- >> Nacho (Ignacio) Solis >> Protocol Architect >> Principal Scientist >> Palo Alto Research Center (PARC) >> +1(650)812-4458 >> Ignacio.Solis at parc.com >> >> >> > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest From Ignacio.Solis at parc.com Mon Jun 8 12:23:21 2015 From: Ignacio.Solis at parc.com (Ignacio.Solis at parc.com) Date: Mon, 8 Jun 2015 19:23:21 +0000 Subject: [Ndn-interest] Faces and adjacency Message-ID: CCNx (1.0) is designed for adjacency. In old CCN (0.x) (and maybe NDN too if based on the old CCN model), faces were used for PITs and FIBs. Faces could behave like L2 in many circumstances, so these were real problems. For example, what is currently done for multicast faces? Nacho On 6/8/15, 11:53 AM, "Dave Oran (oran)" wrote: >Naive question: > >Are faces like L2 interfaces, or like routing adjacencies? >If the former, all the kinds of weirdnesses regarding unsolicited data >and non-transitivity show up. >If the latter, you need an adjacency initialization and maintenance >protocol (which all routing protocols running on multi-access links >have), but you avoid all the messiness pointed out in this thread. > >My recommendation is that faces behave as adjacencies, not interfaces and >that we adopt or design a good adjacency management protocol ASAP. > >DaveO. > >> On Jun 8, 2015, at 2:45 PM, Ignacio.Solis at parc.com wrote: >> >> On 6/8/15, 11:11 AM, "Muhammad Hosain Abdollahi Sabet" >> wrote: >>> Actually I'm looking for a chances to have self-learning path feature, >>>which implies - I guess - receiving data packets on faces which are not >>>the same faces the interest has been forwarded to, or in better words >>>the faces which is not in the corresponding FIB entry. >> >> Can you describe what you have in mind? I?m unclear what you mean by >>self-learning path features with respect to the data objects. I can >>come up with protocols in my mind but they change the behavior of >>NDN/CCN drastically. >> >>> I'm not quite aware of those security risks you are talking about, and >>>I will be grateful If you could enlighten me a bit. >>> The only point that is in my mind right now is that accepting such >>>data packets will break fully symmetric subscriber-publisher approach. >> >> Well, in a regular Interest->Data exchange allowing "off-path? >>responses basically means you can have nodes that shouldn?t have >>authority in responding to traffic being able to generate responses. >>This is a waste of resources and a potential denial of service between >>otherwise cooperating nodes. A node off path can insert data in >>response to interests that will cause nodes to perform extra work >>(verifying hashes or signatures, triggering retransmissions, adding >>exclude filters, etc). >> >> You can imagine this gets trickier on multi-access networks. >> >> Nacho >> >> >> >>> -----Original Message----- >>> From: Ignacio.Solis at parc.com [mailto:Ignacio.Solis at parc.com] >>> Sent: Mon 6/8/2015 10:21 PM >>> To: shijunxiao at email.arizona.edu >>> Cc: Muhammad Hosain Abdollahi Sabet; ndn-interest at lists.cs.ucla.edu >>> Subject: Re: [Ndn-interest] Data comes from another face? >>> >>> On 6/8/15, 10:15 AM, "Junxiao Shi" >>>> >>>wrote: >>> >>> Sabet's original question is asking whether a Data packet could be >>>received on a face where an Interest has not been forwarded to, under >>>normal situations. The question is not about whether such Data packet >>>should be accepted. >>> Currently NFD forwarding would accept a Data packet as long as there >>>is a PIT entry, without considering whether an Interest has been >>>forwarded to the incoming face. >>> This behavior is inherited from ccnd 0.7.2, and I know there's a >>>security risk. >>> >>> Good thing we deprecated the old ccnd :-). >>> . >>> >>> I also suspect there would forwarding problems where transmissions on >>>a multi-access link cannot reach every node. >>> But I'm unfamiliar with those links, so I can't say exactly what >>>problem could occur. >>> >>> Assume a network of: A--B--C--D where nodes can only hear >>>neighbors. So: A can hear B but not C. B can hear both A+C. C can >>>hear B+D, D can only hear C. A is a requester, D is a producer. A >>>wants to get data located at D. >>> >>> Case 1 - Nodes don't forward interests over the interface they >>>received them from. >>> A sends and interest and B gets it. B needs to forward the interest, >>>but won't do so over the same interface it arrived on. Protocol fails. >>> >>> Case 2 - Nodes forward interest over interface they received it on + >>>nodes don't forward objects over same interface >>> A sends an interest and B gets it. It forwards the interest. Any >>>node that receives the interest will forward it, flooding the network. >>>C gets the interest, D gets the interest. D responds. C gets the >>>reply satisfying the PIT from the interface that requested it. It >>>assumes somebody else answered. - Protocol fails. >>> Case 2b - Nodes that receive duplicate interests (same nonce), send >>>control message to prune >>> Chaos ensues as networks larger than 3 start pruning each other. A >>>sends to B. B sends to A+C. C sends to B+D. >>> B sees same interest from C, sends a prune message to C. C removes pit >>>state. >>> Case 2b.1 - If there is hold time on PIT, C won't create a PIT entry >>>again. Protocol fails. >>> Case 2b.2 - If there is no hold time on the PIT entry, it may get >>>created again as the interest is still being flooded. Network will >>>continuously prune and flood, collapsing. - Network fails. >>> >>> Case 3 - Nodes forward interest over interface they received it on + >>>nodes forward objects over same interface >>> Same as Case 2, interest is flooded on the network. and then the data >>>is flooded on the network. >>> >>> I'm sure other cases exist. >>> >>> These errors don't occur if the link/interface/face has other >>>properties. Like they can all hear each other (though there may are >>>other issues in this scenario alone), there is an underlying protocol >>>(like MAC level unicast), next-hops are used instead of >>>interfaces/links/faces, etc. >>> >>> Again, maybe there are NDN features I'm not aware of or forgot. But >>>either way, it's a good discussion to have. And maybe you can clarify >>>how NDN handles these cases. >>> >>> Nacho >>> >>> >>> >>> On Mon, Jun 8, 2015 at 9:55 AM, >>>> wrote: >>> Hi folks. >>> >>> I wanted to bring up a couple of important points to this discussion >>>that have not been mentioned. Maybe people have already assimilated >>>them so they think they're obvious, but just in case: >>> >>> 1- A node should not accept data packets over links/interfaces/faces >>>over which it did not forward an interest. This is a security risk. >>> >>> 2- NDN may have issues over multiple access links/interfaces/faces >>>where not all nodes can hear each other (non-infrastructure WiFi). >>> >>> Both of these are true in the basic case. It's possible that with >>>extra design, protocols or developments that I'm unaware of these can >>>be mitigated/solved. >>> >>> Nacho >>> >>> >>> -- >>> Nacho (Ignacio) Solis >>> Protocol Architect >>> Principal Scientist >>> Palo Alto Research Center (PARC) >>> +1(650)812-4458 >>> Ignacio.Solis at parc.com >>> >>> >>> >> _______________________________________________ >> Ndn-interest mailing list >> Ndn-interest at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > From jefft0 at remap.ucla.edu Mon Jun 8 14:57:13 2015 From: jefft0 at remap.ucla.edu (Thompson, Jeff) Date: Mon, 8 Jun 2015 21:57:13 +0000 Subject: [Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256? In-Reply-To: <3DB747F4-8EDE-40F6-AD6A-2024B62F02EB@cs.ucla.edu> References: <1C839A4C-7C50-4847-8428-B8098983536C@parc.com> <49DE0EF2-012F-4996-80EC-FC52BCCF9BC6@parc.com> <884C8B3F-51D8-4B01-8EE6-EC9337F1FE00@parc.com> <3DB747F4-8EDE-40F6-AD6A-2024B62F02EB@cs.ucla.edu> Message-ID: Hi Yingdi, If the application uses a truncated key digest (e.g. the first 4 bytes of the digest), do you think we can still use the KeyDigest field? Or, if we treat the truncated key digest as a KeyId and put it in a Name, should the spec suggest a format for the Name? - Jeff T From: Yingdi Yu > Date: Friday, June 5, 2015 at 17:58 To: Marc Mosko > Cc: Jeff Thompson >, "Ndn-interest at lists.cs.ucla.edu" > Subject: Re: [Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256? I would prefer to explicitly state in the spec that, for HMAC signature, validating implementation should look up keys in local symmetric key storage. If we restrict the usage of KeyLocator of HMAC to local lookup, we can use Name as KeyId (in KeyLocator). I do not think KeyDigest would be very useful, but if a data producer really wants to use KeyDigest as a KeyLocator, the definition JeffT made in the first mail should be fine. Yingdi On Jun 2, 2015, at 10:14 AM, Marc.Mosko at parc.com wrote: My concern with using the Name in a KeyLocator is that some implementations will start sending an Interest for the name, which is the normal thing to do for a Name in a KeyLocator. If there is some way to clearly indicate in this case the name it is non-routable and that its purpose is to identify a KeyId, that would be ok. I understand that should be implicit from the SignatureType being HMAC?. From the spec on SignatureInfo, one reads: The specific definition of the usage of Name and KeyDigest options in KeyLocator field is outside the scope of this specification. Generally, Name names the Data packet with the corresponding certificate. However, it is up to the specific trust model to define whether this name is a full name of the Data packet or a prefix that can match multiple Data packets. For example, the hierarchical trust model [1] uses the latter approach, requiring clients to fetch the latest version of the Data packet pointed by the KeyLocator (the latest version of the public key certificate) in order to ensure that the public key was not yet revoked. So that does not really allow the third option that the Name does not specify any Data packet but rather names a KeyId. Marc On Jun 2, 2015, at 6:05 PM, Thompson, Jeff > wrote: Hi Marc, As I asked Gene, to avoid expanding the definition of KeyLocator, it is possible to use a local/relative sense of a Name for the Key ID? - Jeff T From: "Marc.Mosko at parc.com" > Date: Monday, June 1, 2015 at 14:32 To: Jeff Thompson > Cc: "christian.tschudin at unibas.ch" >, "Ndn-interest at lists.cs.ucla.edu" > Subject: Re: [Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256? I think overloading the use of a Name to avoid overloading the use of KeyDigest is trading one thing for another. If the Name is only an SPI (32-bit integer), for example, then its not really a name either as it cannot be fetched. I agree that if KeyDigest is defined as the SHA256 of something (as it is in the ndn spec), then its not the right container for an index, and possibly not the right container for a truncated digest. To avoid mis-using a Name and mis-using a KeyDigest, then it looks like one would need to introduce a new TLV container ?KeyIndex? or something like that to accommodate negotiated key IDs in a key exchange protocol. To accomodate truncated KeyDigest, one could use a new container. However, if it is a truncated SHA256, then I think it would be obvious that it is only the ?length? bytes of the SHA256, not the full 32-bytes. I could see allowing a shorter (left truncated) SHA256 in the KeyDigest without loss of specificity. Marc On Jun 1, 2015, at 7:42 PM, Thompson, Jeff > wrote: Hi Christian and Marc, I think we agree that we'll spell out how to get the key digest from the Key, but not spell out the HMAC algorithm itself (or how Key is padded to make the internally-used KeyValue). If the applications want to use an integer identifier for the Key, then the KeyLocator would need to be a Name with the integer as a name component, right? Also, if the "truncated key digest" (maybe as short as a byte) is used as an identifier, I wonder whether this should be in a Name too. This way, we don't mess with the semantics of KeyDigest which usually means the full digest. What do you think? Thanks, - Jeff T On 2015/6/1, 9:48, "christian.tschudin at unibas.ch" > wrote: I understood Jeff wanting to make the spec as self-contained as possible, but I doubt that a reference to an HMAC-internal variable is helping. (It translate into "Dear NDN implementor, to implement this two-line feature you need to read the following RFC and locate that Keyval variable in your favorit shrinked-wrapped library." As a probe: the Python hashlib API page does not reference it). So better write at least that part out? Regarding how to choose the KeyId (hash, ISAKMP SPI etc): I see, so it make sense to point out the many possibilities to pick your way. At least an advantage of the currently discussed hashing approach would be to not add another document to read 8-) best, c On Mon, 1 Jun 2015, Marc.Mosko at parc.com wrote: The proposed spec already defines KeyValue as the right-padded (for short keys) or sha256 (for long keys) of the Key. I would define the KeyDigest as the SHA256(KeyValue) and not repeat the same algorithm used to compute KeyValue. With regard to repeating the definition of HMAC, I would not do that but simply say that the ?text? input to HMAC is {Name, MetaInfo, Content, SignatureInfo} TLVs. For symmetric key systems, like HMAC, I think it is also acceptable to use an agreed upon integer identifier for the shared secret, as determined by a key exchange protocol (e.g. an ISAKMP SPI). I don?t think that symmetric key KeyDigests need to be derived from the key. That?s different than public key systems, where the the KeyDigest is used like the Subject Key Identifier (RFC 5280 4.2.1.2) and derived from the actual public key. Marc On Jun 1, 2015, at 1:45 PM, > > wrote: On Wed, 27 May 2015, Thompson, Jeff wrote: Hello Christian, Two questions: 1. Can you repeat your suggestion that the spec allow a truncated form of the key digest, for example the first 8 bytes of the key digest instead of the full 32 bytes? Hi Jeff, This is a trick that Marc Mosko used when we presented the 1+0 encoding at the January ICNRG interim meeting: Just reduce then number of KeyID-Bits (2 Bytes, in our case), if need be. The observation is that the key digest is for convenience, not security reasons: If you have many parties for which you have to maintain different symmetric keys, it is nice to quickly identify which key to use for validating the signature. But theoretically, you could just try out all symmetric keys you have for some peer. Rivest's "chaffing and winnowing" even relies on not sending any KeyID bits, on purpose. 2. If you want this suggestion on the spec, what is the best way to describe the computation of the key digest if we don't describe the HMAC algorithm in the spec? First, it could be made optional. But then I think it would be good to write down how the digest is computed, as you suggest (because RFC 2104 does not cover it, right?) Adapted from previous text of yours: "The Key must not be included in the signature but optionally a full or partial KeyDigest can be put in the KeyLocator block of the SignatureInfo field. If the byte length of Key is less than or equal to the SHA256 block length (64 bytes) then the full length KeyDigest is SHA256(Key). But if the byte length of Key is greater than 64 bytes, the KeyValue is already SHA256(Key) with zeros appended, so in this case the full length KeyDigest is SHA256(SHA256(Key)). The optional KeyDigest bits consist of 2 to 32 of the most-significant (=left-most) bytes of the full length KeyDigest. For the convenience of the validator and if packet size permits, it is recommended to include the full 32 bytes." Would that be precise enough? best, c Thanks, - Jeff T From: Junxiao Shi > Date: Wednesday, May 27, 2015 at 5:10 To: Jeff Thompson > Cc: "ndn-interest at lists.cs.ucla.edu" > Subject: Re: [Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256? Dear folks Details about HMAC algorithm, or any other crypto algorithm, SHOULD NOT appear in NDN Packet Format spec. Instead, the implementer should be referred to RFC. Those details are duplication of RFC, and they would make the spec unnecessary long. They also increase the probability of incorrect implementations because the implementer is unsure whether it's exactly same as what she/he has in the library, and would have to implement it again. "don't have HMAC in their crypto library" is not a valid argument - it's easier to find an RFC-compliant library or snippet for most languages than to implement according to the (duplicate of RFC in) spec. Yours, Junxiao On Mon, May 18, 2015 at 4:00 PM, Thompson, Jeff > wrote: The proposed SignatureHmacWithSha256 spec (below) repeats the details of the HMAC algorithm from RFC 2104. But should the details be removed and just refer to RFC 2104? Arguments for keeping the details are that it provides details for the discussion of creating the KeyDIgest and also because some applications don't have HMAC in their crypto library and need to implement it directly. An argument against keeping the details is that the info is in RFC 2104 so an application writer can read the RFC if needed, and that we don't repeat the details of other algorithms like SHA-256. Any opinions on removing the algorithm details? - Jeff T _______________________________________________ Ndn-interest mailing list 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From yingdi at CS.UCLA.EDU Mon Jun 8 16:44:42 2015 From: yingdi at CS.UCLA.EDU (Yingdi Yu) Date: Mon, 8 Jun 2015 16:44:42 -0700 Subject: [Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256? In-Reply-To: References: <1C839A4C-7C50-4847-8428-B8098983536C@parc.com> <49DE0EF2-012F-4996-80EC-FC52BCCF9BC6@parc.com> <884C8B3F-51D8-4B01-8EE6-EC9337F1FE00@parc.com> <3DB747F4-8EDE-40F6-AD6A-2024B62F02EB@cs.ucla.edu> Message-ID: Hi Jeff, > On Jun 8, 2015, at 2:57 PM, Thompson, Jeff wrote: > > If the application uses a truncated key digest (e.g. the first 4 bytes of the digest), do you think we can still use the KeyDigest field? Or, if we treat the truncated key digest as a KeyId and put it in a Name, should the spec suggest a format for the Name? I would prefer to keep KeyDigest literally (i.e., the real sha256 digest of a key), so that it is consistent with other scenarios (e.g., KeyDigest of public key). For the key name, I think the purpose is to allow both ends to uniquely identify the key. Is there any particular reason of using the first 4 bytes of the digest? Yingdi -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Mon Jun 8 19:03:47 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Mon, 8 Jun 2015 19:03:47 -0700 Subject: [Ndn-interest] Faces and adjacency In-Reply-To: References: Message-ID: Dear folks Excerpt from *NFD Developer Guide*: A Face is an abstraction which implements communication primitives to actually send and receive Interest and Data packets. Depending on nature of communication, a Face can represent slightly different elements. For "unicast" communications (TCP, unicast UDP, UNIX sockets, WebSocket), a Face represents a connection between local and remote endpoints for the specific protocol, i.e, a connection between NFDs on different network nodes or local NFD and local application. For multi-access communications (Ethernet, IP multicast), a Face represents a virtual connection between a local endpoint and zero or more remote peers. This means: - A point-to-point face is an adjacency. - A multi-access face is a L2 interface. In reality, most communications are still using UDP or TCP tunnels. NFD can operate directly on Ethernet. Currently Ethernet support is limited to multicast only. When we integrate NDNLPv1 fragmentation and reassembly, it appears necessary to maintain some kind of adjacency, because the receive must reassemble frames from each individual sender address separately. But there's no explicit adjacency concept in Ethernet face. The only other multi-access face implemented in NFD is IPv4 UDP multicast. It's limited to one hop only so it isn't much different from Ethernet multicast. But if this is extended to allow multiple hops, the problem of "not everyone receive a packet" would happen. In my experiments of self-learning forwarding (see basic idea in NDNcomm 2014 "NDN in local area networks" presentation), I find it more convenient to define a face as a L2 interface. This would allow a node to send an Interest to a well-known multicast address during flooding in order to reach all NDN nodes on a L2 segment, but the reply Data could be delivered over unicast toward the requester only so that other nodes won't be bothered. Yours, Junxiao On Mon, Jun 8, 2015 at 12:23 PM, wrote: > CCNx (1.0) is designed for adjacency. > > In old CCN (0.x) (and maybe NDN too if based on the old CCN model), faces > were used for PITs and FIBs. Faces could behave like L2 in many > circumstances, so these were real problems. For example, what is > currently done for multicast faces? > > Nacho > On Mon, Jun 8, 2015 at 11:53 AM, Dave Oran (oran) wrote: > Naive question: > > Are faces like L2 interfaces, or like routing adjacencies? > If the former, all the kinds of weirdnesses regarding unsolicited data and > non-transitivity show up. > If the latter, you need an adjacency initialization and maintenance > protocol (which all routing protocols running on multi-access links have), > but you avoid all the messiness pointed out in this thread. > > My recommendation is that faces behave as adjacencies, not interfaces and > that we adopt or design a good adjacency management protocol ASAP. > > DaveO. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Marc.Mosko at parc.com Tue Jun 9 03:53:52 2015 From: Marc.Mosko at parc.com (Marc.Mosko at parc.com) Date: Tue, 9 Jun 2015 10:53:52 +0000 Subject: [Ndn-interest] Data comes from another face? In-Reply-To: References: <4AC03A6244C3C34BB52A7EC60B799C4C03CC2964@m-pdc.sbu.ac.ir> <4AC03A6244C3C34BB52A7EC60B799C4C03CC2969@m-pdc.sbu.ac.ir> <4AC03A6244C3C34BB52A7EC60B799C4C03CC296B@m-pdc.sbu.ac.ir> <4AC03A6244C3C34BB52A7EC60B799C4C03CC296F@m-pdc.sbu.ac.ir> Message-ID: The ccnx 1.0 approach has been that neighbors operate like adjacencies plus broadcast interfaces so one could send a packet to a group, multicast, or broadcast address. In general, sending an Interest to a broadcast interface is not a great idea, I think, without some other protocols around it to prevent implosion. Group, multicast, and broadcast are useful for advertisements and discovery. We currently have some automatic learning of these adjacencies but without a management protocol of security. I agree, we need a secure link management protocol and we have been discussing this internally for some time. We will bring this up with the community very soon. In regards to the original poster?s question about self-learning path discovery, how is that different than an on-demand routing protocol? There are also several questions one should answer, such as: is the network secure (i.e. at the physical or link level) or do you need to worry about compromised nodes or mis-behaving nodes? If you worry about compromised nodes or mis-behaving nodes, then accepting a Data object from an unexpected previous hop is a good way to allow those nodes to black-hole certain names, as those nodes could simply start sending bogus responses for common names which would then result in the end-device having to fail a signature validation and re-request the data with an exclusion or a name nonce. Marc On Jun 8, 2015, at 7:53 PM, Dave Oran (oran) wrote: > Naive question: > > Are faces like L2 interfaces, or like routing adjacencies? > If the former, all the kinds of weirdnesses regarding unsolicited data and non-transitivity show up. > If the latter, you need an adjacency initialization and maintenance protocol (which all routing protocols running on multi-access links have), but you avoid all the messiness pointed out in this thread. > > My recommendation is that faces behave as adjacencies, not interfaces and that we adopt or design a good adjacency management protocol ASAP. > > DaveO. > >> On Jun 8, 2015, at 2:45 PM, Ignacio.Solis at parc.com wrote: >> >> On 6/8/15, 11:11 AM, "Muhammad Hosain Abdollahi Sabet" wrote: >>> Actually I'm looking for a chances to have self-learning path feature, which implies - I guess - receiving data packets on faces which are not the same faces the interest has been forwarded to, or in better words the faces which is not in the corresponding FIB entry. >> >> Can you describe what you have in mind? I?m unclear what you mean by self-learning path features with respect to the data objects. I can come up with protocols in my mind but they change the behavior of NDN/CCN drastically. >> >>> I'm not quite aware of those security risks you are talking about, and I will be grateful If you could enlighten me a bit. >>> The only point that is in my mind right now is that accepting such data packets will break fully symmetric subscriber-publisher approach. >> >> Well, in a regular Interest->Data exchange allowing "off-path? responses basically means you can have nodes that shouldn?t have authority in responding to traffic being able to generate responses. This is a waste of resources and a potential denial of service between otherwise cooperating nodes. A node off path can insert data in response to interests that will cause nodes to perform extra work (verifying hashes or signatures, triggering retransmissions, adding exclude filters, etc). >> >> You can imagine this gets trickier on multi-access networks. >> >> Nacho >> >> >> >>> -----Original Message----- >>> From: Ignacio.Solis at parc.com [mailto:Ignacio.Solis at parc.com] >>> Sent: Mon 6/8/2015 10:21 PM >>> To: shijunxiao at email.arizona.edu >>> Cc: Muhammad Hosain Abdollahi Sabet; ndn-interest at lists.cs.ucla.edu >>> Subject: Re: [Ndn-interest] Data comes from another face? >>> >>> On 6/8/15, 10:15 AM, "Junxiao Shi" > wrote: >>> >>> Sabet's original question is asking whether a Data packet could be received on a face where an Interest has not been forwarded to, under normal situations. The question is not about whether such Data packet should be accepted. >>> Currently NFD forwarding would accept a Data packet as long as there is a PIT entry, without considering whether an Interest has been forwarded to the incoming face. >>> This behavior is inherited from ccnd 0.7.2, and I know there's a security risk. >>> >>> Good thing we deprecated the old ccnd :-). >>> . >>> >>> I also suspect there would forwarding problems where transmissions on a multi-access link cannot reach every node. >>> But I'm unfamiliar with those links, so I can't say exactly what problem could occur. >>> >>> Assume a network of: A--B--C--D where nodes can only hear neighbors. So: A can hear B but not C. B can hear both A+C. C can hear B+D, D can only hear C. A is a requester, D is a producer. A wants to get data located at D. >>> >>> Case 1 - Nodes don't forward interests over the interface they received them from. >>> A sends and interest and B gets it. B needs to forward the interest, but won't do so over the same interface it arrived on. Protocol fails. >>> >>> Case 2 - Nodes forward interest over interface they received it on + nodes don't forward objects over same interface >>> A sends an interest and B gets it. It forwards the interest. Any node that receives the interest will forward it, flooding the network. C gets the interest, D gets the interest. D responds. C gets the reply satisfying the PIT from the interface that requested it. It assumes somebody else answered. - Protocol fails. >>> Case 2b - Nodes that receive duplicate interests (same nonce), send control message to prune >>> Chaos ensues as networks larger than 3 start pruning each other. A sends to B. B sends to A+C. C sends to B+D. >>> B sees same interest from C, sends a prune message to C. C removes pit state. >>> Case 2b.1 - If there is hold time on PIT, C won't create a PIT entry again. Protocol fails. >>> Case 2b.2 - If there is no hold time on the PIT entry, it may get created again as the interest is still being flooded. Network will continuously prune and flood, collapsing. - Network fails. >>> >>> Case 3 - Nodes forward interest over interface they received it on + nodes forward objects over same interface >>> Same as Case 2, interest is flooded on the network. and then the data is flooded on the network. >>> >>> I'm sure other cases exist. >>> >>> These errors don't occur if the link/interface/face has other properties. Like they can all hear each other (though there may are other issues in this scenario alone), there is an underlying protocol (like MAC level unicast), next-hops are used instead of interfaces/links/faces, etc. >>> >>> Again, maybe there are NDN features I'm not aware of or forgot. But either way, it's a good discussion to have. And maybe you can clarify how NDN handles these cases. >>> >>> Nacho >>> >>> >>> >>> On Mon, Jun 8, 2015 at 9:55 AM, > wrote: >>> Hi folks. >>> >>> I wanted to bring up a couple of important points to this discussion that have not been mentioned. Maybe people have already assimilated them so they think they're obvious, but just in case: >>> >>> 1- A node should not accept data packets over links/interfaces/faces over which it did not forward an interest. This is a security risk. >>> >>> 2- NDN may have issues over multiple access links/interfaces/faces where not all nodes can hear each other (non-infrastructure WiFi). >>> >>> Both of these are true in the basic case. It's possible that with extra design, protocols or developments that I'm unaware of these can be mitigated/solved. >>> >>> Nacho >>> >>> >>> -- >>> Nacho (Ignacio) Solis >>> Protocol Architect >>> Principal Scientist >>> Palo Alto Research Center (PARC) >>> +1(650)812-4458 >>> Ignacio.Solis at parc.com >>> >>> >>> >> _______________________________________________ >> Ndn-interest mailing list >> 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 From M.AbdollahiSabet at mail.sbu.ac.ir Tue Jun 9 05:54:41 2015 From: M.AbdollahiSabet at mail.sbu.ac.ir (Muhammad Hosain Abdollahi Sabet) Date: Tue, 9 Jun 2015 17:24:41 +0430 Subject: [Ndn-interest] Data comes from another face? References: <4AC03A6244C3C34BB52A7EC60B799C4C03CC2964@m-pdc.sbu.ac.ir><4AC03A6244C3C34BB52A7EC60B799C4C03CC2969@m-pdc.sbu.ac.ir><4AC03A6244C3C34BB52A7EC60B799C4C03CC296B@m-pdc.sbu.ac.ir><4AC03A6244C3C34BB52A7EC60B799C4C03CC296F@m-pdc.sbu.ac.ir> Message-ID: <4AC03A6244C3C34BB52A7EC60B799C4C03CC2970@m-pdc.sbu.ac.ir> Nacho, >Can you describe what you have in mind? I?m unclear what you mean by self-learning path features with respect to the data objects. I can come up with protocols in my mind but they change the behavior of NDN/CCN drastically. Suppose a consumer asks for a piece of data which is in a small/medium-scale access networks. In case A, at first due to not having FIBs built or not having record for a prefix, routers don't know where to forward the interest and do restricted flooding to find the data(and the corresponding prefix). After producer discovery, FIB record for the prefix will be made. Case B is when producer moves. So again the flooding will occur(maybe only for the first interest) to find the producer's new location and update FIB record. Actually it is more a like secondary forwarding strategy. In both cases, there is no need for sending data objects in broadcast or multicast. Case A is similar to Junxiao's presentation in NDNComm 2014 which I hadn't seen it before opening the topic. Marc, >If you worry about compromised nodes or mis-behaving nodes, then accepting a Data object from an unexpected previous hop is a good way to allow those nodes to black-hole certain names, as those nodes could simply start sending bogus responses for common names. You are right. My assumption is that in mobile producer case which consumer is looking for an actual node, names are not common so the risk is not high. Thanks, Sabet -----Original Message----- From: Ndn-interest on behalf of Marc.Mosko at parc.com Sent: Tue 6/9/2015 3:23 PM To: oran at cisco.com Cc: Ignacio.Solis at parc.com; ndn-interest at lists.cs.ucla.edu Subject: Re: [Ndn-interest] Data comes from another face? The ccnx 1.0 approach has been that neighbors operate like adjacencies plus broadcast interfaces so one could send a packet to a group, multicast, or broadcast address. In general, sending an Interest to a broadcast interface is not a great idea, I think, without some other protocols around it to prevent implosion. Group, multicast, and broadcast are useful for advertisements and discovery. We currently have some automatic learning of these adjacencies but without a management protocol of security. I agree, we need a secure link management protocol and we have been discussing this internally for some time. We will bring this up with the community very soon. In regards to the original poster's question about self-learning path discovery, how is that different than an on-demand routing protocol? There are also several questions one should answer, such as: is the network secure (i.e. at the physical or link level) or do you need to worry about compromised nodes or mis-behaving nodes? If you worry about compromised nodes or mis-behaving nodes, then accepting a Data object from an unexpected previous hop is a good way to allow those nodes to black-hole certain names, as those nodes could simply start sending bogus responses for common names which would then result in the end-device having to fail a signature validation and re-request the data with an exclusion or a name nonce. Marc On Jun 8, 2015, at 7:53 PM, Dave Oran (oran) wrote: > Naive question: > > Are faces like L2 interfaces, or like routing adjacencies? > If the former, all the kinds of weirdnesses regarding unsolicited data and non-transitivity show up. > If the latter, you need an adjacency initialization and maintenance protocol (which all routing protocols running on multi-access links have), but you avoid all the messiness pointed out in this thread. > > My recommendation is that faces behave as adjacencies, not interfaces and that we adopt or design a good adjacency management protocol ASAP. > > DaveO. > >> On Jun 8, 2015, at 2:45 PM, Ignacio.Solis at parc.com wrote: >> >> On 6/8/15, 11:11 AM, "Muhammad Hosain Abdollahi Sabet" wrote: >>> Actually I'm looking for a chances to have self-learning path feature, which implies - I guess - receiving data packets on faces which are not the same faces the interest has been forwarded to, or in better words the faces which is not in the corresponding FIB entry. >> >> Can you describe what you have in mind? I'm unclear what you mean by self-learning path features with respect to the data objects. I can come up with protocols in my mind but they change the behavior of NDN/CCN drastically. >> >>> I'm not quite aware of those security risks you are talking about, and I will be grateful If you could enlighten me a bit. >>> The only point that is in my mind right now is that accepting such data packets will break fully symmetric subscriber-publisher approach. >> >> Well, in a regular Interest->Data exchange allowing "off-path" responses basically means you can have nodes that shouldn't have authority in responding to traffic being able to generate responses. This is a waste of resources and a potential denial of service between otherwise cooperating nodes. A node off path can insert data in response to interests that will cause nodes to perform extra work (verifying hashes or signatures, triggering retransmissions, adding exclude filters, etc). >> >> You can imagine this gets trickier on multi-access networks. >> >> Nacho >> >> >> >>> -----Original Message----- >>> From: Ignacio.Solis at parc.com [mailto:Ignacio.Solis at parc.com] >>> Sent: Mon 6/8/2015 10:21 PM >>> To: shijunxiao at email.arizona.edu >>> Cc: Muhammad Hosain Abdollahi Sabet; ndn-interest at lists.cs.ucla.edu >>> Subject: Re: [Ndn-interest] Data comes from another face? >>> >>> On 6/8/15, 10:15 AM, "Junxiao Shi" > wrote: >>> >>> Sabet's original question is asking whether a Data packet could be received on a face where an Interest has not been forwarded to, under normal situations. The question is not about whether such Data packet should be accepted. >>> Currently NFD forwarding would accept a Data packet as long as there is a PIT entry, without considering whether an Interest has been forwarded to the incoming face. >>> This behavior is inherited from ccnd 0.7.2, and I know there's a security risk. >>> >>> Good thing we deprecated the old ccnd :-). >>> . >>> >>> I also suspect there would forwarding problems where transmissions on a multi-access link cannot reach every node. >>> But I'm unfamiliar with those links, so I can't say exactly what problem could occur. >>> >>> Assume a network of: A--B--C--D where nodes can only hear neighbors. So: A can hear B but not C. B can hear both A+C. C can hear B+D, D can only hear C. A is a requester, D is a producer. A wants to get data located at D. >>> >>> Case 1 - Nodes don't forward interests over the interface they received them from. >>> A sends and interest and B gets it. B needs to forward the interest, but won't do so over the same interface it arrived on. Protocol fails. >>> >>> Case 2 - Nodes forward interest over interface they received it on + nodes don't forward objects over same interface >>> A sends an interest and B gets it. It forwards the interest. Any node that receives the interest will forward it, flooding the network. C gets the interest, D gets the interest. D responds. C gets the reply satisfying the PIT from the interface that requested it. It assumes somebody else answered. - Protocol fails. >>> Case 2b - Nodes that receive duplicate interests (same nonce), send control message to prune >>> Chaos ensues as networks larger than 3 start pruning each other. A sends to B. B sends to A+C. C sends to B+D. >>> B sees same interest from C, sends a prune message to C. C removes pit state. >>> Case 2b.1 - If there is hold time on PIT, C won't create a PIT entry again. Protocol fails. >>> Case 2b.2 - If there is no hold time on the PIT entry, it may get created again as the interest is still being flooded. Network will continuously prune and flood, collapsing. - Network fails. >>> >>> Case 3 - Nodes forward interest over interface they received it on + nodes forward objects over same interface >>> Same as Case 2, interest is flooded on the network. and then the data is flooded on the network. >>> >>> I'm sure other cases exist. >>> >>> These errors don't occur if the link/interface/face has other properties. Like they can all hear each other (though there may are other issues in this scenario alone), there is an underlying protocol (like MAC level unicast), next-hops are used instead of interfaces/links/faces, etc. >>> >>> Again, maybe there are NDN features I'm not aware of or forgot. But either way, it's a good discussion to have. And maybe you can clarify how NDN handles these cases. >>> >>> Nacho >>> >>> >>> >>> On Mon, Jun 8, 2015 at 9:55 AM, > wrote: >>> Hi folks. >>> >>> I wanted to bring up a couple of important points to this discussion that have not been mentioned. Maybe people have already assimilated them so they think they're obvious, but just in case: >>> >>> 1- A node should not accept data packets over links/interfaces/faces over which it did not forward an interest. This is a security risk. >>> >>> 2- NDN may have issues over multiple access links/interfaces/faces where not all nodes can hear each other (non-infrastructure WiFi). >>> >>> Both of these are true in the basic case. It's possible that with extra design, protocols or developments that I'm unaware of these can be mitigated/solved. >>> >>> Nacho >>> >>> >>> -- >>> Nacho (Ignacio) Solis >>> Protocol Architect >>> Principal Scientist >>> Palo Alto Research Center (PARC) >>> +1(650)812-4458 >>> Ignacio.Solis at parc.com >>> >>> >>> >> _______________________________________________ >> Ndn-interest mailing list >> 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 _______________________________________________ Ndn-interest mailing list Ndn-interest at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest -------------- next part -------------- An HTML attachment was scrubbed... URL: From jefft0 at remap.UCLA.EDU Tue Jun 9 08:29:50 2015 From: jefft0 at remap.UCLA.EDU (Thompson, Jeff) Date: Tue, 9 Jun 2015 15:29:50 +0000 Subject: [Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256? In-Reply-To: References: <1C839A4C-7C50-4847-8428-B8098983536C@parc.com> <49DE0EF2-012F-4996-80EC-FC52BCCF9BC6@parc.com> <884C8B3F-51D8-4B01-8EE6-EC9337F1FE00@parc.com> <3DB747F4-8EDE-40F6-AD6A-2024B62F02EB@cs.ucla.edu> Message-ID: > I think the purpose is to allow both ends to uniquely identify the key. Is there any particular reason of using the first 4 bytes of the digest? Using a short identifier (4 bytes) is to keep the packet short for low-power devices. Making a short identifier from the digest is an easy way to get a unique identifier instead of maintaining a separate list of sequential ID numbers. Does that answer your question? - Jeff T From: Yingdi Yu > Date: Monday, June 8, 2015 at 16:44 To: Jeff Thompson > Cc: Marc Mosko >, "Ndn-interest at lists.cs.ucla.edu" > Subject: Re: [Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256? Hi Jeff, On Jun 8, 2015, at 2:57 PM, Thompson, Jeff > wrote: If the application uses a truncated key digest (e.g. the first 4 bytes of the digest), do you think we can still use the KeyDigest field? Or, if we treat the truncated key digest as a KeyId and put it in a Name, should the spec suggest a format for the Name? I would prefer to keep KeyDigest literally (i.e., the real sha256 digest of a key), so that it is consistent with other scenarios (e.g., KeyDigest of public key). For the key name, I think the purpose is to allow both ends to uniquely identify the key. Is there any particular reason of using the first 4 bytes of the digest? Yingdi -------------- next part -------------- An HTML attachment was scrubbed... URL: From yingdi at CS.UCLA.EDU Tue Jun 9 11:16:24 2015 From: yingdi at CS.UCLA.EDU (Yingdi Yu) Date: Tue, 9 Jun 2015 11:16:24 -0700 Subject: [Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256? In-Reply-To: References: <1C839A4C-7C50-4847-8428-B8098983536C@parc.com> <49DE0EF2-012F-4996-80EC-FC52BCCF9BC6@parc.com> <884C8B3F-51D8-4B01-8EE6-EC9337F1FE00@parc.com> <3DB747F4-8EDE-40F6-AD6A-2024B62F02EB@cs.ucla.edu> Message-ID: > On Jun 9, 2015, at 8:29 AM, Thompson, Jeff wrote: > > > I think the purpose is to allow both ends to uniquely identify the key. Is there any particular reason of using the first 4 bytes of the digest? > > Using a short identifier (4 bytes) is to keep the packet short for low-power devices. Making a short identifier from the digest is an easy way to get a unique identifier instead of maintaining a separate list of sequential ID numbers. Does that answer your question? I do not think the first 4-bytes can provide a ?unique? identifier. If uniqueness is the major concern, we should use digest, given collision in sha256 has not been found yet. I did not quite understand what you mean by ?a separate list of sequential ID numbers?. My concern is about using digest or something related alone. Given HMAC is about authenticity, one might not be able to tell from a digest or even first 4 bytes that the key can be trusted for a particular data packet. We have to maintaining an additional mapping between the privilege of a key (which is usually the key name) and the key anyway. So using a digest does not save too much at the device side. For length of the key locator, given the packet size is already 1500-byte, I am not sure if it is a good tradeoff to sacrifice some good security property for just tens of bytes. Yingdi -------------- next part -------------- An HTML attachment was scrubbed... URL: From Marc.Mosko at parc.com Tue Jun 9 13:05:15 2015 From: Marc.Mosko at parc.com (Marc.Mosko at parc.com) Date: Tue, 9 Jun 2015 20:05:15 +0000 Subject: [Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256? In-Reply-To: References: <1C839A4C-7C50-4847-8428-B8098983536C@parc.com> <49DE0EF2-012F-4996-80EC-FC52BCCF9BC6@parc.com> <884C8B3F-51D8-4B01-8EE6-EC9337F1FE00@parc.com> <3DB747F4-8EDE-40F6-AD6A-2024B62F02EB@cs.ucla.edu> Message-ID: <29E10C3B-EBE7-4A18-9B11-05D369114353@parc.com> Yingdi, I do not think using the sha256 digest of a symmetric key is a security property (in the good sense). I think it is an unnecessary leaking of information. Symmetric keys must be rotated, based on the rate at which they are used and based on time. They are pair-wise associations. So, one only needs to keep track of keys for the given partner, such as a namespace or endpoint. And, one usually only needs to keep track of the last, current, and next keys to handle timing issues (or maybe just the current and next). So, there should not be a giant library of keys. Because the keys are rotated via a key exchange protocol they are easily identified by some index that can be cryptographically unrelated to the given key, preventing any possible information leakage. It may or may not be a sequential number, it depends on the key exchange protocol. Given that there are only a small number of keys that need to be maintained and that they are scoped by a namespace or endpoint, using the first 4-bytes of the key digest is highly likely to render uniqueness. But, like I said, I don?t think using a key digest is the right thing to do with symmetric keys. One needs a key exchange protocol because the next key should not be determined over a channel protected by the current key. That would break forward secrecy. Yes, if one has long-term statically configured keys one could identify them via their KeyDigest, but I think that is unwise. Both because they are static and because you possibly leak information in the KeyDigest. The issue of trust is separate from how a key is identified. The trust must be established by knowing the identity of the key exchange protocol peer, which is likely an RSA or EC public key. Trust decisions should never be made on the KeyDigest or KeyId until after one has verified the signature and then the remote identity is uniquely known based on which key verified the signature. So, even if there were a collision in KeyDigest or KeyID, one could still have strong authentication based on which of the colliding keys actually verified. Marc On Jun 9, 2015, at 7:16 PM, Yingdi Yu > wrote: On Jun 9, 2015, at 8:29 AM, Thompson, Jeff > wrote: > I think the purpose is to allow both ends to uniquely identify the key. Is there any particular reason of using the first 4 bytes of the digest? Using a short identifier (4 bytes) is to keep the packet short for low-power devices. Making a short identifier from the digest is an easy way to get a unique identifier instead of maintaining a separate list of sequential ID numbers. Does that answer your question? I do not think the first 4-bytes can provide a ?unique? identifier. If uniqueness is the major concern, we should use digest, given collision in sha256 has not been found yet. I did not quite understand what you mean by ?a separate list of sequential ID numbers?. My concern is about using digest or something related alone. Given HMAC is about authenticity, one might not be able to tell from a digest or even first 4 bytes that the key can be trusted for a particular data packet. We have to maintaining an additional mapping between the privilege of a key (which is usually the key name) and the key anyway. So using a digest does not save too much at the device side. For length of the key locator, given the packet size is already 1500-byte, I am not sure if it is a good tradeoff to sacrifice some good security property for just tens of bytes. Yingdi -------------- next part -------------- An HTML attachment was scrubbed... URL: From gts at ics.uci.EDU Tue Jun 9 13:16:39 2015 From: gts at ics.uci.EDU (GTS) Date: Tue, 09 Jun 2015 22:16:39 +0200 Subject: [Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256? In-Reply-To: <29E10C3B-EBE7-4A18-9B11-05D369114353@parc.com> References: <1C839A4C-7C50-4847-8428-B8098983536C@parc.com> <49DE0EF2-012F-4996-80EC-FC52BCCF9BC6@parc.com> <884C8B3F-51D8-4B01-8EE6-EC9337F1FE00@parc.com> <3DB747F4-8EDE-40F6-AD6A-2024B62F02EB@cs.ucla.edu> <29E10C3B-EBE7-4A18-9B11-05D369114353@parc.com> Message-ID: <557749A7.9010501@ics.uci.edu> FWIW, I fully agree with Marc's point of view, especially this bit: > I think it is an unnecessary leaking of information. Cheers, Gene On 6/9/15 10:05 PM, Marc.Mosko at parc.com wrote: > Yingdi, > > I do not think using the sha256 digest of a symmetric key is a > security property (in the good sense). I think it is an unnecessary > leaking of information. Symmetric keys must be rotated, based on the > rate at which they are used and based on time. They are pair-wise > associations. So, one only needs to keep track of keys for the given > partner, such as a namespace or endpoint. And, one usually only needs > to keep track of the last, current, and next keys to handle timing > issues (or maybe just the current and next). So, there should not be > a giant library of keys. > > Because the keys are rotated via a key exchange protocol they are > easily identified by some index that can be cryptographically > unrelated to the given key, preventing any possible information > leakage. It may or may not be a sequential number, it depends on the > key exchange protocol. > > Given that there are only a small number of keys that need to be > maintained and that they are scoped by a namespace or endpoint, using > the first 4-bytes of the key digest is highly likely to render > uniqueness. But, like I said, I don?t think using a key digest is the > right thing to do with symmetric keys. > > One needs a key exchange protocol because the next key should not be > determined over a channel protected by the current key. That would > break forward secrecy. > > Yes, if one has long-term statically configured keys one could > identify them via their KeyDigest, but I think that is unwise. Both > because they are static and because you possibly leak information in > the KeyDigest. > > The issue of trust is separate from how a key is identified. The > trust must be established by knowing the identity of the key exchange > protocol peer, which is likely an RSA or EC public key. Trust > decisions should never be made on the KeyDigest or KeyId until after > one has verified the signature and then the remote identity is > uniquely known based on which key verified the signature. So, even if > there were a collision in KeyDigest or KeyID, one could still have > strong authentication based on which of the colliding keys actually > verified. > > Marc > > On Jun 9, 2015, at 7:16 PM, Yingdi Yu > wrote: > >> >>> On Jun 9, 2015, at 8:29 AM, Thompson, Jeff >> > wrote: >>> >>> > I think the purpose is to allow both ends to uniquely identify the >>> key. Is there any particular reason of using the first 4 bytes of >>> the digest? >>> >>> Using a short identifier (4 bytes) is to keep the packet short for >>> low-power devices. Making a short identifier from the digest is an >>> easy way to get a unique identifier instead of maintaining a >>> separate list of sequential ID numbers. Does that answer your question? >> >> I do not think the first 4-bytes can provide a ?unique? identifier. >> If uniqueness is the major concern, we should use digest, given >> collision in sha256 has not been found yet. >> >> I did not quite understand what you mean by ?a separate list of >> sequential ID numbers?. >> >> My concern is about using digest or something related alone. Given >> HMAC is about authenticity, one might not be able to tell from a >> digest or even first 4 bytes that the key can be trusted for a >> particular data packet. We have to maintaining an additional mapping >> between the privilege of a key (which is usually the key name) and >> the key anyway. So using a digest does not save too much at the >> device side. >> >> For length of the key locator, given the packet size is already >> 1500-byte, I am not sure if it is a good tradeoff to sacrifice some >> good security property for just tens of bytes. >> >> Yingdi >> >> >> >> > > > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest -------------- next part -------------- An HTML attachment was scrubbed... URL: From yingdi at CS.UCLA.EDU Tue Jun 9 13:44:43 2015 From: yingdi at CS.UCLA.EDU (Yingdi Yu) Date: Tue, 9 Jun 2015 13:44:43 -0700 Subject: [Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256? In-Reply-To: <29E10C3B-EBE7-4A18-9B11-05D369114353@parc.com> References: <1C839A4C-7C50-4847-8428-B8098983536C@parc.com> <49DE0EF2-012F-4996-80EC-FC52BCCF9BC6@parc.com> <884C8B3F-51D8-4B01-8EE6-EC9337F1FE00@parc.com> <3DB747F4-8EDE-40F6-AD6A-2024B62F02EB@cs.ucla.edu> <29E10C3B-EBE7-4A18-9B11-05D369114353@parc.com> Message-ID: <813C1DD1-0FA3-44B1-A3CC-DDDB0FB248DA@cs.ucla.edu> Hi Marc, I also do not think we should use digest of symmetric key. What I mean a "security property? here is a structured name of the symmetric key which allows one to determine the trust scope of the key. Neither digest nor first 4 byte of a digest can provide such information. Yingdi > On Jun 9, 2015, at 1:05 PM, wrote: > > Yingdi, > > I do not think using the sha256 digest of a symmetric key is a security property (in the good sense). I think it is an unnecessary leaking of information. Symmetric keys must be rotated, based on the rate at which they are used and based on time. They are pair-wise associations. So, one only needs to keep track of keys for the given partner, such as a namespace or endpoint. And, one usually only needs to keep track of the last, current, and next keys to handle timing issues (or maybe just the current and next). So, there should not be a giant library of keys. > > Because the keys are rotated via a key exchange protocol they are easily identified by some index that can be cryptographically unrelated to the given key, preventing any possible information leakage. It may or may not be a sequential number, it depends on the key exchange protocol. > > Given that there are only a small number of keys that need to be maintained and that they are scoped by a namespace or endpoint, using the first 4-bytes of the key digest is highly likely to render uniqueness. But, like I said, I don?t think using a key digest is the right thing to do with symmetric keys. > > One needs a key exchange protocol because the next key should not be determined over a channel protected by the current key. That would break forward secrecy. > > Yes, if one has long-term statically configured keys one could identify them via their KeyDigest, but I think that is unwise. Both because they are static and because you possibly leak information in the KeyDigest. > > The issue of trust is separate from how a key is identified. The trust must be established by knowing the identity of the key exchange protocol peer, which is likely an RSA or EC public key. Trust decisions should never be made on the KeyDigest or KeyId until after one has verified the signature and then the remote identity is uniquely known based on which key verified the signature. So, even if there were a collision in KeyDigest or KeyID, one could still have strong authentication based on which of the colliding keys actually verified. > > Marc > > On Jun 9, 2015, at 7:16 PM, Yingdi Yu > wrote: > >> >>> On Jun 9, 2015, at 8:29 AM, Thompson, Jeff > wrote: >>> >>> > I think the purpose is to allow both ends to uniquely identify the key. Is there any particular reason of using the first 4 bytes of the digest? >>> >>> Using a short identifier (4 bytes) is to keep the packet short for low-power devices. Making a short identifier from the digest is an easy way to get a unique identifier instead of maintaining a separate list of sequential ID numbers. Does that answer your question? >> >> I do not think the first 4-bytes can provide a ?unique? identifier. If uniqueness is the major concern, we should use digest, given collision in sha256 has not been found yet. >> >> I did not quite understand what you mean by ?a separate list of sequential ID numbers?. >> >> My concern is about using digest or something related alone. Given HMAC is about authenticity, one might not be able to tell from a digest or even first 4 bytes that the key can be trusted for a particular data packet. We have to maintaining an additional mapping between the privilege of a key (which is usually the key name) and the key anyway. So using a digest does not save too much at the device side. >> >> For length of the key locator, given the packet size is already 1500-byte, I am not sure if it is a good tradeoff to sacrifice some good security property for just tens of bytes. >> >> Yingdi >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ignacio.Solis at parc.com Tue Jun 9 21:17:34 2015 From: Ignacio.Solis at parc.com (Ignacio.Solis at parc.com) Date: Wed, 10 Jun 2015 04:17:34 +0000 Subject: [Ndn-interest] Data comes from another face? In-Reply-To: <4AC03A6244C3C34BB52A7EC60B799C4C03CC2970@m-pdc.sbu.ac.ir> References: <4AC03A6244C3C34BB52A7EC60B799C4C03CC2964@m-pdc.sbu.ac.ir> <4AC03A6244C3C34BB52A7EC60B799C4C03CC2969@m-pdc.sbu.ac.ir> <4AC03A6244C3C34BB52A7EC60B799C4C03CC296B@m-pdc.sbu.ac.ir> <4AC03A6244C3C34BB52A7EC60B799C4C03CC296F@m-pdc.sbu.ac.ir> <4AC03A6244C3C34BB52A7EC60B799C4C03CC2970@m-pdc.sbu.ac.ir> Message-ID: On 6/9/15, 5:54 AM, "Muhammad Hosain Abdollahi Sabet" wrote: >>Can you describe what you have in mind? I?m unclear what you mean by >>self-learning path features with respect to the data objects. I can >>come up with protocols in my mind but they change the behavior of >>NDN/CCN drastically. > >Suppose a consumer asks for a piece of data which is in a >small/medium-scale access networks. In case A, at first due to not having >FIBs built or not having record for a prefix, routers don't know where to >forward the interest and do restricted flooding to find the data(and the >corresponding prefix). After producer discovery, FIB record for the >prefix will be made. Case B is when producer moves. So again the flooding >will occur(maybe only for the first interest) to find the producer's new >location and update FIB record. Actually it is more a like secondary >forwarding strategy. In both cases, there is no need for sending data >objects in broadcast or multicast. Case A is similar to Junxiao's >presentation in NDNComm 2014 which I hadn't seen it before opening the >topic. If I understand correctly, what you?re doing is exploring with the interests. So the interests are doing some flooding, but the data is not. The data is coming back on an interface you sent the interest on. BTW, I don?t recommend this (flooding interests) without some more advanced protocol on top. Specially if you plan on modifying the FIB based on there returned data object. Unless you have some security association to that requester/producer/name you may be asking for a trivial attack on the network. >>If you worry about compromised nodes or mis-behaving nodes, then >>accepting a Data object from an unexpected previous hop is a good way to >>allow those nodes to black-hole certain names, as those nodes could >>simply start sending bogus responses for common names. > >You are right. My assumption is that in mobile producer case which >consumer is looking for an actual node, names are not common so the risk >is not high. Like Marc mentioned, without some trust mechanism any node will be able to black hole traffic and prefixes. To make matters worse, if you?re flooding, any node will be able to see the interest traffic and carry out the attack. So, you?re going to need to add some security semantics to your protocol. I would guess that it?s probably easier to use an on-demand routing protocol (and secure that) than to use the interests to do the discovery with security. Nacho >-----Original Message----- >From: Ndn-interest on behalf of Marc.Mosko at parc.com >Sent: Tue 6/9/2015 3:23 PM >To: oran at cisco.com >Cc: Ignacio.Solis at parc.com; ndn-interest at lists.cs.ucla.edu >Subject: Re: [Ndn-interest] Data comes from another face? > >The ccnx 1.0 approach has been that neighbors operate like adjacencies >plus broadcast interfaces so one could send a packet to a group, >multicast, or broadcast address. In general, sending an Interest to a >broadcast interface is not a great idea, I think, without some other >protocols around it to prevent implosion. Group, multicast, and >broadcast are useful for advertisements and discovery. > >We currently have some automatic learning of these adjacencies but >without a management protocol of security. I agree, we need a secure >link management protocol and we have been discussing this internally for >some time. We will bring this up with the community very soon. > >In regards to the original poster's question about self-learning path >discovery, how is that different than an on-demand routing protocol? >There are also several questions one should answer, such as: is the >network secure (i.e. at the physical or link level) or do you need to >worry about compromised nodes or mis-behaving nodes? If you worry about >compromised nodes or mis-behaving nodes, then accepting a Data object >from an unexpected previous hop is a good way to allow those nodes to >black-hole certain names, as those nodes could simply start sending bogus >responses for common names which would then result in the end-device >having to fail a signature validation and re-request the data with an >exclusion or a name nonce. > >Marc > >On Jun 8, 2015, at 7:53 PM, Dave Oran (oran) wrote: > >> Naive question: >> >> Are faces like L2 interfaces, or like routing adjacencies? >> If the former, all the kinds of weirdnesses regarding unsolicited data >>and non-transitivity show up. >> If the latter, you need an adjacency initialization and maintenance >>protocol (which all routing protocols running on multi-access links >>have), but you avoid all the messiness pointed out in this thread. >> >> My recommendation is that faces behave as adjacencies, not interfaces >>and that we adopt or design a good adjacency management protocol ASAP. >> >> DaveO. >> >>> On Jun 8, 2015, at 2:45 PM, Ignacio.Solis at parc.com wrote: >>> >>> On 6/8/15, 11:11 AM, "Muhammad Hosain Abdollahi Sabet" >>> wrote: >>>> Actually I'm looking for a chances to have self-learning path >>>>feature, which implies - I guess - receiving data packets on faces >>>>which are not the same faces the interest has been forwarded to, or in >>>>better words the faces which is not in the corresponding FIB entry. >>> >>> Can you describe what you have in mind? I'm unclear what you mean by >>>self-learning path features with respect to the data objects. I can >>>come up with protocols in my mind but they change the behavior of >>>NDN/CCN drastically. >>> >>>> I'm not quite aware of those security risks you are talking about, >>>>and I will be grateful If you could enlighten me a bit. >>>> The only point that is in my mind right now is that accepting such >>>>data packets will break fully symmetric subscriber-publisher approach. >>> >>> Well, in a regular Interest->Data exchange allowing "off-path" >>>responses basically means you can have nodes that shouldn't have >>>authority in responding to traffic being able to generate responses. >>>This is a waste of resources and a potential denial of service between >>>otherwise cooperating nodes. A node off path can insert data in >>>response to interests that will cause nodes to perform extra work >>>(verifying hashes or signatures, triggering retransmissions, adding >>>exclude filters, etc). >>> >>> You can imagine this gets trickier on multi-access networks. >>> >>> Nacho >>> >>> >>> >>>> -----Original Message----- >>>> From: Ignacio.Solis at parc.com [mailto:Ignacio.Solis at parc.com] >>>> Sent: Mon 6/8/2015 10:21 PM >>>> To: shijunxiao at email.arizona.edu >>>> Cc: Muhammad Hosain Abdollahi Sabet; ndn-interest at lists.cs.ucla.edu >>>> Subject: Re: [Ndn-interest] Data comes from another face? >>>> >>>> On 6/8/15, 10:15 AM, "Junxiao Shi" >>>>> >>>>wrote: >>>> >>>> Sabet's original question is asking whether a Data packet could be >>>>received on a face where an Interest has not been forwarded to, under >>>>normal situations. The question is not about whether such Data packet >>>>should be accepted. >>>> Currently NFD forwarding would accept a Data packet as long as there >>>>is a PIT entry, without considering whether an Interest has been >>>>forwarded to the incoming face. >>>> This behavior is inherited from ccnd 0.7.2, and I know there's a >>>>security risk. >>>> >>>> Good thing we deprecated the old ccnd :-). >>>> . >>>> >>>> I also suspect there would forwarding problems where transmissions on >>>>a multi-access link cannot reach every node. >>>> But I'm unfamiliar with those links, so I can't say exactly what >>>>problem could occur. >>>> >>>> Assume a network of: A--B--C--D where nodes can only hear >>>>neighbors. So: A can hear B but not C. B can hear both A+C. C can >>>>hear B+D, D can only hear C. A is a requester, D is a producer. A >>>>wants to get data located at D. >>>> >>>> Case 1 - Nodes don't forward interests over the interface they >>>>received them from. >>>> A sends and interest and B gets it. B needs to forward the interest, >>>>but won't do so over the same interface it arrived on. Protocol fails. >>>> >>>> Case 2 - Nodes forward interest over interface they received it on + >>>>nodes don't forward objects over same interface >>>> A sends an interest and B gets it. It forwards the interest. Any >>>>node that receives the interest will forward it, flooding the network. >>>>C gets the interest, D gets the interest. D responds. C gets the >>>>reply satisfying the PIT from the interface that requested it. It >>>>assumes somebody else answered. - Protocol fails. >>>> Case 2b - Nodes that receive duplicate interests (same nonce), send >>>>control message to prune >>>> Chaos ensues as networks larger than 3 start pruning each other. A >>>>sends to B. B sends to A+C. C sends to B+D. >>>> B sees same interest from C, sends a prune message to C. C removes >>>>pit state. >>>> Case 2b.1 - If there is hold time on PIT, C won't create a PIT entry >>>>again. Protocol fails. >>>> Case 2b.2 - If there is no hold time on the PIT entry, it may get >>>>created again as the interest is still being flooded. Network will >>>>continuously prune and flood, collapsing. - Network fails. >>>> >>>> Case 3 - Nodes forward interest over interface they received it on + >>>>nodes forward objects over same interface >>>> Same as Case 2, interest is flooded on the network. and then the data >>>>is flooded on the network. >>>> >>>> I'm sure other cases exist. >>>> >>>> These errors don't occur if the link/interface/face has other >>>>properties. Like they can all hear each other (though there may are >>>>other issues in this scenario alone), there is an underlying protocol >>>>(like MAC level unicast), next-hops are used instead of >>>>interfaces/links/faces, etc. >>>> >>>> Again, maybe there are NDN features I'm not aware of or forgot. But >>>>either way, it's a good discussion to have. And maybe you can clarify >>>>how NDN handles these cases. >>>> >>>> Nacho >>>> >>>> >>>> >>>> On Mon, Jun 8, 2015 at 9:55 AM, >>>>> wrote: >>>> Hi folks. >>>> >>>> I wanted to bring up a couple of important points to this discussion >>>>that have not been mentioned. Maybe people have already assimilated >>>>them so they think they're obvious, but just in case: >>>> >>>> 1- A node should not accept data packets over links/interfaces/faces >>>>over which it did not forward an interest. This is a security risk. >>>> >>>> 2- NDN may have issues over multiple access links/interfaces/faces >>>>where not all nodes can hear each other (non-infrastructure WiFi). >>>> >>>> Both of these are true in the basic case. It's possible that with >>>>extra design, protocols or developments that I'm unaware of these can >>>>be mitigated/solved. >>>> >>>> Nacho >>>> >>>> >>>> -- >>>> Nacho (Ignacio) Solis >>>> Protocol Architect >>>> Principal Scientist >>>> Palo Alto Research Center (PARC) >>>> +1(650)812-4458 >>>> Ignacio.Solis at parc.com >>>> >>>> >>>> >>> _______________________________________________ >>> Ndn-interest mailing list >>> 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 > > >_______________________________________________ >Ndn-interest mailing list >Ndn-interest at lists.cs.ucla.edu >http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > > From christian.tschudin at unibas.ch Wed Jun 10 00:53:03 2015 From: christian.tschudin at unibas.ch (christian.tschudin at unibas.ch) Date: Wed, 10 Jun 2015 09:53:03 +0200 (CEST) Subject: [Ndn-interest] Data comes from another face? In-Reply-To: References: <4AC03A6244C3C34BB52A7EC60B799C4C03CC2964@m-pdc.sbu.ac.ir> <4AC03A6244C3C34BB52A7EC60B799C4C03CC2969@m-pdc.sbu.ac.ir> <4AC03A6244C3C34BB52A7EC60B799C4C03CC296B@m-pdc.sbu.ac.ir> Message-ID: Hi Nacho, this is basically a useful warning, but I think this is not true in general and fingerpointing in the wrong direction? A historically different perspective: In the original concept of cryptographically bound name+content, the lookup operation is idempotent and it does not matter through which face content is flowing back because the forwarder can validate and ground the packet if validation fails. Now CCNx1.0 has opted to move validation to the end points and then - sure - the attack angle shifts and acceptance rules have to be revised. In fact, on top of defining restrictions on what a router accepts, now you also have to trust the delivery chain: any malicious upstream node can do the blackholing and face bookkeeping acceptance rules alone will not solve this (new) problem. *) Regarding over-generalizing the warning: CCNx1.0 still overlaps with that original vision and could go beyond your safety warning perimeter. Data that is requested with a ContentObjectHash restriction is safe to accept from any face because the router can validate locally. I'm not aware if CCNx1.0 does that optimization or not (well, this is the general uphill battle of closed source ...) So I guess we have to look case-by-case, and for sure selectors and other non-idempotent operations like expiry-values, scope and hop limits are food for thought. Best, christian *) And linking this to the "adjacency thread" on the NDN interest list: I'm concerned that such adjacency protocols will re-introduced the secured circuits that the original CCN wanted to get rid of. Dont misunderstand me: I think that adjacency protocols are a good thing to have - the question is how far they want to reach and how much they open the arena for gaming the free flow of validated content, the "data acceptance rules discussion" just being the prelude. On Mon, 8 Jun 2015, Ignacio.Solis at parc.com wrote: > Hi folks. > > I wanted to bring up a couple of important points to this discussion that > have not been mentioned. ?Maybe people have already assimilated them so they > think they?re obvious, but just in case: > > 1- ?A node should not accept data packets over links/interfaces/faces over > which it did not forward an interest. ?This is a security risk. > > 2- NDN may have issues over multiple access links/interfaces/faces where not > all nodes can hear each other (non-infrastructure WiFi). > > Both of these are true in the basic case. It?s possible that with extra > design, protocols or developments that I?m unaware of these can be > mitigated/solved. > > Nacho > > > -- > Nacho (Ignacio) Solis > Protocol Architect > Principal Scientist > Palo Alto Research Center (PARC) > +1(650)812-4458 > Ignacio.Solis at parc.com > > On 6/8/15, 9:22 AM, "Muhammad Hosain Abdollahi Sabet" > wrote: > > Junxiao, > > Thank you for responding. > > >?Infrastructure WiFi is different: at MAC layer, all > communications go through the AP (access point). > We could take advantage of this property, and install an NDN > stack on the AP that aggregates Interests and caches Data. > > ?You mean we turn a L2 device (access point) into a wireless > router? > > ?? > ?>?the AP treats the WiFi link as both a multi-access link where > packets can be broadcast to all wireless clients, and one > point-to-point link to each wireless link. > > Does that make any difference? An ap treat a link as a > multiple-access or a point-to-point link. I mean in both cases, > the ap does the same thing(transmit one copy of a packet). The > only difference would be in L2 addressing?, right? Of course > there could be difference if using omnidirectional or > unidirectional antennas, which could be a big deal facing mobile > nodes. But that's out of computer networking scope. > > Thanks, > Sabet > > > -----Original Message----- > From: Junxiao Shi [mailto:shijunxiao at email.arizona.edu] > Sent: Thu 6/4/2015 2:19 AM > To: Muhammad Hosain Abdollahi Sabet > Cc:?ndn-interest at lists.cs.ucla.edu > Subject: RE: [Ndn-interest] Data comes from another face? > > Hi Sabet > > Ethernet repeater and UDP multicast group are two examples of > multi-access > links. > > Infrastructure WiFi is different: at MAC layer, all > communications go > through the AP (access point). > We could take advantage of this property, and install an NDN > stack on the > AP that aggregates Interests and caches Data. Under this design, > a wireless > client treats the WiFi link as a point-to-point link to the AP, > and the AP > treats the WiFi link as both a multi-access link where packets > can be > broadcast to all wireless clients, and one point-to-point link > to each > wireless link. > > Yours, Junxiao > On May 31, 2015 2:27 PM, "Muhammad Hosain Abdollahi Sabet" < > M.AbdollahiSabet at mail.sbu.ac.ir> wrote: > > >? Junxiao, > > > > So in wired nets it would be good old BUS or ethernet HUB > networks, which > > is rare these days unless we face lack of switching devices. > And in > > wireless nets, generally all of them are multiple-access link, > right? > > > > Actually It'very good to see you here by chance. Lately I've > been thinking > > on intelligent(self-learning) forwarding and I was counting > different > > situations which it would be useful for. Just a couple of > hours ago I saw > > your presentation about NDN in LANs at NDNComm and I was like > :| "Again, > > I've got here late!", though I had felt the need for such a > self-learning > > mechanism in producer mobility. I don't know if still there is > a room to > > contribute more in this. As far as I already saw, this NFD in > addition to a > > pointer to the chosen output face in PIT, which is available > right now, > > lacks some pointer to the chosen FIB entry itself. And of > course some > > measures are needed to check efficiency of self-learned chosen > faces after > > a while and see if another flooding is needed for choosing > possible better > > face. > > > > Thanks, > > Sabet. > > > > > > -----Original Message----- > > From: Junxiao Shi [mailto:shijunxiao at email.arizona.edu > > ] > > Sent: Sun 5/24/2015 1:48 AM > > To: Muhammad Hosain Abdollahi Sabet > > Cc:?ndn-interest at lists.cs.ucla.edu > > Subject: Re: [Ndn-interest] Data comes from another face? > > > > Hi Sabet > > > > As I understand you question is: > > In a network of NDN nodes where none of the nodes is using > broadcast > > strategy, if a node has not forwarded an Interest out of an > interface, is > > it possible for this node to receive a Data on this interface? > > > > The answer is YES. > > Think about a multi-access link with 3 hosts P Q R. > > > >??? 1. Q sends an Interest. P and R receive this Interest, > >??? 2. P replies with a Data. Q and R receive this Data. > > > > In this scenario, R has not forwarded an Interest to the > multi-access link, > > but receives a Data from the multi-access link. > > > > Yours, Junxiao > > > > On Wed, May 20, 2015 at 11:17 AM, Muhammad Hosain Abdollahi > Sabet < > >?M.AbdollahiSabet at mail.sbu.ac.ir> wrote: > > > > >? Hi, > > > We all know that data packets follow breadcrumbs which > interest packets > > > leave behind. And we expect to receive data packets from the > same face > > > which interests have already been forwarded to, according to > > correspondent > > > fib entries, right? So, when the second sentence won't > happen? I mean a > > > node receive a data packet matching a pit entry, from a face > that the > > > interest has not been forwarded to, according to the fib > entry. If a node > > > choose to broadcast for forwarding strategy, such a > situation happens. I > > > know that. But is there any other condition? > > > > > > Thanks, > > > Sabet > > > > > > > > > > From Marc.Mosko at parc.com Wed Jun 10 02:08:27 2015 From: Marc.Mosko at parc.com (Marc.Mosko at parc.com) Date: Wed, 10 Jun 2015 09:08:27 +0000 Subject: [Ndn-interest] Data comes from another face? In-Reply-To: References: <4AC03A6244C3C34BB52A7EC60B799C4C03CC2964@m-pdc.sbu.ac.ir> <4AC03A6244C3C34BB52A7EC60B799C4C03CC2969@m-pdc.sbu.ac.ir> <4AC03A6244C3C34BB52A7EC60B799C4C03CC296B@m-pdc.sbu.ac.ir> Message-ID: <73663F85-D48E-4CE6-BB50-35B1047BB534@parc.com> Christian, CCN 0.x and CCN 1.0 and NDN could verify a cryptographic signature at every hop, but in practice do not due to performance overhead. I do not believe this is a difference between ccnx and ndn. If a consumer asked for content by name and public key digest and each response (or at least a sufficient percentage) carried the public key [1], then each hop could verify it to within the collision probability of the sha256 digest of the public key. Likewise, if a consumer requests content by name + data hash, then each hop should verify the hash at each hop. We believe this is the best way to get trusted delivery. However, if one is doing path discovery (as the original poster said), then I don?t think one can do that with data hash names. So, this option is not available to the OP?s question. However, if the consumer is only using names or only using names + keyid requests, then in general there is a blackhole vulnerability because usually each hop is not verifying the cryptographic signature. I agree that saying ?secure an on-demand protocol? is kicking the can down the road, however there has been a history of work in this area along with reputation algorithms and other ways to cross-check that routing information advertised by one node is consistent with advertisements from other nodes (to within collusion limits). Marc [1] there are many ways to get the public keys in to the network and they have lots of trade offs. On Jun 10, 2015, at 8:53 AM, wrote: > Hi Nacho, > > this is basically a useful warning, but I think this is not true in general and fingerpointing in the wrong direction? A historically different perspective: > > In the original concept of cryptographically bound name+content, the lookup operation is idempotent and it does not matter through which face content is flowing back because the forwarder can validate and ground the packet if validation fails. > > Now CCNx1.0 has opted to move validation to the end points and then - sure - the attack angle shifts and acceptance rules have to be revised. In fact, on top of defining restrictions on what a router accepts, now you also have to trust the delivery chain: any malicious upstream node can do the blackholing and face bookkeeping acceptance rules alone will not solve this (new) problem. *) > > Regarding over-generalizing the warning: CCNx1.0 still overlaps with that original vision and could go beyond your safety warning perimeter. Data that is requested with a ContentObjectHash restriction is safe to accept from any face because the router can validate locally. I'm not aware if CCNx1.0 does that optimization or not (well, this is the general uphill battle of closed source ...) > > So I guess we have to look case-by-case, and for sure selectors and other non-idempotent operations like expiry-values, scope and hop limits are food for thought. > > Best, christian > > *) And linking this to the "adjacency thread" on the NDN interest list: I'm concerned that such adjacency protocols will re-introduced the secured circuits that the original CCN wanted to get rid of. > > Dont misunderstand me: I think that adjacency protocols are a good thing to have - the question is how far they want to reach and how much they open the arena for gaming the free flow of validated content, the "data acceptance rules discussion" just being the prelude. > > > On Mon, 8 Jun 2015, Ignacio.Solis at parc.com wrote: > >> Hi folks. >> I wanted to bring up a couple of important points to this discussion that >> have not been mentioned. Maybe people have already assimilated them so they >> think they?re obvious, but just in case: >> 1- A node should not accept data packets over links/interfaces/faces over >> which it did not forward an interest. This is a security risk. >> 2- NDN may have issues over multiple access links/interfaces/faces where not >> all nodes can hear each other (non-infrastructure WiFi). >> Both of these are true in the basic case. It?s possible that with extra >> design, protocols or developments that I?m unaware of these can be >> mitigated/solved. >> Nacho >> -- >> Nacho (Ignacio) Solis >> Protocol Architect >> Principal Scientist >> Palo Alto Research Center (PARC) >> +1(650)812-4458 >> Ignacio.Solis at parc.com >> On 6/8/15, 9:22 AM, "Muhammad Hosain Abdollahi Sabet" >> wrote: >> >> Junxiao, >> >> Thank you for responding. >> >> >?Infrastructure WiFi is different: at MAC layer, all >> communications go through the AP (access point). >> We could take advantage of this property, and install an NDN >> stack on the AP that aggregates Interests and caches Data. >> >> ?You mean we turn a L2 device (access point) into a wireless >> router? >> >> ? >> ?>?the AP treats the WiFi link as both a multi-access link where >> packets can be broadcast to all wireless clients, and one >> point-to-point link to each wireless link. >> >> Does that make any difference? An ap treat a link as a >> multiple-access or a point-to-point link. I mean in both cases, >> the ap does the same thing(transmit one copy of a packet). The >> only difference would be in L2 addressing?, right? Of course >> there could be difference if using omnidirectional or >> unidirectional antennas, which could be a big deal facing mobile >> nodes. But that's out of computer networking scope. >> >> Thanks, >> Sabet >> >> -----Original Message----- >> From: Junxiao Shi [mailto:shijunxiao at email.arizona.edu] >> Sent: Thu 6/4/2015 2:19 AM >> To: Muhammad Hosain Abdollahi Sabet >> Cc: ndn-interest at lists.cs.ucla.edu >> Subject: RE: [Ndn-interest] Data comes from another face? >> >> Hi Sabet >> >> Ethernet repeater and UDP multicast group are two examples of >> multi-access >> links. >> >> Infrastructure WiFi is different: at MAC layer, all >> communications go >> through the AP (access point). >> We could take advantage of this property, and install an NDN >> stack on the >> AP that aggregates Interests and caches Data. Under this design, >> a wireless >> client treats the WiFi link as a point-to-point link to the AP, >> and the AP >> treats the WiFi link as both a multi-access link where packets >> can be >> broadcast to all wireless clients, and one point-to-point link >> to each >> wireless link. >> >> Yours, Junxiao >> On May 31, 2015 2:27 PM, "Muhammad Hosain Abdollahi Sabet" < >> M.AbdollahiSabet at mail.sbu.ac.ir> wrote: >> >> > Junxiao, >> > >> > So in wired nets it would be good old BUS or ethernet HUB >> networks, which >> > is rare these days unless we face lack of switching devices. >> And in >> > wireless nets, generally all of them are multiple-access link, >> right? >> > >> > Actually It'very good to see you here by chance. Lately I've >> been thinking >> > on intelligent(self-learning) forwarding and I was counting >> different >> > situations which it would be useful for. Just a couple of >> hours ago I saw >> > your presentation about NDN in LANs at NDNComm and I was like >> :| "Again, >> > I've got here late!", though I had felt the need for such a >> self-learning >> > mechanism in producer mobility. I don't know if still there is >> a room to >> > contribute more in this. As far as I already saw, this NFD in >> addition to a >> > pointer to the chosen output face in PIT, which is available >> right now, >> > lacks some pointer to the chosen FIB entry itself. And of >> course some >> > measures are needed to check efficiency of self-learned chosen >> faces after >> > a while and see if another flooding is needed for choosing >> possible better >> > face. >> > >> > Thanks, >> > Sabet. >> > >> > >> > -----Original Message----- >> > From: Junxiao Shi [mailto:shijunxiao at email.arizona.edu >> > ] >> > Sent: Sun 5/24/2015 1:48 AM >> > To: Muhammad Hosain Abdollahi Sabet >> > Cc: ndn-interest at lists.cs.ucla.edu >> > Subject: Re: [Ndn-interest] Data comes from another face? >> > >> > Hi Sabet >> > >> > As I understand you question is: >> > In a network of NDN nodes where none of the nodes is using >> broadcast >> > strategy, if a node has not forwarded an Interest out of an >> interface, is >> > it possible for this node to receive a Data on this interface? >> > >> > The answer is YES. >> > Think about a multi-access link with 3 hosts P Q R. >> > >> > 1. Q sends an Interest. P and R receive this Interest, >> > 2. P replies with a Data. Q and R receive this Data. >> > >> > In this scenario, R has not forwarded an Interest to the >> multi-access link, >> > but receives a Data from the multi-access link. >> > >> > Yours, Junxiao >> > >> > On Wed, May 20, 2015 at 11:17 AM, Muhammad Hosain Abdollahi >> Sabet < >> > M.AbdollahiSabet at mail.sbu.ac.ir> wrote: >> > >> > > Hi, >> > > We all know that data packets follow breadcrumbs which >> interest packets >> > > leave behind. And we expect to receive data packets from the >> same face >> > > which interests have already been forwarded to, according to >> > correspondent >> > > fib entries, right? So, when the second sentence won't >> happen? I mean a >> > > node receive a data packet matching a pit entry, from a face >> that the >> > > interest has not been forwarded to, according to the fib >> entry. If a node >> > > choose to broadcast for forwarding strategy, such a >> situation happens. I >> > > know that. But is there any other condition? >> > > >> > > Thanks, >> > > Sabet >> > > >> > >> > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest From jefft0 at remap.UCLA.EDU Wed Jun 10 14:32:50 2015 From: jefft0 at remap.UCLA.EDU (Thompson, Jeff) Date: Wed, 10 Jun 2015 21:32:50 +0000 Subject: [Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256? In-Reply-To: <813C1DD1-0FA3-44B1-A3CC-DDDB0FB248DA@cs.ucla.edu> References: <1C839A4C-7C50-4847-8428-B8098983536C@parc.com> <49DE0EF2-012F-4996-80EC-FC52BCCF9BC6@parc.com> <884C8B3F-51D8-4B01-8EE6-EC9337F1FE00@parc.com> <3DB747F4-8EDE-40F6-AD6A-2024B62F02EB@cs.ucla.edu> <29E10C3B-EBE7-4A18-9B11-05D369114353@parc.com> <813C1DD1-0FA3-44B1-A3CC-DDDB0FB248DA@cs.ucla.edu> Message-ID: So, based of comments form Marc, Gene, Yingdi and others, it sounds like the spec should completely drop the description of KeyDigest based on the HMAC key. Any objections? - Jeff T From: Yingdi Yu > Date: Tuesday, June 9, 2015 at 13:44 To: Marc Mosko > Cc: Jeff Thompson >, "Ndn-interest at lists.cs.ucla.edu" > Subject: Re: [Ndn-interest] Describe the HMAC algorithm in SignatureHmacWithSha256? Hi Marc, I also do not think we should use digest of symmetric key. What I mean a "security property? here is a structured name of the symmetric key which allows one to determine the trust scope of the key. Neither digest nor first 4 byte of a digest can provide such information. Yingdi On Jun 9, 2015, at 1:05 PM, > > wrote: Yingdi, I do not think using the sha256 digest of a symmetric key is a security property (in the good sense). I think it is an unnecessary leaking of information. Symmetric keys must be rotated, based on the rate at which they are used and based on time. They are pair-wise associations. So, one only needs to keep track of keys for the given partner, such as a namespace or endpoint. And, one usually only needs to keep track of the last, current, and next keys to handle timing issues (or maybe just the current and next). So, there should not be a giant library of keys. Because the keys are rotated via a key exchange protocol they are easily identified by some index that can be cryptographically unrelated to the given key, preventing any possible information leakage. It may or may not be a sequential number, it depends on the key exchange protocol. Given that there are only a small number of keys that need to be maintained and that they are scoped by a namespace or endpoint, using the first 4-bytes of the key digest is highly likely to render uniqueness. But, like I said, I don?t think using a key digest is the right thing to do with symmetric keys. One needs a key exchange protocol because the next key should not be determined over a channel protected by the current key. That would break forward secrecy. Yes, if one has long-term statically configured keys one could identify them via their KeyDigest, but I think that is unwise. Both because they are static and because you possibly leak information in the KeyDigest. The issue of trust is separate from how a key is identified. The trust must be established by knowing the identity of the key exchange protocol peer, which is likely an RSA or EC public key. Trust decisions should never be made on the KeyDigest or KeyId until after one has verified the signature and then the remote identity is uniquely known based on which key verified the signature. So, even if there were a collision in KeyDigest or KeyID, one could still have strong authentication based on which of the colliding keys actually verified. Marc On Jun 9, 2015, at 7:16 PM, Yingdi Yu > wrote: On Jun 9, 2015, at 8:29 AM, Thompson, Jeff > wrote: > I think the purpose is to allow both ends to uniquely identify the key. Is there any particular reason of using the first 4 bytes of the digest? Using a short identifier (4 bytes) is to keep the packet short for low-power devices. Making a short identifier from the digest is an easy way to get a unique identifier instead of maintaining a separate list of sequential ID numbers. Does that answer your question? I do not think the first 4-bytes can provide a ?unique? identifier. If uniqueness is the major concern, we should use digest, given collision in sha256 has not been found yet. I did not quite understand what you mean by ?a separate list of sequential ID numbers?. My concern is about using digest or something related alone. Given HMAC is about authenticity, one might not be able to tell from a digest or even first 4 bytes that the key can be trusted for a particular data packet. We have to maintaining an additional mapping between the privilege of a key (which is usually the key name) and the key anyway. So using a digest does not save too much at the device side. For length of the key locator, given the packet size is already 1500-byte, I am not sure if it is a good tradeoff to sacrifice some good security property for just tens of bytes. Yingdi -------------- next part -------------- An HTML attachment was scrubbed... URL: From oran at cisco.com Fri Jun 12 08:57:44 2015 From: oran at cisco.com (Dave Oran (oran)) Date: Fri, 12 Jun 2015 15:57:44 +0000 Subject: [Ndn-interest] [Nfd-dev] review request: NDNLPv2 NACK, Fragmentation, LocalControlHeader In-Reply-To: <1B4B0A27-70B8-480A-A289-8CC2BCCED276@ucla.edu> References: <867622B3-56EA-4206-BFFB-FE8B1FF4D139@cisco.com> <1B4B0A27-70B8-480A-A289-8CC2BCCED276@ucla.edu> Message-ID: > On Jun 11, 2015, at 5:59 PM, Alex Afanasyev wrote: > > I think what we are talking here are two orthogonal issues. Well, we differ on that. I don?t think they are orthogonal at all. > The first priority here is to define NDNLP2 as a protocol to work as adaptation layer under an assumption that parameters of the link are known. > But they aren?t - the purpose of a link layer adaptation protocol is to?well?adapt to the link. In some cases in fact, you need to measure the link in order to know what the adaptation should be. While this is an ancient example that may not be applicable now, the general principle may apply: When we were deigning ISIS we discovered that some Ethernets would pass full link-sized packets and some would not (either due to physical layer errors or buggy repeaters). So, one could initialize the link and even exchange small packets, but real packets would get dropped. So, we made sure that the link initialization protocol padded the hello packets to the maximum size. (This had some amusing second-order consequences, such as what to put in the padding - different people were were funny in a number of creative ways). I?ll also note that failing to do this caused us to have many different adjacency-establishment protocols on top of the same kind of link, which in turn resulted in multiplicity of link management schemes, which even now is not cleaned up. At least now we have BFD, which has a way to unify these separate protocols under one umbrella. Maybe we should adopt BFD as the substrate to do the NDN-specific link adaptation features rather than starting form scratch? You can of course go too far in the other direction, for example with the PPP multi-layer link management stuff which got unnecessarily complicated. > If we get to the point that we need to negotiate NDNLP features on the link, then we would need to figure out how to do this negotiations, e.g., with some interests/data handshakes or some other way. I think we need to do this now - it?s to me a fundamental part of defining the link adaptation protocol(s). > > --- > Alex > >> On Jun 11, 2015, at 7:27 AM, Dave Oran (oran) wrote: >> >>> >>> On Jun 11, 2015, at 10:19 AM, Junxiao Shi wrote: >>> >>> Hi Dave >>> >>> Enabled features can be set at compile time, in the configuration file, or through management commands. >>> >>> Defaults for NFD are: >>> ? Ethernet multicast and UDP multicast: indexed fragmentation, network NACK >>> ? UDP unicast: indexed fragmentation, network NACK >>> ? TCP: network NACK >>> ? TCP local and UNIX socket: network NACK, local cache policy >>> ? turn on with management command: consumer controlled forwarding, incoming face indication >>> >>> There is no handshake because the receiver needs to know what NDNLPv2 features are enabled when processing the handshake packet. >>> However, since NDNLPv2 features can be controlled through management commands, it's possible to determine an initial set of enabled features at compile time or in the configuration file, and then change the features during runtime. This has a similar effect of handshake, because a management command can be sent from a remote node. >> How do you get the management command to the node if the link hasn?t come up with NDNLP2 running yet? >> How to you ?reset? the link if it gets desynchronized due to a bad management command setting? >> How do you do version checking? >> How does a receiver tell a transmitter what is the acceptable maximum MTU? >> >> I don?t have a problem using Interest/Data exchanges as the way to do the initialization handshake, but I don?t see how this works reasonably when starting from an unknown or incorrect state, and I don?t see how the link state machine is maintained. >> >>> For example, an end host can send a command "on my face, disable indexed fragmentation and enable B-E fragmentation" to the router, and the next packet will use the new fragmentation feature; but those packets transmitted prior to the command and received afterwards would be processed incorrectly and likely got dropped. >>> >>> Yours, Junxiao >>> >>> On Thu, Jun 11, 2015 at 4:32 AM, Dave Oran (oran) wrote: >>>> The protocol in charge is determined by the link, not determined by every packet. >>>> Before an NDNLPv2 packet is processed, the receiver already knows what features are enabled. >>> How? Not by hand on each end I hope? No initialization handshake? >> >> >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From Marc.Mosko at parc.com Fri Jun 12 13:26:03 2015 From: Marc.Mosko at parc.com (Marc.Mosko at parc.com) Date: Fri, 12 Jun 2015 20:26:03 +0000 Subject: [Ndn-interest] [Nfd-dev] review request: NDNLPv2 NACK, Fragmentation, LocalControlHeader In-Reply-To: References: <867622B3-56EA-4206-BFFB-FE8B1FF4D139@cisco.com> <1B4B0A27-70B8-480A-A289-8CC2BCCED276@ucla.edu> Message-ID: <625E28C1-02C8-49A0-BEF7-4D0519B30CE2@parc.com> Dave, I think BFD has some good features, but it does not itself have a discovery mechanism and must be configured. It also has some older authentication mechanisms. It also reserves point-to-multipoint for future use, which for router-to-router links is probably not a problem but if it is expected to run on every node on a LAN, I think the point-to-point nature of BFD would not scale well. BFD does not include a capabilities exchange, except for its own parameters, so we would need to do something beyond what it offers (without getting as far out there as ML-PPP). There is quite a bit of work on neighbor discovery and link maintenance, so I think we can put together something that would be ok to run on all nodes on a multiple access link without being overwhelming. Also, if one uses a route-reflector approach then one does not need to monitor a full mesh but only those in-use destinations. Marc On Jun 12, 2015, at 4:57 PM, Dave Oran (oran) wrote: > >> On Jun 11, 2015, at 5:59 PM, Alex Afanasyev wrote: >> >> I think what we are talking here are two orthogonal issues. > Well, we differ on that. I don?t think they are orthogonal at all. > >> The first priority here is to define NDNLP2 as a protocol to work as adaptation layer under an assumption that parameters of the link are known. >> > But they aren?t - the purpose of a link layer adaptation protocol is to?well?adapt to the link. In some cases in fact, you need to measure the link in order to know what the adaptation should be. While this is an ancient example that may not be applicable now, the general principle may apply: > > When we were deigning ISIS we discovered that some Ethernets would pass full link-sized packets and some would not (either due to physical layer errors or buggy repeaters). So, one could initialize the link and even exchange small packets, but real packets would get dropped. So, we made sure that the link initialization protocol padded the hello packets to the maximum size. (This had some amusing second-order consequences, such as what to put in the padding - different people were were funny in a number of creative ways). > > I?ll also note that failing to do this caused us to have many different adjacency-establishment protocols on top of the same kind of link, which in turn resulted in multiplicity of link management schemes, which even now is not cleaned up. At least now we have BFD, which has a way to unify these separate protocols under one umbrella. Maybe we should adopt BFD as the substrate to do the NDN-specific link adaptation features rather than starting form scratch? > > You can of course go too far in the other direction, for example with the PPP multi-layer link management stuff which got unnecessarily complicated. > >> If we get to the point that we need to negotiate NDNLP features on the link, then we would need to figure out how to do this negotiations, e.g., with some interests/data handshakes or some other way. > I think we need to do this now - it?s to me a fundamental part of defining the link adaptation protocol(s). > >> >> --- >> Alex >> >>> On Jun 11, 2015, at 7:27 AM, Dave Oran (oran) wrote: >>> >>>> >>>> On Jun 11, 2015, at 10:19 AM, Junxiao Shi wrote: >>>> >>>> Hi Dave >>>> >>>> Enabled features can be set at compile time, in the configuration file, or through management commands. >>>> >>>> Defaults for NFD are: >>>> ? Ethernet multicast and UDP multicast: indexed fragmentation, network NACK >>>> ? UDP unicast: indexed fragmentation, network NACK >>>> ? TCP: network NACK >>>> ? TCP local and UNIX socket: network NACK, local cache policy >>>> ? turn on with management command: consumer controlled forwarding, incoming face indication >>>> >>>> There is no handshake because the receiver needs to know what NDNLPv2 features are enabled when processing the handshake packet. >>>> However, since NDNLPv2 features can be controlled through management commands, it's possible to determine an initial set of enabled features at compile time or in the configuration file, and then change the features during runtime. This has a similar effect of handshake, because a management command can be sent from a remote node. >>> How do you get the management command to the node if the link hasn?t come up with NDNLP2 running yet? >>> How to you ?reset? the link if it gets desynchronized due to a bad management command setting? >>> How do you do version checking? >>> How does a receiver tell a transmitter what is the acceptable maximum MTU? >>> >>> I don?t have a problem using Interest/Data exchanges as the way to do the initialization handshake, but I don?t see how this works reasonably when starting from an unknown or incorrect state, and I don?t see how the link state machine is maintained. >>> >>>> For example, an end host can send a command "on my face, disable indexed fragmentation and enable B-E fragmentation" to the router, and the next packet will use the new fragmentation feature; but those packets transmitted prior to the command and received afterwards would be processed incorrectly and likely got dropped. >>>> >>>> Yours, Junxiao >>>> >>>> On Thu, Jun 11, 2015 at 4:32 AM, Dave Oran (oran) wrote: >>>>> The protocol in charge is determined by the link, not determined by every packet. >>>>> Before an NDNLPv2 packet is processed, the receiver already knows what features are enabled. >>>> How? Not by hand on each end I hope? No initialization handshake? >>> >>> >>> _______________________________________________ >>> Nfd-dev mailing list >>> Nfd-dev at lists.cs.ucla.edu >>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >> > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev From gordoni at gordoni.com Fri Jun 12 18:24:36 2015 From: gordoni at gordoni.com (Gordon Irlam) Date: Fri, 12 Jun 2015 18:24:36 -0700 Subject: [Ndn-interest] NDN Packet Spec Message-ID: Hi, I'm new here. I was reading the NDN Packet Specification 0.2-alpha-2 and had a few questions and comments. 1. The BNF for a Name allows an ImplictSha256DigestComponent to appear other than at the end of a name: Name ::= NAME-TYPE TLV-LENGTH NameComponent* NameComponent ::= GenericNameComponent | ImplicitSha256DigestComponent should probably make clear this is not actually allowed (or define the semantics): Name ::= NAME-TYPE TLV-LENGTH GenericNameComponent* ImplicitSha256DigestComponent? 2. Interest packet ChildSelector. "For example ... setting ChildSelector to be 1 will retrieve the rightmost version number (i.e., the latest version) and the leftmost segment number (i.e., the first segment)". I understand why the rightmost version number is returned, but am not sure based on the spec why the leftmost segment number (which is one past the version number) will be returned. 3. Data packet Content type. What network level semantics are associated with content type KEY; why isn't it just another BLOB? Can a LINK point to a KEY or just a BLOB? 4. Signature. Signature ::= SignatureInfo SignatureBits SignatureBits is undefined. Should be: Signature ::= SignatureInfo SignatureValue 5. Signature type DigestSha256. Cryptographic robustness isn't necessary for integrity protection, and comes at great cost. A quick test shows that Sha256 only runs at around 250Mbytes/sec on a current generation single core. Thanks in part to a special instruction on the same core, CRC32C runs at around 24Gbytes/sec. The use case for dispensing with provenance protection is likely to be the need for high performance. I would therefore suggest considering adding CRC32C to the spec, and possibly removing DigestSha256. thanks, gordon -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.afanasyev at ucla.edu Fri Jun 12 18:51:16 2015 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Fri, 12 Jun 2015 18:51:16 -0700 Subject: [Ndn-interest] NDN Packet Spec In-Reply-To: References: Message-ID: Hi Gordon, Thanks for your questions and I have some answers inline: > On Jun 12, 2015, at 6:24 PM, Gordon Irlam wrote: > > Hi, > > I'm new here. I was reading the NDN Packet Specification 0.2-alpha-2 and had a few questions and comments. > > 1. The BNF for a Name allows an ImplictSha256DigestComponent to appear other than at the end of a name: > > Name ::= NAME-TYPE TLV-LENGTH NameComponent* > NameComponent ::= GenericNameComponent | ImplicitSha256DigestComponent > > should probably make clear this is not actually allowed (or define the semantics): > > Name ::= NAME-TYPE TLV-LENGTH GenericNameComponent* ImplicitSha256DigestComponent? We had this definition initially, but decided that it is an unnecessary restriction. There are cases when you would want to put implicit digest component in the middle of the name (e.g., when you do interest-in-interest encapsulation). It these cases, the component will not be interpreted as such by the forwarder, but the specification (and therefore implementations) should allowed to define it as part of the name. > 2. Interest packet ChildSelector. "For example ... setting ChildSelector to be 1 will retrieve the rightmost version number (i.e., the latest version) and the leftmost segment number (i.e., the first segment)". I understand why the rightmost version number is returned, but am not sure based on the spec why the leftmost segment number (which is one past the version number) will be returned. I'm a little bit lost with your question. Can you explain a little bit more which part is confusing? > > 3. Data packet Content type. What network level semantics are associated with content type KEY; why isn't it just another BLOB? Can a LINK point to a KEY or just a BLOB? We haven't yet defined any specific network-level semantics with KEY type. However, given keys in NDN network may have more significant importance (i.e., multiple data packets could be signed with the same key), network-level can in theory prioritize data packets with KEY type. > 4. Signature. > > Signature ::= SignatureInfo SignatureBits > > SignatureBits is undefined. Should be: > > Signature ::= SignatureInfo SignatureValue Thanks for noticing. We'll fix this bug asap. > > 5. Signature type DigestSha256. Cryptographic robustness isn't necessary for integrity protection, and comes at great cost. A quick test shows that Sha256 only runs at around 250Mbytes/sec on a current generation single core. Thanks in part to a special instruction on the same core, CRC32C runs at around 24Gbytes/sec. The use case for dispensing with provenance protection is likely to be the need for high performance. I would therefore suggest considering adding CRC32C to the spec, and possibly removing DigestSha256. Thanks for the suggestion. We will discuss this issue during our next NFD call. -- Alex > > thanks, > gordon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From oran at cisco.com Sat Jun 13 05:42:53 2015 From: oran at cisco.com (Dave Oran (oran)) Date: Sat, 13 Jun 2015 12:42:53 +0000 Subject: [Ndn-interest] [Nfd-dev] review request: NDNLPv2 NACK, Fragmentation, LocalControlHeader In-Reply-To: <625E28C1-02C8-49A0-BEF7-4D0519B30CE2@parc.com> References: <867622B3-56EA-4206-BFFB-FE8B1FF4D139@cisco.com> <1B4B0A27-70B8-480A-A289-8CC2BCCED276@ucla.edu> <625E28C1-02C8-49A0-BEF7-4D0519B30CE2@parc.com> Message-ID: > On Jun 12, 2015, at 4:26 PM, Marc.Mosko at parc.com wrote: > > Dave, > > I think BFD has some good features, but it does not itself have a discovery mechanism and must be configured. It also has some older authentication mechanisms. It also reserves point-to-multipoint for future use, which for router-to-router links is probably not a problem but if it is expected to run on every node on a LAN, I think the point-to-point nature of BFD would not scale well. BFD does not include a capabilities exchange, except for its own parameters, so we would need to do something beyond what it offers (without getting as far out there as ML-PPP). > Good points. I withdraw the suggestion about BFD as a model for auto-configuration, although it is definitely worth looking at as a model for how to do an adjacency maintenance protocol. > There is quite a bit of work on neighbor discovery and link maintenance, so I think we can put together something that would be ok to run on all nodes on a multiple access link without being overwhelming. Also, if one uses a route-reflector approach then one does not need to monitor a full mesh but only those in-use destinations. > It would be really good to work together on this (i.e. the NDN and CCN communities). We?ve done some internal work at Cisco as well, but mostly as an experimentation harness in Python to try to get the semantics right before worrying about packet formats. Maybe we could collaborate on some talks at ICNRG in Prague to try to scope the work and prevent divergence in our designs? Seems this is an area where our other design differences won?t affect things much. DaveO. > Marc > > > On Jun 12, 2015, at 4:57 PM, Dave Oran (oran) wrote: > >> >>> On Jun 11, 2015, at 5:59 PM, Alex Afanasyev wrote: >>> >>> I think what we are talking here are two orthogonal issues. >> Well, we differ on that. I don?t think they are orthogonal at all. >> >>> The first priority here is to define NDNLP2 as a protocol to work as adaptation layer under an assumption that parameters of the link are known. >>> >> But they aren?t - the purpose of a link layer adaptation protocol is to?well?adapt to the link. In some cases in fact, you need to measure the link in order to know what the adaptation should be. While this is an ancient example that may not be applicable now, the general principle may apply: >> >> When we were deigning ISIS we discovered that some Ethernets would pass full link-sized packets and some would not (either due to physical layer errors or buggy repeaters). So, one could initialize the link and even exchange small packets, but real packets would get dropped. So, we made sure that the link initialization protocol padded the hello packets to the maximum size. (This had some amusing second-order consequences, such as what to put in the padding - different people were were funny in a number of creative ways). >> >> I?ll also note that failing to do this caused us to have many different adjacency-establishment protocols on top of the same kind of link, which in turn resulted in multiplicity of link management schemes, which even now is not cleaned up. At least now we have BFD, which has a way to unify these separate protocols under one umbrella. Maybe we should adopt BFD as the substrate to do the NDN-specific link adaptation features rather than starting form scratch? >> >> You can of course go too far in the other direction, for example with the PPP multi-layer link management stuff which got unnecessarily complicated. >> >>> If we get to the point that we need to negotiate NDNLP features on the link, then we would need to figure out how to do this negotiations, e.g., with some interests/data handshakes or some other way. >> I think we need to do this now - it?s to me a fundamental part of defining the link adaptation protocol(s). >> >>> >>> --- >>> Alex >>> >>>> On Jun 11, 2015, at 7:27 AM, Dave Oran (oran) wrote: >>>> >>>>> >>>>> On Jun 11, 2015, at 10:19 AM, Junxiao Shi wrote: >>>>> >>>>> Hi Dave >>>>> >>>>> Enabled features can be set at compile time, in the configuration file, or through management commands. >>>>> >>>>> Defaults for NFD are: >>>>> ? Ethernet multicast and UDP multicast: indexed fragmentation, network NACK >>>>> ? UDP unicast: indexed fragmentation, network NACK >>>>> ? TCP: network NACK >>>>> ? TCP local and UNIX socket: network NACK, local cache policy >>>>> ? turn on with management command: consumer controlled forwarding, incoming face indication >>>>> >>>>> There is no handshake because the receiver needs to know what NDNLPv2 features are enabled when processing the handshake packet. >>>>> However, since NDNLPv2 features can be controlled through management commands, it's possible to determine an initial set of enabled features at compile time or in the configuration file, and then change the features during runtime. This has a similar effect of handshake, because a management command can be sent from a remote node. >>>> How do you get the management command to the node if the link hasn?t come up with NDNLP2 running yet? >>>> How to you ?reset? the link if it gets desynchronized due to a bad management command setting? >>>> How do you do version checking? >>>> How does a receiver tell a transmitter what is the acceptable maximum MTU? >>>> >>>> I don?t have a problem using Interest/Data exchanges as the way to do the initialization handshake, but I don?t see how this works reasonably when starting from an unknown or incorrect state, and I don?t see how the link state machine is maintained. >>>> >>>>> For example, an end host can send a command "on my face, disable indexed fragmentation and enable B-E fragmentation" to the router, and the next packet will use the new fragmentation feature; but those packets transmitted prior to the command and received afterwards would be processed incorrectly and likely got dropped. >>>>> >>>>> Yours, Junxiao >>>>> >>>>> On Thu, Jun 11, 2015 at 4:32 AM, Dave Oran (oran) wrote: >>>>>> The protocol in charge is determined by the link, not determined by every packet. >>>>>> Before an NDNLPv2 packet is processed, the receiver already knows what features are enabled. >>>>> How? Not by hand on each end I hope? No initialization handshake? >>>> >>>> >>>> _______________________________________________ >>>> Nfd-dev mailing list >>>> Nfd-dev at lists.cs.ucla.edu >>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>> >> >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > From christian.tschudin at unibas.ch Sat Jun 13 09:21:15 2015 From: christian.tschudin at unibas.ch (christian.tschudin at unibas.ch) Date: Sat, 13 Jun 2015 18:21:15 +0200 (CEST) Subject: [Ndn-interest] [Nfd-dev] review request: NDNLPv2 NACK, Fragmentation, LocalControlHeader In-Reply-To: References: <867622B3-56EA-4206-BFFB-FE8B1FF4D139@cisco.com> <1B4B0A27-70B8-480A-A289-8CC2BCCED276@ucla.edu> <625E28C1-02C8-49A0-BEF7-4D0519B30CE2@parc.com> Message-ID: Hi Dave, we should extend the small workgroup we had at Dagstuhl on operational NW management. Iterating from then: NW mgmt is the killer app - if it's badly done you are dead. See you in Prague, christian On Sat, 13 Jun 2015, Dave Oran (oran) wrote: > >> On Jun 12, 2015, at 4:26 PM, Marc.Mosko at parc.com wrote: >> >> Dave, >> >> I think BFD has some good features, but it does not itself have a discovery mechanism and must be configured. It also has some older authentication mechanisms. It also reserves point-to-multipoint for future use, which for router-to-router links is probably not a problem but if it is expected to run on every node on a LAN, I think the point-to-point nature of BFD would not scale well. BFD does not include a capabilities exchange, except for its own parameters, so we would need to do something beyond what it offers (without getting as far out there as ML-PPP). >> > Good points. I withdraw the suggestion about BFD as a model for auto-configuration, although it is definitely worth looking at as a model for how to do an adjacency maintenance protocol. > >> There is quite a bit of work on neighbor discovery and link maintenance, so I think we can put together something that would be ok to run on all nodes on a multiple access link without being overwhelming. Also, if one uses a route-reflector approach then one does not need to monitor a full mesh but only those in-use destinations. >> > It would be really good to work together on this (i.e. the NDN and CCN communities). We?ve done some internal work at Cisco as well, but mostly as an experimentation harness in Python to try to get the semantics right before worrying about packet formats. > > Maybe we could collaborate on some talks at ICNRG in Prague to try to scope the work and prevent divergence in our designs? Seems this is an area where our other design differences won?t affect things much. > > DaveO. > >> Marc >> >> >> On Jun 12, 2015, at 4:57 PM, Dave Oran (oran) wrote: >> >>> >>>> On Jun 11, 2015, at 5:59 PM, Alex Afanasyev wrote: >>>> >>>> I think what we are talking here are two orthogonal issues. >>> Well, we differ on that. I don?t think they are orthogonal at all. >>> >>>> The first priority here is to define NDNLP2 as a protocol to work as adaptation layer under an assumption that parameters of the link are known. >>>> >>> But they aren?t - the purpose of a link layer adaptation protocol is to?well?adapt to the link. In some cases in fact, you need to measure the link in order to know what the adaptation should be. While this is an ancient example that may not be applicable now, the general principle may apply: >>> >>> When we were deigning ISIS we discovered that some Ethernets would pass full link-sized packets and some would not (either due to physical layer errors or buggy repeaters). So, one could initialize the link and even exchange small packets, but real packets would get dropped. So, we made sure that the link initialization protocol padded the hello packets to the maximum size. (This had some amusing second-order consequences, such as what to put in the padding - different people were were funny in a number of creative ways). >>> >>> I?ll also note that failing to do this caused us to have many different adjacency-establishment protocols on top of the same kind of link, which in turn resulted in multiplicity of link management schemes, which even now is not cleaned up. At least now we have BFD, which has a way to unify these separate protocols under one umbrella. Maybe we should adopt BFD as the substrate to do the NDN-specific link adaptation features rather than starting form scratch? >>> >>> You can of course go too far in the other direction, for example with the PPP multi-layer link management stuff which got unnecessarily complicated. >>> >>>> If we get to the point that we need to negotiate NDNLP features on the link, then we would need to figure out how to do this negotiations, e.g., with some interests/data handshakes or some other way. >>> I think we need to do this now - it?s to me a fundamental part of defining the link adaptation protocol(s). >>> >>>> >>>> --- >>>> Alex >>>> >>>>> On Jun 11, 2015, at 7:27 AM, Dave Oran (oran) wrote: >>>>> >>>>>> >>>>>> On Jun 11, 2015, at 10:19 AM, Junxiao Shi wrote: >>>>>> >>>>>> Hi Dave >>>>>> >>>>>> Enabled features can be set at compile time, in the configuration file, or through management commands. >>>>>> >>>>>> Defaults for NFD are: >>>>>> ? Ethernet multicast and UDP multicast: indexed fragmentation, network NACK >>>>>> ? UDP unicast: indexed fragmentation, network NACK >>>>>> ? TCP: network NACK >>>>>> ? TCP local and UNIX socket: network NACK, local cache policy >>>>>> ? turn on with management command: consumer controlled forwarding, incoming face indication >>>>>> >>>>>> There is no handshake because the receiver needs to know what NDNLPv2 features are enabled when processing the handshake packet. >>>>>> However, since NDNLPv2 features can be controlled through management commands, it's possible to determine an initial set of enabled features at compile time or in the configuration file, and then change the features during runtime. This has a similar effect of handshake, because a management command can be sent from a remote node. >>>>> How do you get the management command to the node if the link hasn?t come up with NDNLP2 running yet? >>>>> How to you ?reset? the link if it gets desynchronized due to a bad management command setting? >>>>> How do you do version checking? >>>>> How does a receiver tell a transmitter what is the acceptable maximum MTU? >>>>> >>>>> I don?t have a problem using Interest/Data exchanges as the way to do the initialization handshake, but I don?t see how this works reasonably when starting from an unknown or incorrect state, and I don?t see how the link state machine is maintained. >>>>> >>>>>> For example, an end host can send a command "on my face, disable indexed fragmentation and enable B-E fragmentation" to the router, and the next packet will use the new fragmentation feature; but those packets transmitted prior to the command and received afterwards would be processed incorrectly and likely got dropped. >>>>>> >>>>>> Yours, Junxiao >>>>>> >>>>>> On Thu, Jun 11, 2015 at 4:32 AM, Dave Oran (oran) wrote: >>>>>>> The protocol in charge is determined by the link, not determined by every packet. >>>>>>> Before an NDNLPv2 packet is processed, the receiver already knows what features are enabled. >>>>>> How? Not by hand on each end I hope? No initialization handshake? >>>>> >>>>> >>>>> _______________________________________________ >>>>> Nfd-dev mailing list >>>>> Nfd-dev at lists.cs.ucla.edu >>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>>> >>> >>> _______________________________________________ >>> Nfd-dev mailing list >>> Nfd-dev at lists.cs.ucla.edu >>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >> > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > From Ignacio.Solis at parc.com Sun Jun 14 23:22:14 2015 From: Ignacio.Solis at parc.com (Ignacio.Solis at parc.com) Date: Mon, 15 Jun 2015 06:22:14 +0000 Subject: [Ndn-interest] [Nfd-dev] review request: NDNLPv2 NACK, Fragmentation, LocalControlHeader In-Reply-To: References: <867622B3-56EA-4206-BFFB-FE8B1FF4D139@cisco.com> <1B4B0A27-70B8-480A-A289-8CC2BCCED276@ucla.edu> <625E28C1-02C8-49A0-BEF7-4D0519B30CE2@parc.com> Message-ID: We?re in favor of discussing this in Prague. Nacho -- Nacho (Ignacio) Solis Protocol Architect Principal Scientist Palo Alto Research Center (PARC) +1(650)812-4458 Ignacio.Solis at parc.com On 6/13/15, 5:42 AM, "Dave Oran (oran)" wrote: > >> On Jun 12, 2015, at 4:26 PM, Marc.Mosko at parc.com wrote: >> >> Dave, >> >> I think BFD has some good features, but it does not itself have a >>discovery mechanism and must be configured. It also has some older >>authentication mechanisms. It also reserves point-to-multipoint for >>future use, which for router-to-router links is probably not a problem >>but if it is expected to run on every node on a LAN, I think the >>point-to-point nature of BFD would not scale well. BFD does not include >>a capabilities exchange, except for its own parameters, so we would need >>to do something beyond what it offers (without getting as far out there >>as ML-PPP). >> >Good points. I withdraw the suggestion about BFD as a model for >auto-configuration, although it is definitely worth looking at as a model >for how to do an adjacency maintenance protocol. > >> There is quite a bit of work on neighbor discovery and link >>maintenance, so I think we can put together something that would be ok >>to run on all nodes on a multiple access link without being >>overwhelming. Also, if one uses a route-reflector approach then one >>does not need to monitor a full mesh but only those in-use destinations. >> >It would be really good to work together on this (i.e. the NDN and CCN >communities). We?ve done some internal work at Cisco as well, but mostly >as an experimentation harness in Python to try to get the semantics right >before worrying about packet formats. > >Maybe we could collaborate on some talks at ICNRG in Prague to try to >scope the work and prevent divergence in our designs? Seems this is an >area where our other design differences won?t affect things much. > >DaveO. > >> Marc >> >> >> On Jun 12, 2015, at 4:57 PM, Dave Oran (oran) wrote: >> >>> >>>> On Jun 11, 2015, at 5:59 PM, Alex Afanasyev >>>> wrote: >>>> >>>> I think what we are talking here are two orthogonal issues. >>> Well, we differ on that. I don?t think they are orthogonal at all. >>> >>>> The first priority here is to define NDNLP2 as a protocol to work as >>>>adaptation layer under an assumption that parameters of the link are >>>>known. >>>> >>> But they aren?t - the purpose of a link layer adaptation protocol is >>>to?well?adapt to the link. In some cases in fact, you need to measure >>>the link in order to know what the adaptation should be. While this is >>>an ancient example that may not be applicable now, the general >>>principle may apply: >>> >>> When we were deigning ISIS we discovered that some Ethernets would >>>pass full link-sized packets and some would not (either due to physical >>>layer errors or buggy repeaters). So, one could initialize the link and >>>even exchange small packets, but real packets would get dropped. So, we >>>made sure that the link initialization protocol padded the hello >>>packets to the maximum size. (This had some amusing second-order >>>consequences, such as what to put in the padding - different people >>>were were funny in a number of creative ways). >>> >>> I?ll also note that failing to do this caused us to have many >>>different adjacency-establishment protocols on top of the same kind of >>>link, which in turn resulted in multiplicity of link management >>>schemes, which even now is not cleaned up. At least now we have BFD, >>>which has a way to unify these separate protocols under one umbrella. >>>Maybe we should adopt BFD as the substrate to do the NDN-specific link >>>adaptation features rather than starting form scratch? >>> >>> You can of course go too far in the other direction, for example with >>>the PPP multi-layer link management stuff which got unnecessarily >>>complicated. >>> >>>> If we get to the point that we need to negotiate NDNLP features on >>>>the link, then we would need to figure out how to do this >>>>negotiations, e.g., with some interests/data handshakes or some other >>>>way. >>> I think we need to do this now - it?s to me a fundamental part of >>>defining the link adaptation protocol(s). >>> >>>> >>>> --- >>>> Alex >>>> >>>>> On Jun 11, 2015, at 7:27 AM, Dave Oran (oran) wrote: >>>>> >>>>>> >>>>>> On Jun 11, 2015, at 10:19 AM, Junxiao Shi >>>>>> wrote: >>>>>> >>>>>> Hi Dave >>>>>> >>>>>> Enabled features can be set at compile time, in the configuration >>>>>>file, or through management commands. >>>>>> >>>>>> Defaults for NFD are: >>>>>> ? Ethernet multicast and UDP multicast: indexed fragmentation, >>>>>>network NACK >>>>>> ? UDP unicast: indexed fragmentation, network NACK >>>>>> ? TCP: network NACK >>>>>> ? TCP local and UNIX socket: network NACK, local cache policy >>>>>> ? turn on with management command: consumer controlled >>>>>>forwarding, incoming face indication >>>>>> >>>>>> There is no handshake because the receiver needs to know what >>>>>>NDNLPv2 features are enabled when processing the handshake packet. >>>>>> However, since NDNLPv2 features can be controlled through >>>>>>management commands, it's possible to determine an initial set of >>>>>>enabled features at compile time or in the configuration file, and >>>>>>then change the features during runtime. This has a similar effect >>>>>>of handshake, because a management command can be sent from a remote >>>>>>node. >>>>> How do you get the management command to the node if the link hasn?t >>>>>come up with NDNLP2 running yet? >>>>> How to you ?reset? the link if it gets desynchronized due to a bad >>>>>management command setting? >>>>> How do you do version checking? >>>>> How does a receiver tell a transmitter what is the acceptable >>>>>maximum MTU? >>>>> >>>>> I don?t have a problem using Interest/Data exchanges as the way to >>>>>do the initialization handshake, but I don?t see how this works >>>>>reasonably when starting from an unknown or incorrect state, and I >>>>>don?t see how the link state machine is maintained. >>>>> >>>>>> For example, an end host can send a command "on my face, disable >>>>>>indexed fragmentation and enable B-E fragmentation" to the router, >>>>>>and the next packet will use the new fragmentation feature; but >>>>>>those packets transmitted prior to the command and received >>>>>>afterwards would be processed incorrectly and likely got dropped. >>>>>> >>>>>> Yours, Junxiao >>>>>> >>>>>> On Thu, Jun 11, 2015 at 4:32 AM, Dave Oran (oran) >>>>>>wrote: >>>>>>> The protocol in charge is determined by the link, not determined >>>>>>>by every packet. >>>>>>> Before an NDNLPv2 packet is processed, the receiver already knows >>>>>>>what features are enabled. >>>>>> How? Not by hand on each end I hope? No initialization handshake? >>>>> >>>>> >>>>> _______________________________________________ >>>>> Nfd-dev mailing list >>>>> Nfd-dev at lists.cs.ucla.edu >>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>>> >>> >>> _______________________________________________ >>> Nfd-dev mailing list >>> Nfd-dev at lists.cs.ucla.edu >>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >> > > >_______________________________________________ >Nfd-dev mailing list >Nfd-dev at lists.cs.ucla.edu >http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev From chaim.rieger at gmail.com Wed Jun 17 10:49:29 2015 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Wed, 17 Jun 2015 10:49:29 -0700 Subject: [Ndn-interest] Fresh install on Fedora having issues Message-ID: <5581B329.4080409@gmail.com> running the following on fresh fedora install git clone https://github.com/named-data/ndn-cxx.git ndn-cxx cd ndn-cxx/ ./waf configure --enable-shared --disable-static ./waf ./waf install ls -lasrth /usr/local/bin/ 4.0M -rwxr-xr-x. 1 root root 4.0M Jun 17 10:40 ndnsec Fresh install according to the time stamp. [crieger at localhost ndn-cxx] $ /usr/local/bin/ndnsec /usr/local/bin/ndnsec: error while loading shared libraries: libndn-cxx.so.0.3.2: cannot open shared object file: No such file or directory -- -- Chaim Rieger From susmit at cs.colostate.edu Wed Jun 17 10:56:22 2015 From: susmit at cs.colostate.edu (Susmit) Date: Wed, 17 Jun 2015 11:56:22 -0600 Subject: [Ndn-interest] Fresh install on Fedora having issues In-Reply-To: <5581B329.4080409@gmail.com> References: <5581B329.4080409@gmail.com> Message-ID: Hi Chaim, You need to set the LD_LIBRARY_PATH. You can simply do this: $ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH: Thanks. On Wed, Jun 17, 2015 at 11:49 AM, Chaim Rieger wrote: > running the following on fresh fedora install > git clone https://github.com/named-data/ndn-cxx.git ndn-cxx > cd ndn-cxx/ > ./waf configure --enable-shared --disable-static > ./waf > ./waf install > ls -lasrth /usr/local/bin/ > 4.0M -rwxr-xr-x. 1 root root 4.0M Jun 17 10:40 ndnsec > Fresh install according to the time stamp. > > [crieger at localhost ndn-cxx] $ /usr/local/bin/ndnsec > /usr/local/bin/ndnsec: error while loading shared libraries: > libndn-cxx.so.0.3.2: cannot open shared object file: No such file or > directory > > > > > -- > -- > Chaim Rieger > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest -- Regards, Susmit ==================================== http://www.cs.colostate.edu/~susmit ==================================== From shijunxiao at email.arizona.edu Wed Jun 17 10:59:11 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Wed, 17 Jun 2015 10:59:11 -0700 Subject: [Ndn-interest] Fresh install on Fedora having issues In-Reply-To: <5581B329.4080409@gmail.com> References: <5581B329.4080409@gmail.com> Message-ID: Hi Chaim Execute this right after ./waf install: sudo ldconfig See INSTALL.md for more details. Yours, Junxiao On Jun 17, 2015 10:50 AM, "Chaim Rieger" wrote: > running the following on fresh fedora install > git clone https://github.com/named-data/ndn-cxx.git ndn-cxx > cd ndn-cxx/ > ./waf configure --enable-shared --disable-static > ./waf > ./waf install > ls -lasrth /usr/local/bin/ > 4.0M -rwxr-xr-x. 1 root root 4.0M Jun 17 10:40 ndnsec > Fresh install according to the time stamp. > > [crieger at localhost ndn-cxx] $ /usr/local/bin/ndnsec > /usr/local/bin/ndnsec: error while loading shared libraries: > libndn-cxx.so.0.3.2: cannot open shared object file: No such file or > directory > > > > > -- > -- > Chaim Rieger > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chaim.rieger at gmail.com Wed Jun 17 11:06:37 2015 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Wed, 17 Jun 2015 11:06:37 -0700 Subject: [Ndn-interest] Fresh install on Fedora having issues In-Reply-To: References: <5581B329.4080409@gmail.com> Message-ID: <5581B72D.6060104@gmail.com> I did the ldcofig I think that ldconfig only takes care of /usr/local/lib not /usr/local/lib64 On 06/17/2015 10:59 AM, Junxiao Shi wrote: > > Hi Chaim > > Execute this right after ./waf install: > sudo ldconfig > > See INSTALL.md for more details. > > Yours, Junxiao > > On Jun 17, 2015 10:50 AM, "Chaim Rieger" > wrote: > > running the following on fresh fedora install > git clone https://github.com/named-data/ndn-cxx.git ndn-cxx > cd ndn-cxx/ > ./waf configure --enable-shared --disable-static > ./waf > ./waf install > ls -lasrth /usr/local/bin/ > 4.0M -rwxr-xr-x. 1 root root 4.0M Jun 17 10:40 ndnsec > Fresh install according to the time stamp. > > [crieger at localhost ndn-cxx] $ /usr/local/bin/ndnsec > /usr/local/bin/ndnsec: error while loading shared libraries: > libndn-cxx.so.0.3.2: cannot open shared object file: No such file > or directory > > > > > -- > -- > Chaim Rieger > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > -- -- Chaim Rieger -------------- next part -------------- An HTML attachment was scrubbed... URL: From chaim.rieger at gmail.com Wed Jun 17 11:18:02 2015 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Wed, 17 Jun 2015 11:18:02 -0700 Subject: [Ndn-interest] Fresh install on Fedora having issues In-Reply-To: References: <5581B329.4080409@gmail.com> Message-ID: <5581B9DA.2070401@gmail.com> I was correct, on Fedora 22 there seems to be a manual need to add /usr/local/lib64 to the ld lib path ndn-cxx installs properly as shared, and can be run without errors. On 06/17/2015 10:59 AM, Junxiao Shi wrote: > > Hi Chaim > > Execute this right after ./waf install: > sudo ldconfig > > See INSTALL.md for more details. > > Yours, Junxiao > > On Jun 17, 2015 10:50 AM, "Chaim Rieger" > wrote: > > running the following on fresh fedora install > git clone https://github.com/named-data/ndn-cxx.git ndn-cxx > cd ndn-cxx/ > ./waf configure --enable-shared --disable-static > ./waf > ./waf install > ls -lasrth /usr/local/bin/ > 4.0M -rwxr-xr-x. 1 root root 4.0M Jun 17 10:40 ndnsec > Fresh install according to the time stamp. > > [crieger at localhost ndn-cxx] $ /usr/local/bin/ndnsec > /usr/local/bin/ndnsec: error while loading shared libraries: > libndn-cxx.so.0.3.2: cannot open shared object file: No such file > or directory > > > > > -- > -- > Chaim Rieger > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > -- -- Chaim Rieger -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.afanasyev at ucla.edu Wed Jun 17 11:23:22 2015 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Wed, 17 Jun 2015 11:23:22 -0700 Subject: [Ndn-interest] Fresh install on Fedora having issues In-Reply-To: <5581B9DA.2070401@gmail.com> References: <5581B329.4080409@gmail.com> <5581B9DA.2070401@gmail.com> Message-ID: Yes. Fedora for some reason does not include /usr/local/* paths in the default library search paths. Just add a new entry into /etc/ld.conf.so.d and it would work. --- Alex > On Jun 17, 2015, at 11:18 AM, Chaim Rieger wrote: > > I was correct, on Fedora 22 there seems to be a manual need to add /usr/local/lib64 to the ld lib path > > ndn-cxx installs properly as shared, and can be run without errors. > > > > On 06/17/2015 10:59 AM, Junxiao Shi wrote: >> Hi Chaim >> >> Execute this right after ./waf install: >> sudo ldconfig >> >> See INSTALL.md for more details. >> >> Yours, Junxiao >> >> On Jun 17, 2015 10:50 AM, "Chaim Rieger" > wrote: >> running the following on fresh fedora install >> git clone https://github.com/named-data/ndn-cxx.git ndn-cxx >> cd ndn-cxx/ >> ./waf configure --enable-shared --disable-static >> ./waf >> ./waf install >> ls -lasrth /usr/local/bin/ >> 4.0M -rwxr-xr-x. 1 root root 4.0M Jun 17 10:40 ndnsec >> Fresh install according to the time stamp. >> >> [crieger at localhost ndn-cxx] $ /usr/local/bin/ndnsec >> /usr/local/bin/ndnsec: error while loading shared libraries: libndn-cxx.so.0.3.2: cannot open shared object file: No such file or directory >> >> >> >> >> -- >> -- >> Chaim Rieger >> >> _______________________________________________ >> Ndn-interest mailing list >> Ndn-interest at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > > -- > -- > Chaim Rieger > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From chaim.rieger at gmail.com Wed Jun 17 11:30:00 2015 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Wed, 17 Jun 2015 11:30:00 -0700 Subject: [Ndn-interest] Fresh install on Fedora having issues In-Reply-To: References: <5581B329.4080409@gmail.com> <5581B9DA.2070401@gmail.com> Message-ID: <5581BCA8.8090708@gmail.com> Can we add the following note for Fedora edit the file /etc/ld.so.conf.d/ndn-cxx.conf and add /usr/local/lib64 currently when running lddconfig only /usr/local/lib gets added On 06/17/2015 11:23 AM, Alex Afanasyev wrote: > Yes. Fedora for some reason does not include /usr/local/* paths in the > default library search paths. Just add a new entry into > /etc/ld.conf.so.d and it would work. > > --- > Alex > >> On Jun 17, 2015, at 11:18 AM, Chaim Rieger > > wrote: >> >> I was correct, on Fedora 22 there seems to be a manual need to add >> /usr/local/lib64 to the ld lib path >> >> ndn-cxx installs properly as shared, and can be run without errors. >> >> >> >> On 06/17/2015 10:59 AM, Junxiao Shi wrote: >>> >>> Hi Chaim >>> >>> Execute this right after ./waf install: >>> sudo ldconfig >>> >>> See INSTALL.md for more details. >>> >>> Yours, Junxiao >>> >>> On Jun 17, 2015 10:50 AM, "Chaim Rieger" >> > wrote: >>> >>> running the following on fresh fedora install >>> git clone https://github.com/named-data/ndn-cxx.git ndn-cxx >>> cd ndn-cxx/ >>> ./waf configure --enable-shared --disable-static >>> ./waf >>> ./waf install >>> ls -lasrth /usr/local/bin/ >>> 4.0M -rwxr-xr-x. 1 root root 4.0M Jun 17 10:40 ndnsec >>> Fresh install according to the time stamp. >>> >>> [crieger at localhost ndn-cxx] $ /usr/local/bin/ndnsec >>> /usr/local/bin/ndnsec: error while loading shared libraries: >>> libndn-cxx.so.0.3.2: cannot open shared object file: No such >>> file or directory >>> >>> >>> >>> >>> -- >>> -- >>> Chaim Rieger >>> >>> _______________________________________________ >>> Ndn-interest mailing list >>> Ndn-interest at lists.cs.ucla.edu >>> >>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest >>> >> >> -- >> -- >> Chaim Rieger >> _______________________________________________ >> Ndn-interest mailing list >> Ndn-interest at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > -- -- Chaim Rieger -------------- next part -------------- An HTML attachment was scrubbed... URL: From susmit at cs.colostate.edu Wed Jun 17 11:37:23 2015 From: susmit at cs.colostate.edu (Susmit) Date: Wed, 17 Jun 2015 12:37:23 -0600 Subject: [Ndn-interest] Fresh install on Fedora having issues In-Reply-To: References: <5581B329.4080409@gmail.com> <5581B9DA.2070401@gmail.com> Message-ID: Very distribution specific reason. "No Fedora package can contain files or directories under /usr/local"[1]. Since no packages use it, there is no reason to include it by default. [1] https://fedoraproject.org/wiki/Packaging:Guidelines#No_Files_or_Directories_under_.2Fsrv.2C_.2Fusr.2Flocal.2C_or_.2Fhome.2F.24USER On Wed, Jun 17, 2015 at 12:23 PM, Alex Afanasyev wrote: > Yes. Fedora for some reason does not include /usr/local/* paths in the > default library search paths. Just add a new entry into /etc/ld.conf.so.d > and it would work. > > --- > Alex > > On Jun 17, 2015, at 11:18 AM, Chaim Rieger wrote: > > I was correct, on Fedora 22 there seems to be a manual need to add > /usr/local/lib64 to the ld lib path > > ndn-cxx installs properly as shared, and can be run without errors. > > > > On 06/17/2015 10:59 AM, Junxiao Shi wrote: > > Hi Chaim > > Execute this right after ./waf install: > sudo ldconfig > > See INSTALL.md for more details. > > Yours, Junxiao > > On Jun 17, 2015 10:50 AM, "Chaim Rieger" wrote: >> >> running the following on fresh fedora install >> git clone https://github.com/named-data/ndn-cxx.git ndn-cxx >> cd ndn-cxx/ >> ./waf configure --enable-shared --disable-static >> ./waf >> ./waf install >> ls -lasrth /usr/local/bin/ >> 4.0M -rwxr-xr-x. 1 root root 4.0M Jun 17 10:40 ndnsec >> Fresh install according to the time stamp. >> >> [crieger at localhost ndn-cxx] $ /usr/local/bin/ndnsec >> /usr/local/bin/ndnsec: error while loading shared libraries: >> libndn-cxx.so.0.3.2: cannot open shared object file: No such file or >> directory >> >> >> >> >> -- >> -- >> Chaim Rieger >> >> _______________________________________________ >> Ndn-interest mailing list >> Ndn-interest at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > > > -- > -- > Chaim Rieger > > _______________________________________________ > Ndn-interest mailing list > 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 > -- Regards, Susmit ==================================== http://www.cs.colostate.edu/~susmit ==================================== From vslehman at memphis.EDU Tue Jun 30 15:38:32 2015 From: vslehman at memphis.EDU (Vince Lehman (vslehman)) Date: Tue, 30 Jun 2015 22:38:32 +0000 Subject: [Ndn-interest] NLSR 0.2.1 release Message-ID: <2D5B4736-89E0-43FE-8A9A-8AD6975C01BC@memphis.edu> Dear all, We are pleased to announce the release of version 0.2.1 of Named-data Link State Routing Protocol (NLSR). Detailed release notes can be found at: http://named-data.net/doc/NLSR/0.2.1/RELEASE-NOTES.html More information about NLSR, tutorials, installation and configuration guides, and other useful resources are available on the official webpage of NLSR: http://named-data.net/doc/NLSR/0.2.1/ * * * NLSR Developers and Contributors: Vince Lehman, A K M Mahmudul Hoque, Adam Alyyan, Syed Obaid Amin, Muktadir Chowdhury, Ashlesh Gawande, Minsheng Zhang, Lan Wang, Alexander Afanasyev, Spyridon Mastorakis, Jiewen Tan, Yingdi Yu, Lixia Zhang, Junxiao Shi, Beichuan Zhang -- Vince Lehman -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh at caida.org Tue Jun 30 18:08:49 2015 From: josh at caida.org (Josh Polterock) Date: Tue, 30 Jun 2015 18:08:49 -0700 Subject: [Ndn-interest] Named Data Networking (NDN) Project Monthly Newsletter for June 2015 Message-ID: <20150701010849.GB85255@caida.org> Named Data Networking (NDN) Project Monthly Newsletter for June 2015 The NDN project team compiles and publishes this newletter monthly to inform the community about recent activities, technical news, meetings, publications, presentations, code releases, and upcoming events. You can find these newsletters posted on the Named Data Networking Project blog. COMMUNITY OUTREACH * This month we welcome Juniper Networks to the NDN Consortium. * Save the date: We will host the NDN Community Meeting (NDNComm 2015) at the University of California at Los Angeles campus in the Little Theater, MacGowan Hall, UCLA on 28-29 September 2015. We plan to hold a Hackathon on Sunday 27 September preceeding the meeting. Registration is now open on the web at http://www.caida.org/workshops/ndn/1509/ TECHNICAL NEWS * The NDN Testbed added two new nodes at Verisign and the Korea Institute of Science and Technology Information to bring the total to 26 nodes. Currently we have nodes in 9 different countries. You can see the current status of the testbed at: http://www.arl.wustl.edu/~jdd/ndnstatus/ndn_prefix/tbs_ndnx.html and the real time bandwidth usage at: http://ndnmap.arl.wustl.edu/ * We announced the release of version 0.2.1 of Named Data Link State Routing Protocol (NLSR). Detailed release notes can be found at: http://named-data.net/doc/NLSR/0.2.1/RELEASE-NOTES.html More information about NLSR, tutorials, installation and configuration guides, and other useful resources are available on the official webpage of NLSR: http://named-data.net/doc/NLSR/0.2.1/ NDN PUBLICATIONS, PRESENTATIONS, and TECHNICAL REPORTS * In June, we posted the NDN Next Phase project annual report. This report catalogs a wide range of our accomplishments during the first year of the NDN Next Phase (NDN-NP) project. This phase of the project is environment-driven, in that we are focusing on deploying and evaluating the NDN architecture in two specific environments: building automation management systems and mobile health, together with a cluster of multimedia collaboration tools. http://named-data.net/project/annual-progress-summaries/2014-2015/ * NDN TR-30 Revision 2: Yingdi Yu, Alexander Afanasyev, David Clark, kc claffy, Van Jacobson, and Lixia Zhang. "Schematizing and Automating Trust in Named Data Networking" that describes how NDN automates data authentication into the narrow waist layer using trust schemas. http://named-data.net/publications/techreports/ndn-0030-2-trust-schema/ For more information about the Named Data Networking (NDN) Project please visit http://www.named-data.net/.