Re: [NSIS] Responder Cookie construction

["Hannes Tschofenig" <[e-mail]>]

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

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

-------- Original-Nachricht --------
Datum: Fri, 27 Apr 2007 21:53:11 +0100
Von: Andrew McDonald <[e-mail]>
An: NSIS Working Group <[e-mail]>
Betreff: [NSIS] Responder Cookie construction

> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/nsis

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