Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-fw-05.txt

From: "Ling Kim Hui" <[email-masked]>
Date: Mon, 3 Nov 2003 11:30:43 +0800

Dear Mr Hancock,

Thanks a lot for your timely reply. After checking the mailing list
archieve, I realized that the framework draft -04 has already gone
through the working group last call.  Does it mean that the draft -05
will go directly to AD/IESG for review? Sorry for asking, since I am not
that familiar with the review procedure.

I agree with most of your comments, though I have a few more thoughts
about them.

> i consider this as coming under the broad heading of route changes. 
> there are actually several different categories of route change anyway

> (different peer because of topology change, different peer because of 
> NE failure but no rerouting, same peer but different ingress or egress

> interfaces, same peer but different intermediate routers, ...)
> 
> exactly how each case is distinguished and handled will have to be 
> done during protocol design. different protocol designs and indeed 
> different implementations will be able to do different types of route 
> change handling, so the framework can't really define this.

This makes things clearer to me.  But I think the case we listed out is
more of a detection of false route change. Largely in the draft, the
route change is defined as the change of route for data traffic. 

It is correct that details of handling the route change is a protocol
design issue, but my feeling is that in the framework, we should point
out different scenarios, so that protocol designer could be aware of
those issues.

Therefore, it would be good to include some text to clearly identify the
route change cases (including the false route change)

> the information is the flow id (4.6.1). we specifically don't call 
> this the flow classifier, since the NTLP isn't interested in packet 
> classification; another name for the flow id would be 'flow routing 
> information' (which is what the NTLP draft calls it). the NSLP might 
> use the flow id as part of a packet classifier.

Is the flow ID the only field that needs to be visible to the NTLP?  How
would the NTLP uses information in the NSLP payload?  Should it be
accessible by the NTLP? Shouldn't that be encrypted?

I know this maybe depend on the implementation, but is it possible to
give me some guidance on any possible implementation method, since I am
really curious how it should be realized? 

> formally, the f/w is not a standards track document, so it
> cannot define and manage identifier formats in this way. at
> the moment it seems likely that the session id will be an object in
> the NTLP, so the NTLP specification will pin this down and the sort
> of problems you indicate cannot arise.

I am a bit confused here. Does this mean that the session ID instead of
Signaling Application ID would be used for demultiplexing the NSLPs?
Would the NTLP define how the Session ID be formatted?

As described also in your mail, the Session ID is not able to fully
replace the Signaling Application ID.  Therefore, I think the SAID
format still has to be formally defined to achieve interoperability.  If
the framework could not do it, would NTLP draft able to define it?  I
feel maybe it is better to put a pointer in the framework draft to that.

Also, I am not quite clear about the statement "it seems likely that the
session id will be an object in the NTLP".  Does it mean the Session ID
would be generated and maintained in NTLP, and it would be carried at
NTLP headers?

Thank you very much for your time and attention.

Regards,
Kim Hui

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

---

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 6 Nov 2003 08:07:18 -0000

hi melinda,

two points:

> -----Original Message-----
> From: Melinda Shore [mailto:[email-masked]]
> Sent: Wednesday, November 05, 2003 23:45
> To: Hancock, Robert
> Cc: [email-masked]
> Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-fw-05.txt
> 
> 
> On Wednesday, November 5, 2003, at 06:28 PM, Hancock, Robert wrote:
> > For the nearly-orthogonal and quite restricted functionality to
> > handle (1), at the moment we are trying to make it possible to do
> > this in the NTLP (at least partly for the reasons you describe).
> > We could have made a design decision that
> > - the NAT should implement the functionality of (2), and
> > - the signalling application should use it to fill out its payloads
> > and this remains a possible approach, but I think it's overkill for
> > a lot of scenarios. It might still be the right way in particularly
> > paranoid security environments. Of course, we would have to 
> be careful
> > that nodes don't try to do things both ways at the same time.
> 
> It's actually not very complex to tag addresses and put them in the
> NTLP with a "translate me" flag and put tags in the NSLP payloads.
> Another advantage of doing that, aside from providing optional
> support for translation of an address in any NSLP, is that you
> don't have to worry about application payload rewrites breaking
> integrity protection, and you don't have to deal with having
> an application do a credentials exchange with both its peers and
> whatever NATs may be along the path.  I think it's a lot simpler
> and provides both better function and better security, but it's
> certainly not what's in the framework and you might not want to
> deviate at this late date.

on the framework front, please check the end of 4.6.1:
"  We've assumed here that the flow identification is not hidden within 
   the NSLP, but is explicitly part of the NTLP. The justification for 
   this is that it might be valuable to be able to do NSIS processing 
   even at a node which was unaware of the specific signaling 
   application (see section 3.2.3): an example scenario would be 
   messages passing through an addressing boundary where the flow 
   identification had to be re-written."
i think this is saying something pretty close to what you are
saying. what do you see as the main difference? (see also the mailing
list on "Re: [NSIS] comments on NTLP design proposals" around 17/7/03
where this was discussed in a bit more detail.)

on the security front, the issues are non-trivial. a basic problem
is that an on-path adversary can re-write the flow id to make it 
refer to a different flow, hence stealing the reservation (or 
whatever the signalling is controlling); the fact that you can
re-write the address fields without breaking integrity protection
(as you mention) is both a benefit and a cost. this sort of issue
needs more analysis in the NTLP design work (i don't think there
is a perfect answer which satisfies the demands both of security
and ease of deployment).

cheers,

r.

> Melinda