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

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]> 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 protected]>
> > > 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 protected] in CC.
> > > > 
> > > > Best regards,
> > > > Ole
> > > > 
> > > > --------------------------------------------------------------------
> > > > IETF IPv6 working group mailing list
> > > > [email protected]
> > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > > --------------------------------------------------------------------
>  
> _______________________________________________
> L2tpext mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/l2tpext