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

From: Martin Stiemerling <[email-masked]>
Date: Wed, 19 Oct 2005 10:39:34 +0200

Hi all,

--On Montag, 17. Oktober 2005 22:57 Uhr +0100 "Hancock, Robert" 
<[email-masked]> wrote:

| hi all,
|
| IIRC there were two aspects of this topic discussed at the
| interim:
|
| a) the availability of the diagnosis/query features in the
| first place, and
|
| b) the use of them to build some procedures for recovery from
| certain error/restart scenarios
|
| I don't recall much discussion of (a). I recall significant
| objections to (b) (indeed, I think I made several of them)

Yes, you've made those objections :)

I object to b) as well since recovery from error/restart is complicated and
fragile. So I see b) as ruled out.

For case a) I have solicited real use cases for several times - without any
real response. However, what can a node learn by using a query capability,
other he can learn by using the already defined mechanisms (error messages,
NOTIFY messages? (this is not a question to you Robert but others :)

| because they seemed rather complicated and fragile.
| But that doesn't mean that the facilities themselves are
| not useful for - well - diagnosis (for which it's hard to
| build reasonable scenarios other than "something went wrong
| and I'd like to work out what").
|
| It is possible to go overboard on diagnostics but I don't
| think we're there yet.

I see it the same way. Probably, somebody will find an interesting
use case in the future. If so, we can extend the NATFW NSLP later.

Thanks,

  Martin

|
| r.
|
|> -----Original Message-----
|> From: [email-masked] [mailto:[email-masked]] On
|> Behalf Of [email-masked]
|> Sent: 14 October 2005 08:09
|> To: [email-masked]; [email-masked]
|> Subject: RE: [NSIS] Query & Diagnosis Capabilities in NATFW NSLP
|>
|>
|> Hi Martin,
|>
|> > Draft -07 of the NATFW NSLP describes a query and diagnosis
|> > capability in Section 3.3.6. These capabilities have been in
|> > the draft for while but no real usage scenarios have been
|> > described so far (see issue 30 in the tracker
|> > <https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/issue30>).
|> >
|> > The general feeling of the WG about these query and diagnosis
|> > capabilities were quite mixed (as expressed during the last
|> > interim in Munich). Since then I have not received any further
|> > comments about this issue.
|> >
|> > Personally, I do not see any good use cases for such a
|> > capability in the NATFW NSLP and I'm in favour of removing it
|> > completely.
|> >
|> > I'm soliciting the WG to give feedback on this issue, whether
|> > it is considered a useful feature or not. If you consider it a
|> > useful feature, you should give some use cases.
|>
|> I am leaning towards dropping this feature.  I think that this is
|> extra functionality without defined use - this will make the
|> implementatino & usage more difficult.
|>
|> John
|>
|> _______________________________________________
|> nsis mailing list
|> [email-masked]
|> https://www1.ietf.org/mailman/listinfo/nsis
|>

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

---

From: David R Oran <[email-masked]>
Date: Wed, 19 Oct 2005 08:57:33 -0400

I've stopped following the protocol details, so excuse me if these   
are stupid questions.

1. Is there a way (through QUERY or some other machinery) for an NSIS  
client to say "if I were to ask for a QoS reservation with the  
following attributes (including QSPEC) to the following destination,  
would it succeed, and if not, would the failure by due to
a) insufficient resources
b) policy violation
c) something mal-formed

2. Does QUERY follow the same NSIS path as what it is querying about?  
If so, does the response tell me the path? If not, can I find out  
what path an NSIS session takes (either current or prospective) so I  
have the equivalent funcitonality for NSIS routing that I do with  
traceroute?

I've often wished I had such diagnostic capabilities in RSVP.

Dave.

P.S. I happen to agree on point (b) that building separate state  
recovery / restart machinery is a bad idea - the protocol should  
simply work and have clear failure semantics when self-repair fails.

---

From: Jukka MJ Manner <[email-masked]>
Date: Wed, 19 Oct 2005 16:21:41 +0300 (EEST)

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.

Cheers,
Jukka

On Wed, 19 Oct 2005, David R Oran wrote:

