Subject: [NSIS] Responder Cookie construction

From: Andrew McDonald <[email-masked]>
Date: Fri, 27 Apr 2007 21:53:11 +0100

Hi,

In reviewing the draft and attempting to implement 'late state
installation' (i.e. wait until you get a Confirm before installing
routing state), I found some potential issues in the suggested
(non-normative) construction for responder cookies in section 8.5.

(Part of this also relates to gist-aware nat-traversal.)

For reference, the construction there is:
  R-Cookie = liveness data + hash (locally known secret,
                                   Q-Node NLI, MRI, NSLPID,
                                   reception interface,
                                   liveness data)

There are four particular cases to consider:
1) install routing state when you get the Query
2) wait until you receive the Confirm before installing routing state
3) as case (1), but where there is a NAT-Traversal object in the Query
4) as case (2), but where there is a NAT-Traversal object in the Query

The current construction is sufficient for (1), although in that case an
implementer may well choose just to generate random cookies and remember
them in the responding node.

One issue, however, I'm not clear whether the whole "Q-Node NLI" element
is relevant. The key parts of the NLI for routing state are the Peer ID
and Interface Address. Are there any problems if Routing State Validity
Time was to change between Query and Confirm?

For (2), it is necessary to store the reception interface in the cookie.
The responding node can only discover this from a Q-mode encapsulated
message. If not keeping routing state, then it needs to be able to
recover this information from the cookie in the confirm. An version of
the cookie construction to handle this would be:
  R-Cookie = liveness data + reception interface +
                             hash (locally known secret,
                                   Q-Node NLI, MRI, NSLPID,
                                   reception interface,
                                   liveness data)

For (3) and (4) things get slightly more complicated. Section 7.2.3 says
   Therefore, a Responding node that wishes to delay state installation
   until receiving a Confirm must somehow reconstruct the translations
   when the Confirm arrives.  How to do this is an implementation issue;
   one approach is to carry the translated objects as part of the
   Responder cookie which is echoed in the Confirm.  Indeed, for one of
   the cookie constructions in Section 8.5 this is automatic.
However, section 8.5 does not currently appear to cover this.

I'll discuss this from the point of view of case (4), case (3) is
simpler since routing state data does not need to be recovered from the
cookie.

If there is a NAT traversal object present, I think we need to take into
account both the translated and untranslated MRIs, since the responding
node is expected to construct its routing state based on the
untranslated MRI, but the translated MRI is needed by NSLPs.

Also, the translated NLI needs to be recovered, since that is what
should be used in the routing state (but only the untranslated NLI will
be in the Confirm[*]).

So, the cookie construction we need for case (4) probably looks like:
  R-Cookie = liveness data + reception interface +
             translated MRI + translated NLI +
                             hash (locally known secret,
                                   translated Q-Node NLI,
                                   untranslated MRI,
                                   translated MRI,
                                   NSLPID,
                                   reception interface,
                                   liveness data)

In case (3), we don't need the recoverable data outside the hash.

I did also wonder whether the SID ought to be incorporated into the
hashed data. The SID is part of the routing state to avoid malicious
(blind, off-path) modification of the state. Are there any security
issues if it was to change between Query and Confirm? If it did, then in
the current state of affairs different routing state would be installed
in the last state installation case to if the state had been installed
when the query was received. (Also, if state had been installed when the
Query was received the Confirm would be rejected as not matching that
routing state.)

The remaining question is, how much of this discussion (and which
suggested constructions) needs to be included in 8.5?

[*] I've also just noticed that 7.2.2 says that opaque versions of the
NLI may be carried in the NAT-Traversal object to aid topology hiding.
If the untranslated version appears in the Confirm, how does this help?

regards,
Andrew

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 28 Apr 2007 10:35:37 +0200

The aspect of Cookie construction in case of NAT traversal is addressed in 

http://tools.ietf.org/html/draft-pashalidis-nsis-gimps-nattraversal-04