Subject: [NSIS] NATFW Session and address lifetime

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 28 Apr 2006 13:58:13 +0100

hi,

some comments on the session and address lifetime issue, see
sections 3.4 and 5.11 (in particular) [nb these sections should
probably refer to each other].

I think the main threat here is that an IP address that was
validly assigned to one node which then set up signalling
sessions referring to it may get validly reassigned to another
node which then re-uses those sessions. 

One solution to this is indeed data origin authentication as
mentioned in the text. However, I'm sceptical that data origin
authentication could ever be used in practice to address this
sort of issue (it would require the address allocation process
and protocol to include time-bounded credentials for the ownership
of an address which everyone else in the network was able to
verify). However, it should at least be possible to ensure that
the node initiating a signalling session gave it a lifetime that
was smaller than the remaining validity of any dynamically 
allocated address. That way, by the time the address is available
for re-allocation, any signalling sessions would have already
timed out. I would propose to add this to section 3.4.

Some lesser points on 3.4:
- (page 28): the lifetime value should ideally take some account of load
on the signalling plane. Short lifetimes imply more frequent
signalling messages.
- (page 28): the lifetime value should also take account of the
acceptable
time for a signalling session to be present after it is no longer
actually needed. (For example, if the existence of the session
implies a monetary cost and teardown cannot be guaranteed, shorter
lifetimes would be preferable.)
- (page 29): can messages be rejected on the basis of the lifetime
being too long only when a session is first created, or also on
refresh?
- (page 29): it strikes me that as well as the 'lifetime too big'
error there should be a 'lifetime too small' error. if someone initiates
a session with a lifetime of 1 second, i am compelled to use a lifetime
no longer than that on the downstream segments of the path. But that
lifetime may cause excessive signalling load. It would be good to
indicate what approaches are available to a NATFW implementation to
handle this kind of overload.
- (page 29 last paragraph): i don't understand which value is being
referred to as the 'proposed' value.

cheers,

r.

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 30 Apr 2006 14:49:42 -0400

Hi Robert,

Hancock, Robert wrote:
> verify).

Yes; We are not suggesting this solution since this document is about 
non-crypgraphic data traffic filtering. If this threat is a concern then 
  protocols that provide data origin authentication are more applicable.

  However, it should at least be possible to ensure that
> timed out. I would propose to add this to section 3.4.

That's certainly a good hint.

> on the signalling plane. Short lifetimes imply more frequent

True.

> lifetimes would be preferable.)

Fine.

> being too long only when a session is first created, or also on

Also on a refresh.
We need to state that more precisely.

> handle this kind of overload.

Sounds reasonable to me.

> referred to as the 'proposed' value.

I guess you refer to the following sentences:

"
    Each NSLP forwarder processes the RESPONSE message, reads and stores
    the granted lifetime value.  The forwarders MUST accept the granted
    lifetime, as long as this value is less than or equal to their
    proposed value.
"

With "proposed" value we refer to the value that is received by the 
NATFW NSLP forwarder when computing the lifetime of the session. It 
might either accept the received lifetime or lower it.

We could be a bit more specific when we talk about the "proposed" value.

Ciao
Hannes