Subject: [NSIS] NATFW message format

From: Matthias Friedrich <[email-masked]>
Date: Thu, 11 May 2006 13:56:45 +0200

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.

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

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

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

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

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

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

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

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

Thanks for reading,
	Matthias

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

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 11 May 2006 15:51:39 +0200

Hi Matthias,

>    could also be noted that only one object of a type may appear

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

>    experimental implementations are compatible. The message types

Alright, this will be added to the next version.

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

>    4.3.[123] just use "lifetime".

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

>    object header only allows for 12 bits.

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

>    from text and diagram, but the length is specified as 3 words.

Right! Will be fixed.

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

>    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