Subject: RE: 3gpp-analysis-04: Security considerations [issue 11]

From: <[email-masked]>
Date: Fri, 22 Aug 2003 16:06:52 +0300

Yep, let's freeze this for a moment and try to complete the content of the doc first.

Cheers,
	-Juha-

-----Original Message-----
From: ext Pekka Savola [mailto:[email-masked]]
Sent: 06 August, 2003 12:05
To: Soliman Hesham
Cc: [email-masked]
Subject: RE: 3gpp-analysis-04: Security considerations

On Thu, 24 Jul 2003, Soliman Hesham wrote:
> Do you want to send text? Perhaps when you get back.
> This comment is a bit too open.

I think we had better to first try to settle the rest of the document 
(wrt. transition scenarios, etc.) because changes in those would affect 
the security considerations a lot too.

>  > -----Original Message-----
>  > From: Pekka Savola [mailto:[email-masked]]
>  > Sent: Thursday, July 24, 2003 11:20 PM
>  > To: [email-masked]
>  > Subject: 3gpp-analysis-04: Security considerations
>  > 
>  > 
>  > Hi,
>  > 
>  > The security consideration section of the 3GPP analysis 
>  > document is still 
>  > very weak; in principle, they only cover three points 
>  > related to NAT-PT 
>  > and/or DNSSEC.  A more thorough analysis is required.  
>  > 
>  > In addition to NAT-PT/DNSSEC issues (I'm not sure if the 
>  > three points are 
>  > a conclusive list, though), the security properties of different 
>  > transition scenarios and mechanisms should be briefly described.  
>  > 
>  > The exact contents depends a lot on which mechanisms we seem to get
>  > rough consensus on.
>  > 
>  > =====
>  >  5. Security Considerations
>  >                                                              
>  >                                                          
>  >          1. NAT-PT DNS ALG problems are described in [NATPT-DNS] and
>  >             [v4v6trans].
>  >                                                              
>  >                                                          
>  >          2. The 3GPP specifications do not currently define the usage
>  >             of DNS Security. They neither disallow the usage 
>  > of DNSSEC,
>  >             nor do they mandate it.
>  >                                                              
>  >                                                          
>  >          3. NAT-PT breaks DNSSEC.
>  > -- 
>  > Pekka Savola                 "You each name yourselves king, yet the
>  > Netcore Oy                    kingdom bleeds."
>  > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>  > 
>  > 
>  > 
> 

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Fred Templin <[email-masked]>
Date: Fri, 22 Aug 2003 16:47:48 -0700

Is RFC 2893-style automatic tunneling (i.e., with IPv4-compatible IPv6 
addresses)
used in any active deployments? It seems to me that the functionality is 
obsoleted
by newer automatic tunneling mechanisms (e.g., 6to4, isatap, etc.) but 
I'd like to
hear from those with more current operational experience.

Thanks  - Fred
[email-masked]

---

From: Fred Templin <[email-masked]>
Date: Tue, 26 Aug 2003 13:08:40 -0700

There was no answer to my question on RFC 2893-style automatic tunneling,
so I take this as a possible indication that no one is still using this 
mechanism.

Should we move to deprecate, then? If so, what form should the 
deprecation take?

Thanks - Fred
[email-masked]

Fred Templin wrote:

> used in any active deployments? It seems to me that the functionality 
> is obsoleted

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 26 Aug 2003 16:23:18 -0700

In fact I just had to deal with a customer asking about automated tunneling
of IPv4 over an IPv6-only network in the last couple of weeks. At this point
I am not sure if 2893 is the only way to solve the problem, but it is at
least one way. While it is creates some routing issues if used in the
greater Internet, it may have applicability in some closed configurations
without a massive number of routes. It would be premature to deprecate it at
this time.

Tony

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Fred Templin
> Sent: Tuesday, August 26, 2003 1:09 PM
> To: Fred Templin
> Cc: [email-masked]
> Subject: Re: RFC 2893-style automatic tunneling
> 
> 
> There was no answer to my question on RFC 2893-style 
> automatic tunneling, so I take this as a possible indication 
> that no one is still using this 
> mechanism.
>

---

From: Fred Templin <[email-masked]>
Date: Tue, 26 Aug 2003 16:18:33 -0700

OK. When will we see this document advanced for last-call?

Fred
[email-masked]

Alain Durand wrote:

> The answer is in draft-ietf-v6ops-mech-v2-00.txt:
>
>   Types of IPv6 Addresses
>
>        IPv4-compatible IPv6 address:
>
>                An IPv6 address bearing the high-order 96-bit prefix
>                0:0:0:0:0:0, and an IPv4 address in the low-order 32-
>                bits.  IPv4-compatible addresses are no longer used by
>                this specification, thus this definition is preserved in
>                the specification merely to clarify their non-use.
>
>
>    - Alain.
>
> Fred Templin wrote:
>
>> so I take this as a possible indication that no one is still using 
>> this mechanism.
>>
>>> Is RFC 2893-style automatic tunneling (i.e., with IPv4-compatible 
>>> IPv6 addresses)
>>> used in any active deployments? It seems to me that the 
>>> functionality is obsoleted
>>> by newer automatic tunneling mechanisms (e.g., 6to4, isatap, etc.) 
>>> but I'd like to

---

From: Alain Durand <[email-masked]>
Date: Tue, 26 Aug 2003 15:04:06 -0700

Types of IPv6 Addresses

    - Alain.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 29 Aug 2003 01:14:35 +0300 (EEST)

Hi,

Perhaps an update is in order.

> OK. When will we see this document advanced for last-call?

The document is being revised as we speak -- and hope to have a new 
version out soon.  Last call should be soon to follow.

Our updated milestones list moving RFC2893bis to DS for November 2003, but 
whether the changes are too extensive to warrant for that (and whether we 
can get implementation reports by then, etc.etc.) remains to be seen.

Pekka
(speaking as co-chair)

---

From: Pekka Savola <[email-masked]>
Date: Fri, 29 Aug 2003 07:52:57 +0300 (EEST)

> without a massive number of routes. It would be premature to deprecate it at

Having to use automatic tunneling over IPv6-only network would seem to
suggest a failure to consider dual-stack.   Or if the need for tunnels is 
not high, manual tunnels and a routing protocol could also suffice.

The automatic tunneling in its present form is simply too flawed (in
particular, the security considerations was never well defined), and has
to go.