Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-6lo-ap-nd-15: (with DISCUSS and COMMENT)

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello again Benjamin:

About your discuss below we published -18 that has text from Rene that removes the uncertainty on compression.
Please have a look at https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-ap-nd-18 and let us know if the diffs correct the issue properly.

Many thanks again

Pascal

> -----Original Message-----
> From: Benjamin Kaduk via Datatracker <[e-mail]>
> Sent: samedi 1 février 2020 00:19
> To: The IESG <[e-mail]>
> Cc: [e-mail]; Shwetha Bhandari (shwethab)
> <[e-mail]>; [e-mail]; Shwetha Bhandari (shwethab)
> <[e-mail]>; [e-mail]
> Subject: Benjamin Kaduk's Discuss on draft-ietf-6lo-ap-nd-15: (with DISCUSS
> and COMMENT)
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-6lo-ap-nd-15: Discuss
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-6lo-ap-nd/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> The CIPO description specifies that a 5-bit Reserved1 field and a 13-bit Public
> Key Length field are combined to fit into a 16 (not 18)-bit space.
> (The Figure shows the Public Key Length field as 11 bits.)
> 
> Why do we need to allow ambiguity/flexibility as to the point representation
> within a given Crypto-Type value (as opposed to fixing the representation as a
> parameter of the Crypto-Type)?  Alternately, what does "(un)compressed"
> mean, as it's not really clarified directly?  Furthermore, Table 2 lists an
> "(un)compressed" representation for type 0 (over P-256), but RFC 7518 notes
> that the compressed representation is not supported for P-256 (Section
> 6.2.1.1).  I also am not finding the needed codepoints registered in the JOSE
> registries to use ECDSA25519 (crypto-type 2) -- do we need to register
> anything there?
> 
> Per my comment on Section 4.4, there may be some implicit
> expectation/requirement of 128+-bit ROVRs for AP-ND, but I didn't find where
> such a requirement was stated.
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks for this well-written document!  It will be good to see this stuff getting
> deployed.
> 
> What's the risk of DoS via (short) address exhaustion in terms of 6LBR
> resources (as distinct from 6LR resources mentioned at the end of Section 7.1)?
> 
> Section 1
> 
>    In this specification, a 6LN generates a cryptographic ID (Crypto-ID)
>    and places it in the ROVR field during the registration of one (or
>    more) of its addresses with the 6LR(s).  Proof of ownership of the
>    Crypto-ID is passed with the first registration exchange to a new
>    6LR, and enforced at the 6LR.  The 6LR validates ownership of the
>    cryptographic ID before it creates any new registration state, or
>    changes existing information.
> 
> I'll read on and see, but how much trust does this imply that we require of all
> 6LRs (as opposed to the 6LBR, which is kind of required to be pretty trusted)?
> [ed.: basically complete trust is required]
> 
>    The protected address registration protocol proposed in this document
>    enables Source Address Validation (SAVI) [RFC7039].  This ensures
>    that only the actual owner uses a registered address in the IPv6
>    source address field.  A 6LN can only use a 6LR for forwarding
>    packets only if it has previously registered the address used in the
>    source field of the IPv6 packet.
> 
> nit: this last sentence is written as if we not only enable, but also require, SAVI.
> 
>    The 6lo adaptation layer in [RFC4944] and [RFC6282] requires a device
>    to form its IPv6 addresses based on its Layer-2 address to enable a
>    better compression.  This is incompatible with Secure Neighbor
>    Discovery (SeND) [RFC3971] and Cryptographically Generated Addresses
>    (CGAs) [RFC3972], since they derive the Interface ID (IID) in IPv6
>    addresses with cryptographic keys.
> 
> Are we going to have some further discussion of the scope of that loss of
> functionality and/or alternative mechanisms to achieve those goals, or is this
> statement just intended to note the incompatibility?
> 
> Section 3
> 
>    The proof requires the support of Elliptic Curve Cryptography (ECC)
>    and that of a hash function as detailed in Section 6.2.  To enable
>    the verification of the proof, the registering node needs to supply
>    certain parameters including a Nonce and a signature that will
>    demonstrate that the node has the private-key corresponding to the
>    public-key used to build the Crypto-ID.
> 
> nit: the proof itself may only indirectly involve a hash, since we use non-
> prehash Ed25519 (but the hash function is still needed to generate the Crypto-
> ID itself).
> 
> nit(?): I think we tend to see "possesses the private key" more often than "has
> the private-key", for parallelism with the "proof of possession" term of art.
> 
>    The elliptic curves and the hash functions that can be used with this
>    specification are listed in Table 2 in Section 8.3.  The signature
>    scheme that specifies which combination is used is signaled by a
> 
> nit: this could be misread as saying that the Table is authoritative, not the
> registry.
> 
> Section 4.1
> 
>    The Crypto-ID is derived from the public key and a modifier as
>    follows:
> 
>    1.  The hash function indicated by the Crypto-Type is applied to the
>        CIPO.  Note that all the reserved and padding bits MUST be set to
>        zero.
>    2.  The leftmost bits of the resulting hash, up to the size of the
>        ROVR field, are used as the Crypto-ID.
> 
> This construction seems to allow for some malleability, in that an attacker who
> observes a given Crypto-ID and CIPO could produce a related, valid, Crypto-ID
> by reducing the ROVR length and truncating what was received.  I haven't
> attempted to explore what (if any) potential consequences there are of such
> malleability, and would like to know if anyone else has already done so.  It
> looks like the NDPSO construction includes the length of the Crypto-ID, so it
> would be hard for an attacker to do much with such a truncated Crypto-ID, but
> attacks only get better...
> 
> Section 4.2
> 
> nit: I confess I'm missing what compels us to produce a de novo definition of
> the "Status" field (and Length field) as opposed to deferring to the RFC
> 8505 definition, as we do for most of the other fields.
> 
> Section 4.3
> 
>    Crypto-Type:  8-bit unsigned integer.  The type of cryptographic
>       algorithm used in calculation Crypto-ID (see Table 2 in
>       Section 8.3).  Although the different signature schemes target
>       similar cryptographic strength, they rely on different curves,
>       hash functions, signature algorithms, and/or representation
>       conventions.
> 
> While the currently-defined signature schemes target similar cryptographic
> strength, do we need to imply that all future ones will also target a similar
> strength (especially since Section 8.3 admits the possibility of "better
> security")?
> 
>    Modifier:  8-bit unsigned integer.  Set to an arbitrary value by the
>       creator of the Crypto-ID.  The role of the modifier is to enable
>       the formation of multiple Crypto-IDs from a same key pair, which
>       reduces the traceability and thus improves the privacy of a
>       constrained node that could not maintain many key-pairs.
> 
> It may be worth digging in a little further to the threat model being addressed
> here -- while I laud the ability to have multiple Crypto-IDs from a single keypair,
> it seems that the tracking-prevention this affords implies an attacker who can
> observe Crypto-IDs, most likely at multiple points in the network.  Are Crypto-
> IDs used for anything other than EAROs?  I don't have a great sense for how
> likely it is that an attacker in position to observe (a subset of) EAROs would not
> also be in a position to observe at least one associated CIPO, which includes all
> the information needed to generate the Crypto-ID other than the Modifier.
> With only an 8-bit Modifier space, brute-forcing the other possible Crypto-IDs
> for that keypair is not terribly strenuous, whereas allowing for a (potentially
> variable length?) larger Modifier, say 64 bits, would substantially increase the
> work-factor needed to predict (and store!) other Crypto-IDs that might be used
> for this keypair.  Given that the CIPO already carries the public key itself, it's
> not entirely clear how space-constrained we are so as to limit this to just
> 8 bits of modifier.
> 
>    Padding:  A variable-length field completing the Public Key field to
>       align to the next 8-bytes boundary.
> 
> (MUST be set to zero by sender and ignored by receiver, as well?)
> 
>    The implementation of multiple hash functions in a constrained
>    devices may consume excessive amounts of program memory.
> 
> But multiple signature algorithm implementations will not?
> 
> Section 4.4
> 
> Is there some more discussion to have about how NDPSO includes only a
> specific fixed set of information under the signature but RSAO signs all options
> that appear prior to it in the message?
> 
> nit: style suggests parallelism between the Section 4.3 and 4.4 introductory
> remarks (e.g., "this specification defines the NDP Signature Option (NDPSO)").
> 
>    As opposed to the RSA Signature Option (RSAO) defined in section 5.2.
>    of SEND [RFC3971], the NDPSO does not have a key hash field.  The
>    hash that can be used as index is the 128 leftmost bits of the ROVR
>    field in the EARO.
> 
> nit: this last sentence perhaps leaves more context implicit than the reader
> might like; I suggest "Instead, the leftmost 128 bits of the ROVR field in the
> sibling EARO are used to lookup the key used for signature verification, [left-
> padded with zeros if needed]".  (I added the part in square brackets because
> I'm not sure that anything guarantees the ROVR will actually contain
> 128 bits -- when AP-ND is not in use its typically just 64 bits, right?)
> 
>    Pad Length:  8-bit unsigned integer.  The length of the Padding
>       field.
> 
> (In octets?)
> 
>    Padding:  A variable-length field making the option length a multiple
>       of 8, containing as many octets as specified in the Pad Length
>       field.  Typically there is no need of a padding and the field is
>       NULL.
> 
> Just to check: nothing requires the use of minimal-length padding to achieve
> the required alignment, and padding of 200+ bytes is permitted by the spec,
> albeit silly?
> 
> Section 6
> 
>    This specification enables the 6LR to verify the ownership of the
>    binding at any time assuming that the "C" flag is set.  The
>    verification prevents other nodes from stealing the address and
>    trying to attract traffic for that address or use it as their source
>    address.
> 
> nit: I think that the verification cannot be done unilaterally by the 6LR, so
> maybe "enables the 6LR to challenge the node to verify its ownership of the
> binding at any time" is better.
> 
>    A node may use multiple IPv6 addresses at the same time.  The node
>    MAY use the same Crypto-ID, to prove the ownership of multiple IPv6
>    addresses.  The separation of the address and the cryptographic
> 
> nit: no comma
> 
>    material avoids the constrained device to compute multiple keys for
> 
> nit: "avoids the need for"
> 
>    multiple addresses.  The registration process allows the node to use
>    the same Crypto-ID for all of its addresses.
> 
> nit(?): We could potentially mention again the ability to use different Crypto-
> IDs with a single keypair, though there's not any clear need to do so.
> 
> Section 6.1
> 
> Mostly just for my own elucidation, where is it first specified to put the address
> being registered in the Target Address field of the NS message?
> 
>    detrimental to the battery lifetime.  Alternatively, the device may
>    use an always-incrementing value saved in the same stable storage as
>    the key, so they are lost together, and starting at a best effort
>    random value, either as Nonce value or as a component to its
>    computation.
> 
> nit: "as the Nonce value".
> 
>    and the NDPSO containing the signature.  The information associated
>    to a Crypto-ID stored by the 6LR on the first NS exchange where it
>    appears.  The 6LR MUST store the CIPO parameters associated with the
> 
> nit: I think there's a verb missing in this sentence ("MUST be"?)
> 
>         |------- NS with EARO, CIPO, NonceLN and NDPSO -------->|
> 
> (This still includes the Crypto-ID, even if there's not room in the figure to
> explicition indicate that, right?)
> 
>    *  Upon the first exchange with a 6LR, a 6LN will be challenged to
>       prove ownership of the Crypto-ID and the Target Address being
> 
> How is the "first exchange" tracked?  Just whether the 6LR knows about the
> registered IPv6 address, or the L2 address, or something else?  In particular, if a
> 6LR has cached an IP address/ROVR binding, and an attacker tries to join that
> 6LR with that address/ROVR, what controls whether the 6LR will challenge the
> attacker's 6LN?  Is it purely at the 6LR's discretion?
> 
>    *  The challenge is triggered when the registration for a Source
>       Link-Layer Address is not verifiable either at the 6LR or the
>       6LBR.  In the latter case, the 6LBR returns a status of
>       "Validation Requested" in the DAR/DAC exchange, which is echoed by
>       the 6LR in the NA (EARO) back to the registering node.  The
>       challenge MUST NOT alter a valid registration in the 6LR or the
>       6LBR.
> 
> nit(?): the previous bullet describes a case where the 6LR MUST issue a
> challenge; my understanding is that this bullet describes an additional way in
> which challenges can occur (i.e., when the 6LBR doesn't know about the
> address registration either).  Stylistically, it might be more clear to reword this
> as being an "additional case" on top of the previous one, as opposed to the
> current wording which tries to be very general about when a challenge can
> happen, which is neither a parallel construction to the previous bullet nor
> particularly clear about what new information is being conveyed by this bullet.
> 
>    *  In order to validate the ownership, the 6LR performs the same
>       steps as the 6LN and rebuilds the Crypto-ID based on the
>       parameters in the CIPO.  If the rebuilt Crypto-ID matches the
>       ROVR, the 6LN also verifies the signature contained in the NDPSO
>       option.  If at that point the signature in the NDPSO option can be
>       verified, then the validation succeeds.  Otherwise the validation
>       fails.
> 
> I worry a little bit that we haven't fully specified the entire list of steps the 6LR
> takes to follow the cryptographic chain and validate that the 6LN holds the key
> in question and registers the address in question to the Crypto-ID in question.  I
> don't have a specific thing in mind that the 6LR might forget, but if we
> explicitly state what things are bound to what other things, the 6LR is less likely
> to make a security-relevant mistake.
> 
> Section 6.2
> 
> Might we want to include the Modifier or the Crypto-ID itself in the signed
> data, in addition to the public key, to avoid any potential misbinding?
> 
>    2.  JWK-encoded public key
> 
> [just to check: JWK-encoding means that we have an injective map and aren't
> subject to some sort of extension attack?  Not that such a thing would be easy
> to pull off, with a strict registry of Crypto-Types, of course]
> 
>    6.  The length of the ROVR field in the NS message containing the
>        Crypto-ID that was sent.
> 
> nit: is this really the NS "that was sent" as opposed to the NS under
> construction that contains the NDPSO?  (This is related to my question up in
> Section 6.1.)  Tying the initial NS to the followup one requires more state on
> the 6LR (though the 6LR probably already had to keep state for the Nonce) and
> makes some of the verification steps a bit tougher to implement correctly.
> 
>    7.  1-byte (in network byte order) Crypto-Type value sent in the CIPO
>        option.
> 
> nit: Is there any byte order with distinct representation from network byte
> order, for a 1-byte quantity?  ;)
> 
>    *  Depending on the Crypto-Type, apply the hash function on this
>       concatenation.
> 
> nit: is this clearer as "Apply the hash function (if any) specified by the Crypto-
> Type to the concatenated data"?
> 
>    *  Depending on the Crypto-Type, sign the hash output with ECDSA (if
>       curve P-256 is used) or sign the hash with EdDSA (if curve Ed25519
>       (PureEdDSA)).
> 
> nit: this text is not very consistent with the idea of an extensible registry of
> Crypto-Types; similar "apply the signature algorithm specified by the Crypto-
> Type" language to what I suggested above may be appropriate.
> 
>    The 6LR on receiving the NDPSO and CIPO options first regenerates the
>    Crypto-ID based on the CIPO option to make sure that the leftmost
>    bits up to the size of the ROVR match.  If and only if the check is
> 
> In the vein of my previous questions about where the Crypto-ID appears and
> truncation/malleability, this text seems to leave some room for confusion
> about how many bits of output are being compared, and compared to what.
> 
>    *  Depending on the Crypto-Type indicated by the (6LN) in the CIPO,
>       apply the hash function on this concatenation.
> 
> [similar comment as above]
> 
>    *  Verify the signature with the public-key received and the locally
>       computed values.  If the verification succeeds, the 6LR and 6LBR
>       add the state information about the Crypto-ID, public-key and
>       Target Address being registered to their database.
> 
> This might be a place to reiterate the FCFS nature of address registration,
> though it's hardly necessary.
> 
> Section 6.3
> 
>    In a multihop 6LoWPAN, a 6LBR sends RAs with prefixes downstream and
>    the 6LR receives and relays them to the nodes. 6LR and 6LBR
>    communicate using ICMPv6 Duplicate Address Request (DAR) and
>    Duplicate Address Confirmation (DAC) messages.  The DAR and DAC use
>    the same message format as NS and NA, but have different ICMPv6 type
>    values.
> 
>    In AP-ND we extend DAR/DAC messages to carry cryptographically
>    generated ROVR.  In a multihop 6LoWPAN, the node exchanges the
>    messages shown in Figure 6.  The 6LBR must identify who owns an
>    address (EUI-64) to defend it, if there is an attacker on another
>    6LR.
> 
> This description feels a little vague to me -- I'm interested in knowing how the
> 6LBR gains confidence that a proof-of-possession was provided to the 6LR, and
> how the ROVR gets validated at 6LBR and 6LR when the 6LN in question moves
> to a new 6LR.  What information remains local to (each) 6LR and what is
> communicated between 6LR and 6LBR?
> This also relates to the "how trusted are 6LRs?" question I mentioned earlier.
> 
> Section 7
> 
> It might be appropriate to talk about how the NonceLR and NonceLN combine
> to ensure contributory behavior from both 6LR and 6LN, and that each protects
> against a different type of replay attack.
> 
> Section 7.1
> 
>    Duplicate Address Detection DoS Attack:  Inside the LLN, Duplicate
>       Addresses are sorted out using the ROVR, which differentiates it
>       from a movement.  DAD coming from the backbone are not forwarded
>       over the LLN, which provides some protection against DoS attacks
>       inside the resource-constrained part of the network.  Over the
>       backbone, the EARO option is present in NS/NA messages.  This
>       protects against misinterpreting a movement for a duplication, and
>       enables the backbone routers to determine which one has the
>       freshest registration and is thus the best candidate to validate
>       the registration for the device attached to it.  But this
>       specification does not guarantee that the backbone router claiming
>       an address over the backbone is not an attacker.
> 
> Where do we specify the behavior of the 6LBR to reject EAROs when the 6LBR
> is not the one with the freshest registration?  Or do I misunderstand the
> discussion of "freshest registration"?
> 
>    Replay Attacks  Using Nonces (NonceLR and NonceLN) generated by both
>       the 6LR and 6LN provides an efficient protection against replay
>       attacks of challenge response flow.  The quality of the protection
>       still depends on the quality of the Nonce, in particular of a
>       random generator if they are computed that way.
> 
> It's probably worth noting explicitly that we do not require unpredictable
> nonces, just non-repeating ones.
> 
>    Neighbor Discovery DoS Attack:  A rogue node that managed to access
>       the L2 network may form many addresses and register them using AP-
>       ND.  The perimeter of the attack is all the 6LRs in range of the
>       attacker.  The 6LR MUST protect itself against overflows and
>       reject excessive registration with a status 2 "Neighbor Cache
>       Full".  This effectively blocks another (honest) 6LN from
>       registering to the same 6LR, but the 6LN may register to other
>       6LRs that are in its range but not in that of the rogue.
> 
> Are there L2 technologies where L2 media keys are tied to L2 address, so a
> rogue node might be rate-limited or given a quota based on L2 address?
> 
> Section 7.2
> 
>    address.  This specification frees the device to form its addresses
>    in any fashion, thereby enabling not only 6LoWPAN compression which
>    derives IPv6 addresses from Layer-2 addresses but also privacy
>    addresses.
> 
> We noted in Section 1 that the 6lo adaptation layer requires use of L2-address-
> based IPv6 address selection, so it's not clear how it would be valid to use
> privacy addresses with this specification.
> 
> Section 7.3
> 
> We seem to be assuming for these calculations/discussion that the hash used
> for calculating the Crypto-ID is a well-behaved cryptographic hash and thus
> that random collisions are the only ones possible.  It would be worth
> mentioning that weaknesses in the hashes associated with a given Crypto-Type
> could allow attackers to make more targetted collision attempts.
> 
>    The formula for calculating the probability of a collision is 1 -
>    e^{-k^2/(2n)} where n is the maximum population size (2^64 here,
>    1.84E19) and K is the actual population (number of nodes).  If the
> 
> nit: minuscule vs. majuscule 'k'/'K'
> 
> Section 7.4
> 
>    The signature schemes referenced in this specification comply with
>    NIST [FIPS186-4] or Crypto Forum Research Group (CFRG) standards
>    [RFC8032] and offer strong algorithmic security at roughly 128-bit
>    security level.  These signature schemes use elliptic curves that
> 
> Do we want to make any forward-looking statement about the expected
> strength of future-defined Crypto-Types?  ("No" is a fine answer...)
> 
> Section 7.5
> 
> The text here is more about cross-algorithm attacks than cross-protocol ones.
> It would be great to see some text about cross-protocol attacks added, too
> (e.g., prohibiting use of the keypair for anything other than AP-ND).
> 
> Section 7.6
> 
>    This specification distributes the challenge and its validation at
>    the edge of the network, between the 6LN and its 6LR.  The central
>    6LBR is offloaded, which avoids DOS attacks targeted at that central
>    entity.  This also saves back and forth exchanges across a
> 
> nit: "the central 6LBR is offloaded" reads very oddly, as the offloading is of
> work from the 6LBR, but the 6LBR itself remains in place.
> 
>    The downside is that the 6LBR needs to trust the 6LR for performing
>    the checking adequately, and the communication between the 6LR and
>    the 6LBR must be protected to avoid tempering with the result of the
>    test.
> 
> I'd prefer to see some more details about the nature of the required protection
> for 6LR/6LBR communications.
> 
>    If a 6LR is compromised, it may pretend that it owns any address and
>    defeat the protection.  It may also admit any rogue and let it take
>    ownership of any address in the network, provided that the 6LR knows
>    the ROVR field used by the real owner of the address.
> 
> nit: this language could probably be tightened up to be more precise about the
> hazards.
> 
> Section 8.3
> 
>    New Crypto-Type values providing similar or better security (with
>    less code) may be defined in the future.
> 
> I'm not sure what purpose the "with less code" requirement serves.  It seems
> to needlessly constrain future actions.
> 
> Section 11
> 
> Curve25519 support is a MAY, so I think RFC 7748 belongs as normative;
> likewise for RFCs 8032 and 6234.
> 
> It's probably better to cite RFC 7696 as BCP 201 directly.
> 
> Section B.3
> 
> It would be great if the document shepherd could diff the paramters listed here
> against [CURVE-REPRESENTATIONS].
>