> I've stopped following the protocol details, so excuse me if these  are stupid
> questions.
> 
> 1. Is there a way (through QUERY or some other machinery) for an NSIS client
> to say "if I were to ask for a QoS reservation with the following attributes
> (including QSPEC) to the following destination, would it succeed, and if not,
> would the failure by due to
> 2. Does QUERY follow the same NSIS path as what it is querying about? If so,
> does the response tell me the path? If not, can I find out what path an NSIS
> session takes (either current or prospective) so I have the equivalent
> funcitonality for NSIS routing that I do with traceroute?
> 
> P.S. I happen to agree on point (b) that building separate state recovery /
> restart machinery is a bad idea - the protocol should simply work and have
> clear failure semantics when self-repair fails.
> 
>

---

From: David R Oran <[email-masked]>
Date: Wed, 19 Oct 2005 09:30:02 -0400

On Oct 19, 2005, at 9:21 AM, Jukka MJ Manner wrote:

> S
Sorry - I keep pretending that general-purpose functions are actually  
in a general-purpose part of the NSIS protocol suite :-)

> might also ask, whether you are allowed to reserve resources in the  
Yes, ditto for NAT/FW mappings, so you did a good job of correctly  
realizing my question, though framed in terms of QoS, could just as  
easily been framed in terms of NAT/FW.

> Currently, you can't trace the route, at least not that I know of.
I'm interested in whether other folks think this is important, as I do.

Thanks, Dave.

>> recovery /

---

From: Roland Bless <[email-masked]>
Date: Thu, 20 Oct 2005 09:29:58 +0200

Hi Dave,

> in a general-purpose part of the NSIS protocol suite  :-) 

Unfortunately, no. That would be a candidate for common NSLP
functionality, but we don't have a separate layer for that.

>From my experience it would be important at least for error
diagnosis purposes. IIRC we discussed this a little at the interim
meeting in Munich in the context of the GIST ping-tool, that is
more like a traceroute NSLP. A problem using a separate NSLP instance
for traceroute functionality is that the actual NSLP node set on the
path may be slightly different for the ping/traceroute and the
actually used QoS or NAT/FW NSLP.

Nevertheless, I think it's helpful to know something about
the (nodes on the) path at least in case of errors.
That's why I requested some time ago to add something like
an Error Source Identifier in NSLPs so that you may at least
know where the failure occured. Having this, maybe we could easily
mimic a tracroute functionality:
GIST has a GHC (GIST Hop Count). If it is decremented to zero GIST
will report an error to the sender. I'm not sure about the currently
defined interaction of GIST with NSLP in this case, but I think
it would be useful to let GIST report that error also to the NSLP
via a MessageStatus API call (Robert?). That in turn could generate an
NSLP error message that is propagated back towards the originator of
the QUERY/RESERVE etc. Opinions?

Regards,
 Roland

---

From: Elwyn Davies <[email-masked]>
Date: Thu, 20 Oct 2005 09:32:07 +0100

Hi, all.

> fragile. So I see b) as ruled out.

I agree that the recovery from error/restart is unlikely to be really 
useful.  The chances of the node
retaining enough information across a problem event for this mechanism 
to be useful is just too low.

> NOTIFY messages? (this is not a question to you Robert but others :)

HOWEVER, I do see a case for a very limited query mechanism which would 
be able to report just
the identities of NSLP nodes active on a session path.  With this 
information, a management system
(for example) would be able to make more specific queries about the 
session.  Without it, the
management system has no idea (or at least a very complex problem) of 
how to obtain and correlate information
relating to a session - I believe this issue was discussed some time ago 
but in a more general context. It is
a common problem for all path directed mecahnisms.

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.

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

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 21 Oct 2005 13:03:11 +0200

Hi Dave and all,

--On Mittwoch, 19. Oktober 2005 9:30 Uhr -0400 David R Oran 
<[email-masked]> wrote:

|
| On Oct 19, 2005, at 9:21 AM, Jukka MJ Manner wrote:
|
|>
|> Hi,
|>
|> This is a thread about the NATFW, and you are talking about QoS,
|> but I'm
|> still answering. ;)
|> S
| Sorry - I keep pretending that general-purpose functions are actually  in
| a general-purpose part of the NSIS protocol suite :-)
|
|> 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.
| Yes, ditto for NAT/FW mappings, so you did a good job of correctly
| realizing my question, though framed in terms of QoS, could just as
| easily been framed in terms of NAT/FW.

