Subject: Re: I-D.ietf-v6ops-cpe-simple-security-10

From: Robert Moskowitz <[email-masked]>
Date: Tue, 20 Apr 2010 09:27:35 -0400

I discussed this briefly with James during IETF 77.

HIP is on track to be reved for standards track.  It is assigned 
Protocol number 139, and should be treated by cpe-simple-security the 
same as IKE.  I will offer my best effort at text below.

I apologize for the few week delay, Passover came RIGHT after IETF.  And 
I SUPPOSE I should have pushed this 6 months ago while we were pushing 
to get HIP moving towards standards.  But that is water under the bridge...

On 03/29/2010 05:43 PM, james woodyatt wrote:
> concerned--
>
> This is to inform the chairs of the V6OPS working group that it is the sense of the editor of draft-ietf-v6ops-cpe-simple-security and the design team that worked most closely on it during its development, that the latest posted revision, i.e. -10, is ready for Working Group Last Call.

In sec 2.2 add at the end of the para:

HIP is also explicitly secured by definition, so this document 
recommends the DEFAULT operating mode permit Host Identity Protocol 
(HIP) flows to pass without filtering.

Add sec 3.2.6:

3.2.6  Host Identity Protocol (HIP)

Host Identity Protocol (HIP) offers greater flexibility and better 
overall security than the simple security of stateful packet filtering 
at network perimeters.  Therefore, residential IPv6 gateways need not 
prohibit HIP traffic flows.

REC-nn: In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit 
the forwarding of packets, to and from legitimate node addresses, with 
destination extension headers of type "Host Identity Protocol (HIP)" 
[RFC5201] in their outer IP extension header chain.

{note here, 5201-bis exists, but it will take a few months to finish 
this (we are NOT expecting a long process to add the agreed changes to 
5201).  The new RFC will be tagged as Standard, but will use the same 
protocol number.}

REC-nn: In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit 
the forwarding of packets, to and from legitimate node addresses, with 
an upper layer protocol of type "Encapsulating Security Payload (ESP)" 
[RFC4303] in their outer IP extension header chain.

{note this is the same text as REC-21, as HIP uses ESP in TRANSPORT mode.}

{note:  There is no easy equivalence of REC-23 with HIP due to its 
mobility.  In RFC 5206 we cover mobility and mid-box updating of moves.  
But do you want that here?  In HIP the SPI is all you can count on, as 
the IP address pair are mutable during the life of the SPI.}

In sec 8.1 add:

RFC 5201

Thank you.

---

From: james woodyatt <[email-masked]>
Date: Tue, 20 Apr 2010 10:59:41 -0700

On Apr 20, 2010, at 06:27, Robert Moskowitz wrote:

> HIP is on track to be reved for standards track.  It is assigned Protocol number 139, and should be treated by cpe-simple-security the same as IKE.  I will offer my best effort at text below.

I agree.  If no one objects, I will import the suggested amendments.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Mark Smith <[email-masked]>
Date: Wed, 21 Apr 2010 20:22:04 +0930

On Tue, 20 Apr 2010 10:59:41 -0700

> I agree.  If no one objects, I will import the suggested amendments.

Would it be possible to make these rules a bit more general, such that
they'd automatically cover things like IPsec, HIP or any other current
(e.g. ssh) or future protocols that are authenticated, without
nominating the protocols specifically? It seems to me that it is only
really luck rather than good planning that there is the opportunity to
add HIP in as a specified exception at this time.

Regards,
Mark.

---

From: Timothy Baldwin <[email-masked]>
Date: Thu, 22 Apr 2010 17:38:11 +0100

Mark Smith wrote:
> nominating the protocols specifically?
There are many ssh servers with default or poorly chosen passwords, so
that might not be a good idea.

---

From: Mark Townsley <[email-masked]>
Date: Thu, 22 Apr 2010 19:05:34 +0200

>> nominating the protocols specifically?

Being able to adapt to future protocols implies that there be a
mechanism to communicate this adaptation. simple-security doesn't have
that.

> that might not be a good idea.

