Re: [L2tpext] 6MAN cross-wg review: draft-ietf-l2tpext-keyed-ipv6-tunnel-01

[Giles Heron <[e-mail]>]

Hi Karsten,

thanks again for your comments.  Apologies for my slow response - more inline:

On 20 Feb 2015, at 17:03, Karsten Thomann <[e-mail]> wrote:

> Hi Giles
>  
> comments inline.
>  
> Am Mittwoch, 18. Februar 2015, 15:18:56 schrieb Giles Heron:
> > Hi Karsten,
> > 
> > thanks for your comments.  My apologies for the delay in processing them.
> > 
> > more inline:
> > 
> > On 22 Jan 2015, at 14:50, Karsten Thomann <[e-mail]> wrote:
> > > Hi,
> > > 
> ...
> > > 4. Is there any reason to not use src + dst ip for all cases instead to
> > > only use it for the case that the local ip is used for more than one
> > > tunnel? I think every device should know from which IPs it receives
> > > packets for a specific local l2tp ip as the cookie must be configured and
> > > should be unique per tunnel.
> > I'm not sure the cookie needs to be unique per tunnel?  The session ID is
> > unique per tunnel/IP address pair.  And in the 1:1 case the session ID is
> > ignored.
> I will try rephrase it in another way, I was thinking about if it is possible to merge section 2 and 4 at chapter 2:
>    The IPv6 L2TPv3 tunnel encapsulating device uniquely identifies each
>    Ethernet L2 attachment connection by a port ID or a combination of
>    port ID and VLAN ID(s) on the access side, and by a Source and Destination
>    IPv6 address pair on the network side.
>  
> I can't think about a case where this should cause problems, as it won't forbid the use of a single address for multiple tunnels or are there any deployment scenarios where it should be possible to use multiple source IPs to send traffic to a single tunnel?

Agreed, there's no reason to use multiple source IPs to send to a single tunnel.  The canonical use-case for the 4th paragraph of section 2 is where tunnels terminate on loopback or anycast addresses (as discussed in section 3).

However in the case where you terminate a tunnel on a physical port or a port/VLAN performance may be higher if you don't check the remote IP (of course there may be security implications to that - but then we have the 64-bit cookie).

In fact it may be that we should rewrite the 4th paragraph to make it clear that in the loopback/anycast case the local end is identified by the loopback/anycast address and the remote end by the remote IP (as for the port and port/VLAN cases).

> > > 6. I'm not sure if it should be added to the security considerations
> > > section, but in RFC 3931 it is mentioned that there are no checksums for
> > > the packets as ipv6 and l2tp have none. I know it was especially
> > > mentioned for the control packets, but it also applies to all other
> > > packets with payload.
> > isn't that more of an issue of detecting corrupted packets than a security
> > consideration?  Re detecting corrupted packets we already have two
> > mechanisms: 1) the hop-by-hop FCS
> > 2) the payload's own mechanisms (in general the keyed IP tunnel will be
> > carrying UDP and TCP traffic that has its own checksum).
> > 
> > so I guess the question is whether there's much value in inserting another
> > level of check in between those two (e.g. an end-to-end integrity check for
> > the tunnel itself)?
> As noted I'm really sure if it should be added, I know there was a lenghty diskussion about checksums for some tunnel mechanisms, but not sure if it was mpls over udp or a gre over IPv6 draft...
> If no one else is thinking that it should be noted that there is no end to end checksum I'm fine with it.
> 

Yes, there's an option with MPLS PWE to cary the checksum end to end (RFC4720).  I'm not sure if any other tunnelling technologies that do the same.  Certainly we can make FCS retention an option if consensus is that it's a useful option.

Giles

> Regards
> Karsten
>  
> > Giles
> > 
> > > Regards
> > > 
> > > Karsten
> > >