Subject: [NSIS] Sam Hartman: DISCUSS: draft-ietf-nsis-ntlp

From: <[email-masked]>
Date: Fri, 15 Sep 2006 16:05:38 +0300

Here's a DISCUSS and Sam about GIST.  Robert is traveling,
but it would be good to discuss this in the WG to find out ways to
address 
his DISCUSS.

John 

>-----Original Message-----
>From: ext Sam Hartman [mailto:[email-masked]] 
>Sent: 13 September, 2006 22:53
>To: [email-masked]
>Cc: [email-masked]; [email-masked]; 
>[email-masked]
>Subject: DISCUSS: draft-ietf-nsis-ntlp 
>
>Discuss:
>First, thanks for a well written protocol writeup.  While I'm 
>bringing up serious concerns, I think that we'll be able to 
>address them and move forward relatively quickly.
>
>
>How does GIST deal with lost response packets in the case 
>where there are multiple responders.  The discussion in 
>section 5.3.3 presents an argument that a node will get at 
>least one query response.  However, it seems that there could 
>be multiple GIST nodes wishing to participate in signaling 
>between the querying node and the destination of the data flow 
>(assuming path-coupled MRM).
>How will you know if there was a GIST peer who wanted to set 
>up routing state but whose response was lost?
>
>GIST raises significant architectural concerns about the 
>end-to-end service model of the Internet.  In particular there 
>are multiple cases having to do with q-mode encapsulation 
>where GIST nodes consume, generate and modify packets that are 
>neither sourced nor destined for them.  The advice in section 
>7.2 goes against the requirements of section 7 of 
>draft-ietf-behave-nat-udp (an approved BCP).  Even so, I think 
>it is necessary for GIST to do these things but I think we 
>need to be very careful about the interactions with other 
>things deployed on the Internet.  We also want to discourage 
>general applications of this form and I think it critical that 
>we establish architectural requirements so that future 
>proposals work with GIST.  I don't think it necessary to block 
>GIST on that architectural work.
>
>I propose that:
>
>1) A section of the GIST document be added clearly indicating 
>when a GIST implementation can modify a packet not targeted 
>for itself and when it is expected to intercept such packets.  
>That is currently scattered too much throughout the document.  
>Specific care should be given to cases where a GIST node will 
>not forward traffic for which it would normally act as a 
>router.  In particular, I think it would be harmful if traffic 
>that happened to be on the GIST UDP port were discarded if it 
>clearly had no relation to GIST.
>
>
>2) Discuss interactions with AH and other mechanisms that 
>might be added (especially by intermediate routers) that could 
>cause problems when packets are modified.
>
>
>3) Explicitly call out this document's divergence from 
>draft-ietf-behave-nat-udp.
>
>4) Send a more general architectural question to the community and IAB.
>
>
>Would it be possible to add a MAC (message integrity code) 
>based on a negotiated secret to D-mode packets using an 
>extensibility mechanism?
>If so, how would this be done?  I don't think we need require 
>this now, but I do think we need to make sure that if 
>modification of D-mode packets becomes a problem we have a 
>solution we can specify.
>
>
>The discussion of TLS needs to describe what names 
>certificates need to use.
>
>Section 8.3 claims that authenticated peers can be trusted not 
>to claim they are on-path when they are off-path.  
>Authentication is not the same as authorization.  The 
>discussion of when this assumption is reasonable needs to be 
>significantly expanded.
>
>
>There does not seem to be a discussion of extensibility in the 
>main body of the document.
>
>
>

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

---

From: Sam Hartman <[email-masked]>
Date: Mon, 18 Sep 2006 12:56:16 -0400

>>>>> "John" ==   <[email-masked]> writes:

    John> Here's a DISCUSS and Sam about GIST.  Robert is traveling,
    John> but it would be good to discuss this in the WG to find out
    John> ways to address his DISCUSS.

A few additional comments on the discuss.

First, I've been told that many of my architectural questions about
changing IP packets as they traverse the network are handled in the
NSIS framework.  That's on my reading list probably for late this
week.

Second, I realize that the situation  for multiple responses is more complicated than I thought.

It turns out that what happens to the original query falls off a
disconnect between section 4.3.1 and 4.4.1 Section 4.3.1 tells us that
we're going to 4.4.1 if we are a GIST peer that actually wants to
become involved in the signaling.

We know from 3.7 that the query packet we received will be forwarded
and will make its way to the end node.

However 4.4.1 does not discuss this forwarding.  Who does the response
go to?  Is the MRI updated to point to us, or is the MRI left
unchanged so that all responses go to the querying node?

It turns out this is important to understand my comment about multiple
responses.

---

From: "Robert Hancock" <[email-masked]>
Date: Wed, 20 Sep 2006 09:54:11 +1000

Hi Sam,

I'll try to address this multiple responses issue specifically,
and come back to the rest of the discuss in another mail.
The situation here should be relatively simple, but it's possible
that the current text has misleading aspects. 