So Bob's bad password means Alice has to figure out how to configure a
pinhole for ssh because she wants her ssh to be reachable from the
Internet. Hardly fair, particularly when we don't even know what the
intrusion rate would be for a given service/protocol over IPv6.

Modern IPS firewalls actually have provisions for sniffing and blocking
login attempts from the outside using poor/default passwords. But this
isn't foolproof, and requires digging deeply into packets.

It would be really nice if applications would be easily configurable for
what IPv6 address scope they could use. Then when you turn on SSH, you
are simply asked whether it should be made available on the Internet or not.

- Mark

---

From: Konrad Rosenbaum <[email-masked]>
Date: Fri, 23 Apr 2010 09:30:48 +0100

On Thursday 22 April 2010, Mark Townsley wrote:
> Internet.

On the other hand: Alices (I would call Alice a geek - she is using ssh 
after all) desire to have a reachable ssh port means that Bob (let's assume 
he knows nothing about computing, but is a very fine chef) is vulnerable to 
attacks. Just because nobody told him to click a specific button that he 
knew nothing about.

I would assume Alice capable of opening a port, but would guess Bob gets 
very apprehensive when he is told to configure his home router.

> Hardly fair, particularly when we don't even know what the 

I think we can assume it to grow proportionately with the growth of IPv6 - 
it is practically nil now because attackers don't consider IPv6 gurus dumb 
enough to have default passwords on open ssh ports.

> isn't foolproof, and requires digging deeply into packets.

I don't think the master chef Bob would have an IPS firewall - all he wanted 
was to connect his kitchen computer to this Internet thing because we heard 
there were good recipes out there.

> are simply asked whether it should be made available on the Internet or

Open a feature request on your favorite bugzilla... ;-)

More realistically: there will always be thousands of very popular 
applications out there with insecure defaults. I spent the last ten years 
(that's my entire career) trying to educate my programmer colleagues and 
friends about secure programming. I think I can count the ones I've reached 
on one hand - either I'm a bad teacher or it is not a popular topic.

	Konrad

---

From: Mark Smith <[email-masked]>
Date: Sat, 24 Apr 2010 01:12:35 +0930

On Thu, 22 Apr 2010 17:38:11 +0100

> that might not be a good idea.

There are, of course, always corner cases. Passwords in themselves
aren't fundamentally very good, but in most cases we seem to persist
them them. Physical tokens, as an example of 2 factor authentication,
are a relative rarity.

CPE can't protect their users from being stupid when picking passwords.
As much as they shouldn't really have to, that role is best performed by
the point of entry of the password itself. If a protocol has the
property of authentication, then I think the CPE should trust it, and
make issues such as password quality the responsibility of the
end-nodes/end-points.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Sat, 24 Apr 2010 01:22:41 +0930

On Thu, 22 Apr 2010 19:05:34 +0200

> mechanism to communicate this adaptation. simple-security doesn't have

I think that if there is a statement of baseline expected security
for protocols, then a CPE vendor could add it as a default allow.
e.g. If XYZ security protocol, invented in 2015, and operating over UDP
port ABC, has end-to-end integrity as one it's properties, then vendors
who make CPE that is compliant with this draft can add UDP port ABC to
the list of permitted end-to-end protocols in 2015/2016. I think it is
possible to do that without being tied to specifying particular
protocols, as long as the required security properties are specified.
Otherwise we're in the trap of revising this draft/RFC for every new
protocol that has end-to-end integrity.

Regards,
Mark.

---

From: james woodyatt <[email-masked]>
Date: Fri, 23 Apr 2010 14:36:26 -0700

On Apr 23, 2010, at 08:52 , Mark Smith wrote:
> 
> Otherwise we're in the trap of revising this draft/RFC for every new protocol that has end-to-end integrity.

Alas, I don't think we will quickly arrive at a consensus on more general language.

I'm adding HIP, and I'm clarifying the intent not to break MIPv6, because I think there won't be any objection to either of those changes.  I'm going to exercise editorial judgment and hold off on attempting to make a more generalized statement about unspecified future protocols.  I think the working group is interested in keeping I-D.ietf-v6ops-cpe-simple-security simple.  More advanced considerations, I would say, ought to be deferred for later publication.