Re: [Int-area] comment on draft-ietf-intarea-gre-ipv6

[Tom Herbert <[e-mail]>]

On Mon, Mar 9, 2015 at 10:55 AM, Lucy yong <[e-mail]> wrote:
> Hi Templin,
>
> -----Original Message-----
> From: Templin, Fred L [mailto:[e-mail]]
> Sent: Monday, March 09, 2015 12:15 PM
> To: Lucy yong; Ronald Bonica; [e-mail]
> Subject: RE: [Int-area] comment on draft-ietf-intarea-gre-ipv6
>
> Hi Lucy,
>
> Also, you say:
>
>>  [Lucy] RFC2473 is about IPv6 in IPv6, i.e., IPv6 as a delivery network for IPv6 traffic.
>
> but that is not correct. RFC2473 is about "Generic Packet Tunneling in IPv6", which could include encapsulation of IPv4, IPv6, or other network protocols - and not just
> IPv6 within IPv6 encapsulation.
> [Lucy] You are right. It has that generalization although very focusing on IPv6. The misdelivery and corruption issues are concern there too. The draft is very old (1998). IPv6 was barely deployed then. We should address or document these issues if we are working on it now.
>

We added this paragraph to the GRE-in_UDP draft to describe how the
keyid might be used as a weak authentication. This might be applicable
to gre-ipv6 also:

An implementation MAY use the GRE keyid to authenticate the
   encapsulator. In this model, a shared value is either configured or
   negotiated between an encapsulator and decapsulator. When a GRE-in-
   UDP packet is received with the keyid present, it is checked to see
   if it is valid for the source to have set for the tunnel packet was
   sent on. An implementation MAY enforce that a keyid be used for
   source authentication on selected tunnels. When a decapsulator
   determines a presented keyid is not valid for the source to send or
   the keyid is absent and is considered required for authenticating
   the encapsulator for a tunnel, the packet MUST be dropped.

Thanks,
Tom

> Thanks,
> Lucy
>
> Thanks - Fred
> [e-mail]
>
>> -----Original Message-----
>> From: Int-area [mailto:[e-mail]] On Behalf Of
>> Templin, Fred L
>> Sent: Monday, March 09, 2015 7:52 AM
>> To: Lucy yong; Ronald Bonica; [e-mail]
>> Subject: Re: [Int-area] comment on draft-ietf-intarea-gre-ipv6
>>
>>
>>
>> > -----Original Message-----
>> > From: Lucy yong [mailto:[e-mail]]
>> > Sent: Sunday, March 08, 2015 10:05 AM
>> > To: Templin, Fred L; Ronald Bonica; [e-mail]
>> > Subject: RE: [Int-area] comment on draft-ietf-intarea-gre-ipv6
>> >
>> > Hi Templin,
>> >
>> >
>> > > -----Original Message-----
>> > > From: Int-area [mailto:[e-mail]] On Behalf Of
>> > > Lucy yong
>> > > Sent: Thursday, March 05, 2015 12:09 PM
>> > > To: Ronald Bonica; [e-mail]
>> > > Subject: Re: [Int-area] comment on draft-ietf-intarea-gre-ipv6
>> > >
>> > > Hi Ron,
>> > >
>> > > RFC2784 has this statement: See [RFC1122] for requirements relating to the
>> > >    delivery of packets over IPv4 networks.
>> > > Does this apply to over IPv6 networks?
>> > >
>> > > Since IPv6 header does not have checksum, if a packet is
>> > > mis-delivered to GRE decapsulator, will that cause a concern? This is not a concern when IPv4 network is the delivery network.
>> >
>> > In terms of header integrity checks, they are very much in the same boat as RFC2473.
>> > But, somehow that got standardized.
>> > [Lucy] RFC2473 is about IPv6 in IPv6, i.e., IPv6 as a delivery
>> > network for IPv6 traffic. Since IPv6 packets and upper layer
>> > applications have to follow RFC2460, i.e., protect the misdelivery
>> > and corruption, so that is OK if there is only such kind of tunnel
>> > in IPv6. GRE-in-
>> > IPv6 is deferent. They can't be in the same boat. If there are
>> > various network protocols that are tunneled over a same IPv6
>> > network,
>> it
>> > will have a problem due to packet misdelivery and corruption. IMO: the draft needs to document these.
>>
>> Oh, I thought you were concerned about lack of an integrity check for
>> the encapsulating
>> IPv6 header. Are you saying that (in the RFC2473 case at least) it is
>> OK to omit an integrity check for the encapsulating IPv6 header as
>> long as there is an integrity check for the encapsulated IP header? But, somehow that is not OK for draft-ietf-intarea-gre-ipv6?
>>
>> Thanks - Fred
>> [e-mail]
>>
>> > Thanks,
>> > Lucy
>> >
>> > Thanks - Fred
>> > [e-mail]
>> >
>> > > Thanks,
>> > > Lucy
>> > >
>> > >
>> > > -----Original Message-----
>> > > From: Ronald Bonica [mailto:[e-mail]]
>> > > Sent: Thursday, March 05, 2015 11:57 AM
>> > > To: [e-mail]; Lucy yong
>> > > Subject: RE: [Int-area] comment on draft-ietf-intarea-gre-ipv6
>> > >
>> > > Hi Lucy,
>> > >
>> > > The goal of this draft is *not* to prove the GRE behaves
>> > > identically with IPv6 as it does with IPv4. In fact, its goal is to point out the differences.
>> > >
>> > > Can you think of any differences between the two GRE environments that we have failed to point out?
>> > >
>> > >
>> > > Ron
>> > >
>> > >
>> > > >
>> > > > Message: 1
>> > > > Date: Wed, 4 Mar 2015 15:25:54 +0000
>> > > > From: Lucy yong <[e-mail]>
>> > > > To: "[e-mail]" <[e-mail]>
>> > > > Subject: [Int-area] comment on draft-ietf-intarea-gre-ipv6
>> > > > Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4545BB21@dfweml701-
>> > > > chm>
>> > > > Content-Type: text/plain; charset="us-ascii"
>> > > >
>> > > > Hi,
>> > > >
>> > > > If this draft is to document the protocol of gre in IPv6 exact
>> > > > same as of gre in
>> > > > IPv4 and update rfc2784, IMHO, it should point out the gre
>> > > > application behavior differences in IPv4 network and IPv6 network.
>> > > > The exact same protocol does not mean the same behavior for an
>> > > > application since IPv4 and
>> > > > IPv6 networks have different behaviors such as header checksum.
>> > > >
>> > > > Thanks,
>> > > > Lucy
>> > > >
>> > > >
>> > > >
>> > > >
>> > >
>> > > _______________________________________________
>> > > Int-area mailing list
>> > > [e-mail]
>> > > https://www.ietf.org/mailman/listinfo/int-area
>>
>> _______________________________________________
>> Int-area mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/int-area
>
> _______________________________________________
> Int-area mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/int-area