The basic concept is that each Query gets one Response. The Response
gets sent to the node that sent the Query (the node address comes
from the NLI object in the Query message); the two nodes, Querying
and Responding, are the two ends of a single GIST hop. Along an
end-to-end path, there will likely be multiple GIST hops; for each
of them, there is a Query/Response exchange which is local to that
hop. The MRI is not changed along the path.

GIST is basically ignorant of the fact that there are multiple hops
chained together in this way; linking up the hops to provide an 
end-to-end signalling exchange is carried out at the signalling
application level (e.g. the forwarding referred to in section 3.7
step 5 is done at that level) - a single Query itself does not travel
end to end. Each hop is initiated by signalling application on the
node trying to send a message; GIST then carries out a local Query/
Response to get to the next node.

Most of the details of the process are in section 4.3. The 
complications arise from the rules about when a node decides that
it is going to be the other end of a hop, i.e. when it decides to
send a Response to an intercepted Query. There are 3 cases:
- node is completely uninterested; the Query is forwarded (4.3.4)
- the signalling application inspects the Query payload but the node
  decides not to become the end of a hop; the Query is forwarded 
  (4.3.2 case 2)
- the signalling application inspects the Query payload and decides
  to peer; a Response is sent (4.3.2 case 1; 4.4.1 then describes
  the details of how the peering process continues)

(There are subtleties in the case of error conditions, but the
fundamental behaviour above is preserved.)

Is this explanation going in the right direction to address your
concern? Or have I misunderstood it?

cheers,

Robert H.

ps. responses may be delayed by travelling

> From: Sam Hartman [mailto:[email-masked]] 
> Sent: 19 September 2006 02:56
> To: [email-masked]
> Cc: [email-masked]
> Subject: [NSIS] Re: Sam Hartman: DISCUSS: draft-ietf-nsis-ntlp
> 
>

---

From: Sam Hartman <[email-masked]>
Date: Wed, 20 Sep 2006 11:27:54 -0400

>>>>> "Robert" == Robert Hancock <[email-masked]> writes:

    Robert> Hi Sam, I'll try to address this multiple responses issue
    Robert> specifically, and come back to the rest of the discuss in
    Robert> another mail.  The situation here should be relatively
    Robert> simple, but it's possible that the current text has
    Robert> misleading aspects.

    Robert> The basic concept is that each Query gets one
    Robert> Response. The Response gets sent to the node that sent the
    Robert> Query (the node address comes from the NLI object in the
    Robert> Query message); the two nodes, Querying and Responding,
    Robert> are the two ends of a single GIST hop. Along an end-to-end
    Robert> path, there will likely be multiple GIST hops; for each of
    Robert> them, there is a Query/Response exchange which is local to
    Robert> that hop. The MRI is not changed along the path.

Sorry, I meant NLI not MRI.

I found nothing in the text of section 3 or early section 4 that
clearly states this.  I think for example updating 3.7 to include two
nodes that want to be interested in the signal flow would help handle
some of these issues.

    Robert> GIST is basically ignorant of the fact that there are
    Robert> multiple hops chained together in this way; linking up the
    Robert> hops to provide an end-to-end signalling exchange is
    Robert> carried out at the signalling application level (e.g. the
    Robert> forwarding referred to in section 3.7 step 5 is done at
    Robert> that level) - a single Query itself does not travel end to
    Robert> end. Each hop is initiated by signalling application on
    Robert> the node trying to send a message; GIST then carries out a
    Robert> local Query/ Response to get to the next node.

This seems like it is discussed nowhere.  It also makes 5 in 3.7 very
misleading, because that behavior is dependent on the signaling
application.  I assumed throughout my entire reading of the document
that such forwarding was an invarient of GIST.

---

From: "Robert Hancock" <[email-masked]>
Date: Thu, 21 Sep 2006 11:45:45 +1000

hi sam,

Basically I'll apologise now that the text has led you astray in
this way.

I think the question now is how and where to clarify the text to
avoid other people falling into the same trap.

One possibility would be to make a normative reference to the
framework (rfc4080) and highlight it as required reading. For
example, section 3.2.2 of RFC4080 covers exactly this point (i think
fairly unambiguously). On the other hand, it is just more text for
the implementor to read. Do you think that extending 3.7 of the
GIST spec itself to cover who takes responsibility for what for 
the multi-hop aspects would be enough?

cheers & thanks for your patience,

robert h.

> Sent: 21 September 2006 01:28
> To: Robert Hancock
> Cc: [email-masked]; [email-masked]
> Subject: Re: multiple responses to a Query
> 
>

---

From: David R Oran <[email-masked]>
Date: Sun, 24 Sep 2006 07:55:59 -0400

> the multi-hop aspects would be enough?
This of course begs the question of whether the end-to-end  
transactional state machine should or should not be common for the  
different signaling applications.

As everyone on this list knows, I've been on the other side of this  
question (I wouldn't call it a debate because I was roundly defeated  
by the WG consensus) on this and the associated issues of common end- 
to-end features among the signaling applications.

I simply can't resist posting, because I am undeterred in my  
conviction that the design is at least suboptimal, and possibly flawed.

If there's no stomach to wind back and revisit these issues, I'll  
crawl back into my cave.

Dave.