Subject: RE: [NSIS] Responder Cookie construction

From: "Christian Dickmann" <[email-masked]>
Date: Fri, 27 Apr 2007 23:43:08 +0200

Hi Andrew,

> 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. 

I do not understand why you can only get the reception interface in case
of
a Q-Mode encapsulated message (this is what you meant, right?). Is this
a
theoretical argument or do you just see a problem with actual
implementations of TCP/IP?

> 
> 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.

You seem to be right. I can't see how 8.5 covers this problem.

Christian

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

---

From: Andrew McDonald <[email-masked]>
Date: Fri, 27 Apr 2007 23:44:50 +0100

Hi Christian,

> implementations of TCP/IP?

The Q-Mode encapsulation, at least in the path coupled MRM case,
recommends the setting of fields in the IP header in certain ways,
including:
- source address set to MRI source address (S=0)
- setting of DiffServ field to match MRI
- setting of flow label to match MRI
These /could/ cause the Q-Mode encapsulated packet to be routed
differently (and so arrive over a different interface) to a Confirm.

Andrew