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

Hi Giles,

On Feb 24, 2015, at 9:33 AM, Giles Heron <[email protected]<mailto:[email protected]>> wrote:

Hi Karsten,

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

On 20 Feb 2015, at 17:03, Karsten Thomann <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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.


L2TPv3 PWs also allow for FCS Retention already:
https://tools.ietf.org/html/rfc4720#section-4

So you can specify it as an option if it makes sense.

Thanks,

— Carlos.

Giles

Regards
Karsten

Giles

Regards

Karsten


_______________________________________________
L2tpext mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/l2tpext

_______________________________________________
L2tpext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/l2tpext