Subject: RE: [NSIS] GIMPS connection mode and intermediaries

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 28 Jan 2004 10:41:57 -0000

hi attila (also responding to georgios),

> -----Original Message-----
> From: Attila Báder (IJ/ETH) [mailto:[email-masked]]
> Sent: Wednesday, January 28, 2004 10:20
> To: Hancock, Robert; Nsis (E-mail)
> Subject: RE: [NSIS] GIMPS connection mode and intermediaries
> 
> 
> Hi Robert,
> 
> I think in case of a) it is not an issue. We are considering 
> to use two kind of signaling in a stateless domain: 
> edge-to-edge, probably in 'C' mode, and intradomain signaling 
> in 'D' mode. I think the first one is not needed to intercept.
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
this is the critical point. 3175 does this (prevention of the
interior nodes seeing these messages) with a special
protocol number (as georgios mentions); the current assumption
in the -00 draft is that aggregation levels can be encoded
into the RAO field with the same effect, although of course 
that is still open to discussion. in any case, the functionality
is clearly needed.

> 
> In connection with intermediaries, my question is if GIMPS 
> supports a routing alert functions with which a QSpec can be 
> reached fast, without going through all protocol stacks. 
> (Thinking of first of all of our RMD-like NTLP stateless operation.)

once the RAO has been spotted at the IP layer, our assumption/
hope is that the rest of GIMPS D-mode processing will be 
fairly simple (e.g. strip of UDP, demultiplex on signalling
application ID and flow/session ID matching). time will tell
if we are able to hold to this promise, of course...

cheers,

robert h.

> 
> Best regards, Attila
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf Of
> > Hancock, Robert
> > Sent: Tuesday, January 27, 2004 5:46 PM
> > To: Nsis (E-mail)
> > Subject: [NSIS] GIMPS connection mode and intermediaries
> > 
> > 
> > dear all,
> > 
> > This is the first of two mails which proposes the elimination
> > of some options in the GIMPS (proposed solution for NTLP) design
> > space; it's intended to find out if there is any objection to
> > removing these options (i.e. are people happy to live with the
> > resulting limitations on GIMPS functionality).
> > 
> > All of the following refers to
> > http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-00.txt
> > 
> > BACKGROUND: GIMPS has a datagram ("D") mode (basically unsecured 
> > UDP transport) and a connection ("C") mode (which can use connection
> > oriented transport protocols like TCP, SCTP, DCCP and channel
> > security mechanisms like IPsec, TLS - details TBD). C-mode is 
> > supposed to be used between adjacent peers for a given signalling
> > application, where that signalling application needs 
> > industrial-strength 
> > transport or security services.
> > 
> > C-mode is simple and easy where there is no need to do anything
> > to the signalling messages between the NSLP peers; you just use
> > the "raw" C-mode encapsulation defined in 5.3.2 of the draft. 
> > However, 
> > there are some cases where "intermediaries" between the NSLP 
> > peers want
> > to do something to the messages, and there the situation gets 
> > much more messy. A description of how messy it gets is given in
> > the slides from Minneapolis (start at
> > http://www.ietf.org/proceedings/03nov/slides/nsis-1/sld10.htm)
> > and one possible solution is outlined in section 5.3.3 of the draft.
> > 
> > We'd like to head towards an alternative solution, namely banning
> > intermediaries in C-mode altogether.
> > 
> > WHY DID WE EVER WANT THEM? The concept of intermediary functionality
> > seems quite general, but in practice there have IIRC only ever
> > been two concrete applications:
> > 
> > a) RMD-like functions in the QoS-NSLP (you want C-mode between the
> > edge nodes of a network, but you want interior nodes to access
> > the signalling messages to update information about resource
> > availability by looking at per-flow messages). This was partly
> > in the background in the wg -00 draft (and several previous 
> > individual submissions).
> > 
> > b) Signalling through a NAT which doesn't support the NSLP in
> > question (the NAT wants to modify the addressing information which 
> > defines what flow is being signalled for, but doesn't want to
> > modify or even understand any of the other information; see
> > further discussion in section 5.3 of
> > http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-05.txts 
> > and 4.5, 4.6 of 
> > 
> http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-00.txt
> > and to a lesser extent
> > http://www.ietf.org/internet-drafts/draft-aoun-nsis-nslp-natfw
> -migration-00.txt)
> 
> WHAT COULD WE DO INSTEAD? 
> 
> (a) Our sources in the QoS-NSLP activity suggest that the favoured
> approach is now to use separate sessions for the direct edge-edge 
> signalling and edge-interior-edge signalling. The first would be
> simple C-mode and the second in D-mode. The edge nodes would have
> to correlate the two (but this is true in any aggregation-like
> scenario).
> ==> we don't need to worry about (a) any more.
> 
> (b) For the NAT case, rather than translating the content of C-mode
> messages as they go backwards and forwards through the NAT, we 
> should require that the GIMPS instances in the NSLP peers discover
> during initial message exchanges that a NAT is present and what
> it will do to packet headers; GIMPS then includes the pre- and
> post-translation flow-ids in C-mode messages, invisibly for the NAT.
> 
> Host A ---- NSLP ------- NAT ------- NSLP ----- Host B
>             NTLP                     NTLP
>              NE1                      NE2
> 
> C mode messages from NE1 to NE2 would say, at the GIMPS level, "this
> is a message about a flow which I see as being defined by flow-id-1
> but you see as being about flow-id-2". This approach was mentioned 
> in the past at various meetings and is also hinted at in the NATFW 
> drafts, but has not been intensively discussed.
> [Note: for the purpose of this discussion, it doesn't really matter
> if the NAT is GIMPS aware or not. Either way, we are saying that 
> once GIMPS discovery is complete and C-mode is being used, the NAT 
> has nothing to do with the payloads of signalling messages.]
> 
> [We do need to do more thinking about how GIMPS works out how the
> NAT is there and what it is doing, but that seems unavoidable in 
> any approach and also seems soluble.]
> 
> ==> if we go this way, we don't need to care about (b) either
> 
> ==> overall we can allow ourselves to restrict the required GIMPS
> functionality to the 'no intermediaries' case.
> 
> Comments welcome,
> 
> robert h.
> 
> _______________________________________________
> 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: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 28 Jan 2004 12:13:54 +0100

Hi Robert

Thank you very much!
In that case I agree with your proposal.

Best Regards,
Georgios

----- Original Message ----- 
From: "Hancock, Robert" <[email-masked]>
To: "'Attila Báder (IJ/ETH) '" <[email-masked]>; "Nsis (E-mail)"
<[email-masked]>
Sent: Wednesday, January 28, 2004 11:41 AM
Subject: RE: [NSIS] GIMPS connection mode and intermediaries