The NATFW NSLPs does not give such a QUERY where you can ask if
you theoretically can obtain these resources. The way to do this in
the NATFW NSLP is to send a request message (CREATE, REA, UCREATE, or
their proxy variants) and to see the reply.  The reply will tell,
if the request has been fulfilled successfully or if there has been
an error (for instance, firewall/NAT does not like your requested
policy rule, no resources left, not allowed to get this policy rule,
etc).

|
|> This needs some clarification in our work, Hannes?
|>
|> Currently, you can't trace the route, at least not that I know of.
|>
| I'm interested in whether other folks think this is important, as I do.

Until I have been against a traceroute functionality in the NATFW NSLP,
but some recent discussions have changed that. My response to Elwyn's
email contains my thoughts.

Best regards,

  Martin

|
| Thanks, Dave.
|
|> Cheers,
|> Jukka
|>
|> On Wed, 19 Oct 2005, David R Oran wrote:
|>
|>
|>> I've stopped following the protocol details, so excuse me if
|>> these  are stupid
|>> questions.
|>>
|>> 1. Is there a way (through QUERY or some other machinery) for an
|>> NSIS client
|>> to say "if I were to ask for a QoS reservation with the following
|>> attributes
|>> (including QSPEC) to the following destination, would it succeed,
|>> and if not,
|>> would the failure by due to
|>> a) insufficient resources
|>> b) policy violation
|>> c) something mal-formed
|>>
|>> 2. Does QUERY follow the same NSIS path as what it is querying
|>> about? If so,
|>> does the response tell me the path? If not, can I find out what
|>> path an NSIS
|>> session takes (either current or prospective) so I have the
|>> equivalent
|>> funcitonality for NSIS routing that I do with traceroute?
|>>
|>> I've often wished I had such diagnostic capabilities in RSVP.
|>>
|>> Dave.
|>>
|>> P.S. I happen to agree on point (b) that building separate state
|>> recovery /
|>> restart machinery is a bad idea - the protocol should simply work
|>> and have
|>> clear failure semantics when self-repair fails.
|>>
|>>
|>> On Oct 19, 2005, at 4:39 AM, Martin Stiemerling wrote:
|>>
|>>
|>>> Hi all,
|>>>
|>>> --On Montag, 17. Oktober 2005 22:57 Uhr +0100 "Hancock, Robert"
|>>> <[email-masked]> wrote:
|>>>
|>>> | hi all,
|>>> |
|>>> | IIRC there were two aspects of this topic discussed at the
|>>> | interim:
|>>> |
|>>> | a) the availability of the diagnosis/query features in the
|>>> | first place, and
|>>> |
|>>> | b) the use of them to build some procedures for recovery from
|>>> | certain error/restart scenarios
|>>> |
|>>> | I don't recall much discussion of (a). I recall significant
|>>> | objections to (b) (indeed, I think I made several of them)
|>>>
|>>> Yes, you've made those objections :)
|>>>
|>>> I object to b) as well since recovery from error/restart is
|>>> complicated and
|>>> fragile. So I see b) as ruled out.
|>>>
|>>> For case a) I have solicited real use cases for several times -
|>>> without any
|>>> real response. However, what can a node learn by using a query
|>>> capability,
|>>> other he can learn by using the already defined mechanisms (error
|>>> messages,
|>>> NOTIFY messages? (this is not a question to you Robert but others :)
|>>>
|>>> | because they seemed rather complicated and fragile.
|>>> | But that doesn't mean that the facilities themselves are
|>>> | not useful for - well - diagnosis (for which it's hard to
|>>> | build reasonable scenarios other than "something went wrong
|>>> | and I'd like to work out what").
|>>> |
|>>> | It is possible to go overboard on diagnostics but I don't
|>>> | think we're there yet.
|>>>
|>>> I see it the same way. Probably, somebody will find an interesting
|>>> use case in the future. If so, we can extend the NATFW NSLP later.
|>>>
|>>> Thanks,
|>>>
|>>>  Martin
|>>>
|>>> |
|>>> | r.
|>>> |
|>>> |> -----Original Message-----
|>>> |> From: [email-masked] [mailto:[email-masked]] On
|>>> |> Behalf Of [email-masked]
|>>> |> Sent: 14 October 2005 08:09
|>>> |> To: [email-masked]; [email-masked]
|>>> |> Subject: RE: [NSIS] Query & Diagnosis Capabilities in NATFW NSLP
|>>> |>
|>>> |>
|>>> |> Hi Martin,
|>>> |>
|>>> |> > Draft -07 of the NATFW NSLP describes a query and diagnosis
|>>> |> > capability in Section 3.3.6. These capabilities have been in
|>>> |> > the draft for while but no real usage scenarios have been
|>>> |> > described so far (see issue 30 in the tracker
|>>> |> > <https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/issue30>).
|>>> |> >
|>>> |> > The general feeling of the WG about these query and diagnosis
|>>> |> > capabilities were quite mixed (as expressed during the last
|>>> |> > interim in Munich). Since then I have not received any further
|>>> |> > comments about this issue.
|>>> |> >
|>>> |> > Personally, I do not see any good use cases for such a
|>>> |> > capability in the NATFW NSLP and I'm in favour of removing it
|>>> |> > completely.
|>>> |> >
|>>> |> > I'm soliciting the WG to give feedback on this issue, whether
|>>> |> > it is considered a useful feature or not. If you consider it a
|>>> |> > useful feature, you should give some use cases.
|>>> |>
|>>> |> I am leaning towards dropping this feature.  I think that this is
|>>> |> extra functionality without defined use - this will make the
|>>> |> implementatino & usage more difficult.
|>>> |>
|>>> |> John
|>>> |>
|>>> |> _______________________________________________
|>>> |> nsis mailing list
|>>> |> [email-masked]
|>>> |> https://www1.ietf.org/mailman/listinfo/nsis
|>>> |>
|>>>
|>>>
|>>>
|>>> _______________________________________________
|>>> nsis mailing list
|>>> [email-masked]
|>>> https://www1.ietf.org/mailman/listinfo/nsis
|>>>
|>>>
|>>
|>> _______________________________________________
|>> nsis mailing list
|>> [email-masked]
|>> https://www1.ietf.org/mailman/listinfo/nsis
|>>
|>
|
| _______________________________________________
| nsis mailing list
| [email-masked]
| https://www1.ietf.org/mailman/listinfo/nsis

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 21 Oct 2005 13:06:34 +0200

--On Donnerstag, 20. Oktober 2005 9:29 Uhr +0200 Roland Bless 
<[email-masked]> wrote:

| Hi Dave,
|
|> Sorry - I keep pretending that general-purpose functions are actually
|> in a general-purpose part of the NSIS protocol suite  :-)
|
| Unfortunately, no. That would be a candidate for common NSLP
| functionality, but we don't have a separate layer for that.

I even doubt that it could be done in a separate layer, since the
parameters to query are quite different per NSLP.

|
|>> Currently, you can't trace the route, at least not that I know of.
|>>
|> I'm interested in whether other folks think this is important, as I do.
|
|> From my experience it would be important at least for error
| diagnosis purposes. IIRC we discussed this a little at the interim
| meeting in Munich in the context of the GIST ping-tool, that is
| more like a traceroute NSLP. A problem using a separate NSLP instance
| for traceroute functionality is that the actual NSLP node set on the
| path may be slightly different for the ping/traceroute and the
| actually used QoS or NAT/FW NSLP.
|
| Nevertheless, I think it's helpful to know something about
| the (nodes on the) path at least in case of errors.

NATFW NSLP people are currently discussing about this feature. So
stay tuned :-)

