draft-dommety-gre-ext-02.txt in iesg

[Randy Bush <randy@psg.com>]

( email comment from an iesger.  can you answer these in the next hour?  :-)


I realize this is a limited constituency draft, but 
it has security and other problems as currently specified.

Technical issues -

Security Considerations reasonably points out that injected bogus
sequence numbers can break delivery and then says:

>  In order to protect
>  against such attacks, IP security protocols [4] MUST be used to
>  protect the GRE header and the tunneled payload.

When the attacker uses bogus sequence numbers to cause discard 
of packets (making them appear to be out-of-order), protecting the
tunneled payload may possibly allow detection, but it can't prevent 
the attack.  

There's no way for IPSec AH as spec'd now to 
protect the GRE header (unless I have missed some extension to allow
an AH header outside the outermost IP header).

Referring to [4], RFC2401, the security architecture, is
pretty content-free.

-----------

> The first datagram is sent with a sequence number of 1.

Why mandate starting with 1?  There may be security advantages
to starting randomly, though for different issues than doing so
in TCP.

-----------

> The sequence number of a received message is
> considered less than or equal to the last successfully received
> sequence number if its value lies in the range of the last received
> sequence number and the preceding 2**31-1 values, inclusive.

This is either just unclearly written or else it also describes a 
sequence space that doesn't wrap around correctly.  The description
of sequence number wraparound and comparison should be taken from
RFC793 or something else clear.

-----------

> When the decapsulator receives an out-of sequence packet it
> SHOULD be silently discarded. 
...
>  The sequence number MAY be
>  used to restore the original sequence of packets that may have been
>  reordered during transport.

This use of SHOULD and MAY for contradictory treatments of out-of-order
packets may be valid logically, but it leaves the decapsulator 
behavior indeterminate, which seems like a bad specification move.

-----------

Under the method for reordering:

> maintaince of a per-flow buffer 

"Flow" has not been defined - presumably it's the set of packets with
sequence number set under a given key.  

-----------

Not specified in this draft - can one key and sequence number run 
include multiple encapsulated protocol types?

-----------

Standardization issues - 

The GRE RFC (2784) does not obsolete RFC 1701, which is 
Informational, but it does specifically deprecate the bits
that this spec wants to use.  It provides for a manner of
interoperating with RFC 1701 implementations.  Probably the
current spec needs to be more clear - is IETF undeprecating the
bits?  Should this be a use for the version field?

>From RFC 2784:

   In RFC 1701, the field described here as Reserved0 contained a number
   of flag bits which this specification deprecates. In particular, the
   Routing Present, Key Present, Sequence Number Present, and Strict
   Source Route bits have been deprecated, along with the Recursion
   Control field. As a result, the GRE header will never contain the
   Key, Sequence Number or Routing fields specified in RFC 1701.

   There are, however, existing implementations of RFC 1701. The
   following sections describe correct interoperation with such
   implementations.

-----------

Prose nits:

 Sentences beginning "Key field is", "Sequence field is" should
 start with "The" 

 "is lesser than or equal" -> "less"