Re: [NSIS] NATFW message format

Martin Stiemerling <stiemerling@netlab.nec.de> Thu, 11 May 2006 14:45 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeCPs-00079R-6r; Thu, 11 May 2006 10:45:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeCPq-00079J-AQ for nsis@ietf.org; Thu, 11 May 2006 10:45:22 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeBfI-0002rx-8f for nsis@ietf.org; Thu, 11 May 2006 09:57:16 -0400
Received: from kyoto.netlab.nec.de ([195.37.70.21]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FeBZy-00014U-1g for nsis@ietf.org; Thu, 11 May 2006 09:51:47 -0400
Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id DAC6C1BAC4D; Thu, 11 May 2006 15:44:40 +0200 (CEST)
In-Reply-To: <20060511115645.GA22784@mafr.de>
References: <20060511115645.GA22784@mafr.de>
Mime-Version: 1.0 (Apple Message framework v749.3)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <D672BC0D-F889-4F8F-9EAA-DF7D7D7D268F@netlab.nec.de>
Content-Transfer-Encoding: 7bit
From: Martin Stiemerling <stiemerling@netlab.nec.de>
Subject: Re: [NSIS] NATFW message format
Date: Thu, 11 May 2006 15:51:39 +0200
To: Matthias Friedrich <matt@mafr.de>
X-Mailer: Apple Mail (2.749.3)
X-Spam-Score: -2.6 (--)
X-Scan-Signature: 34d35111647d654d033d58d318c0d21a
Cc: nsis@ietf.org
X-BeenThere: nsis@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Next Steps in Signaling <nsis.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:nsis@ietf.org>
List-Help: <mailto:nsis-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=subscribe>
Errors-To: nsis-bounces@ietf.org

Hi Matthias,


Am 11.05.2006 um 13:56 schrieb Matthias Friedrich:

> Hi,
>
> while reading section 4 (NATFW NSLP Message Components), I noticed the
> following minor issues:
>
>  * The order the objects may appear in a message is not specified.
>    If there is no fixed order, it should be stated explicitly. It
>    could also be noted that only one object of a type may appear
>    in a message.

There is no fixed order of the objects and each object must only appear
once in the message. Will be fixed.

>
>  * It would be nice to have preliminary object type IDs to make sure
>    experimental implementations are compatible. The message types
>    already have IDs.

Alright, this will be added to the next version.

>
>  * The "Forward" treatment is never used in the draft. Is there a use
>    case where it is necessary?

The "Forward" treatment, as described in Section 4.2, is not used by
the objects defined in the NATFW NSLP draft. But this treatment is
likely used by future objects that are yet to defined.
Imagine a new "mobile IP" object (however this may look like and  
useful).
This "mobile IP" object may request packet treatment by the firewall
that is are possibly needed, i.e., make life easier but is not 100%  
needed
for life. Another scenario would be a vendor specific object that can  
only be
handled by particular firewalls/NATs of that vendor.

>
>  * The NATFW_LT object is named "session lifetime", but sections
>    4.3.[123] just use "lifetime".

Should all read "session lifetime" or even better "signaling session
lifetime". Will be fixed.

>
>  * The NATFW_INFO object has a 16 bit object type, while the common
>    object header only allows for 12 bits.

Yes, the object field should be limited to 12 bits as well. Will be  
fixed.

>
>  * The NATFW_DTINFO_IPv4 object seems to have a variable length,  
> judging
>    from text and diagram, but the length is specified as 3 words.

Right! Will be fixed.

>
>  * The NATFW_TRACE's hop count seems to be unnecessary. The number of
>    hops can be derived from the number of IP addresses in this object.

Right, and see the extra email threat about the TRACE semantics. Feel  
free
to comment on this threat about TRACE in general.

>
>  * Is the NATFW_CREDENTIAL's length field really necessary? A concrete
>    credential type could still decide to use these bits as a length
>    field to support padding. For other credential types it might not
>    be needed. If the credential data is a multiple of 32 bit, the
>    leading 16 bit could be used as padding.

So will need so length information, some won't. This requires
a field where the length can be stored. Otherwise we would need
a flag that indicates whether the length field is used or not.

>
>  * Would a version number in the message header make sense?

You mean the NSLP header? No, it does not make sense per WG
decision. There will be new NSLP ID assigned, whenever there is
a new version of an NSLPs. This has been decided very long ago.

>
>
> Thanks for reading,

Thank you for reading!

   Martin

_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis