Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts

From: [email-masked] (Patrice Calhoun)
Date: Wed, 27 Jan 1999 07:18:19 -0800

>
>>Bernard, these two paragraphs form a completely adequate (to me)
>>security section for the tunnel-impl draft!
>>(Of course, this depends on L2TP always using PPP inside; is this
>>always true?)
>
>Yes, L2TP always tunnels PPP.
>
>>Glenn, Bernard, is it OK to take this text and put it there
>
>Yes, it is ok to add the text below to the "Security considerations"
>section.
>
>>Absolutely.
>>That is *exactly* what a security section is supposed to be.
>>Or rather, for the tunnel-auth draft: The list of questions that each
>>mode of operation raises, which each tunnelling protocol has to answer.
>
>Such an analysis is supplied for L2TP in the L2TP security draft.
>Interestingly, while the draft was placed on the standards track by
>PPPEXT, it has been unclear to me what the IESG wanted to do
>with it. It was decided not to include it in the L2TP draft proper
>so as to allow its expedited advancement. Given the questions,
>I'd suggest that an L2TP security analysis is necessary and
>needs to be on the standards track.
>
>>
>>>Such an analysis belongs in the relevant protocol drafts, not in
>>>this set of documents.
>>
>>The answers, yes. The questions, no.
>
>From the above discussion, I think we can come up with an
>abreviated list of questions and brief answers relating to
>compulsory tunneling.
>
>>Failures of others.....the L2TP documents have been yelled at,
>>objected to, commented and asked for revisions of on so many other
>>points (including the need to document numerous security problems)
>>that the particular issues that pertain to operating a NAS box that
>>is not implicitly in the same trust domain as the tunnel endpoint
>>have not been raised.
>>It does not excuse us; WE are the ones responsible for the multi-domain
>>situation.
>>
>
>
>I'm available to assist in preparing any material relating
>to L2TP security that the IESG may request. My experience
>with this is that the issues can be somewhat intricate so that they
>are worth explaining in detail. These can include subjects as
>arcane as why L2TP/IPSEC is not compatible with NAT (answer
>has to do with IKE; if UDP checksumming is turned off and
>IPSEC ESP is used, L2TP/IPSEC packets should pass
>the NAT.)

I am not sure this is true. If the UDP Port numbers are not available to the
NAT gateway, how would it work? Perhaps you mean address, and not port 
translation. However, port translation is really what's used out there today.

PatC

>
>-
>To unsubscribe, email [email-masked]' with
>'unsubscribe ietf-radius' in the body of the message.

-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: Glen Zorn <[email-masked]>
Date: Wed, 27 Jan 1999 19:00:59 -0800 (PST)

On Wed, 27 Jan 1999, Patrice Calhoun wrote:

> >>mode of operation raises, 

I'm not quite clear on what you mean by 'modes of operation'.

> >>which each tunnelling protocol has to answer.

Sorry, Harald, but this makes no sense to me: it's like putting the
security considerations for every unix command into the man page for rsh.
Realistically, that's just what we're doing here: the RADIUS server is
telling the NAS to start a tunnel to a certain destination.

-