Regards,

  Martin

| That's why I requested some time ago to add something like
| an Error Source Identifier in NSLPs so that you may at least
| know where the failure occured. Having this, maybe we could easily
| mimic a tracroute functionality:
| GIST has a GHC (GIST Hop Count). If it is decremented to zero GIST
| will report an error to the sender. I'm not sure about the currently
| defined interaction of GIST with NSLP in this case, but I think
| it would be useful to let GIST report that error also to the NSLP
| via a MessageStatus API call (Robert?). That in turn could generate an
| NSLP error message that is propagated back towards the originator of
| the QUERY/RESERVE etc. Opinions?
|
| Regards,
|  Roland
|
| _______________________________________________
| nsis mailing list
| [email-masked]
| https://www1.ietf.org/mailman/listinfo/nsis

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 21 Oct 2005 13:16:33 +0200

Hi Elwyn,

--On Donnerstag, 20. Oktober 2005 9:32 Uhr +0100 Elwyn Davies 
<[email-masked]> wrote:

[...]
|
|>
|> For case a) I have solicited real use cases for several times -
|> without any
|> real response. However, what can a node learn by using a query
|> capability,
|> other he can learn by using the already defined mechanisms (error
|> messages,
|> NOTIFY messages? (this is not a question to you Robert but others :)
|
| HOWEVER, I do see a case for a very limited query mechanism which would
| be able to report just
| the identities of NSLP nodes active on a session path.  With this
| information, a management system
| (for example) would be able to make more specific queries about the
| session.  Without it, the
| management system has no idea (or at least a very complex problem) of how
| to obtain and correlate information
| relating to a session - I believe this issue was discussed some time ago
| but in a more general context. It is
| a common problem for all path directed mecahnisms.
|
| 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)

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

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

