RE: [NSIS] Lars Eggert: DISCUSS and COMMENT: draft-ietf-nsis-ntlp

["Robert Hancock" <[e-mail]>]

hi,

inline:

> -----Original Message-----
> From: Lars Eggert [mailto:[e-mail]] 
> Sent: 21 September 2006 00:27
> To: Robert Hancock
> Cc: [e-mail]; [e-mail]
> Subject: Re: [NSIS] Lars Eggert: DISCUSS and COMMENT: 
> draft-ietf-nsis-ntlp
> 
> 
> Hi,
> 
> below, I've cut all the stuff I agree with in your original email.
> 
> On Sep 20, 2006, at 16:01, Robert Hancock wrote:
> >>> Section 3.5., paragraph 8:
> >>>>    o  Messages with the same SID that are to be 
> delivered reliably
> >>>>       between the same GIST peers are delivered in order.
> >>>
> >>>  DISCUSS: If messages with the same SID go over different 
> messaging
> >>>  associations, there is a possibility that they reach the
> >> peer out-of
> >>>  order, even if each messaging association guarantees in-order
> >>>  delivery. I don't see this case addressed in the document.
> >>>
> >
> > it's not addressed explicitly; the simple solution is not to
> > distribute messages for the same SID over multiple associations.
> > if (for some reason) you need to create a new association while
> > an existing one is active, you can either close the existing one
> > gracefully (4.4.3) or use a MA-Hello request/response to flush
> > the connection. do you want this highlighted more?
> 
> I asume "this" is that only a single MA MUST be used for 
> messages for  
> the same SID? Then yes, please.

we'll add something to cover the topic.

> 
> >>>  Some IP options force packets onto a router's slow path, 
> which may
> >>>  contribute to resource exhaustion. I assume that the authors have
> >>>  verified that Router Alert Options are safe to use in 
> this regard?
> >
> > its difficult to be definitive. however, we do believe while not all
> > routers can handle the RAO in their fast path, at least some can,
> > and that from that point of view it is the safest way to 
> mark packets
> > for interception which also allows a subset of the marked packets to
> > be pulled out of the fast path for interception (which is basically
> > a requirement for the multi-application support). Further discussion
> > of the RAO is in the extensibility document. Basically, the path-
> > coupling mandate of NSIS requires packet interception, and the RAO
> > appears to have the optimum design for that.
> 
> We should involve the RTG/INT ADs here. We just had a discussion in  
> the IESG on a similar mechanism that used IP options, where the  
> stance was basically that everything that forces stuff on the slow- 
> path is almost a DoS on the router CPU.

I think one needs to be careful here. Since we are talking about 
signalling to control the router, all the signalling that is relevant
to the router will almost certainly cause an impact on the router
CPU. The best we can do is to minimise the impact of signalling 
traffic which is not relevant to the router in question. Given that
we're mandated to use packet interception for path coupling 
following the basic RVSP model, this means that we need
- something in the packet that marks it as a potential
  signalling packet
- something in the packet that the router can check efficiently
  to see if the packet can be ignored
I believe the RAO is a fairly precise match for this requirement.
There is more discussion of this in section 3.4 of 
http://tools.ietf.org/wg/nsis/draft-loughney-nsis-ext-02.txt
(that text originally came from the GIST spec).

Side note: interception techniques have been a topic since the 
start of NSIS. It was one of the biggest discussion points 
during the NTLP early review (search for 'interception' at
http://www3.ietf.org/proceedings/04mar/235.htm; Dave and Fred
are Oran and Baker respectively). The point made there is that,
if you are a bad person and want to DoS the router, there are
easier ways than RAO, if you can find out a router IP address.
If you are not a bad person, you want to make sure that the
marked packets are as small as possible percentage of the overall
traffic, and C-mode enables that (and the RAO design allows
rapid filtering of whatever is marked).

I don't believe that the ecn-alternates use of options is strictly
comparable. ecn-alternates (and similar mechanisms) require a
read-write operation on the option field, rather than a filter
comparison. Also, I assume it would apply to a much larger 
proportion of the total traffic than we are expecting here.

> 
> >>>  Many middleboxes drop packets with IP options (Alberto 
> Medina, Mark
> >>>  Allman, Sally Floyd. Measuring the Evolution of Transport
> >>> Protocols in
> >>>  the Internet. ACM Computer Communication Review, 35(2),
> >> April 2005.)
> >>>  Although I assume that this will mostly occur on the 
> first or last
> >>>  couple of hops, this can still interfere with end-to-end NSIS
> >>>  operation.
> >
> > true. one approach would be to allow a Querying node to fall back to
> > encapsulating without the RAO if the first message(s) fail. However,
> > this would interact with other fallback processing (source address
> > setting, relevant to the NAT discovery case) and would also make the
> > interception more complex.
> 
> Encapsulation would also alleviate the possible concerns due to use  
> of an IP option for the previous comment, so this might be something  
> that needs some investigation.

I am not clear on this. Note that encapsulation without using the 
RAO may make packets less likely to be dropped (solves one problem), 
but it makes the interception process harder because it requires 
5-tuple analysis (in fact, for v6 it would require complete header
chain analysis), so it makes the previous problem even worse). So 
there is a tradeoff to be made.

> 
> >>>  Additionally, because some
> >>>  messages MUST be carried in D- or Q-mode - is it guaranteed
> >>>  that their payloads are always less than 512 bytes?
> >
> > In theory no, because things like the cookies and peer identity
> > are variable length strings. But I just did a quick count, and
> > with a worst case for the other fields (e.g. using v6 addresses,
> > and a couple of possible stack proposals) adds up to about 150
> > bytes. So I think we are safe.
> 
> Since you were going to add MTU-related text anyway, it may be good  
> to point out that if payloads grow past the MTU, C-mode SHOULD be  
> used if possible.

OK.

> 
> >>> Section 5.4.2., paragraph 0:
> >>>>    5.4.2.  Encapsulation Format
> >>>
> >>>  Move up, section is not specific to C-mode. Section 5.4 should
> >>>  probably be restructured after these changes.
> >
> > Again, this is about C mode (see above).
> 
> But not only about C-mode  - D-mode uses the same encapsulation  
> format, no? (Similar to the prior comment, which should be 
> located in  
> the D-mode section, because it recommends to not use D-mode in a  
> specific case.)

Similar, but not the same. The same diagram for D mode would
- remove the security encpsulation annotation
- allow only a single GIST message
- have an optional RAO included (for Q-mode)
- have several different possible addresses in the IP header
  (for Q-mode)
- allow only UDP as a transport

In retrospect, I might be tempted to remove 5.4.2 or at least
figure 5 altogether, since it it actually technically wrong 
for the TCP case anyway (although in practice this seems to 
have caused no confusion!)

> 
> >>> Section 7.3., paragraph 0:
> >>>>     7.3.  Interaction with IP Tunnelling
> >>>
> >>>  This subsection doesn't really belong under "Advanced Protocol
> >>>  Features."
> >
> > Yes, it turned out to be less advanced than we expected.
> > Are you suggesting it to be moved earlier? From the point
> > of view of the document structure I'd prefer to leave it
> > where it is - it isn't needed to understand the earlier
> > sections, which are already pretty long.
> 
> Maybe just change the title of section 7?

'Additional'?

cheers,

r.

> 
> Lars
> -- 
> Lars Eggert                                     NEC Network 
> Laboratories
> 
> 
> 


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