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

[Gopal Dommety <gdommety@cisco.com>]

At 10:32 AM 01/06/00 -0400, Randy Bush wrote:
>( 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.  
>

Are you saying this because the attcker can send bogus IP sec packets and so
we cannot 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).

If we assume that the delivery protocol is IP then


BEFORE APPLYING AH

the packet will look like 

    IP hdr | GRE header| Payload

AFTER APPLYING AH  (example transport mode)
 
    IP hdr | AH | GRE header| Payload

Entire packet other than the mutable feilds are authenticated.  ESP will also work.

Please let me know you do not agree. I will add text and references to AH and ESP RFCs.



>
>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.

It is good to start randomly, then we need a message exchange to setup the tunnel to exchange the sequence number they will
need to start with. I did not assume that we always will have the message exchange. 


 
>
>-----------
>
>> 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.
>

I will reword it and send the text in the next hour.

>-----------
>
>> 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.

The intent is to ensure atleast inorder delivery and to leave reordering as an implentation choice.

>
>-----------
>
>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.  

That is correct. I will add this sentence.
>
>-----------
>
>Not specified in this draft - can one key and sequence number run 
>include multiple encapsulated protocol types?
>

The wording of the draft allows it. But, I would think that one key and sequence number run
will be used by one encap protocol type. Do you see a problem with the draft leaving open 
for multiple encap protocol types in a key and sequence?

>-----------
>
>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?

We should undeprecate these fields. Should this request be in the IANA section?

>
>>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"
>
>

Thanks
Gopal