Subject: Re: [Bier] Stephen Farrell's No Objection on charter-ietf-bier-00-01: (with COMMENT)

From: Alia Atlas <[email-masked]>
Date: Thu, 19 Feb 2015 11:00:19 -0500

Hi Stephen,

On Thu, Feb 19, 2015 at 10:47 AM, Stephen Farrell <[email-masked]
> wrote:

> Stephen Farrell has entered the following ballot position for
> charter-ietf-bier-00-01: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/charter-ietf-bier/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> I'm fine with this going for external review.
>
> I would like to see the security properties of Bier called out more
> as something that the proposed WG will address, e.g. does the
> work to date include any integrity mechanisms so that one could
> check if a bit-flip is causing packets to be sent to the "wrong"
> places? Is there some (usable) security mechanism in place
> for establishing the bit-mask value to use at ingress? Etc.
>

I did talk with Greg and Tony about the possibility of having an integrity
mechanism,
though MPLS doesn't and has been working ok.   It is something that should
be
discussed in the context of an encapsulation; I just don't see it as
something that
needs to be pulled out into a separate work-item in the charter.

I'm happy to chat with you and get your thoughts on what additional
security mechanisms might make sense to be concerned about.  The integrity
of
the bitmap was the only one that I easily saw.

Alia

---

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 19 Feb 2015 07:47:58 -0800

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 19 Feb 2015 18:35:33 +0000

Hiya,

> needs to be pulled out into a separate work-item in the charter.

Well, folks do sometimes forget security things if they're not
called out, but I can live with that:-)

> the bitmap was the only one that I easily saw.

Yep. Well, protecting it's integrity in transit, but presumably also
trying to ensure one starts out with the right bit-mask as well.

I agree though that generic mpls things (like opportunistic security:-)
oughtn't be intertwined here.

Cheers,
S.

---

From: Antoni Przygienda <[email-masked]>
Date: Fri, 20 Feb 2015 23:02:35 +0000

What I suggested off the bat is something like 2 bits 

1 - indicates presence of ECC bit 
2 - ECC bit 

treatment is probably simply discarding frames with corrupt bitmask. 

At least in MPLS encaps we have enough space in the back after the bitmask flew through before BFR-id. 

Optional because it may be additional burden on the hardware.

again, just a first shot idea without any further deeper thought  

--- tony 

> I would like to see the security properties of Bier called out more as something
> that the proposed WG will address, e.g. does the work to date include any
> integrity mechanisms so that one could check if a bit-flip is causing packets to be
> sent to the "wrong"
> places? Is there some (usable) security mechanism in place for establishing the
> bit-mask value to use at ingress? Etc.
> 
> 
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 20 Feb 2015 23:21:18 +0000

Hi Tony, 
Maybe we can get away with one bit: https://tools.ietf.org/html/rfc3514 ;)
Acee

---

From: Greg Shepherd <[email-masked]>
Date: Fri, 20 Feb 2015 16:21:06 -0800

I agree with higher level motivation, but particularly with MPLS encap why should BIER be treated with any more concern than all other MPLS packets?

Greg

Sent from my iPhone

> On Feb 20, 2015, at 15:21, "Acee Lindem (acee)" <[email-masked]> wrote:
> 
> Hi Tony,

---

From: Antoni Przygienda <[email-masked]>
Date: Sat, 21 Feb 2015 00:22:36 +0000

Honestly, after having been presented with the concern 
I was holding it with mild attempt to go after an Apr 1st draft but then the discussion started to sound serious ;-) 

BIER over Avian Carriers will have to do then (we'll need a new encapsulation type to pull it off, probably BIER-in-CANS or 
BIER-in-Bottles drafts to make sure the transport can lift it. You volunteer?  ;-) 

OK, me back to writing code here again and you get back to squint @ the yang models 

--- tony 

> -----Original Message-----
> From: Acee Lindem (acee) [mailto:[email-masked]]
> Sent: Friday, February 20, 2015 3:21 PM
> To: Antoni Przygienda; Stephen Farrell; The IESG
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Bier] Stephen Farrell's No Objection on charter-ietf-bier-00-01:
> (with COMMENT)
> 
> Hi Tony,
> Maybe we can get away with one bit: https://tools.ietf.org/html/rfc3514 ;) Acee
> 
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 21 Feb 2015 01:48:48 +0000

On 2/20/15, 7:22 PM, "Antoni Przygienda" <[email-masked]>
wrote:

>I was holding it with mild attempt to go after an Apr 1st draft but then
>the discussion started to sound serious ;-)
>
>BIER over Avian Carriers will have to do then (we'll need a new
>encapsulation type to pull it off, probably BIER-in-CANS or

I have extensive experience in this area and would be open to reviewing
some drafts in Dallas. I'd even review them without prior viewing (i.e.,
I¹ll review these BIER drafts cold...).

>OK, me back to writing code here again and you get back to squint @ the

Yeah - I do have to get back to those YANG models. But on a more serious
note, I don¹t believe we want to go down the path of encapsulation
security (MPLS, BIER, or otherwise). We will always have authentication in
the endpoints. 

Acee 

>>as
>> >>something

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 21 Feb 2015 02:34:31 +0000

Nothing to do with the bier charter's progression, but I'm curious...

On 21/02/15 01:48, Acee Lindem (acee) wrote:
> on a more serious

Can you translate that into something I understand I wonder? :-) When
you say "authentication in the endpoints" who do you mean is
authenticating what to whom?

Ta,
S.

PS: I'm fine continuing this chat offlist or in a fine bar in Dallas
(assuming an accessible one exists:-)

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 21 Feb 2015 12:24:17 +0000

>authenticating what to whom?

I meant that multicast receivers could authenticate received multicast
packets. Upon further reflection, this probably isn’t all that relevant or
interesting. The security considerations for BIER are similar to
conventional multicast except that the multicast core doesn’t have all the
(S,G) state. Hence, I believe what really needs to be defined is the level
of trust required within a BIER domain and the role of the BIER domain
border routers in protecting that domain.

Thanks,
Acee