Subject: Re: [Tsv-art] [Last-Call] Tsvart last call review of draft-ietf-ospf-ospfv2-hbit-10

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 2 Nov 2019 19:03:02 -0700

Hi Padma,

On Thu, Oct 31, 2019 at 03:50:45PM -0700, Padma Pillay-Esnault wrote:
> Hi Kyle
> 
> Thank you for your review
> 
> Please see below PPE
> 
> On Thu, Oct 31, 2019 at 2:47 PM Kyle Rose via Datatracker <[email-masked]>
> wrote:
> 
> * I'm curious what happens if a router sets the H-bit when it is on the only
> > feasible transit path.
> >
> 
> PPE - The router with the H-bit set will not be "on the only feasible
> transit path" to other destinations.  The H-bit functionality will exclude
> the host router from the path calculation in the SPF.

I think you are talking about normal operation ("will not be on the only
feasible transit path") and Kyle is asking about misconfiguration or
similar edge cases.

Having only read this email thread and not the document itself, I assume
that traffic will fail to flow if such a misconfiguration occurred, but it
would be good to confirm/refute that.

Thanks,

Ben

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Sun, 3 Nov 2019 11:28:11 -0800

Hi Ben

> feasible transit path") and Kyle is asking about misconfiguration or

Thanks for this clarification.

> would be good to confirm/refute that.

Yes you are right ... for some cases.

Assuming the router with the H-bit clear is on the only transit path. There
are several cases see below.

Normal case:
The router has H-bit set
(a) All routers in the area support the H-bit then the router is excluded
in the SPF calculations and traffic will not flow.
(b) At least one router in the area does not support H-bit then H-bit is
not active in area.  The traffic will flow as per normal OSPF operation.

Misconfiguration case:
The router has H-bit erroneously set (misconfig)
(a) All routers in the areas support H-bit then the router is excluded in
the SPF calculations and traffic will not flow.
(b) At least one router in the area does not support H-bit then H-bit is
not active in area.  The traffic will flow as per normal OSPF operation.

The Section 8 of the document has a discussion on this.

Hope that this addresses your comment.

Thanks
Padma

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 7 Nov 2019 08:58:30 -0800

On November 3, 2019 at 2:28:29 PM, Padma Pillay-Esnault wrote:

Padma:

Hi!

See below...

> On Sat, Nov 2, 2019 at 7:03 PM Benjamin Kaduk wrote:
> > > On Thu, Oct 31, 2019 at 2:47 PM Kyle Rose via Datatracker
> > > wrote:
> > >
> > > > * I'm curious what happens if a router sets the H-bit when it is on the
> > > > only feasible transit path.
> > >
> (a) All routers in the area support the H-bit then the router is excluded in
> (b) At least one router in the area does not support H-bit then H-bit is not
> active in area. The traffic will flow as per normal OSPF operation.
>
> Misconfiguration case:
> (a) All routers in the areas support H-bit then the router is excluded in the
> SPF calculations and traffic will not flow.
> (b) At least one router in the area does not support H-bit then H-bit is not
> active in area. The traffic will flow as per normal OSPF operation.
>

Yes, there is a discussion in §8, but I think we left out the case
where a rogue router, who is on the only transit path, may set the
H-bit (for no good/valid reason) and effectively partition the
network.  This case is indistinguishable from the normal case where
the operator (still on the only transit path) may consciously decide
to set the H-bit to perform maintenance, for example.

Please add a new bullet to cover this case.

Thanks!

Alvaro.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 7 Nov 2019 17:06:10 +0000

Hi Alvaro, 

On 11/7/19, 11:58 AM, "Alvaro Retana" <[email-masked]> wrote:

    Padma:
    
    Hi!
    
    See below...

    

If an OSPFv2 router is a trusted participant in the OSPFv2 routing domain (with or without cryptographic authentication), there are at least 3 or 4 other ways in which it could partition the routing domain. This is just one more. However, I'm not opposed to adding the bullet as this is "what we do" during the security reviews. 

Thanks,
Acee

    Thanks!
    
    Alvaro.

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Thu, 7 Nov 2019 10:29:19 -0800

Hi Alvaro, Acee

Ack, I will spin a new version with the review comments and will add the
new bullet.

Thanks everyone for your valuable feedback and comments!

Padma

On Thu, Nov 7, 2019 at 9:06 AM Acee Lindem (acee) <[email-masked]> wrote:

> If an OSPFv2 router is a trusted participant in the OSPFv2 routing domain
> (with or without cryptographic authentication), there are at least 3 or 4
> other ways in which it could partition the routing domain. This is just one
> more. However, I'm not opposed to adding the bullet as this is "what we do"
> during the security reviews.
>
> Thanks,
> Acee
>
>
>     Thanks!
>
>     Alvaro.
>
>
>