Subject: Re: [NSIS] Query & Diagnosis Capabilities in NATFW NSLP

From: Xiaoming Fu <[email-masked]>
Date: Thu, 03 Nov 2005 09:53:13 +0100

Hi Martin, Elwyn,

My comments inline:
Martin Stiemerling wrote:
> Hi Elwyn,
> 
> | A query message for NATFW NSLP specifically would be able to return the
> | sequnce of device types (NAT or FW or combined)
> | plus addressing information for the node (in the case of a NAT public and
> | private sides).  This is a strictly limited set
> | of information which does not need to worry about how rules are
> | formulated. It is simple to specify and gives the
> | substrate on which more complex queries could be built using other
> | (targeted) protocols.
> 
> This proposal sounds realistic, since the response is limited to a
> very specific information. Past proposals included reporting of
> policy rules installed at the involved firewalls/NATs. In my opinion,
> reporting of the policy rules is challenging in many ways:
> - Administrators do not like others to see the real policy rules will
>  all parameters,
> - Returning policy rules per hop may result in quite large messages
> - Representation of any thinkable policy rule in a generic and
>  interoperable seem quite difficult. (Consider all the possible
>  parameters of firewall/NAT implementations and the number of
>  vendors + software version)

If the query is just to collect NAT/FW device types along the path, 
there is an issue whether this should be put in a general tool or inside 
NAT/FW NSLP.
> 
> |
> | I suspect a similar query mechanism for QoS NSLP would also be useful.
> |
> | There would be some possible security issues.  Would a remote node wish
> | to give away its address, or even its existence?
> 
> I guess that many operators do not like others to see details about
> their infrastructure. Especially, when nodes from outside the network
> can learn about the infrastructure. As you have said below, a
> scoping mechanism is required. Furthermore, I would suggest to
> declare the NATFW Query mechanism optional, i.e., nodes may enter
> the IP address but they must not.

It might be the case a sysadm may desire to query such info in its 
domain (or even other neighboring trusted domains).
> 
> | Nodes should (I guess) be able to 'pass' on the message - forward it
> | without filling in information - and scope mechanisms might apply
> | so that the message is turned round at the edge of a domain.
> |
> | I think it has to be at the NSLP level because of the specificity of
> | sessions.
> 
> Right.
If such a capability is desired, I agree this is probably the right 
direction to go.
Xiaoming

> Best regards,
>  Martin

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

---

From: Xiaoming Fu <[email-masked]>
Date: Thu, 03 Nov 2005 09:56:26 +0100

Hi Jukka, David,

Jukka MJ Manner wrote:
> Hi,
> 
> This is a thread about the NATFW, and you are talking about QoS, but I'm 
> still answering. ;)
> 
> You can ask that for resources on the exact data path you intend to send
> your data. The answer you get depends on your QUERY message, but in
> practise you should get this information in return, yes. Still you raised 
> an interesting point, as I've thought that any authorization is done to 
> see whether you are allowed in general to query for resources. Yet, you 
> might also ask, whether you are allowed to reserve resources in the end. 
> This needs some clarification in our work, Hannes?
> 
> Currently, you can't trace the route, at least not that I know of.
If I understand it correctly, currently QoS queries only work like RSVP 
PATH with Adspec mostly used to gather available resource information 
along the path. If one desires the RFC2745-like functions, some 
possibilities are described in
http://user.informatik.uni-goettingen.de/~fu/nsis/diagnostics/draft-fu-nsis-diagnostics-nslp-00.txt

Thanks,
Xiaoming
> Cheers,
> Jukka