Requirements for Separation of IP Control and Forwarding
draft-ietf-forces-requirements-10

From: RFC Editor
Subject: authors 48 hours: RFC 3654
          NOW AVAILABLE
Date: Fri, 21 Nov 2003 16:10:55 -0800
To: hormuzd.m.khosravi@intel.com, todd.a.anderson@intel.com
Cc: RFC Editor , Alex Zinin
    , Bill Fenner ,
    dro@zurich.ibm.com, David.Putzolu@intel.com

Registering IESG comments. Sent to the WG chairs
on Dec-11-2002

> Scott:
>                it seems to me that the text in 6.5 3) is too high-level
>                and not explicit enough on what functions have to be able to
>                be signaled

AZ:  guys didn't want to reinvent the wheel, so the text says
    whatever the model is, it must be sufficient to provide
    IntServ or DiffServ functions.

>                6.5 7) seems too terse - there are other things (like
>                the TCP-MD5 checksum) that are security related that
>                may need to be signaled - and it may be required to
>                pass paswords etc to the FE

AZ:  I'd be careful here. That section talks about _minimal_ function
    set. The example you bring is where some CE functionality is
    off-loaded to FEs. This definitely cannot be in the minimal
    set, as many FEs will just not do this.

>                did the WG discuss a requirement to be able to tell an FE
>                to duplicate a packet for the purposes of monitoring?
>                I expect this will be needed in the real world for
>                network management, DoS tracking and "lawful intercept"
>                (rfc 2804 will be an issue here)


AZ:  Good point. I don't think this has been discussed. We'll definitely
    need this for NetFlow-like functionality. There's a similar
    requirement for packet redirection, but duplication is different,
    of course.

> Steve:
> 7(2)(c) suggests TLS as an option. But 7(6) says that the protocol
> runs on top of an unreliable datagram protocol. TLS requires a
> reliable stream. This contradiction should be resolved.

AZ: need to resolve.


> Randy:

>  this is a pretty spacey document. it this engineering or is it
>  research? note that, as this is about routing, interoperability
>  requirements could come into early play.
>
>  in general, one gets the feeling that there was no agreement on one
>  single structure/architecture, so the document goes to the extreme
>  of generic and flexible. this was a basic fear when this wg was
>  chartered.
>
>  i.e. do they expect a CE from vendor A to work with an FE from
>  vendor B? interesting that no one from a router vendor is on the
>  list of authors. in reality, a router's control system has
>  intimate knowledge of the forwarding plane's implementation.

>  intro needs to be before definitions. one should be able to say
>  what this is without needing new definitions.

>  definitions use words like packet while at the same time trying to
>  allow an addressable entity to be an ether switch. the title is
>  "ip control".

>  security issues seem to be missed.

>  they got nat, filtering, and qos in, but not ipv4, ipv6, icmp,
>  cflow, psamp, ...

>  much of my problems above are still with the charter, and maybe not
>  so much with this document.

Some more from Steve later:

> Back on 26 November (Randy, maybe that will help you locate your
> comment), I said
>
>
>    7(2)(c) suggests TLS as an option.  But 7(6) says that the protocol
>    runs on top of an unreliable datagram protocol.  TLS requires a
>    reliable stream.  This contradiction should be resolved.
>
> Their response was to change "TLS" to "TLS (if transport is reliable)".
> They left alone the text that says "the ForCES protocol SHALL assume that
> it runs on top of an unreliable, datagram service."  To me, that still
> looks like a contradiction.
>
> The right answer is either to use their own security mechanism, but
> then they'd need seriously-expert help from the security area to design
> it, or to use IPsec.  *But* -- while a requirements document doesn't
> need to specify all the things that draft-bellovin-useipsec calls for,
> they need to show some signs of having thought through the
> requirements.  For example -- an IKE exchange is a half-dozen messages,
> plus some expensive calculations.  Is the link good enough for that? 
> Does the box have the horsepower to do the exponentiations?  Instead,
> do they need something like KINK or SNMPv3-style key management?  These
> really are requirements-level questions, since the answers turn on the
> operating environment they're assuming.

State Changes to AD Evaluation                                    from Pre AD Evaluation                                by azinin