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

From: Giles Heron <[email-masked]>
Date: Wed, 18 Feb 2015 15:18:56 +0000

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-masked]> wrote:

> Hi,
>  
> my comments about the draft:
> 1. As far as I know the IETF processes this must be a standards track draft instead of a informational, as it not only simplifies the tunnels like removing the control plane, but uses MUST where the L2TPv3 RFC only set it as optional (e.g. Cookie).

fixed

> 2. In my opinion the terms key, cookie and authentication key for the required 64bit cookie should be cleaned up, as the terms have in some context of the rfc the same meaning

fixed - using cookie everywhere.

> 3. Why is the explicit value for the hop limit mentioned? In my opinion it should be lower, or are there any implementations which really use that value as a default? Should be rewritten to something without a fixed hop limit

fixed.

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

> 5. I didn't understand the meaning of the last sentence:
>    o  Payload.  The customer data, with s-tag or s-tag/c-tag removed.
>       As noted above preamble and FCS are stripped before encapsulation.
>       A new FCS will be added at each hop when the IP packet is
>       transmitted.
> 
> There is no relation between the routing of the l2tp packet and the payload FCS, as there is no FCS in the payload.

good catch.  The intent of the section is to show that the original FCS doesn't need to be carried as an FCS is added at each hop.  I've reworded the sentence to reflect that.

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

Giles

>  
> Regards
> 
> Karsten
> 
>  
>  
> Am Dienstag, 13. Januar 2015, 09:59:28 schrieb Ole Troan:
> > Thanks Karsten, I look forward to your review.
> > 
> > Best regards,
> > Ole
> > 
> > > On 12 Jan 2015, at 12:52 , Karsten Thomann <[email-masked]>
> > > wrote:
> > > 
> > > As Jinmai already wrote, I can volunteer, but only under the same
> > > constrains, as I have no prior experience with reviews.
> > > 
> > > Some comments:
> > > I know it is also written in RFC4719, but why was "or" used at "Ethernet
> > > frame, without the preamble or frame check sequence (FCS)". At the
> > > payload section is "and" used...
> > > "As noted above preamble and FCS are stripped before encapsulation."
> > > 
> > > As already written by Jinmai, the hop limit is with 255 as a default
> > > setting a bit high, a default of 64 should be high enough for nearly all
> > > cases.
> > > 
> > > Kind regards
> > > Karsten
> > > 
> > > Am Dienstag, 6. Januar 2015, 12:14:14 schrieb Ole Troan:
> > > > Hi,
> > > > 
> > > > The chairs of l2tpext have asked for a 6man review of:
> > > > 
> > > > Title: Keyed IPv6 Tunnel
> > > > https://tools.ietf.org/html/draft-ietf-l2tpext-keyed-ipv6-tunnel-01
> > > > 
> > > > Can we get a couple of volunteers please? As well as any other comments
> > > > to
> > > > the lists are welcome of course. Please keep [email-masked] in CC.
> > > > 
> > > > Best regards,
> > > > Ole
> > > > 
> > > > --------------------------------------------------------------------
> > > > IETF IPv6 working group mailing list
> > > > [email-masked]
> > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > > --------------------------------------------------------------------
>  
> _______________________________________________
> L2tpext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/l2tpext

---

From: Karsten Thomann <[email-masked]>
Date: Fri, 20 Feb 2015 18:03:39 +0100

Hi Giles

comments inline.

> On 22 Jan 2015, at 14:50, Karsten Thomann 
<[email-masked]> wrote:
...
> > 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?

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

Regards
Karsten

---

From: Giles Heron <[email-masked]>
Date: Tue, 24 Feb 2015 14:33:59 +0000

Hi Karsten,

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

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

> > > packets for a specific local l2tp ip as the cookie must be configured and
> > I'm not sure the cookie needs to be unique per tunnel?  The session ID is
> 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:
>    port ID and VLAN ID(s) on the access side, and by a Source and Destination
> 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).

> > > section, but in RFC 3931 it is mentioned that there are no checksums for
> > isn't that more of an issue of detecting corrupted packets than a security
> > 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

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 25 Feb 2015 03:24:14 +0000

Hi Giles,

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

Hi Karsten,

On 20 Feb 2015, at 17:03, Karsten Thomann <[email-masked]<mailto:[email-masked]>> wrote:

Hi Giles

comments inline.

more inline:

On 22 Jan 2015, at 14:50, Karsten Thomann <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

...

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-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/l2tpext