Best regards,

  Martin

|
|>
|> | because they seemed rather complicated and fragile.
|> | But that doesn't mean that the facilities themselves are
|> | not useful for - well - diagnosis (for which it's hard to
|> | build reasonable scenarios other than "something went wrong
|> | and I'd like to work out what").
|> |
|> | It is possible to go overboard on diagnostics but I don't
|> | think we're there yet.
|>
|> I see it the same way. Probably, somebody will find an interesting
|> use case in the future. If so, we can extend the NATFW NSLP later.
|>
|> Thanks,
|>
|>  Martin
|>
|> |
|> | r.
|> |
|> |> -----Original Message-----
|> |> From: [email-masked] [mailto:[email-masked]] On
|> |> Behalf Of [email-masked]
|> |> Sent: 14 October 2005 08:09
|> |> To: [email-masked]; [email-masked]
|> |> Subject: RE: [NSIS] Query & Diagnosis Capabilities in NATFW NSLP
|> |>
|> |>
|> |> Hi Martin,
|> |>
|> |> > Draft -07 of the NATFW NSLP describes a query and diagnosis
|> |> > capability in Section 3.3.6. These capabilities have been in
|> |> > the draft for while but no real usage scenarios have been
|> |> > described so far (see issue 30 in the tracker
|> |> > <https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/issue30>).
|> |> >
|> |> > The general feeling of the WG about these query and diagnosis
|> |> > capabilities were quite mixed (as expressed during the last
|> |> > interim in Munich). Since then I have not received any further
|> |> > comments about this issue.
|> |> >
|> |> > Personally, I do not see any good use cases for such a
|> |> > capability in the NATFW NSLP and I'm in favour of removing it
|> |> > completely.
|> |> >
|> |> > I'm soliciting the WG to give feedback on this issue, whether
|> |> > it is considered a useful feature or not. If you consider it a
|> |> > useful feature, you should give some use cases.
|> |>
|> |> I am leaning towards dropping this feature.  I think that this is
|> |> extra functionality without defined use - this will make the
|> |> implementatino & usage more difficult.
|> |>
|> |> John
|> |>
|> |> _______________________________________________
|> |> nsis mailing list
|> |> [email-masked]
|> |> https://www1.ietf.org/mailman/listinfo/nsis
|> |>
|>
|>
|>
|> _______________________________________________
|> nsis mailing list
|> [email-masked]
|> https://www1.ietf.org/mailman/listinfo/nsis
|

---

From: Roland Bless <[email-masked]>
Date: Fri, 21 Oct 2005 16:33:44 +0200

Hi Martin,
> parameters to query are quite different per NSLP.

I think Dave meant something like a record route or traceroute.
That would be IMHO a very basic and simple functionality for all NSLPs.
But you're right if you're interested in more specific information about
a particular NSLP.

Regards,
 Roland