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

[Karsten Thomann <[e-mail]>]

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?

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

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